avg@hq.demos.su (Vadim Antonov) (01/05/91)
IMHO the current autobounce scheme needs some improvements allowing user mail programs to understand a report about receiption of the message automatically. 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 The first form informs the sender that the message is illegal (say mistyped address etc). The second form suggests the originator to retry posting (say 'cause of a disk crash etc). The body of the autobounced message should contain the header and body of rejected message (probably with some debugging information). The second proposed field Receipt-Confirmed: <message-id> should be generated only if the original message has contained Return-Receipt-To: in its header and mail delivery service is sure that the message reached the destination (quite like a usual effect of Return-Receipt-To: ). 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
rodmur@ecst.csuchico.edu (Dale A. Harris) (01/05/91)
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
moore@betelgeuse.cs.utk.edu (Keith Moore) (01/05/91)
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.''