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 [firstname.lastname@example.org], 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.
In Exchange 2000 SP1, we come up with a similar solution. However it was missing something: 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: email@example.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:firstname.lastname@example.org" and a primary address of "SMTP:email@example.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 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.
Hmm. So the address rewrite tool is simply twice involving imail, ie. the store MIME->MAPI conversion component ? Or is the native MIME Content from the incoming message preserved in the outgoing mail after Address rewriting ? (which can be rewriting company.com with company.com)
Yes, that is correct. I double-checked with transport guys (Hi Max!) When you enable the address rewrite feature of Exchange 2003 with that configuration tool, it causes the message to be sent on a quick roundtrip through the store. I believe that the design of the store is such that the MIME that you get out should be exactly the same as the MIME that you put in, except for the header changes that you're looking for by setting ResolveP2.
Can you explain the behavior of not resolving the 'TO' field ? The documentation on support website only tells about 'From" field, but I do not want that resolving happens on 'from' ADN 'TO' field. Thx.
Since you're on the topic of ResolveP2, what does the Resolve Anonymous Sender perform on Exchange 2003. Will that rewrite the address also
Resolve anonymous submissions says whether or not to turn SMTP addresses into native Exchange addresses by looking them up in the directory. Exchange always resolves such messages for messages that come in authenticated, such as from other Exchange servers,
but that setting lets you say that messages that come in anonymously (such as on from the Internet) should not be resolved. More details and why you'd want to do it can be found in:
PingBack from http://www.keyongtech.com/4997791-how-to-display-email-address