RFC 5064

The Archived-At Message Header Field

📅 published December 2007, from ietf

The Archived-At Message Header Field 💌

Part 1 of 2 🎀

  • Network Working Group, RFC 5064 📜
  • Author: M. Duerst, Aoyama Gakuin University ✨
  • Category: Standards Track 🔥
  • Date: December 2007 🌸
  • Obsoletes / Updates: nothing listed in this header 🙈

Status of This Memo 🦋

okay so this document is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 💬 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 💖

Abstract ✨

This memo introduces a brand new email header field, Archived-At:, that gives you a direct link to the archived version of one 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

1. Introduction 🌈

okay so [RFC2369] defines a bunch of header fields that can be added to Internet messages, like the ones sent by email distribution lists or in netnews [RFC1036] 📬 One of them is the List-Archive header field, which describes how to get into the archives for a list. That's great for the archives as a whole, but it doesn't get you to one specific message 😭

Honestly there's often a need (or a want) to point at the archived form of a single message. For more detailed usage scenarios, see Section 3.3 🧚 This memo defines a new header, Archived-At, that refers to a single message at an archived location. It gives you quick access to where a mailing list message lives in the list archive. It can also be used without mailing lists at all, like when there are 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 💖

The field name for this header is "Archived-At". The field body is a URI [STD66] wrapped in angle brackets ('<', '>'). The URI MAY contain folding whitespace (FWS, [RFC2822]), and that whitespace gets ignored 🫶 Mail Transfer Agents (MTAs) MUST NOT insert whitespace within the angle brackets. Client applications SHOULD ignore any whitespace that might have been inserted by poorly behaved MTAs, so they can still read it all 🙄 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] 📝

Here's the formal version, written in Augmented BNF (ABNF) according to [RFC4234]:

      archived-at = "Archived-At:" [FWS] "<" folded-URI ">" CRLF
      folded-URI  = <URI, but free insertion of FWS permitted>

where URI is defined in [STD66], and CRLF and FWS are defined in [RFC2822] 🧩

To turn a folded-URI back into a URI, first apply the standard [RFC2822] unfolding rules (replacing FWS with a single SP). Then delete any remaining un-encoded SP characters ✂️

This syntax is kept simple on purpose: only one URI per header field is allowed. That's a big difference 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 you want to list several URIs where an archived copy of the message can be found, you need a separate Archived-At field for each URI, and that's 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 that header field. No fake links, bestie 💀

Now for forwarding. If a message gets 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. It should NOT remove the one(s) that are already there 🌸 The exception is when the header field is exactly the same as one that already exists. In that case, the new header field SHOULD NOT be added 🧚

2.3. Interaction with Message Fragmentation and Reassembly 🧵

[RFC2046] allows messages to be fragmented and then reassembled 🧩 Archived-At header fields are treated the same way as Comments header fields. That means they get copied into the first fragment's message header when fragmentation happens, and then copied back from there into the header of the reassembled message 🔁

This treatment was chosen for compatibility with existing infrastructure ✨ It means the Archived-At header fields in the first fragment 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 let non-ASCII text go directly into message header field bodies, and that's so iconic 🌏 In those contexts, the URI non-terminal in the syntax from Section 2.1 gets replaced by an Internationalized Resource Identifier (IRI), as defined in [RFC3987]. The exact octet encoding of the IRI follows the rules for general direct encoding of non-ASCII text. For converting between IRIs and URIs, the procedures in [RFC3987] are to be applied 🔄

2.5. The X-Archived-At Header Field 👑

For backwards compatibility, this document also describes the X-Archived-At header field. It's a precursor to the Archived-At header field, so it's like the OG version 🕰️ The X-Archived-At header field MAY also be parsed, but SHOULD not be generated 🙅‍♀️

Here's the syntax for X-Archived-At 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 the URI 🚫🫧

Heads up: X-Archived-At is only here so older stuff still works. The newer Archived-At field is the one to use going forward ✨

Part 2 is coming up next with Section 3 and all the implementation vibes 👀💜

3.3. Usage Considerations 🦋

okay so it may feel a little weird at first to put a pointer to the archived version of a message inside that same message 🙈 like, if you already HAVE the message, why would you need a link to it?? but trust me bestie, these pointers are actually super useful 💖 here are some of the ways people use them.

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 that case, they can just grab the URI from the Archived-At header field, which means no more digging through the archive to find the right message 😭✨

A user may want to refer to other messages in a message context. 💌 replying to a message is the usual way to point at one specific message, but once you're pointing at MORE than one, giving out links to archived messages is super common. the Archived-At header field makes those links way easier to share 💅

A user may want to find messages related to a message at hand. 🔍 maybe they never got the related messages at all, so they need the archive to find them. they might also just prefer digging through the archive over their MUA, because archives can link messages together in ways the MUA doesn't 🧚 the Archived-At header field gives you a link to the starting point in the archive, so you can go hunting for related stuff from there 💜

Please note that in all of these scenarios, it's mostly the human reader, not the email client software, that uses the URI in the Archived-At header 🙌 BUT that doesn't mean the email client or other software can't use it too, if they find it helpful 🌸

4. Security Considerations 🔐

okay bestie, this part is serious, so let's get into it 💀 there are lots of potential security issues when you activate and dereference a URI. for more details, including some countermeasures, check out [STD66]. for this proposal, these are the big ones: an intruder might get access to the message transmission and be able to insert a URI that points to some malicious content 😱 this can be handled by using a secured way of transmitting messages 🔒 also, somebody might be able to build a message that's totally harmless when you receive it directly, but causes problems when it's accessed through the URI 🙈 one reason this could happen is the format used in the archive, where some content wasn't escaped properly. this can be fixed by using adequate escaping ✨

The Archived-At header field points to an archived form of the message itself 📨 and that archived form can contain the Archived-At field too 🔁 this creates a possible denial-of-service attack on the server that the URI in the Archived-At header field points to 😬 the setup for this is: the archived form of the message gets downloaded automatically, and then any further URIs in that message are followed and downloaded recursively, without checking for resources that were already downloaded. BUT this kind of scenario is super easy to avoid in 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 might break a URI to a message by introducing a new message with the same message identifier 🕵️‍♀️ possible countermeasures are discussed there too, so go check them out 🎀

5. IANA Considerations 📋

5.1. Registration of the Archive-At Header Field

okay so IANA registered the Archived-At header field in the Message Header Fields Registry ([RFC3864]) like this 💖

   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 🧁 (which means an implementation that ignores this section still counts as compliant with this specification ✨)

IANA also registered the X-Archived-At header field in the Message Header Fields Registry ([RFC3864]) like this 🌈

   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

   Related information:
      none

6. Acknowledgments 🫶

huge shoutout to the members of the W3C system team, especially Gerald Oskoboiny, Olivier Thereaux, Jose Kahan, and Eric Prud'hommeaux 👑 they created the mid-based email archive lookup system and the experimental form of the Archived-At header. Pete Resnik gave the motivation for writing this memo 💜 discussion on the ietf-822@imc.org mailing list, especially contributions from Frank Ellermann, Arnt Gulbrandsen, Graham Klyne, Bruce Lilly, Charles Lindsey, and Keith Moore, led to more improvements to the proposal 🔥 and Chris Newman, Chris Lonvick, Stephane Borzmeyer, Vijay K. Gurbani, and S. Moonesamy gave extra 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.
  • [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&#252;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/

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.

📦 where this page comes from