Internet Message Format
obsoleted by
- rfc-5322 — Internet Message Format
obsoletes
- rfc-822 — STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES
updated by
Extracted elements (32)
The '-0000' zone value is semantically distinct from '+0000': '+0000' means explicitly UTC, while '-0000' means the time was generated on a system that may have an unknown local time zone, indicating the datetime carries no local timezone information.
The 998-character hard limit exists because many implementations cannot handle longer lines, and RFC 2821 transport rejects messages with lines exceeding 1000 characters including CRLF. The 78-character recommendation accommodates common user interface displays that truncate or wrap longer lines.
The period character ('.') is allowed in obs-phrase (and thus display names) but not in the normative phrase production, because permitting it creates ambiguity between display names and addr-spec in parsing. It is included in the obsolete syntax because it is already widely used in names (e.g., initials) and must be correctly interpreted.
Obsolete addressing allowed a route portion ('obs-route': comma-separated '@domain' list terminated by ':') before the addr-spec within angle brackets. When interpreting such addresses, the route portion SHOULD be ignored.
Single-character military time zones (A–Z) from RFC 822 were defined incorrectly and are therefore unpredictable. They SHOULD all be treated as equivalent to '-0000' (unknown local time) unless out-of-band information confirms their meaning.
Two-digit years in the obsolete date syntax are interpreted as follows: values 00–49 map to 2000–2049; values 50–99 and all three-digit years map to years 1900–1999 by adding 1900.
When multiple occurrences of destination address fields ('To:', 'Cc:', 'Bcc:') appear in an obsolete message, they SHOULD be treated as if the address-lists are combined by adding a comma and concatenating.
A date-time specification MUST be semantically valid: day-of-week (if present) MUST match the date, numeric day MUST be in range for the month/year, time MUST be 00:00:00–23:59:60 (allowing leap second), and zone MUST be within -9959 through +9959.
Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF. This applies to both header fields and the message body.
If the 'From:' field contains more than one mailbox specification, the 'Sender:' field MUST appear in the message identifying the single agent responsible for transmission.
If the local-part of an addr-spec can be represented as a dot-atom, the dot-atom form SHOULD be used and the quoted-string form SHOULD NOT be used.
In the message body, CR and LF MUST only occur together as CRLF; they MUST NOT appear independently. Body lines MUST be limited to 998 characters (SHOULD be 78) excluding the CRLF.
Obsolete syntactic elements (section 4) MUST be accepted and parsed by conformant receivers for interoperability, but MUST NOT be generated by conformant message creators.
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 use the generating host's domain name on the right of '@' and a timestamp plus unique token on the left.
The only required header fields are the origination date field ('Date:') and the originator address field(s) ('From:'). All other header fields are syntactically optional. Header fields SHOULD NOT be reordered during transport or transformation.
Trace header fields and resent header fields MUST NOT be reordered and SHOULD be kept in blocks prepended to the message.
When resent fields are used, 'Resent-From:' and 'Resent-Date:' MUST be present. 'Resent-Message-ID:' SHOULD be included. 'Resent-Sender:' SHOULD NOT be used if it would be identical to 'Resent-From:'.
Header folding allows a long field body to be split across multiple lines by inserting CRLF before any whitespace (WSP). Unfolding reverses this by removing any CRLF immediately followed by WSP before further parsing.
Optional fields (X-headers and other extension fields) MUST conform to `field-name ":" unstructured CRLF`. The field name is composed of printable US-ASCII characters excluding SP and colon, and MUST NOT duplicate any field name defined in this standard.
Reply messages SHOULD include 'In-Reply-To:' containing the parent message's 'Message-ID:' value(s), and 'References:' containing the thread chain (parent's 'References:' plus parent's 'Message-ID:'). These fields enable mail clients to display conversation threads.
Resent fields ('Resent-Date:', 'Resent-From:', 'Resent-To:', etc.) are prepended as a block when a user reintroduces a message into the transport system. They are strictly informational and MUST NOT be used in normal reply processing.
The 'Bcc:' field specifies recipients whose addresses are not revealed to other recipients. Implementations may handle 'Bcc:' by either removing the field entirely from all copies, or sending a separate copy with the 'Bcc:' field to blind recipients only; which method is implementation-dependent.
The CFWS (comment / folding white space) token allows comments enclosed in parentheses and folding white space to appear between many structured header field tokens. Comments may nest and may contain quoted-pairs. CFWS MUST NOT produce a folded line consisting entirely of WSP.
The 'From:' field contains one or more mailbox specifications. If 'From:' contains more than one mailbox, a 'Sender:' field containing a single mailbox MUST appear. An optional 'Reply-To:' field may indicate preferred reply addresses.
The 'Message-ID:' field contains a single unique message identifier with syntax `"<" id-left "@" id-right ">"`. Every message SHOULD have a 'Message-ID:' field. Subsequent revisions of a message must receive new message identifiers.
Trace fields consist of an optional 'Return-Path:' field (containing angle-bracket-enclosed optional addr-spec) and one or more 'Received:' fields (containing name/value pairs followed by a semicolon and date-time). These are strictly informational per this standard; full semantics are in RFC 2821.
Displaying messages on terminals that interpret escape sequences can enable denial-of-service, keyboard remapping, answerback-triggered command execution, or printer manipulation. Message viewers SHOULD strip potentially dangerous terminal escape sequences before display, but MUST NOT strip indiscriminately as some escape sequences (e.g., ISO 2022 charset switching) are legitimate.
Mishandling 'Bcc:' fields can inadvertently reveal confidential recipient addresses. When the field is removed entirely, blind recipients may accidentally expose their inclusion by replying to all. When a 'Bcc:' copy is sent, if all blind addresses are listed together, each blind recipient sees the others. Implementations must process replies carefully to avoid leaking Bcc recipients.
A header field is composed of a field name (printable US-ASCII, values 33–126, excluding colon), followed by ':', followed by a field body, terminated by CRLF. Field names are case-insensitive by convention.
A message consists of header fields followed optionally by a body. The header and body are separated by an empty line (a bare CRLF). The body is `*(*998text CRLF) *998text` and the header is a sequence of field lines.
An addr-spec is `local-part "@" domain`. The local-part is either a dot-atom or a quoted-string; the domain is either a dot-atom or a domain-literal enclosed in square brackets. Comments and FWS SHOULD NOT appear around the '@'.
The date-time field encodes as `[ day-of-week "," ] day month year FWS time FWS zone`, where zone is `("+" / "-") 4DIGIT` representing UTC offset in hours and minutes (e.g., +0530). The form "+0000" SHOULD indicate UTC.