Internet Message Format
obsoletes
- rfc-2822 — Internet Message Format
updated by
- rfc-6854 — Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields
updates
- rfc-4021 — Registration of Mail and MIME Header Fields
Extracted elements (32)
Implementations SHOULD use the full name-addr form (display name in the phrase before angle-bracket addr-spec) rather than the legacy form where the name appeared as a comment after the bare addr-spec. Comments in address fields generally SHOULD NOT be used as some legacy implementations interpret them in conflicting ways.
The separation of 'generation' grammar (section 3) from 'interpretation' grammar (sections 3+4) reflects a deliberate design: obsolete syntax forms are non-interoperable or cause significant problems for recipients, so implementations must be able to read them for backward compatibility but must not produce them in new messages.
The zone '+0000' SHOULD be used to indicate UTC, while '-0000' also indicates UTC but specifically signals that the generating system may be in an unknown local time zone — i.e., that the date-time contains no information about the actual local time. This distinction allows receivers to distinguish known-UTC from unknown-offset messages.
Folding white space (FWS) in the obsolete syntax (obs-FWS) allows any amount of folding white space including entirely-whitespace lines, which differs from current syntax. Implementations parsing older messages must handle this more liberal form without treating it as a header section terminator.
Two-digit years in obsolete date syntax are interpreted as: 00–49 maps to 2000–2049; 50–99 maps to 1950–1999. Three-digit years also add 1900. Military single-letter time zones defined in RFC 822 were non-standard and SHOULD all be treated as equivalent to '-0000' unless out-of-band information confirms their meaning.
When interpreting obsolete addresses, the route portion (a comma-separated '@'-prefixed domain list before the addr-spec inside angle brackets) SHOULD be ignored. This route syntax was used in earlier specifications but is no longer relevant to mail delivery.
A date-time specification MUST be semantically valid: the day-of-week (if present) MUST match the date, the numeric day MUST be within the allowed range for the month and year, the time-of-day MUST be 00:00:00 through 23:59:60 (allowing for leap seconds), and the zone minutes MUST be 00–59.
A field name MUST be composed of printable US-ASCII characters (values 33–126 inclusive) except colon. A field body MUST NOT include CR and LF except when used in folding and unfolding.
CFWS (comments/folding white space) 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.
Comments and folding white space SHOULD NOT be used around the '@' in the addr-spec. If the local-part can be represented as a dot-atom, the dot-atom form SHOULD be used and the quoted-string form SHOULD NOT be used.
Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF. The 998-character limit reflects transport system limitations; the 78-character recommendation accommodates user interfaces that may truncate or wrap longer lines.
Every message SHOULD have a 'Message-ID:' field. Reply messages SHOULD have 'In-Reply-To:' and 'References:' fields as appropriate.
Header fields SHOULD NOT be reordered when a message is transported or transformed. More importantly, the trace header fields and resent header fields MUST NOT be reordered, and SHOULD be kept in blocks prepended to the message.
If the 'From:' field contains more than one mailbox specification, then the 'Sender:' field MUST appear in the message, containing a single mailbox. The 'Sender:' field SHOULD NOT be used when the author and transmitter are identical.
In the message body, CR and LF MUST only occur together as CRLF; they MUST NOT appear independently. Lines of the body MUST be limited to 998 characters and SHOULD be limited to 78 characters, excluding the CRLF.
Obsolete syntax elements defined in section 4 MUST be accepted and parsed by a conformant receiver, but MUST NOT be generated by creators of conformant messages. This dual grammar separates generation rules (section 3) from interpretation rules (sections 3+4).
The field names of any optional field MUST NOT be identical to any field name specified elsewhere in this document. Optional fields MUST conform to the optional-field syntax: a field name of printable US-ASCII excluding SP and colon, followed by a colon and unstructured content.
The 'From:' field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message.
The message identifier (msg-id) MUST be a globally unique identifier for a message, and the generator MUST guarantee its uniqueness. The recommended approach is to include a domain identifier on the right-hand side of the '@' and combine the current date/time with a system-unique value on the left.
When resent fields are used, the 'Resent-From:' and 'Resent-Date:' fields MUST be sent. 'Resent-Message-ID:' SHOULD be sent. Resent fields MUST NOT be used in the normal processing of replies or other automatic actions on messages.
A message consists of a header section (sequence of header fields) followed optionally by a body separated from the header by an empty line (a lone CRLF). Header fields are composed of a field name, a colon, a field body, and a terminating CRLF.
Folding allows a header field body to be split across multiple lines by inserting CRLF before any whitespace (WSP). Unfolding is performed by removing any CRLF immediately followed by WSP before semantic analysis; the unfolded form has no length restriction.
Resent fields (Resent-Date:, Resent-From:, Resent-Sender:, Resent-To:, Resent-Cc:, Resent-Bcc:, Resent-Message-ID:) are prepended as a block each time a message is reintroduced into the transport system by a user. They are strictly informational and must not alter normal reply processing.
The 'Bcc:' (Blind Carbon Copy) field contains recipient addresses not to be revealed to other recipients. Three implementation strategies are defined: strip the Bcc: line entirely; send each visible-copy recipient a message without Bcc: while sending Bcc: recipients a separate copy; or send each Bcc: recipient an individual copy.
The group address construct allows a named group of zero or more mailboxes: a display-name, followed by a colon, a comma-separated mailbox-list (possibly empty), and a semicolon. This can also be used to indicate a named recipient set without revealing individual mailbox addresses.
The only required header fields are the origination date field ('Date:') and the originator address field(s) ('From:'). All other header fields, including 'To:', 'Cc:', 'Bcc:', 'Subject:', and 'Message-ID:', are syntactically optional though 'Message-ID:' SHOULD be present.
Displaying messages on terminals or terminal emulators is dangerous because escape sequences and US-ASCII control characters may remap keyboards, trigger answerback messages causing commands to be issued on the recipient's behalf, or affect attached devices like printers. Implementations should strip potentially dangerous escape sequences before display but must not do so indiscriminately.
Mishandling of the 'Bcc:' field can disclose confidential recipient addresses. Under the first Bcc method (stripping the Bcc: line), a blind recipient may accidentally reveal their receipt by replying-all; under the second method (individual copies), if a single Bcc: copy lists all blind recipients, all of them become visible to each other.
The addr-spec format is 'local-part "@" domain', where local-part is a dot-atom or quoted-string, and domain is a dot-atom or domain-literal (IP address enclosed in brackets). The msg-id is a restricted form: '<' dot-atom-text '@' (dot-atom-text / no-fold-literal) '>' with no internal CFWS.
The date-time format is: optional day-of-week followed by comma, then 1–2 digit day, 3-letter month name, 4-digit year, 2-digit hour, colon, 2-digit minute, optional colon and 2-digit second, and a numeric zone offset of the form (+/-)hhmm.
The overall message ABNF is: message = (fields / obs-fields) [CRLF body], where body = (*(*998text CRLF) *998text). Text characters exclude CR and LF (values %d1-9, %d11, %d12, %d14-127). Use of US-ASCII control characters (1–8, 11, 12, 14–31) in the body is discouraged.
The 'References:' field construction algorithm for replies: take parent's 'References:' field (if any), append parent's 'Message-ID:' (if any); if no 'References:' but parent has single-id 'In-Reply-To:', use that plus 'Message-ID:'. This builds a traceable conversation thread.