I speculated that a backup MX would be placed on another network, so
many of the NAT / routing problems would result in the backup MX also
not able to contact the primary MX. That would then "activate" the backup
MX.
I don't think life is that easy. A can reach MX2, MX2 can reach MX1, does
not mean A can reach MX1. The link between MX1 and MX2 may be accepting only
"local" traffic (think east coast to west coast but not intercontinental),
and not route A's traffic. If the link between A and MX1 is disrupted, for
whichever reason, it's traffic does not reach MX1
Ofcourse the Internet is way more complex than this simple triangle I just
depicted, but I think it proves my point.
Routing problems in the senders' network would indeed cause
the backup MX to behave rude, but then the sender should fix his faulty
network.
Another assumption I do not agree with. The problem may very well be in an
intermediate network, peering agreements, and so on. It's not the fault of
A, MX1 or MX2, neither can fix it. Then what?
In fact, the backup MX giving an error that the primary MX is
reachable from the backup MX could help detect routing problems. (This
all assumes network seperation between the primary and the backup MX.)
That I'd consider to be feature creep.
Note, though, that I agree that routing problems could cause problems
and that the backup MX is a great tool to have an alternate means of
delivery. But nowadays many organisations just give up the backup MX
because of spam, so something must be done.
To 'prove' that A can reach MX2 and not MX1, even if MX2 can reach MX1, you
would need to cooperation of A. Spammers won't cooperate, so you would need
to rely on trustworthy hosts near A, on the same network or at least using
the same peering.
Maybe the biggest mail providers can do that, but that's about it.
Maybe the idea could still be useful when some restrictions on its use
are introduced? Like MX network seperation and maybe a retry period or
mailhosts on the same network should, IMHO, just use a failover
configuration and appear to the rest of the Internet as one single MX.
Probably as part of a load balancer.
just a warning ("primary is online") or, in a very softhearted manner,
accepting the message but marking it as possible spam.
Combined with some bayesian logic perhaps. No need to mark all mail from MX2
as spam if little to no mail comes via MX1.
my 2 cents again
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp