jim@tiamat.fsc.com (Jim O'Connor) (04/07/89)
In article <11428@s.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) writes: > Some people using MMDF are wanting to implement some sort of features > for returning indicators for when mail is delivered and/or read. > There are good reasons for wanting to do this, and I'm interested > in implementing the "when mail is delivered" version at least. > It is probably true that any type of "tell me when/if they read it" feature would have to be implemented in the MUA's (perhaps a new feature for Elm 2.3). This feature is something I would also be interested in. "Return notice on delivery" is/should be implemented in the MDA, but as you said, not all systems support that, and even when they do support it, the text of the message you get back is not consistent. ------------- James B. O'Connor jim@tiamat.fsc.com Filtration Sciences Corporation 615/821-4022 x. 651 *** Altos users unite! mail to "info-altos-request@tiamat.fsc.com" ***
taylor@cs.glasgow.ac.uk (Mr Jem Taylor) (04/10/89)
In article <513@tiamat.fsc.com> jim@tiamat.fsc.com (Jim O'Connor) writes: >It is probably true that any type of "tell me when/if they read it" feature >would have to be implemented in the MUA's (perhaps a new feature for Elm 2.3). I would not use a User Agent which did such a thing without asking me first, when I read a message tagged with Return-Receipt: ... Consider the privacy implications before doing this, and compare the ISO MOTIS operations. I think Delivery Notification is in X400, I think Read-and-understood Notification is not. -jem. -- Arpa:taylor@cs.glasgow.ac.uk \ J.A.Taylor, Computing Science, Janet: taylor@uk.ac.glasgow.cs \ University of Glasgow, Uucp: mcvax!cs.glasgow.ac.uk!taylor \ GB-GLASGOW G12 8QQ
jim@tiamat.fsc.com (Jim O'Connor) (04/12/89)
In article <2765@crete.cs.glasgow.ac.uk>, taylor@cs.glasgow.ac.uk (Mr Jem Taylor) writes: > In article <513@tiamat.fsc.com> jim@tiamat.fsc.com (Jim O'Connor) writes: > >It is probably true that any type of "tell me when/if they read it" feature > >would have to be implemented in the MUA's (perhaps a new feature for Elm 2.3). > > I would not use a User Agent which did such a thing without asking me > first, when I read a message tagged with Return-Receipt: ... That sounds reasonable. The MUA could flag the message with some identifier indicating it is a "Read Receipt" message, so the user would know that notification will be sent. Or exit the smart MUA, and read/delete the message with an old "mail" MUA, which would not know what to do with the header. There might be some sticky points to work out (e.g. make sure you send the notification only once), but there are times when I really wonder if a person has read the mail I sent, or simply discarded it. I guess the right of freedom to ignore people will win out on this one. ------------- James B. O'Connor jim@tiamat.fsc.com Filtration Sciences Corporation 615/821-4022 x. 651 *** Altos users unite! mail to "info-altos-request@tiamat.fsc.com" ***
cfe+@andrew.cmu.edu (Craig F. Everhart) (04/14/89)
Andrew's Messages program implements an acknowledgement-requested feature. You
have to answer a dialog box to send the acknowledgement; you're prompted for it
only once, the first time you read a message that requests it.
Nathaniel Borenstein has a draft RFC describing the headers and values, if
you're interested.
Craig Everhart
Andrew message systemnsb+@andrew.cmu.edu (Nathaniel Borenstein) (04/14/89)
Craig is right; I haven't submitted the RFC because it needs more polishing, but
here's what I've got, for now. I believe that the Andrew Message System (all of
the clients, not just the Messages program) all conform to this spec. I've
decided to go ahead and post in on the net in the hope that I might get some
useful comments and hence be spurred on to actually finish it.
(By the way, I have two other draft RFC's in the works, one describing the AMS
mechanism for automatically calling for and collecting votes, and one describing
the AMS mechanism for sending files around inside mail as "enclosures". If
there's enough interest, I can post them, too. -- NB)
RFC XXX
An end-to-end delivery notification feature for ARPA Internet Messages
Nathaniel S. Borenstein
Craig F. Everhart
Information Technology Center
Carnegie-Mellon University
Pittsburgh, Pennsylvania, 15213
nsb+@andrew.cmu.edu
Abstract
A standardized Ack-To field allows mail reading systems to implement
a "confirmation" feature whereby the users can request confirmation
that a piece of mail has actually been received by the recipient. The
type of confirmation defined for the User-Reciept-To feature is
"end-to-end" in the sense that it confirms actual receipt by the final
reader (the human being) rather than the completion of some stage of
the delivery process (e.g. the entry of the message into the
recipient's mailbox). The feature has been designed to conform to the
Internet mail standard RFC 822 and to be plausibly converted to and
from the X.400 Delivery Notification service at future SMTP-X.400
gateways. This proposal calls for the creation of three new standard
Intenet mail headers, "Ack-To", "Ack-type", and "Ack"
1. Introduction
This RFC proposes a new addition to the set of standard headers which may
appear in Internet mail as defined by RFC 822. The purpose of the new "Ack-To"
header is to facilitate confirmation that a message has indeed been delivered
to its intended recipient.
Although the feature appears simple, it has been carefully designed to meet a
few key criteria:
- Conformity to RFC 822
- Interoperability with X.400
- Non-interference with the functioning of mail systems that do not
implement the feature.
- Independence from other types of confirmation schemes with different
semantics, which have been implemented independently.
The last criterion is necessary because there has been and continues to be a
significant amount of disagreement regarding the most desirable form of
delivery notification. Some efforts have been made in the past, such as the
4.2/3 BSD sendmail program's use of the "Return-Reciept-To" header, which
requests automatic notification of the completion of key steps in the delivery
process. Rather than assert that the "end-to-end" return receipt proposed in
this document is the "correct" form of delivery notification, we simply offer
it as an alternative, to be implemented by those systems that regard it as
desirable.
2. Alternative Models for Delivery Notification
Ideally, a delivery notification mechanism would provide a one-to-one mapping
onto successful deliveries: if the user receives a delivery notification, he
could be certain that the message had been delivered, and if the notification
never arrived, he could be certain the message had never been delivered.
Unfortunately, this ideal mechanism is rendered virtually impossible by the
fundamental uncertainty of internetwork mail delivery, which is of course
itself one of the major motivating factors in providing such a service. Since
it is always conceivable that mail will be lost, it is always conceivable that
mail confirming successful delivery will be lost. While one can imagine
mechanisms that would guarantee this mapping, their implementation would be
essentially as hard as implementing completely reliable mail delivery in the
first place. In the absence of any medium-term prospects of such reliability,
a useful delivery notification scheme should be designed to be much easier to
implement.
Given that the ideal guarantee can not be made, an alternative is to
guarantee that the receipt of a delivery notification implies that the
recipient received the mail, but to make no guarantees about the absence of
receipt. That is the position taken in this proposal.
Another point where notions of delivery confirmation may differ is in the
point at which the confirmation is generated. The two major choices here are
confirmation of delivery and confirmation of human receipt. In the former
case, the receipt guarantees simply that the message was put somewhere (e.g. a
mailbox) where the user could be expected to find it. In the latter case, the
position specified in this proposal, the receipt guarantees that the message
was actually seen by the human recipient. (Of course, no guarantee can be made
that the right human being read the message, especially given the
unatuthenticated nature of internetwork mail, but the recipient's identity
should be checked to the extent that the authentication facilities on the
recipient's system permit.) The receipt by human being was selected for this
proposal because it seems the stronger of the two guarantees, and is well
within the implementation capabilities of most mail systems.
In order to better accommodate the mix of possible acknowledgement types, a
third, optional header is defined, the "Ack-type" header. If present, this
field indicates the type of acknowledgement being provided, as indicated below.
3. Specification of the Ack-To header
The User-Reciept-To header has a syntax identical to the Reply-To header, as
defined in RFC 822. It specifies a destination address to which the delivery
confirmation should be mailed. It may be identical to the From or Reply-To
header, but need not be.
When a User-Reciept-To header is used, a Message-ID header is required.
4. Specification of the Ack-Type header
The Ack-Type header is optional. If provided, it should have one of a small
set of designated values, indicated the type of confirmation being provided.
In particular, "Ack-type: explicit" indicates that the mail was actually read
by the human user and that the user explicitly agreed to send the
acknowledgement. Other values for the Ack-type field should be published as
needed.
5. Specification of the Delivery Notification Message
When the user agent in a mail system shows a user a new message requesting
confirmation with the Ack-To header, it may generate a corresponding delivery
notification message. (The term "may" implies not only that many mail systems
may not implement this feature, but also that some may choose to give the user
the option of sending or not sending such a confirmation.) In this case, it
will send a message to the destination address specified in the Ack-To header.
That message should contain a "Ack" header, the contents of which should be
simply the Message-ID header of the message being confirmed.
In addtion, it is recommended that, for the benefit of users of mail systems
that do not automatically correlate return-reciepts, two additional steps be
taken in the composition of the confirmation message. First, the Subject
header should be composed of the word "Confirming: " followed by the subject of
the original message. Second, the body of the message should contain a
suitable explanatory phrase, one that will be meaningful if read by a human
being. A sample can be found in the following section.
Finally, it is recommended that, when the delivery notification message is
sent, the user agent makes some note of the fact in order to prevent the
sending of a duplicate notification message in the future.
6. Example
The following shows a matched pair of messages, the first requesting delivery
notification, and the second (presumably automatically generated) providing it.
From: Nathaniel Borenstein <nsb+@andrew.cmu.edu>
Subject: How are you?
Date: Sun, 25 Oct 87 09:46:54 -0500 (EST)
To: "Craig F. Everhart" <cfe+@andrew.cmu.edu>
Ack-To: Nathaniel Borenstein <nsb+receipts@andrew.cmu.edu>
Message-ID: <MVTvxNyOOWAKRYA07p@andrew.cmu.edu>
Hi, Craig. This is just a test of the user-receipt feature.
- Nathaniel
From: "Craig F. Everhart" <cfe+@andrew.cmu.edu>
Subject: Confirming: How are you?
Date: Sun, 25 Oct 87 10:46:54 -0500 (EST)
To: Nathaniel Borenstein <nsb+receipts@andrew.cmu.edu>
Ack: <MVTvxNyOOWAKRYA07p@andrew.cmu.edu>
Message-ID: <NACvx0078@andrew.cmu.edu>
This message confirms the receipt by "Craig F. Everhart"
of a message from "Nathaniel Borenstein <nsb+@andrew.cmu.edu>"
on the subject "How are you?"
dated "Sun, 25 Oct 87 09:46:54 -0500 (EST)".
This is an "explicit" receipt, which means that the user
saw the message and agreed to send this confirmation.
7. References
1. Crocker, David H. RFC 822: Standard for the Format of ARPA Internet Text
Messages. Network Information Center, August 13, 1982.
Table of Contents
1. Introduction 1
2. Alternative Models for Delivery Notification 1
3. Specification of the Ack-To header 1
4. Specification of the Ack-Type header 1
5. Specification of the Delivery Notification Message 1
6. Example 1
7. References 1