rfc822 (3 of 5)
ron at brl-adm.UUCP
ron at brl-adm.UUCP
Tue May 20 14:00:11 AEST 1986
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 =
<Any field which is defined in a document
published as a formal extension to this
specification; none will have names beginning
with the string "X-">
user-defined-field =
<Any field which has not been defined
in this specification or published as an
extension to this specification; names for
such fields must be unique and may be
pre-empted by published extensions>
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 <word> parameter indicates the
software used to encrypt the body, and the second, optional
<word> 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
More information about the Mod.sources.doc
mailing list