Backup MXes

Thu Nov 17 00:49:35 PST 2005

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rick,

I'm missing the point of this e-mail? Is it really backup MXs, or a  
reason to publically
flog dnsreport's toolset?

On Nov 16, 2005, at 10:34 AM, Rick Moen wrote:

> 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 -----

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFDfEQrwjCqooJyNAMRAqHPAJ9yA0vy+Q1UB7uETrEvUtkZIPGaqACgmxok
hHgdTwORBSqJevSsmIKwCXI=
=uZ2w
-----END PGP SIGNATURE-----