On Sun, Apr 26, 2020 at 11:26:09AM -0700, Ned Freed wrote:
So how do we address this issue? Well, we can:
(0) Move the entire DSN specification to historic.
I don't believe that's warranted.
(1) Revise DSN saying it should only be used within an ADMD.
Though I usually give that advice informally, SHOULD would IMHO be too
strong, I think this is closer to MAY, i.e. something along the lines of
(non-normative lower case):
operators should consider whether limiting the use of DSN to just
inside their ADMD is appropriate for them.
(2) Same as (1), but only the NOTIFY=SUCCESS part.
(3) Revise the DSN specification and eliminate NOTIFY=SUCCESS.
There is no interoperable way to do that without introducing a new ESMTP
extension keyword, along the lines of:
250-DSNNG NEVER FAILURE DELAY
with the old "DSN" retaining its original meaning:
DSN == DSNNG NEVER SUCCESS DELAY FAILURE
(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.)
No, that's broken. Existing MTAs won't know about the shiny new DSN
semantics and will bounce the message,
(5) In addition to (4), deprecate NOTIFY=SUCCESS.
Though "DSNNG" could be defined without SUCCESS, while the utility of
SUCCESS is limited, and we should recommend that it not be turned on
"DSNNG" by default, I think that SUCCESS should be retained, for cases
(say within an ADMD) where it can be useful.
(6) In addition to (4), add some sort of indicator to EHLO that NOTIFY=SUCCESS
will be rejected.
This too is broken, but would be addressed with a "DSNNG".
(7) Do nothing.
This is also an option, with the only downside being that when chooses
to neither offer nor consume DSN SUCCESS across ADMD boundarie, one also
loses the other options.
--
Viktor.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp