Re: Value of backup MX
On Wed, Nov 10, 2004 at 02:10:18PM -0500, Robert Brockway wrote:
> On Wed, 10 Nov 2004, Craig Sanders wrote:
>
> > backup MX is obsolete these days, very few people need it (most of
>
> This does seem to be a prevailing opinion but I think backup MXs are
> valuable now for the same reason they always were - outages happen. We
> have no way of knowing how long a remote MTA will continue attempting to
> resend, even if it is following the rules of SMTP. I do not want to lose
> mail because a remote admin can't afford to hold mail for very long
> (assuming a major issue like a hardware fault).
>
> I do fully support the idea of the backup MXs having the same anti-spam
> capabilities as the primary (rsync over ssh can do wonders)
if you have full administrative control over your own backup MX, *AND* if you
maintain the list of valid relay recipients, then it is perfectly OK to have a
backup MX.
you probably won't benefit from it anywhere near as much as you think you will
(and it will be constantly bombarded by spammers), but it won't cause any
problems for anyone else.
> Peered MXs (eg, 2 x MX 10) and dynamic backups which don't just queue mail
> but continue to deliver when the primary is down are even better.
that's not backup MX, that's load-balancing. a different kettle of fish. in
order to work at all, they *MUST* have a list of valid recipients. again, not
a problem AND, unlike backup MX, you will get significant benefits from running
a load-balanced mail setup if you have the mail volume to warrant it.
> > those who *think* they do are just running on ancient & obsolete
> > gossip/"common sense" from the days when backup MXes were useful).
> > almost all mail these days is delivered by SMTP, and all real SMTP
>
> MXs are hardly useful for mail that is not travelling over SMTP :)
true. however, very little mail travels over alternative transports these
days. except for a few weirdoes like myself who set up uucp over tcp instead
of the brain-damaged kludge of multi-drop POP mailboxes, almost nobody does
anything but SMTP.
and in any case, when using uucp, you generally don't set up the uucp host as a
secondary MX. you set it up as the primary MX, and give it a transport table
entry to route mail for the destination domain via uucp.
> > servers(*) will retry delivery. this works perfectly well without a
> > backup MX, and in fact works BETTER without a backup MX.
>
> How does it work _better_ without a backup MX?
1. it's not clogged up with undeliverable spam bounces
2. it's not clogged up with backscatter
3. the original sender (or their sysadmin) can tell that their mail hasn't been
delivered yet, instead of wondering why they haven't got a reply to their
important mail that has been waiting in a queue on the backup MX for 3+ days.
> > if you do have a backup MX, then you need to have the same anti-spam
> > & anti-virus rules as on your primary server AND (most important!) it
>
> I agree with this (as noted above)
>
> > needs to have a list of valid recipients, so that it can 5xx reject
> > mail for unknown users rather than accept and bounce them (known as
>
> I disagree with this. I'd sooner not have a backup than use this
> strategy. Sounds like a good way to lose new customers.
a list of valid relay recipients is essential.
without it, you generate vast quantities of backscatter. if you do that, you
are contributing to the spam & virus problem.
sooner or later, someone will get pissed off enough by backscatter to create a
backscatter DNSRBL that lists sites which generate large amounts of backscatter
(and sites that send out those annoying bogus virus notifications from their AV
scanners).
as with open-relay and open-proxy and spam-source DNSRBLs, this can only be a
good thing because it will force lazy and ignorant system admins to do the
Right Thing if they want their legit mail to be delivered.
> > btw, backscatter also causes problems for you and your server. many
> > of the spam/virus bounces are from undeliverable return addresses,
> > so they end up clogging your mail queue for days and slowing the
> > entire system down.
>
> Only if the queue is really huge, honestly.
yes, and this happens in very short time.
craig
--
craig sanders <cas@taz.net.au> (part time cyborg)
Reply to: