📄 rfc822.txt
字号:
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. 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⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -