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.
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.
If you are experiencing unwanted bulk mail today there are some things you can start with.
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 headersBulk Complaint Level valuesUse transport rules to aggressively filter bulk email messages
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
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.
Is seems that setting SCL to 5 via a transport rule short-circuits the user-based Safe-Senders list (since rules are evaulated before the Content Filtering). Thus, there's no way for an end-user to whitelist his bulk-senders if we use this method. Am I missing
something, or do we have to live with this limitation until you add granularity to the built-in bulk filtering options? Is there any hook we can use as an exception in the transport rule that will lookup the recipients' safe-senders list? I'm assuming not
but wanted to check.
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.