Things Not To Do with MailHop Backup MX

This KB article lays out a number of things which we have seen MailHop® Backup MX customers do which have had a negative impact on their service. We're documenting these here to assist all of our MailHop customers in not making the same mistakes.

Changing settings in MailHop Relay while mail is queued

If MailHop Relay receives a message, but is unable to deliver that message to you, the message is tagged with the destination port and hostname and sent to MailHop Backup MX for queuing and redelivery.

If you change the destination hostname or port in your Relay service, mail still stored in Backup MX will continue to be delivered on the original hostname and port. For example, if you have your service set to mail.domain.com on port 2525, and you move to a new location and set up your server on 10025, Backup MX will still try to deliver stored mail to 2525.

Since messages cannot be re-tagged once received, it is very important to keep the hostname and port the same after downtime. If the original port is disabled for some reason (new network, ISP port blocking, etc.), you will need to set up a temporary server on the original port in an unrestricted network to "flush out" the stored queue. (New messages will be tagged with the updated configuration.)

Please also note that the service tags by port and hostname; you can change the IP for your hostname to a new location without any adverse effects on mail delivery. Customers using just MailHop Backup MX generally do not need to worry about this issue when using the service.

Tarpitting

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.

So, make sure you don't tarpit our servers. In fact, you should explicitly whitelist our servers. See our entry Using MailHop Services with Firewalls, for the current list of IP addresses.

Note: If you are going to restrict access to your mail server based on the IP addresses of our MailHop servers, you must subscribe to the system-status mailing list, available on the mailing list management page.

Soft rejecting or accepting invalid addresses

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

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.

Having MX records which point to IP addresses or an alias

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.

Setting mx2.mailhop.org as the primary server

Do not set the mx2.mailhop.org as either the sole or primary MX host. The following two configurations represent these cases.

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.

Using an alternate name for mx2.mailhop.org

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.

Using third-party primary mail hosting

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.

However, the larger concern is that most mail hosting providers do not allow customers to whitelist particular sending servers or IP ranges. As a result, the mail host's anti-spam services may blacklist our servers when we are attempting to redeliver stored mail, causing the queued mail to be lost. Unless you are absolutely certain that you are able to fully whitelist our entire MailHop IP ranges or *.mailhop.org (if whitelisting by host), you should not use MailHop Backup MX.

If you are using a third-party mail hosting provider for your domain, and you are worried about the reliability of their service and their own redundancy measures to ensure your mail is safe, you may wish to either begin hosting the mail yourself and using our Backup MX service, or find a new mail hosting provider for your domain.

Using a hardware anti-spam solution without proper configuration

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.

You must be absolutely certain to fully whitelist our entire MailHop server IP ranges or *.mailhop.org (if whitelisting by host) to ensure that your device does not accidentally target MailHop Backup MX as a spam source, in addition to whitelisting and disabling these types of measures on your server itself.

Note to Barracuda users: When configuring your device to work with MailHop Backup MX, please add our MailHop server IP addresses as Trusted Forwarder IPs under Advanced - Email Protocol. This allows the Barracuda to continue to scan messages delivered through MailHop, while preventing the device from accidentally designating our servers as a spam source.

Not adding mx2.mailhop.org to the list of MX hosts

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.