🚀 go-pugleaf

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