Backup MXes

Wed Nov 16 11:08:42 PST 2005

On Wed, Nov 16, 2005 at 10:34:18AM -0800, Rick Moen wrote:
[A handful of things, with most of which I am in "violent agreement." :-}]
>...

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

Although in practice, that it what I end up doing I wouldn't state it
quite that way.

Rather, just as a sewer line needs to flow into a line that does
not have a smaller diameter, the anti-spam measures must merely not
become stricter as the mail passes from one relay to another.

The simile is chosen purposefully.  :-}

> For one thing, ....

In my case, the MX would probably be provided by a colleague, and since
I know that my anti-spam rules fluctuate very rapidly, it's highly
unlikely that the anti-spam rules at the MX would meet the above test.
And my MX would probably reject at bunch of the spam, thus leaving the
higher-numbered MX "holding the bag," so to speak -- which is not how
I'd like to treat someone who's doing a favor for me.

[Note:  in case it's not clear, all of my anti-spam measures are
performed during the SMTP conversation, by my MTA.  The choices are:
accept; silently discard; reject (either permanently or temporarily).]

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

That does, howevber, "assume" (ahem!) a "well-behaved" SMTP client.
Then again, if the SMTP client is sufficiently ill-behaved as to lose
mail in such a circumstance, whose problem is that?  Probably the
administrator of the client; probably the user of the client.  But the
administrator of the server?  Maybe, but if I were forced to decide one
way or the other, I'd select "not" for that case.

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

I have been known to implement a variation on that theme: Have a backup
MX all right, properly advertised, but as long as the primary is
functioning, have the backup MX not listen to 25/tcp at all, so spammers
get "connection refused."

Now, if the objective were to capture spam, a variant might be to
advertise a higher-numbered MX, and as long as the primary MX is
working OK, accept the mail, but rather than deliver it as addressed,
assume that it's spam....  After all, no legitimate SMTP client has
any business sending mail to the higher-numbered MX unless the
lower-numbered MX fails to respond.

Peace,
david
-- 
David H. Wolfskill				david at catwhisker.org
Prediction is difficult, especially if it involves the future. -- Niels Bohr

See http://www.catwhisker.org/~david/publickey.gpg for public key.