Re: [ietf-smtp] DSNs

On 4/25/2020 3:41 PM, John C Klensin wrote:
> --On Saturday, April 25, 2020 14:46 -0700 Dave Crocker
> <dhc(_at_)dcrocker(_dot_)net> wrote:
>
> > ...
> > First, I meant whether the feature worked, for whatever
> > reason.  If operational policy prohibits its use, then it
> > doesn't work.
> Dave, I think this is where either your comments are still not
> clear (at least to me) or we disagree.
>
> Suppose there were correspondents, or even domains, for which I
> have found read receipts useful and something I'm willing to let
> them use.  So, because of them, I advertise the availability of
> that feature in the EHLO response. 
You think that advertising something through an EHLO response produces a 
communication of that support back to one or another author?
For that matter, you think that advertising anything, downstream and as 
part of a real-time infrastructure transaction, affects later 
origination behavior?
Also, MDN isn't an SMTP option.(*)  It's a user-level feature, unlike 
DSN.  It's independence of the transport service is why it's usable; the 
requirement for protocol support of DSN requests at every SMTP hop is 
why it has such poor -- in my experience, non-existence -- utility.

> When the MAIL command comes
> along and doesn't contain that domain or mailbox, I reject the
> request. 
Sorry, I'm not parsing this sentence meaningfully. I don't understand 
what specific actions or references you are making in this sentence, nor 
why a rejection by the receiving server is produced.

>    Now, which mailboxes or domains to accept is an
You seem to be saying that advertising DSN support affects which domains 
mail is accepted from, by the receiving server. (You also don't indicate 
which identifier field is to be used for this accept/reject evaluation.)
....

> Your statement above (at least as I interpreted it) would
> clearly be true (and the feature not workable for policy
> reasons) if operational policies were consistent all across the
> Internet, probably including uses of SMTP over VPNs or SDNs, and
> those policies never allowed the feature to be used, but
> counterexamples  have already been given to any possible
> assertion about the policy condition is globally true.

Let's try a different approach...

Success for any bit of end-to-end functionality requires:

  Specification + Software + Deployment + Operations + Use

If any one of these do not happen, the functionality fails.  If there is 
a long-term demonstration of failure, the functionality is deprecated as 
a matter of pragmatics.  Broadly any effort/expense to support it is 
therefore wasted.  (Obviously, if there are pockets of end-to-end 
support and those pockets matter to the Internet community, then it 
hasn't failed; my comments concern 'general' failure.)
My comment was meant to note that, in general terms, such a long-term 
demonstration of failure for a feature warrants removing it from the 
specification. This a) makes the spec cleaner, b) clarifies to the 
community that the feature isn't supported, c) saves time/money.
d/



(*) 
https://www.iana.org/assignments/mail-parameters/mail-parameters.xhtml#mail-parameters-2

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp