Re: [ietf-smtp] DSNs

[Viktor Dukhovni <[e-mail]>]

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.