From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5064.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc5064.txt (limited to 'doc/rfc/rfc5064.txt') diff --git a/doc/rfc/rfc5064.txt b/doc/rfc/rfc5064.txt new file mode 100644 index 0000000..0921e9e --- /dev/null +++ b/doc/rfc/rfc5064.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group M. Duerst +Request for Comments: 5064 Aoyama Gakuin University +Category: Standards Track December 2007 + + + The Archived-At Message Header Field + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This memo defines a new email header field, Archived-At:, to provide + a direct link to the archived form of an individual email message. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Header Field Definition .........................................2 + 2.1. Syntax .....................................................2 + 2.2. Multiple Archived-At Header Fields .........................3 + 2.3. Interaction with Message Fragmentation and Reassembly ......3 + 2.4. Syntax Extension for Internationalized Message Headers .....3 + 2.5. The X-Archived-At Header Field .............................4 + 3. Implementation and Usage Considerations .........................4 + 3.1. Formats of Archived Message ................................4 + 3.2. Implementation Considerations ..............................4 + 3.3. Usage Considerations .......................................5 + 4. Security Considerations .........................................6 + 5. IANA Considerations .............................................7 + 5.1. Registration of the Archive-At Header Field ................7 + 5.2. Registration of the X-Archived-At Header Field .............7 + 6. Acknowledgments .................................................8 + 7. References ......................................................8 + 7.1. Normative References .......................................8 + 7.2. Informative References .....................................8 + + + + + + + + + + +Duerst Standards Track [Page 1] + +RFC 5064 The Archived-At Message Header Field December 2007 + + +1. Introduction + + [RFC2369] defines a number of header fields that can be added to + Internet messages such as those sent by email distribution lists or + in netnews [RFC1036]. One of them is the List-Archive header field + that describes how to access archives for the list. This allows + access to the archives as a whole, but not an individual message. + + There is often a need or desire to refer to the archived form of a + single message. For more detailed usage scenarios, please see + Section 3.3. This memo defines a new header, Archived-At, to refer + to a single message at an archived location. This provides quick + access to the location of a mailing list message in the list archive. + It can also be used independently of mailing lists, for example in + connection with legal requirements to archive certain messages. + + In this document, the key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" are to be interpreted as described in [RFC2119]. + +2. Header Field Definition + +2.1. Syntax + + For the Archived-At header field, the field name is "Archived-At". + The field body consist of a URI [STD66] enclosed in angle brackets + ('<', '>'). The URI MAY contain folding whitespace (FWS, [RFC2822]), + which is ignored. Mail Transfer Agents (MTAs) MUST NOT insert + whitespace within the angle brackets, but client applications SHOULD + ignore any whitespace, which might have been inserted by poorly + behaved MTAs. The URI points to an archived version of the message. + See Section 3.1 for more details. + + This header field is subject to the encoding and character + restrictions for mail headers as described in [RFC2822]. + + More formally, the header field is defined as follows in Augmented + BNF (ABNF) according to [RFC4234]: + + archived-at = "Archived-At:" [FWS] "<" folded-URI ">" CRLF + folded-URI = + + where URI is defined in [STD66], and CRLF and FWS are defined in + [RFC2822]. + + To convert a folded-URI to a URI, first apply standard [RFC2822] + unfolding rules (replacing FWS with a single SP), and then delete any + remaining un-encoded SP characters. + + + +Duerst Standards Track [Page 2] + +RFC 5064 The Archived-At Message Header Field December 2007 + + + This syntax is kept simple in that only one URI per header field is + allowed. In this respect, the syntax is different from [RFC2369]. + Also, comments are not allowed. + +2.2. Multiple Archived-At Header Fields + + Each Archived-At header field only contains a single URI. If it is + desired to list multiple URIs where an archived copy of the message + can be found, a separate Archived-At field per URI is required. + Multiple Archived-At header fields with the same URI SHOULD be + avoided. An Archived-At header field SHOULD only be created if the + message is actually being made available at the URI given in the + header field. + + If a message is forwarded from a list to a sublist and both lists + support adding the Archived-At header field, then the sublist SHOULD + add a new Archived-At header field without removing the already + existing one(s), unless the header field is exactly the same as an + already existing one, in which case the new header field SHOULD NOT + be added. + +2.3. Interaction with Message Fragmentation and Reassembly + + [RFC2046] allows for the fragmentation and reassembly of messages. + Archived-At header fields are to be treated in the same way as + Comments header fields, i.e., copied to the first fragment message + header on fragmentation and back from there to the header of the + reassembled message. + + This treatment has been chosen for compatibility with existing + infrastructure. It means that Archived-At header fields in the first + fragment message MAY refer to an archived version of the whole, + unfragmented message. To avoid confusion, Archived-At headers SHOULD + NOT be added to fragment messages. + +2.4. Syntax Extension for Internationalized Message Headers + + There are some efforts to allow non-ASCII text directly in message + header field bodies. In such contexts, the URI non-terminal in the + syntax defined in Section 2.1 is to be replaced by an + Internationalized Resource Identifier (IRI) as defined in [RFC3987]. + The specifics of the actual octet encoding of the IRI will follow the + rules for general direct encoding of non-ASCII text. For conversion + between IRIs and URIs, the procedures defined in [RFC3987] are to be + applied. + + + + + + +Duerst Standards Track [Page 3] + +RFC 5064 The Archived-At Message Header Field December 2007 + + +2.5. The X-Archived-At Header Field + + For backwards compatibility, this document also describes the + X-Archived-At header field, a precursor of the Archived-At header + field. The X-Archived-At header field MAY also be parsed, but SHOULD + not be generated. + + The following is the syntax of the X-Archived-At header field in ABNF + according to [RFC4234] (which also defines SP): + + obs-archived-at = "X-Archived-At:" SP URI CRLF + + The X-Archived-At header field does not allow whitespace inside URI. + +3. Implementation and Usage Considerations + +3.1. Formats of Archived Message + + There is no restriction on the format used to serve the archived + message from the URI in an Archived-At header field. It is expected + that in many cases, the archived message will be served as (X)HTML, + as plain text, or in its original form as message/rfc822 [RFC2046]. + Some forms of URIs may imply the format in which the archived message + is served, although this should not be relied upon. + + If the protocol used to retrieve the message allows for content + negotiation, then it is also possible to serve the archived message + in several different formats. As an example, an HTTP URI in an + Archived-At header may make it possible to serve the archived message + both as text/html for human consumption in a browser and as + message/rfc822 for use by a mail user agent (MUA) without loss of + information. + +3.2. Implementation Considerations + + Mailing list expanders and email archives are often separate pieces + of software. It may therefore be difficult to create an Archived-At + header field in the mailing list expander software. + + One way to address this difficulty is to have the mailing list + expander software generate an unambiguous URI, e.g., a URI based on + the message identifier of the incoming email, and to set up the + archiving system so that it redirects requests for such URIs to the + actual messages. If the email does not contain a message identifier, + a unique identifier can be generated. + + + + + + +Duerst Standards Track [Page 4] + +RFC 5064 The Archived-At Message Header Field December 2007 + + + Such a system has been implemented and is in productive use at W3C. + As an example, the URI + "http://www.w3.org/mid/0I5U00G08DFGCR@mailsj-v1.corp.adobe.com", + containing the significant part of the message identifier + "<0I5U00G08DFGCR@mailsj-v1.corp.adobe.com>", is redirected to the URI + of this message in the W3C mailing-list archive at + http://lists.w3.org/Archives/Public/uri/2004Oct/0017.html. + + Source code for this implementation is available at + http://dev.w3.org/cvsweb/search/, in particular + http://dev.w3.org/cvsweb/search/cgi/mid.pl and + http://dev.w3.org/cvsweb/search/bin/msgid-db.pl. These locations may + be subject to change. + + When using the message identifier to create an address for the + archived mail, care has to be taken to escape characters in the + message identifier that are not allowed in the URI, or to remove + them, as done above for the "<" and ">" delimiters. + + Implementations such as that described above can introduce a security + issue. Somebody might deliberately reuse a message identifier to + break the link to a message. This can be addressed by checking + incoming message identifiers against those of the messages already in + the archive and discarding incoming duplicates, by checking the + content of incoming duplicates and discarding them if they are + significantly different from the first message, by offering multiple + choices in the response to the URI, or by using some authentication + mechanism on incoming messages. + +3.3. Usage Considerations + + It may at first seem strange to have a pointer to an archived form of + a message in a header field of that same message. After all, if one + has the message, why would one need a pointer to it? It turns out + that such pointers can be extremely useful. This section describes + some of the scenarios for their use. + + A user may want to refer to messages in a non-message context, such + as on a Web page, in an instant message, or in a phone conversation. + In such a case, the user can extract the URI from the Archived-At + header field, avoiding the search for the correct message in the + archive. + + A user may want to refer to other messages in a message context. + Referring to a single message is often done by replying to that + message. However, when referring to more than one message, providing + pointers to archived messages is a widespread practice. The + Archived-At header field makes it easier to provide these pointers. + + + +Duerst Standards Track [Page 5] + +RFC 5064 The Archived-At Message Header Field December 2007 + + + A user may want to find messages related to a message at hand. The + user may not have received the related messages, and therefore needs + to use an archive. The user may also prefer finding related messages + in the archive rather than in her MUA, because messages in archives + may be linked in ways not provided by the MUA. The Archived-At + header field provides a link to the starting point in the archive + from which to find related messages. + + Please note that in the above usage scenarios, it is mostly the human + reader, rather than the email client software, that makes use of the + URI in the Archived-At header. However, this does not rule out the + use of the URI in the Archived-At header by the email client or other + software if such use is found helpful. + +4. Security Considerations + + There are many potential security issues when activating and + dereferencing a URI. For more details, including some + countermeasures, please see [STD66]. In the context of this + proposal, the following are particularly relevant: An intruder may + get access to the message transmission and be able to insert a URI + pointing to some malicious content. This can be addressed by using a + secured way of message transmission. Also, somebody may be able to + construct a message that is harmless when received directly, but that + produces problems when accessed via the URI. One reason for this may + be the format used in the archive, where some content was not + adequately escaped. This can be addressed by using adequate + escaping. + + The Archived-At header field points to some archived form of the + message itself. This in turn may contain the Archived-At field. + This creates a potential for a denial-of-service attack on the server + pointed to by the URI in the Archived-At header field. The + conditions are that the archived form of the message is downloaded + automatically, and that further URIs in that message are followed and + downloaded recursively without checking for already downloaded + resources. However, this kind of scenario can easily be avoided by + implementations. First, the URI in the Archived-At header field + should not be dereferenced automatically. Second, appropriate + measures for loop detection should be used. + + In Section 3.2, an attack is described that may break a URI to a + message by introducing a new message with the same message + identifier. Possible countermeasures are also discussed. + + + + + + + +Duerst Standards Track [Page 6] + +RFC 5064 The Archived-At Message Header Field December 2007 + + +5. IANA Considerations + +5.1. Registration of the Archive-At Header Field + + IANA has registered the Archived-At header field in the Message + Header Fields Registry ([RFC3864]) as follows: + + Header field name: + Archived-At + + Applicable protocol: + mail (RFC 2822) and netnews (RFC 1036) + + Status: + standard + + Author/Change controller: + IETF + + Specification document(s): + RFC 5064 + + Related information: + none + +5.2. Registration of the X-Archived-At Header Field + + This section is non-normative (specifically, an implementation that + ignores this section remains compliant with this specification). + + IANA has registered the X-Archived-At header field in the Message + Header Fields Registry ([RFC3864]) as follows: + + Header field name: + X-Archived-At + + Applicable protocol: + mail (RFC 2822) and netnews (RFC 1036) + + Status: + deprecated + + Author/Change controller: + IETF + + Specification document(s): + RFC 5064 + + + + +Duerst Standards Track [Page 7] + +RFC 5064 The Archived-At Message Header Field December 2007 + + + Related information: + none + +6. Acknowledgments + + The members of the W3C system team, in particular Gerald Oskoboiny, + Olivier Thereaux, Jose Kahan, and Eric Prud'hommeaux, created the + mid-based email archive lookup system and the experimental form of + the Archived-At header. Pete Resnik provided the motivation for + writing this memo. Discussion on the ietf-822@imc.org mailing list, + in particular contributions by Frank Ellermann, Arnt Gulbrandsen, + Graham Klyne, Bruce Lilly, Charles Lindsey, and Keith Moore, led to + further improvements of the proposal. Chris Newman, Chris Lonvick, + Stephane Borzmeyer, Vijay K. Gurbani, and S. Moonesamy provided + additional valuable comments. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, + April 2001. + + [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, RFC 3864, + September 2004. + + [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource + Identifiers (IRIs)", RFC 3987, January 2005. + + [RFC4234] Crocker, D., Ed., and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", RFC 4234, October 2005. + + [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, RFC + 3986, January 2005. + +7.2. Informative References + + [RFC1036] Horton, M. and R. Adams, "Standard for interchange of + USENET messages", RFC 1036, December 1987. + + [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + November 1996. + + + +Duerst Standards Track [Page 8] + +RFC 5064 The Archived-At Message Header Field December 2007 + + + [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax + for Core Mail List Commands and their Transport through + Message Header Fields", RFC 2369, July 1998. + +Author's Address + + Martin Duerst (Note: Please write "Duerst" with u-umlaut wherever + possible, for example as "Dürst" in XML and HTML.) + Aoyama Gakuin University + 5-10-1 Fuchinobe + Sagamihara, Kanagawa 229-8558 + Japan + + Phone: +81 42 759 6329 + Fax: +81 42 759 6495 + EMail: duerst@it.aoyama.ac.jp + URI: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Duerst Standards Track [Page 9] + +RFC 5064 The Archived-At Message Header Field December 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights 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; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Duerst Standards Track [Page 10] + -- cgit v1.2.3