idnits 2.17.1 draft-ietf-mailext-new-fields-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 629 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: - 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". -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1999) is 9196 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'FWS' on line 219 -- Looks like a reference, but probably isn't: 'CFWS' on line 447 == Unused Reference: '3' is defined on line 569, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 589, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 592, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (ref. '1') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1327 (ref. '2') (Obsoleted by RFC 2156) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 1894 (ref. '6') (Obsoleted by RFC 3464) ** Obsolete normative reference: RFC 1891 (ref. '7') (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 1036 (ref. '8') (Obsoleted by RFC 5536, RFC 5537) -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Normative reference to a draft: ref. '11' ** Obsolete normative reference: RFC 2234 (ref. '12') (Obsoleted by RFC 4234) Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Jacob Palme 2 Network Working Group Stockholm University/KTH 3 draft-ietf-mailext-new-fields-15.txt Sweden 4 Expires August 1999 February 1999 6 The Auto-Submitted and Expires Headers in E-mail 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance 11 with all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright (C) The Internet Society 1998. All Rights Reserved. 32 Abstract 34 This memo introduces two new e-mail headers, Auto-Submitted 35 and Expires. This document may, if accepted by the IESG, 36 become a proposed standard, at some time in the future. 38 Differences from version 14 40 The "Supersedes" header has been removed. The reason for this 41 is that this header is currently being discussed a lot in the 42 IETF usefor group, and it should not be specified for e-mail 43 before we know how usefor specifies it for Usenet News. 45 The places where white space may include a comment has been 46 slightly reduced. 48 Added the following text: 50 The word "client" may in this text designate functionality, 51 which some implementations actually implement wholly or 52 partly in a server. For example, in the case of IMAP and 53 NNTP, it is very common to implement functionality, which 54 logically may be regarded as belonging to a client, in the 55 server. 57 The syntax of date-time has been changed to agree with draft- 58 ietf-drums-msg-fmt-06. 60 A mandatory space has been added after the header name and 61 ":", to agree with usenet news practice. 63 Differences from version 13 65 Minor clarifications that the choice of soft or hard 66 supersedes is not indicated by any header information, the 67 choice is done by the recipient or recipient software. This 68 clarifications was suggested by Paul Hoffman at the Chicago 69 1998 IETF meeting. 71 Differences from version 12 73 The syntax for parameters to the Auto-Submitted header is 74 better specified. 76 The list of examples in section 3.5.1 have been extended with 77 more examples. 79 The text about the Supersedes header (4.2.2 to 4.2.3) has been 80 modified to more clearly indicate when soft and hard 81 supersedes are to be implemented and to reflect current usage. 83 The text about the Supersedes header (4.2.1) has been modified 84 to more clearly show who are allowed to issue superseding 85 messages. 87 Table of contents 89 1. Introduction 90 2. Syntax elements 91 2.1 Identifier 92 2.2 date-time 93 3. Auto-Submitted 94 3.1 Syntax: 95 3.2 Semantics 96 3.3 Relation to NOTIFY ESMTP command 97 3.4 Parameters 98 3.5 Fuller semantics with examples 99 3.5.1 Syntax examples without private extensions: 100 3.5.2 Possible syntax examples with private or future 101 extensions: 102 3.5.3 Auto-Submitted: no or no Auto-Submitted header 103 3.5.4 Keep the field in forwarded message 104 3.5.5 Auto-Submitted: auto-generated 105 3.5.6 Auto-Submitted: auto-replied 106 3.5.7 Recipient use of Auto-Submitted fields 107 4. Expires: 108 5. Relation to X.400 gateways versus Netnews 109 6. Security considerations 110 6.1 "Auto-Submitted" security considerations 111 6.2 "Expires" security considerations 112 7. Copyright 113 8. Acknowledgments 114 9. References 115 10. Author's address 117 1. Introduction 119 This memo introduces two new header fields for Internet e-mail 120 [1] headers, which will enhance the e-mail service in various 121 ways. These headers may occur in Usenet News [8], too, but 122 this document will only be a standard for Usenet News, if the 123 Usenet News standards documents in the future say so. 125 The names of the new headers are: Auto-Submitted and Expires. 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 128 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described 130 in RFC 2119. 132 The word "client" may in this text designate functionality, 133 which some implementations actually implement wholly or partly 134 in a server. For example, in the case of IMAP and NNTP, it is 135 very common to implement functionality, which logically may be 136 regarded as belonging to a client, in the server. 138 An informational RFC [11] with advice on the implementation of 139 the features specified in this specification will 140 simultaneously be published. For more info see URL 141 http://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.html#newfields 143 2. Syntax elements 145 This section defines some syntax elements needed for the 146 syntax specifications of the new fields. The syntax is defined 147 using the ABNF rules from [12]. 149 2.1 Identifier 151 identifier = "<" id-left-side "@" id-right-side ">" 153 id-left-side = dot-atom-text / no-fold-quote 155 id-right-side = dot-atom-text / no-fold-literal 157 no-fold-quote = DQUOTE *(qtext / quoted-pair) DQUOTE 159 dot-atom-text = 1*atext *("." 1*atext) 161 atext = ALPHA / DIGIT / ; Any character except 162 ; controls, SP and 163 "!" / "#" / ; specials. 164 "$" / "%" / ; Used for atoms 165 "&" / "'" / 166 "*" / "+" / 167 "-" / "/" / 168 "=" / "?" / 169 "^" / "_" / 170 "`" / "{" / 171 "|" / "}" / 172 "~" 174 qtext = NO-WS-CTL / ; Non-white-space controls 175 %d33 / ; The rest of the US-ASCII 176 %d35-91 / ; characters not including 177 "\" 178 %d93-127 ; or the quote character 180 quoted-pair = ("\" text) 182 text = %d1-9 / ; Chars excl. CR and LF 183 %d11-12 / 184 %d14-127 186 WSP = SP / HTAB ; Whitespace 187 characters 189 FWS = ([*WSP CRLF] 1*WSP) ; Folding 190 white-space 192 ctext = NO-WS-CTL / ; Non-white-space controls 193 %d33-39 / ; The rest of the US-ASCII 194 %d42-91 / ; characters not including 195 %d93-127 ; "(", ")", or "\" 197 comment = "(" *([FWS] (ctext / quoted-pair / 198 comment)) [FWS] ")" 200 CFWS = *([FWS] comment) (([FWS] comment) / FWS) 202 2.2 date-time 204 day-of-week = ([FWS] day-name [FWS]) / obs-day-of-week 206 day-name = "Mon" / "Tue" / "Wed" / "Thu" / 207 "Fri" / "Sat" / "Sun" 209 date = day month year 211 year = ([FWS] 4*DIGIT [FWS]) / obs-year 213 month = (FWS month-name FWS) / obs-month 215 month-name = "Jan" / "Feb" / "Mar" / "Apr" / 216 "May" / "Jun" / "Jul" / "Aug" / 217 "Sep" / "Oct" / "Nov" / "Dec" 219 day = ([FWS] 1*2DIGIT [FWS]) / obs-day 221 time = time-of-day FWS zone 223 time-of-day = hour ":" minute [ ":" second ] 225 hour = 2DIGIT / obs-hour 227 minute = 2DIGIT / obs-minute 229 second = 2DIGIT / obs-second 231 zone = (( "+" / "-" ) 4DIGIT) / obs-zone 233 3. Auto-Submitted 235 3.1 Syntax: 237 auto-submitted-field = "Auto-Submitted:" CFWS 238 auto-submitted [CFWS] CRLF 240 auto-submitted = ( "no" / "auto-generated" / 241 "auto-replied" / 242 private-extension / 243 future-extension ) 244 optional-parameter-list 246 private-extension = x-token 248 Future-extension = token 250 The symbols "token", "x-token", and "parameter" are as 251 defined in MIME [5]. 253 optional-parameter-list = *( [CFWS] ";" 254 [CFWS] LWSP parameter ) 256 parameter = parameter-name [ "=" 257 parameter-value ] 259 parameter-name = "increment" / 260 private-parameter / 261 future-parameter 263 Note 1: All the syntax specified above is case-insensitive. 264 Thus "Auto-Submitted: Auto-Replied" is identical to 265 "auto-submitted: auto-replied" or "aUTO-sUBMITTED: 266 aUTO-rEPLIED". 268 Note 2: The syntax for private-extension and future-extension 269 is specified as a placeholder for future extensions. 270 private-extension keywords must begin with "x-", future 271 extension keywords may be defined only by standards-track 272 RFCs, or by Informational or Experimental RFCs with approval 273 of the IESG. Implementations which examine the value of the 274 Auto-Submitted field should handle an Auto-Submitted field 275 which contains an unrecognized private-extension or 276 future-extension keyword as if the message had been 277 automatically submitted, but without information about the 278 type of auto-submission. 280 3.2 Semantics 282 This field indicates whether the message was sent with or 283 without explicit human control. 285 The auto-generated keyword: 287 SHOULD be used on messages generated by automatic (often 288 periodic) processes, 289 MUST NOT be used on manually generated messages, 290 MUST NOT be used on a message issued in direct response to 291 another message. 293 The auto-replied keyword: 295 SHOULD be used on messages sent in direct response to another 296 message, 297 MUST NOT be used on manually-generated messages, 298 MUST NOT be used on messages generated by automatic or 299 periodic processes. 301 Note 1: A similar header field is defined in X.420 [4]. 303 Note 2: If a message does not have any Auto-Submitted header, 304 no assumption should be made of whether this message was 305 automatically generated or not. 307 The "comment" syntactical construct can be used to indicate a 308 reason why this message was auto-submitted. 310 3.3 Relation to NOTIFY ESMTP command 312 This specification does not specify handling of Delivery 313 Status Notifications. Such notifications are requested by the 314 ESTMP NOTIFY command [7] and DSNs themselves need not contain 315 any auto-submitted header, since their mode of submission is 316 shown by the DSN format as defined in the DSN standards [6]. 318 3.4 Parameters 320 Only one optional parameter is defined here. This parameter 321 has the attribute name "increment" and the value a number 322 (1*DIGIT) which indicates the number of seconds since the last 323 time a similar auto-submitted message was produced by the same 324 sender to any recipient. This parameter might be useful to 325 detect and counteract a looping auto-submitter. 327 3.5 Fuller semantics with examples 329 3.5.1 Syntax examples without private extensions: 331 Example 1: Auto-Submitted: auto-generated 333 Example 2: Auto-Submitted: auto-replied 335 Example 3: Auto-Submitted: no 337 Example 4: Auto-Submitted: auto-generated; increment=21600 339 Example 5: Auto-Submitted: (weather-report) auto-generated; 340 (issued every 6 hours) increment=21600 342 3.5.2 Possible syntax examples with private or future extensions: 344 Example 6: Auto-Submitted: x-ibm-transaction 346 Example 7: Auto-Submitted: auto-replied ; bounced 348 Example 8: Auto-Submitted: auto-replied ; x-count=8 350 3.5.3 Auto-Submitted: no or no Auto-Submitted header 352 In the following cases the "Auto-Submitted: no" header, or no 353 Auto-Submitted header shall be generated. 355 - Ordinary e-mail messages written by a person. 357 - A person interacts with a mail-generating client, e.g. 358 instructs it to join a mailing list, and the client 359 generates a message to a listserver with commands for 360 subscribing to the list. 362 - A person interacts with a World Wide Web form, such that 363 the filled-in form is automatically sent to an e-mail 364 address specified in the WWW form document. 366 3.5.4 Keep the field in forwarded message 368 In the following cases, an existing Auto-Submitted header on a 369 forwarded message SHOULD be kept as it is. 371 - A moderator accepts messages to a moderated group, and 372 forwards the accepted messages to the group members, 373 possibly merged into a digest by software for producing 374 digests. 376 - Automatic forwarding by mailing list expanders or to a new 377 e-mail address for the recipient. 379 3.5.5 Auto-Submitted: auto-generated 381 An Auto-Submitted field with the auto-generated keyword SHOULD 382 be supplied with a message that is automatically generated, 383 but not one which is an automatic response to an emailed 384 request. Examples of automatically generated messages include: 386 - An automatic weather station sends periodic messages with 387 temperature, wind velocity, etc. to a weather database 388 server. 390 - An automatically generated weather-report is sent once 391 every three hours to subscribing customers. 393 - An automatic computer process (for example, a "cron job") 394 sends failure reports. 396 - An automatic vote counter counts incoming votes and reports 397 on the outcome of the vote. 399 - A subscription service sends copies of a file every time 400 the file is updated to people subscribing to such updates. 402 Note: This is a borderline case. If the sent files has as 403 SMTP-sender the person who modified this file, it should 404 not be regarded as auto-submitted. 406 - A notification asking you to confirm your subscription to a 407 mailing list, which is sent to you automatically by the 408 mailing-list-serverevery six months. 410 3.5.6 Auto-Submitted: auto-replied 412 An Auto-Submitted field with the auto-replied keyword SHOULD 413 be included in any message issued as an automatic response to 414 another message. Example: 416 - A mail server responds to an incoming request message. 418 Many uses of this header field is for special kinds of 419 notifications, such as: 421 - A vacation server sends a vacation notification in response 422 to an incoming message for the person who is on vacation. 424 - A notification that a message, after receipt, has been 425 purged, forwarded or handled in some other special non- 426 standard way. 428 3.5.7 Recipient use of Auto-Submitted fields 430 The Auto-Submitted field may be used by recipients (human or 431 otherwise) to aid in processing the message. For example: 433 - A mailing list may wish, as a matter of policy, to accept 434 only human-generated input. It may therefore wish to filter 435 out any messages including the Auto-Submitted header field, 436 if the keyword is other than "no". 438 - A process which automatically responds to messages (for 439 example, a "vacation server"), may be intended to send 440 responses only to humans, and not to auto-generated or 441 auto-replied messages. Such a process SHOULD not respond 442 to messages with an Auto-Submitted field with a keyword 443 other than "no". 445 4. Expires: 447 Syntax: Expires-field = "Expires:" CFWS date-time [CFWS] CRLF 449 The Expires header indicates a date-time, at which this 450 message expires. The field can be used both to limit and to 451 extend the life of a message. User agents and servers which 452 employ automatic purging of old messages MAY let this field 453 influence the purging process. There is no requirement that a 454 user agent must suppress expired messages or make them 455 inaccessible to their owners. 457 Note: This header is also defined, with similar but not 458 identical meaning, in netnews [8] and in X.420 [4]. 460 5. Relation to X.400 gateways versus Netnews 462 A similar headers to Expires is also defined in 463 recommendations for gatewaying [2] between X.400 [4] and 464 Internet mail. However, those recommendations are only valid 465 for gateways. By defining the fields here, the fields are made 466 available for general Internet e-mail usage. This document 467 also gives fuller descriptions of the fields than is given by 468 the X.400 gatewaying recommendations [2]. Also an 469 Auto-Submitted feature has been added to X.420, with similar 470 definition as in this document. 472 Unfortunately, the header Expires has a different name in 473 Internet-X.400 gatewaying standards [2] and in netnews. 475 RFC 1327 gives the name "Expiry-Date:" for what in netnews is 476 called "Expires:" (as specified in RFC 1036). 478 Because compatibility with netnews is more important than with 479 X.400, the netnews names of these two fields are proposed 480 here. 482 Future versions of RFC 1327 (the MIXER document) may choose to 483 specify the use of "Expires" also in gatewayed messages from 484 X.400. 486 6. Security considerations 488 6.1 "Auto-Submitted" security considerations 490 "Auto-submitted:" raises no new security concerns, instead, it 491 reduces the risk to security of certain kinds of loops. 492 Automatically submitting messages has, of course, several 493 security concerns, but these security concerns do not become 494 more severe if a header is defined to specify if a message is 495 auto-submitted or not. 497 6.2 "Expires" security considerations 499 One intention of "Expires" is to help recipients avoid seeing 500 messages with information which is not any longer valid. There 501 may of course be cases where a user might want to see an 502 expired message (e.g. a user might sometimes want to be 503 informed of a meeting, even after the time of the meeting). 504 This could possibly be solved by having different kinds of 505 "Expires" for different expiration causes, however, this 506 complexity is not felt needed at present. A user agent can of 507 course be designed to inform the recipient also of expired 508 messages, and allow the recipient the choice of reading them 509 or not. This specification does, therefore, not require user 510 agents to make expired messages inaccessible. 512 7. Copyright and disclaimer 514 The IETF takes no position regarding the validity or scope of 515 any intellectual property or other rights that might be 516 claimed to pertain to the implementation or use of the 517 technology described in this document or the extent to which 518 any license under such rights might or might not be available; 519 neither does it represent that it has made any effort to 520 identify any such rights. Information on the IETF's procedures 521 with respect to rights in standards-track and standards- 522 related documentation can be found in BCP-11. Copies of claims 523 of rights made available for publication and any assurances of 524 licenses to be made available, or the result of an attempt 525 made to obtain a general license or permission for the use of 526 such proprietary rights by implementors or users of this 527 specification can be obtained from the IETF Secretariat." 529 The IETF invites any interested party to bring to its 530 attention any copyrights, patents or patent applications, or 531 other proprietary rights which may cover technology that may 532 be required to practice this standard. Please address the 533 information to the IETF Executive Director. 535 This document and translations of it may be copied and 536 furnished to others, and derivative works that comment on or 537 otherwise explain it or assist in its implmentation may be 538 prepared, copied, published and distributed, in whole or in 539 part, without restriction of any kind, provided that the above 540 copyright notice and this paragraph are included on all such 541 copies and derivative works. However, this document itself may 542 not be modified in any way, such as by removing the copyright 543 notice or references to the Internet Society or other Internet 544 organizations, except as needed for the purpose of developing 545 Internet standards in which case the procedures for copyrights 546 defined in the Internet Standards process must be followed, or 547 as required to translate it into languages other than English. 549 The limited permissions granted above are perpetual and will 550 not be revoked by the Internet Society or its successors or 551 assigns. 553 8. Acknowledgments 555 Many people have helped with the production of this document. 556 Of special value have been R. Allbery, H. T. Alvestrand, A. 557 Bowesman, B. Franz, P. Hoffman, S. Kille, S. Lyall, K. Moore, 558 P. Overell, U. Paz, E. Sommarskog, H. Spencer, J. Stanley, B. 559 Templeton, K. Weide and R. Zellich 561 9. References 563 [1] D. Crocker: "Standard for the format of ARPA Internet 564 text messages." STD 11, RFC 822, August 1982. 566 [2] S. Hardcastle-Kille: "Mapping between X.400(1988) / ISO 567 10021 and RFC 822", RFC 1327 May 1992. 569 [3] ISO/ITU: "Message Handling Systems", ISO international 570 standard 10021, ITU recommendation X.400. 572 [4] ISO/ITU: "Message Handling Systems, Part 7: Interpersonal 573 Messaging System, ISO international standard 10021-7, ITU 574 recommendation X.420. 576 [5] N. Freed, N. Borenstein, "Multipurpose Internet Mail 577 Extensions (MIME) Part One: Format of Internet Message 578 Bodies", RFC 2045, December 1996 580 [6] K. Moore, G. Vaudreuil, "An Extensible Message Format for 581 Delivery Status Notifications", RFC 1894, January 1996. 583 [7] K. Moore, "SMTP Service Extension for Delivery Status 584 Notifications", RFC 1891, January 1996. 586 [8] M.R. Horton, R. Adams: "Standard for interchange of 587 USENET messages", RFC 1036, December 1987. 589 [9] B. Ramsdell: S/MIME Version 3 Message Specification. Work 590 in progress. 592 [10] J. Callas, L. Donnerhacke, H. Finney, R. Thayer: OpenPGP 593 Message Format. Work in progress. 595 [11] J. Palme: "Advise on the implementation of In-Reply-To, 596 References and Supersedes e-mail and netnews headers", 597 draft-palme-newfields-info-02.doc, March 1998. 599 [12] D. Crocker: Augmented BNF for Syntax Specifications: 600 ABNF, RFC 2234, November 1997. 602 10. Author's address 604 Jacob Palme Phone: +46-8-16 16 67 605 Stockholm University/KTH Fax: +46-8-783 08 29 606 Skeppargatan 73 E-mail: jpalme@dsv.su.se 607 S-115 30 Stockholm, Sweden