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 1. Introduction 2. The "Message-ID" Header 2.1 Relation of changes "Message-ID" and other headers and body 2.2 Security Considerations 3. Copyright 4. Acknowledgments 5. References 6. 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: 1. 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. 2. 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. 3. 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. 4. 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. 5. References Not ready 6. 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 6.3 Applications Area Director(s): Keith Moore Harald Alvestrand 6.4 Area Advisor Harald Alvestrand 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/