Ales, Keith:
Thanks for your comments.
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. Routing problems in the senders' network would indeed cause
the backup MX to behave rude, but then the sender should fix his faulty
network. 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.)
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.
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
just a warning ("primary is online") or, in a very softhearted manner,
accepting the message but marking it as possible spam.
Thanks for your thoughts.
Evert
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp