Is it possible to disable Recipient Resolution for a specific mailbox? If so, what are the required steps? Background: I have a mailbox with numerous SMTP addresses. When a message is sent to a non-'Reply' address, the message's To: field is changed to the 'Reply' address. For example, john.doe@company.com is the mailbox's Reply address. jane.doe@company.com has been added as a SMTP address for the mailbox. When a message is sent to jane.doe@company.com, its To: field is changed to john.doe@company.com.

This would be the Primary SMTP address for this mailbox. This is part of the message, and you cant remove this. You can change the reply to address to something else if you want, for e.g you can make the jane.doe@company.com the primary.Sukh

Are you referring to the Display Name for the recipient in the Received message? If you can describe what exactly you are seeing and what you trying to "fix", maybe we can come up with a solution. For what its worth, when I enter a secondary SMTP address within Outlook in Exchange/Outlook 2010, it does not change to the default SMTP address of the recipient. I dont recall the 2007 behavior.

Hi, I have tested in 2007 when you input a non-reply smtp address it will change to display other than any SMTP address. Please make sure the question is described properly. Waiting for your feedback. Best Regards!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.

I guess I will rephrase the question. How can I set up an Exchange 2007 mailbox with multiple SMTP addresses so that the To: field in the messages delivered to it will always match the SMTP address and /not/ be overwritten with the mailbox's reply address? For example, consider a mailbox that has the 5 following SMTP addresses: samaccountname@company.com (Reply) samaccountname@company.local help@company.com it@company.com infrastructure@company.com Expected/Desired Behavior: When someone sends a message to help@company.com, the message's To: field should be "help@company.com". Actual Behavior: When someone sends a message to help@company.com, the message's To: field is changed to "samaccountname@company.com". Expected/Desired Behavior: When someone sends a message to it@company.com, the message's To: field should be "it@company.com". Actual Behavior: When someone sends a message to it@company.com, the message's To: field is changed to "samaccountname@company.com". Expected/Desired Behavior: When someone sends a message to infrastructure@company.com, the message's To: field should be "infrastructure@company.com". Actual Behavior: When someone sends a message to infrastructure@company.com, the message's To: field is changed to "samaccountname@company.com". I hope this makes more sense now...

It should show the Display Name of the Mailbox on the TO: field when viewed in the recipients mailbox. Regardless, Exchange mapi/OWA clients will always default to the default reply address. You could create an Outlook rule that checks the internet header of the message and move message to other folders or flag them based on the actual SMTP address the message was sent to however.

Here are the full (obfuscated) headers of a test message as seen by a POP3 client: Received: from spamfilter.company.com (10.10.114.1) by exchange.company.local (10.10.114.10) with Microsoft SMTP Server id 8.3.137.0; Thu, 23 Jun 2011 15:50:35 -0400 Received: from mail-iw0-f171.google.com (mail-iw0-f171.google.com [209.85.214.171]) by spamfilter.company.com with ESMTP id edw1zOuIpfYpA4TG for <help@company.com>; Thu, 23 Jun 2011 15:50:35 -0400 (EDT) Received: by iwn34 with SMTP id 34so2873150iwn.16 for <help@company.com>; Thu, 23 Jun 2011 12:50:35 -0700 (PDT) Received: by 10.10.113.132 with SMTP id a4mr1418167ibq.72.1308858524486; Thu, 23 Jun 2011 12:48:44 -0700 (PDT) Received: from workstation.company.local (ipnnn-nnn-nnn-nnn.znnn-nn-nn.customer.xxxx.net [nn.nn.nnn.nnn]) by mx.google.com with ESMTPS id gb8sm1053310ibb.26.2011.06.23.12.48.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Jun 2011 12:48:43 -0700 (PDT) From: Fred Flintstone <fred.flintstone@bedrock.net> To: samaccountname <samaccountname@company.com>

I can't see of a way you can do think natively, each time a message is replied to it will use the Primary address (samaccountname@company.com)Sukh

So what are you trying to accomplish by knowing which SMTP address that messages was actually address to?

We have an application server that polls mailboxes and creates help desk tickets from inbound e-mail. Instead of creating a separate mailbox for each e-mail address (we're talking about more than a hundred), we are trying to use a single-mailbox-with-multiple-SMTP-addresses design. Ideally, the application's e-mail engine would map the inbound message's To: address to a specific customer and fire off workflow accordingly. This would ultimately put less load on the e-mail engine, as well as our Exchange server, since the mailbox polling needs to occur ever 60-120 seconds to meet SLA requirements.

We have an application server that polls mailboxes and creates help desk tickets from inbound e-mail. Instead of creating a separate mailbox for each e-mail address (we're talking about more than a hundred), we are trying to use a single-mailbox-with-multiple-SMTP-addresses design. Ideally, the application's e-mail engine would map the inbound message's To: address to a specific customer and fire off workflow accordingly. This would ultimately put less load on the e-mail engine, as well as our Exchange server, since the mailbox polling needs to occur ever 60-120 seconds to meet SLA requirements. Ok, then that application is going to have to be able to parse the internet header of the message, grabt the TO; from there and then fire off the appropriate workflow.

There is no way to disable the resolver, the categorizer will resolve to the primary SMTP. Over 100 email addresses to classify each ticket type seems alot to me, I would design it a much fewer 5-10 with basic, trouble ticket, access request, etc for email submissions. If you bundle all those emails into one mailbox how is the user expected to know the specific email address since only one object will be displayed in the GAL, yes they can look at the email addresses tab but still. For end users I would keep it smaller categories for email submissions to go into a generic queues and then have help desk place them into specific queues if need be from the app itself. Another option you can do is for the 100 email addresses create mail enabled contacts so they at least show in the GAL so users don't have to remember the email or queue name. (Use ldifde to bulk create the contacts) Ticket queue 1 - app1 Ticket queue 2 - app3 etc. Then create a transport rule to redirect any emails going to these contacts to one mailbox. Since they were forwarded, the to: header will be preserved with original contact email address so the app will be able to parse it. James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

There is no way to disable the resolver, the categorizer will resolve to the primary SMTP. Over 100 email addresses to classify each ticket type seems alot to me, I would design it a much fewer 5-10 with basic, trouble ticket, access request, etc for email submissions. If you bundle all those emails into one mailbox how is the user expected to know the specific email address since only one object will be displayed in the GAL, yes they can look at the email addresses tab but still. For end users I would keep it smaller categories for email submissions to go into a generic queues and then have help desk place them into specific queues if need be from the app itself. Another option you can do is for the 100 email addresses create mail enabled contacts so they at least show in the GAL so users don't have to remember the email or queue name. (Use ldifde to bulk create the contacts) Ticket queue 1 - app1 Ticket queue 2 - app3 etc. Then create a transport rule to redirect any emails going to these contacts to one mailbox. Since they were forwarded, the to: header will be preserved with original contact email address so the app will be able to parse it. James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com I suspect that other processes outside of Exchange are actually sending messages to these SMTP addresses rather than users looking in the GAL for the most part.