Network Working Group Jacob Palme Internet Draft Stockholm University/KTH Sweden Category-to-be: Proposed standard July 1997 Expires January 1998 The Auto-Submitted, 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 three new e-mail (RFC 822) headers, Auto-Submitted, Supersedes, and Expires. Differences from previous version The specification of Supersedes and Expires are unchanged. Auto-Submitted has been split into two specifications, one with the simpler case (without loop control) specified here and intended to become a proposed standard, and one with the controversial issue of loop control intended to become an experimental standard, which is submitted at the same time as draft-palme-autosub-03.txt. The value Auto-Submitted: no, which was removed in an earlier revision of this draft, has been added again, since it is known to exist in implementations on the net. It is now explicitly specified that Auto-Submitted and its parameters are case-insensitive. Some other minor wording changes have been made. See ftp://ftp.dsv.su.se/users/jpalme/draft-ietf-mailext-new-fields-08-dif.doc Table of contents 1. Introduction 2. Auto-Submitted 2.1 Syntax: 2.2 Semantics 2.3 Relation to NOTIFY ESMTP command 2.4 Examples 2.4.1 Syntax examples without private extensions: 2.4.2 Possible syntax examples with private or future extensions: 2.4.3 Auto-Submitted: no or no Auto-Submitted header 2.4.4 Keep field in forwarde message 2.4.5 Auto-Submitted: auto-generated 2.4.6 Auto-Submitted: auto-replied 3. Supersedes 4. Expires: 5. Relation to X.400 gateways versus Netnews 6. Security considerations 6.1 "Auto-Submitted" security considerations 6.2 "Supersedes" security considerations 6.3 "Expires" security considerations 7. Acknowledgments 8. References 9. Author's address 1. Introduction This memo introduces three new headers for Internet e-mail (RFC 822) headers which will enhance the e-mail service in various ways. The names of the new headers are: Auto-Submitted, Supersedes and Expires. 2. Auto-Submitted 2.1 Syntax: auto-submitted-field = "Auto-Submitted ":" auto-submitted auto-submitted = ( "no" / "auto-generated" / "auto-replied" / "x-" / " ) = *( ";" ) Note 1: All the syntax specified above is case-insensitive. Thus "Auto- Submitted: Auto-Replied" is identical to "auto-submitted: auto-replied" or "aUTO-sUBMITTED: aUTO-rEPLIED". Note 2: , and are not defined in this standard, but their syntax is specified as placeholders for future extensions. An implementation of this standard which encounters such extensions, but which does not support them, can simply ignore them. 2.2 Semantics This field indicates whether the message was sent with or without explicit human control. Note 1: A similar header field is defined in X.420 [4]. Note 2: If a message does not have any Auto-Submitted header, no assumption SHOULD be made of whether this message was automatically generated or not. 2.3 Relation to NOTIFY ESMTP command This standard does not specify handling of Delivery Status Notifications. Such notifications are requested by the ESTMP NOTIFY command [7] and DSNs themselves need not contain any auto-submitted header, since their mode of submission is defined in the DSN standards [6]. 2.4 Examples 2.4.1 Syntax examples without private extensions: Example 1: Auto-Submitted: auto-generated Example 2: Auto-Submitted: auto-replied Example 3: Auto-Submitted: no 2.4.2 Possible syntax examples with private or future extensions: Example 4: Auto-Submitted: x-ibm-transaction Example 5: Auto-Submitted: auto-replied ; bounced 2.4.3 Auto-Submitted: no or no Auto-Submitted header In the following cases the "Auto-Submitted: no" header, or no Auto- Submitted header shall be generated. > Ordinary e-mail messages written by a person. > A person interacts with a mail-generating client, e.g. instructs it to join a mailing list, and the client generates a message to a listserver with commands for subscribing to the list. > A person interacts with a World Wide Web form, such that the filled-in form is automatically sent to an e-mail address specified in the WWW form document. 2.4.4 Keep field in forwarde message In the following cases, an existing Auto-Submitted header on a forwarded message SHOUş be kept as it is. > A moderator accepts messages to a moderated group, and forwards the accepted messages to the group members, possibly merged into a digest by software for producing digests. > Automatic forwarding by mailing list expanders or to a new e-mail address for the recipient. 2.4.5 Auto-Submitted: auto-generated > An automatic weather-station sends automatic messages with temperature, wind velocity, etc. to a weather data base server. > An automatically generated weather-report is sent once every three hours to subscribing customers. > An automatic computer process sends failure reports. > An automatic vote counter counts incoming votes and reports on the outcome of the vote. > A subscription service sends copies of a file every time the file is updated to people subscribing to such updates. If the subscription server wants notifications when the subscriber address is faulty, it can use the NOTIFY ESMTP command. 2.4.6 Auto-Submitted: auto-replied > A mail server responds to an incoming request message. Many uses of this header field is for special kinds of notifications, such as: > A notification asking you to confirm your subscription to a mailing list, which is sent to you automatically by the mailing-list-server every six month. > A vacation server sends a vacation notification in response to an incoming message for the person who is on vacation. > A notification that a message, after receipt, has been purged, forwarded or handled in some other special way. 3. Supersedes Syntax: supersedes-field = "Supersedes" ":" 1*msg-id The message identifiers (msg-id) use the msg-id format, as defined in RFC 822 [1]. Note that there is no comma between multiple values, and that each Message-ID value is to be surrounded by angle brackets. The Supersedes 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 [9], PGP [10] or MOSS [11] signatures are available, by checking the digital signature. The above procedure is called a "soft supersedes". Some user agents or servers may delete the old version of a message when a new version arrives, which is called a "hard supersedes". Hard supersedes is NOT RECOMMENDED practice, but common, especially in netnews where servers want to save disk space. When this is written (1997) some netnews softwares (servers and clients) cannot handle Supersedes with more than one previous articles listed as parameters. They usually ignore the Supersedes header in this case, and treats the new article as a separate article, not related to the superseded article. Implementors of netnews softwares SHOULD modify their software to be able to handle Supersedes with more than one previous article as parameter, but for some time, many softwares may not be able to handle Supersedes with more than one parameter. A gateway from e-mail to news MAY because of this delete all but the first parameter of this attribute when conveying messages from e-mail to news, BUT such a practice should be temporary only for one or two years until news softwares have been modified. Warning: This header MUST be spelled "Supersedes" and not "Supercedes". Mailers MUST never generate "Supercedes" but MAY accept "Supercedes" in input. Note: The Message-ID of a superseding message MUST be different from the Message-ID of the superseded message. The Message-ID of the superseded message is used as value in the "Supersedes:" header, not in the Message-ID of the superseding message. 4. 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. There is no requirement that a user agent must suppress expired messages or make them inaccessible to their owners. Note: This header is also defined, with similar meaning, in netnews [8] and in X.420 [4]. 5. Relation to X.400 gateways versus Netnews Similar headers to Supersedes and Expires are also defined in recommendations for gatewaying [2] between X.400 [4] 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]. Also an Auto- Submitted feature has recently been added to X.400, with similar definition as in this document. Unfortunately, the two new headers Supersedes and Expires have different names in Internet-X.400 gatewaying standards [2] and in netnews. RFC 1327 [2] gives the name "Obsoletes:" for what in netnews is usually called "Supersedes:" (not specified in RFC 1036 [8] but in common usage). RFC 1327 gives the name "Expiry-Date:" for what in netnews is called "Expires:" (as specified in RFC 1036). Because compatibility with netnews is more important than with X.400, the netnews names of these two 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. 6. Security considerations 6.1 "Auto-Submitted" security considerations "Auto-submitted:" raises no new security concerns, instead, it reduces the risk to security of certain kinds of loops. 6.2 "Supersedes" security considerations If a mail or news server or 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 messages with falsified "From:" field and even falsified SMTP senders. User agents supporting PEM [9] or PGP [10] can require and check digital signatures to reduce 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. Also, since "Supersedes:" in e-mail 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. The fact that Supersedes in e-mail does not enforce deletion of the supersedes message, but that Supersedes in many existing netnews implementations does enforce such deletion, may in some circumstances cause security problems. 6.3 "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. This standard does, therefore, not require user agents to make expired messages inaccessible. 7. Acknowledgments Many people have helped with the production of this document. Of special value have been H. T. Alvestrand, S. Kille, K. Moore, P. Overell, Uzi Paz and K. Weide. 8. 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] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 1996 [6] K. Moore, G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996. [7] K. Moore, "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996. [8] M.R. Horton, R. Adams: "Standard for interchange of USENET messages", RFC 1036, December 1987. [9] S. Kent, J. Linn, D. Balenson, B. Kaliski: 1421 Privacy Enhancement for Internet Electronic Mail: Part I-IV, RFC 1421-1424, February 1993. [10] 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. [11] S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object Security Services", RFC 1848, March 1995. [12] J. Palme: "Loop control for the Auto-Submitted e-mail header", draft-palme-autosub-03.txt, July 1997. [13] J. Palme: "Advise on the implementation of In-Reply-To, References and Supersedes e-mail and netnews headers", draft-palme-newfields-info-00.doc, July 1997. 9. Author's address Jacob Palme Phone: +46-8-16 16 67 Stockholm University/KTH Fax: +46-8-783 08 29 Skeppargatan 73 E-mail: jpalme@dsv.su.se S-115 30 Stockholm, Sweden