Re: Last Call: draft-klensin-rfc2821bis

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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf