A Late New Year's Resolution: Do Not Resolve Anonymous Senders

It's probably a little late to make another New Year's resolution, but I'll try to convince you to make one nevertheless.

By default, when an internal/authenticated user sends you a message, you see the user's display name (e.g. "Joe Adams") in Outlook/OWA, et al. Messages from unauthenticated users, including those from internet senders, show up with their SMTP address - e.g. jadams@somedomain.com. Exchange/Outlook users have been used to seeing this.

You can change SMTP settings to resolve anonymous senders. On Exchange Server 2003: SMTP Virtual Server properties | Access tab | Authentication | check "Resolve anonymous senders". On Exchange 2000, this is done by creating the ResolveP2 registry value described in KBA 288635.

However, not only is resolving anonymous senders a bad idea, it's also a security risk. SMTP, the protocol, allows senders to easily spoof headers. Anonymous senders can send mail to your users, using your CEO's email address for instance, and the message will actually appear as if it was sent by an internal/authenticated sender. A spam message, or one with malicious code - if it gets by anti-spam & anti-virus scanners - buys instant credibility by getting the sender's address resolved to a valid internal sender.

This is one of the reasons I've always wanted Microsoft Outlook to provide an option to show SMTP headers at first look - without the time-wasting, mouse-clicking exercise of selecting a message, right-clicking, selecting Message Options, and viewing what is usually a long message header in a small scrollable text box. It would be great to provide users the option to turn on a "mini" header that shows the actual originating host, and for advanced users - including sysadmins / Exchange administrators who look at headers all day, an option to turn on "full" headers. Sadly, this doesn't exist, even in Outlook 2007. (You could use a little macro that KC posted on her blog a little while ago - and have a button on the Outlook toolbar that shows you the headers with a single click and saves them in a text file.)

What's worse - and I just discovered this, thanks to a newsgroup poster and Exchange MVP Andy David's response - when you check the option to resolve anonymous senders, unauthenticanted senders can now send mail to recipients that have been set to receive email from authenticated users only! That's a big surprise, and totally unexpected - Exchange actually treats anonymous senders as authenticated senders, at least for the purpose of message delivery to such restricted recipients.

Further, not only can someone using a valid internal recipient's email address send mail to such recipients, but even total strangers (addresses that do not resolve to a valid internal recipient, like foo@somedomain.com) can.

I tested this a few times yesterday, and I'm still in disbelief!

Having read KBA 828870: Resolve Anonymous Senders Functionality in Microsoft Exchange 2003 a few times, I don't find any mention of this, though the article clearly recommends that this should not be enabled on any server that receives mail from the internet, and if it is - message from anonymous senders appear as authenticated mail.

KBA 827616: How to restrict the users who can send inbound Internet e-mail to another user or to a distribution group in Exchange 2003 does mention this. It says:

Note If you enable the Resolve anonymous e-mail setting on your front-end SMTP servers, anonymous senders can bypass the From authenticated users only setting.

There may be scenarios where resolving anonymous senders is justified, for instance on internal SMTP virtual servers, where access is controlled or restricted to certain hosts. If you're in a cross-Forest deployment, you should attempt to authenticate the SMTP communication, as stated in KBA 828870 above.

As I said in the beginning of this post, if it's not already too late to make another New Year's resolution, make one today to not resolve anonymous senders on SMTP virtual servers that receive internet mail.