🚀 go-pugleaf

In article <1991Jan4.182308.16683@hq.demos.su> avg@hq.demos.su (Vadim Antonov) writes:
>
>I think it may be reasonable to allow users to suppress long automatic
>replys (if you're keeping the copy of the message on your machine
>you need not to see its header, don't you?). It could be done using
>something like:
>
>	X-Report: brief
>	Return-Receipt-To: author@foo.bar
>
>Hm. I'm worrying why this very simple and clear scheme was not introduced
>from the wery beginning. Net gurus, where are you?
>
>I want to hear opinions of netlanders about turning it into the
>standard way of error processing. I wanna be sure my e-mail will not
>disappear in this infinite maze of wires.
>
>Cheers,
>
>Vadim Antonov
>DEMOS, Moscow, USSR


Sounds reasonable to me, therefore I would like to see it become a reality.
Basicly, it would be like the US Postal Service's certified mail. Good idea!
Now it is just a matter of getting those who can to add the service. 


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dale A. Harris          Chaotically Yours, 
rodmur@ecst.csuchico.edu  __     __   _    ,
{Internet}               /  )   /  ) ' )  /
                        /  /   /--/   /--/
                       /__/ o /  ( o /  ( o

                        =
Let A be a subset of U. A = A. "The double complement of A,
       is like getting no complement at all", S. Moskowitz

In article <1991Jan4.182308.16683@hq.demos.su> avg@hq.demos.su (Vadim Antonov) writes:
>IMHO the current autobounce scheme needs some improvements allowing
>user mail programs to understand a report about receiption of the message
>automatically.

Agreed.

>I suggest to introduce a couple of new obligatory header fields and
>to manage *all* mail delivery systems to generate it.
>
>The first is:
>
>	Receipt-Rejected: <message-id>
>or
>	Receipt-Rejected: <message-id> retry
>

[... to notify the sender that a message delivery failed ...]

>The second proposed field
>
>	Receipt-Confirmed: <message-id>
>
[ ... as confirmation of delivery when the sender asks for it with 
  the Return-receipt-to: header ... ]

>Hm. I'm worrying why this very simple and clear scheme was not introduced
>from the wery beginning. Net gurus, where are you?

Well, I cannot speak to why this scheme was not implemented from the
beginning (I haven't been around that long), but there are a few problems 
with the scheme as you propose it:

1.  The most obvious is that a message can have multiple recipients, with
    various destinations all over the net.  So a single message sent to
    several recipients might result in several (possibly conflicting)
    delivery reports, all with the same <message-id>.

2.  A second problem has to do with the interaction of headers such as
    Return-receipt-to: and mailing lists.  Since the Return-receipt-to
    header is nonstandard (it is a sendmail "feature"), its interaction
    with mailing lists is not defined.  Sending a message to a mailing
    list with a Return-receipt-to: header attached can result in thousands
    of delivery confirmations sent to the given address, which is probably
    not desirable in general even if that's what the sender intended.

    There's also a bug in (some versions of) sendmail that will generate
    a report in response to a return-receipt-to: header *every* time a 
    delivery attempt fails -- even if it fails in such a way that delivery 
    is retried later, when *another* return-receipt is generated... If
    enough versions of sendmail are broken in this way, perhaps the header
    should be called something else (Confirm-delivery-to: ?) if implemented.

3.  Similar to the mailing-list-expansion problem has to do with the
    handling of such headers when forwarding messages across gateways 
    to other message systems that support delivery reporting.  In the 
    case of return-receipt-to:, the gateways have to know to translate 
    the delivery reporting addresses so that they are still meaningful 
    to the destination message systems (so that they can send the 
    delivery report in the first place).

    One problem with existing human-readable delivery reports is that 
    they are not very meaningful if the message has been forwarded to 
    a foreign network, or if the address points to a system that doesn't 
    understand RFC822.  For example: suppose you sent a message to 
    moore@cs.utk.edu and asked for delivery confirmation.  If I happened 
    to have my mail forwarded to a different address,  for example: 
    pa111718@utkvm1.utk.edu, then you might well get back a notice confirming 
    delivery to that address, but it would mean nothing to you.  At one time, 
    if you sent a message to moore@vms1.engr.utk.edu, you might get back a 
    message of the form:  "No user named MOORE at node UTKEN1", since 
    vms1.engr.utk.edu was actually a DECnet node with no connection to
    the Internet.

Problem (1) can be solved by changing the format of the delivery report
header slightly so that it includes the envelope recipient address that
caused the failure.  Something like:

Delivery-report: message <AA910102@cs.utk.edu> rcpt <joe@cs.utk.edu> 
	status failed (No such user)
Delivery-report: message <AA910102@cs.utk.edu> rcpt <moore@cs.utk.edu>
	status succeeded
Delivery-report: message <AA910102@cs.utk.edu> rcpt <pig@cs.utk.edu>
	status deferred (Exceeded disk quota)

I'm not sure it's a good idea to report "temporary failures" -- if the
recipient's mailer recognizes the problem as temporary, it should 
retry delivery for a reasonable amount of time before bouncing the
message instead of having the sender's mailer do the retry --
for one thing, the recipient's mailer has a much better idea of when
it should "give up" -- some failures are more transient than others.
On the other hand, reporting temporary failures *once* lets the sender
know immediately that the recipient did not receive the message right
away.

Problem (2) requires that the behavior of delivery reports to mailing lists 
also be defined.  Probably you want to specify that the list expander sends 
the delivery report (saying, in effect, that the "list" received the message
regardless of whether the message was delivered to all of its members),
but at any rate, the request for delivery reports must be removed before 
forwarding the message to the list.

Solving problem (3) would require that all MTAs keep track of mail 
forwarding and list expansion for each recipient, so that the error 
messages generated by the recipient's MTA would be meaningful in the 
context of the sender.  The gateways also have to translate the 
addresses to which error reports are sent.  Ideally, the information 
would be passed in the *envelope*, not the header.  Either way, these 
are nontrivial changes that have to be applied to nearly every MTA out 
there before you can reliably use the feature.  The most likely way for 
this to happen is for everybody to adopt X.400, but I'm not holding my 
breath.

Even if problem (3) is not solved, it would still be useful to have this
feature.  However, in my experience most of the problems with the usual
"mail bouncing" mechanism result from internetwork mail gateways.  For
messages that stay within a single mail system, the native error reporting 
mechanism is usually adequate.

And as for mail forwarding, list expansion, and internetwork gatewaying:
these topics need to be addressed anyway.

Keith Moore / U.Tenn CS Dept / 107 Ayres Hall / Knoxville TN  37996-1301
Internet: moore@cs.utk.edu      BITNET: moore@utkvx
``Paranoia is a drug which is more dangerous than any controlled substance.''