home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-mailext-new-fields-09.txt < prev    next >
Text File  |  1997-08-21  |  17KB  |  453 lines
  1. Network Working Group                                     Jacob Palme
  2. Internet Draft                               Stockholm University/KTH
  3. <draft-ietf-mailext-new-fields-09.txt>                         Sweden
  4. Category-to-be: Proposed standard                         August 1997
  5. Expires February 1998
  6.  
  7.  
  8.       The Auto-Submitted, Supersedes and Expires E-mail Headers
  9.  
  10.  
  11. Status of this Memo
  12.  
  13. This document is an Internet-Draft.  Internet-Drafts are working
  14. documents of the Internet Engineering Task Force (IETF), its
  15. areas, and its working groups.  Note that other groups may also
  16. distribute working documents as Internet-Drafts.
  17.  
  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.''
  23.  
  24. To learn the current status of any Internet-Draft, please check
  25. the ``1id-abstracts.txt'' listing contained in the Internet-
  26. Drafts Shadow Directories on ftp.is.co.za (Africa),
  27. nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  28. ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
  29.  
  30. This memo provides information for the Internet community. This
  31. memo does not specify an Internet standard of any kind, since
  32. this document is mainly a compilation of information taken from
  33. other RFC-s.. Distribution of this memo is unlimited.
  34.  
  35.  
  36. Abstract
  37.  
  38. This memo introduces three new e-mail (RFC 822) headers, Auto-Submitted,
  39. Supersedes, and Expires.
  40.  
  41.  
  42. Differences from previous version
  43.  
  44. Some minor wording changes in the definitions of what is and what is not
  45. to be regarded as autosubmitted, otherwise no changes. If an automatic
  46. message is generated whenever a file has been changed by a human, is
  47. this auto-submitted or not? The spec now says that if the SMTP-sender of
  48. such a notification is the human who changed the file, then this is not
  49. auto-submitted, but otherwise it is. But the spec also says that this is
  50. a borderline case, and that exact definitions of the border between
  51. auto-submitted and not auto-submitted cannot always be made.
  52.  
  53.  
  54. Table of contents
  55.  
  56. 1. Introduction
  57. 2. Auto-Submitted
  58.  2.1 Syntax:
  59.  2.2 Semantics
  60.  2.3 Relation to NOTIFY ESMTP command
  61.  2.4 Examples
  62.    2.4.1 Syntax examples without private extensions:
  63.    2.4.2 Possible syntax examples with private or future
  64.    extensions:
  65.    2.4.3 Auto-Submitted: no or no Auto-Submitted header
  66.    2.4.4 Keep the field in forwarded message
  67.    2.4.5 Auto-Submitted: auto-generated
  68.    2.4.6 Auto-Submitted: auto-replied
  69. 3. Supersedes
  70. 4. Expires:
  71. 5. Relation to X.400 gateways versus Netnews
  72. 6. Security considerations
  73.  6.1 "Auto-Submitted" security considerations
  74.  6.2 "Supersedes" security considerations
  75.  6.3 "Expires" security considerations
  76. 7. Acknowledgments
  77. 8. References
  78. 9. Author's address
  79.  
  80.  
  81. 1.    Introduction
  82.  
  83. This memo introduces three new headers for Internet e-mail (RFC 822)
  84. headers which will enhance the e-mail service in various ways. The names
  85. of the new headers are: Auto-Submitted, Supersedes and Expires.
  86.  
  87.  
  88. 2.    Auto-Submitted
  89.  
  90. 2.1   Syntax:
  91.  
  92.      auto-submitted-field     = "Auto-Submitted ":"
  93.                                 auto-submitted
  94.  
  95.      auto-submitted           = ( "no" / "auto-generated" /
  96.                                 "auto-replied" /
  97.                                 "x-" <private-extension> /
  98.                                 "<future-extension> )
  99.                                 <optional-parameter-list>
  100.  
  101.     <optional-parameter-list> = *( ";" <optional-parameter> )
  102.  
  103. Note 1: All the syntax specified above is case-insensitive. Thus
  104. "Auto-Submitted: Auto-Replied" is identical to "auto-submitted:
  105. auto-replied" or "aUTO-sUBMITTED: aUTO-rEPLIED".
  106.  
  107. Note 2: <private extension>, <future extension> and <optional-parameter>
  108. are not defined in this standard, but their syntax is specified as
  109. placeholders for future extensions. An implementation of this standard
  110. which encounters such extensions, but which does not support them, can
  111. simply ignore them.
  112.  
  113.  
  114. 2.2   Semantics
  115.  
  116. This field indicates whether the message was sent with or without
  117. explicit human control.
  118.  
  119. Note 1: A similar header field is defined in X.420 [4].
  120.  
  121. Note 2: If a message does not have any Auto-Submitted header, no
  122. assumption SHOULD be made of whether this message was automatically
  123. generated or not.
  124.  
  125.  
  126. 2.3   Relation to NOTIFY ESMTP command
  127.  
  128. This standard does not specify handling of Delivery Status
  129. Notifications. Such notifications are requested by the ESTMP NOTIFY
  130. command [7] and DSNs themselves need not contain any auto-submitted
  131. header, since their mode of submission is shown by the DSN format as
  132. defined in the DSN standards [6].
  133.  
  134.  
  135. 2.4   Examples
  136.  
  137. 2.4.1 Syntax examples without private extensions:
  138.  
  139. Example 1:   Auto-Submitted: auto-generated
  140.  
  141. Example 2:   Auto-Submitted: auto-replied
  142.  
  143. Example 3:   Auto-Submitted: no
  144.  
  145.  
  146. 2.4.2 Possible syntax examples with private or future extensions:
  147.  
  148. Example 4:   Auto-Submitted: x-ibm-transaction
  149.  
  150. Example 5:   Auto-Submitted: auto-replied ; bounced
  151.  
  152.  
  153. 2.4.3 Auto-Submitted: no or no Auto-Submitted header
  154.  
  155. In the following cases the "Auto-Submitted: no" header, or no
  156. Auto-Submitted header shall be generated.
  157.  
  158. >  Ordinary e-mail messages written by a person.
  159.  
  160. >  A person interacts with a mail-generating client, e.g. instructs
  161.    it to join a mailing list, and the client generates a message to a
  162.    listserver with commands for subscribing to the list.
  163.  
  164. >  A person interacts with a World Wide Web form, such that the
  165.    filled-in form is automatically sent to an e-mail address
  166.    specified in the WWW form document.
  167.  
  168.  
  169. 2.4.4 Keep the field in forwarded message
  170.  
  171. In the following cases, an existing Auto-Submitted header on a
  172. forwarded message SHOULD be kept as it is.
  173.  
  174. >  A moderator accepts messages to a moderated group, and forwards
  175.    the accepted messages to the group members, possibly merged into
  176.    a digest by software for producing digests.
  177.  
  178. >  Automatic forwarding by mailing list expanders or to a new
  179.    e-mail address for the recipient.
  180.  
  181.  
  182. 2.4.5 Auto-Submitted: auto-generated
  183.  
  184. >  An automatic weather-station sends automatic messages with
  185.    temperature, wind velocity, etc. to a weather data base server.
  186.  
  187. >  An automatically generated weather-report is sent once every
  188.    three hours to subscribing customers.
  189.  
  190. >  An automatic computer process sends failure reports.
  191.  
  192. >  An automatic vote counter counts incoming votes and reports on
  193.    the outcome of the vote.
  194.  
  195. >  A subscription service sends copies of a file every time the file
  196.    is updated to people subscribing to such updates. If the
  197.    subscription server wants notifications when the subscriber address
  198.    is faulty, it can request them with the NOTIFY ESMTP command.
  199.  
  200.    Note: This is a borderline case. If the sent files has as SMTP-sender
  201.    the person who modified this file, it should not be regarded as
  202.    auto-submitted.
  203.  
  204.  
  205. 2.4.6 Auto-Submitted: auto-replied
  206.  
  207. >  A mail server responds to an incoming request message.
  208.  
  209. Many uses of this header field is for special kinds of notifications,
  210. such as:
  211.  
  212. >  A notification asking you to confirm your subscription to a mailing
  213.    list, which is sent to you automatically by the mailing-list-server
  214.    every six month.
  215.  
  216. >  A vacation server sends a vacation notification in response to an
  217.    incoming message for the person who is on vacation.
  218.  
  219. >  A notification that a message, after receipt, has been purged,
  220.    forwarded or handled in some other special way.
  221.  
  222.  
  223. 3.    Supersedes
  224.  
  225. Syntax: supersedes-field = "Supersedes" ":" 1*msg-id
  226.  
  227. The message identifiers (msg-id) use the msg-id format, as defined in
  228. RFC 822 [1].
  229.  
  230. Note that there is no comma between multiple values, and that each
  231. Message-ID value is to be surrounded by angle brackets.
  232.  
  233. The Supersedes header identifies previous correspondence, which this
  234. message supersedes. A user agent is expected to handle this field in
  235. much the same way as the In-Reply-To and References header.
  236.  
  237. (a) Thus, this header does not imply any mandatory deletion of the
  238. previous correspondence.
  239.  
  240. (b) User agents which provide user commands for getting from a reply to
  241. the replied-to message (or for getting from a replied-to message to its
  242. replies), MAY provide similar commands for getting from a superseding
  243. message to the superseded message (or for getting from a superseded
  244. message to its superseding version).
  245.  
  246. (c) User agents MAY normally show the recipient both the previous and
  247. the superseding message. If, however, both the previous and the
  248. superseding message have arrived, both having the same author, but the
  249. user has not yet seen either of them, a user agent MAY show only the
  250. superseding message, but also show the supersedes-field to inform the
  251. recipient that this message supersedes a previous message.
  252.  
  253. (d) User agents might issue a warning if a superseding message arrives
  254. with a different author than the author of the superseded message. This
  255. can be done by checking the "From:" header, or, if PEM [9], PGP [10] or
  256. MOSS [11] signatures are available, by checking the digital signature.
  257.  
  258. The above procedure is called a "soft supersedes".
  259.  
  260. Some user agents or servers may delete the old version of a message when
  261. a new version arrives, which is called a "hard supersedes". Hard
  262. supersedes is NOT RECOMMENDED practice, but common, especially in
  263. netnews where servers want to save disk space.
  264.  
  265. When this is written (1997) some netnews softwares (servers and clients)
  266. cannot handle Supersedes with more than one previous articles listed as
  267. parameters. They usually ignore the Supersedes header in this case, and
  268. treats the new article as a separate article, not related to the
  269. superseded article. Implementors of netnews softwares SHOULD modify
  270. their software to be able to handle Supersedes with more than one
  271. previous article as parameter, but for some time, many softwares may not
  272. be able to handle Supersedes with more than one parameter. A gateway
  273. from e-mail to news MAY because of this delete all but the first
  274. parameter of this attribute when conveying messages from e-mail to news,
  275. BUT such a practice should be temporary only for one or two years until
  276. news softwares have been modified.
  277.  
  278. Warning: This header MUST be spelled "Supersedes" and not "Supercedes".
  279. Mailers MUST never generate "Supercedes" but MAY accept "Supercedes" in
  280. input.
  281.  
  282. Note: The Message-ID of a superseding message MUST be different from the
  283. Message-ID of the superseded message. The Message-ID of the superseded
  284. message is used as value in the "Supersedes:" header, not in the
  285. Message-ID of the superseding message.
  286.  
  287.  
  288. 4.    Expires:
  289.  
  290. Syntax: Expires-field = "Expires" ":" date-time
  291.  
  292. The Expires header indicates a date-time, at which this message expires.
  293. The field can be used both to limit and to extend the life of a message.
  294. User agents and servers which employ automatic purging of old messages
  295. MAY let this field influence the purging process. There is no
  296. requirement that a user agent must suppress expired messages or make
  297. them inaccessible to their owners.
  298.  
  299. Note: This header is also defined, with similar meaning, in netnews [8]
  300. and in X.420 [4].
  301.  
  302.  
  303. 5.    Relation to X.400 gateways versus Netnews
  304.  
  305. Similar headers to Supersedes and Expires are also defined in
  306. recommendations for gatewaying [2] between X.400 [4] and Internet mail.
  307. However, those recommendations are only valid for gateways. By defining
  308. the fields here, the fields are made available for general Internet
  309. e-mail usage. This document also gives fuller descriptions of the fields
  310. than is given by the X.400 gatewaying recommendations [2]. Also an
  311. Auto-Submitted feature has recently been added to X.400, with similar
  312. definition as in this document.
  313.  
  314. Unfortunately, the two new headers Supersedes and Expires have different
  315. names in  Internet-X.400 gatewaying standards [2] and in netnews.
  316.  
  317. RFC 1327 [2] gives the name "Obsoletes:" for what in netnews is usually
  318. called "Supersedes:" (not specified in RFC 1036 [8] but in common
  319. usage).
  320.  
  321. RFC 1327 gives the name "Expiry-Date:" for what in netnews is called
  322. "Expires:" (as specified in RFC 1036).
  323.  
  324. Because compatibility with netnews is more important than with X.400,
  325. the netnews names of these two fields are proposed here.
  326.  
  327. Future versions of RFC 1327 (the MIXER document) may choose to specify
  328. the use of "Supersedes" and "Expires" also in gatewayed messages from
  329. X.400.
  330.  
  331.  
  332. 6.    Security considerations
  333.  
  334. 6.1   "Auto-Submitted" security considerations
  335.  
  336. "Auto-submitted:" raises no new security concerns, instead, it reduces
  337. the risk to security of certain kinds of loops.
  338.  
  339.  
  340. 6.2   "Supersedes" security considerations
  341.  
  342. If a mail or news server or receiving user agent suppresses showing of
  343. superseded messages, the "Supersedes:" feature might be used maliciously
  344. to suppress messages written by other people. To reduce the risk for
  345. this, it is RECOMMENDED that user agents give a warning to the recipient
  346. when a superseding message has a different "From:" name than the
  347. superseded message.
  348.  
  349. A moderately clever forger can of course circumvent this by sending
  350. messages with falsified "From:" field and even falsified SMTP senders.
  351. User agents supporting PEM [9] or PGP [10] can require and check digital
  352. signatures to reduce also this risk.
  353.  
  354. Another possible risk with "Supersedes:" is that it allows people to
  355. "change their minds", possibly changing the meaning of replies to them.
  356. Example: A message with the text "Do you like your mother" gets the
  357. reply "Yes, very much", and then the original message might be changed
  358. to "Do you like Hitler", changing the meaning of the reply. Note,
  359. however, that the "In-Reply-To" or "References" headers in the reply
  360. refers to the Message-ID of the original message, not of the superseding
  361. message. Thus, a user agent can avoid this problem by designing the user
  362. interface so that replies are not shown as referring to the superseding
  363. message, when they use the Message-ID of the superseded message.
  364.  
  365. Also, since "Supersedes:" in e-mail does not actually cause deletion of
  366. the superseded message, recipients can look up the superseded message to
  367. see if the author has changed his mind. In general, it is not illegal or
  368. unethical to change your mind, rather, it shows your openness to new
  369. ideas and willingness to listen to the arguments of other people.
  370.  
  371. The fact that Supersedes in e-mail does not enforce deletion of the
  372. supersedes message, but that Supersedes in many existing netnews
  373. implementations does enforce such deletion, may in some circumstances
  374. cause security problems.
  375.  
  376.  
  377. 6.3   "Expires" security considerations
  378.  
  379. One intention of "Expires" is to help recipients avoid seeing messages
  380. with information which is not any longer valid. There may of course be
  381. cases where a user might want to see an expired message (e.g. a user
  382. might sometimes want to be informed of a meeting, even after the time of
  383. the meeting). This could possibly be solved by having different kinds of
  384. "Expires" for different expiration causes, however, this complexity is
  385. not felt needed at present. A user agent can of course be designed to
  386. inform the recipient also of expired messages, and allow the recipient
  387. the choice of reading them or not. This standard does, therefore, not
  388. require user agents to make expired messages inaccessible.
  389.  
  390.  
  391. 7.    Acknowledgments
  392.  
  393. Many people have helped with the production of this document. Of special
  394. value have been H. T. Alvestrand, S. Kille, K. Moore, P. Overell, Uzi
  395. Paz and K. Weide.
  396.  
  397.  
  398. 8.    References
  399.  
  400. [1]  D. Crocker: "Standard for the format of ARPA Internet text
  401.      messages." STD 11, RFC 822, August 1982.
  402.  
  403. [2]  S. Hardcastle-Kille: "Mapping between X.400(1988) / ISO 10021
  404.      and RFC 822",  RFC 1327 May 1992.
  405.  
  406. [3]  ISO/ITU: "Message Handling Systems", ISO international standard
  407.      10021, ITU  recommendation X.400.
  408.  
  409. [4]  ISO/ITU: "Message Handling Systems, Part 7: Interpersonal
  410.      Messaging System, ISO international standard 10021-7, ITU
  411.      recommendation X.420.
  412.  
  413. [5]  N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions
  414.      (MIME) Part One: Format of Internet Message Bodies", RFC 2045,
  415.      December 1996
  416.  
  417. [6]  K. Moore, G. Vaudreuil, "An Extensible Message Format for
  418.      Delivery Status Notifications", RFC 1894, January 1996.
  419.  
  420. [7]  K. Moore, "SMTP Service Extension for Delivery Status
  421.      Notifications", RFC 1891, January 1996.
  422.  
  423. [8]  M.R. Horton, R. Adams: "Standard for interchange of USENET
  424.      messages", RFC 1036, December 1987.
  425.  
  426. [9]  S. Kent, J. Linn, D. Balenson, B. Kaliski: 1421 Privacy
  427.      Enhancement for Internet Electronic Mail: Part I-IV,
  428.      RFC 1421-1424, February 1993.
  429.  
  430. [10] Gary B. Edstrom: Frequently Asked Questions; alt.security.pgp.
  431.      Available from faq servers, such as URL: gopher:
  432.      //nutmeg.ukc.ac.uk.:70/11/.archive/uunet/usenet/news.answers/
  433.      pgp-faq.
  434.  
  435. [11] S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object Security
  436.      Services", RFC 1848, March 1995.
  437.  
  438. [12] J. Palme: "Loop control for the Auto-Submitted e-mail header",
  439.      draft-palme-autosub-03.txt, July 1997.
  440.  
  441. [13] J. Palme: "Advise on the implementation of In-Reply-To,
  442.      References and Supersedes e-mail and netnews headers",
  443.      draft-palme-newfields-info-00.doc, July 1997.
  444.  
  445.  
  446. 9.    Author's address
  447.  
  448. Jacob Palme                          Phone: +46-8-16 16 67
  449. Stockholm University/KTH             Fax: +46-8-783 08 29
  450. Skeppargatan 73                      E-mail: jpalme@dsv.su.se
  451. S-115 30 Stockholm, Sweden
  452.  
  453.