Re: [ietf-smtp] DSNs

[John C Klensin <[e-mail]>]

--On Sunday, April 26, 2020 12:31 +0200 Arnt Gulbrandsen
<[e-mail]> 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.

   john