--On Sunday, April 26, 2020 12:31 +0200 Arnt Gulbrandsen
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.
ietf-smtp mailing list