The vast majority of modern messaging environments have a challenge of establishing and maintaining reliable and secure Internet e-mail connectivity. While the task of enabling Internet e-mail routing is relatively straight forward and usually well documented for most messaging platforms (most people view it as narrow as creating a DNS MX record for inbound e-mail and designing an equivalent of an SMTP connector for outbound e-mail), making a robust Internet e-mail system can be quite challenging. In this blog, I wanted to share some of the issues and challenges that Microsoft IT faced in the Internet e-mail area as well as demonstrate some solutions that were implemented in Microsoft’s own messaging environment to make Internet e-mail flow. This solution is based on Exchange 2003 technologies, so it may be relevant to other environments that have Exchange 2003 performing gateway functions to send and receive mail from the Internet.
Before we jump into the technical details, let’s look at the problem area. In addition to the fact that a typical SMTP gateway system is a popular point of enforcing e-mail hygiene policies (such as antispam and antivirus) it has the fundamental task of bridging two different e-mail transports – a reliable, trusted, authenticated, rich and mostly homogeneous transport of the internal messaging system; and an unreliable, anonymous, generally non trusted, highly heterogeneous SMTP transport on the Internet or in the DMZ. For example in case of Exchange 2003, the internal SMTP transport is authenticated with Windows Integrated Authentication, Send-As permissions are enforced, Linkstate and EXCH50 blobs are exchanged and hopefully viruses are spam are already being cleaned for internal messages. The external SMTP transport does not exhibit such characteristics.
In essence the focus point of this blog can be pictured by the following diagram.
Most Exchange 2000/2003 environments face the following challenges when connecting an Exchange gateway to the Internet or to the DMZ SMTP infrastructures:
- Exchange SMTP gateway has to accept anonymous SMTP connections from the SMTP gateway in the DMZ or from the Internet. Many of the environments do not want to expose Exchange SMTP authentication to the outside systems, to minimize the risk of password harvesting/guessing from the outside.
- Exchange SMTP gateway has to accept authenticated SMTP connections from the internal Exchange servers and relay e-mail received from them to the Internet. It may also have to accept and transmit system information, such as link state and EXCH50 info, from the internal Exchange servers, which requires authenticated connection. Allowing anonymous SMTP authentication to the internal SMTP systems also may be undesirable as it opens a possibility of unauthorized e-mail submission to that gateway. Anonymous mail submission, even in the internal environment, also opens a possibility of sender address spoofing.
- Exchange SMTP gateway administrator may want to enforce different actions (such as filtering, or archiving) to the SMTP e-mail that enters the environment versus e-mail that leaves the environment. Inbound e-mail coming from the Internet is generally less trusted from the security perspective and often needs to be subject of additional security checks (such as spam filtering, content inspection). Outgoing e-mail traffic is more trusted and some of the filtering/security controls may be waived for performance reasons. In the end, you don’t expect your internal users to spam the Internet!
- Environments want quick and easy metrics and reporting on the amount of e-mail that they send to the Internet versus the amount of e-mail that they receive from the Internet. Those metrics, for example, are often used for capacity planning and also to justify the investment into spam filtering technologies.
While Exchange 2003 SMTP stack is fairy functional and efficient in the gateway role, its default configuration makes it quite challenging to accomplish the above tasks. Consider the following diagram that represents a typical default configuration of Exchange 2003 based SMTP gateway:
While perfectly functional from the mail routing perspective the above design has the following limitations/concerns:
- Both inbound and outbound mail go through the same virtual server making it difficult to enforce different policies, such as e-mail filtering, blocking or adding disclaimers.
- Authentication is exposed to the external environment making it possible for password guessing from external systems
- Relaying for authenticated users is allowed so knowledge of a single valid username/password allows external users to relay mail from the external hosts
- Inability to restrict the default SMTP virtual server by IP (for example so that only SMTP servers located in the DMZ can submit mail). Restricting by IP will prevent all internal Exchange servers from connecting.
- Anonymous SMTP is exposed to internal clients, that may quickly turn this gateway into mail server that internal users target with their SMTP applications to relay mail directly to the Internet bypassing established enterprise avenues for these functions
- There is no easy way to calculate metrics for inbound e-mail versus outbound e-mail (you most likely have to go through the tracking logs to get this data)
A slight modification of this design that Microsoft IT implemented internally for its Exchange 2003 based gateways makes all the above items possible.
Exchange 2000 and 2003 allows creating multiple SMTP Virtual servers on a single Exchange computer. Obviously those SMTP Virtual servers need to be logically separated. One SMTP Virtual server is designated as Inbound SMTP Virtual Server and is handling e-mail traffic from the Internet and another SMTP Virtual Server is handling outbound traffic. The easiest way to create multiple SMTP Virtual Servers is to assign them to different IP addresses. In the case of a dual homed computer those IP addresses are assigned to different NICs. In the case of a server with a single NIC multiple IP addresses can be assigned to that single NIC.
When you create multiple SMTP virtual servers, they must be properly bound to the respective IP addresses in Exchange ESM.
Hosting the SMTP connector for the Internet on the appropriate SMTP virtual server, ensures that only that virtual server passes outbound mail going to the Internet. Pointing MX records or smarthosting SMTP servers in the DMZ to the IP address of the second SMTP Virtual Server ensures that all e-mail traffic going through it is inbound to the organization.
An important note is binding SMTP Virtual Server to IP addresses affects only inbound SMTP connections. The source IP address of the outbound SMTP connections from such gateway server will be determined by the IP layer of the sending host. For example if the gateway has two IP addresses, 172.16.x.1 and 10.x.x.1 and wants to communicate with the remote host 10.x.x.2, then the source IP address of the SMTP connection will be 10.x.x.1, regardless which SMTP Virtual server established the connection.
Having such design in place you can apply different filtering and other security policies to SMTP Virtual Servers separately. For example if you want to implement sender filtering of specific internal aliases (to mitigate the problem of them being spoofed from the Internet) you can enable such filtering on the Inbound SMTP Virtual Server only. Thus, outbound e-mail flow will not be affected by such filtering.
If you have a spam filtering solution that runs on Exchange 2003 gateway platform (such as IMF or Brightmail) you can bind that solution to the Inbound SMTP Virtual server. This way your outbound mail won’t be scanned for spam which could result in performance wins.
With the two SMTP virtual server approach you can control inbound vs. outbound e-mail traffic through this gateway separately.
As an added benefit of the above design, you get more convenient monitoring of inbound and outbound Internet mail flow going through this gateway. Performance Monitor has separate instances of SMTP counters for each SMTP Virtual Server. The counter for instance #1 represents the first SMTP Virtual Server (in this case Outbound mail) and instance #2 maps to Inbound Internet mail.
It should be noted that such configuration should be used for Exchange gateway servers that do not host production mailboxes. When the server is rebooted the first SMTP Virtual Server to start will own the local store’s SendQ, hence for mail originating from the mailboxes hosted on the server itself there is no guarantee which SMTP Virtual Server will be used to process such messages. This may affect the validity of metrics for inbound vs. outbound mail.