As per Relevance of the word indicate, we have this rfc below:
RFC # 822
Obsoletes: RFC #733 (NIC #41952)
STANDARD FOR THE FORMAT
ARPA INTERNET TEXT
August 13, 1982
Revised
David H.
Dept. of Electrical
University of Delaware, Newark, DE 19711
Network: DCrocker @ UDel-
Standard for ARPA Internet Text
TABLE OF
PREFACE ....................................................
1. INTRODUCTION ........................................... 1
1.1. Scope ............................................ 1
1.2. Communication Framework .......................... 2
2. NOTATIONAL CONVENTIONS ................................. 3
3. LEXICAL ANALYSIS OF MESSAGES ........................... 5
3.1. General Description .............................. 5
3.2. Header Field Definitions ......................... 9
3.3. Lexical Tokens ................................... 10
3.4. Clarifications ................................... 11
4. MESSAGE SPECIFICATION .................................. 17
4.1. Syntax ........................................... 17
4.2. Forwarding ....................................... 19
4.3. Trace Fields ..................................... 20
4.4. Originator Fields ................................ 21
4.5. Receiver Fields .................................. 23
4.6. Reference Fields ................................. 23
4.7. Other Fields ..................................... 24
5. DATE AND TIME SPECIFICATION ............................ 26
5.1. Syntax ........................................... 26
5.2. Semantics ........................................ 26
6. ADDRESS SPECIFICATION .................................. 27
6.1. Syntax ........................................... 27
6.2. Semantics ........................................ 27
6.3. Reserved Address ................................. 33
7. BIBLIOGRAPHY ........................................... 34
A. EXAMPLES ............................................... 36
B. SIMPLE FIELD PARSING ................................... 40
C. DIFFERENCES FROM RFC #733 .............................. 41
D. ALPHABETICAL LISTING OF SYNTAX RULES ................... 44
August 13, 1982 - i - RFC #822
Standard for ARPA Internet Text
By 1977, the Arpanet employed several informal standards
the text messages (mail) sent among its host computers. It
felt necessary to codify these practices and provide for
features that seemed imminent. The result of that effort
Request for Comments (RFC) #733, "Standard for the Format of
Network Text Message", by Crocker, Vittal, Pogran, and Henderson
The specification attempted to avoid major changes in
software, while permitting several new features
This document revises the specifications in RFC #733,
order to serve the needs of the larger and more complex
Internet. Some of RFC #733's features failed to gain
acceptance. In order to simplify the standard and the
that follows it, these features have been removed. A
addressing scheme is used, to handle the case of inter-
mail; and the concept of re-transmission has been introduced
This specification is intended for use in the ARPA Internet
However, an attempt has been made to free it of any dependence
that environment, so that it can be applied to other network
message systems
The specification of RFC #733 took place over the course
one year, using the ARPANET mail environment, itself, to
an on-going forum for discussing the capabilities to be included
More than twenty individuals, from across the country, partici
pated in the original discussion. The development of
revised specification has, similarly, utilized network mail-
group discussion. Both specification efforts greatly
from the comments and ideas of the participants
The syntax of the standard, in RFC #733, was
specified in the Backus-Naur Form (BNF) meta-language. Ken L
Harrenstien, of SRI International, was responsible for re-
the BNF into an augmented BNF that makes the
smaller and easier to understand
August 13, 1982 - ii - RFC #822
Standard for ARPA Internet Text
1.
1.1.
This standard specifies a syntax for text messages that
sent among computer users, within the framework of "
mail". The standard supersedes the one specified in
Request for Comments #733, "Standard for the Format of ARPA Net
work Text Messages".
In this context, messages are viewed as having an
and contents. The envelope contains whatever information
needed to accomplish transmission and delivery. The
compose the object to be delivered to the recipient. This stan
dard applies only to the format and some of the semantics of mes
sage contents. It contains no specification of the
in the envelope
However, some message systems may use information from
contents to create the envelope. It is intended that this stan
dard facilitate the acquisition of such information by programs
Some message systems may store messages in formats
differ from the one specified in this standard. This specifica
tion is intended strictly as a definition of what message
format is to be passed BETWEEN hosts
Note: This standard is NOT intended to dictate the internal for
mats used by sites, the specific message system
that they are expected to support, or any of the charac
teristics of user interface programs that create or
messages
A distinction should be made between what the
REQUIRES and what it ALLOWS. Messages can be made complex
rich with formally-structured components of information or can
kept small and simple, with a minimum of such information. Also
the standard simplifies the interpretation of differing
formats in messages; only the visual aspect of a message
affected and not the interpretation of information within it
Implementors may choose to retain such visual distinctions
The formal definition is divided into four levels. The bot
tom level describes the meta-notation used in this document.
second level describes basic lexical analyzers that feed
to higher-level parsers. Next is an overall specification
messages; it permits distinguishing individual fields. Finally
there is definition of the contents of several structured fields
August 13, 1982 - 1 - RFC #822
Standard for ARPA Internet Text
1.2. COMMUNICATION
Messages consist of lines of text. No special
are made for encoding drawings, facsimile, speech, or
text. No significant consideration has been given to
of data compression or to transmission and storage efficiency
and the standard tends to be free with the number of bits con
sumed. For example, field names are specified as free text
rather than special terse codes
A general "memo" framework is used. That is, a message con
sists of some information in a rigid format, followed by the
part of the message, with a format that is not specified in
document. The syntax of several fields of the rigidly-
("headers") section is defined in this specification; some
these fields must be included in all messages
The syntax that distinguishes between header fields
specified separately from the internal syntax for
fields. This separation is intended to allow simple parsers
operate on the general structure of messages, without concern
the detailed structure of individual header fields. Appendix
is provided to facilitate construction of these parsers
In addition to the fields specified in this document, it
expected that other fields will gain common use. As necessary
the specifications for these "extension-fields" will be
through the same mechanism used to publish this document.
may also wish to extend the set of fields that they
privately. Such "user-defined fields" are permitted
The framework severely constrains document tone and appear
ance and is primarily useful for most intra-organization communi
cations and well-structured inter-organization communication
It also can be used for some types of inter-process communica
tion, such as simple file transfer and remote job entry. A
robust framework might allow for multi-font, multi-color, multi
dimension encoding of information. A less robust one, as
present in most single-machine message systems, would
severely constrain the ability to add fields and the decision
include specific fields. In contrast with paper-based communica
tion, it is interesting to note that the RECEIVER of a
can exercise an extraordinary amount of control over
message's appearance. The amount of actual control available
message receivers is contingent upon the capabilities of
individual message systems
August 13, 1982 - 2 - RFC #822
Standard for ARPA Internet Text
2. NOTATIONAL
This specification uses an augmented Backus-Naur Form (BNF
notation. The differences from standard BNF involve naming
and indicating repetition and "local" alternatives
2.1. RULE
Angle brackets ("<", ">") are not used, in general.
name of a rule is simply the name itself, rather than "".
Quotation-marks enclose literal text (which may be upper and/
lower case). Certain basic rules are in uppercase, such
SPACE, TAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used
rule definitions, and in the rest of this document,
their presence will facilitate discerning the use of rule names
2.2. RULE1 / RULE2:
Elements separated by slash ("/") are alternatives. There
fore "foo / bar" will accept foo or bar
2.3. (RULE1 RULE2): LOCAL
Elements enclosed in parentheses are treated as a
element. Thus, "(elem (foo / bar) elem)" allows the
sequences "elem foo elem" and "elem bar elem".
2.4. *RULE:
The character "*" preceding an element indicates repetition
The full form is
*
indicating at least and at most occurrences of element
Default values are 0 and infinity so that "*(element)" allows
number, including zero; "1*element" requires at least one;
"1*2element" allows one or two
2.5. [RULE]:
Square brackets enclose optional elements; "[foo bar]"
equivalent to "*1(foo bar)".
2.6. NRULE: SPECIFIC
"(element)" is equivalent to "*(element)"; that is
exactly occurrences of (element). Thus 2DIGIT is a 2-
number, and 3ALPHA is a string of three alphabetic characters
August 13, 1982 - 3 - RFC #822
Standard for ARPA Internet Text
2.7. #RULE:
A construct "#" is defined, similar to "*", as follows
#
indicating at least and at most elements, each
by one or more commas (","). This makes the usual form of
very easy; a rule such as '(element *("," element))' can be
as "1#element". Wherever this construct is used, null
are allowed, but do not contribute to the count of
present. That is, "(element),,(element)" is permitted,
counts as only two elements. Therefore, where at least one ele
ment is required, at least one non-null element must be present
Default values are 0 and infinity so that "#(element)" allows
number, including zero; "1#element" requires at least one;
"1#2element" allows one or two
2.8. ;
A semi-colon, set off some distance to the right of
text, starts a comment that continues to the end of line.
is a simple way of including useful notes in parallel with
specifications
August 13, 1982 - 4 - RFC #822
Standard for ARPA Internet Text
3. LEXICAL ANALYSIS OF
3.1. GENERAL
A message consists of header fields and, optionally, a body
The body is simply a sequence of lines containing ASCII charac
ters. It is separated from the headers by a null line (i.e.,
line with nothing preceding the CRLF).
3.1.1. LONG HEADER
Each header field can be viewed as a single, logical line
ASCII characters, comprising a field-name and a field-body
For convenience, the field-body portion of this
entity can be split into a multiple-line representation;
is called "folding". The general rule is that wherever
may be linear-white-space (NOT simply LWSP-chars), a
immediately followed by AT LEAST one LWSP-char may instead
inserted. Thus, the single
To: "Joe & J. Harvey" , JJV @
can be represented as
To: "Joe & J. Harvey" ,
JJV@
To: "Joe & J. Harvey
,
@
To: "Joe &
J. Harvey" , JJV @
The process of moving from this folded multiple-
representation of a header field to its single line represen
tation is called "unfolding". Unfolding is accomplished
regarding CRLF immediately followed by a LWSP-char
equivalent to the LWSP-char
Note: While the standard permits folding wherever linear
white-space is permitted, it is recommended that struc
tured fields, such as those containing addresses,
folding to higher-level syntactic breaks. For
fields, it is recommended that such folding
August 13, 1982 - 5 - RFC #822
Standard for ARPA Internet Text
between addresses, after the separating comma
3.1.2. STRUCTURE OF HEADER
Once a field has been unfolded, it may be viewed as being com
posed of a field-name followed by a colon (":"), followed by
field-body, and terminated by a carriage-return/line-feed
The field-name must be composed of printable ASCII
(i.e., characters that have values between 33. and 126.,
decimal, except colon). The field-body may be composed of
ASCII characters, except CR or LF. (While CR and/or LF may
present in the actual text, they are removed by the action
unfolding the field.)
Certain field-bodies of headers may be interpreted
to an internal syntax that some systems may wish to parse
These fields are called "structured fields".
include fields containing dates and addresses. Other fields
such as "Subject" and "Comments", are regarded simply
strings of text
Note: Any field which has a field-body that is defined
other than simply is to be treated as a struc
tured field
Field-names, unstructured field bodies and
field bodies each are scanned by their own,
"lexical" analyzers
3.1.3. UNSTRUCTURED FIELD
For some fields, such as "Subject" and "Comments", no struc
turing is assumed, and they are treated simply as s,
in the message body. Rules of folding apply to these fields
so that such field bodies which occupy several lines
therefore have the second and successive lines indented by
least one LWSP-char
3.1.4. STRUCTURED FIELD
To aid in the creation and reading of structured fields,
free insertion of linear-white-space (which permits
by inclusion of CRLFs) is allowed between lexical tokens
Rather than obscuring the syntax specifications for
structured fields with explicit syntax for this linear-white
space, the existence of another "lexical" analyzer is assumed
This analyzer does not apply for unstructured field
that are simply strings of text, as described above.
analyzer provides an interpretation of the unfolded
August 13, 1982 - 6 - RFC #822
Standard for ARPA Internet Text
composing the body of the field as a sequence of lexical sym
bols
These symbols are
- individual special
- quoted-
- domain-
-
-
The first four of these symbols are self-delimiting.
are not; they are delimited by the self-delimiting symbols
by linear-white-space. For the purposes of
sequences of atoms and quoted-strings, exactly one SPACE
assumed to exist, and should be used, between them. (Also,
the "Clarifications" section on "White Space", below, note
rules about treatment of multiple contiguous LWSP-chars.)
So, for example, the folded body of an address
":sysmail"@ Some-Group. Some-Org
Muhammed.(I am the greatest) Ali @(the)Vegas.
August 13, 1982 - 7 - RFC #822
Standard for ARPA Internet Text
is analyzed into the following lexical symbols and types
:sysmail quoted
@
Some-Group
.
Some-Org
,
Muhammed
.
(I am the greatest)
Ali
@
(the)
Vegas
.
WBA
The canonical representations for the data in these
are the following strings
":sysmail"@Some-Group.Some-
Muhammed.Ali@Vegas.
Note: For purposes of display, and when passing such struc
tured information to other systems, such as mail proto
col services, there must be NO linear-white-
between s that are separated by period (".")
at-sign ("@") and exactly one SPACE between all
s. Also, headers should be in a folded form
August 13, 1982 - 8 - RFC #822
Standard for ARPA Internet Text
3.2. HEADER FIELD
These rules show a field meta-syntax, without regard for
particular type or internal syntax. Their purpose is to
detection of fields; also, they present to higher-level
an image of each field as fitting on one line
field = field-name ":" [ field-body ]
field-name = 1*
field-body = field-body-
[CRLF LWSP-char field-body
field-body-contents =
defined in the following sections, and
of combinations of atom, quoted-string,
specials tokens, or else consisting of texts
August 13, 1982 - 9 - RFC #822
Standard for ARPA Internet Text
3.3. LEXICAL
The following rules are used to define an underlying
analyzer, which feeds tokens to higher level parsers. See
ANSI references, in the Bibliography
; ( Octal, Decimal.)
CHAR = character> ; ( 0-177, 0.-127.)
ALPHA = character
; (101-132, 65.- 90.)
; (141-172, 97.-122.)
DIGIT = ; ( 60- 71, 48.- 57.)
CTL =
character and DEL> ; ( 177, 127.)
CR = ; ( 15, 13.)
LF = linefeed> ; ( 12, 10.)
SPACE = ; ( 40, 32.)
HTAB = horizontal-tab> ; ( 11, 9.)
<"> = ; ( 42, 34.)
CRLF = CR
LWSP-char = SPACE / HTAB ; semantics =
linear-white-space = 1*([CRLF] LWSP-char) ; semantics =
; CRLF =>
specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted
/ "," / ";" / ":" / "\" / <"> ; string, to
/ "." / "[" / "]" ; within a word
delimiters = specials / linear-white-space /
text = atoms, specials
CR & bare LF, but NOT ; comments
including CRLF> ; quoted-strings
; NOT recognized
atom = 1*
quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext
; quoted chars
qtext = , ; => may be
"\" & CR, and
linear-white-space
domain-literal = "[" *(dtext / quoted-pair) "]"
August 13, 1982 - 10 - RFC #822
Standard for ARPA Internet Text
dtext = may be
"]", "\" & CR, &
linear-white-space
comment = "(" *(ctext / quoted-pair / comment) ")"
ctext = may be
")", "\" & CR, &
linear-white-space
quoted-pair = "\" CHAR ; may quote any
phrase = 1*word ; Sequence of
word = atom / quoted-
3.4.
3.4.1.
Some characters are reserved for special interpretation,
as delimiting lexical tokens. To permit use of these charac
ters as uninterpreted data, a quoting mechanism is provided
To quote a character, precede it with a backslash ("\").
This mechanism is not fully general. Characters may be
only within a subset of the lexical constructs. In particu
lar, quoting is limited to use within
- quoted-
- domain-
-
Within these constructs, quoting is REQUIRED for CR and "\"
and for the character(s) that delimit the token (e.g., "("
")" for a comment). However, quoting is PERMITTED for
character
Note: In particular, quoting is NOT permitted within atoms
For example when the local-part of an addr-spec
contain a special character, a quoted string must
used. Therefore, a specification such as
Full\ Name@
is not legal and must be specified as
"Full Name"@
August 13, 1982 - 11 - RFC #822
Standard for ARPA Internet Text
3.4.2. WHITE
Note: In structured field bodies, multiple linear space
characters (namely HTABs and SPACEs) are treated
single spaces and may freely surround any symbol.
all header fields, the only place in which at least
LWSP-char is REQUIRED is at the beginning of continua
tion lines in a folded field
When passing text to processes that do not interpret
according to this standard (e.g., mail protocol servers),
NO linear-white-space characters should occur between a
(".") or at-sign ("@") and a . Exactly ONE SPACE
be used in place of arbitrary linear-white-space and
sequences
Note: Within systems conforming to this standard, wherever
member of the list of delimiters is allowed, LWSP-
may also occur before and/or after it
Writers of mail-sending (i.e., header-generating)
should realize that there is no network-wide definition of
effect of ASCII HT (horizontal-tab) characters on the appear
ance of text at another network host; therefore, the use
tabs in message headers, though permitted, is discouraged
3.4.3.
A comment is a set of ASCII characters, which is enclosed
matching parentheses and which is not within a quoted-
The comment construct permits message originators to add
which will be useful for human readers, but which will
ignored by the formal semantics. Comments should be
while the message is subject to interpretation according
this standard. However, comments must NOT be included
other cases, such as during protocol exchanges with
servers
Comments nest, so that if an unquoted left parenthesis
in a comment string, there must also be a matching
parenthesis. When a comment acts as the delimiter between
sequence of two lexical symbols, such as two atoms, it is lex
ically equivalent with a single SPACE, for the purposes
regenerating the sequence, such as when passing the
onto a mail protocol server. Comments are detected as
only within field-bodies of structured fields
If a comment is to be "folded" onto multiple lines, then
syntax for folding must be adhered to. (See the "
August 13, 1982 - 12 - RFC #822
Standard for ARPA Internet Text
Analysis of Messages" section on "Folding Long Header Fields
above, and the section on "Case Independence" below.)
that the official semantics therefore do not "see"
unquoted CRLFs that are in comments, although particular pars
ing programs may wish to note their presence. For these pro
grams, it would be reasonable to interpret a "CRLF LWSP-char
as being a CRLF that is part of the comment; i.e., the CRLF
kept and the LWSP-char is discarded. Quoted CRLFs (i.e.,
backslash followed by a CR followed by a LF) still must
followed by at least one LWSP-char
3.4.4. DELIMITING AND QUOTING
The quote character (backslash) and characters that
syntactic units are not, generally, to be taken as data
are part of the delimited or quoted unit(s). In particular
the quotation-marks that define a quoted-string,
parentheses that define a comment and the backslash
quotes a following character are NOT part of the quoted
string, comment or quoted character. A quotation-mark that
to be part of a quoted-string, a parenthesis that is to
part of a comment and a backslash that is to be part of
must each be preceded by the quote-character backslash ("\").
Note that the syntax allows any character to be quoted
a quoted-string or comment; however only certain
MUST be quoted to be included as data. These characters
the ones that are not part of the alternate text group (i.e.,
ctext or qtext).
The one exception to this rule is that a single SPACE
assumed to exist between contiguous words in a phrase,
this interpretation is independent of the actual number
LWSP-chars that the creator places between the words.
include more than one SPACE, the creator must make the LWSP
chars be part of a quoted-string
Quotation marks that delimit a quoted string and
that quote the following character should NOT accompany
quoted-string when the string is passed to processes that
not interpret data according to this specification (e.g.,
protocol servers).
3.4.5. QUOTED-
Where permitted (i.e., in words in structured fields) quoted
strings are treated as a single symbol. That is, a quoted
string is equivalent to an atom, syntactically. If a quoted
string is to be "folded" onto multiple lines, then the
for folding must be adhered to. (See the "Lexical Analysis
August 13, 1982 - 13 - RFC #822
Standard for ARPA Internet Text
Messages" section on "Folding Long Header Fields" above,
the section on "Case Independence" below.) Therefore,
official semantics do not "see" any bare CRLFs that are
quoted-strings; however particular parsing programs may
to note their presence. For such programs, it would be rea
sonable to interpret a "CRLF LWSP-char" as being a CRLF
is part of the quoted-string; i.e., the CRLF is kept and
LWSP-char is discarded. Quoted CRLFs (i.e., a backslash fol
lowed by a CR followed by a LF) are also subject to rules
folding, but the presence of the quoting character (backslash
explicitly indicates that the CRLF is data to the
string. Stripping off the first following LWSP-char is
appropriate when parsing quoted CRLFs
3.4.6. BRACKETING
There is one type of bracket which must occur in matched
and may have pairs nested within each other
o Parentheses ("(" and ")") are used to indicate com
ments
There are three types of brackets which must occur in
pairs, and which may NOT be nested
o Colon/semi-colon (":" and ";") are used in
specifications to indicate that the included list
addresses are to be treated as a group
o Angle brackets ("<" and ">") are generally used
indicate the presence of a one machine-usable refer
ence (e.g., delimiting mailboxes), possibly
source-routing to the machine
o Square brackets ("[" and "]") are used to indicate
presence of a domain-literal, which the
name-domain is to use directly, bypassing
name-resolution mechanisms
3.4.7. CASE
Except as noted, alphabetic strings may be represented in
combination of upper and lower case. The only syntactic
August 13, 1982 - 14 - RFC #822
Standard for ARPA Internet Text
which requires preservation of case information are
-
-
-
-
- quoted-
- local-part, except "Postmaster
When matching any other syntactic unit, case is to be ignored
For example, the field-names "From", "FROM", "from", and
"FroM" are semantically equal and should all be treated ident
ically
When generating these units, any mix of upper and lower
alphabetic characters may be used. The case shown in
specification is suggested for message-creating processes
Note: The reserved local-part address unit, "Postmaster",
an exception. When the value "Postmaster" is
interpreted, it must be accepted in any mixture
case, including "POSTMASTER", and "postmaster".
3.4.8. FOLDING LONG HEADER
Each header field may be represented on exactly one line con
sisting of the name of the field and its body, and
by a CRLF; this is what the parser sees. For readability,
field-body portion of long header fields may be "folded"
multiple lines of the actual field. "Long" is commonly inter
preted to mean greater than 65 or 72 characters. The
length serves as a limit, when the message is to be viewed
most simple terminals which use simple display software; how
ever, the limit is not imposed by this standard
Note: Some display software often can selectively fold lines
to suit the display terminal. In such cases, sender
provided folding can interfere with the
software
3.4.9. BACKSPACE
ASCII BS characters (Backspace, decimal 8) may be included
texts and quoted-strings to effect overstriking. However,
use of backspaces which effects an overstrike to the left
the beginning of the text or quoted-string is prohibited
August 13, 1982 - 15 - RFC #822
Standard for ARPA Internet Text
3.4.10. NETWORK-SPECIFIC
During transmission through heterogeneous networks, it may
necessary to force data to conform to a network's local con
ventions. For example, it may be required that a CR be fol
lowed either by LF, making a CRLF, or by , if the CR
to stand alone). Such transformations are reversed, when
message exits that network
When crossing network boundaries, the message should
treated as passing through two modules. It will enter
first module containing whatever network-specific transforma
tions that were necessary to permit migration through
"current" network. It then passes through the modules
o Transformation
The "current" network's idiosyncracies are removed
the message is returned to the canonical form speci
fied in this standard
o
The "next" network's local idiosyncracies are
on the message
------------------
From ==> | Remove Net-A |
Net-A | idiosyncracies |
------------------
||
\/
with
||
\/
------------------
| Impose Net-B | ==>
| idiosyncracies | Net-
------------------
August 13, 1982 - 16 - RFC #822
Standard for ARPA Internet Text
4. MESSAGE
4.1.
Note: Due to an artifact of the notational conventions, the syn
tax indicates that, when present, some fields, must be
a particular order. Header fields are NOT required
occur in any particular order, except that the
body must occur AFTER the headers. It is
that, if present, headers be sent in the order "Return
Path", "Received", "Date", "From", "Subject", "Sender",
"To", "cc", etc
This specification permits multiple occurrences of
fields. Except as noted, their interpretation is
specified here, and their use is discouraged
The following syntax for the bodies of various fields
be thought of as describing each field body as a single
string (or line). The "Lexical Analysis of Message" section
"Long Header Fields", above, indicates how such long strings
be represented on more than one line in the actual
message
message = fields *( CRLF *text ) ; Everything
; first null
; is message
fields = dates ; Creation time
source ; author id &
1*destination ; address
*optional-field ; others
source = [ trace ] ; net
originator ; original
[ resent ] ;
trace = return ; path to
1*received ; receipt
return = "Return-path" ":" route-addr ; return
received = "Received" ":" ; one per
["from" domain] ; sending
["by" domain] ; receiving
["via" atom] ; physical
*("with" atom) ; link/mail
["id" msg-id] ; receiver msg
["for" addr-spec] ; initial
August 13, 1982 - 17 - RFC #822
Standard for ARPA Internet Text
";" date-time ; time
originator = authentic ; authenticated
[ "Reply-To" ":" 1#address] )
authentic = "From" ":" mailbox ; Single
/ ( "Sender" ":" mailbox ; Actual
"From" ":" 1#mailbox) ; Multiple
; or not
resent = resent-
[ "Resent-Reply-To" ":" 1#address] )
resent-authentic =
= "Resent-From" ":"
/ ( "Resent-Sender" ":"
"Resent-From" ":" 1#mailbox )
dates = orig-date ;
[ resent-date ] ;
orig-date = "Date" ":" date-
resent-date = "Resent-Date" ":" date-
destination = "To" ":" 1#address ;
/ "Resent-To" ":" 1#
/ "cc" ":" 1#address ;
/ "Resent-cc" ":" 1#
/ "bcc" ":" #address ; Blind
/ "Resent-bcc" ":" #
optional-field =
/ "Message-ID" ":" msg-
/ "Resent-Message-ID" ":" msg-
/ "In-Reply-To" ":" *(phrase / msg-id
/ "References" ":" *(phrase / msg-id
/ "Keywords" ":" #
/ "Subject" ":" *
/ "Comments" ":" *
/ "Encrypted" ":" 1#2
/ extension-field ; To be
/ user-defined-field ; May be pre-
msg-id = "<" addr-spec ">" ; Unique message
August 13, 1982 - 18 - RFC #822
Standard for ARPA Internet Text
extension-field =
published as a formal extension to
specification; none will have names
with the string "X-">
user-defined-field =
in this specification or published as
extension to this specification; names
such fields must be unique and may
pre-empted by published extensions
4.2.
Some systems permit mail recipients to forward a message
retaining the original headers, by adding some new fields.
standard supports such a service, through the "Resent-" prefix
field names
Whenever the string "Resent-" begins a field name, the
has the same semantics as a field whose name does not have
prefix. However, the message is assumed to have been
by an original recipient who attached the "Resent-" field.
new field is treated as being more recent than the equivalent
original field. For example, the "Resent-From", indicates
person that forwarded the message, whereas the "From" field indi
cates the original author
Use of such precedence information depends upon partici
pants' communication needs. For example, this standard does
dictate when a "Resent-From:" address should receive replies,
lieu of sending them to the "From:" address
Note: In general, the "Resent-" fields should be treated as con
taining a set of information that is independent of
set of original fields. Information for one set
not automatically be taken from the other. The interpre
tation of multiple "Resent-" fields, of the same type,
undefined
In the remainder of this specification, occurrence of
"Resent-" fields are treated identically with the occurrence
August 13, 1982 - 19 - RFC #822
Standard for ARPA Internet Text
fields whose names do not contain this prefix
4.3. TRACE
Trace information is used to provide an audit trail of mes
sage handling. In addition, it indicates a route back to
sender of the message
The list of known "via" and "with" values are
with the Network Information Center, SRI International,
Park, California
4.3.1. RETURN-
This field is added by the final transport system
delivers the message to its recipient. The field is
to contain definitive information about the address and
back to the message's originator
Note: The "Reply-To" field is added by the originator
serves to direct replies, whereas the "Return-Path
field is used to identify a path back to the origina
tor
While the syntax indicates that a route specification
optional, every attempt should be made to provide that infor
mation in this field
4.3.2.
A copy of this field is added by each transport service
relays the message. The information in the field can be
useful for tracing transport problems
The names of the sending and receiving hosts and time-of
receipt may be specified. The "via" parameter may be used,
indicate what physical mechanism the message was sent over
such as Arpanet or Phonenet, and the "with" parameter may
used to indicate the mail-, or connection-, level
that was used, such as the SMTP mail protocol, or X.25 tran
sport protocol
Note: Several "with" parameters may be included, to
specify the set of protocols that were used
Some transport services queue mail; the internal message iden
tifier that is assigned to the message may be noted, using
"id" parameter. When the sending host uses a
address specification that the receiving host reinterprets,
August 13, 1982 - 20 - RFC #822
Standard for ARPA Internet Text
expansion or transformation, the receiving host may wish
record the original specification, using the "for" parameter
For example, when a copy of mail is sent to the member of
distribution list, this parameter may be used to record
original address that was used to specify the list
4.4. ORIGINATOR
The standard allows only a subset of the combinations possi
ble with the From, Sender, Reply-To, Resent-From, Resent-Sender
and Resent-Reply-To fields. The limitation is intentional
4.4.1. FROM / RESENT-
This field contains the identity of the person(s) who
this message to be sent. The message-creation process
default this field to be a single, authenticated
address, indicating the AGENT (person, system or process
entering the message. If this is not done, the "Sender"
MUST be present. If the "From" field IS defaulted this way
the "Sender" field is optional and is redundant with
"From" field. In all cases, addresses in the "From"
must be machine-usable (addr-specs) and may not contain
lists (groups).
4.4.2. SENDER / RESENT-
This field contains the authenticated identity of the
(person, system or process) that sends the message. It
intended for use when the sender is not the author of the mes
sage, or to indicate who among a group of authors
sent the message. If the contents of the "Sender" field
be completely redundant with the "From" field, then
"Sender" field need not be present and its use is
(though still legal). In particular, the "Sender" field
be present if it is NOT the same as the "From" Field
The Sender mailbox specification includes a word
which must correspond to a specific agent (i.e., a human
or a computer program) rather than a standard address.
indicates the expectation that the field will identify
single AGENT (person, system, or process) responsible
sending the mail and not simply include the name of a
from which the mail was sent. For example in the case of
shared login name, the name, by itself, would not be adequate
The local-part address unit, which refers to this agent,
expected to be a computer system term, and not (for example)
generalized person reference which can be used outside
network text message context
August 13, 1982 - 21 - RFC #822
Standard for ARPA Internet Text
Since the critical function served by the "Sender" field
identification of the agent responsible for sending mail
since computer programs cannot be held accountable for
behavior, it is strongly recommended that when a computer pro
gram generates a message, the HUMAN who is responsible
that program be referenced as part of the "Sender" field mail
box specification
4.4.3. REPLY-TO / RESENT-REPLY-
This field provides a general mechanism for indicating
mailbox(es) to which responses are to be sent. Three
uses for this feature can be distinguished. In the
case, the author(s) may not have regular machine-based mail
boxes and therefore wish(es) to indicate an alternate
address. In the second case, an author may wish
persons to be made aware of, or responsible for, replies.
somewhat different use may be of some help to "text
teleconferencing" groups equipped with automatic
services: include the address of that service in the "Reply
To" field of all messages submitted to the teleconference
then participants can "reply" to conference submissions
guarantee the correct distribution of any submission of
own
Note: The "Return-Path" field is added by the mail
service, at the time of final deliver. It is
to identify a path back to the orginator of the mes
sage. The "Reply-To" field is added by the
originator and is intended to direct replies
4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-
For systems which automatically generate address lists
replies to messages, the following recommendations are made
o The "Sender" field mailbox should be sent notices
any problems in transport or delivery of the
messages. If there is no "Sender" field, then
"From" field mailbox should be used
o The "Sender" field mailbox should NEVER be
automatically, in a recipient's reply message
o If the "Reply-To" field exists, then the reply
go to the addresses indicated in that field and not
the address(es) indicated in the "From" field
August 13, 1982 - 22 - RFC #822
Standard for ARPA Internet Text
o If there is a "From" field, but no "Reply-To" field
the reply should be sent to the address(es)
in the "From" field
Sometimes, a recipient may actually wish to communicate
the person that initiated the message transfer. In
cases, it is reasonable to use the "Sender" address
This recommendation is intended only for automated use
originator-fields and is not intended to suggest that
may not also be sent to other recipients of messages. It
up to the respective mail-handling programs to decide
additional facilities will be provided
Examples are provided in Appendix A
4.5. RECEIVER
4.5.1. TO / RESENT-
This field contains the identity of the primary recipients
the message
4.5.2. CC / RESENT-
This field contains the identity of the secondary (informa
tional) recipients of the message
4.5.3. BCC / RESENT-
This field contains the identity of additional recipients
the message. The contents of this field are not included
copies of the message sent to the primary and secondary reci
pients. Some systems may choose to include the text of
"Bcc" field only in the author(s)'s copy, while others
also include it in the text sent to all those indicated in
"Bcc" list
4.6. REFERENCE
4.6.1. MESSAGE-ID / RESENT-MESSAGE-
This field contains a unique identifier (the local-
address unit) which refers to THIS version of THIS message
The uniqueness of the message identifier is guaranteed by
host which generates it. This identifier is intended to
machine readable and not necessarily meaningful to humans.
message identifier pertains to exactly one instantiation of
particular message; subsequent revisions to the message
August 13, 1982 - 23 - RFC #822
Standard for ARPA Internet Text
each receive new message identifiers
4.6.2. IN-REPLY-
The contents of this field identify previous correspon
dence which this message answers. Note that if message iden
tifiers are used in this field, they must use the msg-
specification format
4.6.3.
The contents of this field identify other
which this message references. Note that if message identif
iers are used, they must use the msg-id specification format
4.6.4.
This field contains keywords or phrases, separated
commas
4.7. OTHER
4.7.1.
This is intended to provide a summary, or indicate
nature, of the message
4.7.2.
Permits adding text comments onto the message
disturbing the contents of the message's body
4.7.3.
Sometimes, data encryption is used to increase
privacy of message contents. If the body of a message
been encrypted, to keep its contents private, the "Encrypted
field can be used to note the fact and to indicate the
of the encryption. The first parameter indicates
software used to encrypt the body, and the second,
is intended to aid the recipient in selecting
proper decryption key. This code word may be viewed as
index to a table of keys held by the recipient
Note: Unfortunately, headers must contain envelope, as
as contents, information. Consequently, it is neces
sary that they remain unencrypted, so that mail tran
sport services may access them. Since names
addresses, and "Subject" field contents may
August 13, 1982 - 24 - RFC #822
Standard for ARPA Internet Text
sensitive information, this requirement limits
message privacy
Names of encryption software are registered with the Net
work Information Center, SRI International, Menlo Park, Cali
fornia
4.7.4. EXTENSION-
A limited number of common fields have been defined
this document. As network mail requirements dictate, addi
tional fields may be standardized. To provide user-
fields with a measure of safety, in name selection,
extension-fields will never have names that begin with
string "X-".
Names of Extension-fields are registered with the
Information Center, SRI International, Menlo Park, California
4.7.5. USER-DEFINED-
Individual users of network mail are free to define
use additional header fields. Such fields must have
which are not already used in the current specification or
any definitions of extension-fields, and the overall syntax
these user-defined-fields must conform to this specification'
rules for delimiting and folding fields. Due to
extension-field publishing process, the name of a user
defined-field may be pre-
Note: The prefatory string "X-" will never be used in
names of Extension-fields. This provides user-
fields with a protected set of names
August 13, 1982 - 25 - RFC #822
Standard for ARPA Internet Text
5. DATE AND TIME
5.1.
date-time = [ day "," ] date time ; dd mm
; hh:mm:ss
day = "Mon" / "Tue" / "Wed" / "Thu
/ "Fri" / "Sat" / "Sun
date = 1*2DIGIT month 2DIGIT ; day month
; e.g. 20 Jun 82
month = "Jan" / "Feb" / "Mar" / "Apr
/ "May" / "Jun" / "Jul" / "Aug
/ "Sep" / "Oct" / "Nov" / "Dec
time = hour zone ; ANSI and
hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT
; 00:00:00 - 23:59:59
zone = "UT" / "GMT" ; Universal
; North American :
/ "EST" / "EDT" ; Eastern: - 5/ - 4
/ "CST" / "CDT" ; Central: - 6/ - 5
/ "MST" / "MDT" ; Mountain: - 7/ - 6
/ "PST" / "PDT" ; Pacific: - 8/ - 7
/ 1ALPHA ; Military: Z = UT
; A:-1; (J not used
; M:-12; N:+1; Y:+12
/ ( ("+" / "-") 4DIGIT ) ; Local
; hours+min. (HHMM
5.2.
If included, day-of-week must be the day implied by the
specification
Time zone may be indicated in several ways. "UT" is Univer
sal Time (formerly called "Greenwich Mean Time"); "GMT" is per
mitted as a reference to Universal Time. The military
uses a single character for each zone. "Z" is Universal Time
"A" indicates one hour earlier, and "M" indicates 12 hours ear
lier; "N" is one hour later, and "Y" is 12 hours later.
letter "J" is not used. The other remaining two forms are
from ANSI standard X3.51-1975. One allows explicit indication
the amount of offset from UT; the other uses common 3-
strings for indicating time zones in North America
August 13, 1982 - 26 - RFC #822
Standard for ARPA Internet Text
6. ADDRESS
6.1.
address = mailbox ; one
/ group ; named
group = phrase ":" [#mailbox] ";"
mailbox = addr-spec ; simple
/ phrase route-addr ; name & addr-
route-addr = "<" [route] addr-spec ">"
route = 1#("@" domain) ":" ; path-
addr-spec = local-part "@" domain ; global
local-part = word *("." word) ;
; case-
domain = sub-domain *("." sub-domain
sub-domain = domain-ref / domain-
domain-ref = atom ; symbolic
6.2.
A mailbox receives mail. It is a conceptual entity
does not necessarily pertain to file storage. For example,
sites may choose to print mail on their line printer and
the output to the addressee's desk
A mailbox specification comprises a person, system or pro
cess name reference, a domain-dependent string, and a name-
reference. The name reference is optional and is usually used
indicate the human name of a recipient. The name-domain refer
ence specifies a sequence of sub-domains. The domain-
string is uninterpreted, except by the final sub-domain; the
of the mail service merely transmits it as a literal string
6.2.1.
A name-domain is a set of registered (mail) names. A name
domain specification resolves to a subordinate name-
specification or to a terminal domain-dependent string
Hence, domain specification is extensible, permitting
number of registration levels
August 13, 1982 - 27 - RFC #822
Standard for ARPA Internet Text
Name-domains model a global, logical, hierarchical
scheme. The model is logical, in that an address specifica
tion is related to name registration and is not
tied to transmission path. The model's hierarchy is
directed graph, called an in-tree, such that there is a
path from the root of the tree to any node in the hierarchy
If more than one path actually exists, they are considered
be different addresses
The root node is common to all addresses; consequently, it
not referenced. Its children constitute "top-level" name
domains. Usually, a service has access to its own full
specification and to the names of all top-level name-domains
The "top" of the domain addressing hierarchy -- a child of
root -- is indicated by the right-most field, in a
specification. Its child is specified to the left, its
to the left, and so on
Some groups provide formal registration services; these con
stitute name-domains that are independent logically
specific machines. In addition, networks and machines impli
citly compose name-domains, since their membership usually
registered in name tables
In the case of formal registration, an organization
a (distributed) data base which provides an address-to-
mapping service for addresses of the form
person@registry.
Note that "organization" is a logical entity, separate
any particular communication network
A mechanism for accessing "organization" is universally avail
able. That mechanism, in turn, seeks an instantiation of
registry; its location is not indicated in the address specif
ication. It is assumed that the system which operates
the name "organization" knows how to find a subordinate regis
try. The registry will then use the "person" string to deter
mine where to send the mail specification
The latter, network-oriented case permits simple, direct
attachment-related address specification, such as
user@host.
Once the network is accessed, it is expected that a
will go directly to the host and that the host will
August 13, 1982 - 28 - RFC #822
Standard for ARPA Internet Text
the user name, placing the message in the user's mailbox
6.2.2. ABBREVIATED DOMAIN
Since any number of levels is possible within the
hierarchy, specification of a fully qualified address
become inconvenient. This standard permits abbreviated
specification, in a special case
For the address of the sender, call the left-
sub-domain Level N. In a header address, if all
the sub-domains above (i.e., to the right of) Level
are the same as those of the sender, then they do
have to appear in the specification. Otherwise,
address must be fully qualified
This feature is subject to approval by local sub
domains. Individual sub-domains may require
member systems, which originate mail, to provide
domain specification only. When permitted, abbrevia
tions may be present only while the message
within the sub-domain of the sender
Use of this mechanism requires the sender's sub-
to reserve the names of all top-level domains, so
full specifications can be distinguished from abbrevi
ated specifications
For example, if a sender's address is
sender@registry-A.registry-1.organization-
and one recipient's address is
recipient@registry-B.registry-1.organization-
and another's is
recipient@registry-C.registry-2.organization-
then ".registry-1.organization-X" need not be specified in
the message, but "registry-C.registry-2" DOES have to
specified. That is, the first two addresses may be abbrevi
ated, but the third address must be fully specified
When a message crosses a domain boundary, all addresses
be specified in the full format, ending with the top-
name-domain in the right-most field. It is the
of mail forwarding services to ensure that addresses
August 13, 1982 - 29 - RFC #822
Standard for ARPA Internet Text
with this requirement. In the case of abbreviated addresses
the relaying service must make the necessary expansions.
should be noted that it often is difficult for such a
to locate all occurrences of address abbreviations. For exam
ple, it will not be possible to find such abbreviations
the body of the message. The "Return-Path" field can
recipients in recovering from these errors
Note: When passing any portion of an addr-spec onto a
which does not interpret data according to this stan
dard (e.g., mail protocol servers). There must be
LWSP-chars preceding or following the at-sign or
delimiting period ("."), such as shown in the
examples, and only ONE SPACE between
s
6.2.3. DOMAIN
A domain-ref must be THE official name of a registry, network
or host. It is a symbolic reference, within a name sub
domain. At times, it is necessary to bypass standard mechan
isms for resolving such references, using more
information, such as a network host address rather than
associated host name
To permit such references, this standard provides the domain
literal construct. Its contents must conform with the
of the sub-domain in which it is interpreted
Domain-literals which refer to domains within the ARPA Inter
net specify 32-bit Internet addresses, in four 8-bit
noted in decimal, as described in Request for Comments #820,
"Assigned Numbers." For example
[10.0.3.19]
Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.
is permitted only as a means of bypassing
system limitations, such as name tables which are
complete
The names of "top-level" domains, and the names of
under in the ARPA Internet, are registered with the
Information Center, SRI International, Menlo Park, California
6.2.4. DOMAIN-DEPENDENT LOCAL
The local-part of an addr-spec in a mailbox
(i.e., the host's name for the mailbox) is understood to
August 13, 1982 - 30 - RFC #822
Standard for ARPA Internet Text
whatever the receiving mail protocol server allows. For exam
ple, some systems do not understand mailbox references of
form "P. D. Q. Bach", but others do
This specification treats periods (".") as lexical separators
Hence, their presence in local-parts which are not quoted
strings, is detected. However, such occurrences carry
semantics. That is, if a local-part has periods within it,
address parser will divide the local-part into several tokens
but the sequence of tokens will be treated as one uninter
preted unit. The sequence will be re-assembled, when
address is passed outside of the system such as to a mail pro
tocol service
For example, the address
First.Last@Registry.
is legal and does not require the local-part to be
with quotation-marks. (However, "First Last" DOES
quoting.) The local-part of the address, when passed
of the mail system, within the Registry.Org domain,
"First.Last", again without quotation marks
6.2.5. BALANCING LOCAL-PART AND
In some cases, the boundary between local-part and domain
be flexible. The local-part may be a simple string, which
used for the final determination of the recipient's mailbox
All other levels of reference are, therefore, part of
domain
For some systems, in the case of abbreviated reference to
local and subordinate sub-domains, it may be possible
specify only one reference within the domain part and
the other, subordinate name-domain references within
local-part. This would appear as
mailbox.sub1.sub2@this-
Such a specification