P2 Headers Now Respected for End User Safe and Blocked Senders Lists

Exchange Online Protection will now evaluate both the P1 and P2 headers in a message against an end users safe and blocked senders list. I know, I’m super excited too! Previously only the P1 header of a message was compared to these lists. Not only does this make blocking or safe listing within Outlook or OWA easier for an end user, the process is much more intuitive.

If this makes sense to you then you can probably skim or skip the rest of the article. But if you would like more information on what this means and why we have made this change then read on.

Note: This also applies to on-premises mailboxes in Exchange 2010 or newer where the Directory Synchronization tool is being used to sync the safe and blocked sender lists to EOP. For the syncing to work with Exchange 2007 some manual configuration is required which is beyond the scope of this article.

Background in Safe and Block senders

In the Outlook client (and in OWA), there are two important lists in the Junk E-mail options. Safe Senders and Blocked Senders.

 
Senders placed in the Safe Senders list will never be marked as spam by the Outlook client and senders placed in the Blocked Senders list will always be moved to your Junk Mail folder.

When using EOP, these lists will be respected in the cloud. For example. If one of your end users has added andrew@contoso.com to their Safe Senders list, any email from andrew@contoso.com which are destined to ONLY this user will skip spam filtering in EOP. These messages are easy to identify as you will see SFV:SFE and SCL:-1 in the X-Forefront-Antispam-Report header for that message.

On the other side of the fence, if an end user has added andrew@contoso.com to their Blocked Senders list, EOP will mark the message with SFV:BLK andrew SCL:6 in the X-Forefront-Antispam-Report header and will take the spam action defined in the content filter. If the spam action is quarantine message, then the message will be moved to the quarantine.

Note: The above only affects the single end user that added the sender to their safe or blocked senders list. An end user cannot safe or block a sender for the entire organization. That would be crazy!

Background on P1 and P2 headers

Before I continue, let’s quickly talk about P1 and P2 headers. I’m going to use an actual paper letter (I know, ghetto!) as an analogy for easier understanding. The P1 address is what’s seen on the outside of the envelope, where the P2 address is what we see on the paper inside. Often these are the same, but they don’t have to be.

On the technical side, the P1 header refers to the MAIL FROM and RCPT TO commands in the SMTP conversation. The P2 header refers to the FROM and TO commands in the SMTP conversation.

The FROM address in the P2 header is what you see in your email client when looking at the sender of a message. Typically the sender is the same between P1 and P2 headers, but in some cases can be different. If a marketing company is sending mail on-behalf of another company you may see a difference between these two headers.

Consider the following SMTP command sequence.

P1 header
mail from: p1@fabrikam.com
rcpt to: astobart@tailspintoys.com
data

P2 header
from: p2@contoso.com
to: andrew@tailspintoys.com
Subject: P1 and P2 headers are different
The P1 and P2 headers will be different in this message.

In my Outlook client, here is what the message looks like.

 
Notice how Outlook shows the sender as being the address that was specified in the P2 header. My P1 sender address is nowhere to be found… on the surface that is.

Digging into the headers we find that there is a Return-Path listed which shows the P1 address. Here is an excerpt from the header of the above message.

From: p2@contoso.com
To: andrew@tailspintoys.com
Return-Path: p1@fabrikam.com

Here we can clearly see that the P1 and P2 headers are different in this message. If the sender is the same in both the P1 and P2 header then you typically won’t see a Return-Path in the header.

With all this in mind let’s loop back and think of the end user that received the above message. I right click on this message in Outlook and choose “Never block sender.” This will add p2@contoso.com to my Safe Senders list. Before the change to EOP, if a subsequent message was sent with the same P1 and P2 headers as above, it would still be scanned by the EOP spam filter and my safe list not respected. This is because EOP would look at the P1 header which is p1@fabrikam.com and since this address isn’t in my Safe Senders list, the message would not be treated as safe.

In this scenario an end user would need to go through the headers of a message, find the Return-Path, and then add this address to their safe or blocked senders list. This is definitely not a great end user experience.

Now, because EOP compares both P1 and P2 headers, it would see that p2@contoso.com is on my safe senders list and so this message would be marked with SFV:SFE, SCL:-1, and would skip spam filtering. Hence, this is now much more intuitive for an end user. They no longer need to hunt through the header of a message if the P1 and P2 headers are different.

In the past why did EOP only check the P1 header?

I’m sure this will be the next question on your mind. The reason why EOP used to only evaluate the P1 header for safe and blocked sender lists comes down to security. The SPF check is only performed on the P1 header. By only checking the P1 header when evaluating Safe and Blocked Sender lists, we can reduce the chance of spoofing because this is the domain we will perform an SPF check on. The following is from the header of the above message.

Received-SPF: Neutral (protection.outlook.com: 167.220.24.155 is neither permitted nor denied by domain of fabrikam.com)

We can see that the SPF check was done against fabrikam.com which was the sender domain in the P1 header.

With this change, a spammer could present a P1 Mail From address that will pass the SPF check, and then spoof the P2 From address to be a domain or sender which an end user has added to their Safe Senders list and EOP will skip spam filtering. On the flip side, an end user that chooses to block a sender who sends with different P1 and P2 addresses now no longer needs to hunt through a header to find the Return-Path value to add to their Blocked Senders list.

While it’s true that with this change we are forgoing some security, the gain in end user usability far outweighs this loss.

Final thoughts

This change is still rolling out so if you don’t see EOP respecting P2 headers yet, just be patient. Final note, EOP started comparing both P1 and P2 headers to end users Blocked Senders list a few months ago, but only started comparing both P1 and P2 headers to end users Safe Senders list this month.

Resources

Manage safe sender lists for bulk mailers
Anti-spam message headers