Deb Shinder Blog RSS

All Blogs  »  Deb Shinder Blog  »  ISA Central  »  Blog article: A Solution to the Static NAT and the SMTP Reverse Lookup Problem

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:

@domain.com

@company.com

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:

1.1.1.1 PTR mailserver.domain.com

1.1.1.1 PTR mailserver.company.com

When the destination SMTP server does a reverse lookup on 1.1.1.1, 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 tshinder@isaserver.org

Thanks!

Tom

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

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

Email: tshinder@isaserver.org

MVP — ISA Firewalls

10 Responses to “A Solution to the Static NAT and the SMTP Reverse Lookup Problem”

  1. Mike Wooldridge Says:

    November 22nd, 2006 at 11:42 am

    Hi Tom, i just read this article “A Solution to the Static NAT and the SMTP Reverse Lookup Problem” and understand the concept but wonder how this might help with another scenario that happens while hosting mail for clients, if all email is sent out via the same ip and a client’s smtp instance gets spammed, even with all the necessary blocks in place, then the IP number sending email gets on a black list and finally no one can send email. What are your thoughts. Thank you.

  2. Henrik Zawischa Says:

    December 12th, 2006 at 7:45 am

    Hi, Tom,

    this does not really solve the problem. Why? Because what we want is two different names and addresses for two different domains. So that the mail-flow is seperated completely. Your approach brings it all back to one relay - the source of all mails will be one IP.

    We think that this lack of static NAT is a major shortcoming in ISA Server. There is no workaround.

    Henrik

  3. Thomas Shinder Says:

    December 12th, 2006 at 5:20 pm

    Hi Henrik,

    Is does solve the problem because rDNS lookups just check the last hop. They don’t try to resolve the MX domain name of the source email message.

    HTH,
    Tom

  4. Pierre Dufresne Says:

    January 26th, 2007 at 3:16 pm

    It works OK with one ISA server.
    If you have a pair of ISA EE 2004 servers load balanced with NLB, you will never know which ISA server is used to relay the mail and you are stuck with the same original problem.

  5. Lance Prager Says:

    May 29th, 2007 at 5:45 pm

    Unfortunately, without actually changing the IP for outbound mail, abuse checking services will not work with this solution.

    They check the sending ip which is registered. Reverse DNS is not often used anymore in spam prevention scenaraios, instead most engines rely on RBL services and that means IP

    So, without Static NAT you can really only use one outbound public IP address regardless of the number of static public IP’s you have.

  6. Thomas Shinder Says:

    May 29th, 2007 at 6:17 pm

    Hi Lance,

    That’s correct, but it doesn’t matter. These solutions only check for the last hop address, so as long as you use a smart host, it doesn’t matter how many public IP addresses you have.

    HTH,
    Tom

  7. Andre van den Berg Says:

    April 8th, 2008 at 6:03 am

    Helo Tom,

    Pierre has right with ISA EE with two servers and NLB. We have also ISA 2006 EE with two servers and NLB.

    One time the mail is send from xxx.xxx.xxx.66 and other time xxx.xxx.xxx.67

  8. Andrew Says:

    July 1st, 2008 at 8:40 am

    Same problem with EE here and mail servers. For now we’ve hardcoded our outgoing mailserver to use only one array member, so the outgoing IP is consistent. Kind of defeats the failover protection of having the array, but its what we’re stuck with right now.

  9. Jack Says:

    December 16th, 2008 at 1:36 pm

    Hi Tom,

    We have only one email server. When we send an email, it has a source IP of x.x.x.117. The problem is that the MX record is to x.x.x.118. This is a major problem because of Spam enginees. The Spam engines will see a difference in IP address and think it is Spam. There are third party solutions out there that will do this for us, for a price. Is there ANY way to do this in the ISA configuration?

  10. vpavel Says:

    March 4th, 2010 at 8:42 am

    Hello Thomas
    It’s an nice article, but what about ISa 2006 NLB.We have exchange 2003 as front end protected by isa 2006 nlb.What can we do to allow mx resolving and keep failover protection for outbound smtp ?Does any solution exist ?

Leave a Reply

This is a captcha-picture. It is used to prevent mass-access by robots. (see: www.captcha.net)

You must read and type the 5 chars within 0..9 and A..F, and submit the form.

  

If CAPTCHA image is missing or you cannot read the characters above, please generate a




Receive all the latest articles by email!

Receive Real-Time & Monthly ISAserver.org article updates in your mailbox. Enter your email below!
Click for Real-Time sample & Monthly sample

Become an ISAserver.org member!

Discuss your ISA Server issues with thousands of other ISA Server experts. Click here to join!

Follow TechGenix on Twitter