RFC 733
Standard for the format of ARPA network text messages
Okay bestie, the big one is here! 🎀✨ This is RFC 733, the Standard for the Format of ARPA Network Text Messages (NIC #41952). It's dated 21 November 1977, and it's the document that defines how the earliest ARPANET mail messages were supposed to look. 💌
It obsoletes three older RFCs: RFC 561 (NIC #18516), RFC 680 (NIC #32116), and RFC 724 (NIC #37435). So this is the new official version and the old ones are retired. 🦋
The authors are a whole squad 💜:
- David H. Crocker, The Rand Corporation
- John J. Vittal, Bolt Beranek and Newman Inc.
- Kenneth T. Pogran, Massachusets Institute of Technology
- D. Austin Henderson, Jr., Bolt Beranek and Newman Inc.
The footnotes are cute too. The first one is the funding note 💅: "This work was supported by the Defense Advanced Research Projects Agency of the Department of Defense, under contract Nos. N00014-75-C-0661, MDA903-76-C-0212, and DAHC15-73-C0181."
The second footnote lists the authors' postal addresses and their ARPANET addresses: "The authors' postal addresses are: D. Crocker, The Rand Corporation, Information Sciences Dept., 1700 Main St., Santa Monica, California 90406; J. Vittal & D. A. Henderson, Bolt Beranek & Newman, 50 Moulton St., Cambridge, Massachusetts 02138; and K. Pogran, MIT Laboratory for Computer Science, 545 Technology Square, Cambridge, Massachusetts 02139. The authors' ARPANET addresses are: DCrocker at Rand-Unix, Vittal at BBN-TenexD, Pogran at MIT-Multics, and Henderson at BBN-TenexD." 📬
PREFACE 🎀
ARPA's Committee on Computer-Aided Human Communication (CAHCOM) wanted to put out a standard for the format of ARPA Network text message (mail) headers that could reasonably handle what the different message subsystems on the Network need today. The authors of this document are the CAHCOM subcommittee that got the job of writing it. 💖
Basically, this is a revision of RFC 561, "Standardizing Network Mail Headers", and RFC 680, "Message Transmission Protocol". The revision cuts and tightens some of the older syntax and adds some new stuff for network addresses. The big focus is on people rather than mailboxes as recipients, and it lets you reference stored address lists. 🧚
The hope is that this syntax covers most users' immediate needs, which gives developers breathing room to build a new mail transmission protocol "properly". The authors believe the Network community already agrees enough on a standard syntax to make adopting it possible right now. An earlier draft was published as RFC #724, "Proposed Official Standard for the Format of ARPA Network Messages", and that draft has lots of background and issues in ARPANET mail standards if you want the tea. ☕
This spec was developed over one year, and the team used the ARPANET mail environment itself as an ongoing forum to talk through what should go in. More than twenty individuals from across the country joined that discussion, and the authors want to thank them for all their work. 🫶 The syntax was first written in Backus-Naur Form (BNF). Ken L. Harrenstien, of SRI International, re-coded the BNF into an augmented BNF, which makes the spec more compact and easier to understand. 🔥
CONTENTS 📋
PREFACE..................................................... iii
Section
I. INTRODUCTION......................................... 1
II. FRAMEWORK............................................ 2
III. SYNTAX............................................... 4
A. Notational Conventions............................ 4
B. Lexical Analysis of Messages...................... 5
C. General Syntax of Messages........................ 13
D. Syntax of General Addressee Items................. 15
E. Supporting Constructs............................. 15
IV. SEMANTICS............................................ 17
A. Address Fields.................................... 17
B. Reference Specification Fields.................... 22
C. Other Fields and Syntactic Items.................. 23
D. Dates and Times................................... 24
V. EXAMPLES............................................. 25
A. Addresses......................................... 25
B. Address Lists..................................... 26
C. Originator Items.................................. 26
D. Complete Headers.................................. 28
Appendix
A. ALPHABETICAL LISTING OF SYNTAX RULES................. 31
B. SIMPLE PARSING....................................... 35
BIBLIOGRAPHY................................................ 37I. INTRODUCTION ✨
This standard specifies a syntax for text messages that get passed between computer users inside the framework of "electronic mail". 💌 It supersedes the informal standards from ARPANET Request for Comments numbers 561, "Standardizing Network Mail Headers", and 680, "Message Transmission Protocol". The doc goes like this: first a general framework, then the formal syntax, then a discussion of the semantics, and finally a bunch of examples. 🦋
This specification is meant strictly as a definition of what gets passed between hosts on the ARPANET. It is NOT meant to dictate either the features systems on the Network are expected to support, or the user interfaces of programs that create or read messages. Not its business, bestie! 💅
Here's a key distinction: what the specification REQUIRES versus what it ALLOWS. Messages can be super complex and rich, with formally structured pieces of information, or they can be kept small and simple with very little of that stuff. The standard also simplifies how different visual formats in messages get interpreted. These simplifications make the formal spec easier to write and show what the OFFICIAL semantics are for messages. Only the visual side of a message is affected. The interpretation of the information inside it is not. Implementors can choose to keep those visual distinctions if they want. 🌈
II. FRAMEWORK 🧚
Lots of message systems exist outside the ARPANET as well as inside it, so it's useful to look at the general framework this standard gives you, along with the capabilities and limitations that come with it. 🍓
Messages are expected to be made of lines of text. Nothing special is set up, for now, for encoding drawings, facsimile, speech, or structured text. 🙈
Data compression and transmission or storage efficiency were not really considered here. The standard is actually pretty loose about how many bits it eats. For example, field names are free text instead of special terse codes. It's giving "no thoughts, just vibes" energy, lowkey. 💀
The framework is a general "memo" design. A message has some information in a rigid format, then the main part of the message, which is text whose format this document does not specify. The syntax for several fields in that rigidly formatted ("header") section is defined here, and some header fields must be included in every message. The syntax that tells headers apart is specified separately from the internal syntax of each particular header. That split is intentional, so super simple parsers can work on the overall structure of messages without caring about the details of individual headers. Appendix B exists to help build those simple parsers. 👑
Beyond the fields in this document, other fields are expected to become common too. User-defined header fields let systems extend their functionality while keeping a uniform framework. The approach is similar to the TELNET protocol, which defines a basic standard that includes a mechanism for (optionally) extending itself. When needed, the authors of this document will regulate how specifications for these "extension-fields" get published, using the same mechanisms used to publish this document. 🔥
The framework is very constraining when it comes to document tone and appearance. It's mainly useful for communication within an organization and fairly structured communication between organizations. A more robust environment might allow multi-font, multi-color, multi-dimensional encoding of information. A less robust environment, like most single-machine message systems, would constrain more heavily the ability to add fields and the decision about which specific fields to include. Unlike paper communication, the RECEIVER of a message can exercise a surprising amount of control over how the message looks. How much control receivers actually have depends on what their individual message systems can do. 📬
III. SYNTAX 💜
The syntax is given in five parts. Part one describes the notation used in the specification. Part two describes the base-level lexical analyzers that feed the higher-level parser covered in the later sections. Part three gives the general syntax for messages and standard header fields. Part four specifies the syntax of addresses. A final part specifies some general syntax that supports the other sections. 🌸
A. Notational Conventions 🎀
These specifications are written in an augmented Backus-Naur Form (BNF). The differences from standard BNF are about how rules get named, how repetition is marked, and how "local" alternatives work. 🦋
1. Rule naming
Angle brackets ("<", ">") are generally not used. A rule's name is just the name itself, not "<name>". Quotation marks enclose literal text, which may be uppercase and/or lowercase. Certain basic rules are in uppercase, like SPACE, TAB, CRLF, DIGIT, ALPHA, and so on. Angle brackets do show up in rule definitions, and in the rest of this document, whenever they make it easier to spot the rule names. ✨
2. Parentheses: Local alternatives
Elements wrapped in parentheses are treated as a single element. So (elem (foo / bar) elem) allows (elem foo elem) and (elem bar elem). 🧚
3. * construct: Repetition
The character * in front of an element means repetition. The full form is:
<l>*<m>elementIt means at least <l> and at most <m> occurrences of element. The defaults are 0 and infinity, so *(element) allows any number, including zero. 1*element requires at least one. 1*2element allows one or two. 💅
4. <number>element
<n>(element) is equivalent to <n>*<n>(element), which means exactly <n> occurrences of (element). So 2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic characters. 🔢
5. # construct: Lists
There's a construct # that's defined a lot like *, like this:
<l>#<m>elementIt means at least <l> and at most <m> elements, each one separated by one or more commas (","). This makes the usual list form super easy. A rule like (element *("," element)) can be written as 1#element. Wherever this construct is used, null elements
5. construct: Lists 💕
are allowed, but do not contribute to the count of elements present. 🙈 So "(element),,(element)" is totally permitted, but it only counts as two elements. Which means where at least one element is required, at least one non-null element must be present. Empty spots are fine, but they don't count toward the total, bestie. 💅
6. [optional] 🌸
Square brackets wrap optional elements, so [foo bar] is the same as *1(foo bar). ✨ Simple, clean, and very on brand. 🎀
7. ; Comments 💬
A semi-colon, set off some distance to the right of rule text, starts a comment that runs to the end of the line. 🦋 It's the easiest way to drop useful notes right next to the specs without them getting in the way. Iconic. 😭
B. LEXICAL ANALYSIS OF MESSAGES 🎀
1. General Description 🌸
A message is made of headers and, optionally, a body (basically a series of text lines). 💌 The text part is just a sequence of lines made of ASCII characters, and it gets separated from the headers by a null line (a line with nothing before the CRLF). ✨
a. Folding and unfolding of headers 🦋
Each header item can be thought of as one single, logical line of ASCII characters. 💖 For convenience, the field-body part of that logical line can be split across multiple lines, which is called "folded." The general rule is that wherever there can be linear-white-space (NOT simply LWSP-chars), a CRLF immediately followed by AT LEAST one LWSP-char can be inserted instead. 🫶 (However, a header's name and the colon (":") after it, which sit at the very start of the header item, may NOT be folded onto multiple lines. 🙅♀️) So this single 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 BBNor like this:
To: "Joe Dokes & J. Harvey"
<ddd at Host>,
JJV at BBNor even like this:
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 happens by treating a CRLF immediately followed by a LWSP-char as equivalent to just the LWSP-char. Snatched. 👑
b. Structure of header fields 🧁
Once header fields are unfolded, they can be seen as a field-name, then a colon (":"), then a field-body. 💜 The field-name has to be made of printable ASCII characters (meaning characters with values between 33. and 126., decimal, except colon) and LWSP-chars. 🍓 The field-body can be made of any ASCII characters, other than an unquoted CRLF (which got removed by unfolding). ✨
Some field-bodies can be read according to an internal syntax that some systems might want to parse. ⭐ Those are called "structured" fields. Examples include fields with dates and addresses. 📅 Other fields, like "Subject" and "Comments," are just treated as strings of text. 📝
NOTE: Field-names, unstructured field bodies and structured field bodies each get scanned by their own, INDEPENDENT "lexical" analyzer. 🔥 Three separate analyzers, no mixing. Respect the boundaries, bestie. 💅
c. Field-names 🎀
To make field-names easier to write and read, you're allowed to freely insert LWSP-chars in reasonable places. 🌷
Instead of cluttering the syntax spec for field-name with the explicit rules for these LWSP-chars, a "lexical" analyzer is assumed to exist. 🧚 The analyzer reads the text of the field-name as a sequence of field-name atoms (fnatoms), separated by LWSP-chars. ✨
Note that ONLY LWSP-chars may appear between the fnatoms of a field-name, and CRLFs may NOT. 🙈 Comments are NOT lexically recognized as such, but parenthesized strings are legal as part of field-names. 🦋 These constraints are different from what's allowed inside structured field bodies. 💅 In particular, this means that header field-names must wholly occur on the FIRST line of a folded header item, and may NOT be split across two or more lines. 😭
d. Unstructured field bodies 🌈
For some fields, like "Subject" and "Comments," there's no structure assumed. 💬 They're treated simply as text, same as the message body. Folding rules still apply to them, so if one of these field bodies takes up several lines, the second and later lines must be indented by at least one LWSP-char. 🫶
e. Structured field bodies 💎
To make structured fields easier to write and read, you can freely insert linear-white-space (which allows folding with CRLFs) in reasonable places. 🌸 Instead of cluttering these structured field syntax specs with explicit rules for this linear-white-space, another "lexical" analyzer is assumed to exist. 🔮 This analyzer doesn't apply to field bodies that are just unstructured strings of text. ✨ It takes the unfolded text of the field body and reads it as a sequence of lexical symbols. 💖 Those symbols are:
- 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. 🧁 When regenerating sequences of atoms and quoted-strings, exactly one SPACE is assumed to exist, and it should be used between them. 💅 (Also, in Section III.B.3.a, check out the rules on how multiple contiguous LWSP-chars are treated. 📚)
So, for example, the folded body of an address field:
":sysmail"@ Some-Host,
Muhammed(I am the greatest)Ali at(the)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
(the) comment
WBA atomThe canonical representations for the data in these addresses are the following strings (note that there is exactly one SPACE between words): 🎀
:sysmail at Some-Hostand
Muhammed Ali at WBA2. Formal Definitions 🧚
The first four rules below set up a meta-syntax for fields, without caring about their particular type or internal syntax. ✨ The remaining rules define the basic syntactic structures that the rules in Sections III.C, III.D, and III.E use. 💕
field = field-name ":" [ field-body ] CRLF
field-name = fnatom *( LWSP-char [fnatom] )
fnatom = 1*<any CHAR, excluding CTLs, SPACE, and ":">
field-body = field-body-contents
[CRLF LWSP-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, and specials tokens, or else consisting of
texts>
; ( Octal, Decimal.)
CHAR = <any TELNET ASCII character> ; ( 0-177, 0.-127.)
ALPHA = <any TELNET ASCII alphabetic character>
; (101-132, 65.- 90.)
; (141-172, 97.-122.)
DIGIT = <any TELNET ASCII digit> ; ( 60- 71, 48.- 57.)
CTL = <any TELNET ASCII control ; ( 0- 37, 0.- 31.)
character and DEL> ; ( 177, 127.)
CR = <TELNET ASCII carriage return>;( 15, 13.)
LF = <TELNET ASCII linefeed> ; ( 12, 10.)
SPACE = <TELNET ASCII space> ; ( 40, 32.)
HTAB = <TELNET ASCII horizontal-tab>; ( 11, 9.)
<"> = <TELNET 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 = "(" / ")" / "<" / ">" / "@" ; To use in a word,
/ "," / ";" / ":" / "\" / <"> ; word must be a
; quoted-string.
delimiters = specials / comment / linear-white-space
text = <any CHAR, including bare ; => atoms, specials,
CR and/or bare LF, but NOT ; comments and
including CRLF> ; quoted-strings are
; NOT interpreted.
atom = 1*<any CHAR except specials and CTLs>
quoted-string = <"> *(qtext/quoted-pair) <">; Any number of qtext
; chars or any
; quoted char.
qtext = <any CHAR excepting <"> ; => may be folded
and CR, and including
linear-white-space>
comment = "(" *(ctext / comment / quoted-pair) ")"
ctext = <any CHAR excluding "(", ; => may be folded
")" and CR, and including
linear-white-space>
quoted-pair = "\" CHAR3. Clarifications 🔍
a. "White space" 🫧
Remember that in field-names and structured field bodies, MULTIPLE LINEAR WHITE SPACE TELNET ASCII CHARACTERS (namely HTABs and SPACEs) ARE TREATED AS SINGLE SPACES AND MAY FREELY SURROUND ANY SYMBOL. ✨ In all header fields, the only place where at least one space is REQUIRED is at the beginning of continuation lines in a folded field. 🦋 When text gets passed to processes that don't interpret it according to this standard (e.g., ARPANET FTP mail servers), then exactly one SPACE should be used in place of any arbitrary linear-white-space and comment sequences. 💅
WHEREVER A MEMBER OF THE LIST OF <DELIMITER>S IS ALLOWED, LWSP-CHARS MAY ALSO OCCUR BEFORE AND/OR AFTER IT. 🌈
Writers of mail-sending (i.e. header generating) programs should realize that there's no Network-wide definition of what horizontal-tab TELNET ASCII characters do to the appearance of text on another Network host. 🙈 So even though tabs are permitted in message headers, their use is discouraged. 🫶
Note that during transmissions across the ARPANET using TELNET NVT connections, data must conform to TELNET NVT conventions (e.g., CR must be followed by either LF, making a CRLF, or <null>, if the CR is to stand alone). 🔥
b. Comments 💬
okay so comments only get recognized inside the field-bodies of structured fields, bestie 🎀 A comment is a set of TELNET ASCII characters that is NOT inside a quoted-string and is enclosed in matching parentheses. Parentheses nest, so if an unquoted left parenthesis shows up in a comment, there must also be a matching right parenthesis. When a comment is the thing separating two lexical symbols, like two atoms, it counts as one SPACE for regenerating the sequence, such as when it gets passed along to an FTP mail server ✨
In particular, comments are NOT passed to the FTP server as part of a MAIL or MLFL command, since comments aren't part of the "formal" address 💅
If a comment gets "folded" onto multiple lines, the folding syntax must be followed. (See items III.B.1.a, above, and III.B.3.f, below.) The official semantics don't "see" any unquoted CRLFs that are in comments, but particular parsing programs may want to note they're there 👀 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 tossed. Quoted CRLFs (a backslash, then a CR, then a LF) still must be followed by at least one LWSP-char 🫶
c. Delimiting and quoting characters 🎀
the quote character (backslash) and the characters that delimit syntactic units usually aren't data that belongs to the unit they wrap 💁♀️ The one exception is SPACE. So the quotation marks that define a quoted-string, the parentheses that define a comment, and the backslash that quotes the next character are NOT part of the quoted-string, comment, or quoted character. If you want a quotation mark to be part of a quoted-string, a parenthesis to be part of a comment, or a backslash to be part of either, each one needs to 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 count as data. Those are the ones that aren't in the alternate text group (ctext or qtext) 🌸
A single SPACE is assumed between contiguous words in a phrase, no matter how many LWSP-chars the creator puts between them. To include more than one SPACE, the creator has to make the LWSP-chars part of a quoted-string ✨
Quotation marks that delimit a quoted string, and backslashes that quote the following character, should NOT come along with the quoted-string when it's used with processes that don't interpret data according to this specification (e.g., ARPANET FTP mail servers) 🙈
d. Quoted-strings 🫧
Wherever they're allowed (that is, in words of structured fields), quoted-strings are treated as a single symbol, syntactically equivalent to an atom. If a quoted-string gets "folded" onto multiple lines, the folding syntax must be followed. (See items III.B.1.a, above, and III.B.3.f, below.) The official semantics don't "see" any bare CRLFs inside quoted-strings, but particular parsing programs may want to note their presence. For those programs, it would be reasonable to read a "CRLF LWSP-char" as a CRLF that's part of the quoted-string. So the CRLF is kept and the LWSP-char is discarded. Quoted CRLFs (a backslash, then a CR, then a LF) also follow the folding rules, but the quoting character (backslash) explicitly shows that the CRLF is data for the quoted string. Stripping off the first following LWSP-char is also appropriate when parsing quoted CRLFs 💖
e. Bracketing characters 🌈
There are three types of brackets, and they must be well nested:
- Parentheses are used to indicate comments.
- Angle brackets ("<" and ">") are generally used to indicate the presence of at least one machine-usable code (e.g., delimiting mailboxes).
- Colon/semi-colon (":" and ";") are used in address specifications to indicate that the included list of addresses are to be treated as a group.
f. Case independence of certain specials atoms 🔤
Some atoms are written in the syntax as literal alphabetic strings, and they can be in any mix of upper and lower case. These are:
- field-name,
"Include","Postal"and equivalent atoms in a":"<atom>":"address specification,"at", in a host-indicator,- node,
- day-of-week,
- month, and
- zones.
When you match an atom against one of these literals, case gets ignored. For example, the field-names "From", "FROM", "from", and even "FroM" should all be treated the same 💅 The case shown in this specification is just suggested for message-creating processes. But at the level of this specification, case IS relevant to other words and texts. Also see Section IV.A.1.f, below. 🧚
g. Folding long lines 📏
Each header item (field of the message) can be on exactly one line made up of the field's name and its body. That's what the parser sees. For readability, it's recommended that the field-body of long header items be "folded" onto multiple lines of the actual header. "Long" is commonly read as meaning greater than 65 or 72 characters. The former length is recommended as a limit, but this standard doesn't impose it 📝
h. Backspace characters ⌫
Backspace TELNET ASCII characters (ASCII BS, decimal 8.) may be included in texts and quoted-strings to create overstriking. However, any backspace use that overstrikes to the left of the beginning of the text or quoted-string is prohibited 🙅♀️
C. GENERAL SYNTAX OF MESSAGES 💌
NOTE: Because of an artifact of the notational conventions, the syntax shows that "Date", "From", "Sender", and "Reply-To" fields must appear in a particular order. These header items must be unique (occur exactly once). However, header fields are NOT required to occur in any particular order, except that the message body must occur AFTER the headers. For readability and easy parsing by simple systems, it's recommended that headers be sent in the order "Date", "From", "Subject", "Sender", "To", "cc", etc. This specification permits multiple occurrences of most optional-fields. However, their interpretation isn't specified here, and their use is strongly discouraged 😭
The following syntax for the bodies of various fields should be thought of as describing each field body as a single long string (or line). The section on Lexical Analysis (section II.B) explains how such long strings can be represented on more than one line in the actual transmitted message 🦋
message = fields *( CRLF *text ) ; Everything after
; first null line
; is message body
fields = date-field ; Creation time-stamp
originator-fields ; & author id are
*optional-field ; required: others
; are all optional
originator-fields =
( "From" ":" mailbox ; Single author
["Reply-To" ":" #address] )
/ ( "From" ":" 1#address ; Multiple authors &
"Sender" ":" mailbox ; may have non-mach-
["Reply-To" ":" #address] ); ine addresses
date-field = "Date" ":" date-time
optional-field =
"To" ":" #address
/ "cc" ":" #address
/ "bcc" ":" #address ; Blind carbon
/ "Subject" ":" *text
/ "Comments" ":" *text
/ "Message-ID" ":" mach-id ; Only one allowed
/ "In-Reply-To"":" #(phrase / mach-id)
/ "References" ":" #(phrase / mach-id)
/ "Keywords" ":" #phrase
/ extension-field ; To be defined in
; supplemental
; specifications
/ user-defined-field ; Must have unique
; field-name & may
; be pre-empted
extension-field = <Any field which is defined in a document
published as a formal extension to this
specification>
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 preempted by published
extensions>D. SYNTAX OF GENERAL ADDRESSEE ITEMS 📬
address = host-phrase ; Machine mailbox
/ ( [phrase] "<" #address ">") ; Individual / List
/ ( [phrase] ":" #address ";") ; Group
/ quoted-string ; Arbitrary text
/ (":" ( "Include" ; File, w/ addr list
/ "Postal" ; (U.S.) Postal addr
/ atom ) ; Extended data type
":" address)
mailbox = host-phrase / (phrase mach-id)
mach-id = "<" host-phrase ">" ; Contents must never
; be modified!E. SUPPORTING CONSTRUCTS 💖
okay bestie, here are the little building-block grammars that the address and date stuff is made of 🧚 copy them exactly, no cap, they're the whole vibe 💅
host-phrase = phrase host-indicator ; Basic address
host-indicator = 1*( ("at" / "@") node ) ; Right-most node is
; at top of network
; hierarchy; left-
; most must be host
node = word / 1*DIGIT ; Official host or
; network name or
; decimal address
date-time = [ day-of-week "," ] date time
day-of-week = "Monday" / "Mon" / "Tuesday" / "Tue"
/ "Wednesday" / "Wed" / "Thursday" / "Thu"
/ "Friday" / "Fri" / "Saturday" / "Sat"
/ "Sunday" / "Sun"
date = 1*2DIGIT ["-"] month ; day month year
["-"] (2DIGIT /4DIGIT) ; e.g. 20 Aug [19]77
month = "January" / "Jan" / "February" / "Feb"
/ "March" / "Mar" / "April" / "Apr"
/ "May" / "June" / "Jun"
/ "July" / "Jul" / "August" / "Aug"
/ "September" / "Sep" / "October" / "Oct"
/ "November" / "Nov" / "December" / "Dec"
time = hour zone ; ANSI and Military
; (seconds optional)
hour = 2DIGIT [":"] 2DIGIT [ [":"] 2DIGIT ]
; 0000[00] - 2359[59]
zone = ( ["-"] ( "GMT" ; Relative to GMT:
; North American
/ "NST" / ; Newfoundland:-3:30
/ "AST" / "ADT" ; Atlantic: - 4/ - 3
/ "EST" / "EDT" ; Eastern: - 5/ - 4
/ "CST" / "CDT" ; Central: - 6/ - 5
/ "MST" / "MDT" ; Mountain: - 7/ - 6
/ "PST" / "PDT" ; Pacific: - 8/ - 7
/ "YST" / "YDT" ; Yukon: - 9/ - 8
/ "HST" / "HDT" ; Haw/Ala -10/ - 9
/ "BST" / "BDT" ; Bering: -11/ -10
1ALPHA )) ; Military: Z = GMT;
; A:-1; (J not used)
; M:-12; N:+1; Y:+12
/ ( ("+" / "-") 4DIGIT ) ; Local differential
; hours/min. (HHMM)
phrase = 1*word ; Sequence of words.
; Separation seman-
; tically = SPACE
word = atom / quoted-stringIV. SEMANTICS ✨
A. ADDRESS FIELDS 📬
1. General
a. The phrase part of a host-phrase in an address specification (i.e., the host's name for the mailbox) is understood to be whatever the receiving FTP Server allows. For example, TENEX systems do not now understand addresses of the form "P. D. Q. Bach", but another system might. 🎀
Note that a mailbox is a conceptual entity which does not necessarily pertain to file storage. For example, some sites MAY choose to print mail on their line printer and deliver the output to the addressee's desk. 🖨️
An individual MAY have several mailboxes, and a group of individuals MAY wish to receive mail as a single unit (i.e., a distribution list). The second and third alternatives of an address list (#address) allow naming a collection of subordinate addresses list(s). Recipient mailboxes are specified within the bracketed part ("<" - ">" or ":" - ";") of such named lists. The use of angle-brackets ("<", ">") is intended for the cases of individuals with multiple mailboxes and of special mailbox lists; it is not expected to be nested more than one level, although the specification allows such nesting. The use of colon/semi-colon (":", ";") is intended for the case of groups. Groups can be expected to nest (i.e., to contain subgroups). For both individuals and groups, a copy of the transmitted message is to be sent to EACH mailbox listed. For the case of a special list, treatment of addresses is defined in the relevant subsections of this section. 📮
b. The inclusion of bare quoted-strings as addresses (i.e., the fourth address-form alternative) is allowed as a syntactic convenience, but no semantics are defined for their use. However, it is reasonable, when replicating an address list, to replicate ALL of its members, including quoted-strings. 🌸
c. ":Include:" specifications are used to refer to one or more locations containing stored address lists (#address). If more than one location is referenced, the address part of the Include phrase MUST be a list (#address) surrounded by angle-brackets, as per the "Individual / List" alternative of <address>. Constituent addresses MUST resolve to a host-phrase; only they have any meaning within this construct. The phrase part of indicated host-phrases SHOULD contain text which the referenced host can resolve to a file. This standard is not a protocol and so does not prescribe HOW data is to be retrieved from the file. However, the following requirements are made: 🗂️
- 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 allow programs to retrieve such lists automatically. 🤖
The interpretation of such a file reference follows. This is not intended to imply any particular implementation scheme, but is presented to aid in understanding the notion of including file contents in address lists: 🧠
- Elements of the address list part are alternates, and the contents of ONLY ONE of them are to be included in the resultant address list.
- The contents of the file indicated by a member host-phrase are treated as an address list and are inserted as an address list (#address) in the position of the path item in the syntax. That is, the TELNET ASCII characters specifying the entire Include <address> is replaced by the contents of one of the files to which the host-phrase(s), of the address list (#address), refers. Therefore, the contents of each file, indicated by an Include address, MUST be syntactically self-contained and MUST adhere to the full syntax prescribed herein for an address list. 🔥
d. ":Postal:" specifications are used to indicate (U.S.) postal addresses, but can be treated the same as quoted-string addresses. To reference a list of postal addresses, the list MUST conform to the "Individual / List" alternative of <address>. The ":Include:" alternative also is valid. 🏤
e. The "':' atom ':'" syntax is intended as a general mechanism for indicating specially data-typed addresses. As with extension-fields, the authors of this document will regulate the publishing of specifications for these extended data-types. In the absence of defined semantics, any occurrence of an address in this form MAY be treated as a quoted-string address. 🧩
f. A node name MUST be THE official name of a network or a host, or else a decimal number indicating the Network address for that network or host, at the time the message is created. The USE OF NUMBERS IS STRONGLY DISCOURAGED and is permitted only due to the occasional necessity of bypassing local name tables. For the ARPANET, official names are maintained by the Network Information Center at SRI International, Menlo Park, California. 🛰️
Whenever a message might be transmitted or migrate to a host on another network, full hierarchical addresses MUST be specified. These are indicated as a series of words, separated by at-sign or "at" indications. The communication environment is assumed to consist of a collection of networks organized as independent "trees" except for connections between the root nodes. That is, only the roots can act as gateways between these independent networks. While other actual connections MAY exist, it is believed that presuming this type of organization will provide a reliable method for describing VALID, if not EFFICIENT, paths between hosts. A typical full mailbox specification might therefore look like: 🌳
Friendly User @ hosta @ local-net1 @ major-netqIn the simplest case, a mail-sending host SHOULD transmit the message to the node which is mentioned last (farthest to the right), strip off that node reference from the specification, and then pass the remaining host-phrase to the recipient host (in the ARPANET, its FTP server) for it to process. This treats the remaining portion of the host-indicator merely as the terminating part of the phrase. 💫
NOTE: When passing any portion of a host-indicator onto a process which does not interpret data according to this standard (e.g., ARPANET FTP servers), "@" MUST be used and not "at", and it MUST NOT be preceded or followed by any LWSP-chars. Using the above example, the following string would be passed to the major-netq gateway: 🙈
Friendly User@hosta@local-net1When the sending host has more knowledge of the network environment, then it SHOULD send the message along a more efficient path, making appropriate changes to the form of the host-phrase which it gives to the recipient host. 🚀
To use the above specification as an example: If a sending hostb also were part of local-net1, then it could send the message directly to hosta and would give only the phrase "Friendly User" to hosta's mail-receiving program. If hostb were part of local-net2, along with hostc, and happened to know that hosta and hostc were part of another local-net, then hostb could send the message to hostc to the address "Friendly User@hosta". 🧃
The phrase in a host-phrase is intended to be meaningful only to the indicated receiving host. To all other hosts, the phrase is to be treated as an uninterpreted 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. 💌
2. 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. 🚨
a. 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 AGENT (person or process) entering the message. If this is NOT done, the Sender field MUST be present; if this IS done, the Sender field is optional. 💖
b. Sender 💌
This field contains the identity of the AGENT (person or process) who 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 sent it. If the contents of Sender would be completely redundant with the From field, then the Sender field need not be present and its use is discouraged (though still legal). Bestie, in particular, the Sender field MUST be present if it is NOT the same as the From Field. 🫶
The Sender host-phrase includes a phrase which must correspond to a specific agent (i.e., a human user or a computer program) rather than a standard address. This shows the expectation that the field will identify the single AGENT (person or process) responsible for sending the mail, and not simply include the name of a mailbox the mail was sent from. For example, with a shared login name, the name by itself would not be adequate. The phrase part of the host-phrase that refers to this agent is expected to be a computer system term, and not (for example) a generalized person reference that can be used outside the network text message context. 🤖
Since the critical job of the Sender field is identifying the agent responsible for sending mail, and since computer programs cannot be held accountable for their behavior, it is strongly recommended that when a computer program generates a message, the HUMAN who is responsible for that program be referenced as part of the Sender field host-phrase. This is giving accountability energy 👑
c. Reply-To 🎀
This field provides a general mechanism for indicating any mailbox(es) that responses should be sent to. There are three typical uses for this feature. In the first case, the author(s) may not have regular machine-based mailboxes and therefore wish(es) 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) listed in the original message. A somewhat different use may help "text message teleconferencing" groups that have automatic distribution services: include the address of that service in the Reply-To field of all messages submitted to the teleconference, so participants can "reply" to conference submissions and guarantee the correct distribution of any submission of their own. 🌸
Reply-To fields are NOT required to contain any machine addresses (i.e., host-phrases). Note, however, that the absence of even one valid network address will tend to stop software systems from automatically helping users respond to mail conveniently. 😭
NOTE: For systems that automatically generate address lists for replies to messages, the following recommendations are made:
- The receiver, when replying to a message, should NEVER automatically include the
Senderhost-phrase in the reply's address list. - If the
Reply-Tofield exists, then the reply should go ONLY to the addresses indicated in that field and not to the addresses indicated in theFromfield.
(Extensive examples are provided in Section V.) This recommendation is intended only for originator-fields and is not intended to suggest that replies should not also be sent to the other recipients of this message. It's up to the respective mail handling programs to decide what additional facilities will be provided. 🦋
3. Receiver Fields 💜
a. To 💕
This field contains the identity of the primary recipients of the message.
b. cc 🍓
This field contains the identity of the secondary recipients of the message.
b. 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 all those indicated in the Bcc list. 🤫
B. REFERENCE SPECIFICATION FIELDS 🧚
1. Message-ID
This field contains a unique identifier (the phrase) which refers to THIS version of THIS message. The uniqueness of the message identifier is guaranteed by the host which 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; subsequent revisions to the message should each receive a new message identifier. ✨
2. In-Reply-To
The contents of this field identify previous correspondence which this message answers. Note that if message identifiers are used in this field, they must use the mach-id specification format. 🔁
3. References
The contents of this field identify other correspondence which this message references. Note that if message identifiers are used, they must use the mach-id specification format. 📎
4. Keywords
This field contains keywords or phrases, separated by commas. 🏷️
C. OTHER FIELDS AND SYNTACTIC ITEMS 💅
1. Subject
The Subject field is meant to provide as much information as necessary to adequately summarize or indicate the nature of the message. 📝
2. Comments
Permits adding text comments onto the message without disturbing the contents of the message's body. 💬
3. Extension-field
A relatively limited number of common fields have been defined in this document. As network mail requirements dictate, additional fields may be standardized. The authors of this document will regulate the publishing of such definitions as extensions to the basic specification. 🌈
4. User-defined-field
Individual users of network mail are free to define and use additional header fields. Such fields must have names that are not already used in the current specification or in any definitions of extension-fields, and the overall syntax of these user-defined-fields must conform to this specification's rules for delimiting and folding fields. Due to the extension-field publishing process, the name of a user-defined-field may be pre-empted. 🧁
D. DATES AND TIMES 🕰️
If included, day-of-week must be the day implied by the date specification. ✨
Time zone may be indicated in several ways. The military standard uses a single character for each zone. "Z" is Greenwich Mean Time; "A" indicates one hour earlier, and "M" indicates 12 hours earlier; "N" is one hour later, and "Y" is 12 hours later. The letter "J" is not used. The other two remaining forms are taken from ANSI standard X3.51-1975. One allows explicit indication of the amount of offset from GMT; the other uses common 3-character strings for indicating time zones in North America. 🌎
V. EXAMPLES 🎀
A. ADDRESSES 💌
1. Alfred E. Neuman <Neuman at BBN-TENEXA>
Alfred E. Neuman <Neuman at BBN-TENEXA>2. Neuman@BBN-TENEXA
Neuman@BBN-TENEXAThese two "Alfred E. 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 FTP server are concerned. In the first example, the "Alfred E. Neuman" is ignored by the mailer, since "Neuman at BBN-TENEXA" completely specifies the recipient. The second example contains no superfluous information, and, again, "Neuman@BBN-TENEXA" is the intended recipient. 🧠
3. Al Neuman at BBN-TENEXA
Al Neuman at BBN-TENEXAThis is identical to "Al Neuman <Al Neuman at BBN-TENEXA>". That is, the full phrase, "Al Neuman", is passed to the FTP server. Note that not all FTP servers accept multi-word identifiers; 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 "Neuman"). 😬
4. "George Lovell, Ted Hackle" <Shared-Mailbox at Office-1>
"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, since "Shared-Mailbox at Office-1" completely specifies the destination mailbox. 🤝
4. Wilt (the Stilt) Chamberlain at NBA
Wilt (the Stilt) Chamberlain at NBAThe "(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.) 🏀
B. ADDRESS LISTS 🍷
Gourmets: Pompous Person <WhoZiWhatZit at Cordon-Bleu>,
Cooks: Childs at WGBH, Galloping Gourmet at
ANT (Australian National Television);,
Wine Lovers: Cheapie at Discount-Liquors,
Port at Portugal;;,
Jones at SEAThis group list example shows 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. 🧀
C. ORIGINATOR ITEMS 📮
1. Author-sent
George Jones logs into his Host as "Jones". He sends mail himself. 💁
From: Jones at Host
or
From: George Jones <Jones at Host>2. Secretary-sent
George Jones logs in as Jones on his Host. His secretary, who logs in as Secy on Shost, sends mail for him. Replies to the mail should go to George, of course. 💼
From: George Jones <Jones at Host>
Sender: Secy at SHost3. Shared directory or unrepresentative directory-name
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>4. Secretary-sent, for user of shared directory
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). ✨
5. Secretary acting as full agent of author
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 Host6. Agent for user without online mailbox
A non-ARPANET user friend of George's, Sarah, is visiting. George's secretary sends some mail to a friend of Sarah in computer-land. Replies should go to George, whose mailbox is Jones at Host. 🌙
From: Sarah Friendly
Sender: Secy at Host
Reply-To: Jones at Host7. Sent by member of a committee
George is a member of a committee. He wishes to have any replies
So George wants every reply to his message to go to all the committee members 📬🎀
From: George Jones
Sender: Jones at Host
Reply-To: Big-committee: Jones at Host,
Smith at Other-Host,
Doe at Somewhere-Else;Note that if George had not included himself in the enumeration of Big-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. So the Reply-To list is the boss now 👑
8. Example of INCORRECT use 🚫
George wants a reply to go to his secretary, so his secretary leaves his mailbox address off the From field, leaving only his name, which is not, itself, a mailbox address 💀
From: George Jones
Sender: Secy at SHostTHIS IS NOT PERMITTED. Replies are NEVER implicitly sent to the Sender. The secretary should have used the Reply-To field, or the mail creating program should have forced the secretary to do that 😭
9. Agent for member of a committee 🧚
George's secretary sends out a message that was authored jointly by all the members of the Big-committee. Iconic teamwork 🫶
From: Big-committee: Jones at Host,
Smith at Other-Host,
Doe at Somewhere-Else;
Sender: Secy at SHostD. COMPLETE HEADERS 💖
1. Minimum required:
Date: 26 August 1976 1429-EDT
From: Jones at Host2. Using some of the additional fields:
Date: 26 August 1976 1430-EDT
From:George Jones<Group at Host>
Sender:Secy at SHOST
To:Al Neuman at Mad-Host,
Sam Irving at Other-Host
Message-ID: <some string at SHOST>3. About as complex as you're going to get: 🌈
Date : 27 Aug 1976 0932-PDT
From : Ken Davis <KDavis at Other-Host>
Subject : Re: The Syntax in the RFC
Sender : KSecy at Other-Host
Reply-To : Sam Irving at Other-Host
To : George Jones <Group at Host>,
Al Neuman at Mad-Host
cc : Important folk:
Tom Softwood <Balsa at Another-Host>,
Sam Irving at Other-Host;,
Standard Distribution::Include:
</main/davis/people/standard at Other-Host,
"<Jones>standard.dist.3" at Tops-20-Host>,
(The following Included Postal list is part
of Standard Distribution.)
:Postal::Include: Non-net-addrs@Other-host;,
:Postal: "Sam Irving, P.O. Box 001, Las Vegas,
Nevada" (So that he can stay
apprised of the situation)
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 at SHOST>
Special (action): This is a sample of multi-word field-
names, using a range of characters. There
could also be a field-name "Special (info)".
Message-ID: <4231.629.XYzi-What at Other-Host>APPENDIX ✨
A. ALPHABETICAL LISTING OF SYNTAX RULES 📚
address = host-phrase / quoted-string
/ (*phrase "<" #address ">" )
/ (*phrase ":" #address ";" )
/ (":" ("Include" / "Postal" / atom) ":" address)
ALPHA = <any TELNET ASCII alphabetic character>
atom = 1*<any CHAR except specials and CTLs>
CHAR = <any TELNET ASCII character>
comment = "(" *(ctext / comment / quoted-pair) ")"
CR = <TELNET ASCII carriage return>
CRLF = CR LF
ctext = <any CHAR excluding "(", ")", CR, LF and
including linear-white-space>
CTL = <any TELNET ASCII control character and DEL>
date = 1*2DIGIT ["-"] month ["-"] (2DIGIT /4DIGIT)
date-field = "Date" ":" date-time
date-time = [ day-of-week "," ] date time
day-of-week = "Monday" / "Mon" / "Tuesday" / "Tue"
/ "Wednesday" / "Wed" / "Thursday" / "Thu"
/ "Friday" / "Fri" / "Saturday" / "Sat"
/ "Sunday" / "Sun"
delimiters = specials / comment / linear-white-space
DIGIT = <any TELNET ASCII digit>
extension-field = <Any field which is defined in a document
published as a formal extension to this
specification>
field = field-name ":" [ field-body ] CRLF
fields = date-field originator-fields *optional-field
field-body = field-body-contents
[CRLF LWSP-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, and specials tokens, or else consisting of
texts>
field-name = fnatom *(LWSP-char [fnatom])
fnatom = 1*<any CHAR, excluding CTLs, SPACE, and ":">
host-indicator = 1*( ("at" / "@") node )
host-phrase = phrase host-indicator
hour = 2DIGIT [":"] 2DIGIT [ [":"] 2DIGIT ]
HTAB = <TELNET ASCII horizontal-tab>
LF = <TELNET ASCII linefeed>
linear-white-space = 1*([CRLF] LWSP-char)
LWSP-char = SPACE / HTAB
mach-id = "<" host-phrase ">"
mailbox = host-phrase / (phrase mach-id)
message = fields *(CRLF *text)
month = "January" / "Jan" / "February" / "Feb"
/ "March" / "Mar" / "April" / "Apr"
/ "May" / "June" / "Jun"
/ "July" / "Jul" / "August" / "Aug"
/ "September" / "Sep" / "October" / "Oct"
/ "November" / "Nov" / "December" / "Dec"
node = word / 1*DIGIT
optional-field =
"To" ":" #address
/ "cc" ":" #address
/ "bcc" ":" #address
/ "Subject" ":" *text
/ "Comments" ":" *text
/ "Message-ID" ":" mach-id
/ "In-Reply-To"":" #(phrase / mach-id)
/ "References" ":" #(phrase / mach-id)
/ "Keywords" ":" #phrase
/ extension-field
/ user-defined-field
originator-fields =
( "From" ":" mailbox
["Reply-To" ":" #address] )
/ ( "From" ":" 1#address
"Sender" ":" mailbox
["Reply-To" ":" #address] )
phrase = 1*word
quoted-pair = "\" CHAR
quoted-string = <"> *(qtext / quoted-pair) <">
qtext = <any CHAR except <">, CR, or LF and including
linear-white-space>
SPACE = <TELNET ASCII space>
specials = "(" / ")" / "<" / ">" / "@"/ "," / ";" / ":"
/ "\" / <">
text = <any CHAR, including bare CR and/or bare LF, but
NOT including CRLF>
time = hour zone
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 preempted by putlished
extensions>
word = atom / quoted-string
zone = ( ("+" / "-") 4DIGIT )
/ ( ["-"] (1ALPHA
/ "GMT" / "NST" / "AST" / "ADT" / "EST" / "EDT"
/ "CST" / "CDT" / "MST" / "MDT" / "PST" / "PDT"
/ "YST" / "YDT" / "HST" / "HDT" / "BST" / "BDT" ))
<"> = <TELNET ASCII quote mark>B. SIMPLE PARSING 🎀
Some mail-reading software systems may wish to do only minimal processing, ignoring the internal syntax of structured field-bodies and treating 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 will be enough for this purpose 💅 They describe a limited view of messages and are 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:
SYNTAX:
message = *field *(CRLF *text)
field = field-name ":" [field-body] CRLF
field-name = fnatom *( LWSP-char [fnatom] )
fnatom = 1*<any CHAR, excluding CTLs, SPACE, and ":">
field-body = *text [CRLF LWSP-char field-body]SEMANTICS:
Headers occur before the message body and are terminated 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), each separated by one or more SPACES or HTABS. A field-name MUST be contained on one line. Upper and lower case are not distinguished when comparing field-names.
BIBLIOGRAPHY 📖
ANSI. Representations of universal time, local time differentials, and United States time zone references for information interchange. ANSI X3.51-1975; American National Standards Institute: New York, 1975.
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.
McKenzie, A. TELNET Protocol Specification. Network Information Center No. 18639; Augmentation Research Center, Stanford Research Institute: Menlo Park, August 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.
Pogran, K., Vittal, J., Crocker, D. and Henderson, A. Proposed official standard for the format of ARPA network messages. ARPANET Request for Comments, No. 724, Network Information Center No. 37435; Augmentation Research Center, Stanford Research Institute: Menlo Park, May 1977.
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. 🦋
📦 where this page comes from
- ietf: rfc733 1977-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms