RFC 724
Proposed official standard for the format of ARPA Network messages
RFC 724: Proposed Official Standard for the Format of ARPA Network Messages 💌🦋
okay so let's start with the title block bc it tells you everything 💅
- RFC number: 724 (NIC #37435)
- Date: 12 May 1977
- Category: Proposed Official Standard
- Title: Proposed Official Standard for the Format of ARPA Network Messages
- Authors:
- Ken Pogran, MIT-LCS/CSR (Pogran at MIT-Multics)
- John Vittal, BBN (Vittal at BBN-TENEXA)
- Dave Crocker, RAND-ISD (DCrocker at Rand-Unix)
- Austin Henderson, BBN (Henderson at BBN-TENEXD)
- Obsoletes and updates: the title block doesn't list these, but the Preface says this is a revision of RFC 561 and RFC 680 🫶
Preface 🎀
okay so ARPA's Committee on Computer-Aided Human Communication (CAHCOM) wants to make an official standard for the format of ARPA Network mail headers 📬 It has to meet the needs of all the different message service subsystems on the Network today. The authors of this RFC are the CAHCOM subcommittee in charge of building this new standard, and this document is basically our current thinking plus one specific proposal ✨
the document is organized like this: first there's a history of how the ARPA Network "mail" or "message" service came to be, plus the issues we think are the most urgent. These are problems with no solutions yet, and they're holding back new message subsystems 😭 Then comes the specification for the new ARPA Network Message Header standard. After that is a References section.
so basically we're proposing a revision of Request for Comments (RFC) 561, "Standardizing Network Mail Headers", and RFC 680, "Message Transmission Protocol". The revision removes and compacts parts of the old syntax and adds several features to network address specification 🔥 The big vibe shift is that we focus on people, not mailboxes, as recipients, and we allow reference to stored address lists. We expect this syntax to cover most users' immediate needs, which gives developers enough breathing room to build a new mail transmission protocol "properly" 🧚 We also think the Network community already agrees enough in favor of a standard syntax that adopting it now is doable 🌈
now the status of this proposed standard (very important, bestie 👑): the CAHCOM Steering Committee has replaced the Message Service Committee as the ARPANET standards-setting organization for message services. The plan is that this subcommittee's proposal, once it's in final form, gets adopted as an ARPANET standard by CAHCOM. We're sending it out as an RFC so we can make the standard the best it can possibly be 💖
please send any comments and criticisms to any of the authors of this RFC by 15 June 1977. The plan is to officially adopt the standard by 1 September 1977, with hosts expected to accept its syntax by 1 January 1978 📅✨
Contents 🌸
- I. Problems with ARPANET Message Standards
- A. Background and History
- B. Issues and Conclusions
- C. Message Parts
- D. Adoption of the Standard
- II. Standard for the Format of ARPA Network Messages
- A. Framework
- B. Syntax
- C. Semantics
- D. Examples
- III. References
- Appendix A. Alphabetical Listing of Syntax Rules
I. Problems with ARPANET Message Standards 🦋
A. Background and History 📜
okay so today's ARPA Network "mail" or "message" service uses two special commands from the File Transfer Protocol for delivery 🚚 From inside FTP's point of view, the whole message, header and text, is just data for the FTP MAIL and MLFL commands. This facility got bolted onto File Transfer Protocol as an afterthought 💀 It was supposed to be an interim solution, only used until a separate mail transmission protocol got specified. Several versions of that protocol have been proposed, but none has gotten general acceptance yet. Meanwhile, people have been trying to improve on the original interim facility.
as message service subsystems on various host systems (TENEX especially) got advanced enough to do basic parsing of incoming messages, it became clear that standardizing the format and content of message headers passed between hosts over these FTP commands would be super useful 🙌 So an ad hoc committee wrote RFC 561, which suggested a standard message header format. That committee was unofficial, so it couldn't legislate a standard; it could only recommend one. Still, the standard it suggested met a pressing need and got generally adopted 💅
here are some key points to note:
- RFC 561 defined the concept of a message header, and specified the syntax that separates it from the actual text of a message.
- It proposed a standard format for the most obvious and most urgently needed header items: "From:", "Date:", and "Subject:".
- It proposed that a general standard syntax be used for all other header items.
- RFC 561 is still, today, an unofficial standard, followed by most people because it's useful 🫶
- Its syntax was designed so humans could read the text easily, without any special message processing systems 🍓
as message services got more sophisticated, the need for specific header items in RFC 561's "miscellaneous" category grew 📈 "To:" and "cc:" especially were generated and recognized by several different message services. But there was no specific standard for the syntax of what goes inside those items 🙈 The message service subsystems on TENEX came up with a particular format for them. Since more messages on the Network came from TENEX hosts than from any other type of host, the TENEX format quietly became a de facto standard 👑 TENEX message service subsystems started parsing these fields and expected them to be in the TENEX-generated format. Message service subsystems on other hosts, Multics for example, started experimenting with other formats for these fields, since there was no standard to follow. Then users of the TENEX message service subsystems started complaining that their "non-standard" headers couldn't be parsed under the (de facto) "standard" syntax 😭
once it was clear the time had come to standardize the extra header fields that had been popping up since RFC 561 came out, ARPA's Message Service Committee chartered a small group in 1975 to write a revised version of RFC 561 that would define the syntax of these additional header fields ✨ A few things are worth knowing about this group. First, they were TENEX-oriented. When a header item they wanted already existed in a TENEX message subsystem, they adopted that syntax. Second, for header items that weren't already on TENEX message subsystems, they based their choices on the deliberations of the Message Service Committee. Third, they weren't familiar with the procedure for publishing a document as a Network RFC 🤷♀️
the document this group produced, labelled RFC 680, "Message Transmission Protocol", only got limited distribution 💔 Things got more confusing because its title was misleading. It wasn't a protocol for transmitting messages between ARPA Network hosts. It was really a standard for the format of messages sent via the standard File Transfer Protocol. Some people, including the Message Service Committee, believed RFC 680 had become a Network Standard. That wasn't strictly true, because it never got proper distribution, and nobody had ever "officially blessed" it to turn it from a request for comments into an accepted official ARPA Network standard document 🙃 The mix-up over its status is still visible today: the document does currently reside in the "official" ARPANET Protocol Handbook, and most users and message system implementors remain unaware of that 🤯
for all its shortcomings, RFC 680 did a needed job, just like RFC 561 did before it 🫶 It defined additional message header items at a time when that needed to happen. Unfortunately, because the group hadn't sought ideas and input from anyone else, the specification didn't adequately respond to a big enough set of community needs. The way the document was promulgated (or not promulgated) also left a lot to be desired 😬 Implementators of message-processing subsystems who hadn't received RFC 680 went their own ways, feeling justified in doing so. Meanwhile, people who accepted RFC 680 as a standard felt justified complaining to, and about, the maverick implementors they considered responsible for idiosyncratic message service subsystems 💀
also, users hadn't really tried to push the system to the limits of their imagination until recently, probably because the interim mail facility was so ad hoc 🚀 Lately, though, several sites are using the "interim" mail facility for more than it was designed for, in ways that clash with each other and with the original intent of the facility 😵💫 Mail subsystem implementors are increasingly being asked to handle mail from idiosyncratic hosts. And it's become clear that there are a few very specific features, too useful to ignore, that can't reasonably be specified within the syntax of RFC 680 🌈
B. Issues and Conclusions ⭐
At first glance, it would seem that today's kinda chaotic situation could best be fixed by immediately junking the existing "interim" mail facility and adopting a true mail transmission protocol. 🗑️ We strongly believe that would be ill-advised right now, because there's no general understanding in the Network community today of how to specify and implement a full and adequate mail transmission protocol. 🤔 However, we are convinced that there is, finally, a strong commitment within the Network community to tackle this problem 💪 (which there wasn't back when the "interim" mail transmission facility was specified and developed).
The frontal attacks on the mail protocol problem have, so far, produced at least two suggestions for a mail transmission protocol. ✨ Why shouldn't one of these protocols be adopted immediately? Because we feel that, in general, experimental Network software has a tendency to get prematurely treated as though it were adequately designed and fully operational. 🙈 Typically, the proposed system or protocol is so much better than what was available before that its experimental nature gets ignored, and it gets pressed into service before it has had a chance to properly develop and mature. We are very concerned that this doesn't happen to the Network mail system any more than it already has. 😭
While it is true that several sites in the ARPA Community have mail systems that understand the syntax specified in RFC's 561 and 680, plus some of the "non-standard" syntax produced by the mail generating programs at several other sites, most mail systems don't parse much of the contents of received messages. 📬 The whole point of the syntax specified here is that messages sent to people should be easily read by people. 🫶 Parsers that can turn an ugly, syntactically expedient form into something easy to read are the exception, rather than the rule, in today's message systems. Also, changes to the existing "non-standard" syntax should be kept to a minimum, which makes it more likely that the requirement of small perturbations to existing software will be accepted. 💅
With this syntax, we introduce mechanisms so that:
- Users of mail systems can have multiple mailboxes, either on one machine or multiple machines, all of which are treated identically; the default mailbox for a user is not necessarily associated (directly) with his login name. 📫
- Mail for a person can be sent to other than a single, default mailbox. 🦋
- Named groups may consist of both individuals and (possibly) other named groups (i.e., nesting within groups is permitted). 🧚
- Address lists may contain references to other, stored, lists. The complete path with which one can retrieve the stored list may be specified in order to allow either manual or automatic retrieval of the stored list. 🗂️
- Address lists may contain references to addresses which are not accessible through the standard ARPANET message system. For example, U.S. Postal system addresses can be specified. Such addresses are, of course, expected to be ignored by the ARPANET system, although individual sites may provide services for using the information (e.g., automatically sending a copy of the message to a line printer, in preparation for transmission through the Postal system). 📮
- Parenthetical remarks, or comments, can be included and syntactically recognized as such within some header items. 🎀
- Received messages are capable of being read by humans without a program having to parse the message (or parts of it) before presenting the message to the user; however, there is sufficient formal syntax to enable a parsing program to modify the appearance and content of material presented to users. Although message-display software may exercise considerable control over message appearance, the degree to which a message's actual format is PLEASANT for humans to read is entirely the responsibility of the message creation program. 🌸
No mechanism for authentication is provided, since the Network provides no mechanisms for enforcing mail security. 🔐 The syntax does provide for one aspect of "correctness": a distinction is made between an address which is claimed to be a valid network address and one which is simply free text, included for the convenience of the human participants. 🍓
C. MESSAGE PARTS 💌
Some confusion has existed over the roles played by different message parts. 🤷♀️ Einar Stefferud has suggested using the perspective of envelope, letter head, and letter content. The presence of structured portions in messages additionally requires reference to "headers".
In computer-based message systems, human users don't generally encounter "envelopes". 🙅♀️ These are often constructed automatically, to be used by the participating system(s) to deliver the message. For example, on TENEX, the envelope is the name of the file containing a message awaiting transmission. For FTP servers, it is the data portion of the MAIL or MLFL command line. Some systems attach "envelope-like" information to the message header, such as time-stamp and originating host name. ⏰
In paper-based communications, headers occur both before (e.g., To: and From: and after (e.g., cc: and enclosure:) the body of the message. 📝 Within this standard, all headers occur before the body of the message, although local message display programs may choose to alter that ordering. 🔄
Wayne Hathaway has pointed out that ARPANET message format does not support specification of letterheads, since these are a type of organizational public relations symbol. 💼 Some idiosyncrasies are supported, however, by way of choosing special field names. 🧁
In general, it is important to realize that the header portion of a message plays several roles during the life of a message, variously participating in each of the three functions suggested by Stefferud. 💜
D. ADOPTION OF THE STANDARD 🌈
During the early phases of specifying this standard, a great deal of concern was expressed over the problems that may be experienced during the transition from the current standard to this new one. 😬 We feel that the true problem is the lack of realization that THERE IS NO CURRENT OFFICIAL STANDARD. 💀 Enough systems have enough overlapping behaviors to allow the current mail environment to function, but this in no way constitutes a standard.
In fact, we strongly believe that the new requirements imposed by the proposed standard involve less complexity than the ambiguities resulting from the current variations in system behaviors. 🧠✨
II. STANDARD FOR THE FORMAT OF ARPA NETWORK MESSAGES 🎀
This standard supersedes the informal standards specified in ARPANET Request for Comments numbers 561, "Standardizing Network Mail Headers", and 680, "Message Transmission Protocol". 📜 In this document, a general framework is described. The formal syntax is then specified, followed by a discussion of the semantics. Finally, a number of examples are given. 🦋
This specification is intended strictly as a definition of what is to be passed between hosts on the ARPANET. It is NOT intended to dictate either features which systems on the Network are expected to support, or user interfaces to message creating or reading programs. 🙅♀️
A distinction should be made between what the specification requires and what it allows. Certain equivalences are defined, such as between a space character <space> and an end-of-line character <crlf>, which both facilitate the formal specification and indicate what the OFFICIAL semantics are for messages. Particular implementations may wish to preserve further distinctions which the specification does not require. 🌸
A. FRAMEWORK 🖼️
Since there are many message systems that exist outside the ARPANET environment, as well as those within it, it may be useful to consider the general framework, and resulting capabilities and limitations, of this standard. 🌍
Messages are expected to consist of lines of text. No special provisions are made, at this time, for encoding drawings, facsimile, speech, or structured text. 🚫🎨
No significant consideration has been given to questions of data compression or transmission/storage efficiency. The standard, in fact, tends to be very free with the number of bits consumed. For example, field names are specified as free text, rather than special terse codes. 🫠
A general "memo" framework is used. That is, a message consists of some information, in a rigid format, followed by the main part of the message, which is text and whose format is not specified in this document. The syntax of several fields of the rigidly-formatted ("header") section is defined in this specification; some of the header fields must be included in all messages. 📋 In addition to the fields specified in this document, it is expected that other fields will gain common use. User-defined header fields allow systems to extend their functionality while maintaining a uniform framework. Our approach is similar to that of the TELNET protocol, in that we are defining a basic standard which includes a mechanism for (optionally) extending itself. The authors of this document will regulate the publishing of specifications for these extensions. 🔧
Such a framework severely constrains document "tone" and appearance, and is primarily useful for most intra-organization communications and relatively structured inter-organization communication. 🎀 A more robust environment might allow for multi-font, multi-color, multi-dimension encoding of information. A less robust environment, as is present in most single-machine message systems, would more severely constrain the ability to add fields and the decision to include specific fields. Relative to paper-based communication, it is interesting to note that the RECEIVER of a message can exercise an extraordinary amount of control over the message's appearance. The amount of actual control available to message receivers is contingent upon the capabilities of their individual message systems. 👑
B. SYNTAX 🧩
This syntax is given in four parts. 🎀 The first part is a base-level lexical analyzer that feeds the higher-level parser in the sections after it. The second part gives the general syntax for messages and standard header fields. The third part specifies the syntax of addresses. The final section covers some general syntax that supports the other sections. 🧚
1. LEXICAL ANALYSIS OF MESSAGES ✨
a. General Description
okay so a message is made of headers and, optionally, a body (aka the <message-text>) 💌 The <message-text> is just a run of ASCII characters, and it's separated from the headers by a null line (basically a line with nothing before the <crlf>) 🌸
1) Folding and unfolding of headers
each header item can be pictured as one single, logical, super long line of ASCII characters 🦋 For convenience, you can split that into several lines (this is called "folded"). The general rule is that wherever <linear-white-space> characters are allowed, you can put a <crlf> right before AT LEAST one <linear-white-space> character instead. So this one line:
To: "Joe Dokes & J. Harvey" <ddd at Host>, JJV at BBNcan be written like this 💅
To: "Joe Dokes & J. Harvey" <ddd at Host>,
JJV at BBNand like this 😭
To: "Joe Dokes & J. Harvey"
<ddd at Host>,
JJV at BBNand like this too 🙈
To: "Joe Dokes
& J. Harvey" <ddd at Host>, JJV at BBNGoing from this folded multi-line version back to the single line is called "unfolding" ✨ Unfolding works by treating a <crlf> that's immediately followed by a <linear-white-space-char> as if it's just that <linear-white-space-char> 🫶
2) Structure of header fields
once the header fields are unfolded, they're made of a <field-name>, then a ":" (colon), then a <field-body> 💖 The <field-name> must be made of printable ASCII characters (aka characters with decimal values between 33 and 126) and <linear-white-space> characters. The <field-body> may composed of any ASCII characters (other than <cr> and <lf>, which get removed by unfolding) 🍓
Some header fields can be read using an internal syntax that some systems might want to parse. These are called structured fields 👑 Dates and addresses are good examples. Other fields, like the subject field, are just treated as one single line of text 💜
3) Field names
so to make <field-name>s easier to write and read, free insertion of <linear-white-space> characters is allowed in reasonable places 🎀 Instead of cluttering the syntax for <field-name> with explicit rules for those <linear-white-space> characters, we just assume there's a simple "lexical" analyzer around. It reads the unfolded text that makes up the <field-name> as a sequence of <atoms> separated by <linear-white-space> characters. The field name can then be represented as that sequence of atoms, separated by a single ASCII space character ✨
4) Field bodies
same energy here 🌈 For structured fields, free insertion of <linear-white-space> characters is allowed in reasonable places, and we don't clutter the syntax with it. We assume another simple "lexical" analyzer. It turns the unfolded body of the field into a sequence of lexical symbols 🦋 These include:
- individual special characters
- quoted strings
- comments
- atoms
The first three symbols are self-delimiting. Atoms aren't, so they get delimited by the self-delimiting symbols and by <linear-white-space> 💅
So, for example, the folded body of an address field:
":sysmail"@ Some-Host,
Muhammed(I am the greatest)Ali at WBAgets analyzed into these lexical symbols and types 🫶
":sysmail" quoted string
@ special
Some-Host atom
, special
Muhammed atom
(I am the greatest) comment
Ali atom
at atom
WBA atomb. Formal Definition
the grammar, bestie 📜 it's a lot, but it's giving clarity ✨
<field> ::= <field-name> ":" <field-body>
<field-name> ::= <atom>
| <atom> <field-name>
<field-body> ::= <field-body-contents>
| <field-body-contents> <crlf>
<linear-white-space-char>
<field-body>
<field-body-contents> ::= <the TELNET ASCII characters making
up the <field-body>, as defined in
the following sections, and
consisting of combinations of
<atom>, <quoted-string>, <text-line>,
and <specials> tokens>
<atom> ::= <a sequence of one or more TELNET
ASCII alpha-numeric or graphics
characters, excluding all control
characters (those characters with
a decimal value less than 33 or
equal to 127) and <delimeters> >
<quoted-string> ::= <double quote mark ("), decimal 34>
<a sequence of one or more TELNET
ASCII characters, where two
adjacent quotes are treated as a
single quote and part of the
string> <">
<text-line> ::= <a sequence of one or more TELNET
ASCII characters excluding <cr>
and <lf> >
<message-text> ::= <a sequence of zero of more TELNET
ASCII characters>
<delimeters> ::= <specials> | <comment>
| <linear-white-space> | <crlf>
<specials> ::= "(" | ")" | "<" | ">"
| "@" | "," | ";" | ":" | <">
<comment> ::= "(" <TELNET ASCII characters, except
<crlf> > ")"
<linear-white-space>::= <linear-white-space-char>
| <linear-white-space-char>
<linear-white-space>
<linear-white-space-char>::= <space> | <horizontal-tab>
<space> ::= <TELNET ASCII space (decimal 32)>
<tab> ::= <TELNET ASCII tab (decimal 9)>
<cr> ::= <TELNET ASCII carriage return
(decimal 13)>
<lf> ::= <TELNET ASCII line feed (decimal 10)>
<crlf> ::= <TELNET ASCII carriage return/line
feed (decimal 13, followed by
decimal 10)>c. Clarifications
1) Comments
comments can only show up inside <field-body>s of structured fields 💭 A comment is any set of TELNET ASCII characters that isn't inside a quoted string and is wrapped in matching parentheses. Parentheses nest, so if a left paren shows up inside a comment, there has to be a matching right paren too 🎀
Comments are NOT passed to the FTP server as part of a MAIL or MLFL command, since they aren't part of the "formal" address 🙅♀️
2) "White space"
okay, important bit 🚨 In structured fields, MULTIPLE LINEAR WHITE SPACE TELNET ASCII CHARACTERS (namely <tab>s and <space>s) ARE TREATED AS SINGLE SPACES AND MAY FREELY SURROUND ANY SYMBOL. In all header fields, at least one <space> is REQUIRED only at the beginning of folded lines 🌸
Writers of mail-sending (aka header-generating) programs should know that there's no Network-wide definition of what a <tab> TELNET ASCII character does to how text looks on another Network host 🙈 So even though <tab>s are permitted in message headers, the use of them is discouraged 💅
Also, the contents of messages have to follow TELNET NVT conventions (e.g. a <cr> must be followed by either <lf>, making a <crlf>, or <null>, if the <cr> is supposed to stand alone) ⭐
3) Quoted strings
where they're allowed (aka in structured fields), quoted strings count as one single symbol (same as an <atom>, syntactically) ✨ But if quoted strings get "folded" over multiple lines, the folding syntax has to be followed (see items II.B.1.a.1, above, and II.B.1.c.6, below.) The official semantics don't run into <crlf>s inside quoted strings, though particular parsing programs may wish to note when they're there 🦋
4) Bracketing characters
there are two types of brackets, and they have to be well nested 🧚
- Parentheses are used to indicate comments.
- Angle brackets ("<" and ">") are used where there's a question of machine-usable code being present (e.g. delimiting mailboxes).
5) Case independence of certain specials <atom>s
all mail reading programs should assume that certain <atom>s can show up in any mix of upper and lower case 🌈 These are:
- <field-name>s,
- "File", in a <path>,
- "at", in an <at-indicator>,
- <host-name>s,
- <day-of-week>s,
- <string-month>s, and
- <time-zone>s
okay bestie, so for example, the field names "From", "FROM", "from", and even "FroM" should all be treated identically 💅 like, they're the same field, no cap ✨. ngl though, at the level of this spec, case IS relevant for other <word>s and <text-line>s 👀 so don't get it twisted. Also peep Section II.C.1.a.4, below 🦋
6) Folding long lines
okay this one is giving clean vibes 🫶 each header item (field of the message) may be represented on exactly one line made of the field name and its body, and that's the thing the parser actually sees 🧚. for readability though, it is recommended that the <field-body> part of long header items gets "folded" onto multiple lines of the actual header 📜✨
7) Backspace characters
the TELNET ASCII backspace (ASCII BS, decimal 8) may be included in <text-line> and <quoted-string> to effect overstriking 🖍️ however, any backspace use that overstrikes to the left of the beginning of the <text-line> or <quoted-string> is prohibited 🚫 no going backwards off the edge, bestie 💀
2. GENERAL SYNTAX OF MESSAGES:
okay this section is the big one 👑 NOTE: the syntax says the items in <required-headers> must be in a specific order and come before all other header items 📌 but header fields are NOT required to occur in any particular order, so chill 🧘♀️ required header items must be unique (occur exactly once) 💖 and this spec lets you have multiple occurrences of most optional fields 🌈 however, how those multiple occurrences get interpreted is not specified here 🤷♀️
<message> ::= <headers>
| <headers> <crlf> <message-text>
<headers> ::= <required-headers>
| <required-headers> <optional-headers>
<required-headers> ::= <date-field> <originator>
<originator> ::= <mach-from-field>
| <mach-from-list> <sender-field>
| <mach-from-field> <reply-to-field>
| <any-from-field> <sender-field>
<reply-to-field>
<date-field> ::= "Date" ":" <date-time>
<mach-from-field> ::= "From" ":" <mach-addr-item>
<mach-from-list> ::= "From" ":" <mach-addr-list>
<any-from-field> ::= "From" ":" <address-list>
<sender-field> ::= "Sender" ":" <host-phrase>
<reply-to-field> ::= "Reply-To" ":" <mach-addr-list>
<optional-headers>::= <optional-header-field>
| <optional-headers>
<optional-header-field>
<optional-header-field> ::= <addressee-field>
| <extension-field>
<addressee-field> ::= "To" ":" <address-list>
| "cc" ":" <address-list>
| "bcc" ":" <address-list>
| "Fcc" ":" <path-list>
<extension-field> ::= "In-Reply-To" ":" <reference-list>
| "Keywords" ":" <phrase-list>
| "Message-Id" ":" <mach-host-phrase>
| "References" ":" <reference-list>
| "Subject" ":" <text-line>
| "Comments" ":" <text-line>
| <user-defined-field>
<user-defined-field> ::= <A <field> which has a <field-name>
not defined in this specification>so the bodies of these fields should be thought of as one long string (or line) each 🧵 section II.B.1 (Lexical Analysis) explained how those long strings can be spread over more than one line in the actual transmitted message 🎀
3. SYNTAX OF GENERAL ADDRESSEE ITEMS
<mach-addr-list> ::= <mach-addr-item>
| <mach-addr-item> "," <address-list>
<address-list> ::= <null>
| <address-item>
| <address-item> "," <address-list>
<address-item> ::= <mach-addr-item>
| <group-name> ":" <address-list> ";"
| <any-name>
| <path>
<mach-addr-item> ::= <mailbox>
| <phrase> "<" <mailbox-list> ">"
<group-name> ::= <phrase>
<any-name> ::= <quoted-string>
<mailbox-list> ::= <mailbox>
| <mailbox> "," <mailbox-list>
<mailbox> ::= <host-phrase>
<path> ::= ":" "File" ":" <path-name>
<path-name> ::= <path-item>
| "<" <path-list> ">"
<path-list> ::= <path-item>
| <path-item> "," <path-list>
<path-item> ::= <host-phrase>4. SUPPORTING SYNTAX
<reference-list> ::= <null>
| <reference-item>
| <reference-item> "," <reference-list>
<reference-item> ::= <phrase>
| <mach-host-phrase>
<mach-host-phrase>::= "<" <host-phrase> ">"
<host-phrase> ::= <phrase> <host-indicator>
<host-indicator> ::= <at-indicator> <host-name>
<at-indicator> ::= "at" | "@"
<host-name> ::= <atom>
| <decimal host address>
<date-time> ::= <day> <date> <time>
<day> ::= <null>
| <day-of-week> ","
<day-of-week> ::= "Monday" | "Mon"
| "Tuesday" | "Tue"
| "Wednesday" | "Wed"
| "Thursday" | "Thu"
| "Friday" | "Fri"
| "Saturday" | "Sat"
| "Sunday" | "Sun"
<date> ::= <string-date>
| <slash-date>
<string-date> ::= <day-of-month> <string-month>
<4-digit-year>
<slash-date> ::= <numeric-month> "/" <date-of-month>
"/" <2-digit-year>
<numeric-month> ::= <one or two decimal digits>
<day-of-month> ::= <one or two decimal digits>
<string-month> ::= "January" | "Jan"
| "February" | "Feb"
| "March" | "Mar"
| "April" | "Apr"
| "May"
| "June" | "Jun"
| "July" | "Jul"
| "August" | "Aug"
| "September"| "Sep"
| "October" | "Oct"
| "November" | "Nov"
| "December" | "Dec"
<4-digit-year> ::= <four decimal digits>
<2-digit-year> ::= <two decimal digits>
<time> ::= <24-hour-time> "-" <time-zone>
<24-hour-time> ::= <hour> <minute>
<hour> ::= <two decimal digits>
<minute> ::= <two decimal digits>
<time-zone> ::= "GMT" | "Z" | "GDT"
| "AST" | "ADT"
| "EST" | "EDT" | "CST" | "CDT"
| "MST" | "MDT" | "PST" | "PDT"
| "YST" | "YDT" | "HST" | "HDT"
<phrase> ::= <word>
| <word> <phrase>
<phrase-list> ::= <null>
| <phrase>
| <phrase> "," <phrase-list>
<word> ::= <atom>
| <quoted-string>C. SEMANTICS
1. ADDRESS FIELDS
a. General
1) okay so <path>s are how you point at a spot on the ARPANET that holds a stored address list 📂 the <phrase> should contain text the referenced host can resolve to a file 🗂️ this standard isn't a protocol though, so it doesn't prescribe HOW the data gets retrieved from the file 🤷♀️ but there are two requirements:
- the file must be accessible through the local operating system interface (if it exists), given adequate user access rights; and
- if a host has an FTP server and a user is able to retrieve any files from the host using that server, then the file must be accessible through FTP, using DEFAULT transfer settings, given adequate user access rights.
it is intended that this mechanism lets programs retrieve such lists automatically 🤖✨
the interpretation of a <path> goes like this 💫 this is not meant to imply any particular implementation scheme, it's just here to help you understand the idea of <path>s 🧚
- the contents of the file indicated by a
<path-name>are treated as an<address-list>and get inserted as an<address-item>in the position of the<path-name>item in the syntax 🪄 so the TELNET ASCII character string of the<path-name>(or the<path-list>containing it, if present) gets replaced by the contents of the file it refers to. therefore, the contents of the file indicated by a<path-name>must be syntactically self-contained and must adhere to the full syntax prescribed herein for<address-list>📜 <path-item>s of a<path-list>are alternates, and the contents of ONLY ONE of them is to be included in the resultant address list 🫶
2) the <phrase> part of a <mailbox> is understood to be whatever the receiving FTP Server allows 💅 (for example, TENEX systems don't currently understand addresses like "P. D. Q. Bach", but another system might 😭)
note that a <mailbox> is a conceptual entity that doesn't necessarily have anything to do with file storage 📬 for example, some sites may choose to print mail on their line printer and deliver the output to the addressee's desk 🖨️🍓
a user may have several mailboxes 🦋 using the second alternative of <mach-addr-item> (<phrase> "<" <mailbox-list> ">") means a copy of the message is to be sent to EACH mailbox named 💌
3) <any-name> may contain any sequence of "words" 🌸 this sequence of words, used as an <address-item>, is there to help you reference non-standard (e.g. non-Network) addresses 🏡 like, an address that's acceptable to the U.S. Postal Service, for example 💖
- The
<host-name>in a<host-phrase>must be THE official name of a Network host 💅, or else a decimal number indicating the Network address for that host. The USE OF NUMBERS IS STRONGLY DISCOURAGED 🙈 and is permitted only due to the occasional necessity of bypassing local host-name tables.
The <phrase> in a <host-phrase> is intended to be meaningful only to the indicated host. To all other hosts, the <phrase> is treated as a literal string. No case transformations should be (automatically) performed on the <phrase>. The <phrase> is passed to the local host's mail sending program 📬. It is the responsibility of the destination host's mail receiving (distribution) program to perform case mapping on this <phrase>, if required, to deliver the mail 🧚.
b. Originator Fields ✨
WARNING: The standard allows only a subset of the combinations possible with the From, Sender, and Reply-to fields. The limitation is intentional; the permitted alternatives have been carefully chosen and are adequate for the purposes of this standard. 🚨
1) From:
This field contains the identity of the person(s) who wished this message to be sent. The message-creation process should default this field to be a single machine address, indicating the user entering the message; if and only if this is done, the "Sender:" field need not be present. 💖
2) Sender:
This field contains the identity of the person who sends the message. It need not be present in the header of the message if it is the SAME as the "From:" field. 🎀
The <sender-field-body> includes a <phrase> which must correspond to a user, rather than a standard <address-item>, to indicate the expectation that the field will refer to the PERSON responsible for sending the mail and not simply include the name of a mailbox, from which the mail was sent. For example in the case of a shared login name, the name, by itself, would not be adequate. The <phrase> (user) is a system entity, not a generalized person reference. 👑
3) Reply-to:
This field provides a general mechanism for indicating any mailbox(es) to which responses are to be sent. Three different uses for this feature can be distinguished. In the first case, the author(s) may not have regular machine-based mailboxes and therefore wish to indicate an alternate machine address. In the second case, an author may wish additional persons to be made aware of, or responsible for, responses; responders should send their replies to the "Reply-to:" mailbox(es). More interesting is a case such as text-message teleconferencing in which an automatic distribution facility is provided and a user submitting an "entry" for distribution only needs to send their message to the mailbox(es) indicated in the "Reply-to:" field. 🦋
If there is no <reply-to-field>, then the <from-field> MUST contain AT LEAST ONE machine address. In all cases when used and even if a <sender> field is present, the Reply-to field must contain at least one machine address. 🫶
NOTE: For systems which automatically generate address lists for replies to messages, the following requirements are made:
- The receiver, when replying to a message, must NEVER automatically include the
<sender-field-body>in the reply's address list 🙅♀️ - If the
<reply-to-field>exists, then the reply should go ONLY to the<reply-to-field-body>addressees.
(Extensive examples are provided in Section II.D.) This recommendation is intended only for <originator-field>s and in no way is intended to reflect that replies should not be sent, also, to the other recipients of this message. It is up to the respective mail handling programs as to what additional facilities will be provided. 🌸
c. Receiver Fields
1) To:
This field contains the identity of the primary recipients of the message. 💌
2) cc:
This field contains the identity of the secondary recipients of the message. 📨
3) Bcc:
This field contains the identity of additional recipients of the message who are to remain hidden from 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 include it in the text sent to all those indicated in the "Bcc:" list. 🕵️♀️
4) Fcc:
This field contains the identity of any message files in which copies of this message are being placed by the originator. Note that the presence of this field does NOT guarantee long-term availability of the message in any of the indicated files. 📁
2. Reference Specification Fields
2. REFERENCE SPECIFICATION FIELDS
a. Message-Id:
This field contains a unique identifier (the <phrase>) to refer to this version of this message. The uniqueness of the message identifier is guaranteed by each host. This identifier is intended to be machine readable, and not necessarily meaningful to humans. A message-id pertains to exactly one instantiation of a particular message; subsequent revisions to the message should receive new message-id's. 🔖
b. In-Reply-To:
The contents of this field identify previous correspondence which this message answers. If message identifiers are used in this field, they should be enclosed in angle brackets (<>). 💬
c. References:
The contents of this field identify other correspondence which this message references. If message identifiers are used, they should be enclosed in angle brackets (<>). 🧵
d. Keywords:
This field contains keywords or phrases, separated by commas. 🏷️
3. OTHER FIELDS AND SYNTACTIC ITEMS
a. Subject:
The "subject:" field is intended to provide as much information as necessary to adequately summarize or indicate the nature of the message. 🌈
b. Comments:
Permits adding text comments onto the message without disturbing the contents of the message's body. 💜
4. Dates
4. DATES
It is recommended that, because of differing international interpretations, the <string-day> option be used instead of the <slash-day> option in the specification of a <day>. 🗓️
If included, <day-of-week> must be the day implied by the <date> specification. ⭐
<Time-zones> allow reference to Greenwich and to each of the zones in the United States. The zone references beginning with "A" are for Atlantic time which are one hour faster than the corresponding Eastern times. "Y" indicates Yukon time in Alaska, which is one hour slower than the corresponding Pacific times, and "H" indicates Hawaiian times, which are two hours slower. 🌺
D. EXAMPLES 🎀
1. ADDRESSES
a. Alfred E. Newman <Newman at BBN-TENEXA> Newman@BBN-TENEXA
These two "Alfred E. Newman" examples have identical semantics, as far as the operation of the local host's mailer and the remote host's FTP server are concerned. In the first example, the "Alfred E. Newman" is ignored by the mailer, as "Newman at BBN-TENEXA" completely specifies the recipient. The second example contains no superfluous information, and, again, "Newman@BBN-TENEXA" is the intended recipient. 💁♀️
b. Al Newman at BBN-TENEXA
This is identical with "Al Newman<Al Newman at BBN-TENEXA>." That is, the full <phrase>, "Al Newman", is passed to the FTP server. Note that not all FTP servers accept multi-word identifiers; and some that do accept them will treat each word as a different addressee (in this case, attempting to send a copy of the message to "Al" and a copy to "Newman"). 😬
c. "George Lovell, Ted Hackle" <Shared-Mailbox at Office-1>
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, as "Shared-Mailbox at Office-1" completely specifies the destination mailbox. 👯♀️
d. Wilt (the Stilt) Chamberlain at NBA
The "(the Stilt)" is a comment, which is NOT included in the destination mailbox address handed to the originating system's mailer. The address is the string "Wilt Chamberlain", with exactly one space between the first and second words. (The quotation marks are not included.) 🏀
2. ADDRESS LISTS
Gourmets: Pompous Person <WhoZiWhatZit at Cordon-Bleu>,
Cooks: Childs at WGBH, Galloping Gourmet at
ANT (Australian National Television);
Wine Lovers: Drunk at Discount-Liquors,
Port at Portugal;;,
Jones at SEAThis group list example points out the use of comments, the nesting of groups, and the mixing of addresses and groups. Note that the two consecutive semi-colons preceding "Jones at SEA" mean that Jones is NOT a member of the Gourmets group. 🍷
3. ORIGINATOR ITEMS
a. George Jones logs into his Host as "Jones". He sends mail himself. 🙋♀️
From: Jones at Host
or
From: George Jones <Jones at Host>b. George Jones logs in as Jones on his Host. His secretary, who logs in as Secy on her Host (SHost) sends mail for him. Replies to the mail should go to George, of course. 💼
From: George Jones <Jones at Host>
Sender: Secy at SHostc. George Jones logs in as Group at Host. He sends mail himself; replies should go to the Group mailbox. 👥
From: George Jones <Group at Host>d. George Jones' secretary sends mail for George in his capacity as a member of Group while logged in as Secy at Host. Replies should go to Group. 🧁
From: George Jones<Group at Host>
Sender: Secy at HostNote that there need not be a space between "Jones" and the "<", but adding a space enhances readability (as is the case in other examples). ✨
e. George Jones asks his secretary (Secy at Host) to send a message for him in his capacity as Group. He wants his secretary to handle all replies. 🌷
From: George Jones <Group at Host>
Sender: Secy at Host
Reply-to: Secy at Hostf. Okay bestie, so George has a non-ARPANET friend, Sarah, who's visiting 🧚 His secretary is emailing a friend of Sarah's in computer-land, and replies are supposed to come back to George, whose mailbox is Jones at Host. Here's how the headers look:
From: Sarah Friendly
Sender: Secy at Host
Reply-to: Jones at Hostg. George is on a committee, and he wants any replies to his message to reach everybody on it 👑
From: George Jones
Sender: Jones at Host
Reply-To: Big-committee: Jones at Host,
Smith at Other-Host,
Doe at Somewhere-Else;Now the tea ☕ If George had left himself out of the Big-committee list, he would not get a reply. The "Reply-to:" field SUPERSEDES the reply going to whoever's named in "From:", so it's not just an add-on, it replaces it. Main character energy, but make sure you include yourself 🙈
h. (Example of INCORRECT USE) 🚫
George wants replies to go to his secretary, so she leaves his mailbox address out of "From:" and just puts his name there, which isn't a mailbox address at all 💀
From: George Jones
Sender: Secy at SHostTHIS IS NOT PERMITTED. Replies are NEVER implicitly sent to the "Sender:". George's secretary should have used the "Reply-to:" field, or the mail program she was using should have forced her to. Not a vibe ❌
i. George's secretary sends out a message that was written together by everyone in the "Big-committee" 🫶
From: Big-committee: Jones at Host,
Smith at Other-Host,
Doe at Somewhere-Else;
Sender: Secy at SHost4. COMPLETE HEADERS ✨
a. Minimum required: 🎀 This is the bare minimum, just a Date and a From.
Date: 26 August 1976 1429-EDT
From: Jones at Hostb. Using some of the additional fields: 🌸 Now we're adding more fields, and it's giving full inbox energy.
Date 26 August 1976 1430-EDT
From: George Jones<Group at Host>
Sender: Secy at SHOST
To: Al Newman at Mad-Host,
Sam Irving at Other-Host
Message-id: some string at SHOSTc. About as complex as you're going to get: 🔥 This one is the full chaos ending, and honestly it's iconic.
Date: 27 Aug 1976 0932-PDT
From: Ken Davis <KDavis at Other-Host>
Sender: KSecy at Other-Host
Reply-to: Sam Irving at Other-Host
Subject: Re: The Syntax in the RFC
To: George Jones <Group at Host>,
Al Newman at Mad-Host
cc: Tom Softwood <Balsa at Another-Host>,
Sam Irving at Other-Host,
Standard Distribution:
:File:
</main/davis/people/standard at Other Host,
"<Jones>standard.dist.3" at Tops-20-Host>
In-Reply-to: <some string at SHOST>
Message-ID: 4231.629.XYzi-What at Other-Host
Comment: Sam is away on business. He asked me to handle
his mail for him today. He'll be able to
provide a more accurate explanation tomorrow
when he returns.III. REFERENCES 📚
--- TELNET Protocol Specification. Network Information Center No. 18639; Augmentation Research Center, Stanford Research Institute: Menlo Park, August 1973.
Bhushan, A.K. The File Transfer Protocol. ARPANET Request for Comments, No. 354, Network Information Center No. 10596; Augmentation Research Center, Stanford Research Institute: Menlo Park, July 1972.
Bhushan, A.K. Comments on the File Transfer Protocol. ARPANET Request for Comments, No. 385, Network Information Center No. 11357; Augmentation Research Center, Stanford Research Institute: Menlo Park, August 1972.
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; Augmentation Research Center, Stanford Research Institute: Menlo Park, September 1973.
Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook. Network Information Center No. 7104; Augmentation Research Center, Stanford Research Institute: Menlo Park, April 1976. (NTIS AD A003890).
McKenzie, A. File Transfer Protocol. ARPANET Request for Comments, No. 454, Network Information Center No. 14333; Augmentation Research Center, Stanford Research Institute: Menlo Park, February 1973.
Myer, T.H. and Henderson, D.A. Message Transmission Protocol. ARPANET Request for Comments, No. 680, Network Information Center No. 32116; Augmentation Research Center, Stanford Research Institute: Menlo Park, 1975.
Neigus, N. File Transfer Protocol. ARPANET Request for Comments, No. 542, Network Information Center No. 17759; Augmentation Research Center, Stanford Research Institute: Menlo Park, July 1973.
Postel, J.B. Revised FTP Reply Codes. ARPANET Request for Comments, No. 640, Network Information Center No. 30843; Augmentation Research Center, Stanford Research Institute: Menlo Park, June 1974.
okay bestie, this is the grammar cheat sheet 🧚 every single rule, lined up A to Z so you can find your way around fast 💅
<2-digit-year> ::= <two decimal digits>
<4-digit-year> ::= <four decimal digits>
<24-hour-time> ::= <hour> <minute>
<addressee-field> ::= "To" ":" <address-list>
| "cc" ":" <address-list>
| "bcc" ":" <address-list>
| "Fcc" ":" <path-list>
<address-item> ::= <mach-addr-item>
| <group-name> ":" <address-list> ";"
| <any-name>
| <path>
<address-list> ::= <null> | <address-item>
| <address-item> "," <address-list>
<any-from-field> ::= "From" ":" <address-list>
<any-name> ::= <quoted-string>
<at-indicator> ::= "at" | "@"
<atom> ::= <a sequence of one or more TELNET ASCII
alpha-numeric or graphics characters,
excluding all control characters
(those characters with a decimal value
less than 33 or equal to 127) and
<delimeters> >
<comment> ::= "(" <TELNET ASCII characters, except
<crlf> > ")"
<cr> ::= <TELNET ASCII carriage return (decimal 13)>
<crlf> ::= <TELNET ASCII carriage return/line feed
(decimal 13, followed by decimal 10)>
<date> ::= <string-date> | <slash-date>
<date-field> ::= "Date" ":" <date-time>
<date-time> ::= <day> <date> <time>
<day> ::= <null> | <day-of-week> ","
<day-of-month> ::= <one or two decimal digits>
<day-of-week> ::= "Monday" | "Mon"
| "Tuesday" | "Tue"
| "Wednesday" | "Wed"
| "Thursday" | "Thu"
| "Friday" | "Fri"
| "Saturday" | "Sat"
| "Sunday" | "Sun"
<delimeter> ::= <specials> | <comment>
| <linear-white-space> | <crlf>
<field> ::= <field-name> ":" <field-body>
<field-body> ::= <field-body-contents>
| <field-body-contents> <crlf>
<linear-white-space-CHAR> <field-body>
<field-body-contents> ::= <the TELNET ASCII characters making up
the field body, as defined in the
following sections and consisting of
combinations of <atom>, <quoted-
string>, <text-line>, and <specials>
tokens>
<field-name> ::= <atom> | <atom> <field-name>
<group-name> ::= <phrase>
<headers> ::= <required-headers>
| <required-headers> <optional-headers>
<host-indicator> ::= <at-indicator> <host-name>
<host-name> ::= <atom> | <decimal host address>
<host-phrase> ::= <phrase> <host-indicator>
<hour> ::= <two decimal digits>
<lf> ::= <TELNET ASCII line feed (decimal 10)>
<linear-white-space>::= <linear-white-space-char>
| <linear-white-space-char>
<linear-white-space>
<linear-white-space-char>::= <space> | <horizontal-tab>
<mach-addr-item> ::= <mailbox> | <phrase> "<" <mailbox-list> ">"
<mach-addr-list> ::= <mach-addr-item>
| <mach-addr-item> "," <address-list>
<mach-from-field> ::= "From" ":" <mach-addr-item>
<mach-from-list> ::= "From" ":" <mach-addr-list>
<mach-host-phrase>::= "<" <host-phrase> ">"
<mailbox> ::= <host-phrase>
<mailbox-list> ::= <mailbox> | <mailbox> "," <mailbox-list>
<message> ::= <headers>
| <headers> <crlf> <message-text>
<message-text> ::= <a sequence of zero of more TELNET ASCII
characters>
<minute> ::= <two decimal digits>
<numeric-month> ::= <one or two decimal digits>
<optional-headers>::= <optional-header-field>
| <optional-headers> <optional-header-field>
<optional-header-field> ::= <addressee-field> | <extension-field>
<originator> ::= <mach-from-field>
| <mach-from-list> <sender-field>
| <mach-from-field> <reply-to-field>
| <any-from-field> <sender-field>
<reply-to-field>
<path> ::= ":" "File" ":" <path-name>
<path-item> ::= <host-phrase>
<path-list> ::= <path-item> | <path-item> "," <path-list>
<path-name> ::= <path-item> | "<" <path-list> ">"
<phrase> ::= <word> | <word> <phrase>
<phrase-list> ::= <null> | <phrase>
| <phrase> "," <phrase-list>
<reference-item> ::= <phrase> | <mach-host-phrase>
<reference-list> ::= <null> | <reference-item>
| <reference-item> "," <reference-list>
<quoted-string> ::= <double quote mark ("), decimal 34>
<a sequence of one or more TELNET
ASCII characters, where two adjacent
quotes are treated as a single quote
and part of the string> <">
<reply-to-field> ::= "Reply-To" ":" <mach-addr-list>
<required-headers> ::= <date-field> <originator>
<sender-field> ::= "Sender" ":" <host-phrase>
<slash-date> ::= <numeric-month> "/" <date-of-month>
"/" <2-digit-year>
<space> ::= <TELNET ASCII space (decimal 32)>
<specials> ::= "(" | ")" | "<" | ">"
| "@" | "," | ";" | ":" | <">
<string-date> ::= <day-of-month> <string-month>
<string-month> ::= "January" | "Jan" | "February" | "Feb"
| "March" | "Mar" | "April" | "Apr"
| "May" | "June" | "Jun"
| "July" | "Jul" | "August" | "Aug"
| "September"| "Sep" | "October" | "Oct"
| "November" | "Nov" | "December" | "Dec"
<tab> ::= <TELNET ASCII tab (decimal 9)>
<text-line> ::= <a sequence of one or more TELNET ASCII
characters excluding <cr> and <lf> >
<time> ::= <24-hour-time> "-" <time-zone>
<time-zone> ::= "GMT" | "Z" | "GDT" | "AST" | "ADT
| "EST" | "EDT" | "CST" | "CDT"
| "MST" | "MDT" | "PST" | "PDT"
| "YST" | "YDT" | "HST" | "HDT"
<user-defined-field> ::= <A <field> which has a <field-name> not
defined in this specification>
<word> ::= <atom> | <quoted-string>that's the whole grammar, bestie 🫶 every rule copied exactly, typos and all, because the rulebook is the rulebook 🙈
📦 where this page comes from
- ietf: rfc724 1977-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms