Re: [ietf-smtp] DSNs

John C Klensin <> Sun, 26 April 2020 15:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 77D783A0885 for <>; Sun, 26 Apr 2020 08:13:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cnp_vgPTswOn for <>; Sun, 26 Apr 2020 08:13:20 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 644E13A0884 for <>; Sun, 26 Apr 2020 08:13:20 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1jSiy5-000J95-Kr; Sun, 26 Apr 2020 11:13:17 -0400
Date: Sun, 26 Apr 2020 11:13:11 -0400
From: John C Klensin <>
To: Arnt Gulbrandsen <>,
Message-ID: <04F588DCA6B646C83CA1840E@PSB>
In-Reply-To: <>
References: <20200409230011.F039B17637D0@ary.qy> <alpine.OSX.2.22.407.2004091945050.80689@ary.qy> <> <> <r7fq4k$1nm5$> <C1A5FAAA942E0F363CA177C0@PSB> <> <> <> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
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: Sun, 26 Apr 2020 15:13:21 -0000

--On Sunday, April 26, 2020 12:31 +0200 Arnt Gulbrandsen
<> wrote:

> On Saturday 25 April 2020 23:15:23 CEST, Ned Freed wrote:
>> Completely inapplicable in this case, I'm afraid. One of the 
>> primary goals of
>> the NOTARY effort, if not the primary goal, was feature
>> parity with X.400. And the operational model for X.400 was
>> success receipts as the default.
>> So the feature had to be part of the core. 
>> But thinkgs change. X.400 collapsed - a casualty of even more
>> serious design errors than success DSNs. Spam became email's
>> biggest problem, which made NOTIFY=SUCCESS less desirable.
>> Privacy concerns also arose that weren't even on the radar at
>> the time this work was done.
> X.400 collapsed, other things appeared. Delivery and display
> receipts appear to be popular features of some human-to-human
> instant messaging systems nowadays — I've heard that Signal
> added that precisely because it was popular with Telegram
> users. That's a rumour, but that both have delivery receipts
> is a fact.
> I've no idea what the problems with notify=success are
> considered to be, so I don't know whether
> Signal/Telegram/Threema/… have equivalent problems, or
> whehter the problems relate to some aspect of the
> implementation that is not shared by those IM implementations.
> I'd love to know.

On the differences (not an aspect of the implementation but of
the design) between email and most IM systems (I'm not familiar
with the details of those three) is that SMTP is designed to
work reliably through relays and with systems at the endpoints
that are independent of each other.  Most of the IM systems I've
seen either assume a direct connection between the originating
and destination hosts or require that the entire path between
sender and receiver be under the control of a single provider
entity.   That makes a lot of things easier including that
provider's being able to authenticate and validate the sender
and receiver to the extent it considers necessary.