Ironport ESA - Allowing emails with bad reputation score.

[MANSOORQ123]

Dear Team

As ironport PoC, ironport ESA is deployed after a leading email security gateway ( say Gateway x) . Ironport therefore does not receive messages directly from internet but from this gateway X.

Surprisingly ESA is receiving a lot of messages with bad reputation and dropping them straightaway, as per PoC requirement, none of the message should be dropped/blocked and have be logged & allowed, as we are doing for anti spam, anti virus, antimalware messages, we are logging them and allow to the end users..

is there a way in ESA to allow emails with bad reputation score to end users and at the same time quarantine / log them.

Any inputs will be highly appreciated.

Thanks

Ahad

[Raed Boshmaf]

Hi Ahad,

Most likely these e-mails are being associated with BLACKLIST which is associated by default settings with the BLOCKED mail flow policy.

So what you can do is create a new sender group with the SBRS range that you want not to block, set it above the BLACKLIST in order and assign it with a mail flow policy other than BLOCKED "since BLOCKED will have action drop with it, you can select something like the ACCEPT one". This way these e-mails with bad SBRS scores will match with the new sender group "since it is listed before the BLACKLIST" that has ACCEPT mail flow policy that is associated with it, which will deliver the e-mails to the work queue.

Regards

Raed 

[MANSOORQ123]

Hi Raed

Thanks for your reply.

Query 1: I  think following rules can be modified.

      HAT Overview > "Blacklist" & "Suspectlist"

Blacklist is using "Drop" Policy and SuspectList is using "Throttled" , we can change them to Accepted, because our main goal is that Ironport passes everything but logs every message.

if we do so, all emails even coming from domains with bad reputation scores will be allowed. 

Query 2: how i can track these messages (having bad reputation score/ Blacklist) either through GUI or CLI.

Thanks

Mansoor

[Raed Boshmaf · Accepted solution]

Hi Mansoor,

Query 1: Possible, in the end this is your deployment and you can go with doing things in different ways, but the point is that the Block is happening due to the e-mail being assosiated with BLAKLIST sender group which has the BLOCKED mail flow policy which will drop the e-mail at listener level.

Query2:

From CLI <mail_logs>

some of the things that comes to my mind is something like grep "sender group" mail_logs > where sender group is the name of the sender group that you know that these bad scores will be assigned to. 

Another one would be to do something like grep "SBRS" mail_logs, this will show you the e-mails based on SBRS score and from there you can filter the e-mails that have bad scores

From GUI 

webUI(GUI) > Monitor > Sender groups 

Also you can create a filter that with conditions based on reputation that will do an action of logging, and you can track how many times the filter took place from webUI(GUI) > Monitor > Message filter "this will give you an estimate of the number of e-mail with bad score that you receive"

example of the filter

Log_Bad_SBRS:
if(reputation < 0.0)
{
log-entry("This e-mail has a bad SBRS score!");
}
.

Regards

Raed

[exMSW4319]

In that scenario are you sure your Incoming Relays setting is correct?

Once you've followed Raed's suggestion (or changed the BLOCKED mail policy not to block, if it's not being used elsewhere in the HAT) that will give you some actual samples with headers to check.

If the Relay setting is wrong, the IronPort device might be taking decisions based on the IP addresses of the senders' internal infrastructures, with messy and highly inconsistent results.

The only way I know of getting information from the way the HAT processes a message is to use a message filter, which is going further than you may be comfortable with if you are only just at the stage of evaluating IronPort for the first time as it involves the use of the CLI. This is a minor variation of one of my own filters:

tag-blocklist:
if (sendergroup == 'BLOCKLIST') {
    insert-header('X-PoC-Block', '$remoteIP SBRS $reputation flow $policy');
}
.

You can then have a content rule to act on the presence of the X-PoC-Block header, or even add a duplicate-quarantine('quarantine'); to the above filter.