ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] DSNs

2020-04-24 20:36:45
On Sat, Apr 18, 2020 at 07:10:21PM -0400, John C Klensin wrote:

I meant that nobody sends positive DSNs.  You're right, we get
lots of DSN bounces.

But, fwiw, I occasionally (very rarely) request delivery and/or
read receipts and sometimes (especially for the former) get
responses and get them in DNS form.  It may not be common, but
terms like "nobody" are a little strong.

Indeed much too strong, because IIRC support NOTIFY=SUCCESS is on by
default in Postfix, and while I may make a point of turning it off
"at the edge", that's likely not a common practice, and so success
notifications likely work for a large fraction of internet-connected
MTAs.

(1) Are DSNs implemented broadly enough that it is reasonable to
claim that the spec is good enough to allow interoperability?

I don't recall seeing any reports of substantive DNS-interop issues on
the Postfix-users list in the almost ~20 years that I've been an active
participant.

(2) Have they been deployed sufficiently to demonstrate that
they are perceived of as useful by at least some of the people
some of the time.

I also believe that DSNs are useful at least between a sending
application to the edge MTA to acknowledge handoff from the sender's
edge MTA toto the remote organization's edge MTA.  Though similar data
can be collected by providing log excerpts to applications, sometimes
DSNs are easier to orchestrate.  That said, NOTIFY=SUCCESS is not
common.

(3) Have the specification or the feature proven sufficiently
problematic that we should be moving to deprecate RFC 3461
and/or the specifications that depend on it and/or update it?  I
haven't heard that argument yet.

I am not aware of any substantive defects.

(4) Are DNSs sufficiently problematic under various conditions
that have been observed in the current world that we would
recommend that at least some of them not be used -- and requests
for them either rejected or ignored -- unless they are
accompanied by some mechanism that allows verification of the
legitimacy of the requestor and request and/or that the reply is
actually a response to a request and requestor.

Here, I would personally recommend to others not advertising DSN on
receiving edge systems, and perhaps also ignoring its advertisement
by remote edge systems.

    * Inbound, I do not want to offer SUCCESS notices, they leak data
      I'd prefer to not leak.  Let the remote MTA send SUCCESS once
      I accept the message.  The rest is none of their business.

    * Outbound, I can give a timely notification to internal senders
      that the message was delivered to the responsible organisation.
      I prefer to not delegate them to them a duty I'm unwilling to
      fulfil inbound, or to trust that they'll carry it out.

-- 
    Viktor.

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>