From: NED@SIGURD.INNOSOFT.COM (Ned Freed)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: RE: mail problem
Date: Mon, 25 Jan 1993 18:44:05 -0700 (PDT)
Organization: Info-Multinet<==>Vmsnet.Networks.Tcp-Ip.Multinet Gateway
X-Gateway-Source-Info: Mailing List

> The point of such notification messages has never been clear to me.  After
> all, even if I know that my message is queued for delivery somewhere in the
> Australian Outback, there's not a whole lot I can do about it.  So, why
> waste time and resources sending a message with essentially useless
> information?  If the host is reachable, your message will be delivered.  If
> it's not, what's the point of the notification?

Counterexamples taken from real-world cases and uses of email and FAX:

(1) Notes about reservations on planes, trains, reunions, dates, etc. It helps
    a lot to know when one of these is delayed beyond a reasonable amount of
    time.

(2) Stock quotes -- they aren't applicable if delayed.

(3) Weather reports and predictions.

Now, you can make a case for not sending this sort of stuff via email, and you
can make a case for using explicit expiration dates instead of nondelivery
notifications, but the fact remains that people do use email for this sort of
stuff and rightly or wrongly they depend on temporary nondelivery notifications
to tell them when things are messed up. You may not use mail this way, I may
not use mail this way, but believe me there are lots of people who do, and
they're probably the majority.

> (Things are even worse when ill-formed or mishandled headers cause a
> gateway to send the "not sent yet, still trying" messages to a mailing list
> for redistribution, but never mind that for now.)

Different problem; completely solvable, but a different problem nevertheless.

> The question is related to another old favorite, "How can I be notified
> that my message has been read?"  The answer is, you can't.  At the very
> most, you can be notified that the destination MUA has done something (but
> you can't be sure what) with the message.

I'm not sure how this relates in any way to the topic at hand. A delay in
delivery is a delay in delivery; in most cases an agent knows for sure whether
or not it was able to discharge its responsibility for the message. The various
protocols we use for mail are designed to make sure it is possible to do this
cleanly (not as cleanly as I'd like -- there's a case to be made for two-phase
commit mechanisms in mail, but overall we're less concerned about duplication
than with loss). But read-receipts depend on some sort of computer-human
protocol. To put it mildly, these are not subject to standardization (!) and
therefore are always totally unreliable.

The only thing that's unreliable about nondelivery notices is the inconsistency
of their generation. However, users adapt amazingly quickly to the nature of
the systems they use, so they usually take these differences in stride.

A read-receipt is, at best, a notice that the recipient claims to have read the
message. A temporary nondelivery notice is a fairly confident assertion that a
message has been delayed. They both have problems, but the nature of their
problems are completely different.

				Ned