Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_ietf_j_p/draft-ietf-mailext-new-fields-10.txt

Text File | 1997-09-10 | 19KB | 524 lines

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


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


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.


Abstract

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


Differences from previous version

A number of changes suggested by Keith Moore have been made. They are
mainly corrections and language improvements and clarifications and do
not change the intended protocol.


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

2.1 Syntax:

     auto-submitted-field     = "Auto-Submitted ":"
                                auto-submitted

     auto-submitted           = ( "no" / "auto-generated" /
                                "auto-replied" /
                                private-extension /
                                future-extension )
                                optional-parameter-list

    optional-parameter-list   = *( ";" 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.


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


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


2.4 Fuller semantics with examples

2.4.1 Syntax examples without private extensions:

Example 1:
Auto-Submitted: auto-generated


Example 2:
Auto-Submitted: auto-replied


Example 3:
Auto-Submitted: no



2.4.2 Possible syntax examples with private or future extensions:

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


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



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


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


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


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


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


3. Supersedes

Syntax: supersedes-field = "Supersedes" ":" 1*msg-id

The message identifiers (msg-id) use the msg-id format, as defined in
RFC 822 [1].

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

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


4. Expires:

Syntax: Expires-field = "Expires" ":" date-time

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


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


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.


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


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


7. Acknowledgments

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


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


9. Author's address

Jacob Palme                          Phone: [phone]
Stockholm University/KTH             Fax: [phone]
Skeppargatan 73                      E-mail: [e-mail]
S-115 30 Stockholm, Sweden

1
0



9