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

Text File | 1997-07-07 | 17KB | 457 lines

Network Working Group                                     Jacob Palme
Internet Draft                               Stockholm University/KTH
<draft-ietf-mailext-new-fields-08.txt>                         Sweden
Category-to-be: Proposed standard                           July 1997
Expires January 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 (RFC 822) headers, Auto-Submitted,
Supersedes, and Expires.


Differences from previous version

The specification of Supersedes and Expires are unchanged.
Auto-Submitted has been split into two specifications, one with the
simpler case (without loop control) specified here and intended to
become a proposed standard, and one with the controversial issue of loop
control intended to become an experimental standard, which is submitted
at the same time as draft-palme-autosub-03.txt.

The value Auto-Submitted: no, which was removed in an earlier revision
of this draft, has been added again, since it is known to exist in
implementations on the net.

It is now explicitly specified that Auto-Submitted and its parameters
are case-insensitive.

Some other minor wording changes have been made. See
ftp://ftp.dsv.su.se/users/jpalme/draft-ietf-mailext-new-fields-08-dif.doc


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 field in forwarde 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.


2.    Auto-Submitted

2.1   Syntax:

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

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

    <optional-parameter-list> = *( ";" <optional-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: <private extension>, <future extension> and <optional-parameter>
are not defined in this standard, but their syntax is specified as
placeholders for future extensions. An implementation of this standard
which encounters such extensions, but which does not support them, can
simply ignore them.


2.2   Semantics

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

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 defined in the DSN standards
[6].


2.4   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 field in forwarde message

In the following cases, an existing Auto-Submitted header on a
forwarded message SHOU■É 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 automatic weather-station sends automatic 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 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. If the
   subscription server wants notifications when the subscriber address
   is faulty, it can use the NOTIFY ESMTP command.


2.4.6 Auto-Submitted: auto-replied

>  A mail server responds to an incoming request message.

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

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

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