What is a Border MTA?

A Border MTA (Mail Transfer Agent) is the first mail server responsible for handling your email. It operates at the "border" of your network, hence the name.

This is commonly an antispam service or appliance, or sometimes your firewall will have an "SMTP Proxy" built in (common with SonicWall, Tumbleweed, Symantec and Cisco router/firewall combos). Sometimes all the packets are sent directly to the mail server, then it is the "border MTA".

The easiest way to determine your Border MTA (although not always 100% accurate) is to see what server returns its name in response to the SMTP HELO command. In the event of an SMTP proxy on the gateway, it can proxy even these responses, but that's uncommon enough to ignore for most troubleshooting.

The reason an MTA in this location has a specific name is that there are some services that should run ONLY on the Border MTA, and if they are run anywhere else in your email's route can cause disastrous issues.

For instance, SPF authentication should ALWAYS be run on the Border MTA. Microsoft, in their infinite wisdom, decided to include SPF (under a proprietary name, surprise surprise) as a default option in their IMF settings (which stands for "Intelligent Message Filtering", please keep your guffaws to yourself) in Exchange 2003 SP2 through 2010. Keeping in mind that many of their enterprise level customers would have several layers of protection, and therefore probably several MTAs in front of theirs, this was a less than educated decision IMHO.

SPF (or Sender Policy Framework) is a relatively new standard (spearheaded by MS oddly enough) that adds DNS records for the domain advertised in the "mail from:" command. More information can be found here, but essentially if the connecting IP does not itself exist or resolve to a record that does exist in the SPF record the email is bounced or flagged. Let's see how it's supposed to work:

Sender: me@domain.com
Sending server's IP: 1.2.3.4
domain.com's SPF record: "IP4:1.2.3.4 -all"
recipient's border MTA's IP: 10.0.0.1
recipient's mail server: 10.0.0.2

The recipient's Border MTA does an SPF lookup on domain.com since that's in my email address. My DNS server says the SPF record is "IP4:1.2.3.4 -all", which means that all email should be coming from a server with the IP of 1.2.3.4. Since the connecting IP is in fact 1.2.3.4 it passes this check and is either passed to the mail server or is at least allowed to continue being processed.

Now, how it DOESN'T work.

The recipient's Border MTA does an SPF lookup, and it passes the SPF check due to the reasons above. Then, the Border MTA passes the message to the mail server which now does another SPF lookup on it. This time however, the IP of the connecting server is actually 10.0.0.1 NOT 1.2.3.4. So, since this IP is not authenticated by the SPF record, the message bounces unless other steps are taken to prevent this (such as whitelisting your Border MTA's IP).

Other examples of tests that should NEVER be run after the border MTA include RBL checks, reverse DNS tests (and "Forward Confirmed Reverse DNS"), greylisting, or really any IP based authentication techniques.

Of course, all anti spam tests should also be completed at the Border MTA, so greylisting, antispam, antivirus, and other tests should be run there as well to prevent backscatter. Only in special circumstances should even rate limiting be done after the border since this can cause unforeseen bottlenecks that can take an essential route out of commission.

In conclusion, if you only read one paragraph this should be it. Run ALL tests, especially IP based tests, at the border. The only thing that should happen past the border MTA is routing/load balancing to different destination MTAs (where the email is delivered to the user). Ignoring this rule is guaranteed to add to your headaches, and to your employer's dissatisfaction.

Regards,


TEA