Brassy dot net

You'll begin to notice around here that e-mail and Postfix are two of my favourite subjects. Postfix is simply the best MTA out there at the moment, for a number of reasons, not least of which is the postfix-users mailing list.

I used to ignore the discussions before when people talked about the "best MTA" but after 5 years reading and occasionally posting to that list when I've continually unsubscribed from others suggests there's something else involved. Postfix isn't just the best mailer because of the software, but also because of the community.

Now, onto the main point. Having a backup MX is more often than not actually dangerous. That's right! It's not just pointless, it's dangerous. OK, so when I say dangerous, I don't mean it's more likely to kill you in your sleep. It won't light a cigarette when there's a gas leak or hang your children from a 3rd storey window. However, it could generate more problems than it solves. What's the point in spending effort and money on something that causes more problems than it solves?

The point of a backup MX is that if your primary mailserver is down, mail will be delivered to the backup MX instead. That doesn't mean your mail is actually collectable... Oh no. I'll say it again: having a BACKUP MX does not mean you can collect your mail if the primary mail server is down. Users cannot download or read mail off a backup mx (you can read directly from the mail queue if you that's what fills your pie I suppose).

Ok, so what's the point of a backup MX then? Well a backup MX will essentially queue your mail until your primary MX is back up and running. In days of yore on d'internet when you had far less reliability, far less spam and redundancy meant a lot less than it does today mail servers would go down occasionally. Sites were more friendly (less commercial) and would perform backup MX and secondary / tertiary DNS for each other. The advantage of the backup MX is that once the primary MX was back up and running after some downtime, the queue could be flushed on the backup MX to start relaying all the mail onto the primary MX that it had collected while it was down.

You don't have to worry about misconfigured mail servers on remote sites or delivery notifications going back to senders informing them your mail server is down etc. etc. So back in the before time, this was all great and allowed administrators to take down their mailserver without much thought.

It all sounds good until you zoom forward to 2006 and you start to inspect the reasoning a bit closer. So when Joe User X in Australia tries to send one of your customers/users a mail he doesn't connect to your mailserver directly. He connects to his ISPs mailserver or his hosting providers mailserver and instructs them to send the message on.

His ISPs mailserver or hosting providers mailserver should be configured with sane defaults like the maximum retry time for a message. This is the maximum amount of time the MTA (mail transport agent; i.e. the piece of software on your mail server which accepts, queues and relays messages) will try to deliver to a remote site before it gives up. This time should be set to 4 or 5 days! [ Ref: RFC 2821 ]

If your mail server is down for four or five days you probably have more serious problems and backup MX's normally have a limit to the amount of messages or length of time they'll queue messages for anyway. The only advantage is that you get to decide when messages start to deliver back to your primary MX.

Ok, so it's not completely pointless, but I don't think it's the end of the world. That's often not enough to satisfy the pointy haired bosses though and to move away from what's seen as convention. "Backup" always sounds good and email has become so critical for some businesses that anything that sounds like "backup" for e-mail is very tempting.

The bit where it becomes dangerous is when spammers enter the equation. It's all fine and dandy when Chuck is sending his sister Sue an email and everything's legitimate and above board. But what happens when Chuck is a spammer and he's got a couple of million spam messages to send out?

Well, in some cases, Chuck has noticed that primary MX's are configured to stop him sending them spam. They do all kinds of checks including a really important one which is to reject non-existent recipients at the SMTP layer.

When Chuck connects to your well configured mail server and sends a mail to dontexist@domain.com, the mail server will reject it. Poorly configured mail servers will blindly accept the mail and use a bounce message to inform the user of an non-existent recipient.

Bounces in this case are bad, because Chuck (the spammer remember) normally tries to hide his identity. So he'll often pretend to be sending from a domain that doesn't exist or doesn't have mail servers and the bounces can't be sent anywhere and they queue up on your server.

Maybe you're also using RBL checks on your mail server which reject dodgy clients during the SMTP transaction. There are also a host of other restrictions that can we used to weed out a percentage of spammers during the SMTP phase of the process. Remember that the SMTP transaction is basically looking at the connecting IP address, the envelope sender and recipient and other details about the transaction. It rarely involves actually scanning the mail, most mail servers are configured to accept mail, then scan, then bounce / tag / discard if it's spam. During the SMTP transaction spammers basically connect to your mail server, try to send a mail you look at certain conditions, go "No you're a spammer, piss off" and they go. (note: it is possible to use something like SpamAssassin during the SMTP transaction, just that it can be intense on resources and most people avoid it.

This brings us onto problems with backup MXs. They are normally poorly configured. They don't have the same amount of spam restrictions as the primary MX & most importantly they nearly always don't have a list of valid recipients on the domain they're accepting mail for. They are almost certainly always a bad idea when they're not under your control. Unless by some fluke of luck, or actual co-ordination, you're not going to have the same spam controls on your server as someone else (consistency is important here as well).

Because of this tradition, if you'll let me call it that, plenty of spammers have decided that sending mail directly to a backup MX will give them a much higher chance of getting their mail through. And... most of the time they're right.

Even if they don't, if your primary mail server is down, suddenly the backup MX gets hit with all the spam as well and it doesn't have adequate measures to deal with it.

So, although the title of the article is "Backup MXs are pointless and dangerous" what's probably more appropiate is "Poorly configured Backup MXs are pointless and dangerous". That's not as hard hitting though and the first one sounds better!

If you know why and how Backup MXs are a bad idea, it's possible to run one that in conjunction with your primary MX. However, be aware that the backup MX cannot just sit there while you upgrade and put in place restrictions for your primary MX. It needs as much tender loving care as it's lower priority brother.