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.