INTERNET-DRAFT Jacob Palme Network Working Group Stockholm University/KTH draft-ietf-mailext-new-fields-15.txt Sweden Expires August 1999 February 1999 The Auto-Submitted and Expires Headers in E-mail Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright (C) The Internet Society 1998. All Rights Reserved. Abstract This memo introduces two new e-mail headers, Auto-Submitted and Expires. This document may, if accepted by the IESG, become a proposed standard, at some time in the future. Differences from version 14 The "Supersedes" header has been removed. The reason for this is that this header is currently being discussed a lot in the IETF usefor group, and it should not be specified for e-mail before we know how usefor specifies it for Usenet News. The places where white space may include a comment has been slightly reduced. Added the following text: The word "client" may in this text designate functionality, which some implementations actually implement wholly or partly in a server. For example, in the case of IMAP and NNTP, it is very common to implement functionality, which logically may be regarded as belonging to a client, in the server. The syntax of date-time has been changed to agree with draft- ietf-drums-msg-fmt-06. A mandatory space has been added after the header name and ":", to agree with usenet news practice. Differences from version 13 Minor clarifications that the choice of soft or hard supersedes is not indicated by any header information, the choice is done by the recipient or recipient software. This clarifications was suggested by Paul Hoffman at the Chicago 1998 IETF meeting. Differences from version 12 The syntax for parameters to the Auto-Submitted header is better specified. The list of examples in section 3.5.1 have been extended with more examples. The text about the Supersedes header (4.2.2 to 4.2.3) has been modified to more clearly indicate when soft and hard supersedes are to be implemented and to reflect current usage. The text about the Supersedes header (4.2.1) has been modified to more clearly show who are allowed to issue superseding messages. Table of contents 1. Introduction 2. Syntax elements 2.1 Identifier 2.2 date-time 3. Auto-Submitted 3.1 Syntax: 3.2 Semantics 3.3 Relation to NOTIFY ESMTP command 3.4 Parameters 3.5 Fuller semantics with examples 3.5.1 Syntax examples without private extensions: 3.5.2 Possible syntax examples with private or future extensions: 3.5.3 Auto-Submitted: no or no Auto-Submitted header 3.5.4 Keep the field in forwarded message 3.5.5 Auto-Submitted: auto-generated 3.5.6 Auto-Submitted: auto-replied 3.5.7 Recipient use of Auto-Submitted fields 4. Expires: 5. Relation to X.400 gateways versus Netnews 6. Security considerations 6.1 "Auto-Submitted" security considerations 6.2 "Expires" security considerations 7. Copyright 8. Acknowledgments 9. References 10. Author's address 1. Introduction This memo introduces two new header fields for Internet e-mail [1] headers, which will enhance the e-mail service in various ways. These headers may occur in Usenet News [8], too, but this document will only be a standard for Usenet News, if the Usenet News standards documents in the future say so. The names of the new headers are: Auto-Submitted and Expires. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. The word "client" may in this text designate functionality, which some implementations actually implement wholly or partly in a server. For example, in the case of IMAP and NNTP, it is very common to implement functionality, which logically may be regarded as belonging to a client, in the server. An informational RFC [11] with advice on the implementation of the features specified in this specification will simultaneously be published. For more info see URL http://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.html#newfields 2. Syntax elements This section defines some syntax elements needed for the syntax specifications of the new fields. The syntax is defined using the ABNF rules from [12]. 2.1 Identifier identifier = "<" id-left-side "@" id-right-side ">" id-left-side = dot-atom-text / no-fold-quote id-right-side = dot-atom-text / no-fold-literal no-fold-quote = DQUOTE *(qtext / quoted-pair) DQUOTE dot-atom-text = 1*atext *("." 1*atext) atext = ALPHA / DIGIT / ; Any character except ; controls, SP and "!" / "#" / ; specials. "$" / "%" / ; Used for atoms "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" qtext = NO-WS-CTL / ; Non-white-space controls %d33 / ; The rest of the US-ASCII %d35-91 / ; characters not including "\" %d93-127 ; or the quote character quoted-pair = ("\" text) text = %d1-9 / ; Chars excl. CR and LF %d11-12 / %d14-127 WSP = SP / HTAB ; Whitespace characters FWS = ([*WSP CRLF] 1*WSP) ; Folding white-space ctext = NO-WS-CTL / ; Non-white-space controls %d33-39 / ; The rest of the US-ASCII %d42-91 / ; characters not including %d93-127 ; "(", ")", or "\" comment = "(" *([FWS] (ctext / quoted-pair / comment)) [FWS] ")" CFWS = *([FWS] comment) (([FWS] comment) / FWS) 2.2 date-time day-of-week = ([FWS] day-name [FWS]) / obs-day-of-week day-name = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun" date = day month year year = ([FWS] 4*DIGIT [FWS]) / obs-year month = (FWS month-name FWS) / obs-month month-name = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" day = ([FWS] 1*2DIGIT [FWS]) / obs-day time = time-of-day FWS zone time-of-day = hour ":" minute [ ":" second ] hour = 2DIGIT / obs-hour minute = 2DIGIT / obs-minute second = 2DIGIT / obs-second zone = (( "+" / "-" ) 4DIGIT) / obs-zone 3. Auto-Submitted 3.1 Syntax: auto-submitted-field = "Auto-Submitted:" CFWS auto-submitted [CFWS] CRLF auto-submitted = ( "no" / "auto-generated" / "auto-replied" / private-extension / future-extension ) optional-parameter-list private-extension = x-token Future-extension = token The symbols "token", "x-token", and "parameter" are as defined in MIME [5]. optional-parameter-list = *( [CFWS] ";" [CFWS] LWSP parameter ) parameter = parameter-name [ "=" parameter-value ] parameter-name = "increment" / private-parameter / future-parameter 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: The syntax for private-extension and future-extension is specified as a placeholder for future extensions. private-extension keywords must begin with "x-", future extension keywords may be defined only by standards-track RFCs, or by Informational or Experimental RFCs with approval of the IESG. Implementations which examine the value of the Auto-Submitted field should handle an Auto-Submitted field which contains an unrecognized private-extension or future-extension keyword as if the message had been automatically submitted, but without information about the type of auto-submission. 3.2 Semantics This field indicates whether the message was sent with or without explicit human control. The auto-generated keyword: SHOULD be used on messages generated by automatic (often periodic) processes, MUST NOT be used on manually generated messages, MUST NOT be used on a message issued in direct response to another message. The auto-replied keyword: SHOULD be used on messages sent in direct response to another message, MUST NOT be used on manually-generated messages, MUST NOT be used on messages generated by automatic or periodic processes. 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. The "comment" syntactical construct can be used to indicate a reason why this message was auto-submitted. 3.3 Relation to NOTIFY ESMTP command This specification 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 shown by the DSN format as defined in the DSN standards [6]. 3.4 Parameters Only one optional parameter is defined here. This parameter has the attribute name "increment" and the value a number (1*DIGIT) which indicates the number of seconds since the last time a similar auto-submitted message was produced by the same sender to any recipient. This parameter might be useful to detect and counteract a looping auto-submitter. 3.5 Fuller semantics with examples 3.5.1 Syntax examples without private extensions: Example 1: Auto-Submitted: auto-generated Example 2: Auto-Submitted: auto-replied Example 3: Auto-Submitted: no Example 4: Auto-Submitted: auto-generated; increment=21600 Example 5: Auto-Submitted: (weather-report) auto-generated; (issued every 6 hours) increment=21600 3.5.2 Possible syntax examples with private or future extensions: Example 6: Auto-Submitted: x-ibm-transaction Example 7: Auto-Submitted: auto-replied ; bounced Example 8: Auto-Submitted: auto-replied ; x-count=8 3.5.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. 3.5.4 Keep the field in forwarded message In the following cases, an existing Auto-Submitted header on a forwarded message SHOULD 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. 3.5.5 Auto-Submitted: auto-generated An Auto-Submitted field with the auto-generated keyword SHOULD be supplied with a message that is automatically generated, but not one which is an automatic response to an emailed request. Examples of automatically generated messages include: - An automatic weather station sends periodic messages with temperature, wind velocity, etc. to a weather database server. - An automatically generated weather-report is sent once every three hours to subscribing customers. - An automatic computer process (for example, a "cron job") 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. Note: This is a borderline case. If the sent files has as SMTP-sender the person who modified this file, it should not be regarded as auto-submitted. - A notification asking you to confirm your subscription to a mailing list, which is sent to you automatically by the mailing-list-serverevery six months. 3.5.6 Auto-Submitted: auto-replied An Auto-Submitted field with the auto-replied keyword SHOULD be included in any message issued as an automatic response to another message. Example: - A mail server responds to an incoming request message. Many uses of this header field is for special kinds of notifications, such as: - 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 non- standard way. 3.5.7 Recipient use of Auto-Submitted fields The Auto-Submitted field may be used by recipients (human or otherwise) to aid in processing the message. For example: - A mailing list may wish, as a matter of policy, to accept only human-generated input. It may therefore wish to filter out any messages including the Auto-Submitted header field, if the keyword is other than "no". - A process which automatically responds to messages (for example, a "vacation server"), may be intended to send responses only to humans, and not to auto-generated or auto-replied messages. Such a process SHOULD not respond to messages with an Auto-Submitted field with a keyword other than "no". 4. Expires: Syntax: Expires-field = "Expires:" CFWS date-time [CFWS] CRLF 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 but not identical meaning, in netnews [8] and in X.420 [4]. 5. Relation to X.400 gateways versus Netnews A similar headers to Expires is 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 been added to X.420, with similar definition as in this document. Unfortunately, the header Expires has a different name in Internet-X.400 gatewaying standards [2] and in netnews. 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 "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. Automatically submitting messages has, of course, several security concerns, but these security concerns do not become more severe if a header is defined to specify if a message is auto-submitted or not. 6.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. This specification does, therefore, not require user agents to make expired messages inaccessible. 7. Copyright and disclaimer The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat." The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 8. Acknowledgments Many people have helped with the production of this document. Of special value have been R. Allbery, H. T. Alvestrand, A. Bowesman, B. Franz, P. Hoffman, S. Kille, S. Lyall, K. Moore, P. Overell, U. Paz, E. Sommarskog, H. Spencer, J. Stanley, B. Templeton, K. Weide and R. Zellich 9. 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] B. Ramsdell: S/MIME Version 3 Message Specification. Work in progress. [10] J. Callas, L. Donnerhacke, H. Finney, R. Thayer: OpenPGP Message Format. Work in progress. [11] J. Palme: "Advise on the implementation of In-Reply-To, References and Supersedes e-mail and netnews headers", draft-palme-newfields-info-02.doc, March 1998. [12] D. Crocker: Augmented BNF for Syntax Specifications: ABNF, RFC 2234, November 1997. 10. 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