Network Working Group P. Resnick, Editor Internet-Draft QUALCOMM Incorporated March 26, 1997 Expires in six months Message Format Standard 0. 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). 1. 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: ]. 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 %d65 for uppercase A and %97 for lowercase A) or by a case-insenstive literal value enclosed in quotation marks (e.g., "A" for either uppercase or lowercase A). See the [ABNF] document for the full description of the notation. 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. Both sections 2 and 3 describe messages which are legal to generate for purposes of this standard. Section 4 of this document specifies an "obsolete" syntax. There are references in section 3 to these obsolete syntactic elements. The rules of 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. 2. 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: More people are giving me anecdotal indications that NULL is a problem not only in headers but also in bodies for some implementations. I'd like more evidence one way or the other before I go and change this again. Where should NULL be allowed, if at all, in the generate syntax?] 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 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 comments (as decribed in section 3.2.4) as well as space (SPACE, ASCII value 32) and horizontal tab (HTAB, ASCII value 9) 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, 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), 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. 3. 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. Note: The "specials" below are just such an example. Though the specials token does not appear anywhere else in this standard, it is useful for implementors who use tools which lexically analyze messages. Each of the characters in specials can be used to indicate a tokenization point in lexical analysis. CTL = %d1..%d31 / ; Control characters, inc. delete %d127 NO-WS-CTL = %d1..%d8 / ; US-ASCII control characters %d11 / ; which do not include the %d12 / ; carriage return, linefeed, %d14..%d31 / ; and whitespace characters %d127 <"> = %d34 ; Quote mark text = %d1..%d9 / ; Characters excluding CR and LF %d11..%d12 / %d14..%d127 / obs-text 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. See section 3.2.4 for more information on the use of white-space in the rest of this standard. WS = SPACE / HTAB ; Whitespace characters FWS = (*WS [CRLF WS] *WS) / ; Folding white-space obs-FWS 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. 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. However, where CFWS occurs in this standard, it MUST NOT be inserted in such a way that any line of a folded header is made up entirely of WS characters and nothing else. ctext = NO-WS-CTL / ; Non-white-space controls %d33..%d39 / ; The rest of the US-ASCII %d42..%d91 / ; characters not including "(", %d93..%d127 ; ")", or "\" comment = "(" *(FWS (ctext / quoted-pair / comment)) ")" CFWS = WS / comment / (FWS *(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. qtext = NO-WS-CTL / ; Non-white-space controls %d33 / ; The rest of the US-ASCII %d35..%d91 / ; characters not including "\" %d93..%d127 ; or the quote character quoted-string = *CFWS <"> *(FWS (qtext / 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 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 = *(FWS text) / obs-unstruct 3.3 Date and Time Specification 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 = [ day-of-week "," ] date 1*CFWS time day-of-week = 1*CFWS day-name 1*CFWS day-name = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun" date = day month year year = (*CFWS 4*DIGIT *CFWS) / obs-year month = 1*CFWS month-name 1*CFWS month-name = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" day = *CFWS 1*2DIGIT *CFWS time = time-of-day *CFWS zone time-of-day = hour ":" minute [ ":" second ] hour = *CFWS 2DIGIT *CFWS minute = *CFWS 2DIGIT *CFWS second = *CFWS 2DIGIT *CFWS zone = (( "+" / "-" ) 4DIGIT) / obs-zone The day is the numeric day of the month. The year is any numeric year in the common era. The time-of-day specifies the number of hours, minutes, and optionally seconds since midnight of the date indicated. The date and time-of-day SHOULD express local time. The zone specifies the offset from Coordinated Universal Time (UTC, formerly referred to as "Greenwich Mean Time") that the date and time-of-day represent. The "+" or "-" indicates whether the time-of-day is ahead of or behind Universal Time. The first two digits indicate the number of hours difference from Universal Time, and the last two digits indicate the number of minutes difference from Universal Time. (Hence, +hhmm means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm) minutes). 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 time-of-day MUST be in the range 00:00:00 through 23:59:61 (the number of seconds allowing for leap seconds; see []), and the zone MUST be within the range -9959 through +9959. 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-addr / addr-spec / obs-mailbox phrase-addr = [phrase] *CFWS "<" addr-spec ">" *CFWS 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 domain-literal = *CFWS "[" *(FWS (dtext / quoted-pair)) "]" *CFWS dtext = NO-WS-CTL / ; Non-white-space controls %d33..%d90 / ; The rest of the US-ASCII %d94..%d127 ; characters not including "[", ; "]", or "\" 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 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. However, for brevity sometimes the colon is not referred to in the textual description of the syntax. It is, 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 they have been known to reordered occasionally 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 syntactically optional. fields = {[trace] *resent orig-date originator [identifier] [informational] [destination] *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:" 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 "submit" 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. (For example, a laptop user who is not connected to a network might queue a message for delivery. The origination date should contain the date and time that the user queued the message, not the time when the user connected to the network to send the message.) 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:" 1#mailbox CRLF sender = {"Sender:" mailbox CRLF "From:" 1#mailbox CRLF} from = "From:" 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 the mailbox(es) to which the author of the message suggests that replies be sent. In the absence of the "Reply-To:" field, replies SHOULD be sent to the mailbox(es) specified in 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:" 1#address CRLF] ["Cc:" 1#address CRLF] ["Bcc:" 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 (where the "Bcc" means "Blind Carbon Copy) contains addresses of recipients of the message whose addresses should not be revealed to other recipients of the message. There are two ways in which the "Bcc:" field is used. In the first case, when a message containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is removed even though all of the recipients (including those specified in the "Bcc:" field) are sent a copy of the message. In the second case, recipients specified in the "To:" and "Cc:" lines each are sent a copy of the message with the "Bcc:" line removed as above, but the recipients on the "Bcc:" line get a seperate copy of the message containing a "Bcc:" line. (When there are multiple recipient addresses in the "Bcc:" field, some implementations actually send a seperate copy of the message to each recipient with a "Bcc:" containing only the address of that particular recipient.) Which method to use with "Bcc:" fields is implementation dependent, but refer to the "Security Considerations" section of this document for a discussion of each. 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. If a "Bcc:" field is present in the original message, addresses in that field 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:" msg-id CRLF] ["In-Reply-To:" msg-id CRLF] ["References:" 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:" unstructured CRLF] ["Comments:" unstructured CRLF] ["Keywords:" 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 Resent fields Resent fields SHOULD be added to any message which is reintroduced by a user into 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. The simpler form of resent-orig SHOULD be used if "Resent-Sender:" would be identical to "Resent-From:". resent = {resent-orig CRLF "Resent-Date:" date-time CRLF ["Resent-To:" 1#address CRLF] ["Resent-Cc:" 1#address CRLF] ["Resent-Bcc:" 1#address CRLF] ["Resent-Message-ID:" 1#address CRLF] resent-orig = ("Resent-From:" mailbox CRLF) / {"Resent-Sender:" mailbox CRLF "Resent-From:" 1#mailbox CRLF} Resent fields are used to identify a message as having been reintroduced into the transport system by a user. The purpose of using resent fields is to have the message appear to the final recipient as if it were sent directly by the original sender, with all of the original fields remaining the same. 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). 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 are only informational and MUST NOT be used when forming 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.7 Trace fields The trace fields consist of a group of headers consisting of an optional "Return-Path:" field, and one or more "Received:" fields. The exact syntax of the trace fields is defined in [SMTP]. The following defines a placeholder syntax. trace = [return] 1*received return = "Return-Path:" *(CFWS text) CRLF received = "Received:" *(CFWS text) CRLF 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.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, followed by unstructured text. The field names of any optional-field MUST NOT be identical to any field name specified elsewhere in this standard. optional-field = field-name ":" unstructured field-name = 1*ftext ftext = %d33..%d57 / ; Any character except CTL, %d58..%d126 ; SPACE, and ":". For purposes of this standard, the meaning any optional field is uninterpreted. 4. 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 according to the grammar in section 3, 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 that the rule in section 3.2.4 regarding comments and folding whitespace does not apply. See the discussion of folding whitespace in section 4.2 below. 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 %d0..%d127 obs-body = *(*998obs-text CRLF) *998obs-text obs-unstruct = *(FWS / obs-text) obs-text = *(obs-char / (*CR obs-char) / (*LF *CR obs-char)) obs-char = text / %d0 ; %d0..%d127 except CR and LF 4.2 Obsolete folding whitespace In the obsolete syntax, any amount of folding whitespace MAY be inserted where the obs-FWS rule is allowed. This creates the possibility of having two consecutive "folds" in a line, and therefore the possibility that a line which makes up a folder header could be composed entirely of whitespace. obs-FWS = *(WS [CRLF WS]) 4.3 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-year = 2*DIGIT 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 Where a two or three digit year occurs in a date, the year should be interpreted as follows: If a two digit year is encountered whose value is between 00 and 49, the year should be interpreted by adding 2000, ending up with a value between 2000 and 2049. If a two digit year is encountered with a value between 50 and 99, or any three digit year is encountered, the year should be interpreted by adding 1900. In the obsolete time zone, "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". Other multi-character (usually between 3 and 5) alphabetic time zones have been used in Internet messages. Any unknown time zone specification SHOULD be considered equivalent too "-0000". 4.4 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.5 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. Also, the obsolete syntax allows for any amount of comment or folding whitespace before the ":" at the end of the field name. 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 and obs-received are again given here as template definitions. Their actual interpretation and full syntax is given in [SMTP]. obs-return = "Return-Path" *CFWS ":" *(obs-text / CFWS) CRLF obs-received = "Received" *CFWS ":" *(obs-text / CFWS) CRLF obs-orig-date = "Date" *CFWS ":" 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-Message-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 5. 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]. Many implementations use the "Bcc:" (blind carbon copy) field described in section 3.6.3 to facilitate sending messages to recipients without revealing the addresses of one or more of the addressees to the other recipients. Mishandling this use of "Bcc:" has implications for confidential information that might be revealed. For example, if using the first method described in section 3.6.3, where the "Bcc:" line is removed from the message, blind recipients have no explicit indication that they have been sent a blind copy, except insofar as their address does not appear in the message headers. Because of this, one of the blind addressees could potentially send a reply to all of the shown recipients and accidentally revealing that the message went to the blind recipient. When the second method from section 3.6.3 is used, the blind recipients address appears in the "Bcc:" field of a seperate copy of the message. If the "Bcc:" field sent contains all of the blind addressees, all of the "Bcc:" recipients will be seen by each "Bcc:" recipient. Even if a seperate message is sent to each "Bcc:" recipient with only the individual's address, implementations must still be careful to process replies to the message as per section 3.6.3 so as not to accidentally reveal the blind recipient to other recipients. 6. Bibliography [TBD] 7. Author's Address Peter W. Resnick QUALCOMM Incorporated 6455 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 . 8. Acknowledegments [TBD] Appendix A - Examples of messages [TBD] Appendix B - Differences from eariler standards [Editor's note: I will use this section for some rough notes concerning differences between drafts for now. Eventually I will make this real. 1. Fix quoted-pair (added parens) 2. 4*DIGIT for year. 3. Define year better. 4. Take away silly padding restriction on day-of-month. 5. Added "formula" to time zone semantics. 6. Increase range of legal time and zone. (Researching reference) 7. No more WS after ":" 8. Reworded Reply-To 9. Remove Reply-To != From 10. Got rid of "case-insensitive" stuff 11. Fixed FWS and comment 12. Domain literals moved to addressing section. 13. More explanation of Bcc reply and that Bcc may be empty 14. Put optional CFWS back into Date. 15. Take out SHOULD NOT on NO-WS-CTL 16. More explanation on Resent. 17. Fixed description of optional-field to not allow defined names 18. Fixed obs-text to include NUL and CR and LF properly 19. Describe specials. 20. Return-Path and Received now only pointers to SMTP 21. More explanation on what Date means. 22. Case sensitivity and %d stuff from ABNF To do list: Take out 1000 char line limit Clean up "lexical" and "semantics" speak. Possibly seperate message-id from addressing. Figure out what to do about trace/resent ordering. Specifically talk about X-* headers. Strengthen 1.3. ]