Things Not To Do with MailHop Backup MX

Tarpitting is when your mail server determines that some other mail server (in this case ours) is making too many connection attempts and/or is trying to send mail to too many addresses which don't exist.

This can cause serious problems. Let's say a spammer decides to do a directory attack against your domain and sends hundreds or even thousands of messages to our mail server to addresses which don't exist at your domain. Before accepting a message for delivery, our server will try and connect to your server and do an address verification. If you server rejects the address, we'll turn around and immediately reject the message at RCPT TO time.

If we're not able to connect to your server (because your server is off-line or because you are tarpitting us) then we have no choice but to accept the message and queue it for later delivery. This is OK (and in fact necessary) when your server is off-line, but if it is the result of tarpitting then you can end up with our server queueing potentially tens of thousands of messages which may include valid email as well as spam. You might not notice the problem until one day your server is off-line for a while and you don't get messages from us when it comes back on-line. Once you remove our servers from the tarpitting we'll have to attempt delivery of every single message to your server and that can take a long time.

When a message comes in for an invalid address at your domain, there are three things you server might do. It might

• accept the message (and either deliver it to a default mailbox or send it to /dev/null)
• reject the message with a soft/temporary error (4xx error code)
• reject the message with a hard/permanent error code (5xx error code)

Either of the first two behaviors can cause significant problems. If you accept all such messages your server can become overloaded with junk mail sent as part of a directory harvesting attack. While this won't have an overly significant impact on your Backup MX, it prevents us from limiting the amount of junk mail sent through our system based on address verification.

The second behavior however can have much more drastic consequences. If you server is configured to issue a soft/temporary rejecting on messages addresses to invalid addresses, this will result in our system accepting messages for your domain and queueing them for delivery. We'll then end up queueing these invalid messages for up-to 10 days before we eventually bounce them. This can affect our ability to deliver valid email to your domain as we well as decrease the performance of the service for all customers.

For these reasons, we ask that you configure your server to follow the third path, reject all mail at receipt time with a 5xx level error message. This will allow our servers to reject those messages immediately and will help ensure the best overall performance for your domain.

You shouldn't have this problem if you use our Custom DNS service (because we won't let you create these sorts of MX records) be we occasionally have customers using MailHop Backup MX who have DNS provided by a third party that has allowed them to create a primary MX record that points directly to an IP address or alternatively to a host name which is defined by a CNAME record instead of an A record.

For example, either of the following are broken configurations which can cause problems.

MX record pointing to an IP address:

example.com.          48200   IN  MX      10 10.11.12.13.
example.com.          48200   IN  MX      20 mx2.mailhop.org.

MX record pointing to an alias:

example.com.          48200   IN  MX      10 mail.example.com.
example.com.          48200   IN  MX      20 mx2.mailhop.org.
mail.example.com.     48200   IN  CNAME   server.example.com.
server.example.com.   48200   IN  A       10.11.12.13

The correct configuration would be

example.com.          48200   IN  MX      10 server.example.com.
example.com.          48200   IN  MX      20 mx2.mailhop.org.
server.example.com.   48200   IN  A       10.11.12.13

Having the primary MX record pointing directly at an IP address will result in our server rejecting mail for your domain with a 5xx error response. Having the primary MX record pointing to a CNAME can cause unpredictable results. Since both configurations are a violation of various DNS and SMTP specifications, they should be strenuously avoided.

mx2.mailhop.org as sole MX host:

example.com.        48200   IN  MX      20 mx2.mailhop.org.

mx2.mailhop.org as primary MX host:

example.com.        48200   IN  MX      20 mx2.mailhop.org.
example.com.        48200   IN  MX      50 server.example.com.

Both of these configurations will result in our server rejecting all mail for your domain on receipt. The error message will be slightly different in each case, but the end result will be the same.

Some customers don't want to have hosts other than their own show up in the list of MX hosts for their domain. This is usually due to a feeling that this shows a level of unprofessionalism. Really, nothing could be further from the truth. Using a service such as MailHop Backup MX shows that you are serious about making sure that your mail will be delivered to you and that your email is protected from even catastrophic events.

This leads to customers creating a host name within their own domain, pointing that host to the IP address (or addresses) of our mx2.mailhop.org host and then adding an MX record that points to their own host. Alternatively, they may create a CNAME record to point their own host to the mx2.mailhop.org host.

Pointing your own host to our IP address:

example.com.          48200   IN  MX      10 server.example.com.
example.com.          48200   IN  MX      20 backup.example.com.
backup.example.com.   48200   IN  A       204.13.249.91

Making an alias to mx2.mailhop.org

example.com.          48200   IN  MX      10 mail.example.com.
example.com.          48200   IN  MX      20 backup.example.com.
backup.example.com.   48200   IN  CNAME   mx2.mailhop.org.

Doing either of these things can cause serious problems. If you map your own host name to one of the mx2.mailhop.org IP addresses, you won't get the benefit of our having multiple servers AND if we move that server to a new IP address for some reason your MailHop service will no longer be functional.

If you create your own host and use round robin A records to map this to all of our IP addresses, you will actually cause a potential loop scenario where our servers will deliver messages between each other up to a maximum of 30 times, at which point we'll bounce the message (this loop takes about a minute).

If you use the CNAME method, the results will simply be unpredictable due to the fact that different mail servers behave in different ways when they encounter an MX record that points to an alias.

MailHop Backup MX is intended for use with a primary mail server which you personally operate. It is very strongly recommended that you do not use a third-party service for your domain's primary mail hosting, with MailHop Backup MX acting as a backup to their servers.

First, this should generally be unnecessary; most mail hosting services have their own redundant systems, and MailHop Backup MX should (ideally) be unnecessary in light of these safeguards.

Hardware anti-spam devices such as the Barracuda are becoming more and more commonplace. However, misconfiguration can result in lost email. For example, one of the default settings for the Barracuda is to begin rejecting mail from a source if too many messages are sent in too short a window, regardless of whether or not they are spam; if left enabled, this can result in the Barracuda blocking our Backup MX servers while they are trying to deliver their stored queues to your server.

And, last but not least, don't neglect to actually include mx2.mailhop.org in the list of MX records for your domain. The service can't work if you don't list us in the MX records.