element
Click on the red underlined text to get to the source
... X.400", which
is a convenient shorthand. Any reference to the 1984 Recommendations
will be explicit. Any mappings relating to elements which are in the
1992 version and not in the 1988 version ...
... ASCII text. The header is divided into fields, which
are the protocol elements. Most of these fields are analogous to IPM
heading fields, although some are analogous to MTS Service ...
... MTS Service
Elements and RFC 822std11(-> 2822prop) mapping onto an IPM, but there is a not a clear
match between these services ...
... Elements, and MTA Service Elements on one side are mapped into RFC
822std11(-> 2822prop) + SMTP ...
... Chapters 3-5, the mappings between character sets, and some
fundamental protocol elements.
4. Addressing ...
...
Supported
The corresponding protocol elements map well, and so the service
can be fully provided.
...
...
For reception, the list of service elements required to support this
mapping is specified. This is really an indication of what a
recipient might expect to see in a message which has been remotely
...
... RFC 822std11(-> 2822prop) does not explicitly define service elements, as distinct from
protocol elements. However, all of the RFC 822std11(-> 2822prop) ...
... service elements, as distinct from
protocol elements. However, all of the RFC 822std11(-> 2822prop) header fields, with
...
... display these heading extensions. Support for the various service
elements (headers) is now listed.
...
... services
onto these new headers. Other elements are provided, in part, by the
gateway as they cannot be provided by RFC 822std11(-> 2822prop) ...
...
Some service elements are marked N/A (not applicable). There are
five cases, which are marked with different comments:
...
...
N/A (local)
These elements are only applicable to User Agent / Message
Transfer Agent interaction and so they cannot apply to RFC 822std11(-> 2822prop) ...
... N/A (PDAU)
These service elements are only applicable where the recipient is
reached by use of a Physical Delivery ...
...
Finally, some service elements are not supported. In particular, the
new security services are not mapped onto RFC 822std11(-> 2822prop) ...
... 822std11(-> 2822prop). Unless otherwise
indicated, the behaviour of service elements marked as not supported
will depend on the criticality marking supplied by the user. If the
...
... will depend on the criticality marking supplied by the user. If the
element is marked as critical for transfer or delivery, a non-
...
... error reports by use of IP messages. In other service elements,
this pragmatic result can be treated as effective support of this
service ...
... this pragmatic result can be treated as effective support of this
service element.
Original Encoded Information Types ...
... ASN.1, whereas RFC 822std11(-> 2822prop) is text encoded. To define a detailed
mapping, it is necessary to refer to detailed protocol elements in
each format. A notation to achieve this is described in this
section.
...
...
An element is referred to with the following syntax, defined in EBNF:
...
... a component. The special EBNF.identifier keyword "value" is used to
denote an element of a sequence. For example, IPMS.Heading.subject
...
... subject
defines the subject element of the IPMS heading. The same syntax is
also used to refer to element ...
... element of the IPMS heading. The same syntax is
also used to refer to element values. For example,
MTS.EncodedInformationTypes.[0].g3Fax ...
... ASCII, and needs to be
mapped into X.400 elements encoded as printable string. For this
reason, a mechanism to represent ASCII encoded as PrintableString is
...
... encoding other character set
information into elements of RFC 822std11(-> 2822prop) Headers. A gateway ...
... A gateway which interprets header elements according to RFC 1522(-> 2049draft | 2048(-> 4289 | 4288) | 2047draft | 2046draft | 2045draft) may
apply reasonable heuristics ...
... attribute value pairs. For domain defined attributes, each
element of the sequence will be mapped onto a triple (key and two
values), with each value having the same encoding. The attributes
...
... heuristics. The
address element separator on input may be "/", ";", or a mixture of
these. The output format is used in all examples.
...
...
The equivalence mapping also provides a mechanism to deal with
missing elements in the X.400 hierarchy (most commonly the PRMD,
which is the only element ...
... elements in the X.400 hierarchy (most commonly the PRMD,
which is the only element that may be ommitted when conforming to
recent versions of X.400 ...
... Example 1: (Address with missing X.400 elements and no specific
mapping rule for "o=sales; a=Master400; C=it", where a mapping exists
for a=master400; C=it;)
...
...
Example 3: (Address containing elements not mappable into RFC 822std11(-> 2822prop)
local part)
...
... 822std11(-> 2822prop) Header using this extension, an RFC822Field
element is built using the 822.field omitting the trailing CRLF
(e.g., "Fruit-Of-The-Day: Kiwi Fruit"). All fields shall be unfolded.
...
... header (i.e., in
chronological order). When other trace elements (in particular
X400-Received:) are processed the relative ordering (top to
bottom of the header ...
... header) shall be retained correctly.
The initial element of MTA.PerMessageTransferFields.trace-
...
... MTS.GlobalDomainIdentifier
is set from local information. If this is different from the one
in the last element of MTA.PerMessageTransferFields.trace-
...
... trace stripping are discussed below.
Then add a new element (MTA.InternalTraceInformationElement) to
MTA ...
... trace-
information. In cases where X400-Received: is present, the usual
mapping of Date: to generate the first element of trace shall not be
done. This is because the message has come from X.400 ...
... done. This is because the message has come from X.400, and so the
first element of trace can be taken from the first X400-Received:.
...
... and if not from the Date: of the DSN. This is a strucutred field,
and the Report element contains the key information on the
recipient. For a DeliveryReport, the type-ofMTS-user is defaulted
to public and the message-deliery-time is set to the same as the
...
... The mappings and actions for the IPMS.Heading are now specified for
each element. Addresses and Message Identifiers are mapped according
...
... to Chapter 4. Other mappings are explained, or are straightforward
(algorithmic). If a field with addresses contains zero elements, it
shall be discarded, except for IPMS.Heading.blind-copy-recipients,
...
... acknowledgement-mode = "Manually" / "Automatically"
The mappings for elements of the common fields of IPMS.IPN
(IPMS ...
... Mapped to EBNF.encoded-info in EBNF.ipn-extra-information
The mappings for elements of IPMS.IPN.non-receipt-fields
(IPMS ...
...
The mappings for each element of MTS.MessageDeliveryEnvelope can now
be considered. Where the specified action does not result in an
...
... MTS.MessageDeliveryEnvelope can now
be considered. Where the specified action does not result in an
extended element being mapped, the criticality associated with this
element shall be considered. If the element is marked as critical ...
... be considered. Where the specified action does not result in an
extended element being mapped, the criticality associated with this
element shall be considered. If the element is marked as critical
...
... extended element being mapped, the criticality associated with this
element shall be considered. If the element is marked as critical
for transfer or for delivery ...
... Discarded, as this time will be represented in an appropriate
trace element.
The mappings for elements ...
...
this-recipient-name and other-recipient-names
The handling of these elements is described in Section 4.6.2.
originally-intended-recipient-name
...
...
originally-intended-recipient-name
The handling of this element is described in Section 4.6.2.
converted-encoded-information-types
...
... delivery-request
These elements imply use of security services not available in the
RFC 822std11(-> 2822prop) ...
...
dl-expansion-history
Each element is mapped to an extended RFC 822std11(-> 2822prop) field "DL-
Expansion-History:". These fileds shall be ordered in the message
header ...
... gateway: that is, the gateway may
hold the message until the time specified in the protocol element.
Thus, the value of this element will usually be in the past. For
...
... hold the message until the time specified in the protocol element.
Thus, the value of this element will usually be in the past. For
this reason, the extended RFC 822std11(-> 2822prop) field is primarily for information.
...
... domains has not been stripped, this may require complex interleaving.
Where an element of internal trace and external trace are identical,
...
... trace, only the internal trace
element shall be presented. Use this to generate a sequence of
"X400-Received:" fields. The only difference between external trace
...
... other fields. Trace shall be in chronological order, with the most
recent element at the front of the message. This ordering is
determined from the order of the fields, not from timestamps in the
...
...
EBNF.dr-recipients
There is an element for each recipient in the delivery report. In
each case, EBNF.mailbox ...
... 822std11(-> 2822prop) form of the
originally specified recipient, which is taken from the originally
specified recipient element if present or from the actual
recipient. When reporting success, the message delivery time is
...
... DSN.mta-name has its syntax specified by
EBNF.report-point, with the information derived from the first
element of the DR's trace.
...
... MIXER conversion.
The elements of MTS.ReportDeliveryEnvelope.per-report-fields are
mapped as follows onto the DSN ...
...
originator-and-DL-expansion-history
Each 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 ...
... redirection-history
Generate an "X400-Redirection-History:" field for each redirect
history element. The fields are ordered with the earliest
redirect first.
...
... 822std11(-> 2822prop) field "X400-Received:", as
described in Section 5.3.7. Date: is generated from the first
element of trace.
...
... "rfc822", this may be used at the MTS level, to generate an
element of redirection history, with the redirection date being
the date of conversion and the reason set to "alias".
...
... pseudo-value "@" (not a printable string character) is used to
indicate omission of a level in the hierarchy. This is distinct from
the form including the element with no value, although a correct
X.400 implementation will interpret both in the same manner.
...
... claimed if any of the mandatory features are not implemented. A
specification of conformance may list the service elements of Chapter
2, in order to be clear that full conformance is provied. In
particular:
...
...
RFC 987(-> 2156prop | 1327(-> 2156prop)) was the original document, and contained the key elements of
this specification. It was specific to X.400(1984). RFC 1026(-> 2156prop | 1327(-> 2156prop)) ...
... 822std11(-> 2822prop) extensions
- Realignment of element names
- New syntax for reports, simplifying the header ...