CONFIRM-DELIVERY

[Craig F. Everhart]

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.)

[Bob Page]

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
us...@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 J. Muir]

We in the UK already have this facility. The header line is as follows:

Acknowledge-To: ste...@comp.lancs.ac.uk
--
EMAIL: ste...@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

[Joseph S. D. Yao]

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}
js...@hadron.COM (not yet domainised)