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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp