Re: [ietf-smtp] DSNs

[Ned Freed <[e-mail]>]

> 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.

And IME almost never work. NOTIFY=SUCCESS, on the other hand...

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

>    Specification + Software + Deployment + Operations + Use

Depending on how you define the ends, both DSN in general and NOTIFY=SUCCESS 
in particular meet handily.

> 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.)

All this 10,000 feet stuff is starting to make my head spin. Let's please
focus on the specific issue that's been identified here, which is that
sites are turning off the DSN extension entirely on ingress systems because
they believe they have to in order to comply with the specification.

So how do we address this issue? Well, we can:

(0) Move the entire DSN specification to historic.

(1) Revise DSN saying it should only be used within an ADMD.

(2) Same as (1), but only the NOTIFY=SUCCESS part.

(3) Revise the DSN specification and eliminate NOTIFY=SUCCESS.

(4) Change the specification to make it clear you can reject NOTIFY=SUCCESS,
    and specify a status code for that purpose. (This could be done in a
    follow-on document.)

(5) In addition to (4), deprecate NOTIFY=SUCCESS.

(6) In addition to (4), add some sort of indicator to EHLO that NOTIFY=SUCCESS
    will be rejected.

(7) Do nothing.

> 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.

Even if we believe that removal is warranted or even necessary, the devil is
always in the details. Those details are what concern me, not whether or not
making changes is justified by an overarching standards development philosophy.

				Ned