Backup MXes

Wed Nov 16 10:34:18 PST 2005

1.  Tip:  The www.dnsreport.com tests are damned useful.
2.  I thought y'all might want to chew on the question of backup MXes
    for a bit.

----- Forwarded message from rick -----

Date: Wed, 16 Nov 2005 10:31:13 -0800
To: whois at dnsstuff.com
Subject: Comment on a minor implementation flaw in your CGI, and on MXes

Dear Mr. Perry:

Just an observation and suggestion about the www.dnsreport.com CGI.
Please note the results of running 
http://www.dnsreport.com/tools/dnsreport.ch?domain=linuxmafia.com ,
as to acceptance of mail to abuse@ :  My MTA returned:

    >>> RCPT TO:<abuse at linuxmafia.com>
    <<< 550 Only one recipient accepted for NULL sender.

I'm guessing that you were combining multiple "RCPT TO" lines in that 
portion of your test.  My MTA, as part of its slightly paranoid anti-spam
regime, while it _does_ accept mail from null sender (for DSNs), knows
that implementing that RFC requirement shouldn't involve multiple
recipients, and so doesn't allow such mail.

You therefore might want to change your null-sender probes, accordingly.

The same flaw shows up in the row for "Acceptance of domain literals",
where your script shows a spurious warning claiming "One or more of your
mailservers does not accept mail in the domain literal format", because
my MTA said:

    >>> RCPT TO:<postmaster@[198.144.195.186]>
    <<< 550 Only one recipient accepted for NULL sender.

Last, a third appearance of that flaw:  linuxmafia.com got a "PASS"
on "Open relay test" for, oddly, non-sequitur reasons, when my MTA
replied:

    550 Only one recipient accepted for NULL sender.

My MTA isn't an open relay, but not for the reason shown.  ;->

Comment on the "Multiple MX records" test (not a criticism):  An
increasing number of us sysadmins have come to regard backup MXes 
as more trouble than they're worth, unless you personally admin 
all of them and carefully place them under the exact same antispam
regime.  

For one thing, the spammers long ago figured out that they should
drop off spam preferentially at a domain's _high-numbered_ MXes, 
because the least-preferred MXes usually have the most lax antispam
regimes, and because then the domain owner's MXes work hard to redeliver
spam to the primary, leveraging the target's own network and computing
resources against himself.

For another, I found out repeatedly that third-party backup MX providers 
have a nasty tendency to shut off your relaying or otherwise screw up
your mail, with you having no opportunity to find out they've done that
until the worst possible moment, i.e., when your primary MTA goes
offline.

At that point, you'd be _much_ better off having _no_ backup MXes at all,
rather than backup MXes that energetically autobounce your mail.  Absent
any backup MXes, delivering MTAs elsewhere will keep retrying for four
days.  As long as you bring online a replacement primary MX within that
four-day period, you will not miss any mail.  I figure I can always 
manage that.

Thus, except in the rare, exceptional case of personally controlling
one's multiple MXes, I have come to regard the existence of backup MXes
as actively _undesirable_, contrary to commonly heard advice.

----- End forwarded message -----