Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cbosgd!ulysses!bellcore!decvax!decwrl!pyramid!pesnta!amd!amdcad!lll-crg!seismo!brl-adm!ron From: ron@brl-adm.UUCP Newsgroups: mod.sources.doc Subject: rfc822 (3 of 5) Message-ID: <724@brl-adm.ARPA> Date: Tue, 20-May-86 00:00:11 EDT Article-I.D.: brl-adm.724 Posted: Tue May 20 00:00:11 1986 Date-Received: Sat, 24-May-86 22:26:58 EDT Distribution: net Organization: Ballistic Research Lab Lines: 580 Approved: RON@BRL.ARPA Standard for ARPA Internet Text Messages ";" date-time ; time received originator = authentic ; authenticated addr [ "Reply-To" ":" 1#address] ) authentic = "From" ":" mailbox ; Single author / ( "Sender" ":" mailbox ; Actual submittor "From" ":" 1#mailbox) ; Multiple authors ; or not sender resent = resent-authentic [ "Resent-Reply-To" ":" 1#address] ) resent-authentic = = "Resent-From" ":" mailbox / ( "Resent-Sender" ":" mailbox "Resent-From" ":" 1#mailbox ) dates = orig-date ; Original [ resent-date ] ; Forwarded orig-date = "Date" ":" date-time resent-date = "Resent-Date" ":" date-time destination = "To" ":" 1#address ; Primary / "Resent-To" ":" 1#address / "cc" ":" 1#address ; Secondary / "Resent-cc" ":" 1#address / "bcc" ":" #address ; Blind carbon / "Resent-bcc" ":" #address optional-field = / "Message-ID" ":" msg-id / "Resent-Message-ID" ":" msg-id / "In-Reply-To" ":" *(phrase / msg-id) / "References" ":" *(phrase / msg-id) / "Keywords" ":" #phrase / "Subject" ":" *text / "Comments" ":" *text / "Encrypted" ":" 1#2word / extension-field ; To be defined / user-defined-field ; May be pre-empted msg-id = "<" addr-spec ">" ; Unique message id August 13, 1982 - 18 - RFC #822 Standard for ARPA Internet Text Messages extension-field = user-defined-field = 4.2. FORWARDING Some systems permit mail recipients to forward a message, retaining the original headers, by adding some new fields. This standard supports such a service, through the "Resent-" prefix to field names. Whenever the string "Resent-" begins a field name, the field has the same semantics as a field whose name does not have the prefix. However, the message is assumed to have been forwarded by an original recipient who attached the "Resent-" field. This new field is treated as being more recent than the equivalent, original field. For example, the "Resent-From", indicates the person that forwarded the message, whereas the "From" field indi- cates the original author. Use of such precedence information depends upon partici- pants' communication needs. For example, this standard does not dictate when a "Resent-From:" address should receive replies, in lieu of sending them to the "From:" address. Note: In general, the "Resent-" fields should be treated as con- taining a set of information that is independent of the set of original fields. Information for one set should not automatically be taken from the other. The interpre- tation of multiple "Resent-" fields, of the same type, is undefined. In the remainder of this specification, occurrence of legal "Resent-" fields are treated identically with the occurrence of August 13, 1982 - 19 - RFC #822 Standard for ARPA Internet Text Messages fields whose names do not contain this prefix. 4.3. TRACE FIELDS Trace information is used to provide an audit trail of mes- sage handling. In addition, it indicates a route back to the sender of the message. The list of known "via" and "with" values are registered with the Network Information Center, SRI International, Menlo Park, California. 4.3.1. RETURN-PATH This field is added by the final transport system that delivers the message to its recipient. The field is intended to contain definitive information about the address and route back to the message's originator. Note: The "Reply-To" field is added by the originator and serves to direct replies, whereas the "Return-Path" field is used to identify a path back to the origina- tor. While the syntax indicates that a route specification is optional, every attempt should be made to provide that infor- mation in this field. 4.3.2. RECEIVED A copy of this field is added by each transport service that relays the message. The information in the field can be quite useful for tracing transport problems. The names of the sending and receiving hosts and time-of- receipt may be specified. The "via" parameter may be used, to indicate what physical mechanism the message was sent over, such as Arpanet or Phonenet, and the "with" parameter may be used to indicate the mail-, or connection-, level protocol that was used, such as the SMTP mail protocol, or X.25 tran- sport protocol. Note: Several "with" parameters may be included, to fully specify the set of protocols that were used. Some transport services queue mail; the internal message iden- tifier that is assigned to the message may be noted, using the "id" parameter. When the sending host uses a destination address specification that the receiving host reinterprets, by August 13, 1982 - 20 - RFC #822 Standard for ARPA Internet Text Messages expansion or transformation, the receiving host may wish to record the original specification, using the "for" parameter. For example, when a copy of mail is sent to the member of a distribution list, this parameter may be used to record the original address that was used to specify the list. 4.4. ORIGINATOR FIELDS The standard allows only a subset of the combinations possi- ble with the From, Sender, Reply-To, Resent-From, Resent-Sender, and Resent-Reply-To fields. The limitation is intentional. 4.4.1. FROM / RESENT-FROM This field contains the identity of the person(s) who wished this message to be sent. The message-creation process should default this field to be a single, authenticated machine address, indicating the AGENT (person, system or process) entering the message. If this is not done, the "Sender" field MUST be present. If the "From" field IS defaulted this way, the "Sender" field is optional and is redundant with the "From" field. In all cases, addresses in the "From" field must be machine-usable (addr-specs) and may not contain named lists (groups). 4.4.2. SENDER / RESENT-SENDER This field contains the authenticated identity of the AGENT (person, system or process) that sends the message. It is intended for use when the sender is not the author of the mes- sage, or to indicate who among a group of authors actually sent the message. If the contents of the "Sender" field would be completely redundant with the "From" field, then the "Sender" field need not be present and its use is discouraged (though still legal). In particular, the "Sender" field MUST be present if it is NOT the same as the "From" Field. The Sender mailbox specification includes a word sequence which must correspond to a specific agent (i.e., a human user or a computer program) rather than a standard address. This indicates the expectation that the field will identify the single AGENT (person, system, or process) responsible for sending the mail and not simply include the name of a mailbox from which the mail was sent. For example in the case of a shared login name, the name, by itself, would not be adequate. The local-part address unit, which refers to this agent, is expected to be a computer system term, and not (for example) a generalized person reference which can be used outside the network text message context. August 13, 1982 - 21 - RFC #822 Standard for ARPA Internet Text Messages Since the critical function served by the "Sender" field is identification of the agent responsible for sending mail and since computer programs cannot be held accountable for their behavior, it is strongly recommended that when a computer pro- gram generates a message, the HUMAN who is responsible for that program be referenced as part of the "Sender" field mail- box specification. 4.4.3. REPLY-TO / RESENT-REPLY-TO This field provides a general mechanism for indicating any mailbox(es) to which responses are to be sent. Three typical uses for this feature can be distinguished. In the first case, the author(s) may not have regular machine-based mail- boxes and therefore wish(es) to indicate an alternate machine address. In the second case, an author may wish additional persons to be made aware of, or responsible for, replies. A somewhat different use may be of some help to "text message teleconferencing" groups equipped with automatic distribution services: include the address of that service in the "Reply- To" field of all messages submitted to the teleconference; then participants can "reply" to conference submissions to guarantee the correct distribution of any submission of their own. Note: The "Return-Path" field is added by the mail transport service, at the time of final deliver. It is intended to identify a path back to the orginator of the mes- sage. The "Reply-To" field is added by the message originator and is intended to direct replies. 4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO For systems which automatically generate address lists for replies to messages, the following recommendations are made: o The "Sender" field mailbox should be sent notices of any problems in transport or delivery of the original messages. If there is no "Sender" field, then the "From" field mailbox should be used. o The "Sender" field mailbox should NEVER be used automatically, in a recipient's reply message. o If the "Reply-To" field exists, then the reply should go to the addresses indicated in that field and not to the address(es) indicated in the "From" field. August 13, 1982 - 22 - RFC #822 Standard for ARPA Internet Text Messages o If there is a "From" field, but no "Reply-To" field, the reply should be sent to the address(es) indicated in the "From" field. Sometimes, a recipient may actually wish to communicate with the person that initiated the message transfer. In such cases, it is reasonable to use the "Sender" address. This recommendation is intended only for automated use of originator-fields and is not intended to suggest that replies may not also be sent to other recipients of messages. It is up to the respective mail-handling programs to decide what additional facilities will be provided. Examples are provided in Appendix A. 4.5. RECEIVER FIELDS 4.5.1. TO / RESENT-TO This field contains the identity of the primary recipients of the message. 4.5.2. CC / RESENT-CC This field contains the identity of the secondary (informa- tional) recipients of the message. 4.5.3. BCC / RESENT-BCC This field contains the identity of additional recipients of the message. The contents of this field are not included in copies of the message sent to the primary and secondary reci- pients. Some systems may choose to include the text of the "Bcc" field only in the author(s)'s copy, while others may also include it in the text sent to all those indicated in the "Bcc" list. 4.6. REFERENCE FIELDS 4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID This field contains a unique identifier (the local-part address unit) which refers to THIS version of THIS message. The uniqueness of the message identifier is guaranteed by the host which generates it. This identifier is 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 August 13, 1982 - 23 - RFC #822 Standard for ARPA Internet Text Messages each receive new message identifiers. 4.6.2. IN-REPLY-TO The contents of this field identify previous correspon- dence which this message answers. Note that if message iden- tifiers are used in this field, they must use the msg-id specification format. 4.6.3. REFERENCES The contents of this field identify other correspondence which this message references. Note that if message identif- iers are used, they must use the msg-id specification format. 4.6.4. KEYWORDS This field contains keywords or phrases, separated by commas. 4.7. OTHER FIELDS 4.7.1. SUBJECT This is intended to provide a summary, or indicate the nature, of the message. 4.7.2. COMMENTS Permits adding text comments onto the message without disturbing the contents of the message's body. 4.7.3. ENCRYPTED Sometimes, data encryption is used to increase the privacy of message contents. If the body of a message has been encrypted, to keep its contents private, the "Encrypted" field can be used to note the fact and to indicate the nature of the encryption. The first parameter indicates the software used to encrypt the body, and the second, optional is intended to aid the recipient in selecting the proper decryption key. This code word may be viewed as an index to a table of keys held by the recipient. Note: Unfortunately, headers must contain envelope, as well as contents, information. Consequently, it is neces- sary that they remain unencrypted, so that mail tran- sport services may access them. Since names, addresses, and "Subject" field contents may contain August 13, 1982 - 24 - RFC #822 Standard for ARPA Internet Text Messages sensitive information, this requirement limits total message privacy. Names of encryption software are registered with the Net- work Information Center, SRI International, Menlo Park, Cali- fornia. 4.7.4. EXTENSION-FIELD A limited number of common fields have been defined in this document. As network mail requirements dictate, addi- tional fields may be standardized. To provide user-defined fields with a measure of safety, in name selection, such extension-fields will never have names that begin with the string "X-". Names of Extension-fields are registered with the Network Information Center, SRI International, Menlo Park, California. 4.7.5. USER-DEFINED-FIELD Individual users of network mail are free to define and use additional header fields. Such fields must have names which are not already used in the current specification or in any definitions of extension-fields, and the overall syntax of these user-defined-fields must conform to this specification's rules for delimiting and folding fields. Due to the extension-field publishing process, the name of a user- defined-field may be pre-empted Note: The prefatory string "X-" will never be used in the names of Extension-fields. This provides user-defined fields with a protected set of names. August 13, 1982 - 25 - RFC #822 Standard for ARPA Internet Text Messages 5. DATE AND TIME SPECIFICATION 5.1. SYNTAX date-time = [ day "," ] date time ; dd mm yy ; hh:mm:ss zzz day = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun" date = 1*2DIGIT month 2DIGIT ; day month year ; e.g. 20 Jun 82 month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" time = hour zone ; ANSI and Military hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] ; 00:00:00 - 23:59:59 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 / 1ALPHA ; Military: Z = UT; ; A:-1; (J not used) ; M:-12; N:+1; Y:+12 / ( ("+" / "-") 4DIGIT ) ; Local differential ; hours+min. (HHMM) 5.2. SEMANTICS If included, day-of-week must be the day implied by the date specification. Time zone may be indicated in several ways. "UT" is Univer- sal Time (formerly called "Greenwich Mean Time"); "GMT" is per- mitted as a reference to Universal Time. The military standard uses a single character for each zone. "Z" is Universal Time. "A" indicates one hour earlier, and "M" indicates 12 hours ear- lier; "N" is one hour later, and "Y" is 12 hours later. The letter "J" is not used. The other remaining two forms are taken from ANSI standard X3.51-1975. One allows explicit indication of the amount of offset from UT; the other uses common 3-character strings for indicating time zones in North America. August 13, 1982 - 26 - RFC #822 Standard for ARPA Internet Text Messages 6. ADDRESS SPECIFICATION 6.1. SYNTAX address = mailbox ; one addressee / group ; named list group = phrase ":" [#mailbox] ";" mailbox = addr-spec ; simple address / phrase route-addr ; name & addr-spec route-addr = "<" [route] addr-spec ">" route = 1#("@" domain) ":" ; path-relative addr-spec = local-part "@" domain ; global address local-part = word *("." word) ; uninterpreted ; case-preserved domain = sub-domain *("." sub-domain) sub-domain = domain-ref / domain-literal domain-ref = atom ; symbolic reference 6.2. SEMANTICS 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 their line printer and deliver the output to the addressee's desk. A mailbox specification comprises a person, system or pro- cess name reference, a domain-dependent string, and a name-domain reference. The name reference is optional and is usually used to indicate the human name of a recipient. The name-domain refer- ence specifies a sequence of sub-domains. The domain-dependent string is uninterpreted, except by the final sub-domain; the rest of the mail service merely transmits it as a literal string. 6.2.1. DOMAINS A name-domain is a set of registered (mail) names. A name- domain specification resolves to a subordinate name-domain specification or to a terminal domain-dependent string. Hence, domain specification is extensible, permitting any number of registration levels. August 13, 1982 - 27 - RFC #822