[Top] [All Lists]

Re: [ietf-smtp] DSNs

2020-04-26 10:24:32
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

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.



Dave Crocker
Brandenburg InternetWorking

ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>