INTERNET-DRAFT                                      Jacob Palme
Network Working Group                  Stockholm University/KTH
draft-ietf-mailext-new-fields-15.txt                     Sweden
Expires August 1999                               February 1999

The Auto-Submitted and Expires Headers in E-mail

Status of this Memo

This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.

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

The list of current Internet-Drafts can be accessed at

The list of Internet-Draft Shadow Directories can be accessed at

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


This memo introduces two new e-mail headers, Auto-Submitted
and Expires. This document may, if accepted by the IESG,
become a proposed standard, at some time in the future.

Differences from version 14

The "Supersedes" header has been removed. The reason for this
is that this header is currently being discussed a lot in the
IETF usefor group, and it should not be specified for e-mail
before we know how usefor specifies it for Usenet News.

The places where white space may include a comment has been
slightly reduced.

Added the following text:

   The word "client" may in this text designate functionality,
   which some implementations actually implement wholly or
   partly in a server. For example, in the case of IMAP and
   NNTP, it is very common to implement functionality, which
   logically may be regarded as belonging to a client, in the

The syntax of date-time has been changed to agree with draft-

A mandatory space has been added after the header name and
":", to agree with usenet news practice.

Differences from version 13

Minor clarifications that the choice of soft or hard
supersedes is not indicated by any header information, the
choice is done by the recipient or recipient software. This
clarifications was suggested by Paul Hoffman at the Chicago
1998 IETF meeting.

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

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
   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.   Expires:
5.   Relation to X.400 gateways versus Netnews
6.   Security considerations
 6.1   "Auto-Submitted" security considerations
 6.2   "Expires" security considerations
7.   Copyright
8.   Acknowledgments
9.   References
10.  Author's address

1.    Introduction

This memo introduces two new header fields for Internet e-mail
[1] headers, which will enhance the e-mail service in various
ways. These headers may occur in Usenet News [8], too, but
this document will only be a standard for Usenet News, if the
Usenet News standards documents in the future say so.

The names of the new headers are: Auto-Submitted and Expires.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119.

The word "client" may in this text designate functionality,
which some implementations actually implement wholly or partly
in a server. For example, in the case of IMAP and NNTP, it is
very common to implement functionality, which logically may be
regarded as belonging to a client, in the server.

An informational RFC [11] with advice on the implementation of
the features specified in this specification will
simultaneously be published. For more info see URL

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 /         ; Chars excl. CR and LF
                   %d11-12 /

WSP             =  SP / HTAB               ; Whitespace

FWS             =  ([*WSP CRLF] 1*WSP)     ; Folding

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

day-of-week     =  ([FWS] day-name [FWS]) / obs-day-of-week

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

date            =  day month year

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

month           =  (FWS month-name FWS) / obs-month

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

day             =  ([FWS] 1*2DIGIT [FWS]) / obs-day

time            =  time-of-day FWS zone

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

hour            =  2DIGIT / obs-hour

minute          =  2DIGIT / obs-minute

second          =  2DIGIT / obs-second

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 )

    private-extension         = x-token

    Future-extension          = token

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

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

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

    parameter-name            = "increment" /
                                private-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:

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

-  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

-  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-serverevery 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 non-
   standard 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
   other than "no".

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

5.    Relation to X.400 gateways versus Netnews

A similar headers to Expires is 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 header  Expires has a different name in
Internet-X.400 gatewaying standards [2] and in netnews.

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

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

6.    Security considerations

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

6.2   "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 specification does, therefore, not require user
agents to make expired messages inaccessible.

7.    Copyright and disclaimer

The IETF takes no position regarding the validity or scope of
any intellectual property or other rights that might be
claimed to pertain to the implementation or use of the
technology described in this document or the extent to which
any license under such rights might or might not be available;
neither does it represent that it has made any effort to
identify any such rights. Information on the IETF's procedures
with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims
of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of
such proprietary rights by implementors or users of this
specification can be obtained from the IETF Secretariat."

The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or
other proprietary rights which may cover technology that may
be required to practice this standard. Please address the
information to the IETF Executive Director.

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

8.    Acknowledgments

Many people have helped with the production of this document.
Of special value have been R. Allbery, H. T. Alvestrand, A.
Bowesman, B. Franz, P. Hoffman, S. Kille, S. Lyall, K. Moore,
P. Overell, U. Paz, E. Sommarskog, H. Spencer, J. Stanley, B.
Templeton, K. Weide and R. Zellich

9.    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-02.doc, March 1998.

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

10.   Author's address

Jacob Palme                          Phone: +46-8-16 16 67
Stockholm University/KTH             Fax: +46-8-783 08 29
Skeppargatan 73                      E-mail:
S-115 30 Stockholm, Sweden