STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES
obsoleted by
- rfc-2822 — Internet Message Format
obsoletes
- rfc-733 — Standard for the format of ARPA network text messages
updated by
- rfc-1123 — Requirements for Internet Hosts - Application and Support
- rfc-1138 — Mapping between X.400(1988) / ISO 10021 and RFC 822
- rfc-1148 — Mapping between X.400(1988) / ISO 10021 and RFC 822
- rfc-1327 — Mapping between X.400(1988) / ISO 10021 and RFC 822
- rfc-2156 — MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME
also
- std-11
Extracted elements (40)
Extension-fields are explicitly prohibited from using names beginning with 'X-', reserving that prefix exclusively for user-defined fields. This ensures users have a protected namespace that will never be preempted by formally published extensions.
Source routing via the route component of route-addr is discouraged because the choice of transmission route should normally be left to the mail transport service. Source routing is provided only for cases where the sender has special need of path restriction.
The standard separates envelope information (handled by the transport service) from message contents (governed by this spec), and deliberately contains no specification of envelope format. This separation allows the standard to be applied across different mail transport environments.
The use of ASCII HT (horizontal tab) characters in message headers, though permitted, is discouraged because there is no network-wide definition of the visual effect of tabs at remote hosts, leading to unpredictable rendering.
The use of domain-literals (e.g., [10.0.3.19]) is strongly discouraged. They are permitted only as a temporary means of bypassing system limitations such as incomplete name tables, not as a routine addressing mechanism.
Abbreviated domain specifications are permitted only within a sub-domain when sender and recipient share common right-hand sub-domain components. When messages cross domain boundaries, all addresses must be fully qualified. Mail relays are responsible for expansion but may not find abbreviations in message bodies.
Field-names and most structured-field syntactic units are case-insensitive. The only units requiring case preservation are: text, qtext, dtext, ctext, quoted-pair, and local-part (except that 'Postmaster' must be accepted in any case).
When messages cross heterogeneous network boundaries, the sending gateway must reverse the current network's idiosyncratic transformations (restoring canonical form) and then impose the next network's requirements. This two-step process prevents format corruption across network boundaries.
Comments must NOT be included during protocol exchanges with mail servers. Comments are retained while the message is subject to interpretation according to this standard, but stripped before passing to mail transport services.
Extension-fields will never have names beginning with the string 'X-', reserving that prefix as a protected namespace for user-defined fields.
If the 'From' field is not defaulted to a single authenticated machine address of the actual sender, the 'Sender' field MUST be present. The 'Sender' field MUST be present if it is NOT the same as the 'From' field.
Recursive specification of groups within groups is not permitted. The group construct allows listing individual mailboxes within the colon-semicolon bracket pair, but nesting groups inside groups is disallowed.
The message body MUST occur AFTER the headers. The body is separated from the headers by a null line (a line with nothing preceding the CRLF).
The 'Postmaster' reserved address MUST be matched without sensitivity to alphabetic case, so that 'POSTMASTER', 'postmaster', and any mixture must be accepted.
The reserved local-part address 'Postmaster' MUST be valid at each site, so that 'Postmaster@domain' is a required valid address routed to the responsible mail administrator.
The 'Sender' field mailbox should NEVER be used automatically in a recipient's reply message. Replies should go to 'Reply-To' if present, otherwise to 'From'.
When a message crosses a domain boundary, all addresses must be specified in full format ending with the top-level name-domain in the right-most field. Mail forwarding services are responsible for expanding abbreviated addresses to full form.
When passing text to processes that do not interpret data according to this standard (e.g., mail protocol servers), NO linear-white-space characters should occur between a period or at-sign and a word; exactly ONE SPACE should replace arbitrary whitespace and comment sequences.
Within quoted-strings, domain-literals, and comments, quoting (backslash preceding the character) is REQUIRED for CR and backslash, and for the characters that delimit the token (e.g., parentheses in comments). Quoting is permitted for any character.
The BCC mechanism provides a limited form of recipient privacy by omitting BCC addresses from message copies sent to To and CC recipients. However, the headers (including From, Subject) remain in cleartext and visible to all recipients and intermediate relays.
A group address has the form 'phrase : [#mailbox] ;', allowing a named distribution list. Groups may not be nested within groups. An empty group (name:;) serves as a group-distribution indicator without listing members.
A header field consists of a field-name (printable ASCII, excluding colon and CTLs), followed by a colon, an optional field-body, and a terminating CRLF. Field-names are case-insensitive. The field-body may be folded across multiple lines.
A message consists of structured header fields followed by an optional body. The minimum required fields are: an origination date (Date:), an originator (From:), and at least one destination address. All other fields are optional.
The BCC field contains the identity of additional recipients whose addresses are not disclosed to primary and secondary recipients. Some systems include BCC text only in the author's copy; others include it in copies sent to BCC recipients.
The Encrypted field optionally notes that the message body has been encrypted. The first word parameter identifies the encryption software; the optional second word is a key index hint for the recipient.
The From field contains the identity of the person(s) who wished the message to be sent. The Sender field contains the authenticated identity of the agent that actually submits the message. Reply-To directs replies to specified mailboxes.
The Message-ID field contains a unique identifier in the form '<addr-spec>' that refers to exactly one instantiation of a particular message. Uniqueness is guaranteed by the generating host. Subsequent revisions receive new message identifiers.
The Received field is added by each transport service that relays the message, recording the sending host, receiving host, time-of-receipt, physical mechanism (via), mail protocol (with), internal message ID (id), and original destination address (for).
The Resent- prefix on field names (e.g., Resent-From, Resent-To, Resent-Date) indicates forwarded mail. Resent- fields carry the same semantics as their un-prefixed equivalents but represent the forwarder's information and take precedence over the original fields.
The Return-Path field is added by the final transport system delivering the message, and is intended to contain definitive information about the address and route back to the message originator.
Names of encryption software referenced in the Encrypted field are registered with the Network Information Center, SRI International. Names of extension-fields are similarly registered with NIC.
The names of top-level domains and domains under the ARPA Internet are registered with the Network Information Center, SRI International, Menlo Park, California.
The values for 'via' and 'with' parameters in Received fields (indicating physical mechanisms and mail/connection-level protocols) are registered with the Network Information Center, SRI International.
Headers must remain unencrypted so that mail transport services may access them. Because names, addresses, and Subject field contents may contain sensitive information, this requirement limits total message privacy.
When a computer program generates a message, it is strongly recommended that the human responsible for that program be referenced as part of the Sender field mailbox specification, since programs cannot be held accountable for their behavior.
A domain-literal is encoded as '[' followed by dtext or quoted-pair characters and terminated by ']'. In the ARPA Internet, domain-literals encode 32-bit IPv4 addresses as four decimal octets, e.g., [10.0.3.19].
A route-addr is encoded as '<' followed by an optional route ('1#("@" domain) ":"') and an addr-spec, terminated by '>'. Source routing via the route component is discouraged in favor of leaving routing to the mail transport service.
An addr-spec is encoded as 'local-part "@" domain', where local-part is one or more dot-separated words and domain is a sequence of dot-separated sub-domains. The local-part is case-preserved and treated as uninterpreted by intermediate mail systems.
Date-time is encoded as '[ day "," ] date time', where date is '1*2DIGIT month 2DIGIT' (e.g., '20 Jun 82'), time is 'HH:MM[:SS]', and zone is a named zone (UT, GMT, EST/EDT, etc.), a single military letter, or a signed 4-digit offset (e.g., +0530).
Long header field-bodies may be folded across multiple lines by inserting a CRLF immediately followed by at least one LWSP-char (SPACE or HTAB) wherever linear-white-space is permitted. Unfolding reverses this by treating CRLF+LWSP-char as equivalent to the LWSP-char alone.