Thursday, July 25, 2013

ResolveP2 headers in Exchange 2010 and 2013

Exchange 5.5, 2000, and 2003 had a feature called ResolveP2 headers.  Essentially, it allowed Exchange to accept an inbound message, inspect the sender's SMTP address (or other type of address back in the olden days) and if the address was associated with an object in the Global Address List / Active Directory, then replace the sender's address with the name from the GAL.

For example, if the email was sent from snuffy@volcanosurf.com, but you had a mail-enabled contact or mail-enabled user in GAL with that SMTP address, it would resolve the name and the From would instead say "Snuffy Smith" or whatever the display name was.   You can read more about this feature from the olden days in this blog by David Lemson: 
ResolveP2, RerouteViaStore, and its equivalent in Exchange 2003

This feature was turned off by default to keep spammers from sending "reputable" looking mail by trying to make a message look like it came from a valid internal sender.

Recently, we were trying to figure out out to turn this back on due to an ongoing migration.  We needed the senders in DomainX to be resolved properly to GAL objects when they sent to DomainY.

The ResolveP2 feature does not exist in Exchange 2010 (and 2013).  Exchange will only resolve the sender's address to a GAL object if the message comes from an authenticated or trusted source.

You can duplicate this functionality in Exchagne 2010 / 2013 with a receive connector that is configured to allow relay and on the Authentication properties, include the "Externally Secured" property.

Bharat Suneja has an excellent article on how to do this.
How To Allow Relaying in Exchange 2010 and Exchange 2007 

Once you have set up the relay receive connector, add the sending system's IP addresses to the authorized source IP addresses.

Take care with this feature because you can inadvertently allow people to relay through your system which will inevitably add you to block lists, get you in trouble with your ISP, and bring about plague-o-locust across the land.  Anyone that sends through this particular receive connector will have these rights.


ms-Exch-SMTP-Accept-Authoritative-Domain
ms-Exch-Bypass-Anti-Spam
ms-Exch-Bypass-Message-Size-Limit
ms-Exch-SMTP-Accept-Exch50
ms-Exch-Accept-Headers-Routing
ms-Exch-SMTP-Submit
ms-Exch-SMTP-Accept-Any-Recipient
ms-Exch-SMTP-Accept-Authentication-Flag
ms-Exch-SMTP-Accept-Any-Sender


2 Comments:

At 2:32 AM, Blogger Mark said...

We actually got round this in a quite sneaky way in Exchange 2010. We have some external companies that send mail with an internal from address, but are not in our SPF records given we don't want them to send data to external recipients using our official from address, just our internal employees.
So we setup a transport rule for mails from that specific from address with the specific sender detail in the header, and then we re-write the X-MS-Exchange-Organization-AuthAs header to be "Internal". Exchange 2010 lapped it up, saw it as an internal mail, and then did the ResolveP2 so the users saw the Display Name from the associated contact in the GAL...
Unfortunately Exchange 2013 doesn't like our "workaround"... if I find a new one will let you know.
Mark.

 
At 2:33 AM, Blogger Mark said...

This comment has been removed by the author.

 

Post a Comment

<< Home