Incoming mail that matches a contact has display name resolved to the contact display name
Hello, I have serveral contacts configured in my exchange system. These are used to allow external recipients to be included in distribution groups. The outgoing mail process is fine however when one of these external recipients replies to a message their display name is resolved to the a matching contact's display name. I don't want this behavior. If the sender makes changes to their mail account's display those changes are not reflected on any received mail. When I provisined the contacts they were all configured as hidden from the GAL, and their display name was set to a GUID value. Their only intended purpose was, as stated above, to allow external recipients on Distribution groups. Can someone give me a method for stopping the resolution for inbound mail? I believe this is P2 address resolution correct? Thanks Bill
March 22nd, 2011 3:34pm

You didn't mention the Exchange version? If it's pre-2007 do you have ResolveP2 enabled? If it's 2007 or later do you have Externally Secured enabled as an option on your Receive Connector? (http://blogs.technet.com/b/exchange/archive/2006/12/28/3397620.aspx) Disable the appropriate option to prevent the behavior if you do.
Free Windows Admin Tool Kit Click here and download it now
March 22nd, 2011 5:13pm

Hi Bill, Do you mean the external user which is added as a contact in your own exchange system reply a email to your domain users, and the external user would be resolve to the displayname of the contact? If So, it seems expected; and if you have changed the displayname , we could delete the cache on the client end, and then it will be resolved as the new GUID value. If I misunderstand your issue, please tell me. Regards! Gavin TechNet Subscriber Support in forum If you have any feedback on our support, please contact tngfb@microsoft.com Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
March 23rd, 2011 5:06am

Hello, What I am trying to prevent is: A message received by exchange that matches a contact the message is not just relayed to the target address. The address is altered to match the target address (P2 Resolution). If I have a contact with more than one proxy address I would like the message to simply be sent to the target address without any modificatons to the origional To: address. Presumably the message got to the contact because the P1 address matached the contact proxy address but exchange is rewriting the message in such a way that it appears to have been to the target address. While this may be desireable in some instances in my application it is not. It would be very nice to be able to turn off P2 addressing on a recipient by recipient basis. I have a non-exchange list server that manages E-Lists. I have setup contacts representing each list so that the lists appear in the GAL. However when a user sends to one of these it is resolved to the routing address of the list rather than being left as the user had origionally sent it. xyz@domain.com is chnaged to xyz@list.domain.com where xyz@domain.com is a proxy address and xyz@list.domain.com is the target address. I don't really ever want to see the list.domain.com address. Its purpose is to route the mail external of exchange. Bill
Free Windows Admin Tool Kit Click here and download it now
May 24th, 2011 9:40pm

Hi Bill, Could you please describle more detailed about your exchange email system? In fact, I am confused about your description. 1. what is you domain name 2. what is your smtp address name 3. how do you configure the contact 4. what about your application Understanding the contact: http://technet.microsoft.com/en-us/library/aa998858.aspx Regards! Gavin TechNet Subscriber Support in forum If you have any feedback on our support, please contact tngfb@microsoft.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
May 25th, 2011 12:12am

Hello williamtholmes, I have exactly the same need, creating contacts for the only purpose of being member of distribution lists without having incoming resolve P2 on them. Did you get any solution for this ? On our side we only succeeded in the 2 bad solutions below : 1. Create a "durty" contact with targetaddress xyz@domain.com (real address) and proxyaddresses xyz@localhost.localdomain (fake address) 2. Create a "good" contact with targetaddress xyz@domain.com (real address) and proxyaddresses xyz@domain.;com (real address) With 1. Incoming mails are not resolved for this address, but outgoing mails publish on internet bad address, With 2. Incoming mails are resolved. Julien.
Free Windows Admin Tool Kit Click here and download it now
March 20th, 2012 6:42am

Hello, The method I used to work around this issue was to turn off email address policies for mailcontacts and mailusers. Instead I manage the addresses for these objects manually. I have two cases: Mailusers for whom we forward email. In this case the User wants to use the @mydomain.org address but and does not want their P2 address translated to their target address. The Default Address policy will add our @mydomain.org address to every mail object but it will set the target address primary. I want the @mydomin.org address to be primary so the P2 address is not translated into the target address. MailContacts that exist to allow easy lookups in the GAL and to allow them to be added to distribution groups. In this case I don't want to pollute the @mydomain.org address space with a bunch of contact addresses. Again the default policy will add an @mydomain.org to each contact. Again I disable the Default policy and only create the target address. In some cases you may want the External Address to have an internal email address such as a contractor or partner but in my case I rarely need this. Bill
March 26th, 2012 8:12pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics