Why Do People Use a Backup MX?

Some organizations set up their MX records so there's an offsite backup MTA to receive mail (perhaps that should read "many organizations", I have no data). Is there still a justification for doing this?

In my simple view of the world, you simply don't need a backup MX. If your primary MX is unavailable, mail should still queue at the sending MTA for several days. The sending MTA should continue to retry periodically until your site is available again. In many ways, backup MX configurations are an anachronism -- a holdover from the days when connectivity was unreliable and some MTAs' queuing algorithms weren't great.

Backup MXs can cause problems if they don't do the same spam filtering that your primary MX does. This can cause backscatter.

If your primary MX is down for some time, a backup MX could also cause backscatter spam with "delayed" DSNs (delivery service notifications). On the other hand, not using a backup MX would usually allow the sending MTA to generate the DSN, which is a much better way to do it.

What do you think? Are there circumstances where a backup MX makes sense for you?

More About Why Cisco Bought IronPort

As I mentioned last week, Cisco bought IronPort for $830 million.

Clearly IronPort's reputation data is part of the prize for Cisco. Perhaps also, the PostX email encryption technology will possibly be useful (IronPort bought PostX last year). Perhaps some enhanced competition for Identum and Voltage? Alternatively, I fear that Cisco may let this stuff wither on the vine -- PostX customers should be concerned and watch closely.

An interesting question is what will happen (if anything) with SpamCop. IronPort deliberately ran SpamCop at arm's length as a matter of policy. It's not clear whether Cisco will maintain that policy. SpamCop is of course part of the raw data feeding into IronPort's reputation database, along with the data phoned home by the IronPort boxes.

As we saw with the BlackSpider acquisition by SurfControl, spam control companies that aggregate lots of data about spam sources are valuable, for reasons in addition to spam control. For example, if a zombie is sending spam, it's also probably a potential source of other bad stuff, such as worms and distributed denial of service attacks.

See also: my roundup of blogger reaction to this story in Friday's IT Blowatch.