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.
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.
It would also affect users starting an RFC 3834 mailbot, the
envelope sender address is supposed to work for auto-replies.
And when it works this should be the originator, but 2821bis
does not try to solve that closely related problem.
Similar for all other RFCs using the envelope sender address,
DSNs, MDNs, etc. (I'm not up to date with Lemonade and Sieve,
but e.g. the Sieve vacation I-D or RFC is based on RFC 3834)
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".
you would rather cause additional delivery failures of subject
messages than to risk the failure of nondelivery reports.
For legit mail rejected at the border the sender then at least
knows that the mail bounced, and "can make another plan", as
EAI nicely put it. Dropped legit mail "accepted on probation"
are a black hole from the sender's POV, that's bad.
For what we are discussing here we can ignore all details of
misdirected vs. good bounces, the assumption was that an IPv4
MRN cannot reach the IPv6 MON. Even an SPF PASS cannot help
in this case, it is an IP problem "below" SMTP.
most operators, I think, would have the opposite preference.
Operators still thinking that "accept on probation" is a good
strategy somehow missed Y2K and that 90% of mails are spam.
Or they always considered NDRs as OPTIONAL, but then they are
not reading RFC 2821 or 2821bis.
regardless of what 2821 says, I don't think your reading of
it is justified.
Well, I don't think NDRs are OPTIONAL, and I want to get NDRs
if legit mail from me does not make it. If that's unjustified
what is ? Publishing 2821bis as experimental is no option :-)
My definition of IPv4-only is that there is no other route.
that's a pretty useless definition because the case would
not exist in practice until IPv6 were ubiquitous.
Bill's IPv6-only AAAA example.com triggered the discussion, he
expressly wanted no MX, there is no IPv4 MTA accepting NDRs or
other replies to any(_at_)example(_dot_)com address.
there's always the possibility for an IPv6-only domain to
contract with an MTA sited on both v4 and v6 to relay
outgoing mail. it would be insane for an IPv6-only domain
that wanted to send and receive mail to not have such an
arrangement.
Insane or not, it's what Bill wanted. Likewise IPv4 receivers
could try to add IPv6 to their network, but the interesting
scenario is where that's not the case.
if we were to take your presumption to its logical conclusion,
every inbound MTA should just reject all mail - since it can
never be 100% certain of being able to either deliver the
message or send an NDN.
It needs to be confident that it can do what the MUST in 2821bis
says. 100% certain is too harsh, but 2821bis has clear ideas
about "frivolous":
| it is accepting responsibility for delivering or relaying the
| message. It must take this responsibility seriously. It
| MUST NOT lose the message for frivolous reasons, such as
| because the host later crashes or because of a predictable
| resource shortage.
Or because IPv4-only to IPv6-only cannot work to report errors.
Frank
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf