Ironport Whitelist and related questions

[Slim.Jimmy]

Hi all,

I have recently started at a new position for a company that is utilising ironport as the email spam filtering/virus checking appliance.

Almost immediately after starting in my position issues were being discussed, where the senderbase reputation scoring was marking a sister companies mail as spam - obviously due to a bad reputation.

It was important that these mails were delivered and the obvious answer seemed to be to whitelist the domains, which was implemented by another support person. After the whitelist setting was applied though the mails were still be rejected due to being suspected spam - there is no quarantine setup.

Today I logged into the boxes to see if I could syslog the mail logs to a seperate linux server and suddenly got wrapped up in this problem. I had a look and could see the domains in the whitelist section within the HAT, after doing some reading I can confirm the whitelist section was ordered as being number 1 in the list and by looking further it looks like the whitelist domains were via the 'add to sender group' button within the monitoring overview screens (this is assumed as both .sistercompany.com and sistercompany.com were appended to the whitelist).

After a few hours of reading up I couldn't understand why the whitelist wasn't working, I even did a lookup of the domain in the monitoring overview search section for mail recieved by sistercompany.com and could see that it belonged in the whitelist group. I got further confused when reading the help and support guide - it had screenshots that looked very similar to our setup [within the HAT overview and Mail Policies], however it had an sbrs for the whitelist set between 6 and 10, where as that was blank on our system, nowhere in the document would it describe why this sbrs value was set. Bearing in mind I have only had a few hours of experience with this product, so these maybe silly questions but:

1. Why would you add an sbrs value to the whitelist - I would have thought whitelists would ignore any score presented.
   
2. If number 1 has nothing to do with why these domains were still being flagged as spam, has anyone got any suggestions as to what the issue maybe?
   

For a small bit of information we have the C660 appliances installed.

Any help would be much appreciated

[Donald Nash]

I'm taking a wild guess here since there are a lot of missing details. Forgive me if I'm covering ground you've already trod.

Remember that the HAT controls how incoming SMTP connections are handled, so entries in the HAT must correspond to the remote SMTP servers that are connecting to you. You don't put the "domain" part of "user@domain" in the HAT ("sistercompany.com" in your case), you put in the the domain names of the actual remote SMTP servers or a wildcard that matches them all. In your case, this might be ".sistercompay.com" (note the leading "." indicating that this will match any domain name ending with ".sistercompany.com"), but only if their SMTP servers have host names in that domain.

Whitlisting by domain name requires that the IP addresses of those remote SMTP servers have correct rDNS. If they don't, you'll have to list them in the HAT by IP address. FYI, we never put anything in the HAT by IP address unless it is unavoidable. Using domain names and requiring correct rDNS forces good DNS hygiene, and also provides a layer of abstraction. The server's address can change, but so long as the DNS is kept up to date we don't have to change our HAT entries.

You can see from the mail logs what sender group is being applied on each SMTP connection. Find one of the rejected messages in the log and see what sender group its connection landed in. If it didn't land in the whitelist (which will almost certainly be the case, given that the message was not in fact whitelisted), then you know the HAT entry is wrong. You can also use the log to determine the actual domain name of the remote server, assuming the rDNS for its IP address is correct.

The example screenshot in the manual showing SBRS between 6 and 10 being whitelisted is demonstrating that you can whitelist by SBRS as well as by explicit listing in the sender group. Your whitelist simply isn't doing this, which is fine. In this age of rampant spamming from stolen accounts on reputable servers, whitelisting by SBRS can let spam in. We raised the lower limit from 6 to 8 several years ago after getting hit in this exact way.

++Don

[Andrewkai]

Hi Don,

Can we whitelist base on individual email id? Not the whole domain.

Cheer!

Andrew

[Donald Nash]

Andrew,

Whitelisting a particular email address happens at a totally different layer of the system, since email addresses aren't sent until after the SMTP connection is up. You'll want to set up an Incoming Mail Policy for that.

++Don