I just sent the following proposal to MAIL-L, but since it includes
mail rejections, I thought it might be of interest to people here.
I suggest that discussion take place on MAIL-L.
------------------------------------------------------------------
A few months ago I revived the perennial discussion about possible
extensions for acknowledgement messages. This is a proposal based
on that discussion. I hope it includes what most people thought
should be in such a facility. Comments are welcome. It would be
especially helpful if someone knowledgeable about X.400 looked at
the implications for gateways to X.400 systems. If we can get
enough people to agree, perhaps we can get SRI-NIC to register these
as extension fields in RFC 822.
Headers to be included in messages requesting an acknowledgement:
Acknowledge-to and Resent-acknowledge-to
The syntax of these headers would be the same as the To
header. Each address specified (there could be more than one)
would receive an acknowledgement for each recipient.
Message-id and Resent-message-id
These headers are already defined in RFC 822. The
acknowledgement message would contain an Acknowledgment-of
header containing the message-id from the original message.
Acknowledge-at and Resent-acknowledge-at
These headers would contain exactly one of the following
keywords to specify the originator's preference as to when the
acknowledgement should be generated:
Delivery - when the message is placed in the users mailbox
(i.e., the message could be read, but has not
necessarily been read).
Presentation - when the message is presented to the user
for reading (i.e., displayed on the screen).
Verification - when the receiving user explicitly indicates
that he or she has read the message.
Not all mail user agents would necessarily implement all of
these options. If an option was requested that was not
available, the user agent would give the nearest one that it
does implement (if any).
Headers to be included in acknowledgement messages:
Acknowledgement-of
The header syntax is the same as In-reply-to. If the original
message had a Message-id, it should be included in this
header, so that the originating user agent can tie the
acknowledgment to the original message, if it provides that
facility.
Acknowledgement-at
This header contains exactly one of the following keywords to
indicate when the acknowledgement message was generated:
Delivery - the message was placed into the user's mailbox
Presentation - the message has been displayed to the
recipient.
Verification - the receipient has explicitly indicated that
he or she has read the message.
Deletion - the recipient deleted the message before it
could be acknowledged.
Rejection - the message could not be delivered (e.g.,
because the userid specified does not exist).
An acknowledgement message must contain, at a minimum, an
Acknowledgement-at header. An Acknowledgement-of header should also
be included, if possible.
The text of the acknowledgement message is not specified, but it is
recommended that it clearly state when the acknowledgment message
was generated and what message it is for. Certain headers (such as
To, From, Subject) from the original message might be included.
Note that an unrequested acknowledgement message (indicating
rejection) could be generated when a piece of mail cannot be
delivered. Since it would be explicitly identified as an
acknowledgement message, mailing list servers could avoid sending
such a message to a list. In all cases, in order to prevent loops,
no acknowledgement message (even a rejection) should ever be
generated for a message containing an Acknowledgement-of or
Acknowledgement-at header.
|
