Network Working Group                                   P. Resnick, Editor
Internet-Draft                                          QUALCOMM Incorporated
<draft-ietf-drums-msg-fmt-00.txt>                       25 November 1996

Message Format Standard

. Status of this memo

This document is an Internet-Draft. Internet-Drafts are working documents of
the Internet Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working documents as
Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may
be updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite them
other than as "work in progress."

To learn the current status of any Internet-Draft, please check the "1id-
abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on
ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

. Introduction

1.1 Scope

This standard specifies a syntax for text messages that are sent between
computer users, within the framework of "electronic mail" messages. This
standard supersedes the one specified in Request For Comments 822, "Standard
for the Format of ARPA Internet Text Messages".

This standard only specifies a syntax for text messages. In particular, it
makes no provision for the transmission of images, audio, or other sorts of
structured data in electronic mail messages. There are several extensions
published, such as the MIME document series [MIME-IMT, MIME-IMB], which
describe mechanisms for the transmission of such data through electronic
mail, either by extending the syntax provided here or by structuring such
messages to conform to this syntax. These mechanisms are outside of the scope
of this standard.

In the context of electronic mail, messages are viewed as having an envelope
and contents. The envelope contains whatever information is needed to
accomplish transmission and delivery. (See [SMTP] for a discussion of the
envelope.) The contents compose the object to be delivered to the recipient.
This standard applies only to the format and some of the semantics of message
contents. It contains no specification of the information in the envelope.

However, some message systems may use information from the contents to create
the envelope. It is intended that this standard facilitate the acquisition of
such information by programs.

Some message systems may store messages in formats that differ from the one
specified in this standard. This specification is intended strictly as a
definition of what message content format is to be passed BETWEEN hosts.

Note: This standard is NOT intended to dictate the internal formats used by
sites, the specific message system features that they are expected to
support, or any of the characteristics of user interface programs that create
or read messages. In addition, this standard does not specify an encoding of
the characters for either transport or storage; that is, it does not specify
the number of bits used or how those bits are specifically transferred over
the wire or stored on disk.

1.2 Notational conventions

1.2.1 Requirements notation

This document occasionally uses terms that appear in capital letters. When
the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY" appear
capitalized, they are being used to indicate particular requirements of this
specification. A discussion of the meanings of these terms appears in [KEY-
WORDS] [Editor's note: <draft-bradner-key-words-02.txt>].

1.2.2 Syntactic notation

This standard uses the Augmented Backus-Naur Form notation specified in
[ABNF] for the formal definitions of the syntax of messages. Characters will
be specified either by a decimal value (e.g. the value 65 for uppercase A) or
by a literal value enclosed in quotation marks (e.g. "A" for uppercase A).

1.3 Structure of this document

This document is divided into several sections.

This section, section 1, is a short introduction to the document.

Section 2 will lay out the general description of a message and its
constituent parts. This is an overview to help the reader understand some of
the general principles used in the later portions of this document. Any
examples in this section MUST NOT be taken as specification of the formal
syntax of any part of a message.

Section 3 will give the formal syntax and semantics for each of the parts of
a message. That is, it will describe the actual rules for the structure of
each part of a message (the syntax) as well as a description of the parts and
instructions on how they ought to be interpreted (the semantics). This will
include analysis of the syntax and semantics of subparts of messages which
have specific structure. The syntax included in section 3 represents messages
as they MUST be created. There are also notes in section 3 to indicate if any
of the options specified in the syntax SHOULD be used over any of the others.

Section 4 of this document specifies an "obsolete" syntax. There are
references in section 3 to these obsolete syntactic elements. The obsolete
syntax are elements that have appeared in earlier revisions of this standard
or have previously been widely used in Internet messages. As such, these
elements MUST be interpreted by parsers of messages in order to be conformant
to this standard. However, since items in this syntax have been determined to
be non-interoperable or cause significant problems for recipients of
messages, they MUST NOT be generated by creators of conformant messages.

Section 5 details security considerations to take into account when
implementing this standard.

Section 6 is a bibliography of references in this document.

Section 7 contains the author's address and instructions on where to send
comments.

Section 8 contains acknowledgements.

Appendix A lists examples of different sorts of messages. These examples are
not exhaustive of the types of messages that appear on the Internet, but give
a broad overview of certain syntactic forms.

Appendix B lists the differences between this standard and earlier standards
for Internet messages.

. Lexical Analysis of Messages

2.1 General Description

At the most basic level, a message is a series of characters. A message that
is conformant with this standard is comprised of characters with values in
the range 1 through 127 and interpreted as US-ASCII characters [ASCII]. For
brevity, this document sometimes refers to this range of characters as simply
"US-ASCII characters". Messages are divided into lines of characters. A line
is a series of characters which is delimited with the two characters
carriage-return and line-feed; that is, the carriage return (CR) character
(ASCII value 13) followed immediately by the line feed (LF) character (ASCII
value 10). (The carriage-return/line-feed pair is usually written in this
document as "CRLF".)

Note: This standard specifies that messages are made up of characters in the
US-ASCII range of 1 through 127. There are other documents, specifically the
MIME document series [MIME-IMT, MIME-IMB], which extend this standard to
allow for values outside of that range. Discussion of these mechanisms is not
within the scope of this standard.

[Editor's note: Discussion to be had on the above.]

A message consists of header fields (collectively called the header of the
message) followed, optionally, by a body. The header is a sequence of lines
of characters with special syntax as defined in this standard. The body is
simply a sequence of characters that follows the headers and is separated
from the headers by an empty line (i.e., a line with nothing preceding the
CRLF).

2.2 Headers Fields

Header fields are lines which have a specific syntax. Header fields are all
composed of a field name, followed by a colon (":"), followed by either a
space (SPACE, ASCII value 32) or a horizontal tab (HTAB, ASCII value 9)
character, followed by a field body, and terminated by CRLF. A field name
must be composed of printable US-ASCII characters (i.e., characters that have
values between 33 and 126, except colon). A field body may be composed of any
US-ASCII characters, except for CR and LF. However, a field body may contain
CRLF when used in header "folding" and "unfolding" as described in section
2.2.3. All field bodies must conform to the syntax described in sections 3
and 4 of this standard.

2.2.1 Unstructured Header Field Bodies

Some field bodies in this standard are defined simply as "unstructured"
(which is specified below as any US-ASCII characters, except for CR and LF)
with no further restrictions. These are referred to as unstructured field
bodies. Semantically, unstructured field bodies are simply to be treated as a
single line of characters with no further processing (except for header
"folding" and "unfolding" as described in section 2.2.3).

2.2.2 Structured Header Field Bodies

Some field bodies in this standard have specific lexical structure more
restrictive than the unstructured field bodies described above. These are
referred to as "structured" field bodies. Structured field bodies are lines
of specific lexical tokens as described in sections 3 and 4 of this standard.
Many of these tokens are allowed (according to their syntax) to be freely
surrounded by SPACE and HTAB characters, and those surrounding SPACE and HTAB
characters are subject to header "folding" and "unfolding" as described in
section 2.2.3. Semantic analysis of structured field bodies is given along
with their syntax.

2.2.3 Long Header Fields

Each header is logically a single line of characters comprising the field
name, the colon, the SPACE or HTAB, and the field body. For convenience
however, the field body portion of a header can be split into a multiple line
representation; this is called "folding". The general rule is that wherever
this standard allows for folding white-space (not simply SPACE or HTAB, but
the "FWS" rule for folding white-space), a CRLF followed by AT LEAST one
SPACE or HTAB may instead be inserted. For example, the header:

        Subject: This is a test

can be represented as:

        Subject: This
         is a test

Note: Though structured field bodies are defined in such a way that folding
can take place between many of the lexical tokens, folding SHOULD be limited
to placing the CRLF at higher-level syntactic breaks. For instance, if a
field body is defined as comma-separated values, it is recommended that
folding occur after the comma separating the structured items, even if it is
allowed elsewhere.

The process of moving from this folded multiple-line representation of a
header field to its single line representation is called "unfolding".
Unfolding is accomplished by simply removing any CRLF that is immediately
followed by SPACE or HTAB. Each header should be treated in its unfolded form
for syntactic and semantic evaluation.

2.3 Body

The body of a message is simply lines of US-ASCII characters. The only two
limitations on the body are as follows:

- CR and LF MUST only occur together as CRLF; they MUST NOT appear
independently in the body.

- Lines of characters in the body MUST be limited to 998 characters, and
SHOULD be limited to 80 characters, excluding the CRLF.

Note: As was stated earlier, there are other standards documents,
specifically the MIME documents [MIME-IMT, MIME-IMB] which extend this
standard to allow for different sorts of message bodies. Again, these
mechanisms are beyond the scope of this document.

. Syntax

[Editor's note: What appears in here vs. what appears in the obsolete syntax
is certainly up for debate. There are certain items currently in the SHOULD
NOT generate but MUST accept category that could be pushed into the MUST NOT
generate category, and thus into the obsolete section. I've occasionally made
some random decisions on this topic, so please keep an eye out and yelp if
you think I'm way off. Do check the obsolete section to see whether the
things I have as MUST NOT generate/MUST accept are acceptable.]

3.1 Introduction

The syntax as given in this section defines the legal syntax of Internet
messages. Messages which are conformant to this standard MUST conform to the
syntax in this section. If there are options in this section where one option
SHOULD be generated, that is indicated either in the prose or in a comment
next to the syntax.

For the defined tokens, a short description of the syntax and use is given,
followed by the syntax in ABNF, followed by a semantic analysis. Primitive
tokens that are used but otherwise unspecified come from [ABNF].

3.2 Lexical Tokens

The following rules are used to define an underlying lexical analyzer, which
feeds tokens to the higher level parsers. This section is basically devoted
to defining tokens used in structured header field bodies.

3.2.1 Primitive Tokens

The following are primitive tokens referred to elsewhere this standard, but
are not otherwise defined in [ABNF]. Some of them will not appear anywhere
else in the syntax, but they are convenient to refer to in other parts of
this document.

CTL             =       1..31 / 127     ; Control characters, inc. delete

NO-WS-CTL       =       1..8 /          ; US-ASCII control characters
                        11 /            ;  which do not include the
                        12 /            ;  carriage return, linefeed
                        14..31 / 127    ;  space, and tab characters

<">             =       34              ; Quote mark

text            =       1..9 / 11..12 / ; Characters excluding CR and LF
                        14..127

specials        =       "(" / ")" /     ; Special characters used in other
                        "<" / ">" /     ;  parts of the syntax
                        "[" / "]" /
                        ":" / ";" /
                        <"> / "\" /
                        "," / "." /
                        "@"

No special semantics attaches to these tokens. They are simply single
characters.

3.2.2 Quoted characters

Some characters are reserved for special interpretation, such as delimiting
lexical tokens. To permit use of these characters as uninterpreted data, a
quoting mechanism is provided.

quoted-pair     =       "\" text / obs-qp

Where any quoted-pair appears, it should be interpreted as the text character
alone.

3.2.3 Whitespace

The following define the white-space characters used in this standard.

WS              =       SPACE / HTAB
FWS             =       1*([CRLF] WS)   ; Folding white-space

Throughout this standard, where FWS (the folding white-space token) appears,
it indicates a place where header folding, as discussed in section 2.2.3, may
take place. Wherever header folding appears in a message (that is, a header
field body containing a CRLF followed by any WS), header unfolding (removal
of the CRLF) should be performed before any further lexical analysis is
performed on that header according to this standard. That is to say, any CRLF
that appears in FWS is semantically "invisible."

Runs of FWS are semantically interpreted as identical to single SPACE
character.

3.2.4 Comments

Strings of characters which are treated as comments may be included in
structured field bodies as characters enclosed in parenthesis. Strings of
characters enclosed in parenthesis are considered comments so long as they do
not appear within a "quoted-string", as defined in section 3.2.6. Comments
may nest. Though all of the characters listed in ctext below MAY be used, NO-
WS-CTL US-ASCII control characters noted below SHOULD NOT be used.

There are several places in this standard where comments and FWS may be
freely inserted. To accommodate that syntax, an additional token for "CFWS"
is defined for places where comments and/or FWS can occur.

ctext           =       NO-WS-CTL /     ; Non-white-space controls

                        33..39 /        ; The rest of the US-ASCII
                        42..91 /        ;  characters not including "(",
                        93..127         ;  ")", or "\"

comment         =       "(" *(ctext / FWS /quoted-pair / comment) ")"

CFWS            =       comment / FWS

A comment is normally used in a structured field body to provide some human
readable informational text. A comment is semantically interpreted as a
single SPACE. Since a comment is allowed to contain FWS, folding is
permitted. Also note that since quoted-pair is allowed in a comment, the
parentheses and backslash characters may appear in a comment so long as they
appear as a quoted-pair. Semantically, the enclosing parentheses are not part
of the comment token; the token is what is contained between the two
parentheses.

Runs of CFWS are semantically interpreted as a single space.

3.2.5 Atom

Several tokens in structured header field bodies are simply strings of
certain basic characters. Such tokens are represented as atoms. Two atoms
must be separated by some other token, since putting two atoms next to each
other would create a single atom.

Some of the structured header field bodies also allow the period character
(".", ASCII value 46) within runs of atext. An additional "dot-atom" token is
defined for those purposes.

atext           =       ALPHA / DIGIT / ; Any character except CTL,
                        "!" / "#" /     ;  SPACE, and specials.
                        "$" / "%" /     ;  Used for atoms
                        "&" / "'" /
                        "*" / "+" /
                        "-" / "/" /
                        "=" / "?" /
                        "^" / "_" /
                        "`" / "{" /
                        "|" / "}" /
                        "~"

atom            =       *CFWS 1*atext *CFWS

dot-atom        =       *CFWS 1*(atext ["." atext]) *CFWS

Both atom and dot-atom are interpreted as a single unit, comprised of the
string of characters that make it up. Semantically, the optional comments and
FWS surrounding the rest of the characters are not part of the token; the
token is only the run of atext characters in an atom, or the atext and "."
characters in a dot-atom.

3.2.6 Quoted strings

Strings of characters which include characters other than those allowed in
atoms may be represented in a quoted string format, where the characters are
surrounded by the quote character. Though all of the characters listed in
qtext below MAY be used, the NO-WS-CTL US-ASCII control characters noted
below SHOULD NOT be used.

qtext           =       NO-WS-CTL /     ; Non-white-space controls

                        33 /            ; The rest of the US-ASCII
                        35..91 /        ;  characters not including "\"
                        93..127         ;  or the quote character

quoted-string   =       *CFWS <"> *(qtext / FWS /quoted-pair) <"> *CFWS

A quoted-string is treated as a single symbol. That is, quoted-string is
identical to atom, semantically. Since a quoted-string is allowed to contain
FWS, folding is permitted. Also note that since quoted-pair is allowed in a
quoted-string, the quote and backslash characters may appear in a quoted-
string so long as they appear as a quoted-pair. Semantically, neither the
optional CFWS nor the quote characters are part of the quoted-string token;
the token is what is contained between the two quote characters.

3.2.7 Domain Literals

For use in certain types of addresses as described in section 3.4.1, a domain
literal token is defined. Though all of the characters listed in dtext below
MAY be used, NO-WS-CTL US-ASCII control characters noted below SHOULD NOT be
used.

dtext           =       NO-WS-CTL /     ; Non-white-space controls

                        33..90 /        ; The rest of the US-ASCII
                        94..127         ;  characters not including "[",
                                        ;  "]", or "\"

domain-literal  =       *CFWS "[" *(dtext / FWS /quoted-pair) "]" *CFWS

The semantic interpretation of domain-literal is discussed in section 3.4.1
on addressing. Since a domain-literal is allowed to contain FWS, folding is
permitted. Also note that since quoted-pair is allowed in a domain-literal,
the square brackets and backslash characters may appear in a domain-literal
so long as they appear as a quoted-pair. Semantically, the optional comments
or FWS surrounding the square brackets are not part of the domain-literal
token; the token is the two square brackets and what is between them.

3.2.8 Miscellaneous tokens

Three additional tokens are defined, word and phrase for combinations of
atoms and/or quoted-strings, and unstructured for use in unstructured field
headers and in some places within structured field headers.

word            =       atom / quoted-string

phrase          =       1*word

unstructured    =       *(text / FWS) / obs-unstruct

3.3 Date and Time Specification

[Editor note: As per some suggestions, this spec. for date-time does *not*
allow for free insertion of CFWS. If people think it should, this should be
discussed.]

Date and time occur in several header fields of a message. This section
specifies the syntax for a full date and time specification.

date-time       =       *CFWS [ day "," SPACE ] date SPACE time *CFWS /
                        obs-date-time

day-of-week     =       "Mon" / "Tue" / "Wed" / "Thu" /
                        "Fri" / "Sat" / "Sun"

date            =       1*2DIGIT SPACE month SPACE 4DIGIT

month           =       "Jan" / "Feb" / "Mar" / "Apr" /
                        "May" / "Jun" / "Jul" / "Aug" /
                        "Sep" / "Oct" / "Nov" / "Dec"

time            =       hour SPACE zone

hour            =       2DIGIT ":" 2DIGIT [ ":" 2DIGIT ]

zone            =       ( "+" / "-" ) 4DIGIT

The first one or two digits in the date are the numeric day of the month.
Numeric days of the month numbered 1 through 9 SHOULD NOT be zero-padded or
space-padded.

The year is any numeric year in the common era.

The hour specifies the number of hours, minutes, and optionally seconds since
midnight of the date indicated.

The zone specifies the offset from Coordinated Universal Time (UTC, formerly
referred to as "Greenwich Mean Time") that the date and hour represent. The
"+" or "-" indicates whether the time is ahead of or behind Universal Time.
The first two digits indicate the number of hours difference from Universal
Time. The last two digits indicate the number of minutes difference from
Universal Time. The form "+0000" SHOULD be used to indicate a time zone at
Universal Time. Though "-0000" also indicates Universal Time, it is used to
indicate that the time was generated on a system that may be in a local time
zone other than Universal Time.

A date-time specification MUST be semantically valid. That is, the day-of-the
week (if included) MUST be the day implied by the date, the numeric day-of-
month MUST be within the number of days allowed for the specified month (in
the specified year), the hour MUST be in the range 00:00:00 through 23:59:59,
and the zone MUST be within the range -2359 through +2359.

3.4 Address Specification

Addresses occur in several message headers to indicate senders and recipients
of messages. An address may either be an individual mailbox, or a group of
mailboxes.

address         =       mailbox / group

mailbox         =       [phrase] *CFWS "<" addr-spec ">" *CFWS /
                        addr-spec /
                        obs-mailbox

group           =       phrase ":" #mailbox ";" *CFWS

A mailbox receives mail. It is a conceptual entity which does not necessarily
pertain to file storage. For example, some sites may choose to print mail on
a printer and deliver the output to the addressee's desk. Normally, a mailbox
is comprised of two parts: (1) an optional name reference which indicates the
name of the recipient (which could be a person or a system) , and (2) a name-
domain address (referred to as an "addr-spec") enclosed in angle brackets
("<" and ">"). There is also an alternate simple form of a mailbox where the
name-domain address appears alone, without the angle brackets. The Internet
name-domain address is described in section 3.4.1.

When it is desirable to treat several mailboxes as a single unit (i.e. in a
distribution list), the group construct can be used. The group construct
allows the sender to indicate a named group of recipients. This is done by
giving a group name, followed by a colon, followed by a comma separated list
of any number of mailboxes (including zero and one), and ending with a
semicolon. Because the list of mailboxes can be empty, using the group
construct is also a simple way to indicate in the message that a set of
recipients were sent the message without actually providing the individual
mailbox addresses for each of the recipients.

3.4.1 Name-domain specification

A name-domain is a specific Internet identifier that contains both a locally
interpreted string followed by the at-sign character ("@", ASCII value 64)
followed by an Internet domain. For historical reasons, the token is named
addr-spec. [Editor's note: Someone want to back me up on that?] The locally
interpreted string is either a quoted-string or a dot-atom. If the string can
be represented as a dot-atom (that is, it contains no characters other than
atext characters or "." surrounded by atext characters), then the dot-atom
form SHOULD be used and the quoted-string form SHOULD NOT be used.

addr-spec       =       local-part "@" domain

local-part      =       dot-atom / quoted-string / obs-local-part

domain          =       dot-atom / domain-literal / obs-domain

The domain portion is a fully qualified identifier for an Internet host. For
example, in a mailbox address, it is the host on which the particular mailbox
resides. In the dot-atom form, this is interpreted as an Internet domain name
(either a host name or a mail exchanger name) as described in [DNS]. In the
domain-literal form, the domain is interpreted as the literal Internet
address of the particular host. In both cases, how addressing is used and how
messages are transported to a particular named host is covered in the mail
transport document [SMTP]. These mechanisms are outside of the scope of this
document.

The local-part portion is a domain dependent string. In addresses, it is
simply interpreted on the particular host as a name of a particular mailbox.
In a message identifier (described in section 3.6.4), it is an indentifying
string that is unique to a message generated on a particular host. It is
otherwise uninterpreted in this standard.

3.5 Overall message syntax

A message consists of header fields, optionally followed by a message body.
In a message body, though all of the characters listed in the text rule MAY
be used, the US-ASCII control characters(values 1 through 8, 11, 12, and 14
through 31) SHOULD NOT be used. Also, though the lines in the body MAY be a
maximum of 998 characters excluding the CRLF, lines SHOULD be limited to 78
characters excluding the CRLF.

message         =       (fields / obs-fields)
                        [CRLF body]

body            =       *(*998text CRLF) *998text / obs-body

The header fields carry most of the semantic information and are defined in
section 3.6. The body is simply a series of lines of text which are
uninterpreted for the purposes of this standard.

3.6 Field definitions

The header fields of a message are defined here. All header fields have the
same general syntactic structure: A field name, followed by a colon, followed
by either SPACE or HTAB, followed by the field body. The specific syntax for
each header field is defined in the subsequent sections.

Note: In the ABNF syntax for each field in subsequent sections, each field
name is followed by the required colon and WS. However, for brevity sometimes
those are not referred to in the textual description of the syntax. They are,
nonetheless, required.

It is important to note that the header fields are not guaranteed to be in a
particular order. They may appear in any order, and have occasionally been
reordered in the past when transported over the Internet. However, for the
purposes of this standard, header fields SHOULD NOT be reordered when a
message is transported or transformed. More importantly, the trace header
fields MUST NOT be reordered. Also, the resent header fields, if present,
SHOULD be kept in groups.

The only required header fields are the origination date field and the
originator address field(s). All other header fields are optional, but are
noted below where they SHOULD be used.

fields          =       [trace]
                        {orig-date
                        originator
                        [identifier]
                        [informational]
                        [destination]
                        *resent
                        *optional-field}

The exact interpretation of each field is described in subsequent sections.

3.6.1 The origination date field

The origination date header consists of the field name "Date" followed by a
date-time specification.

orig-date       =       "Date:" WS date-time CRLF

The origination date specifies the date and time at which the creator of the
message indicated that the message was complete and ready to enter the mail
delivery system. For instance, this might be the time that a user pushes the
"send" or "save" button in an application program. In any case, it is
specifically not intended to convey the time that the message is actually
transported, but rather the time at which the human or other creator of the
message has put the message in its final form, ready for transport.

3.6.2 Originator fields

The originator of a message takes one of two forms. The first is a single
header consisting of the field name "From" and a single mailbox
specification. Alternatively, the originator may be two headers, one of which
consisting of the field name "Sender" and a single mailbox address, and the
other with the field name "From" and a comma-separated list of one or more
mailbox specifications. In either form, there is also an optional "Reply-To"
field that may be included, which contains a comma-separated list of one or
more mailboxes.

originator      =       {(from / sender)
                         [reply-to]}

reply-to        =       "Reply-To:" WS 1#mailbox CRLF

sender          =       {"Sender:" WS mailbox CRLF
                         "From:" WS 1#mailbox CRLF}

from            =       "From:" WS mailbox CRLF

The originator indicates the mailbox(es) of the source of the message. The
"From:" field specifies the author(s) of the message, that is, the
mailbox(es) of the person(s) or system(s) responsible for the writing of the
message. The "Sender:" field specifies the mailbox of the agent responsible
for the actual transmission of the message. For example, if a secretary were
to send a message for another person, the mailbox of the secretary would go
in the "Sender:" field and the mailbox of the actual author would go in the
"From:" field. If the originator of the message can be indicated by a single
mailbox and the author and transmitter are identical, the simple "From" form
SHOULD be used. Otherwise, the "From/Sender" form SHOULD be used.

The originator also provides the information required to reply to a message.
When the "Reply-To:" field is present, it indicates that replies SHOULD NOT
go back to the author(s) of the message, but rather the mailbox(es) specified
in the "Reply-To:" field. In the absence of the "Reply-To:" field, replies
SHOULD be sent to the mailbox(es) specified in the "From:" field. "Reply-To:"
SHOULD NOT be used if it is identical to the "From:" field. In all cases, the
"From:" field SHOULD NOT contain any mailbox which does not belong to the
author(s) of the message. See also section 3.6.3 for information on forming
the destination addresses for a reply.

3.6.3 Destination address fields

The destination of a message contains three possible fields, each of the same
form: The field name, which is either "To", "Cc", or "Bcc", followed by a
comma-separated list of one or more addresses (either mailbox or group
syntax). Both the "To:" field and the "Bcc:" field may occur alone, but the
"Cc:" field SHOULD only be present if the "To:" field is also present.

destination     =       {["To:" WS 1#address CRLF]
                         ["Cc:" WS 1#address CRLF]
                         ["Bcc:" WS 1#address CRLF]}

The destination fields specify the recipients of the message. Each
destination field may have one or more addresses, and each of the addresses
receives a copy of the message. The only difference between the three fields
is how each are used.

The "To:" field contains the address(es) of the primary recipient(s) of the
message.

The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of making a
copy on a typewriter using carbon paper) contains the addresses of others who
should receive the message, though the content of the message may not be
directed at them.

The "Bcc:" field contains addresses of recipients of the message whose
addresses should not be revealed to other recipients of the message.
[Editor's note: Rathole alert! Recommendations welcome on where to go from
here on Bcc.]

When a message is a reply to another message, the mailboxes of the authors of
the original message (the mailboxes in the "From:" or "Reply-To:" fields) MAY
appear in the "To:" field of the reply, since that would normally be the
primary recipient. If a reply is sent to a message that has destination
fields, it is often desireable to send a copy of the reply to all of the
recipients of the message in addition to the author. When such a reply is
formed, addresses in the "To:" and "Cc:" fields of the original message MAY
appear in the "Cc:" field of the reply, since these are normally secondary
recipients of the reply. Addresses in the "Bcc:" field of the original
message MAY appear in the "Bcc:" field of the reply, but SHOULD NOT appear in
the "To:" or "Cc:" fields.

3.6.4 Identifier fields

Though optional, every message SHOULD have a "Message-ID:" field.
Furthermore, reply messages SHOULD have "In-Reply-To:" and "References:"
fields as appropriate, as described below.

The "Message-ID:" and "In-Reply-To:" field each contain a single unique
message identifier. The "References:" field contains one or more unique
message identifiers, optionally separated by CFWS.

The message identifier is simply a name-domain construct (addr-spec) enclosed
in the angle bracket characters, "<" and ">".

identifier      =       {["Message-ID:" WS msg-id CRLF]
                         ["In-Reply-To:" WS msg-id CRLF]
                         ["References:" WS msg-id *(*CFWS msg-id) CRLF]}

msg-id          =       "<" addr-spec ">"

The "Message-ID:" field provides a unique identifier which refers to a
particular version of a particular message. The uniqueness of the message
identifier is guaranteed by the host which generates it (see below). This
identifier is intended 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
new message identifiers.

The "In-Reply-To:" and "References:" fields are used when creating a reply to
a message. They hold the message identifier of the original message and the
message identifiers of other messages (for example, in the case of a reply to
a message which was itself a reply). If the original message contains a
"Message-ID:" field, the contents of that field body should be copied into
the body of an "In-Reply-To:" field in the new message. If the original
message contains an "In-Reply-To:" field (and thus is a reply itself), the
contents of the body of the "In-Reply-To:" field should be copied into a
"References:" field in the new message. Finally, if the original message
contains a "References:" field (hence a reply to a reply), the contents of
that field body should be copied to the "References:" field in the new
message, appending to the contents if the original message also had an "In-
Reply-To:" field. In this way, a "thread" of conversation can be established.

The message identifier itself is a domain-dependent unique identifier. The
domain portion of the identifier SHOULD be the domain name of the host on
which it was created, to guarantee uniqueness. The local-part portion of the
identifier MAY be any dot-atom or quoted-string. However, the entire
identifier MUST be globally unique. In order to do this, a common practice is
to form the local-part by using a combination of the current absolute time
and some other currently unique identifer on the host (for example a system
process identifier).

3.6.5 Informational fields

The informational fields are all optional. The "Keywords:" field contains a
comma-separated list of one or more words or quoted-strings. The "Subject:"
and "Comments:" fields are unstructured fields as defined in section 2.2.1,
and therefore may contain text or folding white-space.

informational   =       {["Subject:" WS unstructured CRLF]
                         ["Comments:" WS unstructured CRLF]
                         ["Keywords:" WS 1#phrase CRLF]}

These three fields are only intended to have human-readable content with
information about the message. The "Subject:" field is the most common and
contains a short string identifying the topic of the message. When used in a
reply, it MAY contain the string "Re: " (from the abbreviation for
"Regarding") followed by the contents of the "Subject:" field body of the
original message. The "Comments:" field contains any additional comments on
the text of the body of the message. The "Keywords:" field contains a comma-
separated list of important words and phrases that might be useful for the
recipient.

3.6.6 Trace fields

The optional trace fields MUST appear at the top of the message when present.
The trace fields consist of an optional "Return-Path:" field, and one or more
"Received:" fields. A delivered message SHOULD have a "Return-Path:" field. A
message that has been transported SHOULD have at least one "Received:" field.

trace           =       [return]
                        1*received

return          =       "Return-Path:" WS "<" [addr-spec] ">" CRLF

received        =       "Received:" *CFWS
                        [WS "from" WS domain]
                        [WS "by" WS domain ]
                        [WS "via" WS atom]
                        *(WS "with" WS atom)
                        [WS "id" WS atom [WS "@" WS domain]]
                        [WS "for" WS addr-spec]
                        WS ";" WS date-time CRLF

The "Return-Path:" field is added by the final delivering transport agent.
The field body contains the address found in the transport envelope, which
may be empty, surrounded by "<" and ">".

The "Received:" fields are informational. Each time a message passes through
an agent in the transport system, it prepends to the message a "Received:"
field with a description of the transport action that has taken place and the
date and time at which it was performed.

A full discussion of the trace fields is contained in [SMTP]. For the
purporses of this standard, the trace fields are strictly informational, and
any formal interpretation of them is outside of the scope of this document.

3.6.7 Resent fields

Resent fields SHOULD be added to any message which is reintroduced into the
transport system after being received out of the transport system. A seperate
set of resent fields SHOULD be added if this occurs multiple times. All of
the resent fields corresponding to a particular re-sending of the message
SHOULD be together. Each new set of resent fields should be prepended to the
message; that is, the most recent set of resent fields should appear earlier
in the message. No other fields in the message should be changed when resent
fields are added.

Each of the resent fields corresponds to a particular field elsewhere in the
syntax. For instance, the "Resent-Date:" field corresponds to the "Date:"
field and the "Resent-To:" field corresponds to the "To:" field. In each
case, the syntax for the field body is identical to the syntax given
previously for the corresponding field.

When resent fields are used, the resent originator and "Resent-Date:" fields
MUST be sent. The "Resent-Cc:" field SHOULD NOT be sent if the "Resent-To:"
field is not present. The "Resent-Message-ID:" field SHOULD be sent. "Resent-
Reply-To:" SHOULD NOT be sent if it is identical to "Resent-From:". The
simpler form of resent-orig SHOULD be used if "Resent-Sender:" would be
identical to "Resent-From:".

resent          =       {resent-orig CRLF
                         "Resent-Date:" WS date-time CRLF
                         ["Resent-To:" WS 1#address CRLF]
                         ["Resent-Cc:" WS 1#address CRLF]
                         ["Resent-Bcc:" WS 1#address CRLF]
                         ["Resent-Message-ID:" WS 1#address CRLF]

resent-orig     =       {("Resent-From:" WS mailbox CRLF /
                          {"Resent-Sender:" WS mailbox CRLF
                           "Resent-From:" WS 1#mailbox CRLF})
                         ["Resent-Reply-To:" WS 1#address CRLF]}

Resent fields are used to identify a message as having been reintroduced into
the transport system. Each set of resent fields correspond to a particular
resending event. That is, if a message is resent multiple times, each set of
resent fields gives identifying information for each individual time. Resent
fields are strictly informational. They MUST NOT be used in the normal
processing of replies or other such actions on messages.

The resent originator fields indicate the mailbox of the person(s) or
system(s) that resent the message. As with the regular originator fields,
there are two forms; a simple "Resent-From:" form which contains the mailbox
of the individual doing the resending, and the more complex form, when one
individual (identified in the "Resent-Sender:" field) resends a message on
behalf of one or more others (identified in the "Resent-From:" field). The
"Resent-Reply-To:" indicates a mailbox at which the resender prefers to
receive messages.

Note: When replying to a resent message, replies should behave just as they
would with any other message, using the original "From:", "Reply-To:",
"Message-ID:", and other fields. The resent fields, including "Resent-Reply-
To:", are only informational and MUST NOT be used when sending replies.

The "Resent-Date:" indicates the date and time at which the resent message is
dispatched by the resender of the message. Like the "Date:" field, it is not
the date and time that the message was actually transported.

The "Resent-To:", "Resent-Cc:", and "Resent-Bcc:" fields function identically
to the "To:", "Cc:", and "Bcc:" fields respectively, except that they
indicate the recipients of the resent message, not the recipients of the
original message.

The "Resent-Message-ID:" field provides a unique identifier for the resent
message.

3.6.8 Optional fields

Fields may appear in messages that are otherwise unspecified in this
standard. They must conform to the syntax of an optional-field. This is
basically a field name, made up of the printable US-ASCII characters except
SPACE and colon, followed by a colon and one white-space character, followed
by unstructured text.

optional-field  =       field-name ":" WS unstructured

field-name      =       1*ftext

ftext           =       33..57 / 58..126        ; Any character except CTL,
                                                ;  SPACE, and ":".

For purposes of this standard, the meaning any optional field is
uninterpreted.

. Obsolete Syntax

Earlier versions of this standard allowed for different (usually more
liberal) syntax than are allowed in this version. Also, there have been
syntactic elements used in messages on the Internet that have never been
documented. Though these syntactic forms MUST NOT be generated, they MUST be
accepted and parsed by a conformant receiver. This section documents this
syntax.

One important difference between the obsolete and the current syntax is that
in structured header field bodies (i.e. between the colon and the CRLF of any
structured header field), white-space characters, including folding white-
space, and comments could be freely inserted between any syntactic tokens.
This allowed many complex forms that have proven difficult for some
implementations to parse.

Another key difference between the obsolete and the current syntax is case-
sensitivity. Header field names in the old syntax are identical to those in
the current syntax but are allowed to be either in uppercase, lowercase, or
any combination of uppercase and lowercase characters with identical semantic
interpretation. Implementations MUST continue to treat header field names
which differ only in case as identical.

[Editor's note: I did a little experiment with regard to what this would look
like if I actually wrote it into the syntax; see section 4.4 and 4.4.1. All
of the field names below are ABNF case-insensitive. Feedback solicited on
whether I should "complete the task".]

Finally, certain characters which were formerly allowed in messages appear in
this section. The NULL character (ASCII value 0) was once allowed, but is no
longer for compatibility reasons. CR and LF were allowed to appear in
messages other than as CRLF. This use is also shown here.

Other differences in syntax and semantics are noted in the following
sections.

4.1 Miscellaneous obsolete tokens

These syntactic elements are used elsewhere in the obsolete syntax or in the
main syntax.

obs-qp          =       "\" CHAR                ; CHAR is 0..127

obs-body        =       *(*998obs-text CRLF) *998obs-text

obs-unstruct    =       *(FWS / obs-text)

obs-text        =       obs-chars /
                        (obs-chars CR obs-chars) /
                        (obs-chars LF obs-chars)

obs-chars       =       text / 0                ; 0..127 except CR and LF

4.2 Obsolete Date and Time

The syntax for the obsolete date format allows a 2 digit year in the date
field and allows for a list of alphabetic time zone specifications which were
used in earlier versions of this standard.

obs-date-time   =       [obs-day ","] 1*CFWS obs-date 1*CFWS obs-time

obs-day         =       *CFWS day *CFWS

obs-date        =       1*2DIGIT 1*CFWS month 1*CFWS 2*4DIGIT

obs-time        =       *CFWS (hour / obs-hour) 1*CFWS
                        (zone / obs-zone) *CFWS

obs-hour        =       2DIGIT *CFWS ":" *CFWS 2DIGIT *CFWS
                        [":" *CFWS 2DIGIT *CFWS]

obs-zone        =       "UT" / "GMT" /          ; Universal Time
                                                ; North American : UT
                        "EST" / "EDT" /         ; Eastern:  - 5/ - 4
                        "CST" / "CDT" /         ; Central:  - 6/ - 5
                        "MST" / "MDT" /         ; Mountain: - 7/ - 6
                        "PST" / "PDT" /         ; Pacific:  - 8/ - 7
                        ("A".."I" / "K".."Z")   ; Military zone

Except the time zone, all of the other obsolete elements are identical in
semantics to their corresponding standard elements. "UT" and "GMT" are
indications of "Universal Time" and "Greenwich Mean Time" respectively and
are both semantically identical to "+0000". The remaining three character
zones are the US time zones. The "T" is simply "Time" and the "E", "C", "M",
and "P" are "Eastern", "Central", "Mountain" and "Pacific". When followed by
"S" (for "Standard"), each of these are equivalent to "-0500", "-0600", "-
0700", and "-0800" respectively. When followed by "D" (for "Daylight" or
summer time), the each add an hour and are therefore "-0400", "-0500", "-
0600", and "-0700" respectively. The 1 character military time zones were
defined in a non-standard way in [RFC822] and are therefore unpredictable in
their meaning. The original definitions of the military zones "A" through "I"
are equivalent to "+0100" through "+0900" respectively; "K", "L", and "M" are
equivalent to  "+1000", "+1100", and "+1200" respectively; "N" through "Y"
are equivalent to "-0100" through "-1200" respectively; and "Z" is equivalent
to "+0000". However, because of the error in [RFC822], they SHOULD all be
considered equivalent to "+0000".

4.3 Obsolete Addressing

There are two primary differences in addressing. First, mailbox addresses
were allowed to have a route portion before the addr-spec when enclosed in
"<" and ">". The route is simply a comma-separated list of domain names, each
preceeded by "@", and the list terminated by a colon. Second, CFWS were
allowed between the period-seperated elements of local-part and domain (i.e.
dot-atom was not used).

obs-mailbox     =       obs-addr-spec / [obs-phrase] route-addr

route-addr      =       *CFWS "<" [route] obs-addr-spec ">" *CFWS

route           =       *CFWS 1#("@" obs-domain) ":" *CFWS

obs-addr-spec   =       obs-local-part "@" obs-domain

obs-local-part  =       quoted-string / atom *("." atom)

obs-domain      =       atom *("." atom) / domain-literal

When interpreting addresses, the route portion SHOULD be ignored.

4.4 Obsolete header fields

[Editor's note: This section needs some work.]

Syntactically, the primary difference in the obsolete field syntax is that it
allows multiple occurances of the destination, identifier, and informational
fields.

obs-fields      =       {[obs-trace]
                        obs-orig-date
                        obs-originator
                        *obs-destination
                        *obs-identifier
                        *obs-information
                        *obs-resent
                        *obs-optional}

obs-trace       =       {[obs-return CRLF]
                        1*obs-received}

The obs-return field allows a route-addr instead of simply an addr-spec in
the field body.

obs-return      =       RETURN-PATH *CFWS ":" route-addr CRLF

obs-received    =       RECEIVED *CFWS ":"
                        ["from" 1*CFWS obs-domain]
                        ["by" 1*CFWS obs-domain]
                        ["via" 1*CFWS atom]
                        *("with" 1*CFWS atom)
                        ["id" 1*CFWS atom ["@" obs-domain]]
                        ["for" 1*CFWS obs-addr-spec]
                        ";" obs-date-time CRLF

obs-orig-date   =       DATE *CFWS ":" obs-date-time CRLF

obs-originator  =       {(obs-from / obs sender)
                         [obs-reply-to]

obs-from        =       FROM *CFWS ":" obs-mailbox CRLF

obs-sender      =       {SENDER *CFWS ":" obs-mailbox CRLF
                         FROM *CFWS ":" 1#obs-mailbox CRLF}

obs-reply-to    =       REPLY-TO *CFWS ":" 1#obs-mailbox CRLF

obs-destination =       {[TO *CFWS ":" 1#address CRLF]
                         [CC *CFWS ":" 1#address CRLF]
                         [BCC *CFWS ":" 1#address CRLF]}

obs-identifier  =       {[MESSAGE-ID *CFWS ":" obs-msg-id CRLF]
                         [IN-REPLY-TO *CFWS ":" *(phrase / obs-msg-id) CRLF]
                         [REFERENCES *CFWS ":" *(phrase / obs-msg-id) CRLF]}

obs-msg-id      =       *CFWS "<" obs-addr-spec ">" *CFWS

obs-information =       {[SUBJECT *CFWS ":" obs-unstruct CRLF]
                         [COMMENTS *CFWS ":" obs-unstruct CRLF]
                         [KEYWORDS *CFWS ":" 1#phrase CRLF]}

obs-resent      =       {obs-resent-orig CRLF
                         RESENT-DATE *CFWS ":" obs-date-time CRLF
                         [RESENT-TO *CFWS ":" 1#address CRLF]
                         [RESENT-CC *CFWS ":" 1#address CRLF]
                         [RESENT-BCC *CFWS ":" 1#address CRLF]
                         [RESENT-MSG-ID *CFWS ":" 1#address CRLF]}

obs-resent-orig =       {(RESENT-FROM *CFWS ":" obs-mailbox CRLF /
                          {RESENT-SENDER *CFWS ":" obs-mailbox CRLF
                           RESENT-FROM *CFWS ":" 1#mailbox CRLF})
                         [RESENT-REPLY-TO *CFWS ":" 1#address CRLF]}

obs-optional    =       field-name *CFWS ":" obs-unstruct CRLF

4.4.1 Obsolete field names

DATE            =       ("D"/"d") ("A"/"a") ("T"/"t") ("E"/"e")

SENDER          =       ("S"/"s") ("E"/"e") ("N"/"n") ("D"/"d") ("E"/"e")
                        (/"R"/"r")

FROM            =       ("F"/"f") ("R"/"r") ("O"/"o") ("M"/"m")

REPLY-TO        =       ("R"/"r") ("E"/"e") ("P"/"p") ("L"/"l") ("Y"/"y")
                        "-" ("T"/"t") ("O"/"o")

TO              =       ("T"/"t") ("O"/"o")

CC              =       ("C"/"c") ("C"/"c")

BCC             =       ("B"/"b") ("C"/"c") ("C"/"c")

MESSAGE-ID      =       ("M"/"m") ("E"/"e") ("S"/"s") ("S"/"s") ("A"/"a")
                        ("G"/"g") ("E"/"e") "-" ("I"/"i") ("D"/"d")

IN-REPLY-TO     =       ("I"/"i") ("N"/"n") "-" ("R"/"r") ("E"/"e") ("P"/"p")
                        ("L"/"l") ("Y"/"y") "-" ("T"/"t") ("O"/"o")

REFERENCES      =       ("R"/"r") ("E"/"e") ("F"/"f") ("E"/"e") ("R"/"r")
                        ("E"/"e") ("N"/"n") ("C"/"c") ("E"/"e") ("S"/"s")

SUBJECT         =       ("S"/"s") ("U"/"u") ("B"/"b") ("J"/"j") ("E"/"e")
                        ("C"/"c") ("T"/"t")

COMMENTS        =       ("C"/"c") ("O"/"o") ("M"/"m") ("M"/"m") ("E"/"e")
                        ("N"/"n") ("T"/"t") ("S"/"s")

KEYWORDS        =       ("K"/"k") ("E"/"e") ("Y"/"y") ("W"/"w") ("O"/"o")
                        ("R"/"r") ("D"/"d") ("S"/"s")

RETURN-PATH     =       ("R"/"r") ("E"/"e") ("T"/"t") ("U"/"u") ("R"/"r")
                        ("N"/"n") "-" ("P"/"p") ("A"/"a") ("T"/"t") ("H"/"h")

RECEIVED        =       ("R"/"r") ("E"/"e") ("C"/"c") ("E"/"e") ("I"/"i")
                        ("V"/"v") ("E"/"e") ("D"/"d")

RESENT-DATE     =       ("R"/"r") ("E"/"e") ("S"/"s") ("E"/"e") ("N"/"n")
                        ("T"/"t") "-" ("D"/"d") ("A"/"a") ("T"/"t") ("E"/"e")

RESENT-TO       =       ("R"/"r") ("E"/"e") ("S"/"s") ("E"/"e") ("N"/"n")
                        ("T"/"t") "-" ("T"/"t") ("O"/"o")

RESENT-CC       =       ("R"/"r") ("E"/"e") ("S"/"s") ("E"/"e") ("N"/"n")
                        ("T"/"t") "-" ("C"/"c") ("C"/"c")

RESENT-BCC      =       ("R"/"r") ("E"/"e") ("S"/"s") ("E"/"e") ("N"/"n")
                        ("T"/"t") "-" ("B"/"b") ("C"/"c") ("C"/"c")

RESENT-MSG-ID   =       ("R"/"r") ("E"/"e") ("S"/"s") ("E"/"e") ("N"/"n")
                        ("T"/"t") "-" ("M"/"m") ("E"/"e") ("S"/"s") ("S"/"s")
                        ("A"/"a") ("G"/"g") ("E"/"e") "-" ("I"/"i") ("D"/"d")

RESENT-SENDER   =       ("R"/"r") ("E"/"e") ("S"/"s") ("E"/"e") ("N"/"n")
                        ("T"/"t") "-" ("S"/"s") ("E"/"e") ("N"/"n") ("D"/"d")
                        ("E"/"e") (/"R"/"r")

RESENT-FROM     =       ("R"/"r") ("E"/"e") ("S"/"s") ("E"/"e") ("N"/"n")
                        ("T"/"t") "-" ("F"/"f") ("R"/"r") ("O"/"o") ("M"/"m")

RESENT-REPLY-TO =       ("R"/"r") ("E"/"e") ("S"/"s") ("E"/"e") ("N"/"n")
                        ("T"/"t") "-" ("R"/"r") ("E"/"e") ("P"/"p") ("L"/"l")
                        ("Y"/"y") "-" ("T"/"t") ("O"/"o")

. Security Considerations

Care should be taken when displaying messages on a terminal or terminal
emulator. Powerful terminals may act on escape sequences and other
combinations of ASCII CTL characters which remap the keyboard or permit other
modifications to the terminal which could lead to denial of service or even
damaged data. Message viewers may wish to strip potentially dangerous
terminal escape sequences from the message prior to display. However, other
escape sequences appear in messages for useful purposes (cf. [MIME-IMB],
[ISO-2022-JP]) and therefore should not be stripped indiscriminantly.

Transmission of non-text objects in messages raises additional security
issues. These issues are discussed is [MIME-IMT, MIME-IMB].

. Bibliography

. Author's Address

Peter W. Resnick
QUALCOMM Incorporated
 Lusk Boulevard
San Diego, CA 92121-2779
Phone: +1 619 651 4478
FAX: +1 619 658 2230
e-mail: presnick@qualcomm.com

Grammar and syntax comments are welcome. Substantive comments on this
document should be directed to the DRUMS working group. The subscription
address is <drums-request@uninett.no>.

. Acknowledegments