Email records include fields of information such as the sender, recipient, date, and subject that may be considered to be a form of metadata. However, since these fields can be populated in multiple ways, they may not provide sufficient information to make email records retrievable and useable for as long as they are needed. Agencies should refer to NARA Bulletin 2015-04: Metadata Guidance for the Transfer of Permanent Electronic Records for the minimum required metadata for all permanent Federal electronic records. The required metadata must be provided as an external index in a pipe-delimited CSV file.
NARA’s regulations in 36 CFR 1236.22 require agencies preserve core components of email messages including the addresses of the sender and all recipients, the date the message was sent, and any attachments so that the content, context and structure of the records are maintained. Although these elements are included as a part of message content, email systems may be configured in a manner that substitutes a proper name or a nickname from an address book in place of the qualified email address used to send or receive the message. It is also possible for an email to be sent from an address associated with several people, such as a group or a team, or sent by one person on behalf of another.
To ensure sufficient information is captured and included in transfers of email to NARA, agencies should consider the following:
- Email messages should comply with the specifications outlined in Request for Comments (RFC) 5322, Internet Message Format. This is the successor to RFC 2822, which is currently referenced in NARA’s transfer guidance.
- The email must include–at a minimum–subject, message body, address of sender and all addressees (including blind copy recipients), and the time and date the message was sent or received.
- When exporting email messages from their native system, messages must include labels to identify each part of the message (Date, To [all recipients, including cc: and bc: copies], From, Subject, Body, and Attachment) including transmission and receipt information (Time Sent, Time Opened, Message Size, File Name, and similar information, if available).
- If the email message does not contain the proper name of the sender or recipient of an email message in the header, the agency must maintain records that allow for the association of nicknames or email addresses with the agency employee or official responsible for the account.
- The preferred formats for aggregations of permanent email records transferred to NARA are PST and MBOX (see NARA 2014-04, Appendix A).
Updated to clarify RFC 5322 on July 26, 2017.
Please explain the utility and timing of asking agencies to adhere to the following:
“1) Email messages should comply with the specifications outlined in Request for Comments (RFC) 5322, Internet Message Format.”
“RFC 5322, Internet Message Format” appears to be a draft protocol from 2008 and NARAs only other mention of this document appears in a proposed rule change in the Federal Register from 7/13/2016 that did not result in the promulgation of CFR changes.
It seems that referencing RFC 5322 is premature and possibly unnecessary in this otherwise informative blog post. At a minimum, please provide contextual information about the draft protocol and summarize the 57 page document to highlight how it can be used.
I am concerned about the utility and timing of including the following reference: “1. Email messages should comply with the specifications outlined in Request for Comments (RFC) 5322, Internet Message Format.”
“Request for Comments (RFC) 5322, Internet Message Format.” is a draft protocol from 2008 that was mentioned in a proposed NARA rule change in the Federal Register from 7/13/2016. To date, the proposed CFR changes have not been promulgated and RFC 5322 remains a draft.
At a minimum, I recommend that NARA provide context for including the draft protocol in this blog post and include a summary of the 57 page document to the federal records management community to help us utilize it.
Apologies for any confusion!
In our blog post describing metadata requirements for email we referenced RFC 5322. We included it because it is the definitive authority when it comes to the construction of email messages and the terminology associated with them. RFC 5322 is referenced in NARA’s Criteria for Managing Email Records in Compliance with the Managing Government Records Directive (M-12-18). Its predecessor, RFC 2822, is referenced in NARA’s transfer guidance. We have updated the post to clarify that 5322 is the successor and not currently referenced in the transfer guidance and we recommend that agencies consider referring to that version of the standard.
Email is made possible through a complex set of protocols (there are approximately 12 core standards) that govern different aspects including networking, addressing, internationalization, and attachments. For the most part this complexity is hidden from end users by the maturity of the standards that govern how each piece works and the applications that implement them.
If email messages are migrated out of the original system into a record keeping or archiving system prior to execution of the disposition, it is important for agencies to insure that they retain their significant characteristics as defined in RFC 5322. For example, the field labels To, From, Subject, and Date are located in all message’s header fields and are important for e-discovery but are not always retained when messages are moved between systems.
RFC 5322, is the de facto standard that defines the Internet Message Format (IMF) which describes how messages must be constructed in order for them to be successfully transmitted between systems. While labeled as a Request For Comments (RFC) document, this title does not adequately reflect the authority of the document. As explained on the Internet Engineering Task Force (IETC) site (https://tools.ietf.org/html/rfc1796): “The “Request for Comments” (RFC) document series is the official publication channel for Internet standards documents and other publications of the IESG, IAB, and Internet community.”
RFCs can be published in different categories, Informational, Experimental, or Standards Track (Proposed Standard, Draft Standard, Internet Standard), or Historic. RFC 5322 is published in the standards track.