header
Click on the red underlined text to get to the source
... 822std11(-> 2822prop) specifies an
end to end message format, consisting of a header and an unstructured
text body. MIME (Multipurpose Internet Mail Extensions ...
...
An RFC 822std11(-> 2822prop) message consists of a header, and content which is
uninterpreted ASCII text. The header ...
... header, and content which is
uninterpreted ASCII text. The header is divided into fields, which
are the protocol elements. Most of these fields are analogous to IPM
...
... protocol elements. However, all of the RFC 822std11(-> 2822prop) header fields, with
the exception of trace, can be regarded as corresponding to implicit
...
... A mechanism of mapping, used in several cases, is to map the RFC 822std11(-> 2822prop)
header into a heading extension in the IPM (InterPersonal Message).
This can be regarded as partial support, as it makes the information
available to any X.400 ...
...
The following services (headers) may be present in the header of a
message. These are defined in more detail in Chapter 5 (5.3.4, 5.3.6,
...
... The following services (headers) may be present in the header of a
message. These are defined in more detail in Chapter 5 (5.3.4, 5.3.6,
5.3.7):
...
... 822std11(-> 2822prop), new RFC 822std11(-> 2822prop) headers are defined, and registered by
publication in this standard. It is intended that co-operating RFC
822std11(-> 2822prop) ...
... Supported by use of a new RFC 822std11(-> 2822prop) header (Original-Encoded-
Information-Types:), although in most cases it will not be
possible to map the body part in question.
...
... gateway. A new RFC 822std11(-> 2822prop) header (Deferred-Delivery:)
is provided to transfer information on this service ...
... Supported by use of a new RFC 822std11(-> 2822prop) header (X400-Recipients:). This
is descriptive information for the RFC 822std11(-> 2822prop) recipient, and is not
...
... Supported by use of a new RFC 822std11(-> 2822prop) header (DL-Expansion-History:).
DL Expansion ...
... Supported as new RFC 822std11(-> 2822prop) header (Expires:). In general, no
automatic action can be expected.
...
... Not supported. A new RFC 822std11(-> 2822prop) header (Latest-Delivery-Time:) is
provided, which may be used by the recipient for general
...
... Supported by use of a comment in a new RFC 822std11(-> 2822prop) header (X400-
Recipients:), associated with the recipient in question.
...
... Supported by use of a comment in a new RFC 822std11(-> 2822prop) header (X400-
Recipients:), associated with the recipient in question.
...
... X.400 service "RFC 822std11(-> 2822prop) Header Field" is defined using the
extension facilities. This allows for any RFC 822std11(-> 2822prop) header field ...
... Header Field" is defined using the
extension facilities. This allows for any RFC 822std11(-> 2822prop) header field to be
represented. It may be present in RFC 822std11(-> 2822prop) originated messages which
...
... Around the ":" in all headers
...
...
RFC 822std11(-> 2822prop) folding rules are applied to all headers. Comments are never
used in these new headers.
...
... 822std11(-> 2822prop) folding rules are applied to all headers. Comments are never
used in these new headers.
...
... information into elements of RFC 822std11(-> 2822prop) Headers. A gateway may ignore
this encoding ...
... 1522(-> 2049draft | 2048(-> 4289 | 4288) | 2047draft | 2046draft | 2045draft) is only applied to fields which are "for information only".
A gateway which interprets header elements according to RFC 1522(-> 2049draft | 2048(-> 4289 | 4288) | 2047draft | 2046draft | 2045draft) may
...
... MTS protocol), the originator and each recipient are considered to be
defined by such a construct. In an RFC 822std11(-> 2822prop) header, the EBNF.822-
address is encapsulated ...
... MTA's normal timeout
policy. Where the mapping relates to addresses in the message
header, there shall be a timeout in the range of 1-4 hours or shorter
if this is required to maintain quality of service ...
... For this reason, two new RFC 822std11(-> 2822prop) headers are created, in order to
carry this information to the RFC 822std11(-> 2822prop) ...
... 822std11(-> 2822prop) message. The RFC
822std11(-> 2822prop) headers are used to generate the IPMS.Heading.
...
...
To encode any RFC 822std11(-> 2822prop) Header using this extension, an RFC822Field
element is built using the 822.field omitting the trailing CRLF ...
... IPMS.Heading.primary-recipients. Information shall be
generated from the standard RFC 822std11(-> 2822prop) Headers as follows:
...
... Languages extension.
If any comments or values longer than two characters occur, a
header extension shall also be generated.
Other Fields
...
... Processing of Received: lines follows processing of Date:, and is
done from the bottom to the top of the RFC 822std11(-> 2822prop) header (i.e., in
chronological order). When other trace elements ...
... elements (in particular
X400-Received:) are processed the relative ordering (top to
bottom of the header) shall be retained correctly.
The initial element ...
... MTS extensions are defined as follows:
dsn-header-list EXTENSION
RFC822FieldList
::= id-dsn-header ...
...
The Object Identifiers id-dsn-header-list and id-dsn-field-list are
defined in Appendix D. Theses extensions are used in the same way as
the IPM extension rfc-822-field, described in Section 5.1.2. These
...
... The DSN has an RFC 822std11(-> 2822prop) header. Trace is mapped in the same manner as
for a message to MTA ...
... MTA.ReportTransferEnvelope.trace-information. All
other headers are used to create a dsn-header-list extension, which
...
... other headers are used to create a dsn-header-list extension, which
is added to MTA.PerReportTransferFields.extensions. The DSN ...
... 822std11(-> 2822prop) body. Other services are mapped onto RFC 822std11(-> 2822prop) header
fields. Where there is no appropriate existing field, new fields are
defined for IPMS, MTS ...
... 822std11(-> 2822prop) Message has a number of mandatory fields in the RFC 822std11(-> 2822prop)
Header. Some SMTP services mandate specification of an SMTP
...
... 822std11(-> 2822prop) compliance. When generating RFC 822std11(-> 2822prop)
headers, folding may be used. It is recommended to do this,
following the guidelines of RFC 822std11(-> 2822prop).
...
...
If the RFC 822std11(-> 2822prop) extended header is found, this shall be mapped onto an
RFC 822std11(-> 2822prop) header ...
... header is found, this shall be mapped onto an
RFC 822std11(-> 2822prop) header, as described in Section 5.1.2.
...
... gateway understands the extension and can perform an appropriate
mapping onto an RFC 822std11(-> 2822prop) header field. If extensions are discarded,
the list is indicated in the extended RFC 822std11(-> 2822prop) field "Discarded-X400-
...
... element is mapped to an extended RFC 822std11(-> 2822prop) field "DL-
Expansion-History:". These fileds shall be ordered in the message
header, so that the most recent expansion comes first (same order
as trace).
...
... message shall be rejected. If they are not so marked, they can
safely be discarded. The list of discarded fields shall be
indicated in the extended header "Discarded-X400-MTS-Extensions:".
...
...
The following EBNF is defined for extended RFC 822std11(-> 2822prop) headers:
mta-field = "X400-Received" ":" x400-trace ...
... 822std11(-> 2822prop) message all trace fields (X400-Received
and Received) shall be at the beginning of the header, before any
other fields. Trace shall be in chronological order, with the most
...
... it enables the original message to be extracted. For negative
reports it shall be included if the original message is available.
For positive reports headers from the message shall be included if
the original message is available.
...
... element is mapped to an "X400-Originator-and-DL-Expansion-
History:" They shall be ordered so that the most recent expansion
comes first in the header (same order as trace).
...
...
The following additional mappings are made, which results in fields
in the outer header of the DSN.
...
... per-message-indicators.content-
return-request is set to FALSE, the parameter RET may be set to
HDRS, to specify return of headers only.
...
... IPMS level, and
this shall be replaced by the RFC 987(-> 2156prop | 1327(-> 2156prop)) approach. All header
information which would usually be mapped into the rfc-822-heading-
list extension is mapped into a single IA5 body part, which is the
...
... first body part in the message. This body part will start with the
string "RFC-822-Headers:" as the first line. The headers then follow
this line. This specification requires correct reverse mapping of
...
... start with the
string "RFC-822-Headers:" as the first line. The headers then follow
this line. This specification requires correct reverse mapping of
this format, either from 1988 or 1984. RFC 822std11(-> 2822prop) ...
... this line. This specification requires correct reverse mapping of
this format, either from 1988 or 1984. RFC 822std11(-> 2822prop) extended headers
which could be mapped into X.400(1988) elements ...
... id-rfc-822-field-list OBJECT IDENTIFIER ::= {mixer-core 2}
id-dsn-header-list OBJECT IDENTIFIER ::= {mixer-core 3}
id-dsn-field-list OBJECT IDENTIFIER ...
... 5. Detailed Mappings
- Define extended IPM Header, and use instead of second body
part for RFC 822std11(-> 2822prop) extensions
...
... element names
- New syntax for reports, simplifying the header and
introducing a mandatory body format (the RFC 987(-> 2156prop | 1327(-> 2156prop)) header
format ...
... header and
introducing a mandatory body format (the RFC 987(-> 2156prop | 1327(-> 2156prop)) header
format was unusable)
- Drop complex autoforwarded mapping
...
... id-rfc-822-field-list OBJECT IDENTIFIER ::= {mixer-core 2}
id-dsn-header-list OBJECT IDENTIFIER ::= {mixer-core 3}
id-dsn-field-list OBJECT IDENTIFIER ...