Network Working Group                                       Jacob Palme
Internet Draft                                 Stockholm University/KTH
draft-ietf-drums-message-id-00.txt
Expires: May 1998                                         November 1997


The ''Message-ID'' header



Status of this Document


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

NOTE: This document is a proposal for text to be incorporated in the
new message format standard or published as a separate RFC. It is
written as input for discussions in the drums working group and does
not yet reflect any consensus within that group.


Abstract

This is a proposal of a text to include msgfmt in order to clarify the
relation between changes in the ''Message-ID'' header and other parts of
a message. This information is important, because many mailers use the
''Message-ID'' to eliminate duplicates of the same message, and
information may be lost if this is not done the right way.

Temporary note

This document does not at this time (21 November 1997) represent any
consensus opinion in the drums working group.

Table of Contents

. Introduction
. The "Message-ID" Header
   2.1 Relation of changes "Message-ID" and other headers and body
   2.2 Security Considerations
. Copyright
. Acknowledgments
. References
. Contact Information
   6.1 Author's Addresses
   6.2 Working Group Chairman
   6.3 Applications Area Director(s):
   6.4 Area Advisor
   6.5 Mailing lists:




.    Introduction

The "Reply-To" e-mail header is known to be problematic because it is
used for different purposes by different mailers and when the mailer
inserting this header and the mailer using the header interpret it in
different ways, unexpected results can happen. For example, a message
intended for the author of a previous message only may by mistake be
sent to the mailing list, through which it was sent. One way to reduce
this problem is to define a new header "Mail-Followup-To" which
replaces "Reply-To" in recommending recipients for replies destined for
the group of people discussing an issue.


.    The "Message-ID" Header

2.1   Relation of changes "Message-ID" and other headers and body

The following changes in a message SHOULD NOT cause it to get a new
Message-ID:
- Changes in any headers except From, Date and Subject.
- Conversion of the body to a new Content-Transfer-Encoding.

The following changes in a message SHOULD cause it to get a new Message-
ID:
- Changes in the From, Date and Subject header.
- Changes in the text other than different encoding.

Mailers SHOULD, however, not assume that two messages with the same
Message-ID differ only as specified above. This is of particular
importance for mailers which use the Message-ID to eliminate duplicates
of the same message or for loop control.

If the From, Date or Subject headers have been changed, but not the
body, the message SHOULD get a new Message-ID but the Content-ID should
be the same as before. If the message did not earlier have any Content-
ID, it can be given a Content-ID whose value is the same as the
previous Message-ID in this case.


2.2   Security Considerations

There are no particular security considerations with this clarification
of how the "Message-ID" is to be used, since it only clarifies existing
practice. There is a risk involved with assuming that two messages with
the same "Message-ID" are identicial. This risk is especially common in
Usenet News, since in Usenet News duplicates of messages with the same
"Message-ID" are often automatically eliminated. This may mean that if
a message with the same Message-ID is sent at different times to
different newsgroups, it may never reach some of the newsgroups. The
proposal here does not fully solve this problem, but reduces it a
little by clarifying the relation between changes in "Message-ID" and
body. To fully resolve this problem, Usenet News and other mailers
which use duplicate supression should not stop redistribution of a
message to additional newsgroups. The loop control should only stop
redistribution to the newsgroups which have already got the message.


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


.    Acknowledgments

Chris Newman and several other people have helped us with preparing
this document. I alone take responsibility for any errors which may
still be in the document.


.    References

Not ready

.    Contact Information

6.1   Author's Addresses

Jacob Palme                          Phone: +46-8-16 16 67
Stockholm University and KTH         Fax: +46-8-783 08 29
Electrum 230                         Email: jpalme@dsv.su.se
S-164 40 Kista, Sweden

6.2   Working Group Chairman

Chris Newman <chris.newman@innosoft.com>

6.3    Applications Area Director(s):

Keith Moore  <moore+iesg@cs.utk.edu>
Harald Alvestrand  <Harald.T.Alvestrand@uninett.no>

6.4    Area Advisor

Harald Alvestrand  <Harald.T.Alvestrand@uninett.no>

6.5    Mailing lists:

General Discussion:drums@cs.utk.edu
To Subscribe:      drums-request@cs.utk.edu
Archive:           ftp://cs.utk.edu/pub/drums/mail-archive/