CONFIRM-DELIVERY
John C Klensin
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.