Backup MXes

Wed Nov 16 12:51:33 PST 2005

----- Forwarded message from "R. Scott Perry" <info at DNSstuff.com> -----

Date: Wed, 16 Nov 2005 14:49:53 -0500
From: "R. Scott Perry" <info at DNSstuff.com>
To: Rick Moen <rick at linuxmafia.com>
Subject: Re: Comment on a minor implementation flaw in your CGI, and on MXes

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

Actually, we have code that looks for "bounce messages", "single 
envelope recipient", or "multi-recipient" in the response (to which "one 
recipient accepted" is being added), in which case the following will be 
added:

---
NOTE: It appears that one or more of your mailservers rejects E-mail to 
domain literals if the return address is <> and there are multiple 
recipients.  The RFCs say that mailservers are required to accept E-mail 
to the abuse@ account, and do not say that it is acceptable to block 
E-mail from <> with multiple recipients.  Although it is unlikely this 
will prevent legitimate E-mail from being blocked, it does prevent 
testing tools from detecting that your mailserver accepts E-mail to 
domain literals (the only way we can work around this is by making 
multiple partial E-mail attempts, which could trigger anti-spam software).
---

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

FYI, so you know, it is impossible to accurately distinguish that 
response from "550 Recipient does not exist".  A 550 response is a 550 
response is a 550 response, per the RFCs.  :)

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

My above comment applies here too:  550 == 550.  :)

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

Good point.  I've been considering changing that from a warning response 
to an "informational" response, and have just gone ahead and done so 
(which will take effect when the site is next reloaded, tomorrow morning).

I'm still a fan of multiple mailservers in most cases, especially now 
that many mailservers have significantly reduced the amount of time they 
will keep re-trying E-mails, but otherwise the advantages of multiple 
mailservers are dwindling (such as when the backup has too strict 
anti-spam, causing E-mails to "disappear").

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

Actually, that isn't true.  I believe the de-facto standard back in the 
1990s was 2 days.  But in my experience, few mailservers will re-try 
more than 1 day.  And some won't even re-try a single time, and will 
bounce the message immediately.
                        -Scott

----- End forwarded message -----
----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Wed, 16 Nov 2005 12:49:56 -0800
From: Rick Moen <rick at linuxmafia.com>
To: "R. Scott Perry" <info at DNSstuff.com>
Subject: Re: Comment on a minor implementation flaw in your CGI, and on MXes

Hi, Scott.

> Actually, we have code that looks for "bounce messages", "single 
> envelope recipient", or "multi-recipient" in the response (to which "one 
> recipient accepted" is being added), in which case the following will be 
> added:
> 
> ---
> NOTE: It appears that one or more of your mailservers rejects E-mail to 
> domain literals if the return address is <> and there are multiple 
> recipients.  The RFCs say that mailservers are required to accept E-mail 
> to the abuse@ account, and do not say that it is acceptable to block 
> E-mail from <> with multiple recipients.  Although it is unlikely this 
> will prevent legitimate E-mail from being blocked, it does prevent 
> testing tools from detecting that your mailserver accepts E-mail to 
> domain literals (the only way we can work around this is by making 
> multiple partial E-mail attempts, which could trigger anti-spam software).

Interesting.  My MTA didn't trigger that response, in any event.

> >    >>> RCPT TO:<postmaster@[198.144.195.186]>
> >    <<< 550 Only one recipient accepted for NULL sender.
> 
> FYI, so you know, it is impossible to accurately distinguish that 
> response from "550 Recipient does not exist".  A 550 response is a 550 
> response is a 550 response, per the RFCs.  :)

Sure.  As with the "Open relay test" anomaly, my point was solely that
that, if your postmaster@ test either weren't part of a test using 
NULL as sender, or didn't specify multiple recipients, it wouldn't 
have generated that false positive.  (Maybe you could have a pair of
mail probes to postmaster@ and abuse@, with "MAIL FROM:
postmaster at dnsreport.com"?  I doubt that would trigger anti-spam
software, but happily defer to your experience if I'm wrong on that.)

Not a big thing.  I'm just such a fan of your CGI, I'd like to help it
become even better.  ;->

> >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.
> 
> Actually, that isn't true.  I believe the de-facto standard back in
> the 1990s was 2 days.  But in my experience, few mailservers will
> re-try more than 1 day.  And some won't even re-try a single time, and
> will bounce the message immediately.

The canonical examples of "won't even retry a single time" would probably
be desktop applications that attempt outbound SMTP on their own and 
certain MUAs that aspire do more than stub-MTA handoffs to a nearby
smarthost.

Regarding one day:  Interesting.  Thanks.  Four days was what I
remembered as the sendmail default, and is what my sendmail-geek friends
tell me is still the default timeout for that MTA.  

In any event, I wouldn't not rely on four days -- or one day, either.  I
figure anyone who cannot bring online (or have a friend deploy as a
favour) a replacement MTA in four _hours_ somewhere in the world has no
business calling himself a sysadmin.  ;->

Also, I have a couple of friends on speed-dial who are willing to do
temporary MX (spooling up my mail for a day) on no notice at all, so 
the retry period need only be about a minute longer than that telephone
call and my zonefile refresh.

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