📄 rfc822.txt
字号:
ASCII BS characters (Backspace, decimal 8) may be included in
texts and quoted-strings to effect overstriking. However, any
use of backspaces which effects an overstrike to the left of
the beginning of the text or quoted-string is prohibited.
August 13, 1982 - 15 - RFC #822
Standard for ARPA Internet Text Messages
3.4.10. NETWORK-SPECIFIC TRANSFORMATIONS
During transmission through heterogeneous networks, it may be
necessary to force data to conform to a network's local con-
ventions. For example, it may be required that a CR be fol-
lowed either by LF, making a CRLF, or by <null>, if the CR is
to stand alone). Such transformations are reversed, when the
message exits that network.
When crossing network boundaries, the message should be
treated as passing through two modules. It will enter the
first module containing whatever network-specific transforma-
tions that were necessary to permit migration through the
"current" network. It then passes through the modules:
o Transformation Reversal
The "current" network's idiosyncracies are removed and
the message is returned to the canonical form speci-
fied in this standard.
o Transformation
The "next" network's local idiosyncracies are imposed
on the message.
------------------
From ==> | Remove Net-A |
Net-A | idiosyncracies |
------------------
||
\/
Conformance
with standard
||
\/
------------------
| Impose Net-B | ==> To
| idiosyncracies | Net-B
------------------
August 13, 1982 - 16 - RFC #822
Standard for ARPA Internet Text Messages
4. MESSAGE SPECIFICATION
4.1. SYNTAX
Note: Due to an artifact of the notational conventions, the syn-
tax indicates that, when present, some fields, must be in
a particular order. Header fields are NOT required to
occur in any particular order, except that the message
body must occur AFTER the headers. It is recommended
that, if present, headers be sent in the order "Return-
Path", "Received", "Date", "From", "Subject", "Sender",
"To", "cc", etc.
This specification permits multiple occurrences of most
fields. Except as noted, their interpretation is not
specified here, and their use is discouraged.
The following syntax for the bodies of various fields should
be thought of as describing each field body as a single long
string (or line). The "Lexical Analysis of Message" section on
"Long Header Fields", above, indicates how such long strings can
be represented on more than one line in the actual transmitted
message.
message = fields *( CRLF *text ) ; Everything after
; first null line
; is message body
fields = dates ; Creation time,
source ; author id & one
1*destination ; address required
*optional-field ; others optional
source = [ trace ] ; net traversals
originator ; original mail
[ resent ] ; forwarded
trace = return ; path to sender
1*received ; receipt tags
return = "Return-path" ":" route-addr ; return address
received = "Received" ":" ; one per relay
["from" domain] ; sending host
["by" domain] ; receiving host
["via" atom] ; physical path
*("with" atom) ; link/mail protocol
["id" msg-id] ; receiver msg id
["for" addr-spec] ; initial form
August 13, 1982 - 17 - RFC #822
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.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -