Re: [ietf-smtp] DSNs

Ned Freed <> Sat, 25 April 2020 14:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA2233A10B9 for <>; Sat, 25 Apr 2020 07:50:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tomDY9xISssI for <>; Sat, 25 Apr 2020 07:50:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E1D8A3A10C0 for <>; Sat, 25 Apr 2020 07:49:59 -0700 (PDT)
Received: from by (PMDF V6.1-1 #35243) id <> for; Sat, 25 Apr 2020 07:44:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=201712; t=1587825895; bh=Vzj+Fyc36RMh2WVAHRdGHKJzCPube72LE2ipFbgzAb8=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=nPWHFpRK6bpOoTcYxIiGnm7mVzrZ5X5wi2cA1toeBczhMDGRdRJgw6GYRS92RA4mx 6gWT/46YdC0N8Ua+EfZiA0pOc60yI2cuTrHKl/0NX+xzsCV1HEFpMyeUL+LqU8XMWc wF1HDQ2DH/dqsV3s8U+wL/RKJnvg0iF7iW+eX+rI=
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from by (PMDF V6.1-1 #35243) id <>; Sat, 25 Apr 2020 07:44:53 -0700 (PDT)
Message-id: <>
Date: Sat, 25 Apr 2020 06:01:59 -0700 (PDT)
From: Ned Freed <>
In-reply-to: "Your message dated Fri, 24 Apr 2020 21:36:24 -0400" <>
References: <20200409230011.F039B17637D0@ary.qy> <alpine.OSX.2.22.407.2004091945050.80689@ary.qy> <> <> <r7fq4k$1nm5$> <C1A5FAAA942E0F363CA177C0@PSB> <>
To: Viktor Dukhovni <>
Archived-At: <>
Subject: Re: [ietf-smtp] DSNs
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 25 Apr 2020 14:50:02 -0000

> 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.

Getting something that meets the basic criteria for a DSN - correct MIME
structure - is not a problem. It's only when you actually go to parse the
things that problems can show up, Usually missing fields, but sometimes you'll
see bogus field values.

All of this appears to be shoddy implementation work, althopugh the one that
leaves the second part blank while including all the secord part information in
the first part goes a bit beyond "shoddy".

But such cases are rare, and in any case, none of this seems to have anything
to do with specification quality.

> > (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.

Log processing is actually a poor substitute for a bunch of reasons, not just
the obvious one that DSNs do come back from remote sites while logs, not so
much. Logs are problematic even within an ADMD because every implementation has
its own format. There are also potential security issues with transferring
entire logs around.

Dealing with a single, consistent format, even when there are some
implementation issues, is easier.

> > (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.

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. Regardless, there needs to be
language added saying that implementations MAY reject/ignore NOTIFY=SUCCESS,
and perhaps there needs to be a way for the extension to incidate that this is
going to happen.

> > (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.

The problem with this approach is that it breaks end-to-end features of
the extension like ENVID and ORCPT. ORCPT in particular is very useful.

>     * 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.

They also provide another means of creating blowback.

>     * 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.

Interesting idea to ignore the advertisement and return relayed. Nobody
has ever asked us for it, but legitimate use of NOTIFY=SUCCESS is rare.