ResolveP2, RerouteViaStore, and its equivalent in Exchange 2003

Recently I have encounted a number of people who asked what the ResolveP2 reg key in Exchange 5.5 was meant for, and how to emulate it in Exchange 2003.

--

ResolveP2 in Exchange 5.5

ResolveP2 tells the Exchange server “when the server is storing MIME content, and needs to convert it to MAPI properties, does it try to resolve the SMTP addresses in the RFC 822 fields and turn them into Exchange Distinguished Names (DN)?“ And, you can specify the exact fields that it will resolve because the regkey is a bitfield.

Here's the situation where you'd want to enable and disable this:

Enable: Imagine you have an Exchange user who sends mail to an Internet listserv, and the listserv has other Exchange users as members. When that user sends to the listserv, the mail comes in From: this internal user via SMTP. If you want your internal users to see this mail and be able to double-click on the sender and see the normal Exchange properties of this user, then you must be sure to set the ResolveP2 key to resolve From:. (which is “ADDRESS_CONVERT_SENDER“, so you add “1“ to the value).

Disable: Imagine that you have someone on the Internet sending mail in to your users, pretending to be the CEO of the company. They spoof their From: address to be the CEO's SMTP address. The mail comes in and when the user double clicks on the From: field in Outlook, they see the CEO's details just as though it really came from the CEO. In this case, you would want to set ResolveP2 so that the From: field was not resolved. When it's not resolved, then when they double click on the sender, they will see this three-line dialog that shows the display name, address type, and SMTP address. Outlook 2002 and 2003 do even better because they show this distinction on the From: field without needing to double-click: the name will show up like Bob CEO [bob@company.com], whereas real mail from Bob shows up as “Bob CEO“.

So as you can imagine, different situations will require different settings. In Exchange 4.0, the setting was to resolve all fields by default. For some reason (I do not know the reason exactly), they changed the default in Exchange 5.5 so that no fields were resolved. We found that there were a large number of PSS calls from people who needed to turn on resolution in 5.5. It has occurred to me writing this that the reason is that the KB articles around ResolveP2 are really confusing. I am engaging the right people to get that fixed.

Exchange 2000

In Exchange 2000 SP1, we come up with a similar solution. However it was missing something: ReRouteViaStore.

Adding RerouteViaStore

The above all works great for messages that come in via SMTP and are either locally delivered to a user or goes out via RPC or X.400 via the MTA, because in those cases, the message is saved to the Exchange store and the MIME -> MAPI translation takes place. But if the message comes in via SMTP and goes straight back out via SMTP,  then the MIME -> MAPI conversion that I described above would never occur. The solution in Exchange 5.5 was a regkey called RerouteViaStore

The combination of ResolveP2 + RerouteViaStore helps in the situation where you have two mail systems: company.com and unix.company.com. company.com is the Exchange 5.5 system and accepts all of the mail from the Internet. The users on unix.company.com funnel their mail out through the Exchange system.

Their From: might be From: user@unix.company.com, but you don't want to expose that address on the Internet. So you have a user or contact in the AD for each user on the unix.company.com system, with a secondary address of "smtp:user@unix.company.com" and a primary address of "SMTP:user@company.com". If the mail came in and went out via SMTP, address rewrite will cause the Exchange 5.5 machine to look up the address in the From: (and Reply-To) to find a proxy that matches, and rewrite the address with the primary address on that user or contact. This is also described in a KB article.

Exchange 2003

Exchange 2000 was lacking the RerouteViaStore capability. The only solution in Exchange 2000 was to write a custom transport event sink that modified the headers, which can be tough work to get right. In Exchange 2003, the transport team added RerouteViaStore capability. The way you turn it on is via a special utility that has recently been published to the web called Address Rewrite Config (click to download). Remember that this utility only works with Exchange 2003. What it does is to force messages that come in on an SMTP VS to be committed to the store, so that the MIME -> MAPI translation takes place, which is exactly what RerouteViaStore did. Like RewriteViaStore, this can cause a performance degradation, but depending on your message load, it may not be a big deal. You can imagine the difference between storing the message, untouched, as a MIME stream as a file in the queue directory on disk and then just reading that and sending it out, versus saving to the Exchange store, having it be converted to MAPI properties and then reading it back out of the store, which causes a conversion back from MAPI to MIME.