In which order Ironport checks the incoming / outgoing mails

[Thiruchelvam Thurairaj]

Hi Guys,

I can't find any document regarding this one. In which order does Ironport checks / analyse / verifies the incoming mails?

Considoring Ironport does have these checks enabled on a mail policy;

1. Anti-Spam

2. Anti-Virus

3. HAT's and RAT's

4. Senderbase Reputaion score

5. Outbreak filters

6. Content filters

7. SPF

and 

8. Anti Maleware protection and file analysis.

Why I am asking this because someone asked me why the emails have been blocked via Anti-Spam instead of SPF. And is it possible to block incoming spoofed mails with "own domain name but different IP address" from outside by SPF instead of other policies? Or is it because the Ironport needs to follow the order?

Is there a better way other than creating a new policy - SPF content filters above default policy to achieve this? Because I am afraid If I create a new policy specially for SPF above default policy and when a email does have a verified SPF record but a virus then default policy won't do a second check and the email will be forwarded. Am I correct?

Thank you all in advance

[Ken Stieers]

Page 81 of the user guide is the beginning of Chapter 4, "Understanding the Email Pipeline"

You can find it here:

http://www.cisco.com/c/dam/en/us/td/docs/security/esa/esa9-7/ESA_9-7_User_Guide.pdf

Also, the Online Help, the 4th entry down in the index...

Now, keep in mind, it LIES....  The pipeline drawing will show that its supposed to DROP the connection if SPF fails... IT DOES NOT DO THIS!   

It sets some flags, and then you have to write a either a message filter or content filter to deal with the mail.... We put them in a policy quarantine.

[Ken Stieers]

To answer your later questions:

If you put YOUR spf records in where the ESA can find them (eg internal dns if you're using split dns), it will mark spoofed mail inbound to your domain.  

Add the content policy to quarantine or drop "SPF failed" messages to the default policy... that way you get all of the filtering, now matter what policy the mail hits...

[Libin Varghese · Accepted solution]

Hi

The email flow pipeline is explained in detail in the end user guide Chapter 4

http://www.cisco.com/c/dam/en/us/td/docs/security/esa/esa9-7/ESA_9-7_User_Guide.pdf

In brief the email flows through the appliance as below

.
Email -> SBRS -> HAT -> SPF/DKIM/DMARC -> RAT -> Message filters -> Anti-Spam -> Anti-Virus -> AMP -> Content Filters -> Outbreak Filters

Please note SPF check is performed early on in the pipeline, however an action would only be taken based on message/content filters created for the SPF verdict.

An email would be scanned by all engines unless a final action (such as bounce, drop) is encountered. Quarantine is not a final action and an email would only be sent to the quarantine at the end of workqueue processing after all scanning is completed. Hence an email with quarantine action from SPF filter could still end up in the spam quarantine based on the anti-spam verdict.

You would need to determine which scanning you would like to perform and which to be bypassed for such emails and make modifications accordingly.

Thanks
Libin Varghese

[dmccabej]

Hello,

Few things :

1) I've included a picture of the email pipeline below. Hopefully this helps to clarify what steps happen when on the device.

2) SPF verification works off of the 'Mail-From' header and not the 'From' header. If you're being Spoofed, I'm assuming this means you have malicious users sending content that is Spoofing your From headers and not the Mail-From headers. (IE: Shows internal accepted domain in Outlook but when you reply it shows malicious address) This means that you can still received Spoofed email even if you're performing SPF verification.

3) In addition to #2 ...If you're using ASyncOS 10.x or above, you can take advantage of the new Forged Email Detection features, which helps against the issue you're running into. You can read more about it here : Forged Email Detection

4) We do have the option to Accept/Reject at the connection level based on SPF verification, but this is a CLI only option. You would need to use the following commands : 

Listenerconfig --> Edit --> Select Listener --> Hostaccess --> Edit --> Edit Policy --> Select Policy --> Enter until it asks 'Would you like to change the policy paramteres' --> Type in 'Y' and hit Enter --> Enter until it asks 'Would you like to change the SPF/SIDF settings' --> Type in 'Y' and hit Enter --> Enter until it asks 'Would you like to change SMTP actions taken as a result of SPF verification' --> Type in 'Y' and hit Enter --> Select the action you wish to modify by choosing 'Y' and then choose whether to Accept or Reject those connections.