Send as options and proxy addresses in Exchange – yet another blog

Introduction

Although there are multiple threads about this subject and I even posted a description of this phenomenon on technet there is still no action from MS developers and I don’t believe it is ever going to be resolved. So I’d just list some of the online proposals here. Screenshots and how-tos are on the original sites, here they are not re-displayed.

The case and the bug

The problem is in general with secondary SMTP addresses that are stored as proxyAddresses AD attribute and are also known as aliases. Normally a mailbox enabled user will have a primary SMTP address (in EMC controlled through the "set as reply" button) and (occasionally) some additional addresses. Such is the case here: strong>full_name@domain.org and support@domain.org, assigned to the same person. Even in this simple case, if this user tries to send email from support@domain.org, Outlook silently overrides the "send as" address to the user’s primary one. Second complication comes with an additional (authoritative) domain, let’s say domain.net. If you add an address like full_name@domain.net to the same user and he tries to use this (let’s presume for legal reasons), the email is blocked and a NDR is returned to the user’s mailbox. The case can get even more complex when for example the same user has to supervise two different support addresses: support@domain.org and support@domain.net that are assigned to the same distribution or email enabled security group – even with properly set send as permissions the user will be able to send only from the group’s primary SMTP address.

Mr. Suneja proposes in http://exchangepedia.com/2007/04/how-to-send-as-alternate-email-address.html four solutions: additional mailbox, autonomous SMTP client, address rewriting and third-party tool IvaSoft. Take a look for yourself there and if you are satisfied with one of them, then the lecture is over. In such case pay credit to who the credit is due. For the rest of the audience that is still reading, let me explain my concerns to each of these solutions.

1. Additional Mailbox will be fine if all you need is archiving and compliance. Still keep in mind that this is not a solution for the proxy addresses – you simply will have to create for the above mentioned case one mailbox per address and end up with three mailboxes, that the poor user has the pleasure map to his PIM…
2. SMTP client is a poor man solution – you will have to think about how to integrate it in the user’s desktop experience (like sending rich text formatted data, etc.) and further to assign a static IP address to the workstation in question and to create an SMTP incoming connection rule that allows autonomous access from this address. You ask why? Well, at the moment that you assign any sort of authentication to this connection you will face up the same problem with the denied aliases
3. Address rewriting is in my opinion absolutely unrelated to our case. It is a nice solution for legal matters such as acquisitions, global name spacing, etc. but is applied to all outgoing (and by choice incoming) emails and cannot be filtered with rule conditions
4. About IvaSoft, the only thing that I can say is that I discount it for esthetical reasons. I simply cannot believe that such ugly looking GUI will offer neatly and correctly developed code. Sorry about that guys – here my reasoning cannot be objective

Then at the end we have one more workaround that utilizes security groups or distribution groups.

Four years ago Mr. Leibaschoff wrote on this technet blog a manual "How to Send E-mails with Exchange Using a Different "From" Address" by means of security groups. The same steps work with distribution groups, which I tested on an Exchange 2007 server recently and I find it the best possible workaround so far.

Why do I prefer it?

Let’s recall the case briefly – we are looking for an effective method that allows a single user to use his single mailbox to send and receive emails as different authorities (full_name@domain.org, support@domain.net, etc.) This can be achieved when we assign this user as a member to sufficient distribution groups that on their turn "hold" the user’s aliases as their primary SMTP addresses. To the outer world these aliases will represent him in his different corporate functions and in the inner world (the corporate IT space) only one mailbox has to be maintained and archived appropriately.

Last words: known caveats

During my tests with the distribution groups I noticed two caveats that are worth mentioning here. The first problem lies within the group itself – you cannot assign the distribution group itself "send as" permission just as you could do with security groups in the case that you have more than one persons responsible for the same enterprise position.

The second problem is most frustrating and in my eyes is a plain bug as the above described – if you hide the group(s) from the Exchange Address List, you will receive the same NDR as described in the above scenario (with code [578:0x0000­04DC:0x0000001D]) and you will have a tough time figuring it out; I for myself lost precious time double-checking permissions, OABs, Synchronization matters and proxy addresses, before coming to the "perpetrator".