Untangle Tarpitting and Secondary MX record = ugly
Posted by rbTech Staff on 15 February 2011 11:52 AM

We often set up one of our colocated servers as a backup mx for our clients and our own network.  Yesterday, we received a number of complaints from clients who were receiving bounceback messages from our secondary mail host that their message was undeliverable.

In our investigations, I realized that Untangle ( was tarpitting all incoming SMTP connections (sending a 451 please try again later).  Ordinarily this is perfectly acceptable, and is a very effective anti-spam measure because an infected host sending out spam usually won't come back to try again later, *unless* the domain has a secondary MX.  In that case, the sending server will do a DNS lookup on the domain, and see if there's another host that will accept mail for the domain (e.g. the backup mailhost).  At that point, it will not retry the connection to the primary server, and will instead simply deliver the message to the secondary host.

The secondary host will attempt to relay the message to the primary host.  However, since Untangle doesn't have a Whitelist ability in the tarpit, it will then tarpit the secondary MX's connection.  The secondary MX will then use DNS to look up another delivery point, and complain that the mail is 'looping' back to itself.  It will send an NDR back to the original sending server, and fail the message delivery.

Ultimately there are 2 ways to solve this:

Disable Tarpitting in Untangle, or

Disable the secondary MX record in DNS.

Neither are particularly satisfactory, but both are marginally more accepable than the scenario of your correspondents receiving NDR after NDR from your network that is in fact up and running just fine, but aggressively spam filtering.

(1 vote(s))
Not helpful