I’ve worked with a few clients that, for various reasons, have modified the FQDN of the SMTP Virtual Server. By default, an SMTP Virtual Server will respond to an EHLO with the FQDN of the server itself (e.g. NYMAIL01.client.local) but some clients have adjusted this to something entirely different (e.g. SMTP.client.com). Most of the time, clients have changed this to mask the name of the underlying server responding to SMTP.
While modifying the FQDN of the SMTP Virtual Server certainly does mask this, the actual internal IP address of the server is still listed in the e-mail message headers and, as such, the identity of the server isn’t actually masked. Furthermore, if a hacker were to compromise a perimeter firewall, not knowing the exact name of the server providing SMTP services will not deter much.
In most client environments, modifying this FQDN is mostly harmless, provided that the configured FQDN is resolvable in internal DNS. This is because, when Exchange routing calculates a next hop, the announced FQDN of the appropriate SMTP Virtual Server is used. If the configured name was not resolvable, Exchange would queue and bounce messages destined for a specific server if that server was the designated next hop for SMTP routing. In addition to ensuring the configured FQDN is resolvable, it is also important to understand exactly why the change was made and the ramifications to doing so.
In one client environment I worked on, a specific Exchange 2003 server (SERVER2003_TLS, for example) was defined as the server to use for outbound communications to specific remote domains that required TLS (via an SMTP Connector and being defined as the associated bridgehead). SERVER2003_TLS also had its SMTP Virtual Server FQDN configured to something along the lines of mail.client.com instead of the actual server FQDN. mail.client.com was also the external and internal base URL for accessing OWA and ActiveSync services.
Everything worked fine in the Exchange 2003 environment because mail.client.com pointed to SERVER2003_TLS in DNS. However, when Exchange 2010 was introduced and mail.client.com was moved to the client’s new Exchange 2010 load balanced CAS Array for coexistence purposes, TLS mail started bouncing with a “local loop detected” NDR.
The reason for the NDR was that a message sent to one of the remote domains defined on the SMTP Connector that required TLS would query SERVER2003_TLS since it was defined as the bridgehead for that SMTP Connector. Since SERVER2003_TLS’s SMTP Virtual Server responded as mail.client.com, mail.client.com would be used for next hop routing. However, since mail.client.com had been repointed to the Exchange 2010 CAS Array for CAS coexistence and these servers were also hosting the HTS role, these servers accepted the messages. Since Exchange 2010 had not yet been configured with a direct outbound SMTP path to the Internet, all outbound Internet e-mail was routed across the coexistence Routing Group Connectors to one of two servers defined as transport servers for coexistence mail flow.
These Exchange 2003 servers then identified the same SMTP Connector for the configured remote domains requiring TLS and SERVER2003_TLS as the appropriate bridgehead, queried SERVER2003_TLS’s SMTP Virtual Server, received mail.client.com as the next hop, and the cycle continued until the message reached the maximum hop count limit. Any number of solutions could have been used to resolve this issue once it was identified but changing the SMTP Virtual Server on SERVER2003_TLS to something other than mail.client.com was the preferred approach.
While this specific issue may not happen elsewhere, it highlights the need to truly understand the nature of changes made that alter default functionality. In this case, changing the FQDN of the SMTP Virtual Server didn’t provide a lot of benefit to begin with but resulted in major mail flow issues down the road.
For more in my series on Exchange 2010 Notes from the Field, please click here.