Frank Ellermann wrote:
Keith Moore wrote:
you're assuming lots of conditions there that don't apply
in the general case...
The cases involving MX queries are not unusual, a good part
of 2821bis explains how this works. MTAs know if they are
an inbound "border MTA" or not depending on the client.
e.g. single-hop internal routing for inbound mail and yet
the MTA can't detect that the mail is nondeliverable until
after it has accepted it
If it has no SPF PASS or a similar indication that sending
an NDR "to the originator of the undeliverable mail (as
indicated by the reverse-path)" should work it is forced to
violate a MUST in 2821 or 2821bis. NDRs are not OPTIONAL.
nobody is expected to pay any attention to SPF as a matter of compliance
with 2821. SPF is pretty much a joke.
one way to look at it is that the border for inbound mail
may be different than the border for outbound mail.
Most likely it is, but the admins are supposed to know what
their outbound MTAs can do. If they can't send NDRs to XXX
they better don't accept mail from XXX, otherwise they run
into problems with the MUST.
yes, but "can't send NDRs to XXX" is not the same thing as only having
an IPv6 path. because any sane mail admin will know that having a way
to deliver mail via IPv4 (and for that matter, to accept mail via IPv4)
is a practical necessity.
often, the inbound MTA for a domain lacks reliable knowledge
of whether either the sender or recipient address is actually
valid. it appears that you would have the inbound MTA drop
mail based on a very dubious presumption.
NAK, I think it should REJECT mail if it has no clue what to
do with it if all else fails. Your proposal, accept and pray,
could result in dropped mails silently vanishing in /dev/null,
or what is known as "misdirected bounces".
yes, it could. but the particular case you are arguing is specious.
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf