A Solution to the Static NAT and the SMTP Reverse Lookup Problem

Over the years a great number of ISA firewall admins have asked about static NAT support for the ISA firewall. These ISA firewall admins want to host multiple SMTP servers or domains, and want to bind a specific address for each SMTP server or domain in order to support reverse DNS lookups on the destination SMTP servers when they send mail to other SMTP mail domains on the Internet.

For example, suppose we have two SMTP mail domains:



When an outbound mail is sent to another SMTP server, the following events take place:

  • There are two mail servers: Mail Server A, which is the destination mail server, and Mail Server B, which is your mail server.
  • Mail Server A receives an incoming SMTP connection from machine B (it appears to A, that the connection from B originates from IP address X).
  • As part of the SMTP transaction, machine B identifies itself to Server A by saying: HELO mailserver.domain.com.
  • Mail Server A then carries out a reverse DNS lookup on IP address X – if the reverse lookup resource record (PTR record) matches the name mailserver.domain.com, then mail server A has a greater degree of certainty that the incoming mail is legitimate.

When the ISA firewall sends out mail from any mail server or any other host on an ISA firewall Protected Network, the source IP address will always be the primary IP address on the external interface of the ISA firewall. You can’t map a specific address on the external interface of the ISA firewall to a specific server on the corporate network.

The problem with hosting multiple domains and mail servers in our scenario is that mailserver.domain.com and mailserver.company.com cannot use the same source IP address because when the destination mail server does the reverse DNS lookup, there is no guarantee that the correct rDNS record with the correct name will be returned to the destination SMTP server. RFC states that each SMTP server should present a different source IP address.

For example, suppose we create two PTR records in DNS: PTR mailserver.domain.com PTR mailserver.company.com

When the destination SMTP server does a reverse lookup on, the destination SMTP server will resolve it to either mailserver.domain.com or mailserver.company.com. This means that rDNS will fail about half the time, since the destination SMTP server will use only the first record returned to it (per RFC).

How do I solve this problem? I use a smart host. A smart host is a machine that acts as an outbound SMTP relay. When you send you mail to a smart host, the destination SMTP server only needs to perform a reverse DNS lookup on the name presented by the smart host SMTP server during the HELO. The destination SMTP server isn’t going to try to match the domain used in the FROM header — all the destination SMTP server cares about is that the last hop outbound before reaching the destination SMTP server successfully passes the reverse DNS lookup.

There are a number of ways you can do this:

  • Configure a dedicated outbound SMTP relay on your corporate network and map a DNS and rDNS record for that machine and use that machine as your smart host
  • Configure a dedicated outbound SMTP relay on your ISA firewall and map a DNS and rDNS record for that machine and use that machine as your smart host
  • Configure your internal SMTP server to use your ISP’s SMTP server as a smart host
  • Work together with your friends to create a redundant network of smart hosts

Of course, the devil is often in the details. Some ISP’s require that you authenticate before they will accept outbound mail for relay, but most SMTP servers make this easy to configure (not sure about Exchange 2007, the command might be hidden in some obscure Monad string). If you’re interested in an article on how to make these different scenarios work, drop me a line at [email protected]



Thomas W Shinder, M.D.
Site: www.isaserver.org

Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7

Email: [email protected]

MVP — ISA Firewalls

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top