次の方法で共有

Is X-Microsoft-Antispam a New EOP Header

  • [アーティクル]

Yes, yes it is, and I’m glad you noticed! X-Microsoft-Antispam is quite new and only started showing up in messages passing through EOP a few months ago. This new header currently contains two published values to help with bulk mail and phishing detection.

  • BCL – Bulk Complaint Level
  • PCL – Phishing Confidence Level

The beauty of this header is that it is stamped on incoming messages BEFORE EOP transport rules are evaluated. This means you can write EOP transport rules to trigger based on what’s in this header.

One of the goals behind the new X-Microsoft-Antispam header is to allow customers to decide how sensitive they want EOP to be when it comes to bulk mail detection. Today in the EOP Content Filter there is a bulk mail detection switch that can currently only be set to either on or off.


 
The problem with this switch only being on or off is that bulk mail is a very grey area. What one user considers as bulk another will not. This is why we are moving beyond the on off switch to a multi-value classification system where customers will be able to set the level that they are comfortable with.

With this new header, you can decide on a scale how sensitive you want the service to be with bulk mail detection. Eventually this will be rolled in to the Advanced Spam Filter options and replace the current bulk on off switch, but for now you can write EOP Transport Rules to take advantage of this and enforce the bulk mail detection level of your choosing.

At MEC this year there was a great presentation titled So how does Microsoft handle my spam? In this presentation, bulk mail detection is discussed between 22:30 to 28:50 and the speakers provide great insight into this topic. The entire session is great, but I would recommend at least listening to the six minutes where they discuss bulk mail.

What can I do today?

If you are experiencing unwanted bulk mail today there are some things you can start with.

  1. Take advantage of the new x-Microsoft-Antispam header by writing EOP transport rules that examine it. See Use transport rules to aggressively filter bulk email messages. This page describes three separate rules, the first of which uses the X-Microsoft-Antispam header and the other two look for text patterns and phrases. I would recommend creating only with the first rule that looks at X-Microsoft-Antispam, and if you need even more aggressive bulk mail filtering, then create the subsequent two rules.

  2. Educate yourself on the new X-Microsoft-Antispam header. See Anti-spam message headers and Bulk Complaint Level values.

  3. Educate your users on bulk mail. If a user recognizes the sender of the bulk message and does not want to receive further mail, they can click the unsubscribe link on the email. If the user does not recognize the sender, they can block the sender or domain in Outlook or OWA by adding the sender to their Blocked Senders list.

  4. Submit bulk mail and spam back to Microsoft for analysis. This allows us to continually refine our message filters. See Submitting spam and non-spam messages to Microsoft for analysis.

Resources

The following documentation was updated in July 2014 to include information about the new X-Microsoft-Antispam header.

What’s the difference between junk email and bulk email?
Anti-spam message headers
Bulk Complaint Level values
Use transport rules to aggressively filter bulk email messages

Comments

  • Anonymous
    January 01, 2003
    Hi Verne, great questions. For the location of the documentation, I don't believe we currently document that Transport Rules cannot target the X-Forefront-Antispam-Report header. I'll verify and if we don't I'll let our content team know.

    To review, when messages arrive at EOP we process them in this order: Edge Blocks --> Malware scanning --> Transport Rules --> Spam Protection (Content filter) --> Deliver to mailbox.

    When we get to the Transport Rules step, some items in the X-Forefront-Antispam-Report header have been stamped, but others haven't. Specifically, we haven't stamped the SCL or the Spam Filter Verdict (SFV) yet so a TR would not be able to trigger based on them. However, we have stamped some items like CTRY and CIP which can be identified by a transport rule since they are stamped before the rules are evaluated. 
     
    For the SPF checks, these take place in the Spam Protection stage, which happens after Transport Rules run. This means you can't write a transport rules to look at the EOP SPF check results (although an SPF check may be stamped in the header by a service before the message reached EOP). You could however enable the content filter option "SPF record: hard fail" which will cause our Spam Protection to mark a message as spam if the SPF check shows as failing.

    On a similar note. If you have a transport rule which safe lists a message, the Spam Protection step is totally skipped. In this case, you won't see an SPF check in the header (unless one was stamped before the message arrived at EOP). If a message is not safe listed and goes through the Spam Protection stage, you will see the SPF check result in the header.

  • Anonymous
    January 01, 2003
    Hi Joe, it actually shouldn't be working like that. You are correct that transport rules are evaluated first, and then the content filter is evaluated. The only time the content filter will be skipped is if a transport rule has an action of "bypass spam filtering." Even when a transport rule sets the SCL the content filter will still run. End user "safe senders" lists are evaluated in the content filter. So, if you have a rule that sets the SCL of a message to 5, when the message then hits the content filter, the SCL could change to -1 if the recipient has the sender in their safe senders list. You can tell if this happened because the message will be stamped with SFV:SFE. If you aren't seeing this happen then I would recommend opening a ticket with us. If the end users mailbox is located on-prem there could be a problem with DirSync not syncing the safe senders AD attribute.

  • Anonymous
    January 01, 2003
    Hi Byron, to prevent spoofing I would highly recommend setting up both an SPF and DMARC record. You could then create a transport rule that would be something like this.

    If sending domain is adp.com
    and
    X-Authentication-Results header contains DMARC=pass
    Do the following
    Bypass Spam Filtering.

    For more information on using DMARC to prevent spoofing, see my previous post http://blogs.technet.com/b/eopfieldnotes/archive/2015/02/26/using-dmarc-to-prevent-spoofing.aspx and take a look at the links I have at the end of that story.

    For a good example of creating a transport rule to safe list but also verify that DMARC passes, seehttp://blogs.msdn.com/b/tzink/archive/2014/12/03/using-dmarc-in-office-365.aspx.

  • Anonymous
    July 31, 2014
    where is it documented that ... Keep in mind that the X-Forefront-Antispam-Report header still gets stamped on incoming message AFTER EOP transport rules are evaluated and so cannot be targeted by the rules. ...

    AND ... does that before/after description apply to the two headers

    Received-SPF:
    Authentication-Results:

  • Anonymous
    October 07, 2014
    The comment has been removed

  • Anonymous
    December 24, 2014
    I only began this blog in June of this year and so it’s hard to believe that it is already six

  • Anonymous
    May 01, 2015
    Andrew, If i have a domain, like, adp.com, in our bypass spam list in a transport rule, how do I use SPF check to prevent someone from spoofing adp.com? Is there anyway to safelist a domain, and use SPF to confirm no one spoofs it? Did I understand it correctly?