--On Sunday, February 24, 2013 02:46 +0000 John Levine
<johnl(_at_)taugh(_dot_)com> wrote:
# Reject messages on backup mail exchangers when primary MX is
# online
On today's Internet, are backup MXes still useful? Any decent
mail client should retry for at least a couple of days, and
it's been a very long time since my main MX was down for
longer than that.
For a busy mail system, multiple mail hosts at the same
priority make plenty of sense, but a backup that accepts the
mail, then redelivers it to one of the main hosts later?
Really?
I'm glad you live in such a nice world. I've still got
correspondents in out of the way places for whom the "backup"
(really just "less preferred") MX hosts are routinely reachable
and getting to the primary ("most preferred") host routinely is
not. Many of the long-delay ("interplanetary") setups with
direct transmission windows of only a few minutes or hours a day
work in exactly the same way.
I also periodically use a network setup in which my secondary
mail system has a back channel (not dependent on SMTP over the
public Internet) to the primary one so that, if the primary WAN
connection is down, the messages get to the secondary system and
then to the primary one in close to real time, not after a delay
of potentially several days. That is a problem with your
analysis even if one ignores the intermittently-connected
location problem: it assumes that waiting a few days to
_receive_ the mail is considered acceptable. As Ned and Keith
pointed out in different ways, this is all a matter of
configuration decisions (although it would be possible to
establish more general mechanisms for passing information along)
-- if it is important enough to receive the mail, one sets
things up that way, including with multiple ISP connections that
don't fate-share; if it is not, one doesn't.
And, fwiw, when that setup is running, the list and rules about
deliverable addresses (and other antispam information) are
updated on the secondary machine within a few hours of changes
on the primary one so that the rejects can actually be produced
on the secondary one. That isn't rocket science either and it
actually helps with the spam problem because the secondary
machine can take up some of the load if the primary is
overloaded. Whether it is worth the trouble or not depends on
configuration tradeoffs as well.
Coming back to the original note in this thread, I believe the
key comment is "The proper way to address this issue is to deny
the use of a backup MX when the primary MX is online." With the
understanding that the last clause should perhaps be "primary MX
is responsive", this is exactly what the standard requires
today, so, with the understanding that different senders may
have different visibility to the two (or more) servers (and the
servers may have visibility to each other (or not) when the
sender does or does not), nothing else is needed. Of course, it
would be a dumb idea to configure multiple MXs at the same
preference level if a "backup" setup rather than, e.g., a
load-sharing one, were intended but that is just another
configuration issue.
Against that backdrop and considering assorted race conditions
with network outages and congestion, the proposed "solution" is
not only unnecessary but a genuinely terrible idea, the latter
because it encourages legitimate senders to use long timeouts
while waiting for the primary system to respond which would be
ok except that we are seeing lots of servers trying to force
short timeouts to mitigate DoS attacks.
The problem with the original suggestion is that it assumes an
arrangement of systems and a configuration model that is just
one of many. Making the various other arrangements work worse,
or not at all, in order to get a marginal (and, IMO,
questionable) improvement for that one scenario would be, at
best, a bad optimization.
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp