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?
7 comments:
I know of at least one ISP in the Caribbean that has a 10-retries in several hours policy for delivering mail. If it can't get it through in that time frame, it NDRs it back to the sender. Secondary MXes, so long as they share the same list of valid users, and run at least a similar level of filtering everything should be groovy.
While most MTAs have decent queuing algorithms and connectivity is usually a lot more stable, those vcery factors have combined to convince many mail admins that it's no longer necessary to hold mail for the once-customary time of 7 days before NDRing it. (Ah, the good old days when everyone ran Sendmail. Of course, I hated Sendmail, but at least you knew what to expect.) And I'm not talking about small, insignificant hosts either. There are many major ISPs and mailing list services that will start bouncing mail in a shorter time than you might think.
And while connectivity is usually good, that's not to say it's perfect. When we moved the office, a simple misconfiguration by our data provider left a fair chunk of our public IP addresses unroutable for several days. It's not hard to conceive of circumstances that could keep your mail servers offline for 48, 72, even 96 hours, and you could very well be losing important messages in that timeframe. Backup MXs are still a very good idea.
...Of course Devin Ganger over at 3Sharp has a difference of opinion (and we all know he’s not afraid to express it). So what do you think? All of these guys are smart and the organizations that support them are reputable...
I don't know about most other sites, but ours has an emergency "backup" link for essential services; these days, email is an essential service, and we need to get it in a timely fashion - so the fallback MX is on a satelite site, linked via dedicated line to our main site; no external mail server could reasonably be expected to "discover" a route to our still-functional mailserver via another isp, terminating fifty miles away......
I can't imagine our situation is so unique - a company with more than one physical location, a dedicated line between them, and the cost of a direct ISP feed to the remote site noticably cheaper than provisioning all the extra bandwidth on the dedicated link *and* still buying that bandwidth from an ISP.
I like Richi aren't convinced you need a backup Mx. I think use of core networking protocols such as BGP and VIPs should provide enough protection if you lose a site (which I think is what most of the backup Mx records are really worried about).
So imho just use one Mx pointed to one IP and then do some fancy networking behind that to move the real load elsewhere in the event of a failure.
Backup MX Services are becoming essential these days because the old 7-day rule is no longer taking effect. I know a small company who gets roughly 12,000,000 messages in a 14-day period and if there mail server went down it could be very critical. More and more companies are only keeping emails for a few days and some only hold it for 12-hours max then send a NDR. So, would I recommend a backup MX service....Absolutely!
You've got an interesting conundrum on your hands, but you can only speak from the perspective you believe to be true: Backup MX's are irrelevant.
However, my experience has shown that having a backup MX is indeed required in many of the companies I have worked for. Though, it should be noted I do definitely agree that you should have a valid list of acceptable users and the same, if not better, spam/virus protection at the backup MX. Spammers tend to hit the backup first, not last, most of the time.
My background, of course, heavily deals with working with ISPs and a commercially available anti-spam/anti-virus vendor for which I worked for almost 2 years. So, I guess I got to see both ends of the arguments -- but that's another story for another time.
Under ideal circumstances, you would presumably have a load balancer presenting a Virtual IP pointing to several internal servers. This, I have seen, tends to be the case many times (from Halliburton to Seagate).
However, what happens when, for reasons uncontrollable by the ISP or the company receiving email when the network connection, mail servers, load balancer, firewall, or what have you, prevents access to this? The MTA, in theory, should be able to handle it, right?
Not quite. Some MTAs, even the more annoying and mundane ones like Exchange (some versions) tend to refuse to deliver the message, even though it originally only failed with a temporary 400 series error. As you know, that's not fatal and it is, by nature, temporary. As mentioned, several versions of Exchange stop attempting after this temporary error.
While I am loathed to use Exchange for any reason at all, I am forced to accept that several corporations, indeed many of them, do in fact. I have, in fact, found it to be the case that even a temporary and brief outage, that MOST MTAs would not argue with or even complain about, with a single MX record setup causes bounced email that does not attempt to re-deliver.
You can control your network setup and make sure your configuration is correct. You, however, cannot control the many many many companies out there that do not have the same. And, unfortunately, in the business world, you have to factor in the least common denominator.
You try telling sales people that their customers' servers are misconfigured and you can't get mail from them until they fix the bad setup. That will go over like a lead balloon -- and justifiably so -- you should always accept legitimate mail.
Sadly, this necessitates a backup MX at, usually, an off-site location.
-J
Post a Comment