Spoof Filter False Positives

[cbalicusto46]

The spoof filter as recommended by Cisco (see at the bottom) is working well for us. There are several enhancements I did such as adding a allowed to spoof sendergroup in the condition of the message filter, using dictionary list, content filter whitelisting, additional Exchange hub transport rule processing, etc.

I'm just wondering how everyone is handling false positives for the following:

1) Mailing list that does a send on behalf such as Mailchimp.

2) Email based groups such as Google groups.

3) If you have an Outlook ok forward rules from an external mailbox. It triggers the spoof filter when someone from your internal domain sends an email to it.

4) External user forwarding Outlook calendar invites that shows as on behalf of.

These trigger the header("From") condition.

I appreciate your input in how you're handling this.

Thanks,

Conrado

*************************************************************   

http://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/117796-problemsolution-esa-00.html

if ( (recv-listener == "InboundMail")       AND
         (subject != "\\{Possibly Forged\\}$") )
    {
        if (mail-from == "@yourdomain\\.com$") OR
           (header("From") == "(?i)@yourdomain\\.com")
        {
            strip-header("Subject");
            insert-header("Subject", "$Subject {Possibly Forged}");
        }
    }

[Libin Varghese]

Hi,

With the anti-spoofing filter it is always required to determine what email content or header can be used to add an exception to the existing filter.

The easiest method it to add trusted senders an exception based on the sender IP, complete or partial hostname to the existing allowed spoof sender group.

If IP's and hostnames keep changing we could use header information such as Message-ID, Return-Path, or any other unique characteristics in the emails received from them.

For example for office 365 senders: Message-ID: <SN1PR11MB0816C0D95DFBD5D421880E6FE98C0@SN1PR11MB0816.namprd11.prod.outlook.com>

if (header(Message-ID) == ".prod.outlook.com") {skip-filters();}

With the auto-forwards we would probably need to manually review the headers similarly for any common content which can be used for exceptions.

Thanks

Libin Varghese

[cbalicusto46]

Thanks Libin for the feedback. For the most part, that's actually what I'm doing.

By the way, instead placing the additional condition (exceptions) at the message filter, I moved that the content filter for ease of maintaining list of exceptions. Our spoof filter is a combination of message and content filters.

One thing that I noticed is the inability of the content filter to process 5322 headers such as Return-Path and other headers that I want my exception to latch to. It always work with 5311 headers. Is there any limitation with the content filter for email headers?

Thanks,

Conrado

[Libin Varghese]

Hi Conrado,

The content filter condition for "Other Header" has worked for me in the past to check the headers in the emails such as Message-ID, Reply-To, etc. 

If you are using a regular expression to match the entry we would probably need to review that.

You would also need to probably review if you are using other header equals or contains to account for any ">" character at the end of the header value.

Thanks

Libin

[cbalicusto46]

Hi Libin,

Yes, I'm using 'Contains' for the regular expression. I found other ways to workaround it, so not really an issue for now. Just wanted to find out if it was limitation or not.

With this spoof message filter, is there a better way of handling valid providers that are allowed to send on your behalf when they are already in the SPF DNS record. I'm maintaining a sender group for this trusted senders. Is there are better way of handling this? Would you be able to completely replace it with SPF Verification condition or would it present some gaps?

Thanks,

Conrado

[Libin Varghese · Accepted solution]

Conrado,

SPF verification would certainly be the best way to track and allow legitimate sending servers, however, we have seen third party servers or vendors in use by various organizations which prevents it from replacing the sender groups completely.

I'm attaching a comprehensive article on forged email detection for your review.

- Libin

[cbalicusto46]

Hi Libin,

We have been using our spoof message filter for several months now and it works. The base logic of the filter: 1) it validates our internal domains in Envelop From and From header, and 2) use Sender Group to exclude legitimate vendors allowed to send on behalf of our internal domains.

I would like to improve this by incorporating the SPF mailfrom and PRA results as we maintain close to 150 email domains. PRA evaluation is not working. In page 12 of the "Forged Email Detection" document that you had attached in this thread, it specified the following requirements.

"Publish SPF records for your domain alpha.com, and enable SPF/SIDF Verification in your default mail flow policy. Set Conformance Level to SIDF Compatible and write either a message filter or content filter that detects SPF failures stamped into the header."

This is the result that I see under Received-SPF header for PRA: "None (server.domainxxx.com: no sender authenticity information available from domain of xxxxxxxx) identity=pra"

I only have SPF for version 1 published and would like avoid publishing SPF 2.0.

Let me know what you think.

Thank you in advance.

Conrado Balicusto

[dmccabej]

Hello,

If there are no spf2.0 records published for that domain then you will not see any PRA result, which is what that result is based off of. If you wish to bypass the PRA verification you can simply change the conformance level to SPF instead of SIDF Compatible. Most companies will not be using a spf2.0 record.

Thanks!

-Dennis M.