Internet Message Format
This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK]
Replaces RFC 724: Proposed official standard for the format of ARPA Network messages, RFC 733: Standard for the format of ARPA network text messages, RFC 822: STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES, RFC 2822: Internet Message Format.
This document is current and has been amended. 1 later RFC has changed part of it. Nothing on the RFC itself tells you this.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 29 must, 28 should, 7 may.
1.2.3 Structure of This Document
- MUST NOTAny examples in this section MUST NOT be taken as specification of the formal syntax of any part of a message.
- MUSTThe syntax included in section 3 represents messages as they MUST be created.
- SHOULDThere are also notes in section 3 to indicate if any of the options specified in the syntax SHOULD be used over any of the others.
- MUSTAs such, these elements MUST be interpreted by parsers of messages in order to be conformant to this specification.
- MUST NOTHowever, since items in this syntax have been determined to be non-interoperable or to cause significant problems for recipients of messages, they MUST NOT be generated by creators of conformant messages.
2.1.1 Line Length Limits
- MUSTEach line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.
2.2 Header Fields
- MUSTA field name MUST be composed of printable US-ASCII characters (i.e., characters that have values between 33 and 126, inclusive), except colon.
- MUST NOTA field body MUST NOT include CR and LF except when used in "folding" and "unfolding", as described in section 2.2.3.
- MUSTAll field bodies MUST conform to the syntax described in sections 3 and 4 of this specification.
2.2.3 Long Header Fields
- SHOULDNote: Though structured field bodies are defined in such a way that folding can take place between many of the lexical tokens (and even within some of the lexical tokens), folding SHOULD be limited to placing the CRLF at higher-level syntactic breaks.
2.3 Body
- MUSTo CR and LF MUST only occur together as CRLF; they MUST NOT appear independently in the body.
- MUSTo Lines of characters in the body MUST be limited to 998 characters, and SHOULD be limited to 78 characters, excluding the CRLF.
3.1 Introduction
- MUSTMessages that are conformant to this specification MUST conform to the syntax in this section.
- SHOULDIf there are options in this section where one option SHOULD be generated, that is indicated either in the prose or in a comment next to the syntax.
- MUST NOTIn all cases, these productions are to be ignored for the purposes of generating legal Internet messages and MUST NOT be used as part of such a message.
- MUSTHowever, when interpreting messages, these tokens MUST be honored as part of the legal syntax.
3.2.2 Folding White Space and Comments
- MUST NOTHowever, where CFWS occurs in this specification, it MUST NOT be inserted in such a way that any line of a folded header field is made up entirely of WSP characters and nothing else.
3.3 Date and Time Specification
- RECOMMENDEDThough folding white space is permitted throughout the date-time specification, it is RECOMMENDED that a single space be used in each place that FWS appears (whether it is required or optional); some older implementations will not interpret longer sequences of folding white space correctly.
- SHOULDThe date and time-of-day SHOULD express local time.
- SHOULDThe form "+0000" SHOULD be used to indicate a time zone at Universal Time.
- MUSTA date-time specification MUST be semantically valid.
- MUSTThat is, the day-of-week (if included) MUST be the day implied by the date, the numeric day-of-month MUST be between 1 and the number of days allowed for the specified month (in the specified year), the time-of-day MUST be in the range 00:00:00 through 23:59:60 (the number of seconds allowing for a leap second; see [RFC1305]), and the last two digits of the zone MUST be within the range 00 through 59.
3.4 Address Specification
- SHOULDSince the meaning of the information in a comment is unspecified, implementations SHOULD use the full name-addr form of the mailbox, instead of the legacy form, to specify the display name associated with a mailbox.
- SHOULD NOTAlso, because some legacy implementations interpret the comment, comments generally SHOULD NOT be used in address fields to avoid confusing such implementations.
3.4.1 Addr-Spec Specification
- SHOULDIf the string can be represented as a dot-atom (that is, it contains no characters other than atext characters or "." surrounded by atext characters), then the dot-atom form SHOULD be used and the quoted- string form SHOULD NOT be used.
- SHOULD NOTComments and folding white space SHOULD NOT be used around the "@" in the addr-spec.
3.5 Overall Message Syntax
- MUSTLines in a message MUST be a maximum of 998 characters excluding the CRLF, but it is RECOMMENDED that lines be limited to 78 characters excluding the CRLF.
- MAY(See section 2.1.1 for explanation.) In a message body, though all of the characters listed in the text rule MAY be used, the use of US-ASCII control characters (values 1 through 8, 11, 12, and 14 through 31) is discouraged since their interpretation by receivers for display is not guaranteed.
3.6 Field Definitions
- SHOULD NOTHowever, for the purposes of this specification, header fields SHOULD NOT be reordered when a message is transported or transformed.
- MUST NOTMore importantly, the trace header fields and resent header fields MUST NOT be reordered, and SHOULD be kept in blocks prepended to the message.
3.6.2 Originator Fields
- MUSTIf the from field contains more than one mailbox specification in the mailbox- list, then the sender field, containing the field name "Sender" and a single mailbox specification, MUST appear in the message.
- MAYIn either case, an optional reply-to field MAY also be included, which contains the field name "Reply-To" and a comma-separated list of one or more addresses.
- SHOULD NOTby a single mailbox and the author and transmitter are identical, the "Sender:" field SHOULD NOT be used.
- SHOULDOtherwise, both fields SHOULD appear.
- SHOULDIn the absence of the "Reply-To:" field, replies SHOULD by default be sent to the mailbox(es) specified in the "From:" field unless otherwise specified by the person composing the reply.
- SHOULD NOTIn all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message.
3.6.3 Destination Address Fields
- MAYWhen a message is a reply to another message, the mailboxes of the authors of the original message (the mailboxes in the "From:" field) or mailboxes specified in the "Reply-To:" field (if it exists) MAY appear in the "To:" field of the reply since these would normally be the primary recipients of the reply.
- MAYWhen such a reply is formed, addresses in the "To:" and "Cc:" fields of the original message MAY appear in the "Cc:" field of the reply, since these are normally secondary recipients of the reply.
- MAYIf a "Bcc:" field is present in the original message, addresses in that field MAY appear in the "Bcc:" field of the reply, but they SHOULD NOT appear in the "To:" or "Cc:" fields.
3.6.4 Identification Fields
- SHOULDThough listed as optional in the table in section 3.6, every message SHOULD have a "Message-ID:" field.
- SHOULDFurthermore, reply messages SHOULD have "In-Reply-To:" and "References:" fields as appropriate and as described below.
- RECOMMENDEDHowever, later in this section, the use of a domain for the right-hand side of the "@" is RECOMMENDED.
- MUSTThe message identifier (msg-id) itself MUST be a globally unique identifier for a message.
- MUSTThe generator of the message identifier MUST guarantee that the msg-id is unique.
- RECOMMENDEDThough other algorithms will work, it is RECOMMENDED that the right-hand side contain some domain identifier (either of the host itself or otherwise) such that the generator of the message identifier can guarantee the uniqueness of the left-hand side within the scope of that domain.
3.6.5 Informational Fields
- MAYWhen used in a reply, the field body MAY start with the string "Re: " (an abbreviation of the Latin "in re", meaning "in the matter of") followed by the contents of the "Subject:" field body of the original message.
3.6.6 Resent Fields
- SHOULDResent fields SHOULD be added to any message that is reintroduced by a user into the transport system.
- SHOULDA separate set of resent fields SHOULD be added each time this is done.
- SHOULDAll of the resent fields corresponding to a particular resending of the message SHOULD be grouped together.
- MUSTWhen resent fields are used, the "Resent-From:" and "Resent-Date:" fields MUST be sent.
- SHOULDThe "Resent-Message-ID:" field SHOULD be sent.
- SHOULD NOT"Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be identical to "Resent-From:".
- MUST NOTThey MUST NOT be used in the normal processing of replies or other such automatic actions on messages.
- MUST NOTThe resent fields are only informational and MUST NOT be used in the normal processing of replies.
3.6.8 Optional Fields
- MUSTThey MUST conform to the syntax of an optional-field.
- MUST NOTThe field names of any optional field MUST NOT be identical to any field name specified elsewhere in this document.
4 Obsolete Syntax
- MUST NOTThough these syntactic forms MUST NOT be generated according to the grammar in section 3, they MUST be accepted and parsed by a conformant receiver.
- MUSTNote: This section identifies syntactic forms that any implementation MUST reasonably interpret.
4.2 Obsolete Folding White Space
- MAYIn the obsolete syntax, any amount of folding white space MAY be inserted where the obs-FWS rule is allowed.
4.3 Obsolete Date and Time
- SHOULDHowever, because of the error in [RFC0822], they SHOULD all be considered equivalent to "-0000" unless there is out-of-band information confirming their meaning.
- SHOULDAny such time zone whose meaning is not known SHOULD be considered equivalent to "-0000" unless there is out-of-band information confirming their meaning.
4.4 Obsolete Addressing
- SHOULDWhen interpreting addresses, the route portion SHOULD be ignored.
4.5.3 Obsolete Destination Address Fields
- SHOULDWhen multiple occurrences of destination address fields occur in a message, they SHOULD be treated as if the address list in the first occurrence of the field is combined with the address lists of the subsequent occurrences by adding a comma and concatenating.
6 IANA Considerations
- MUST NOTThe following are examples of obsolete (that is, the "MUST NOT generate") syntactic elements described in section 4 of this document.