The Archived-At Message Header Field
Extracted elements (17)
Fragmentation handling (treating Archived-At like Comments headers) was chosen for compatibility with existing infrastructure, even though it means Archived-At headers in the first fragment may refer to an archived version of the whole unfragmented message.
One implementation approach is to have the mailing list expander generate an unambiguous URI based on the message identifier, and configure the archiving system to redirect such URIs to actual messages. This decouples the mailing list expander from the archive system, addressing the difficulty of tight integration.
The Archived-At syntax allows only one URI per header field, unlike RFC 2369 which permits multiple URIs. Comments are also not allowed. Multiple archive locations require multiple separate Archived-At header fields. This keeps the syntax simple.
Archived-At header fields interact with message fragmentation (RFC 2046) by being treated the same as Comments header fields: copied to the first fragment message header on fragmentation and back to the reassembled message header. Archived-At headers SHOULD NOT be added to fragment messages to avoid confusion.
For internationalized message headers, the URI non-terminal in the Archived-At syntax is to be replaced by an Internationalized Resource Identifier (IRI) as defined in RFC 3987, with conversion between IRIs and URIs following RFC 3987 procedures.
Client applications SHOULD ignore any whitespace within angle brackets that might have been inserted by poorly behaved MTAs.
If a message is forwarded from a list to a sublist and both lists support adding Archived-At, the sublist SHOULD add a new Archived-At field without removing existing ones, unless the header field is exactly the same as an existing one, in which case the new header SHOULD NOT be added.
Mail Transfer Agents (MTAs) MUST NOT insert whitespace within the angle brackets of the Archived-At header field.
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.
The Archived-At header field provides a direct link to the archived form of an individual email message. The field body consists of a URI enclosed in angle brackets ('<', '>'), where the URI points to an archived version of the message.
The X-Archived-At header field is a deprecated precursor to Archived-At. Its ABNF syntax is: `obs-archived-at = "X-Archived-At:" SP URI CRLF`. It MAY be parsed but SHOULD NOT be generated; it does not allow whitespace inside the URI.
IANA registered the Archived-At header field in the Message Header Fields Registry (RFC 3864). Applicable protocol: mail (RFC 2822) and netnews (RFC 1036). Status: standard. Author/Change controller: IETF.
IANA registered the X-Archived-At header field in the Message Header Fields Registry (RFC 3864). Applicable protocol: mail (RFC 2822) and netnews (RFC 1036). Status: deprecated. This registration section is non-normative.
An attacker may introduce a new message with the same message identifier to break the URI link to an existing archived message. Countermeasures include checking incoming message identifiers against existing archived ones, discarding duplicates, or using authentication on incoming messages.
An intruder with access to message transmission may insert a URI pointing to malicious content. This can be addressed by using a secured transmission method. Additionally, a message harmless when received directly could produce problems when accessed via the URI due to inadequate escaping in the archive format.
The Archived-At header creates a potential for a denial-of-service attack on the server pointed to by the URI if the archived form is downloaded automatically and further URIs are followed recursively. Mitigations: do not dereference the URI automatically, and implement loop detection.
The Archived-At header field is defined in ABNF as: `archived-at = "Archived-At:" [FWS] "<" folded-URI ">" CRLF` and `folded-URI = <URI, but free insertion of FWS permitted>`. To convert a folded-URI to a URI, apply RFC 2822 unfolding rules then delete remaining un-encoded SP characters.