Re: [ietf-smtp] DSNs

[Viktor Dukhovni <[e-mail]>]

On Sat, Apr 25, 2020 at 07:56:56AM -0700, Dave Crocker wrote:

> On 4/25/2020 6:01 AM, Ned Freed wrote:
> > Aside from implementation errors, I've seen no operational problems with DSNs,
> > only with the DSN extension. The problem there is that some people have
> > claimed that since NOTIFY=SUCCESS is a part of the base and they don't want to
> > do it the only alternative is to disable the entire extension. I disagree; I
> > think that since security concerns are paramount it's perfectly OK to simply
> > reject NOTIFY=SUCCESS on security grounds.
> 
> Perhaps this goes to the challenge of a specification's distinguishing 
> its essential core, versus desired-but-not-required enhancements.
> 
> Fail to support all of the core and it's not valid to claim to support 
> the specification.
> 
> The danger of a pick-and-choose free-for-all is that a claim to support 
> a specification provides little useful information.

I'm very much with Dave on this one.  If you're not offering
NOTIFY=SUCCESS, then you're not offering DSN.  Pretending to support it,
but then not offering it is breakage.  On the other hand, since I ignore
"DSN" on the outbound leg, I avoid running into any problems should the
remote side misrepresent its behaviour.

There is no mechanism to offer a fine-grained subset of the DSN ESMTP
extension, so I turn it off entirely.  The only one I'd be comfortable
in offering to outsiders would be "NEVER", but the ability to avoid
some rare bounces is not that compelling.

Thus, for example, I also only send delay notices for outbound mail from
inside, but not for inbound mail from outside.

-- 
    Viktor.