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:
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:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.