Klensin@MIT-MULTICS.ARPA (John C Klensin) (09/24/86)
From a technical standpoint, I agree with Bob Austein's comment. We have enough problems already with overloading of the From and Sender fields to deliberately set ourselves up for another one. And two field names is probably better then one, since there are logically three separate confirmations that one might reasonably want to ask for: 1) Confirmation that one's local MTA had actually gotten the message off-system. (Confirm-Sent:?) 2) Confirmation that the MTA closest to the user had delivered the message to the user's mailbox (I assume that this is what you are talking about when you suggest "Confirm:Delivery"). 3) Confirmation that the user has actually received the message. Note that an MTA may have a little bit of difficulty figuring out whether it is the right agent (or when is the right time) to send the acknowledgement in "2". Given clusters, LANs, and mail servers for usually-disconnected machines, the notion of "delivery" can get a little abstract. The protocol used in BITNET/EARN/NETNORTH, for example, acknowledges delivery (to the next machine down the line) at each hop in the forwarding and storing enterprise. Now the hard problem.... At the risk of restarting a long and sometimes acrimonious discussion here, the confirm-receipt notion raises some quite complex privacy questions. It is not, a priori, reasonable that I (as a sender) should be able to force you to tell me when you are reading your mail. It is not, a priori, reasonable that I should be able to make you sign for a message that you wish to reject, rather that explicitly accepting. And many of the reasons for wanting a receipt-acknowledgement -- most of the reasons not accounted for by a confirmation that the network has done its job from Confirm-Delivery -- raise signature issues: you really want to know whether I've received it personally, whether a human agent has collected it for me and [probably] passed it on, or whether the work was done by an MTA that the system cannot identify (or thinks is a UA) and it has not gotten to me at all. For example, consider a computer that periodically logs into another one, collects mail from designated mailboxes, carries it somewhere else, and remails it: much the way that MAILNET works, but without the consent and participation of the MTA on the network-connected machine at the receiving end. Greater separation of envelopes and messages (vis X.400) will help somewhat with this, as there are somewhat fewer objections if one can accurately identify the sender and originator, and the fact that a receipt was requested, before deciding whether to accept delivery of the mail (and assuming that "receipt" is not confirmed on looking at the envelope, but only when looking at the message body). "Decide whether to accept delivery" is suggested here because the addressee can do at least two things with incoming mail -- read it or delete it and, if receipt confirmation is supported, there should be a third option, namely, have the UA send the message back unread and optionally annotated with the reason for rejection, without ever "opening the envelope". Note also that handling a "confirm receipt" facility correctly can place a heavy burden on some classes of UAs. Depending on the mechanism used for maintaining mailboxes, it may be very hard to avoid acknowledging receipt of a message every time it is looked at, at least without rewriting the message to eliminate or annotate the field. And such rewriting can violate security constraints about message-signature binding in many types of implementations. There is also the argument that it is undesirable to include fields that demand action on the part of the recipient that the latter's UA may just ignore without comment. And receipt confirmation is certainly an example of this: receipt confirmation has to be done by a UA; an MTA, by definition, does not have access to the right information. If I, as a user, decide that your sending me messages with receipt acknowledgement requested is antisocial, I can, in principle, modify my UA to ignore the field. That is behavior that you might reasonably consider antisocial, but, from my standpoint, that would just make us even. The only way to avoid this problem appears, in fact, to be to transfer the responsibility back to the MTA. Compare this to the Post. When a letter is sent to me without a request for a receipt confirmation, and the postal delivery person finds me not at home, the letter is simply left. Delivery can be confirmed, but receipt cannot. However (at least in the USA), if that letter arrives with a request for confirmation of receipt, what is left for me if I'm not there to "receive" and acknowledge it is a slip of paper -- acting as a surrogate for the envelope -- that tells me to come and pick the letter up and sign for it, an act equivalent to notifying me to explicitly request the message from the MTA under circumstances that the MTA's responding to the request can be accurately construed as my having actually received the message, rather than just having it delivered it to my doorstep. That still does not confirm that I have read it or paid any attention, of course. So: - Certainly in the third case (receipt confirmation) go slow, at least until you can demonstrate clear enough need to overwhelm the objections outlined above. - Before you add header fields of these types, please work out and discuss, very carefully, the semantics that you expect them to imply. Simply adding a field to the header by [partially] copying an X.400 field, or as a request that something be put into an X.400 field, is looking for trouble in our somewhat different environment. If the only reason for such a field is X.400 compatability, then an alternative solution to consider might be a series of fields named X400-xxx implying that they appear for X.400 compatability and interchange, but that they are expected to be ignored in RFC821/822 mail systems. If you will, they are instructions to X.400 <->RFC822 header-munging gateways, not instructions to MTAs on the RFC822 side.
cfe@andrew.cmu.edu (Craig F. Everhart) (10/15/86)
Suppose we were building a system where people could request delivery confirmation, and we believed that we had handled the ethical questions. Suppose we said that confirmation messages (of any of a desired set of stages in delivery) were to be sent to a given address. Naively, wouldn't that mean that one would get an awful lot of mail confirming delivery? My point is that the confirmation service should make it easy for the original sender's mail-handling agent to match the confirmation messages to the initial request, and that it's not (yet?) clear to me how this process can be automated. The most I can yet assume about confirmation messages so far is that they are composed with an In-Reply-To: header that matches the Message-ID: of the initial message. But this level of service, by itself, is inadequate, because a person replying to the message would generate a reply message that has exactly this same property. Did I miss some set of proposals that would explain how automatic confirmation might work? Or should I propose something? If the latter, here's a try: A goal of automatically-generated confirmation notices should be to allow mail-handling agents to keep track of the confirmed progress. Thus, if I initiate a piece of mail and ask for confirmation of a given phase of its delivery (say, ``In-Mailbox''), I'd expect that I'd later be able to ask my mail- handler about the status of the piece of mail--that of the N recipients, we had received confirmation from these K, and none yet for the remaining N-K of them. (Yes, we can imagine elaborations of this, where if confirmation lags for some recipients, the handler reminds me of the fact. Subsequent proposals might allow us to ask remote delivery or user agents whether mail was received and the confirmation message simply lost.) Let's say that I want confirmation of In-Mailbox state. My message might include the headers: From: mumble@bar To: a@b, c@d, e@f Confirm-In-Mailbox: mumble@bar Message-ID: <foo@bar> The automatically-generated confirmation from c@d might include the headers: From: c@d In-reply-to: <foo@bar> Confirmation-In-Mailbox: [token] where the [token] might be ``accepted'' or ``refused'' or some such. The body of the message might be optional human-readable text describing the reasons for refusal, should the refuser decide to offer any. The automatic handler of these things then scans incoming mail for header field names that start with ``Confirmation-'', matches the In-Reply-To: fields against the set of messages for which not all confirmations have been received, and matches the From: (/Sender:?) fields of the confirmation messages against the To: list of the original message. (This latter matching algorithm might be quite complicated, as it's not a trivial task, but it would reside solely in the mail-handler.)
Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA (10/19/86)
The problem of intelligent handling of confirmations can be split into two parts: (a) Formatting the text of the confirmation itself in such a manner that it can be recognized and handled by a computer program. You suggest an alternative for doing this in your message. (b) Programming your local user agent to use this to provide you with various features such as: - Getting yourself reminded if a message has not been delivered within a certain time interval. - Providing you with a summary of the delivery-status of a multi- recipient message when you ask for it, or automatically at a certain future date. (b) is of course a local matter, does not need standardization. (a) does require a standardized format of confirmations. This is already available in X.400. If we do wish to get this also as an extension to RFC822, something like what you propose should be used. One problem is that more and more of messaging will be X.400, and go via X.400<->RFC822 gateways, and the present proposal for such gateways (RFC987) does not propose that confirmation requests and confirmations should be passed across such gateways (since RFC822 does not have a standard for confirmation formatting in computer-readable form).
page@ulowell.UUCP (Bob Page) (10/20/86)
I missed the initial posting that Glenn followed up to, but on a variation of his suggestion, why can't confirmation of delivery be based on the USPS? For example, if a header line asks for confirmation, the mail agent tells the recipient that s/he has a 'registered letter' from user@host.domain, and would they please sign for it? "Just typing <CR> will be fine, thank you." Once it has been delivered (to the user's mailbox), a confirmation is sent to the From:/Sender: address. If the message isn't picked up within a certain period of time (Confirm-Timeout: ?), it is marked as 'unanswered' and returned to the sender. ..Bob -- UUCP: wanginst!ulowell!page Bob Page, U of Lowell CS Dept VOX: +1 617 452 5000 x2976 Lowell MA 01854 USA
stephen@comp.lancs.ac.uk (Stephen J. Muir) (10/23/86)
We in the UK already have this facility. The header line is as follows: Acknowledge-To: stephen@comp.lancs.ac.uk -- EMAIL: stephen@comp.lancs.ac.uk | Post: University of Lancaster, UUCP: ...!mcvax!ukc!dcl-cs!stephen | Department of Computing, Phone: +44 524 65201 Ext. 4120 | Bailrigg, Lancaster, UK. Project:Alvey ECLIPSE Distribution | LA1 4YR
jsdy@hadron.UUCP (Joseph S. D. Yao) (11/06/86)
The TOFACS mail system uses Send-Receipt: as the mail header.
When the receipt is sent once, this gets changed to Sent-Receipt:
by overwriting one byte. (The TOFACSers were quite concerned
that time not be spent to re-write the mail file.)
--
Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
jsdy@hadron.COM (not yet domainised)