idnits 2.17.1 draft-ietf-mailext-new-fields-13.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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 703 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 different from "no". == 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: (2) For moderated newsgroups and mailing lists, the moderator. Note that a moderator may only supersede messages/articles in groups, for which the moderator is responsible, and such a moderator SHOULD not send superseding messages/articles to other groups. -- 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 (January 1999) is 9225 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 151 -- Looks like a reference, but probably isn't: 'CFWS' on line 498 == Unused Reference: '3' is defined on line 645, 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' == Outdated reference: A later version (-02) exists of draft-palme-newfields-info-01 -- Possible downref: Normative reference to a draft: ref. '11' ** Obsolete normative reference: RFC 2234 (ref. '12') (Obsoleted by RFC 4234) Summary: 14 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jacob Palme 2 Internet Draft Stockholm University/KTH 3 draft-ietf-mailext-new-fields-13.txt Sweden 4 July 1998 5 Expires January 1999 7 The Auto-Submitted, Supersedes and Expires Headers in E-mail and Netnews 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check 23 the ``1id-abstracts.txt'' listing contained in the Internet- 24 Drafts Shadow Directories on ftp.is.co.za (Africa), 25 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 26 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 Copyright (C) The Internet Society 1998. All Rights Reserved. 30 Abstract 32 This memo introduces three new e-mail headers, Auto-Submitted, 33 Supersedes, and Expires. 35 Differences from version 12 37 The syntax for parameters to the Auto-Submitted header is better 38 specified. 40 The list of examples in section 3.5.1 have been extended with more 41 examples. 43 The text about the Supersedes header (4.2.2 to 4.2.3) has been modified 44 to more clearly indicate when soft and hard supersedes are to be 45 implemented and to reflect current usage. 47 The text about the Supersedes header (4.2.1) has been modified to more 48 clearly show who are allowed to issue superseding messages. 50 Table of contents 52 1. Introduction 53 2. Syntax elements 54 2.1 Identifier 55 2.2 date-time 56 3. Auto-Submitted 57 3.1 Syntax: 58 3.2 Semantics 59 3.3 Relation to NOTIFY ESMTP command 60 3.4 Parameters 61 3.5 Fuller semantics with examples 62 3.5.1 Syntax examples without private extensions: 63 3.5.2 Possible syntax examples with private or future 64 extensions: 65 3.5.3 Auto-Submitted: no or no Auto-Submitted header 66 3.5.4 Keep the field in forwarded message 67 3.5.5 Auto-Submitted: auto-generated 68 3.5.6 Auto-Submitted: auto-replied 69 3.5.7 Recipient use of Auto-Submitted fields 70 4. Supersedes 71 4.1 Syntax 72 4.2 Semantics 73 5. Expires: 74 6. Relation to X.400 gateways versus Netnews 75 7. Security considerations 76 7.1 "Auto-Submitted" security considerations 77 7.2 "Supersedes" security considerations 78 7.3 "Expires" security considerations 79 8. Copyright 80 9. Acknowledgments 81 10. References 82 11. Author's address 84 1. Introduction 86 This memo introduces three new header fields for Internet e-mail [1] and 87 Usenet News [8] headers, which will enhance the e-mail service in 88 various ways. The names of the new headers are: Auto-Submitted, 89 Supersedes and Expires. 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119. 95 An informational RFC [11] with advice on the implementation of the 96 features specified in this standard will simultaneously be published. 98 2. Syntax elements 100 This section defines some syntax elements needed for the 101 syntax specifications of the new fields. The syntax is defined 102 using the ABNF rules from [12]. 104 2.1 Identifier 106 identifier = "<" id-left-side "@" id-right-side ">" 108 id-left-side = dot-atom-text / no-fold-quote 110 id-right-side = dot-atom-text / no-fold-literal 112 no-fold-quote = DQUOTE *(qtext / quoted-pair) DQUOTE 114 dot-atom-text = 1*atext *("." 1*atext) 116 atext = ALPHA / DIGIT / ; Any character except controls, 117 "!" / "#" / ; SP, and specials. 118 "$" / "%" / ; Used for atoms 119 "&" / "'" / 120 "*" / "+" / 121 "-" / "/" / 122 "=" / "?" / 123 "^" / "_" / 124 "`" / "{" / 125 "|" / "}" / 126 "~" 128 qtext = NO-WS-CTL / ; Non-white-space controls 129 %d33 / ; The rest of the US-ASCII 130 %d35-91 / ; characters not including "\" 131 %d93-127 ; or the quote character 133 quoted-pair = ("\" text) 135 text = %d1-9 / ; Characters excluding CR and LF 136 %d11-12 / 137 %d14-127 139 WSP = SP / HTAB ; Whitespace characters 141 FWS = ([*WSP CRLF] 1*WSP) ; Folding white-space 143 ctext = NO-WS-CTL / ; Non-white-space controls 144 %d33-39 / ; The rest of the US-ASCII 145 %d42-91 / ; characters not including "(", 146 %d93-127 ; ")", or "\" 148 comment = "(" *([FWS] (ctext / quoted-pair / comment)) 149 [FWS] ")" 151 CFWS = *([FWS] comment) (([FWS] comment) / FWS) 153 2.2 date-time 155 date-time = [ day-of-week "," ] date CFWS time [CFWS] 157 day-of-week = CFWS day-name CFWS 159 day-name = "Mon" / "Tue" / "Wed" / "Thu" / 160 "Fri" / "Sat" / "Sun" 162 date = day month year 164 year = ([CFWS] 4*DIGIT [CFWS]) / obs-year 166 month = CFWS month-name CFWS 168 month-name = "Jan" / "Feb" / "Mar" / "Apr" / 169 "May" / "Jun" / "Jul" / "Aug" / 170 "Sep" / "Oct" / "Nov" / "Dec" 172 day = [CFWS] 1*2DIGIT [CFWS] 174 time = time-of-day CFWS zone 176 time-of-day = hour ":" minute [ ":" second ] 178 hour = [CFWS] 2DIGIT [CFWS] 180 minute = [CFWS] 2DIGIT [CFWS] 182 second = [CFWS] 2DIGIT [CFWS] 184 zone = (( "+" / "-" ) 4DIGIT) / obs-zone 186 3. Auto-Submitted 188 3.1 Syntax: 190 auto-submitted-field = "Auto-Submitted:" [CFWS] 191 auto-submitted [CFWS] CRLF 193 auto-submitted = ( "no" / "auto-generated" / 194 "auto-replied" / 195 private-extension / 196 future-extension ) 197 optional-parameter-list 199 private-extension = x-token 201 Future-extension = token 203 The symbols "token", "x-token", and "parameter" are as 204 defined in MIME [5]. 206 optional-parameter-list = *( ";" [CFWS] parameter ) 208 parameter = parameter-name [ "=" 209 parameter-value ] 211 parameter-name = "increment" / 212 private-parameter / 213 future-parameter 215 Note 1: All the syntax specified above is case-insensitive. Thus 216 "Auto-Submitted: Auto-Replied" is identical to "auto-submitted: 217 auto-replied" or "aUTO-sUBMITTED: aUTO-rEPLIED". 219 Note 2: The syntax for private-extension and future-extension is 220 specified as a placeholder for future extensions. private-extension 221 keywords must begin with "x-", future extension keywords may be defined 222 only by standards-track RFCs, or by Informational or Experimental RFCs 223 with approval of the IESG. Implementations which examine the value of 224 the Auto-Submitted field should handle an Auto-Submitted field which 225 contains an unrecognized private-extension or future-extension keyword 226 as if the message had been automatically submitted, but without 227 information about the type of auto-submission. 229 3.2 Semantics 231 This field indicates whether the message was sent with or without 232 explicit human control. 234 The auto-generated keyword: 236 SHOULD be used on messages generated by automatic (often periodic) 237 processes, 238 MUST NOT be used on manually generated messages, 239 MUST NOT be used on a message issued in direct response to another 240 message. 242 The auto-replied keyword: 244 SHOULD be used on messages sent in direct response to another message, 245 MUST NOT be used on manually-generated messages, 246 MUST NOT be used on messages generated by automatic or periodic 247 processes. 249 Note 1: A similar header field is defined in X.420 [4]. 251 Note 2: If a message does not have any Auto-Submitted header, no 252 assumption should be made of whether this message was automatically 253 generated or not. 255 The "comment" syntactical construct can be used to indicate a reason why 256 this message was auto-submitted. 258 3.3 Relation to NOTIFY ESMTP command 260 This standard does not specify handling of Delivery Status 261 Notifications. Such notifications are requested by the ESTMP NOTIFY 262 command [7] and DSNs themselves need not contain any auto-submitted 263 header, since their mode of submission is shown by the DSN format as 264 defined in the DSN standards [6]. 266 3.4 Parameters 268 Only one optional parameter is defined here. This parameter 269 has the attribute name "increment" and the value a number 270 (1*DIGIT) which indicates the number of seconds since the last 271 time a similar auto-submitted message was produced by the same 272 sender to any recipient. This parameter might be useful to 273 detect and counteract a looping auto-submitter. 275 3.5 Fuller semantics with examples 277 3.5.1 Syntax examples without private extensions: 279 Example 1: Auto-Submitted: auto-generated 281 Example 2: Auto-Submitted: auto-replied 283 Example 3: Auto-Submitted: no 285 Example 4: Auto-Submitted: auto-generated; increment=21600 287 Example 5: Auto-Submitted: (weather-report) auto-generated; 288 (issued every 6 hours) increment=21600 290 3.5.2 Possible syntax examples with private or future extensions: 292 Example 6: Auto-Submitted: x-ibm-transaction 294 Example 7: Auto-Submitted: auto-replied ; bounced 296 Example 8: Auto-Submitted: auto-replied ; x-count=8 298 3.5.3 Auto-Submitted: no or no Auto-Submitted header 300 In the following cases the "Auto-Submitted: no" header, or no 301 Auto-Submitted header shall be generated. 303 - Ordinary e-mail messages written by a person. 305 - A person interacts with a mail-generating client, e.g. instructs 306 it to join a mailing list, and the client generates a message to a 307 listserver with commands for subscribing to the list. 309 - A person interacts with a World Wide Web form, such that the 310 filled-in form is automatically sent to an e-mail address 311 specified in the WWW form document. 313 3.5.4 Keep the field in forwarded message 315 In the following cases, an existing Auto-Submitted header on a 316 forwarded message SHOULD be kept as it is. 318 - A moderator accepts messages to a moderated group, and forwards 319 the accepted messages to the group members, possibly merged into 320 a digest by software for producing digests. 322 - Automatic forwarding by mailing list expanders or to a new 323 e-mail address for the recipient. 325 3.5.5 Auto-Submitted: auto-generated 327 An Auto-Submitted field with the auto-generated keyword SHOULD be 328 supplied with a message that is automatically generated, but not one 329 which is an automatic response to an emailed request. Examples of 330 automatically generated messages include: 332 - An automatic weather station sends periodic messages with 333 temperature, wind velocity, etc. to a weather database server. 335 - An automatically generated weather-report is sent once every 336 three hours to subscribing customers. 338 - An automatic computer process (for example, a "cron job") sends 339 failure reports. 341 - An automatic vote counter counts incoming votes and reports on 342 the outcome of the vote. 344 - A subscription service sends copies of a file every time the file 345 is updated to people subscribing to such updates. 347 Note: This is a borderline case. If the sent files has as SMTP-sender 348 the person who modified this file, it should not be regarded as 349 auto-submitted. 351 - A notification asking you to confirm your subscription to a mailing 352 list, which is sent to you automatically by the mailing-list-server 353 every six months. 355 3.5.6 Auto-Submitted: auto-replied 357 An Auto-Submitted field with the auto-replied keyword SHOULD be included 358 in any message issued as an automatic response to another message. 359 Example: 361 - A mail server responds to an incoming request message. 363 Many uses of this header field is for special kinds of notifications, 364 such as: 366 - A vacation server sends a vacation notification in response to an 367 incoming message for the person who is on vacation. 369 - A notification that a message, after receipt, has been purged, 370 forwarded or handled in some other special way. 372 3.5.7 Recipient use of Auto-Submitted fields 374 The Auto-Submitted field may be used by recipients (human or 375 otherwise) to aid in processing the message. For example: 377 - A mailing list may wish, as a matter of policy, to accept 378 only human-generated input. It may therefore wish to filter 379 out any messages including the Auto-Submitted header field, 380 if the keyword is other than "no". 382 - A process which automatically responds to messages (for 383 example, a "vacation server"), may be intended to send 384 responses only to humans, and not to auto-generated or 385 auto-replied messages. Such a process SHOULD not respond 386 to messages with an Auto-Submitted field with a keyword 387 different from "no". 389 4. Supersedes 391 4.1 Syntax 393 Supersedes-field = "Supersedes:" [CFWS] identifier *([CFWS] 394 identifier) [CFWS] CRLF 396 Note: There is no comma between multiple values, and that each 397 Message-ID value is to be surrounded by angle brackets. 399 Warning: Usenet News software may not work correctly with comments in 400 header fields, especially comments in other places than at the beginning 401 and end of the field value. 403 Warning: This header MUST be spelled "Supersedes" and not "Supercedes". 404 Mailers MUST never generate "Supercedes" but MAY accept "Supercedes" in 405 input. 407 4.2 Semantics 409 The Supersedes header identifies previous correspondence, which this 410 message supersedes. Different messaging agents such as user agents, 411 mailing list expanders, mailing list archives and Usenet News servers 412 may handle the Supersedes header. A user agent is expected to handle 413 this field in much the same way as the In-Reply-To and References 414 header. 416 Note: The Message-ID of a superseding message MUST be different from the 417 Message-ID of the superseded message. The Message-ID of the superseded 418 message is used as value in the "Supersedes:" header, not in the 419 Message-ID of the superseding message. 421 4.2.1 Who may supersede a message/article? 423 Agents receiving superseding messages may ignore, or issue a warning, if 424 the Supersedes header, if the author of the message is not approved. 425 Approved authors of superseding messages are: 427 (1) The author of the message being superseded. 429 (2) For moderated newsgroups and mailing lists, the moderator. Note that 430 a moderator may only supersede messages/articles in groups, for 431 which the moderator is responsible, and such a moderator SHOULD not 432 send superseding messages/articles to other groups. 434 (3) Other users given the authority to supersede messages. Such 435 authority is often local to one particular server only. 437 An agent may ignore or issue a warning for Supersedes headers if the 438 Superseding message does not have a digital signature of its author. 439 Digital signatures are separately standardized (like SMIME [9] and PGP 440 [10] or other standards for digital signatures) and their format and 441 semantics are not specified in this standard. 443 4.2.2 Semantic variant 1: Soft supersedes 445 (a) With soft supersedes this header does not imply any mandatory 446 deletion of the previous correspondence in mailboxes and user 447 agent databases. 449 (b) Agents which provide user commands for getting from a reply to 450 the replied-to message (or for getting from a replied-to message to 451 its replies), MAY provide similar commands for getting from a 452 superseding message to the superseded message (or for getting from a 453 superseded message to its superseding version). 455 (c) Agents MAY normally show the recipient both the previous and 456 the superseding message. If, however, both the previous and the 457 superseding message have arrived, both having the same author, but 458 the user has not yet seen either of them, a user agent MAY show only 459 the superseding message, but also show the supersedes-field to 460 inform the recipient that this message supersedes a previous 461 message. 463 4.2.3 Semantic variant 2: Hard supersedes 465 With hard supersedes, the arrival of a superseding message or article 466 will cause the deletion of the superseded message. The new message will 467 however still have a new Message-ID and will not take over the Message- 468 ID of the superseded message/article. 470 4.2.4 When to use soft and hard supersedes 472 Personal mailboxes and personal message stores SHOULD implement soft 473 supersedes. Usenet News servers and multi-user message archives MAY 474 implement HARD supersedes. 476 If the handler of a message/article storage has a mechanism for 477 automatic purging of old messages, the fact that there is a superseding 478 message may be a component in the decision of when to purge the previous 479 version. 481 4.2.5 Multiple field values 483 When this is written (1998) some netnews softwares (servers and clients) 484 cannot handle Supersedes with more than one previous articles listed as 485 parameters. They usually ignore the Supersedes header in this case, and 486 treats the new article as a separate article, not related to the 487 superseded article. Implementors of netnews softwares SHOULD modify 488 their software to be able to handle Supersedes with more than one 489 previous article as parameter, but for some time, many softwares may not 490 be able to handle Supersedes with more than one parameter. A gateway 491 from e-mail to news MAY because of this delete all but the first 492 parameter of this attribute when conveying messages from e-mail to news, 493 BUT such a practice should be temporary only for one or two years until 494 news softwares have been modified. 496 5. Expires: 498 Syntax: Expires-field = "Expires:" [CFWS] date-time [CFWS] CRLF 500 The Expires header indicates a date-time, at which this message expires. 501 The field can be used both to limit and to extend the life of a message. 502 User agents and servers which employ automatic purging of old messages 503 MAY let this field influence the purging process. There is no 504 requirement that a user agent must suppress expired messages or make 505 them inaccessible to their owners. 507 Note: This header is also defined, with similar meaning, in netnews [8] 508 and in X.420 [4]. 510 6. Relation to X.400 gateways versus Netnews 512 Similar headers to Supersedes and Expires are also defined in 513 recommendations for gatewaying [2] between X.400 [4] and Internet mail. 514 However, those recommendations are only valid for gateways. By defining 515 the fields here, the fields are made available for general Internet 516 e-mail usage. This document also gives fuller descriptions of the fields 517 than is given by the X.400 gatewaying recommendations [2]. Also an 518 Auto-Submitted feature has been added to X.420, with similar definition 519 as in this document. 521 Unfortunately, the two new headers Supersedes and Expires have different 522 names in Internet-X.400 gatewaying standards [2] and in netnews. 524 RFC 1327 [2] gives the name "Obsoletes:" for what in netnews is usually 525 called "Supersedes:" (not specified in RFC 1036 [8] but in common 526 usage). 528 RFC 1327 gives the name "Expiry-Date:" for what in netnews is called 529 "Expires:" (as specified in RFC 1036). 531 Because compatibility with netnews is more important than with X.400, 532 the netnews names of these two fields are proposed here. 534 Future versions of RFC 1327 (the MIXER document) may choose to specify 535 the use of "Supersedes" and "Expires" also in gatewayed messages from 536 X.400. 538 7. Security considerations 540 7.1 "Auto-Submitted" security considerations 542 "Auto-submitted:" raises no new security concerns, instead, it reduces 543 the risk to security of certain kinds of loops. Automatically submitting 544 messages has, of course, several security concerns, but these security 545 concerns do not become more severe if a header is defined to specify if 546 a message is auto-submitted or not. 548 7.2 "Supersedes" security considerations 550 If a mail or news server or receiving user agent suppresses showing of 551 superseded messages, the "Supersedes:" feature might be used maliciously 552 to suppress messages written by other people. To reduce the risk for 553 this, it is RECOMMENDED that user agents give a warning to the recipient 554 when a superseding message has a different "From:" name than the 555 superseded message. 557 A moderately clever forger can of course circumvent this by sending 558 messages with falsified "From:" field and even falsified SMTP senders. 559 User agents supporting S/MIME [9] or PGP [10] or other standards for 560 digital signature can require and check digital signatures to reduce 561 also this risk (see section 4.2.1 above). 563 Another possible risk with "Supersedes:" is that it allows people to 564 "change their minds", possibly changing the meaning of replies to them. 565 Example: A message with the text "Do you like your mother" gets the 566 reply "Yes, very much", and then the original message might be changed 567 to "Do you like Hitler", changing the meaning of the reply. Note, 568 however, that the "In-Reply-To" or "References" headers in the reply 569 refers to the Message-ID of the original message, not of the superseding 570 message. Thus, a user agent can avoid this problem by designing the user 571 interface so that replies are not shown as referring to the superseding 572 message, when they use the Message-ID of the superseded message. 574 Also, since "Supersedes:" in e-mail does not actually cause deletion of 575 the superseded message, recipients can look up the superseded message to 576 see if the author has changed his mind. In general, it is not illegal or 577 unethical to change your mind, rather, it shows your openness to new 578 ideas and willingness to listen to the arguments of other people. 580 The fact that some implementations of Supersedes cause deletion of the 581 Superseded message (hard supersedes, section 4.2.3 above), but others do 582 not (soft supersedes, section 4.2.2 above), may cause security problems. 583 To reduce this problem, a server should clarify its policy on this to 584 its users and follow the recommendations in section 4.2.4 above). 586 7.3 "Expires" security considerations 588 One intention of "Expires" is to help recipients avoid seeing messages 589 with information which is not any longer valid. There may of course be 590 cases where a user might want to see an expired message (e.g. a user 591 might sometimes want to be informed of a meeting, even after the time of 592 the meeting). This could possibly be solved by having different kinds of 593 "Expires" for different expiration causes, however, this complexity is 594 not felt needed at present. A user agent can of course be designed to 595 inform the recipient also of expired messages, and allow the recipient 596 the choice of reading them or not. This standard does, therefore, not 597 require user agents to make expired messages inaccessible. 599 8. Copyright 601 "Copyright (C) The Internet Society (date). All Rights 602 Reserved. 604 This document and translations of it may be copied and 605 furnished to others, and derivative works that comment on or 606 otherwise explain it or assist in its implementation may be 607 prepared, copied, published and distributed, in whole or in 608 part, without restriction of any kind, provided that the above 609 copyright notice and this paragraph are included on all such 610 copies and derivative works. However, this document itself may 611 not be modified in any way, such as by removing the copyright 612 notice or references to the Internet Society or other Internet 613 organizations, except as needed for the purpose of developing 614 Internet standards in which case the procedures for copyrights 615 defined in the Internet Standards process must be followed, or 616 as required to translate it into languages other than English. 618 The limited permissions granted above are perpetual and will 619 not be revoked by the Internet Society or its successors or 620 assigns. 622 This document and the information contained herein is provided 623 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 624 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 625 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 626 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 627 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 628 PARTICULAR PURPOSE." 630 9. Acknowledgments 632 Many people have helped with the production of this document. Of special 633 value have been R. Allbery, H. T. Alvestrand, B. Franz, S. Kille, S. 634 Lyall, K. Moore, P. Overell, U. Paz, H. Spencer, J. Stanley, K. Weide 635 and R. Zellich 637 10. References 639 [1] D. Crocker: "Standard for the format of ARPA Internet text 640 messages." STD 11, RFC 822, August 1982. 642 [2] S. Hardcastle-Kille: "Mapping between X.400(1988) / ISO 10021 643 and RFC 822", RFC 1327 May 1992. 645 [3] ISO/ITU: "Message Handling Systems", ISO international standard 646 10021, ITU recommendation X.400. 648 [4] ISO/ITU: "Message Handling Systems, Part 7: Interpersonal 649 Messaging System, ISO international standard 10021-7, ITU 650 recommendation X.420. 652 [5] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions 653 (MIME) Part One: Format of Internet Message Bodies", RFC 2045, 654 December 1996 656 [6] K. Moore, G. Vaudreuil, "An Extensible Message Format for 657 Delivery Status Notifications", RFC 1894, January 1996. 659 [7] K. Moore, "SMTP Service Extension for Delivery Status 660 Notifications", RFC 1891, January 1996. 662 [8] M.R. Horton, R. Adams: "Standard for interchange of USENET 663 messages", RFC 1036, December 1987. 665 [9] B. Ramsdell: S/MIME Version 3 Message Specification. Work in 666 progress. 668 [10] J. Callas, L. Donnerhacke, H. Finney, R. Thayer: OpenPGP Message 669 Format. Work in progress. 671 [11] J. Palme: "Advise on the implementation of In-Reply-To, 672 References and Supersedes e-mail and netnews headers", 673 draft-palme-newfields-info-01.doc, March 1998. 675 [12] D. Crocker: Augmented BNF for Syntax Specifications: ABNF, 676 RFC 2234, November 1997. 678 11. Author's address 680 Jacob Palme Phone: +46-8-16 16 67 681 Stockholm University/KTH Fax: +46-8-783 08 29 682 Skeppargatan 73 E-mail: jpalme@dsv.su.se 683 S-115 30 Stockholm, Sweden