[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 02 03 04 05 06 07 08 09 10 11 12 13                        
          14 15                                                         
Network Working Group                                     Jacob Palme
Internet Draft                               Stockholm University/KTH
draft-ietf-mailext-new-fields-13.txt                           Sweden
                                                            July 1998
Expires January 1999



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),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

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 12

The syntax for parameters to the Auto-Submitted header is better
specified.

The list of examples in section 3.5.1 have been extended with more
examples.

The text about the Supersedes header (4.2.2 to 4.2.3) has been modified
to more clearly indicate when soft and hard supersedes are to be
implemented and to reflect current usage.

The text about the Supersedes header (4.2.1) has been modified to more
clearly show who are allowed to issue superseding messages.

Table of contents

1.   Introduction
2.   Syntax elements
 2.1   Identifier
 2.2   date-time
3.   Auto-Submitted
 3.1   Syntax:
 3.2   Semantics
 3.3   Relation to NOTIFY ESMTP command
 3.4   Parameters
 3.5   Fuller semantics with examples
   3.5.1  Syntax examples without private extensions:
   3.5.2  Possible syntax examples with private or future
   extensions:
   3.5.3  Auto-Submitted: no or no Auto-Submitted header
   3.5.4  Keep the field in forwarded message
   3.5.5  Auto-Submitted: auto-generated
   3.5.6  Auto-Submitted: auto-replied
   3.5.7  Recipient use of Auto-Submitted fields
4.   Supersedes
 4.1   Syntax
 4.2   Semantics
5.   Expires:
6.   Relation to X.400 gateways versus Netnews
7.   Security considerations
 7.1   "Auto-Submitted" security considerations
 7.2   "Supersedes" security considerations
 7.3   "Expires" security considerations
8.   Copyright
9.   Acknowledgments
10.  References
11.  Author's address


1.    Introduction

This memo introduces three new header fields for Internet e-mail [1] and
Usenet News [8] 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.

An informational RFC [11] with advice on the implementation of the
features specified in this standard will simultaneously be published.


2.    Syntax elements

This section defines some syntax elements needed for the
syntax specifications of the new fields. The syntax is defined
using the ABNF rules from [12].


2.1   Identifier

identifier      =       "<" id-left-side "@" id-right-side ">"

id-left-side    =       dot-atom-text / no-fold-quote

id-right-side   =       dot-atom-text / no-fold-literal

no-fold-quote   =       DQUOTE *(qtext / quoted-pair) DQUOTE

dot-atom-text   =       1*atext *("." 1*atext)

atext           =       ALPHA / DIGIT / ; Any character except controls,
                        "!" / "#" /     ;  SP, and specials.
                        "$" / "%" /     ;  Used for atoms
                        "&" / "'" /
                        "*" / "+" /
                        "-" / "/" /
                        "=" / "?" /
                        "^" / "_" /
                        "`" / "{" /
                        "|" / "}" /
                        "~"

qtext           =       NO-WS-CTL /     ; Non-white-space controls
                        %d33 /          ; The rest of the US-ASCII
                        %d35-91 /       ;  characters not including "\"
                        %d93-127        ;  or the quote character

quoted-pair     =       ("\" text)

text            =       %d1-9 /         ; 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

    private-extension         = x-token

    Future-extension          = token

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

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

    parameter                 = parameter-name [ "="
                                parameter-value ]

    parameter-name            = "increment" /
                                private-parameter /
                                future-parameter

Note 1: All the syntax specified above is case-insensitive. Thus
"Auto-Submitted: Auto-Replied" is identical to "auto-submitted:
auto-replied" or "aUTO-sUBMITTED: aUTO-rEPLIED".

Note 2: The syntax for private-extension and future-extension is
specified as a placeholder for future extensions. private-extension
keywords must begin with "x-", future extension keywords may be defined
only by standards-track RFCs, or by Informational or Experimental RFCs
with approval of the IESG. Implementations which examine the value of
the Auto-Submitted field should handle an Auto-Submitted field which
contains an unrecognized private-extension or future-extension keyword
as if the message had been automatically submitted, but without
information about the type of auto-submission.

3.2   Semantics

This field indicates whether the message was sent with or without
explicit human control.

The auto-generated keyword:

SHOULD be used on messages generated by automatic (often periodic)
processes,
MUST NOT be used on manually generated messages,
MUST NOT be used on a message issued in direct response to another
message.

The auto-replied keyword:

SHOULD be used on messages sent in direct response to another message,
MUST NOT be used on manually-generated messages,
MUST NOT be used on messages generated by automatic or periodic
processes.

Note 1: A similar header field is defined in X.420 [4].

Note 2: If a message does not have any Auto-Submitted header, no
assumption should be made of whether this message was automatically
generated or not.

The "comment" syntactical construct can be used to indicate a reason why
this message was auto-submitted.

3.3   Relation to NOTIFY ESMTP command

This 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

Example 4:   Auto-Submitted: auto-generated; increment=21600

Example 5:   Auto-Submitted: (weather-report) auto-generated;
                (issued every 6 hours) increment=21600

3.5.2 Possible syntax examples with private or future extensions:

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

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

Example 8:   Auto-Submitted: auto-replied ; x-count=8


3.5.3 Auto-Submitted: no or no Auto-Submitted header

In the following cases the "Auto-Submitted: no" header, or no
Auto-Submitted header shall be generated.

-  Ordinary e-mail messages written by a person.

-  A person interacts with a mail-generating client, e.g. instructs
   it to join a mailing list, and the client generates a message to a
   listserver with commands for subscribing to the list.

-  A person interacts with a World Wide Web form, such that the
   filled-in form is automatically sent to an e-mail address
   specified in the WWW form document.

3.5.4 Keep the field in forwarded message

In the following cases, an existing Auto-Submitted header on a
forwarded message SHOULD be kept as it is.

-  A moderator accepts messages to a moderated group, and forwards
   the accepted messages to the group members, possibly merged into
   a digest by software for producing digests.

-  Automatic forwarding by mailing list expanders or to a new
   e-mail address for the recipient.

3.5.5 Auto-Submitted: auto-generated

An Auto-Submitted field with the auto-generated keyword SHOULD be
supplied with a message that is automatically generated, but not one
which is an automatic response to an emailed request. Examples of
automatically generated messages include:

-  An automatic weather station sends periodic messages with
   temperature, wind velocity, etc. to a weather database server.

-  An automatically generated weather-report is sent once every
   three hours to subscribing customers.

-  An automatic computer process (for example, a "cron job") sends
   failure reports.

-  An automatic vote counter counts incoming votes and reports on
   the outcome of the vote.

-  A subscription service sends copies of a file every time the file
   is updated to people subscribing to such updates.

   Note: This is a borderline case. If the sent files has as SMTP-sender
   the person who modified this file, it should not be regarded as
   auto-submitted.

-  A notification asking you to confirm your subscription to a mailing
   list, which is sent to you automatically by the mailing-list-server
   every six months.

3.5.6 Auto-Submitted: auto-replied

An Auto-Submitted field with the auto-replied keyword SHOULD be included
in any message issued as an automatic response to another message.
Example:

-  A mail server responds to an incoming request message.

Many uses of this header field is for special kinds of notifications,
such as:

-  A vacation server sends a vacation notification in response to an
   incoming message for the person who is on vacation.

-  A notification that a message, after receipt, has been purged,
   forwarded or handled in some other special 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: There is no comma between multiple values, and that each
Message-ID value is to be surrounded by angle brackets.

Warning: Usenet News software may not work correctly with comments in
header fields, especially comments in other places than at the beginning
and end of the field value.

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

4.2   Semantics

The Supersedes header identifies previous correspondence, which this
message supersedes. Different messaging agents such as user agents,
mailing list expanders, mailing list archives and Usenet News servers
may handle the Supersedes header. A user agent is expected to handle
this field in much the same way as the In-Reply-To and References
header.

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.

4.2.1 Who may supersede a message/article?

Agents receiving superseding messages may ignore, or issue a warning, if
the Supersedes header, if the author of the message is not approved.
Approved authors of superseding messages are:

(1) The author of the message being superseded.

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

(3) Other users given the authority to supersede messages. Such
    authority is often local to one particular server only.

An agent may ignore or issue a warning for Supersedes headers if the
Superseding message does not have a digital signature of its author.
Digital signatures are separately standardized (like SMIME [9] and PGP
[10] or other standards for digital signatures) and their format and
semantics are not specified in this standard.

4.2.2 Semantic variant 1: Soft supersedes

(a) With soft supersedes this header does not imply any mandatory
    deletion of the previous correspondence in mailboxes and user
    agent databases.

(b) 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) 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.

4.2.3 Semantic variant 2: Hard supersedes

With hard supersedes, the arrival of a superseding message or article
will cause the deletion of the superseded message. The new message will
however still have a new Message-ID and will not take over the Message-
ID of the superseded message/article.

4.2.4 When to use soft and hard supersedes

Personal mailboxes and personal message stores SHOULD implement soft
supersedes. Usenet News servers and multi-user message archives MAY
implement HARD supersedes.

If the handler of a message/article storage has a mechanism for
automatic purging of old messages, the fact that there is a superseding
message may be a component in the decision of when to purge the previous
version.

4.2.5 Multiple field values

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.


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 been added to X.420, 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 S/MIME [9] or PGP [10] or other standards for
digital signature can require and check digital signatures to reduce
also this risk (see section 4.2.1 above).

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 some implementations of Supersedes cause deletion of the
Superseded message (hard supersedes, section 4.2.3 above), but others do
not (soft supersedes, section 4.2.2 above), may cause security problems.
To reduce this problem, a server should clarify its policy on this to
its users and follow the recommendations in section 4.2.4 above).

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 implementation 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 R. Allbery, H. T. Alvestrand, B. Franz, S. Kille, S.
Lyall, K. Moore, P. Overell, U. Paz, H. Spencer, J. Stanley, K. Weide
and R. Zellich


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]  B. Ramsdell: S/MIME Version 3 Message Specification. Work in
     progress.

[10] J. Callas, L. Donnerhacke, H. Finney, R. Thayer: OpenPGP Message
     Format. Work in progress.

[11] J. Palme: "Advise on the implementation of In-Reply-To,
     References and Supersedes e-mail and netnews headers",
     draft-palme-newfields-info-01.doc, March 1998.

[12] 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