Network Working Group Jacob Palme Internet Draft Stockholm University/KTH Sweden Category: Experimental January 1996 Expires July 1996 The Supersedes and Expires e-mail headers Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind, since this document is mainly a compilation of information taken from other RFC-s.. Distribution of this memo is unlimited. Abstract This memo introduces two new e-mail (RFC 822) headers, Supersedes, and Expires. Differences from previous version Differences from previous version : The word "header field" has been changed to just "header". One paragraph in chapter 4 about X.400 gateways has been changed to indicate that the next version of MIXER, and not this memo, may choose to modify MIXER to align with this memo. 1. Introduction This memo introduces certain headers for Internet e-mail (RFC 822) headers which will enhance the e-mail service in various ways. The headers introduced are: Supersedes and Expires. Palme [Page 1] draft-ietf-mailext-new-fields-03.txt January 1996 2. Supersedes Syntax: supersedes-field = "Supersedes" ":" 1#msg-id The message identifiers (msg-id) use the msg-id format, as defined in RFC 822 [1]. This header identifies previous correspondence, which this message supersedes. A user agent is expected to handle this field in much the same way as the In-Reply-To and References header. (a) Thus, this header does not imply any mandatory deletion of the previous correspondence. (b) User agents which provide user commands for getting from a reply to the replied-to message (or for getting from a replied-to message to its replies), may provide similar commands for getting from a superseding message to the superseded message (or for getting from a superseded message to its superseding version). (c) User agents may normally show the recipient both the previous and the superseding message. If, however, both the previous and the superseding message have arrived, both having the same author, but the user has not yet seen either of them, a user agent may show only the superseding message, but also show the supersedes- field to inform the recipient that this message supersedes a previous message. (d) User agents might issue a warning if a superseding message arrives with a different author than the author of the superseded message. This can be done by checking the "From:" header, or, if PEM [6] or PGP [7] signatures are available, by checking the digital signature. Note: A similar header is defined in X.420 [4], and has been in common usage in Usenet News. 3. Expires: Syntax: Expires-field = "Expires" ":" date-time The Expires header indicates a date-time, at which this message expires. The field can be used both to limit and to extend the life of a message. User agents and servers which employ automatic purging of old messages may let this field influence the purging process. Note: This header is also defined, with similar meaning, in Usenet News [5] and in X.420 [4]. Palme [Page 2] draft-ietf-mailext-new-fields-03.txt January 1996 4. Relation to X.400 gateways and to Usenet News Similar headers to those defined in this document are also defined in recommendations for gatewaying [2] between X.400 [3] and Internet mail. However, those recommendations are only valid for gateways. By defining the fields here, the fields are made available for general Internet e-mail usage. This document also gives fuller descriptions of the fields than is given by the X.400 gatewaying recommendations [2]. Unfortunately, the two new headers specified here have different names in Internet-X.400 gatewaying standards [2] and in Usenet News. RFC 1327 gives the name "Obsoletes:" for what in Usenet News is usually called "Supersedes:" (not specified in RFC 1036). RFC 1327 gives the name "Expiry-Date:" for what in Usenet News is called "Expires:" (specified in RFC 1036). Because compatibility with Usenet News is more important than with X.400, the Usenet News names of the fields are proposed here. Future versions of RFC 1327 (the MIXER document) may choose to specify the use of "Supersedes" and "Expires" also in gatewayed messages from X.400. 5. Security considerations 5.1 "Supersedes" security considerations If a receiving user agent suppresses showing of superseded messages, the "Supersedes:" feature might be used maliciously to suppress messages written by other people. To reduce the risk for this, it is recommended that user agents give a warning to the recipient when a superseding message has a different "From:" name than the superseded message. A moderately clever forger can of course circumvent this by sending falsified messages. User agents supporting PEM [6] or PGP [7] can require and check digital signatures to stop also this risk. Another possible risk with "Supersedes:" is that it allows people to "change their minds", possibly changing the meaning of replies to them. Example: A message with the text "Do you like your mother" gets the reply "Yes, very much", and then the original message might be changed to "Do you like Hitler", changing the meaning of the reply. Note, however, that the "In-Reply-To" or "References" headers in the reply refers to the Message-ID of the original message, not of the superseding message. Thus, a user agent can avoid this problem by designing the user interface so that replies are not shown as referring to the superseding message, when they use the Message-ID of the superseded message. Palme [Page 3] draft-ietf-mailext-new-fields-03.txt January 1996 Also, since "Supersedes:" does not actually cause deletion of the superseded message, recipients can look up the superseded message to see if the author has changed his mind. In general, it is not illegal or unethical to change your mind, rather, it shows your openness to new ideas and willingness to listen to the arguments of other people. 5.2 "Expires" security considerations One intention of "Expires" is to help recipients avoid seeing messages with information which is not any longer valid. There may of course be cases where a user might want to see an expired message (e.g. a user might sometimes want to be informed of a meeting, even after the time of the meeting). This could possibly be solved by having different kinds of "Expires" for different expiration causes, however, this complexity is not felt needed at present. A user agent can of course be designed to inform the recipient also of expired messages, and allow the recipient the choice of reading them or not. 6. References [1] D. Crocker: "Standard for the format of ARPA Internet text messages." STD 11, RFC 822, August 1982. [2] S. Hardcastle-Kille: "Mapping between X.400(1988) / ISO 10021 and RFC 822", RFC 1327 May 1992. [3] ISO/ITU: "Message Handling Systems", ISO international standard 10021, ITU recommendation X.400. [4] ISO/ITU: "Message Handling Systems, Part 7: Interpersonal Messaging System, ISO international standard 10021-7, ITU recommendation X.420. [5] M.R. Horton, R. Adams: "Standard for interchange of USENET messages", RFC 1036, December 1987. [6] S. Kent, J. Linn, D. Balenson, B. Kaliski: 1421 Privacy Enhancement for Internet Electronic Mail: Part I-IV, RFC 1421-1424, February 1993. [7] Gary B. Edstrom: Frequently Asked Questions; alt.security.pgp. Available from faq servers, such as URL: gopher: //nutmeg.ukc.ac.uk.:70/11/.archive/uunet/usenet/news.answers/ pgp-faq. 7. Author's address Jacob Palme Phone: +46-8-16 16 67 Stockholm University/KTH Fax: +46-8-703 90 25 (not fast) Electrum 230 E-mail: jpalme@dsv.su.se S-164 40 Kista, Sweden Palme [Page 4]