Network Working Group                                     Jacob Palme
Internet Draft                               Stockholm University/KTH
<draft-ietf-mailext-new-fields-12.txt>                         Sweden
Category-to-be: Proposed standard                        January 1998
Expires August 1998



The Auto-Submitted, Supersedes and Expires Headers in E-mail and Netnews


Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups.  Note that other groups may also
distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time.  It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
``work in progress.''

To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

This memo provides information for the Internet community. This
memo does not specify an Internet standard of any kind, since
this document is mainly a compilation of information taken from
other RFC-s.. Distribution of this memo is unlimited.

Copyright (C) The Internet Society 1998. All Rights Reserved.


Abstract

This memo introduces three new e-mail headers, Auto-Submitted,
Supersedes, and Expires.


Differences from version 11

The syntax definitions have been changed to agree with the new ABNF and
the syntax definitions in draft-ietf-drums-msg-fmt-03.txt. This means
that the syntax now explicitly shows where comments and white space
(CFWS) is allowed and that white spaces is no longer allowed between
header name and the succeeding ":".

The new syntax elements have mostly been copied from
draft-ietf-drums-msg-fmt-03.txt. An issue is whether to allow the
obsolete syntax which draft-ietf-drums-msg-fmt-03.txt allows for accept
but not for generation.

Arguments for allowing obsolete elements: Coding of e-mail software will
be simpler, if the same parser is used for new and old fields. However,
this is no big issue, if an implementer writes a parser which accepts
obsolete elements in the new fields, this does not matter very much,
since the generate syntax is not modified.

Arguments for disallowing obsolete elements: Why allow obsolete elements
in new fields?

I have chosen to not allow obsolete syntax elements in the new fields.

One parameter "increment" to the Auto-Submitted header has been defined.


Table of contents

1. Introduction
2. Auto-Submitted
 2.1 Syntax:
 2.2 Semantics
 2.3 Relation to NOTIFY ESMTP command
 2.4 Examples
   2.4.1 Syntax examples without private extensions:
   2.4.2 Possible syntax examples with private or future
   extensions:
   2.4.3 Auto-Submitted: no or no Auto-Submitted header
   2.4.4 Keep the field in forwarded message
   2.4.5 Auto-Submitted: auto-generated
   2.4.6 Auto-Submitted: auto-replied
3. Supersedes
4. Expires:
5. Relation to X.400 gateways versus Netnews
6. Security considerations
 6.1 "Auto-Submitted" security considerations
 6.2 "Supersedes" security considerations
 6.3 "Expires" security considerations
7. Acknowledgments
8. References
9. Author's address


1.    Introduction

This memo introduces three new headers for Internet e-mail (RFC 822)
headers which will enhance the e-mail service in various ways. The names
of the new headers are: Auto-Submitted, Supersedes and Expires.

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.


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 [14].


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 /         ; Characters excluding 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

date-time       =       [ day-of-week "," ] date CFWS time [CFWS]

day-of-week     =       CFWS day-name CFWS

day-name        =       "Mon" / "Tue" / "Wed" / "Thu" /
                        "Fri" / "Sat" / "Sun"

date            =       day month year

year            =       ([CFWS] 4*DIGIT [CFWS]) / obs-year

month           =       CFWS month-name CFWS

month-name      =       "Jan" / "Feb" / "Mar" / "Apr" /
                        "May" / "Jun" / "Jul" / "Aug" /
                        "Sep" / "Oct" / "Nov" / "Dec"

day             =       [CFWS] 1*2DIGIT [CFWS]

time            =       time-of-day CFWS zone

time-of-day     =       hour ":" minute [ ":" second ]

hour            =       [CFWS] 2DIGIT [CFWS]

minute          =       [CFWS] 2DIGIT [CFWS]

second          =       [CFWS] 2DIGIT [CFWS]

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

    optional-parameter-list   = *( ";" [CFWS] parameter )

    private-extension         = x-token

    Future-extension          = token

    The symbols "token", "x-token", and "parameter" are as
    defined in MIME [5].

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 standard does not specify handling of Delivery Status
Notifications. Such notifications are requested by the ESTMP NOTIFY
command [7] and DSNs themselves need not contain any auto-submitted
header, since their mode of submission is 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


3.5.2 Possible syntax examples with private or future extensions:

Example 4:   Auto-Submitted: x-ibm-transaction

Example 5:   Auto-Submitted: auto-replied ; bounced


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 data base 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-server
   every six month.


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 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
  different from "no".


4.    Supersedes

4.1   Syntax

Supersedes-field=       "Supersedes:" [CFWS] identifier *([CFWS]
                        identifier) [CFWS] CRLF

Note that there is no comma between multiple values, and that each
Message-ID value is to be surrounded by angle brackets.


4.2   Semantics

The Supersedes header identifies previous correspondence, which this
message supersedes. A user agent is expected to handle this field in
much the same way as the In-Reply-To and References header.

(a) Thus, this header does not imply any mandatory deletion of the
    previous correspondence.

(b) User agents which provide user commands for getting from a reply to
    the replied-to message (or for getting from a replied-to message to
    its replies), MAY provide similar commands for getting from a
    superseding message to the superseded message (or for getting from a
    superseded message to its superseding version).

(c) User agents MAY normally show the recipient both the previous and
    the superseding message. If, however, both the previous and the
    superseding message have arrived, both having the same author, but
    the user has not yet seen either of them, a user agent MAY show only
    the superseding message, but also show the supersedes-field to
    inform the recipient that this message supersedes a previous
    message.

(d) User agents might issue a warning if a superseding message arrives
    with a different author than the author of the superseded message.
    This can be done by checking the "From:" header, or, if PEM [9], PGP
    [10] or MOSS [11] signatures are available, by checking the digital
    signature.

The above procedure is called a "soft supersedes".

Some user agents or servers may delete the old version of a message when
a new version arrives, which is called a "hard supersedes". Hard
supersedes is NOT RECOMMENDED practice, but common, especially in
netnews where servers want to save disk space.

When this is written (1998) some netnews softwares (servers and clients)
cannot handle Supersedes with more than one previous articles listed as
parameters. They usually ignore the Supersedes header in this case, and
treats the new article as a separate article, not related to the
superseded article. Implementors of netnews softwares SHOULD modify
their software to be able to handle Supersedes with more than one
previous article as parameter, but for some time, many softwares may not
be able to handle Supersedes with more than one parameter. A gateway
from e-mail to news MAY because of this delete all but the first
parameter of this attribute when conveying messages from e-mail to news,
BUT such a practice should be temporary only for one or two years until
news softwares have been modified.

Warning: This header MUST be spelled "Supersedes" and not "Supercedes".
Mailers MUST never generate "Supercedes" but MAY accept "Supercedes" in
input.

Note: The Message-ID of a superseding message MUST be different from the
Message-ID of the superseded message. The Message-ID of the superseded
message is used as value in the "Supersedes:" header, not in the
Message-ID of the superseding message.


5.    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 meaning, in netnews [8]
and in X.420 [4].


6.    Relation to X.400 gateways versus Netnews

Similar headers to Supersedes and Expires are also defined in
recommendations for gatewaying [2] between X.400 [4] and Internet mail.
However, those recommendations are only valid for gateways. By defining
the fields here, the fields are made available for general Internet
e-mail usage. This document also gives fuller descriptions of the fields
than is given by the X.400 gatewaying recommendations [2]. Also an
Auto-Submitted feature has recently been added to X.400, with similar
definition as in this document.

Unfortunately, the two new headers Supersedes and Expires have different
names in  Internet-X.400 gatewaying standards [2] and in netnews.

RFC 1327 [2] gives the name "Obsoletes:" for what in netnews is usually
called "Supersedes:" (not specified in RFC 1036 [8] but in common
usage).

RFC 1327 gives the name "Expiry-Date:" for what in netnews is called
"Expires:" (as specified in RFC 1036).

Because compatibility with netnews is more important than with X.400,
the netnews names of these two fields are proposed here.

Future versions of RFC 1327 (the MIXER document) may choose to specify
the use of "Supersedes" and "Expires" also in gatewayed messages from
X.400.


7.    Security considerations

7.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.


7.2   "Supersedes" security considerations

If a mail or news server or receiving user agent suppresses showing of
superseded messages, the "Supersedes:" feature might be used maliciously
to suppress messages written by other people. To reduce the risk for
this, it is RECOMMENDED that user agents give a warning to the recipient
when a superseding message has a different "From:" name than the
superseded message.

A moderately clever forger can of course circumvent this by sending
messages with falsified "From:" field and even falsified SMTP senders.
User agents supporting PEM [9] or PGP [10] can require and check digital
signatures to reduce also this risk.

Another possible risk with "Supersedes:" is that it allows people to
"change their minds", possibly changing the meaning of replies to them.
Example: A message with the text "Do you like your mother" gets the
reply "Yes, very much", and then the original message might be changed
to "Do you like Hitler", changing the meaning of the reply. Note,
however, that the "In-Reply-To" or "References" headers in the reply
refers to the Message-ID of the original message, not of the superseding
message. Thus, a user agent can avoid this problem by designing the user
interface so that replies are not shown as referring to the superseding
message, when they use the Message-ID of the superseded message.

Also, since "Supersedes:" in e-mail does not actually cause deletion of
the superseded message, recipients can look up the superseded message to
see if the author has changed his mind. In general, it is not illegal or
unethical to change your mind, rather, it shows your openness to new
ideas and willingness to listen to the arguments of other people.

The fact that Supersedes in e-mail does not enforce deletion of the
supersedes message, but that Supersedes in many existing netnews
implementations does enforce such deletion, may in some circumstances
cause security problems.


7.3   "Expires" security considerations

One intention of "Expires" is to help recipients avoid seeing messages
with information which is not any longer valid. There may of course be
cases where a user might want to see an expired message (e.g. a user
might sometimes want to be informed of a meeting, even after the time of
the meeting). This could possibly be solved by having different kinds of
"Expires" for different expiration causes, however, this complexity is
not felt needed at present. A user agent can of course be designed to
inform the recipient also of expired messages, and allow the recipient
the choice of reading them or not. This standard does, therefore, not
require user agents to make expired messages inaccessible.


8.    Copyright

"Copyright (C) The Internet Society (date). All Rights
Reserved.

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.

This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE
USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."


9.    Acknowledgments

Many people have helped with the production of this document. Of special
value have been H. T. Alvestrand, S. Kille, S. Lyall, K. Moore, P.
Overell, Uzi Paz and K. Weide.


10.   References

[1]  D. Crocker: "Standard for the format of ARPA Internet text
     messages." STD 11, RFC 822, August 1982.

[2]  S. Hardcastle-Kille: "Mapping between X.400(1988) / ISO 10021
     and RFC 822",  RFC 1327 May 1992.

[3]  ISO/ITU: "Message Handling Systems", ISO international standard
     10021, ITU  recommendation X.400.

[4]  ISO/ITU: "Message Handling Systems, Part 7: Interpersonal
     Messaging System, ISO international standard 10021-7, ITU
     recommendation X.420.

[5]  N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions
     (MIME) Part One: Format of Internet Message Bodies", RFC 2045,
     December 1996

[6]  K. Moore, G. Vaudreuil, "An Extensible Message Format for
     Delivery Status Notifications", RFC 1894, January 1996.

[7]  K. Moore, "SMTP Service Extension for Delivery Status
     Notifications", RFC 1891, January 1996.

[8]  M.R. Horton, R. Adams: "Standard for interchange of USENET
     messages", RFC 1036, December 1987.

[9]  S. Kent, J. Linn, D. Balenson, B. Kaliski: 1421 Privacy
     Enhancement for Internet Electronic Mail: Part I-IV,
     RFC 1421-1424, February 1993.

[10] Gary B. Edstrom: Frequently Asked Questions; alt.security.pgp.
     Available from faq servers, such as URL: gopher:
     //nutmeg.ukc.ac.uk.:70/11/.archive/uunet/usenet/news.answers/
     pgp-faq.

[11] S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object Security
     Services", RFC 1848, March 1995.

[12] J. Palme: "Loop control for the Auto-Submitted e-mail header",
     draft-palme-autosub-03.txt, July 1997.

[13] J. Palme: "Advise on the implementation of In-Reply-To,
     References and Supersedes e-mail and netnews headers",
     draft-palme-newfields-info-00.doc, July 1997.

[14] D. Crocker: Augmented BNF for Syntax Specifications: ABNF,
     RFC 2234, November 1997.


11.   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