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

If you have an on-premises mail environment that you are protecting with Exchange Online Protection (EOP) then you’ll need to create some connectors in the cloud. This article is going to focus on EOP Outbound Connectors and how they deliver mail when configured with a smart host.

Keep in mind that with EOP connectors, the naming convention is EOP centric (from EOPs point of view). When we talk about incoming mail, we are referring to mail that has originated on the Internet and is destined to our on-premises mail servers. This Internet originating message will be directed to EOP first because this is where your MX record is pointing. Once EOP processes the message, it needs an Outbound Connector to deliver the message to your on-premises mail environment. Here’s what we’re looking at.

 
Because your MX record will be pointed towards EOP, the EOP Outbound Connector (type is on-premises) will need a smart host to be able to deliver mail to your on-premises mail environment. For the smart host, you can enter either an IP or a Fully Qualified Domain Name (FQDN).

 
Customers that use an FQDN as the smart host typically ask me the following question.

How does the lookup for the FQDN smart host work? Does the EOP Outbound Connector look up the MX record or the A record for the smart host FQDN?

The Outbound Connector respects RFC 5321 section 5 which clearly states the following must happen once the recipient domain is known.

1. Look up the MX record of the recipient domain.
2. If no MX is present, lookup the A record and if present, treat this as the MX record.
3. If an MX record is present, clients MUST NOT use the A record.

Note: In our scenario we are using a smart host and not the recipient domain to determine routing, however this same MX/A logic still applies.

Because the EOP Outbound connector first does an MX lookup on the smart host FQDN, MX priorities are also respected just like you would expect. This in a nutshell is exactly what an EOP Outbound Connector does when it finds an FQDN entered for the smart host.

References

Configure custom mail flow by using connectors
Create required connectors to set up basic email flow through EOP

Update (September 3, 2014)

I was recently involved in a case where a customer needed more information about the certificate that EOP presents. Being the nice guy that I am, I wanted to share it here!

As mentioned in this article, the CN of the certificate that EOP presents is mail.protection.outlook.com. The certificate also contains the following Subject Alternative Names (SAN).

• *.mail.eo.outlook.com
• *.mail.protection.outlook.com
• mail.protection.outlook.com
• outlook.com
• mail.messaging.microsoft.com

Of course, these can also be seen in a network trace.

Finally, this is the certificate path.

The Baltimore CyberTrust Root certificate can be downloaded from https://cacert.omniroot.com/bc2025.crt.

Note As a best practice, we recommend that you don't hard-code trusted root lists for certificate validation. Instead, you should use policy-based root certificate validation that can be updated as industry standards or certificate authorities change.

Original Article

Hello readers!

In this post I will be covering TLS and certificates and how they apply to EOP. Usually when organizations force TLS on mail to and from a partner they will not restrict the connection based on the certificate that the recipient server presents. Instead, they will ensure either the connecting IP or domain is correct, but after that the presented certificate isn’t restricted, or if it is the check is only to ensure it has been issued by a trusted CA and has not expired. Now, what if you have a security policy that requires checking the certificate that the partner server presents? With EOP in the middle, this certificate changes and if your partners are expecting to see your certificate when they send or receive mail from you they will need to update their configurations. Let’s take a look at this with an example.

In this example, Contoso wants to send an email message to Fabrikam. Contoso will verify that the certificate name presented by Fabrikam is mail.fabrikam.com. If the certificate is not correct, Contoso will drop the connection and will not send the message. Here's a visual.

When this connection is established, Contoso sends its certificate, mail.contoso.com to Fabrikam, and Fabrikam sends its certificate, mail.fabrikam.com, to Contoso. Contoso validates that the certificate presented by Fabrikam is mail.fabrikam.com and if instead a different certificate is presented, Contoso will drop the connection.

Now, let’s see what happens when Fabrikam implements Exchange Online Protection.

Now, the MX record for Fabrikam is pointing to EOP, so when Contoso wants to send an email to Fabrikam, Contoso will be communicating with the EOP servers. When the connection is established Contoso will present its own certificate, mail.contoso.com, but since Contoso is communicating with EOP, EOP will present its certificate which is mail.protection.outlook.com. If Contoso has restricted TLS communications to Fabrikam to only take place if the presented certificate is mail.fabrikam.com, Contoso will drop the connection and not send mail because the presented certificate was not mail.fabrikam.com. Contoso will need to update their configuration to accept the certificate mail.protection.outlook.com when sending mail to Fabrikam.

To increase the geek factor of this post, if you’re a curious individual like me, you won’t want to take someones word (even Andrew’s) that the certificate presented by EOP is mail.protection.outlook.com. You instead want to see it with your own eyes…. or maybe that’s just me. In any case, this can easily be seen by capturing network traffic that flows between your on-prem servers and EOP. Here, I have captured a network trace using Wireshark of traffic between my on-premises Exchange server and EOP. Here I can see the certificate in the flesh that is presented by EOP.

Keep in mind that the EOP certificate name is only needed if you or your partner have TLS setup to require a specific certificate name to be presented. If instead you have TLS setup to look for a certificate issued by a trusted CA or even any certificate, then the EOP certificate name will not be of interest to you.

One thing I’ll note because I’ve received a lot of questions about it. You are currently not able to import your on-premises certificate to EOP and in turn have EOP present that certificate to partners instead of mail.protection.outlook.com.

I find that most of the clients I deal with do not actually look at the presented certificate when TLS is established, however, some clients do and this article is meant for them.

Cheers!

Andrew

I’m often asked how to prevent an End user Spam Notification (abbreviated as ESN from this point on) from being sent to a distribution list (abbreviated as DL from this point on). Before getting to the answer, let’s start off with some background information on ESNs to see why this question comes up in the first place.

What is an ESN?

If you are using the online quarantine in Exchange Online Protection (abbreviated as EOP from this point on), an ESN is one method you can use to give your end users the ability to release items from their quarantine on their own. At a minimum of once a day (can be configured to be longer), ESNs will be sent to users that have received mail in their online quarantine since the last time an ESN was sent. The ESN will contain links that can be used to release any of the messages from their quarantine to their inbox. Here’s an example of an ESN.

Problems can arise when an ESN is sent to a DL as this is typically not desired behavior. Let’s take a look at an example to see why this can be a problem.

Example scenario

We have a company that is using EOP Stand Alone (not Exchange Online) to protect their on-premises Exchange environment which hosts all of their mailboxes. This company is also not using Microsoft Azure Active Directory Sync (abbreviated as DirSync from this point on). A spam message destined to a DL in the company is received by EOP and quarantined in the cloud. In this scenario EOP does not know that the recipient email address is a DL, it just sees an email address.

When the ESN is generated, EOP sends it to the recipient address which happens to be a DL. The on-premises Exchange environment receives the ESN which is destined to a DL, expands the DL, and then delivers the ESN to everyone in the DL. Now let’s say one of users decides they would like to release a quarantined message, and so, they click the Release to Inbox link in the ESN. EOP will release the message from the quarantine and send it to the DL, delivering the message to all members of the DL. This action of a single user can cause a quarantined message to be released to many users.
This is certainly not wanted behavior, or at least it usually is not.

Who does this affect?

There are a few different ways this can occur. The most common is when a DL exists on-premises and is not being synced to Office 365. This could happen if DirSync is either not being used, or has been configured not to sync certain objects, which could include DLs, to Office 365. In the end, if Office 365 does not know about a DL, it will not expand it in the cloud and you will see this behavior.

Who does this not affect?

If the DL exists in Office 365, or is being synced with DirSync from on-premises to your Exchange Online Office 365 tenant, you will not have this issue because the DL will be expanded in the cloud so each member will get their own separate ESN.

How do I prevent this?

Lucky for you preventing this behavior is quite easy. ESNs are always sent from quarantine@messaging.microsoft.com, so all we need to do is to stop this address from sending to our distribution lists. The steps I list here are applicable to Exchange Server 2010 and Exchange Server 2013.

1. Create a Mail Contact on your on-premises Exchange Server. Select a name for the alias and enter quarantine@messaging.microsoft.com for the external email address.
2. Let’s assume that the alias for the contact created was "Quarantine" and we don’t want ESNs to be sent to our distribution list called “TestDL.” The PowerShell to accomplish this would look something like this.
   
   Set-DistributionGroup “TestDL” –RejectMessagesFrom “Quarantine”

You could easily write a loop in PowerShell which could set this attribute for all your distribution lists in one swoop, but I’ll leave that to you to script for your environment.

The EOP online quarantine is a wonderful feature that can be easily managed through the Office 365 Portal. However, if you are looking for more functionality and flexibility with quarantine management, you’ll need to turn to PowerShell.

Before I begin I have a quick disclaimer. The PowerShell scripts in this article are not official, nor are they supported by Microsoft. They are just scripts that I have written and use myself in my day to day work with EOP.

Current Limitations of the Office 365 Portal

For most of the day to day quarantine tasks the Office 365 Portal view will work just fine. This view will allow you to search for messages based on a wide range of criteria and release single messages to either a few or all the intended recipients.

There are a few places where the Office 365 Portal view falls short though.

1. There is currently no way to mass release messages from the quarantine. For example, let’s say there are hundreds of quarantined messages from a particular sender in the quarantine and you would like to release all of them. Through the Office 365 Portal you can only release one at a time which is very cumbersome.
   
   
2. The portal will only show a maximum of 500 entries and there is no “next page” button.” If you have a large quarantine in excess of 500 messages, you will need to use the filtering options to limit your search criteria.
   
   
3. There is currently no way to see if a message has been released unless you double click the message to bring up the properties. If “Release to…” is greyed out, then the message has already been released.

PowerShell cmdlets

The following three cmdlets are currently available for quarantine management.

QuarantineMessage
This will retrieve a list of messages in the quarantine which can be filtered with a wide range of search criteria (recipient address, sender address, subject, etc…).

Get-QuarantineMessageHeader
Returns the header of a message in the quarantine. This is the same as highlighting a quarantined message and clicking “View message header…” in the Office 365 Portal.

Release-QuarantineMessage
Messages piped to this cmdlet from Get-QuarantineMessage will be released. This cmdlet can be used to release a message to either some, or all of the intended recipients.

See Exchange Online Protection cmdlets for a complete list.

Technicalities

The Get-QuarantineMessage cmdlet returns a number of properties, but there are three that will always be empty unless you specify the Identity parameter when calling this cmdlet. These three properties are as follows.

• RecipientAddress
• QuarantinedUser
• ReleasedUser

Let’s look at an example. Here I am using Get-QuarantineMessage by specifying the message subject and not the message identify. Take note of the empty properties.

Now I have used Get-QuarantineMessage to target the same message as above, but instead I have referenced it using its identity. In this case the above three properties all contain data.

 
We can now see that this message was sent to two recipients and has been released to one of them but not the other.

One more item I’d like to note. Messages can only be released to email address that were on the original recipient list. This means that you cannot release a message to an admin for review unless the admin was one of the intended recipients. This is true for both the portal view as well as with PowerShell.

Examples

In the following examples I am not limiting the results returned by Get-Quarantine. In a production environment with a quarantine that contains many messages I would recommend filtering the returned results. For example, to restrict the results returned to a single day the following should be used in the examples in this section.

Get-QuarantineMessage –StartReceivedDate 07/20/2014 –EndReceivedDate 07/21/2014

Further filtering may be required with the PageSize property.

View quarantined items that have not yet been released

When a message is released from the quarantine, it will still remain in the quarantine until it expires. This makes it difficult to tell if a message has been released yet or not. Through the portal, you need to bring up the properties of a message to find this out which can be very cumbersome. This can easily be accomplished with PowerShell.

(Get-QuarantineMessage).identity | ForEach {Get-QuarantineMessage -Identity $_} | Where {$_.QuarantinedUser -ne $null}

Here I am looking at the QuarantinedUser property and unless its empty, the message will be returned by this query.

View items that have already been released

This is similar to the above script except here I’m focusing on messages that have already been relased.

(Get-QuarantineMessage).identity | ForEach {Get-QuarantineMessage -Identity $_} | Where {!$_.QuarantinedUser} 

Again I am looking at the QuarantinedUser property, but in this case if it’s empty the message will be returned.

Mass release messages from the quarantine

Let’s say that we’ve created a rule which quarantined all messages sent by joe@contoso.com and we want to mass release them.

Get-QuarantineMessage –SenderAddress joe@contoso.com | Release-QuarantineMessage -ReleaseToAll

Note that this will produce a warning for any message that has already been released but this will not stop the execution of the command.

Export a list of quarantined items to a csv file

Let’s say you want to export a list of quarantined messages to a CSV file for analysis. The following will accomplish this and note that I am specifying the identity parameter to ensure all the properties are returned.

(Get-QuarantineMessage).identity |foreach {Get-QuarantineMessage -Identity $_} |export-csv test.csv -notypeinformation

Resources

Connect to EOP PowerShell – If you have EOP only.
Connect to Exchange Online PowerShell – If you have Exchange Online.
EOP cmdlets