RFC 822
STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES
📜 RFC 822: STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES 💌
okay bestie, let's get into it ✨ this is the OG spec for what an email message looks like, written way back in 1982 by David H. Crocker 🎀. He revised the older RFC #733 and it obsoletes that one (RFC #733, NIC #41952) 🌸. It's giving classic, it's giving foundational, and honestly it's giving "the whole inbox is built on this" 💅
Here's the tea on the title block: it's dated August 13, 1982, and Crocker was at the Dept. of Electrical Engineering, University of Delaware, Newark, DE 19711 🦋. His network address was DCrocker @ UDel-Relay. Iconic. 🫶
1. INTRODUCTION ✨
1.1. SCOPE 🌈
okay so this standard lays out a syntax for text messages that people send to each other, inside the whole "electronic mail" vibe 💌. It replaces the spec from ARPANET Request for Comments #733, "Standard for the Format of ARPA Network Text Messages" 📮.
So here's the thing about messages: they have an envelope and contents 💖. The envelope is all the stuff needed to get the message sent and delivered 🚚. The contents are the actual object the recipient gets 🎁. This standard only cares about the format and some of the semantics of the contents. It says NOTHING about the envelope info 🙈 (that's a whole different vibe).
Some message systems might pull info out of the contents to build the envelope, and this standard is meant to make that easier for programs 🧚.
Also, some systems store messages in formats that are NOT this one 💅. This spec is strictly about what gets passed BETWEEN hosts.
Note: This standard is NOT intended to dictate the internal formats used by sites, the specific message system features they're expected to support, or any of the characteristics of user interface programs that create or read messages. Not its job, bestie 🙅♀️
Now the big distinction ✨: there's what the spec REQUIRES and what it ALLOWS. Messages can be super rich with structured info, or tiny and simple with barely any of it 🍓. The standard also simplifies how different visual formats get interpreted. Only the visual side of a message changes, not what the information inside means 💜. Implementors can keep those visual distinctions if they want 🌸.
The formal definition has four levels 🦋:
- the bottom level is the meta-notation used in this doc
- the second level is the basic lexical analyzers that feed tokens to higher-level parsers
- next is the overall message spec, which lets you tell individual fields apart
- finally, the contents of several structured fields
1.2. COMMUNICATION FRAMEWORK 🎀
Messages are lines of text, period 📝. No special provisions for drawings, fax, speech, or structured text 🙃. Data compression and transmission/storage efficiency didn't get much thought either, so the standard is pretty relaxed about how many bits it eats 🍩. For example, field names are free text instead of special terse codes. Lowkey wild, but that's the era ✨.
It uses a general "memo" framework 💌. So a message is some info in a rigid format, then the main body, which this doc doesn't define 🧁. The syntax of several fields in that rigid "headers" part IS defined here, and some of those fields MUST be included in all messages 🔥.
Hold up, the rule that separates one header field from another is specified separately from the internal syntax of each particular field 🧠. That's on purpose! It lets simple parsers handle the general structure without caring about the details of each field 💖. Appendix B is there to help build those parsers 🧚.
More fields are expected to become common over time 🌈. As needed, specs for these "extension-fields" will get published through the same mechanism as this doc 📣. Users can also make their own private fields, and those "user-defined fields" are allowed 🎀.
The framework is pretty strict about tone and appearance 💅. It's mostly useful for intra-organization stuff and well-structured inter-organization communication 🏢. It can also do some inter-process stuff, like simple file transfer and remote job entry ⚙️. A more robust framework might allow multi-font, multi-color, multi-dimension encoding 🌈, while a less robust one (like most single-machine message systems) would more strictly limit adding fields and including specific ones 🙅♀️.
Fun fact that's lowkey iconic 👑: unlike paper mail, the RECEIVER of a message can have a LOT of control over how it looks 💅. How much control they actually get depends on the capabilities of their own message system ✨.
2. NOTATIONAL CONVENTIONS 🦋
okay so the spec uses an augmented Backus-Naur Form (BNF) notation 📐. It's BNF with a few tweaks: how rules are named, and how repetition and "local" alternatives are written 💖.
2.1. RULE NAMING 🎀
Angle brackets (< and >) are mostly NOT used 🙈. A rule's name is just the name, not <name> 💜. Quotation marks wrap literal text (which can be upper or lower case) 📝. Some basic rules are in uppercase, like SPACE, TAB, CRLF, DIGIT, ALPHA, and so on 🔤. Angle brackets DO show up in rule definitions, and anywhere else in this doc where they make rule names easier to spot 🌸.
2.2. RULE1 / RULE2: ALTERNATIVES 🌈
Elements separated by a slash (/) are alternatives 🔀. So foo / bar accepts foo OR bar 💅. Simple, bestie ✨.
2.3. (RULE1 RULE2): LOCAL ALTERNATIVES 🦋
Elements in parentheses get treated as one single element 🎀. So (elem (foo / bar) elem) allows the token sequences elem foo elem and elem bar elem 🧚.
2.4. *RULE: REPETITION 💖
The character * in front of an element means repetition 🔁. The full form looks like this:
<l>*<m>elementTo be continued in part 2 🫶 — don't worry, the rest is coming! 💜
indicating at least <l> and at most <m> occurrences of element. So the defaults are 0 and infinity, which means *(element) is totally chill with any number, zero included 🫶. 1*element is the one that needs at least one, no ghosting allowed 💀, and 1*2element lets you have one or two 🎀.
2.5. [RULE]: OPTIONAL
Square brackets are the "you can skip this" vibe 🌸. Anything inside them is optional, so [foo bar] is the same as *1(foo bar) ✨.
2.6. NRULE: SPECIFIC REPETITION
<n>(element) is the same as <n>*<n>(element), which just means exactly <n> occurrences of (element) 🧚. So 2DIGIT is a 2-digit number and 3ALPHA is a string of three alphabetic characters, iconic 💅.
2.7. #RULE: LISTS
There's a construct # that's basically * but make it a list 🍓, and it's written like this:
<l>#<m>elementIt means at least <l> and at most <m> elements, each separated by one or more commas (","). This makes the usual form of lists super easy. A rule like (element *("," element)) can be shown as 1#element 🦋. Wherever this construct is used, null elements are allowed, but they don't count toward the number of elements present. So (element),,(element) is permitted but only counts as two elements. Therefore, where at least one element is required, at least one non-null element must be present. Default values are 0 and infinity, so #(element) allows any number including zero, 1#element requires at least one, and 1#2element allows one or two 🌈.
2.8. ; COMMENTS
A semi-colon, set off some distance to the right of rule text, starts a comment that continues to the end of the line 💜. It's a simple way to drop useful notes right next to the specs 📝.
3. LEXICAL ANALYSIS OF MESSAGES 🔍
3.1. GENERAL DESCRIPTION
A message is made of header fields and, optionally, a body 💌. The body is just a sequence of lines containing ASCII characters. It's separated from the headers by a null line, which is a line with nothing before the CRLF 🫧.
3.1.1. LONG HEADER FIELDS
Each header field can be viewed as one single, logical line of ASCII characters, made up of a field-name and a field-body 🌸. For convenience, the field-body can be split across multiple lines. This is called "folding" 🪄. The general rule is that wherever there may be linear-white-space (NOT simply LWSP-chars), a CRLF immediately followed by AT LEAST one LWSP-char may be inserted instead. So this single line:
To: "Joe & J. Harvey" <ddd @Org>, JJV @ BBNcan be folded like this:
To: "Joe & J. Harvey" <ddd @ Org>,
JJV@BBNand like this:
To: "Joe & J. Harvey"
<ddd@ Org>, JJV
@BBNand like this:
To: "Joe &
J. Harvey" <ddd @ Org>, JJV @ BBNGoing from this folded multi-line version back to the single line is called "unfolding" 🔄. Unfolding happens by treating a CRLF immediately followed by a LWSP-char as equivalent to the LWSP-char 💖.
Note: While the standard permits folding wherever linear-white-space is permitted, it is recommended that structured fields, such as those containing addresses, limit folding to higher-level syntactic breaks. For address fields, it is recommended that such folding occur between addresses, after the separating comma.
3.1.2. STRUCTURE OF HEADER FIELDS
Once a field has been unfolded, you can see it as a field-name, then a colon (":"), then a field-body, and then it ends with a carriage-return/line-feed 💅. The field-name must be made of printable ASCII characters, meaning characters with values between 33 and 126 decimal, except colon. The field-body can be any ASCII characters except CR or LF. (CR and/or LF can still show up in the actual text, but unfolding removes them ✨.)
Some field-bodies can be read according to an internal syntax that some systems want to parse. These are called "structured fields" 🗂️. Dates and addresses are examples. Other fields, like "Subject" and "Comments", are just treated as strings of text 📝.
Note: Any field whose field-body is defined as anything other than simply <text> is to be treated as a structured field. Field-names, unstructured field bodies and structured field bodies each are scanned by their own, independent "lexical" analyzers 🧠.
3.1.3. UNSTRUCTURED FIELD BODIES
For some fields, like "Subject" and "Comments", no structure is assumed. They're treated simply as <text>s, the same as the message body 🫧. The folding rules apply to these fields too, so any field body spanning several lines must have its second and later lines indented by at least one LWSP-char 🌷.
3.1.4. STRUCTURED FIELD BODIES
To make structured fields easier to write and read, free insertion of linear-white-space is allowed between lexical tokens. That's what lets you fold with CRLFs 🎀. Instead of cluttering the syntax specs with explicit linear-white-space everywhere, there's another "lexical" analyzer that's just assumed to exist. This analyzer doesn't apply to unstructured field bodies, which are simply strings of text. Its job is to read the unfolded text of the field body as a sequence of lexical symbols 🔍.
These symbols are:
- individual special characters
- quoted-strings
- domain-literals
- comments
- atoms
The first four are self-delimiting. Atoms aren't, since they're delimited by the self-delimiting symbols and by linear-white-space 🧩. When you're regenerating sequences of atoms and quoted-strings, exactly one SPACE is assumed to exist between them, and that's what should be used. (Also, check the "Clarifications" section on "White Space" below for the rules on multiple contiguous LWSP-chars 👀.)
So, for example, the folded body of an address field:
":sysmail"@ Some-Group. Some-Org,
Muhammed.(I am the greatest) Ali @(the)Vegas.WBAgets analyzed into these lexical symbols and types:
:sysmail quoted string
@ special
Some-Group atom
. special
Some-Org atom
, special
Muhammed atom
. special
(I am the greatest) comment
Ali atom
@ atom
(the) comment
Vegas atom
. special
WBA atomThe canonical representations for the data in these addresses are these strings:
":sysmail"@Some-Group.Some-Organd
Muhammed.Ali@Vegas.WBANote: For display, and when passing this kind of structured info to other systems, like mail protocol services, there must be NO linear-white-space between<word>s separated by period (".") or at-sign ("@"), and exactly one SPACE between all other<word>s. Also, headers should be in a folded form 🍰.
3.2. HEADER FIELD DEFINITIONS
These rules show a field meta-syntax without caring about the particular type or internal syntax 📐. Their purpose is to help detect fields. They also give higher-level parsers a picture of each field as something that fits on one line 🦋.
field = field-name ":" [ field-body ] CRLF
field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
field-body = field-body-contents
[CRLF LWSP-char field-body]
field-body-contents =
<the ASCII characters making up the field-body, as
defined in the following sections, and consisting
of combinations of atom, quoted-string, and
specials tokens, or else consisting of texts>3.3. LEXICAL TOKENS
The following rules define an underlying lexical analyzer that feeds tokens to higher-level parsers 🧃. See the ANSI references in the Bibliography 📚.
; ( Octal, Decimal.)
CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
ALPHA = <any ASCII alphabetic character>
; (101-132, 65.- 90.)
; (141-172, 97.-122.)
DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.)
CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
character and DEL> ; ( 177, 127.)
CR = <ASCII CR, carriage return> ; ( 15, 13.)
LF = <ASCII LF, linefeed> ; ( 12, 10.)
SPACE = <ASCII SP, space> ; ( 40, 32.)
HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)
<"> = <ASCII quote mark> ; ( 42, 34.)
CRLF = CR LF
LWSP-char = SPACE / HTAB ; semantics = SPACE
linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE
; CRLF => folding
specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted-
/ "," / ";" / ":" / "\" / <"> ; string, to use
/ "." / "[" / "]" ; within a word.
delimiters = specials / linear-white-space / comment text = <any CHAR, including bare ; => atoms, specials,
CR & bare LF, but NOT ; comments and
including CRLF> ; quoted-strings are
; NOT recognized.
atom = 1*<any CHAR except specials, SPACE and CTLs>
quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
; quoted chars.
qtext = <any CHAR excepting <">, ; => may be folded
"\" & CR, and including
linear-white-space>
domain-literal = "[" *(dtext / quoted-pair) "]"
August 13, 1982 - 10 - RFC #822
dtext = <any CHAR excluding "[", ; => may be folded
"]", "\" & CR, & including
linear-white-space>
comment = "(" *(ctext / quoted-pair / comment) ")"
ctext = <any CHAR excluding "(", ; => may be folded
")", "\" & CR, & including
linear-white-space>
quoted-pair = "\" CHAR ; may quote any char
phrase = 1*word ; Sequence of words
word = atom / quoted-string3.4. CLARIFICATIONS ✨
3.4.1. QUOTING 🫧
Okay so some characters are reserved for special interpretation, like the ones that mark where a lexical token starts and ends 🧩. If you want to use one of those as plain uninterpreted data, you get a quoting mechanism. Just put a backslash ("\") in front of the character. Easy peasy 💅
Quoting is not fully general though, bestie 🙈 You can only use it inside these three constructs:
- quoted-string
- domain-literal
- comment
Inside those, quoting is REQUIRED for CR and "\", and for the character(s) that delimit the token (like "(" and ")" for a comment). Quoting is also permitted for any character, so you're never wrong to use it there 🌸
Note: quoting is NOT permitted within atoms. So if the local-part of an addr-spec needs a special character, you have to use a quoted string instead. This is NOT legal:Full\ Name@Domainand it has to be written like this:"Full Name"@Domain
August 13, 1982 - 11 - RFC #822
3.4.2. WHITE SPACE 🍓
Note: In structured field bodies, multiple linear space ASCII characters (namely HTABs and SPACEs) are treated as single spaces, and they can freely surround any symbol. In all header fields, the only place where at least one LWSP-char is REQUIRED is at the beginning of continuation lines in a folded field.
When you pass text to processes that don't interpret it according to this standard (think mail protocol servers 🖥️), there should be NO linear-white-space characters between a period (".") or an at-sign ("@") and a <word>. Exactly ONE SPACE should replace any arbitrary linear-white-space and comment sequences. Main character energy, honestly 👑
Note: Within systems that conform to this standard, wherever a member of the list of delimiters is allowed, LWSP-chars may also show up before and/or after it.
Writers of mail-sending (aka header-generating) programs should know that there is no network-wide definition of what an ASCII HT (horizontal-tab) character does to the look of text on another host 🫠. So even though tabs are permitted in message headers, using them is discouraged. Spaces are the way 🦋
3.4.3. COMMENTS 💬
A comment is a set of ASCII characters enclosed in matching parentheses, and it's not inside a quoted-string. The comment construct lets message originators add text that's useful for human readers, but it gets ignored by the formal semantics 🧚 Comments should be kept while the message is being interpreted according to this standard. However, comments must NOT be included in other cases, like when you're doing protocol exchanges with mail servers 🙅♀️
Comments nest, so if an unquoted left parenthesis shows up in a comment string, there must also be a matching right parenthesis. When a comment is the delimiter between two lexical symbols, like two atoms, it's lexically equivalent to a single SPACE, for the purposes of regenerating the sequence (for example, when you pass it along to a mail protocol server). Comments are only detected as comments inside field-bodies of structured fields 🔍
If a comment is going to be "folded" onto multiple lines, the syntax for folding must be followed. (See the "Lexical Analysis of Messages" section on "Folding Long Header Fields" above, and the section on "Case Independence" below.) Note that the official semantics therefore do not "see" any unquoted CRLFs that are in comments, although particular parsing programs may want to note where they are. For those programs, it would be reasonable to read a "CRLF LWSP-char" as a CRLF that's part of the comment. So the CRLF is kept and the LWSP-char gets thrown out. Quoted CRLFs (that is, a backslash followed by a CR followed by a LF) still must be followed by at least one LWSP-char 💖
August 13, 1982 - 12 - RFC #822
3.4.4. DELIMITING AND QUOTING CHARACTERS 🎀
The quote character (backslash), and the characters that delimit syntactic units, are generally not data that's part of the unit they delimit or quote 🫶 In particular, the quotation-marks that define a quoted-string, the parentheses that define a comment, and the backslash that quotes a following character are NOT part of the quoted-string, comment, or quoted character. If a quotation-mark is supposed to be part of a quoted-string, a parenthesis is supposed to be part of a comment, or a backslash is supposed to be part of either one, each of those must be preceded by the quote-character backslash ("\"). Also, the syntax lets you quote any character inside a quoted-string or comment, but only certain characters MUST be quoted to be included as data. Those are the ones that aren't part of the alternate text group (that is, ctext or qtext) 🧁
The one exception is that a single SPACE is assumed to exist between contiguous words in a phrase, no matter how many LWSP-chars the creator actually put between the words. If you want more than one SPACE, the creator has to put the LWSP-chars inside a quoted-string 🌈
Quotation marks that delimit a quoted string, and backslashes that quote the following character, should NOT go along with the quoted-string when it's passed to processes that don't interpret data according to this specification (like mail protocol servers) 🙈
3.4.5. QUOTED-STRINGS 🎈
Where they're allowed (that is, in words inside structured fields), quoted-strings are treated as one single symbol. So a quoted-string is syntactically equivalent to an atom 🧸 If a quoted-string is going to be "folded" onto multiple lines, the syntax for folding must be followed. (See the "Lexical Analysis of Messages" section on "Folding Long Header Fields" above, and the section on "Case Independence" below.) So the official semantics don't "see" any bare CRLFs inside quoted-strings, though particular parsing programs may want to note them. For those programs, it would be reasonable to read a "CRLF LWSP-char" as a CRLF that's part of the quoted-string. The CRLF gets kept and the LWSP-char gets dropped. Quoted CRLFs (a backslash followed by a CR followed by a LF) are also subject to the folding rules, but the backslash explicitly tells you the CRLF is data for the quoted string. Stripping the first following LWSP-char is also appropriate when you're parsing quoted CRLFs ✨
August 13, 1982 - 13 - RFC #822
3.4.6. BRACKETING CHARACTERS 🧷
There's one type of bracket that has to come in matched pairs, and pairs of it can nest inside each other:
- Parentheses (
"("and")") are used to indicate comments.
There are three types of brackets that have to come in matched pairs and may NOT be nested:
- Colon/semi-colon (
":"and";") are used in address specifications to indicate that the included list of addresses is to be treated as a group. - Angle brackets (
"<"and">") are generally used to indicate the presence of a single machine-usable reference (for example, delimiting mailboxes), possibly including source-routing to the machine. - Square brackets (
"["and"]") are used to indicate the presence of a domain-literal, which the appropriate name-domain is to use directly, bypassing normal name-resolution mechanisms 🗺️
3.4.7. CASE INDEPENDENCE 🔤
Except where noted, alphabetic strings can be written in any combination of upper and lower case 🌷 The only syntactic units that need case information preserved are:
- text
- qtext
- dtext
- ctext
- quoted-pair
- local-part, except "Postmaster"
When you're matching any other syntactic unit, ignore case. For example, the field-names "From", "FROM", "from", and even "FroM" are semantically equal and should all be treated identically 💜
When you're generating these units, any mix of upper and lower case alphabetic characters may be used. The case shown in this specification is the one suggested for message-creating processes.
Note: The reserved local-part address unit, "Postmaster", is an exception. When the value "Postmaster" is being interpreted, it must be accepted in any mixture of case, including "POSTMASTER" and "postmaster" 🙌
August 13, 1982 - 14 - RFC #822
3.4.8. FOLDING LONG HEADER FIELDS 🌸
Each header field gets to live on exactly one line, bestie: its name and its body, ending in a CRLF. That's the line the parser actually reads 🎀. For readability, though, the body of a long header field can be "folded" across several lines. "Long" usually means over 65 or 72 characters. The 65 is a limit when the message gets viewed on basic terminals with basic display software, but the standard itself doesn't enforce it 💅.
Note: some display software can fold lines on its own to fit the terminal. When that happens, folding done by the sender can clash with the display software 🙈.
3.4.9. BACKSPACE CHARACTERS 🦋
ASCII BS characters (Backspace, decimal 8) can show up in text and quoted-strings so you can overstrike things 😭. Any backspace that overstrikes to the left of where the text or quoted-string begins is prohibited, so don't even try it 🚫.
3.4.10. NETWORK-SPECIFIC TRANSFORMATIONS 🌈
When a message travels through heterogeneous networks, sometimes the data has to be forced to fit a network's local rules 🧚. For example, a CR might have to be followed by an LF to make a CRLF, or by a <null> if the CR is supposed to stand alone. These transformations get reversed once the message leaves that network ✨.
When a message crosses network boundaries, think of it as passing through two modules. First it enters the module holding whatever network-specific transformations were needed to get through the "current" network. Then it goes through these modules, in order:
- Transformation Reversal: the "current" network's idiosyncrasies get removed, and the message goes back to the canonical form defined in this standard 🔄.
- Transformation: the "next" network's local idiosyncrasies get imposed on the message 💖.
Here's the picture, because it's giving diagram energy:
------------------
From ==> | Remove Net-A |
Net-A | idiosyncracies |
------------------
||
\/
Conformance
with standard
||
\/
------------------
| Impose Net-B | ==> To
| idiosyncracies | Net-B
------------------4. MESSAGE SPECIFICATION 📬
4.1. SYNTAX 💌
Note: because of how the notation works, the syntax makes it look like some fields have to appear in a particular order. That's an artifact, ngl 🙃. Header fields are not required to show up in any particular order. The one real rule is that the message body has to come after the headers. It's recommended that headers, if present, be sent in the order Return-Path, Received, Date, From, Subject, Sender, To, cc, and so on 📋.
This spec allows multiple occurrences of most fields. Unless noted otherwise, how those repeats get interpreted isn't specified here, and using them is discouraged 🙅♀️.
The syntax for the bodies of the various fields should be thought of as describing each field body as one long string, or one long line 🧵. The "Lexical Analysis of Message" section, under "Long Header Fields" above, explains how those long strings can be spread across more than one line in the actual transmitted message.
message = fields *( CRLF *text ) ; Everything after
; first null line
; is message body
fields = dates ; Creation time,
source ; author id & one
1*destination ; address required
*optional-field ; others optional
source = [ trace ] ; net traversals
originator ; original mail
[ resent ] ; forwarded
trace = return ; path to sender
1*received ; receipt tags
return = "Return-path" ":" route-addr ; return address
received = "Received" ":" ; one per relay
["from" domain] ; sending host
["by" domain] ; receiving host
["via" atom] ; physical path
*("with" atom) ; link/mail protocol
["id" msg-id] ; receiver msg id
["for" addr-spec] ; initial form
";" date-time ; time received
originator = authentic ; authenticated addr
[ "Reply-To" ":" 1#address] )
authentic = "From" ":" mailbox ; Single author
/ ( "Sender" ":" mailbox ; Actual submittor
"From" ":" 1#mailbox) ; Multiple authors
; or not sender
resent = resent-authentic
[ "Resent-Reply-To" ":" 1#address] )
resent-authentic =
= "Resent-From" ":" mailbox
/ ( "Resent-Sender" ":" mailbox
"Resent-From" ":" 1#mailbox )
dates = orig-date ; Original
[ resent-date ] ; Forwarded
orig-date = "Date" ":" date-time
resent-date = "Resent-Date" ":" date-time
destination = "To" ":" 1#address ; Primary
/ "Resent-To" ":" 1#address
/ "cc" ":" 1#address ; Secondary
/ "Resent-cc" ":" 1#address
/ "bcc" ":" #address ; Blind carbon
/ "Resent-bcc" ":" #address
optional-field =
/ "Message-ID" ":" msg-id
/ "Resent-Message-ID" ":" msg-id
/ "In-Reply-To" ":" *(phrase / msg-id)
/ "References" ":" *(phrase / msg-id)
/ "Keywords" ":" #phrase
/ "Subject" ":" *text
/ "Comments" ":" *text
/ "Encrypted" ":" 1#2word
/ extension-field ; To be defined
/ user-defined-field ; May be pre-empted
msg-id = "<" addr-spec ">" ; Unique message id
extension-field =
<Any field which is defined in a document
published as a formal extension to this
specification; none will have names beginning
with the string "X-">
user-defined-field =
<Any field which has not been defined
in this specification or published as an
extension to this specification; names for
such fields must be unique and may be
pre-empted by published extensions>4.2. FORWARDING 🔁
Some systems let mail recipients forward a message while keeping the original headers, by adding some new fields 💅. This standard supports that kind of service through the Resent- prefix on field names.
Whenever the string Resent- starts a field name, that field has the same semantics as the field without the prefix 💜. The catch is that the message is assumed to have been forwarded by an original recipient, the one who attached the Resent- field. That new field counts as more recent than the equivalent original field 🕰️. So, for example, Resent-From tells you who forwarded the message, while From tells you who the original author was 👑.
How that precedence info gets used depends on what the participants need 🤷♀️. This standard doesn't dictate, for instance, when a Resent-From: address should receive replies instead of the From: address.
Note: in general, the Resent- fields should be treated as holding a set of information that's independent of the original fields 🧠. Info shouldn't automatically get pulled from one set into the other. How you interpret multiple Resent- fields of the same type is undefined, so don't assume anything there 🙈.
For the rest of this spec, legal Resent- fields get treated exactly the same as fields without that prefix ✨.
4.3. TRACE FIELDS 🕵️♀️
Trace information gives you an audit trail of how the message was handled 📜. It also tells you the route back to the sender, which is so useful 🦋.
The known via and with values are registered with the Network Information Center, SRI International, Menlo Park, California 🗺️.
4.3.1. RETURN-PATH 🛤️
The final transport system that delivers the message to its recipient adds this field 📮. It's meant to hold definitive information about the address and the route back to the message's originator, so it's kind of a big deal 👑.
Note: the Reply-To field is added by the originator, and it's there to direct replies 💌. Return-Path, on the other hand, identifies a path back to the originator 🧭. They're different jobs, bestie.
Even though the syntax says the route specification is optional, every attempt should be made to include that info in this field 🫶.
4.3.2. RECEIVED 📥
Every transport service that relays the message adds a copy of this field 🚚. The info in it can be super useful for tracing transport problems 🔍.
The names of the sending and receiving hosts, plus the time of receipt, may be specified 🕰️. The via parameter can show what physical mechanism the message traveled over, like Arpanet or Phonenet 🛰️. The with parameter can show the mail-level or connection-level protocol that got used, like the SMTP mail protocol or the X.25 transport protocol 🔌.
Note: you can include several with parameters to fully spell out the whole set of protocols that were used 🌸.
okay so some transport services queue mail 📬, and the internal message identifier that gets assigned to the message can be noted with the id parameter 🆔✨. when the sending host uses a destination address spec that the receiving host reinterprets (by expansion or transformation 🔁), the receiving host may wish to record the original spec using the for parameter 💌. like, when a copy of mail goes to a member of a distribution list, this parameter can record the original address that was used to specify the list 📋🫶
4.4. ORIGINATOR FIELDS 💅
the standard only allows a subset of the combinations possible with the From, Sender, Reply-To, Resent-From, Resent-Sender, and Resent-Reply-To fields 🙃 and that limit is on purpose, not an accident 🫶
4.4.1. FROM / RESENT-FROM 💖
this field contains the identity of the person(s) who wanted this message sent 📨. the message-creation process should default this field to a single, authenticated machine address that shows the AGENT (person, system or process) entering the message 🤖. if that isn't done, the "Sender" field MUST be present 🚨. if the "From" field IS defaulted this way, the "Sender" field is optional and redundant with the "From" field, so it's giving extra 😌. in every case, addresses in the "From" field must be machine-usable (addr-specs) and may not contain named lists (groups) 🙅♀️
4.4.2. SENDER / RESENT-SENDER 🎀
this field contains the authenticated identity of the AGENT (person, system or process) that sends the message 🔐. it's meant for when the sender isn't the author of the message, or to show who among a group of authors actually hit send 📤. if the contents of the "Sender" field would be completely redundant with the "From" field, the "Sender" field doesn't need to be there, and using it is discouraged (though still legal) 🙈. the "Sender" field MUST be present if it is not the same as the "From" field 🚨
the Sender mailbox spec includes a word sequence that has to correspond to a specific agent (a human user or a computer program) rather than a standard address 👑. the vibe here is that the field should name the single AGENT (person, system, or process) actually responsible for sending the mail, not just the name of a mailbox the mail came from 📬. like, with a shared login name, the name by itself is not enough 🙅♀️. the local-part address unit that points to this agent is expected to be a computer system term, not (for example) a generalized person reference that could be used outside the network text message context 🖥️✨
okay now here's the lowkey important part 😭. the whole job of the "Sender" field is identifying the agent responsible for sending mail, and computer programs can't be held accountable for their behavior 💀. so it is strongly recommended that when a computer program generates a message, the HUMAN who is responsible for that program gets referenced as part of the "Sender" field mailbox spec 🫶🧚
4.4.3. REPLY-TO / RESENT-REPLY-TO 🦋
this field gives a general mechanism for indicating any mailbox(es) that replies should go to 💌. there are three typical uses, and they're all giving different energy 🌈. first, the author(s) might not have regular machine-based mailboxes, so they want to point to an alternate machine address 📭. second, an author might want additional persons to be aware of, or responsible for, replies 👯♀️. and a somewhat different use helps "text message teleconferencing" groups that have automatic distribution services 🎙️: you put that service's address in the "Reply-To" field of every message submitted to the teleconference, and then participants can "reply" to conference submissions to make sure their own submissions get distributed correctly 🔁✨
Note: the "Return-Path" field is added by the mail transport service, at the time of final delivery. it is intended to identify a path back to the originator of the message. the "Reply-To" field is added by the message originator and is intended to direct replies. 📮
4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO 🤖💅
for systems that automatically generate address lists for replies to messages, here are the recs 📝:
- the "Sender" field mailbox should be sent notices of any problems in transport or delivery of the original messages. if there's no "Sender" field, then the "From" field mailbox should be used 🚨
- the "Sender" field mailbox should NEVER be used automatically, in a recipient's reply message 🙅♀️💀
- if the "Reply-To" field exists, then the reply should go to the addresses indicated in that field, and not to the address(es) indicated in the "From" field 🎯
- if there is a "From" field but no "Reply-To" field, the reply should be sent to the address(es) indicated in the "From" field 📨
sometimes a recipient actually wants to talk to the person who started the message transfer 🥹. in that case, it's reasonable to use the "Sender" address 💌
this recommendation is only meant for automated use of originator fields 🤖. it is not meant to suggest that replies can't also go to other recipients of messages 🙅♀️. it's up to the respective mail-handling programs to decide what additional facilities they provide ✨
examples are provided in Appendix A 📚🎀
4.5. RECEIVER FIELDS 💜
4.5.1. TO / RESENT-TO 🎯
this field contains the identity of the primary recipients of the message 👑
4.5.2. CC / RESENT-CC 🌸
this field contains the identity of the secondary (informational) recipients of the message 👀
4.5.3. BCC / RESENT-BCC 🙈
this field contains the identity of additional recipients of the message 🫣. the contents of this field are not included in copies of the message sent to the primary and secondary recipients 🤫. some systems may choose to include the text of the "Bcc" field only in the author(s)'s copy, while others may also include it in the text sent to everyone listed in the "Bcc" list 🫢
4.6. REFERENCE FIELDS 🔗
4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID 🆔
this field contains a unique identifier (the local-part address unit) that refers to THIS version of THIS message ✨. the uniqueness of the message identifier is guaranteed by the host that generates it 🖥️. this identifier is meant to be machine readable and not necessarily meaningful to humans 🤖. a message identifier pertains to exactly one instantiation of a particular message, so subsequent revisions to the message should each get new message identifiers 🔄💖
4.6.2. IN-REPLY-TO 💬
the contents of this field identify previous correspondence that this message answers 🫶. note that if message identifiers are used in this field, they must use the msg-id specification format 📐
4.6.3. REFERENCES 📚
the contents of this field identify other correspondence that this message references 🔍. note that if message identifiers are used, they must use the msg-id specification format 📐✨
4.6.4. KEYWORDS 🏷️
this field contains keywords or phrases, separated by commas 🧁
4.7. OTHER FIELDS 🎀
4.7.1. SUBJECT 💌
this is meant to give a summary, or show the nature, of the message 📝
4.7.2. COMMENTS 💬
this lets you add text comments onto the message without messing with the contents of the message's body 🫶
4.7.3. ENCRYPTED 🔐
sometimes data encryption gets used to boost the privacy of message contents 🕵️♀️. if the body of a message has been encrypted to keep its contents private, the "Encrypted" field can be used to note the fact and to show the nature of the encryption 🔒. the first <word> parameter shows the software used to encrypt the body, and the second, optional <word> helps the recipient pick the right decryption key 🗝️. this code word works like an index to a table of keys that the recipient holds 📖
Note: unfortunately, headers have to contain envelope information as well as contents information 😭. so they need to stay unencrypted, so mail transport services can access them 🚚. since names, addresses, and "Subject" field contents may contain sensitive information, this requirement limits total message privacy 🫠
names of encryption software are registered with the Network Information Center, SRI International, Menlo Park, California 📋✨
4.7.4. EXTENSION-FIELD 🧚
a limited number of common fields have been defined in this document 🌷. as network mail requirements call for it, more fields may be standardized 📈. to give user-defined fields a measure of safety when it comes to naming, extension-fields will never have names that begin with the string "X-" 🛡️💜
names of extension-fields are registered with the Network Information Center, SRI International, Menlo Park, California 📋🎀
4.7.5. USER-DEFINED-FIELD 🌈
individual users of network mail are free to define and use additional header fields 🦄. those fields must have names that aren't already used in the current specification or in any definitions of extension-fields 🙅♀️, and the overall syntax of user-defined-fields must conform to this specification's rules for delimiting and folding fields ✂️. because of the extension-field publishing process, the name of a user-defined-field may be pre-empted
Note: the prefatory string "X-" will never be used in the names of extension-fields. this gives user-defined fields a protected set of names 🛡️🫶
5. DATE AND TIME SPECIFICATION ⏰
5.1. SYNTAX 📅
date-time = [ day "," ] date time ; dd mm yy
; hh:mm:ss zzz5. DATE AND TIME SPECIFICATION ✨ (continued)
day = "Mon" / "Tue" / "Wed" / "Thu"
/ "Fri" / "Sat" / "Sun"
date = 1*2DIGIT month 2DIGIT ; day month year
; e.g. 20 Jun 82
month = "Jan" / "Feb" / "Mar" / "Apr"
/ "May" / "Jun" / "Jul" / "Aug"
/ "Sep" / "Oct" / "Nov" / "Dec"
time = hour zone ; ANSI and Military
hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT]
; 00:00:00 - 23:59:59
zone = "UT" / "GMT" ; Universal Time
; North American : UT
/ "EST" / "EDT" ; Eastern: - 5/ - 4
/ "CST" / "CDT" ; Central: - 6/ - 5
/ "MST" / "MDT" ; Mountain: - 7/ - 6
/ "PST" / "PDT" ; Pacific: - 8/ - 7
/ 1ALPHA ; Military: Z = UT;
; A:-1; (J not used)
; M:-12; N:+1; Y:+12
/ ( ("+" / "-") 4DIGIT ) ; Local differential
; hours+min. (HHMM)5.2. SEMANTICS ✨
okay so, if you include a day-of-week, it must be the day that the date actually lands on 📅
time zones are lowkey a whole mood 🌍 "UT" is Universal Time (it used to be called "Greenwich Mean Time"), and "GMT" is allowed as a way of referring to Universal Time too. The military standard gives each zone a single letter 🫶 "Z" is Universal Time, "A" means one hour earlier, and "M" means 12 hours earlier. On the other side, "N" is one hour later and "Y" is 12 hours later. The letter "J" is not used, so don't even try it 🙅♀️ The other two forms come from ANSI standard X3.51-1975. One lets you spell out the exact offset from UT, and the other uses those cute 3-character strings for North American zones 🇺🇸
6. ADDRESS SPECIFICATION 🦋
6.1. SYNTAX 🎀
address = mailbox ; one addressee
/ group ; named list
group = phrase ":" [#mailbox] ";"
mailbox = addr-spec ; simple address
/ phrase route-addr ; name & addr-spec
route-addr = "<" [route] addr-spec ">"
route = 1#("@" domain) ":" ; path-relative
addr-spec = local-part "@" domain ; global address
local-part = word *("." word) ; uninterpreted
; case-preserved
domain = sub-domain *("." sub-domain)
sub-domain = domain-ref / domain-literal
domain-ref = atom ; symbolic reference6.2. SEMANTICS 💜
a mailbox is the thing that receives mail 📬 It's a conceptual entity, so it doesn't have to be tied to file storage. Some sites might print the mail on their line printer and hand it over to the addressee's desk, and honestly that's iconic 🖨️
A mailbox spec is made of three bits: a person, system, or process name reference, a domain-dependent string, and a name-domain reference. The name reference is optional and usually shows the human name of the recipient 🧚 The name-domain reference is a sequence of sub-domains. The domain-dependent string is uninterpreted, except by the final sub-domain. The rest of the mail service just passes it along as a literal string, no questions asked 🤐
6.2.1. DOMAINS 🌸
A name-domain is a set of registered (mail) names. A name-domain spec resolves either to a subordinate name-domain spec or to a terminal domain-dependent string. So domain specs are extensible and can have any number of registration levels, which is giving infinite scrolling 🌀
Name-domains model a global, logical, hierarchical addressing scheme. It's logical because an address spec is tied to name registration and not necessarily to the transmission path. The hierarchy is a directed graph called an in-tree, so there's exactly one path from the root to any node. If more than one path actually exists, they count as different addresses 🛤️
The root node is shared by all addresses, so nobody ever writes it down. Its children are the "top-level" name-domains. A service usually has access to its own full domain spec and to the names of all top-level name-domains 👑
The "top" of the domain hierarchy (a child of the root) is the right-most field in a domain spec. Its child sits to the left of it, and that child's child sits to the left of that, and so on 🔍
Some groups offer formal registration services, and those count as name-domains that don't depend logically on specific machines. Networks and machines also end up forming name-domains on their own, since their membership is usually recorded in name tables 📒
With formal registration, an organization runs a (distributed) database that maps addresses to routes. Those addresses look like this:
person@registry.organization"Organization" is a logical entity, so it's separate from any particular communication network. Any mechanism for reaching "organization" is universally available 🌍 That mechanism then looks for an instance of the registry. Its location isn't written in the address spec. It's assumed that the system running under the name "organization" knows how to find a subordinate registry. The registry then uses the "person" string to figure out where to send the mail spec 📮
The network-oriented case is simpler and more direct, and it's tied to attachment. It looks like this:
user@host.networkOnce the network is accessed, a message is expected to go directly to the host. The host then resolves the user name and drops the message into that user's mailbox 💌
6.2.2. ABBREVIATED DOMAIN SPECIFICATION 🫧
Since the domain hierarchy can have any number of levels, writing out a fully qualified address can get super inconvenient 😩 So this standard allows abbreviated domain specs in one special case:
For the sender's address, call the left-most sub-domain Level N. In a header address, if all of the sub-domains above it (that is, to its right) are the same as the sender's, they don't have to show up in the spec. Otherwise, the address must be fully qualified. This feature has to be approved by local sub-domains, and individual sub-domains may require their member systems that originate mail to give full domain specs only. When it's allowed, abbreviations may only be used while the message stays inside the sender's sub-domain. Using this mechanism requires the sender's sub-domain to reserve the names of all top-level domains, so that full specs can be told apart from abbreviated ones. 🔐
Here's an example. The sender's address is:
sender@registry-A.registry-1.organization-XOne recipient's address is:
recipient@registry-B.registry-1.organization-Xand another's is:
recipient@registry-C.registry-2.organization-XSo ".registry-1.organization-X" doesn't need to be written out in the message, but "registry-C.registry-2" DOES have to be specified. The first two addresses can be abbreviated, but the third one must be fully specified 🧩
When a message crosses a domain boundary, every address must be written in the full format, ending with the top-level name-domain in the right-most field. Mail forwarding services are responsible for making sure addresses follow this rule. If there are abbreviated addresses, the relaying service has to expand them. It's worth knowing that it's often hard for such a service to find every occurrence of an abbreviation, because it can't find them inside the body of the message 😬 The "Return-Path" field can help recipients recover from these errors 💖
Note: When any portion of an addr-spec gets passed on to a process that doesn't interpret data according to this standard (for example, mail protocol servers), there must be NO LWSP-chars before or after the at-sign or any delimiting period ("."), like in the examples above. There also has to be only ONE SPACE between contiguous <word>s. 🚨
6.2.3. DOMAIN TERMS 🍓
A domain-ref must be THE official name of a registry, network, or host. It's a symbolic reference inside a name sub-domain. Sometimes you have to skip the usual ways of resolving these references and use more basic info, like a network host address instead of its host name 🔧
To allow for that, this standard gives you the domain-literal construct. Its contents must conform to the needs of the sub-domain where it's interpreted.
Domain-literals that refer to domains within the ARPA Internet specify 32-bit Internet addresses, written as four 8-bit fields in decimal, as described in Request for Comments #820, "Assigned Numbers." For example:
[10.0.3.19]Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. They're only allowed as a way to get around temporary system limitations, like name tables that aren't complete yet. 🙅♀️
The names of "top-level" domains, and the names of domains under them in the ARPA Internet, are registered with the Network Information Center, SRI International, Menlo Park, California 🗺️
6.2.4. DOMAIN-DEPENDENT LOCAL STRING 🌈
The local-part of an addr-spec in a mailbox spec (that is, the host's name for the mailbox) is understood to be whatever the receiving mail protocol server allows. For example, some systems don't understand mailbox references like "P. D. Q. Bach", but others totally do 🎶
periods (".") are lexical separators in this spec, so 🦋 the parser totally notices them when they show up in a local-part that isn't a quoted-string ✨ BUT, the tea ☕, they carry NO semantics 💀. If a local-part has periods in it, the address parser chops it into several tokens, but the sequence of tokens gets treated as ONE uninterpreted unit 🫶. It gets glued back together when the address leaves the system, like when it's passed to a mail protocol service 🎀.
For example, this address:
First.Last@Registry.Orgis legal 💅 and the local-part does NOT need quotation-marks around it. (However, "First Last" DOES need quoting 😭.) When the local-part gets passed outside the mail system, within the Registry.Org domain, it's "First.Last", again with no quotation marks 🌸.
6.2.5. BALANCING LOCAL-PART AND DOMAIN
the line between local-part and domain can be kinda flexible 🦋. The local-part can be a simple string, used for the final decision of which mailbox the recipient gets. Everything else, all the other levels of reference, is therefore part of the domain 💜.
Some systems let you do abbreviated reference to the local and subordinate sub-domains, so you can specify only one reference in the domain part and stick the other, subordinate name-domain references in the local-part. It would look like this:
mailbox.sub1.sub2@this-domainAddress parsers that follow RFC #733 would accept that, even though they don't support this newer Internet standard 🙈. It goes against the intent of this standard, but the form is still legal 💅.
Also, some sub-domains have a specification syntax that doesn't follow this standard. For example:
sub-net.mailbox@sub-domain.domainAugust 13, 1982 - 31 - RFC #822
uses a different parsing sequence for the local-part than it does for the domain 👑.
Note: As a rule, the domain specification should contain fields which are encoded according to the syntax of this standard and which contain generally-standardized information. The local-part specification should contain only that portion of the address which deviates from the form or intention of the domain field 🌈.
6.2.6. MULTIPLE MAILBOXES
Someone can have several mailboxes and want to receive mail at whichever one is convenient for the sender to reach 🧚. This standard doesn't give you a way to specify "any member of" a list of mailboxes 💀.
A group of people might want to receive mail as a single unit, aka a distribution list 🎀. The <group> construct lets you specify a list like that. Recipient mailboxes go inside the bracketed part (":" - ";") 🫶. A copy of the transmitted message gets sent to each mailbox on the list. This standard does NOT allow recursive specification of groups within groups 🙅♀️.
A list has to be named, but it's not required that the contents of the list be included 🌸. In that case, the <address> is just an indication of group distribution, and it looks like this:
name:;Some mail services might offer a group-list distribution facility 🦋. They accept a single mailbox reference, expand it into the full distribution list, and relay the mail to the list's members ✨. This standard doesn't give any extra syntax for showing that kind of service 🤷♀️. Using the <group> address alternative while listing just one mailbox in it can mean either that the mailbox reference will be expanded into a list, or that there's a group with one member 👀.
6.2.7. EXPLICIT PATH SPECIFICATION
Sometimes a message originator wants to say which transmission path a message should follow 🛣️. This is called source routing 💅. The normal addressing scheme, used in an addr-spec, is carefully kept separate from that info, and the <route> portion of a route-addr is there for those moments ✨. It specifies the sequence of hosts and/or transmission services that the message is supposed to go through 🧚. Both domain-refs and domain-literals can be used 🌈.
August 13, 1982 - 31 - RFC #822
Note: The use of source routing is discouraged 💀. Unless the sender has a special need for path restriction, the choice of transmission route should be left to the mail transport service 🫶.
6.3. RESERVED ADDRESS
It's often necessary to send mail to a site without knowing any of its valid addresses 🥺. For example, there might be mail system dysfunctions, or a user might want to find out a person's correct address at that site 🔍.
This standard specifies a single, reserved mailbox address (local-part) that is to be valid at each site ✨. Mail sent to that address is to be routed to a person responsible for the site's mail system, or to a person with responsibility for general site operation 👑. The name of the reserved local-part address is:
Postmasterso that Postmaster@domain is required to be valid 💖.
Note: This reserved local-part must be matched without sensitivity to alphabetic case, so that POSTMASTER, postmaster, and even poStmASteR are to be accepted 🌈.
August 13, 1982 - 31 - RFC #822
7. BIBLIOGRAPHY ✨
ANSI. "USA Standard Code for Information Interchange," X3.4. American National Standards Institute: New York (1968). Also in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104.
ANSI. "Representations of Universal Time, Local Time Differentials, and United States Time Zone References for Information Interchange," X3.51-1975. American National Standards Institute: New York (1975).
Bemer, R.W., "Time and the Computer." In: Interface Age (Feb. 1979).
Bennett, C.J. "JNT Mail Protocol". Joint Network Team, Rutherford and Appleton Laboratory: Didcot, England.
Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., and White, J.E. "Standardizing Network Mail Headers," ARPANET Request for Comments No. 561, Network Information Center No. 18516; SRI International: Menlo Park (September 1973).
Birrell, A.D., Levin, R., Needham, R.M., and Schroeder, M.D. "Grapevine: An Exercise in Distributed Computing," Communications of the ACM 25, 4 (April 1982), 260-274.
Crocker, D.H., Vittal, J.J., Pogran, K.T., Henderson, D.A. "Standard for the Format of ARPA Network Text Message," ARPANET Request for Comments No. 733, Network Information Center No. 41952. SRI International: Menlo Park (November 1977).
Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook, Network Information Center No. 7104 (NTIS AD A003890). SRI International: Menlo Park (April 1976).
Harary, F. "Graph Theory". Addison-Wesley: Reading, Mass. (1969).
Levin, R. and Schroeder, M. "Transport of Electronic Messages through a Network," TeleInformatics 79, pp. 29-33. North Holland (1979). Also as Xerox Palo Alto Research Center Technical Report CSL-79-4.
Myer, T.H. and Henderson, D.A. "Message Transmission Protocol," ARPANET Request for Comments, No. 680, Network Information Center No. 32116. SRI International: Menlo Park (1975).
August 13, 1982 - 35 - RFC #822 is not a page we need, so here's the rest 🫶
NBS. "Specification of Message Format for Computer Based Message Systems, Recommended Federal Information Processing Standard." National Bureau of Standards: Gaithersburg, Maryland (October 1981).
NIC. Internet Protocol Transition Workbook. Network Information Center, SRI-International, Menlo Park, California (March 1982).
Oppen, D.C. and Dalal, Y.K. "The Clearinghouse: A Decentralized Agent for Locating Named Objects in a Distributed Environment," OPD-T8103. Xerox Office Products Division: Palo Alto, CA. (October 1981).
Postel, J.B. "Assigned Numbers," ARPANET Request for Comments, No. 820. SRI International: Menlo Park (August 1982).
Postel, J.B. "Simple Mail Transfer Protocol," ARPANET Request for Comments, No. 821. SRI International: Menlo Park (August 1982).
Shoch, J.F. "Internetwork naming, addressing and routing," in Proc. 17th IEEE Computer Society International Conference, pp. 72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C.
Su, Z. and Postel, J. "The Domain Naming Convention for Internet User Applications," ARPANET Request for Comments, No. 819. SRI International: Menlo Park (August 1982).
A. EXAMPLES 💖
A.1. ADDRESSES 🎀
A.1.1. Alfred Neuman <Neuman@BBN-TENEXA>
A.1.2. Neuman@BBN-TENEXA
These two "Alfred Neuman" examples have identical semantics, as far as the operation of the local host's mail sending (distribution) program (also sometimes called its "mailer") and the remote host's mail protocol server are concerned. In the first example, the "Alfred Neuman" is ignored by the mailer, as "Neuman@BBN-TENEXA" completely specifies the recipient. The second example contains no superfluous information, and, again, "Neuman@BBN-TENEXA" is the intended recipient 🧠.
Note: When the message crosses name-domain boundaries, then these specifications must be changed, so as to indicate the remainder of the hierarchy, starting with the top level 🌍.
A.1.3. "George, Ted" <Shared@Group.Arpanet>
This form might be used to indicate that a single mailbox is shared by several users 👯♀️. The quoted string is ignored by the originating host's mailer, because "Shared@Group.Arpanet" completely specifies the destination mailbox ✨.
A.1.4. Wilt . (the Stilt) Chamberlain@NBA.US
The "(the Stilt)" is a comment, which is not included in the destination mailbox address handed to the originating system's mailer 🙃. The local-part of the address is the string "Wilt.Chamberlain", with NO space between the first and second words 🏀.
A.1.5. Address Lists
Gourmets: Pompous Person <WhoZiWhatZit@Cordon-Bleu>,
Childs@WGBH.Boston, Galloping Gourmet@
ANT.Down-Under (Australian National Television),
Cheapie@Discount-Liquors;,
Cruisers: Port@Portugal, Jones@SEA;,
Another@Somewhere.SomeOrgThis group list example shows off comments and how you can mix addresses and groups together, bestie 🎀 It's giving organized chaos ✨
A.2. ORIGINATOR ITEMS ✨
A.2.1. Author-sent
Okay so George Jones logs into his host as "Jones" and sends mail himself, no middleman needed 💅
From: Jones@Group.Orgor
From: George Jones <Jones@Group.Org>A.2.2. Secretary-sent
George Jones logs in as Jones on his host. His secretary, who logs in as Secy, sends mail for him 🫶 Replies to the mail should go to George, not the secretary, because main character energy belongs to George 👑
From: George Jones <Jones@Group>
Sender: Secy@Other-GroupA.2.3. Secretary-sent, for user of shared directory
George Jones' secretary sends mail for George, and replies should go to George 🦋
From: George Jones<Shared@Group.Org>
Sender: Secy@Other-GroupNote that there need not be a space between "Jones" and the "<", but adding a space enhances readability (as is the case in other examples. 🌸
A.2.4. Committee activity, with one author
George is a member of a committee, and he wants any replies to his message to go to all committee members. Iconic behaviour 🔥
From: George Jones <Jones@Host.Net>
Sender: Jones@Host
Reply-To: The Committee: Jones@Host.Net,
Smith@Other.Org,
Doe@Somewhere-Else;Note that if George had not included himself in the enumeration of The Committee, he would not have gotten an implicit reply. The presence of the "Reply-to" field SUPERSEDES the sending of a reply to the person named in the "From" field 🙈
A.2.5. Secretary acting as full agent of author
George Jones asks his secretary (Secy@Host) to send a message for him in his capacity as Group. He wants his secretary to handle all replies, so the secretary is the one in charge 💅
From: George Jones <Group@Host>
Sender: Secy@Host
Reply-To: Secy@HostA.2.6. Agent for user without online mailbox
A friend of George's, Sarah, is visiting 🧚 George's secretary sends some mail to a friend of Sarah in computerland. Replies should go to George, whose mailbox is Jones at Registry.
From: Sarah Friendly <Secy@Registry>
Sender: Secy-Name <Secy@Registry>
Reply-To: Jones@Registry.A.2.7. Agent for member of a committee
George's secretary sends out a message that was authored jointly by all the members of a committee 🌈 The name of the committee cannot be specified here, since <group> names are not permitted in the From field.
From: Jones@Host,
Smith@Other-Host,
Doe@Somewhere-Else
Sender: Secy@SHostA.3. COMPLETE HEADERS 🍓
A.3.1. Minimum required
Date: 26 Aug 76 1429 EDT Date: 26 Aug 76 1429 EDT
From: Jones@Registry.Org or From: Jones@Registry.Org
Bcc: To: Smith@Registry.OrgNote that the "Bcc" field may be empty, while the "To" field is required to have at least one address 💜
A.3.2. Using some of the additional fields
Date: 26 Aug 76 1430 EDT
From: George Jones<Group@Host>
Sender: Secy@SHOST
To: "Al Neuman"@Mad-Host,
Sam.Irving@Other-Host
Message-ID: <some.string@SHOST>A.3.3. About as complex as you're going to get
This one is a lot, but honestly it's gorgeous 😭✨
Date : 27 Aug 76 0932 PDT
From : Ken Davis <KDavis@This-Host.This-net>
Subject : Re: The Syntax in the RFC
Sender : KSecy@Other-Host
Reply-To : Sam.Irving@Reg.Organization
To : George Jones <Group@Some-Reg.An-Org>,
Al.Neuman@MAD.Publisher
cc : Important folk:
Tom Softwood <Balsa@Tree.Root>,
"Sam Irving"@Other-Host;,
Standard Distribution:
/main/davis/people/standard@Other-Host,
"<Jones>standard.dist.3"@Tops-20-Host>;
Comment : Sam is away on business. He asked me to handle
his mail for him. He'll be able to provide a
more accurate explanation when he returns
next week.
In-Reply-To: <some.string@DBM.Group>, George's message
X-Special-action: This is a sample of user-defined field-
names. There could also be a field-name
"Special-action", but its name might later be
preempted
Message-ID: <4231.629.XYzi-What@Other-Host>B. SIMPLE FIELD PARSING 🌸
Some mail-reading software systems may only want to do minimal processing. They can ignore the internal syntax of structured field-bodies and treat them the same as unstructured field-bodies. Such software only needs to tell apart:
- Header fields from the message body,
- Beginnings of fields from lines which continue fields,
- Field-names from field-contents.
The abbreviated set of syntactic rules below is enough for this purpose. It describes a limited view of messages and is a subset of the syntactic rules in the main part of this specification. One small exception is that the contents of field-bodies consist only of text 🦋
B.1. SYNTAX
message = *field *(CRLF *text)
field = field-name ":" [field-body] CRLF
field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
field-body = *text [CRLF LWSP-char field-body]B.2. SEMANTICS
Headers come before the message body and are ended by a null line (i.e., two contiguous CRLFs) 🫶
A line which continues a header field begins with a SPACE or HTAB character, while a line beginning a field starts with a printable character which is not a colon.
A field-name consists of one or more printable characters (excluding colon, space, and control-characters). A field-name MUST be contained on one line. Upper and lower case are not distinguished when comparing field-names. No drama there 💅
C. DIFFERENCES FROM RFC #733 💖
The following summarises the differences between this standard and the one specified in Arpanet Request for Comments #733, "Standard for the Format of ARPA Network Text Messages". The differences are listed in the order they show up in the current specification 🧚
C.1. FIELD DEFINITIONS
C.1.1. FIELD NAMES
These now must be a sequence of printable characters. They may not contain any LWSP-chars.
C.2. LEXICAL TOKENS
C.2.1. SPECIALS
The characters period ("."), left-square bracket ("["), and right-square bracket ("]") have been added. For presentation purposes, and when passing a specification to a system that does not conform to this standard, periods are to be contiguous with their surrounding lexical tokens. No linear-whitespace is permitted between them. The presence of one LWSP-char between other tokens is still directed.
C.2.2. ATOM
Atoms may not contain SPACE.
C.2.3. SPECIAL TEXT
ctext and qtext have had backslash ("") added to the list of prohibited characters.
C.2.4. DOMAINS
The lexical tokens <domain-literal> and <dtext> have been added 🌈
C.3. MESSAGE SPECIFICATION
C.3.1. TRACE
The "Return-path:" and "Received:" fields have been specified.
C.3.2. FROM
The "From" field must contain machine-usable addresses (addr-spec). Multiple addresses may be specified, but named-lists (groups) may not.
C.3.3. RESENT
The meta-construct of prefacing field names with the string "Resent-" has been added, to indicate that a message has been forwarded by an intermediate recipient 🦋
C.3.4. DESTINATION
A message must contain at least one destination address field. "To" and "CC" are required to contain at least one address.
C.3.5. IN-REPLY-TO
The field-body is no longer a comma-separated list, although a sequence is still permitted.
C.3.6. REFERENCE
The field-body is no longer a comma-separated list, although a sequence is still permitted.
C.3.7. ENCRYPTED
A field has been specified that lets senders indicate that the body of a message has been encrypted 🔥
C.3.8. EXTENSION-FIELD
Extension fields are prohibited from beginning with the characters "X-" 🙈
C.4. DATE AND TIME SPECIFICATION
C.4.1. SIMPLIFICATION
Fewer optional forms are permitted, and the list of three-letter time zones has been shortened ✨
C.5. ADDRESS SPECIFICATION
C.5.1. ADDRESS
The use of quoted-string, and the ":"-atom-":" construct, have been removed. An address now is either a single mailbox reference or a named list of addresses. The latter indicates a group distribution 💅
C.5.2. GROUPS
Group lists are now required to have a name. Group lists may not be nested.
C.5.3. MAILBOX
A mailbox specification may indicate a person's name, as before. Such a named list no longer may specify multiple mailboxes and may not be nested.
C.5.4. ROUTE ADDRESSING
Addresses are now taken to be absolute, global specifications, independent of transmission paths. The <route> construct has been provided, to permit explicit specification of transmission path. RFC #733's use of multiple at-signs ("@") was intended as a general syntax for indicating routing and/or hierarchical addressing. The current standard separates these specifications, and only one at-sign is permitted 👑
C.5.5. AT-SIGN
The string " at " no longer is used as an address delimiter. Only the at-sign ("@") serves the function.
C.5.6. DOMAINS
Hierarchical, logical name-domains have been added 🌸
C.6. RESERVED ADDRESS
The local-part "Postmaster" has been reserved, so that users can be guaranteed at least one valid address at a site 🎀
D. ALPHABETICAL LISTING OF SYNTAX RULES 🧚
address = mailbox ; one addressee
/ group ; named list
addr-spec = local-part "@" domain ; global address
ALPHA = <any ASCII alphabetic character>
; (101-132, 65.- 90.)
; (141-172, 97.-122.)
atom = 1*<any CHAR except specials, SPACE and CTLs>
authentic = "From" ":" mailbox ; Single author
/ ( "Sender" ":" mailbox ; Actual submittor
"From" ":" 1#mailbox) ; Multiple authors
; or not sender
CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
comment = "(" *(ctext / quoted-pair / comment) ")"
CR = <ASCII CR, carriage return> ; ( 15, 13.)
CRLF = CR LF
ctext = <any CHAR excluding "(", ; => may be folded
")", "\" & CR, & including
linear-white-space>
CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
character and DEL> ; ( 177, 127.)
date = 1*2DIGIT month 2DIGIT ; day month year
; e.g. 20 Jun 82
dates = orig-date ; Original
[ resent-date ] ; Forwarded
date-time = [ day "," ] date time ; dd mm yy
; hh:mm:ss zzz
day = "Mon" / "Tue" / "Wed" / "Thu"
/ "Fri" / "Sat" / "Sun"
delimiters = specials / linear-white-space / comment
destination = "To" ":" 1#address ; Primary
/ "Resent-To" ":" 1#address
/ "cc" ":" 1#address ; Secondary
/ "Resent-cc" ":" 1#address
/ "bcc" ":" #address ; Blind carbon
/ "Resent-bcc" ":" #address
DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.)
domain = sub-domain *("." sub-domain)
domain-literal = "[" *(dtext / quoted-pair) "]"
domain-ref = atom ; symbolic reference
dtext = <any CHAR excluding "[", ; => may be folded
"]", "\" & CR, & including
linear-white-space>
extension-field =
<Any field which is defined in a document
published as a formal extension to this
specification; none will have names beginning
with the string "X-">Okay so this next chunk is where the grammar gets really into its groove 💅 The fields, the field bodies, and the whole message rule live here, and message is the one that says everything after the first null line is the body 🫶
field = field-name ":" [ field-body ] CRLF
fields = dates ; Creation time,
source ; author id & one
1*destination ; address required
*optional-field ; others optional
field-body = field-body-contents
[CRLF LWSP-char field-body]
field-body-contents =
<the ASCII characters making up the field-body, as
defined in the following sections, and consisting
of combinations of atom, quoted-string, and
specials tokens, or else consisting of texts>
field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
group = phrase ":" [#mailbox] ";"
hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT]
; 00:00:00 - 23:59:59
HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)
LF = <ASCII LF, linefeed> ; ( 12, 10.)
linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE
; CRLF => folding
local-part = word *("." word) ; uninterpreted
; case-preserved
LWSP-char = SPACE / HTAB ; semantics = SPACE
mailbox = addr-spec ; simple address
/ phrase route-addr ; name & addr-spec
message = fields *( CRLF *text ) ; Everything after
; first null line
; is message body
month = "Jan" / "Feb" / "Mar" / "Apr"
/ "May" / "Jun" / "Jul" / "Aug"
/ "Sep" / "Oct" / "Nov" / "Dec"
msg-id = "<" addr-spec ">" ; Unique message id
optional-field =
/ "Message-ID" ":" msg-id
/ "Resent-Message-ID" ":" msg-id
/ "In-Reply-To" ":" *(phrase / msg-id)
/ "References" ":" *(phrase / msg-id)
/ "Keywords" ":" #phrase
/ "Subject" ":" *text
/ "Comments" ":" *text
/ "Encrypted" ":" 1#2word
/ extension-field ; To be defined
/ user-defined-field ; May be pre-empted
orig-date = "Date" ":" date-time
originator = authentic ; authenticated addr
[ "Reply-To" ":" 1#address] )
phrase = 1*word ; Sequence of wordsQuick heads-up, bestie: the optional-field rule starts with a line that has no name in front of it. That's how the original is written, so I've kept it exactly as is 🙈
And the last stretch, the quoted strings, the trace and Received stuff, the resent rules, the route-addr business, and the zone list at the very end 🌈
qtext = <any CHAR excepting <">, ; => may be folded
"\" & CR, and including
linear-white-space>
quoted-pair = "\" CHAR ; may quote any char
quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
; quoted chars.
received = "Received" ":" ; one per relay
["from" domain] ; sending host
["by" domain] ; receiving host
["via" atom] ; physical path
*("with" atom) ; link/mail protocol
["id" msg-id] ; receiver msg id
["for" addr-spec] ; initial form
";" date-time ; time received
resent = resent-authentic
[ "Resent-Reply-To" ":" 1#address] )
resent-authentic =
= "Resent-From" ":" mailbox
/ ( "Resent-Sender" ":" mailbox
"Resent-From" ":" 1#mailbox )
resent-date = "Resent-Date" ":" date-time
return = "Return-path" ":" route-addr ; return address
route = 1#("@" domain) ":" ; path-relative
route-addr = "<" [route] addr-spec ">"
source = [ trace ] ; net traversals
originator ; original mail
[ resent ] ; forwarded
SPACE = <ASCII SP, space> ; ( 40, 32.)
specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted-
/ "," / ";" / ":" / "\" / <"> ; string, to use
/ "." / "[" / "]" ; within a word.
sub-domain = domain-ref / domain-literal
text = <any CHAR, including bare ; => atoms, specials,
CR & bare LF, but NOT ; comments and
including CRLF> ; quoted-strings are
; NOT recognized.
time = hour zone ; ANSI and Military
trace = return ; path to sender
1*received ; receipt tags
user-defined-field =
<Any field which has not been defined
in this specification or published as an
extension to this specification; names for
such fields must be unique and may be
pre-empted by published extensions>
word = atom / quoted-string
zone = "UT" / "GMT" ; Universal Time
; North American : UT
/ "EST" / "EDT" ; Eastern: - 5/ - 4
/ "CST" / "CDT" ; Central: - 6/ - 5
/ "MST" / "MDT" ; Mountain: - 7/ - 6
/ "PST" / "PDT" ; Pacific: - 8/ - 7
/ 1ALPHA ; Military: Z = UT;
<"> = <ASCII quote mark> ; ( 42, 34.)That's the whole grammar, bestie 🦋 Every rule, every comment, every weird little spacing choice, exactly as written. ✨
📦 where this page comes from
- ietf: rfc822 1982-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms