encoding of the 822.msg-id without the angle braces and omit
IPMS.IPMID.user.
4.7.3.4. IPMS.IPMIdentifier -> 822.msg-id
If IPMS.IPMIdentifier.user is absent, and IPMS.IPMIdentifier.user-
relative-identifier mapped to ASCII and angle braces added parses as
822.msg-id, then this is an RFC822 generated ID.
Otherwise, the ID is X.400 generated. Use the
IPMS.IPMIdentifier.user to generate an EBNF.std-or-address form
string. Build the 822.local-part of the 822.msg-id with the syntax:
[ printablestring ] "*" [ std-or-address ]
The printablestring is taken from IPMS.IPMIdentifier.user-relative-
identifier. Use 822.quoted-string if necessary. The 822.msg-id is
generated with this 822.local-part, and "MHS" as the 822.domain.
4.7.3.5. Phrase form
In "In-Reply-To:" and "References:", the encoding 822.phrase may be
used as an alternative to 822.msg-id. To map from 822.phrase to
IPMS.IPMIdentifier, assign IPMS.IPMIdentifier.user-relative-
identifier to the phrase. When mapping from IPMS.IPMIdentifier for
"In-Reply-To:" and "References:", if IPMS.IPMIdentifier.user is
absent and IPMS.IPMIdentifier.user-relative-identifier does not parse
as 822.msg-id, generate an 822.phrase rather than adding the domain
MHS.
4.7.3.6. RFC987 backwards compatibility
The mapping defined here is different to that used in RFC987, as the
RFC987 mapping lead to changed message IDs in many cases. Fixing
the problems is preferable to retaining backwards compatibility. An
implementation of this standard may recognise message IDs generated
by RFC987. This is not recommended.
RFC987 generated encodings may be recognised as follows. When
mapping from X.400 to RFC822, if the IPMS.IPMIdentifier.user-
relative-identifier is "RFC-822" the id is RFC987 generated. When
mapping from RFC822 to X.400, if the 822.domain is not "MHS", and
the 822.local-part can be parsed as
[ printablestring ] "*" [ std-or-address ]
then it is RFC987 generated. In each of these cases, it is
recommended to follow the RFC987 rules.
Chapter 5 - Detailed Mappings
This chapter specifies detailed mappings for the functions outlined
in Chapters 1 and 2. It makes extensive use of the notations and
mappings defined in Chapters 3 and 4.
5.1. RFC822 -> X.400: Detailed Mappings
The mapping of RFC822/MIME messages to X.400 InterPersonal Messages
is described in Sections 5.1.1 to 5.1.7. Mapping of NOTARY format
delivery status notifications, which are all messages of type
multipart/report and subtype delivery-status-notifications to X.400
delivery reports is covered in Section 5.1.8.
5.1.1. Basic Approach
A single IP Message is generated from an RFC822 message. The RFC
822 headers are used to generate the IPMS.Heading.
Some RFC822 fields cannot be mapped onto a standard IPM Heading
field, and so an extended field is defined in Section 5.1.2. This is
then used for fields which cannot be mapped onto existing services.
The message is submitted to the MTS, and the services required can be
defined by specifying MTS.MessageSubmissionEnvelope. A few
parameters of the MTA Abstract service are also specified, which are
not in principle available to the MTS User. Use of these services
allows RFC822 MTA level parameters to be carried in the analogous
X.400 service elements. The advantages of this mapping far outweigh
the layering violation.
5.1.2. X.400 Extension Field
An IPMS Extension is defined:
rfc-822-field HEADING-EXTENSION
VALUE RFC822FieldList
::= id-rfc-822-field-list
RFC822FieldList ::= SEQUENCE OF RFC822Field
RFC822Field ::= IA5String
The Object Identifier id-rfc-822-field-list is defined in Appendix D.
To encode any RFC822 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.
There shall be no space before the ":". The reverse mapping builds
the RFC822 field in a straightforward manner. This RFC822Field is
appended to the RFC822FieldList, which is added to the IPM Heading as
an extension field.
5.1.3. Generating the IPM
The IPM (IPMS Service Request) is generated according to the rules of
this section. The IPMS.IPM.body is generated from the RFC822 message
body in the manner described in Section 5.1.5.
If no specific 1988 features are used, the IPM generated is encoded
as content type 2. Otherwise, it is encoded as content type 22. The
latter will always be the case if extension heading fields are
generated.
When generating the IPM, the issue of upper bounds are handled as
follows. Truncate fields to the upper bounds specified in X.400.
This will prevent problems with UAs which enforce upper bounds, but
will sometimes discard useful information. This approach will cause
more problems for some fields than others (e.g., truncating an OR
Address component that would be used to route a reply would be a more
severe problem than truncating a Free Form Name). If the Free Form
name is truncated, it shall be done so that it does not break RFC822
comments and RFC1522 encoding.
Note:This approach removes a choice of options given in RFC1327,
based on operational experience.
The rest of this section concerns IPMS.IPM.heading (IPMS.Heading).
The only mandatory component of IPMS.Heading is the
IPMS.Heading.this-IPM (IPMS.IPMIdentifier). A default is generated
by the gateway. With the exception of "Received:", the values of
multiple fields are merged (e.g., If there are two "To:" fields, then
the mailboxes of both are merged to generate a single list which is
used in the IPMS.Heading.primary-recipients. Information shall be
generated from the standard RFC822 Headers as follows:
Date:
Ignore (Handled at MTS level)
Received:
Ignore (Handled at MTA level)
Message-Id:
Mapped to IPMS.Heading.this-IPM. For these, and all other
fields containing 822.msg-id the mappings of Chapter 4 are used
for each 822.msg-id.
From:
If Sender: is present, this is mapped to
IPMS.Heading.authorizing-users. If not, it is mapped to
IPMS.Heading.originator. For this, and other components
containing addresses, the mappings of Chapter 4 are used for
each address.
Sender:
Mapped to IPMS.Heading.originator. Because X.400 does not have
the same From/Sender distinction as RFC822, this mapping is not
always natural and may lead to unexpected results in some cases.
Reply-To:
Mapped to IPMS.Heading.reply-recipients.
To: Mapped to IPMS.Heading.primary-recipients
Cc: Mapped to IPMS.Heading.copy-recipients.
Bcc: Mapped to IPMS.Heading.blind-copy-recipients if there is at
least one BCC: recipient. If there are no recipients in this
field, it shall either be mapped to a zero length sequence or
mapped to a single recipient that has a free from name "BCC" and
no other addressing information. This alternate treatment is
allowed because some X.400 systems cannot handle a zero lenght
sequence of addresses.
In-Reply-To:
If there is one value, it is mapped to IPMS.Heading.replied-to-
IPM, using the 822.phrase or 822.msg-id mapping as appropriate.
If there are multiple values, this cannot be done as the X.400
heading is single valued. In this case no IPMS.Heading.replied-
to-IPM is generated and the values are mapped to
IPMS.Heading.related-IPMs, along with any values from a
"References:" field.
References:
Mapped to IPMS.Heading.related-IPMs.
Keywords:
Mapped onto a heading extension.
Subject:
Mapped to IPMS.Heading.subject. The field-body uses the human
oriented mapping referenced in Section 3.3.4.
Comments:
Mapped onto a heading extension.
This is a change from 1327, which specified to generate an
IPMS.BodyPart of type IPMS.IA5TextBodyPart with
IPMS.IA5TextBodyPart.parameters.repertoire set to the default
(ia5), containing the value of the fields, preceded by the
string "Comments: " and that this body part shall precede the
other one. Experience has shown that this complexity is not
justified. This text is retained to facilitate backwards
compatibility.
Encrypted:
Mapped onto a heading extension.
Resent-*
Mapped onto a heading extension.
Note that it would be possible to use a ForwardedIPMessage for
these fields, but the semantics are (arguably) slightly
different, and it is probably not worth the effort.
Content-Language:
This field is defined in RFC1766 [7]. Map the first two
characters of each value given onto the IPM Languages extension.
If any comments or values longer than two characters occur, a
header extension shall also be generated.
Other Fields
In particular X-* fields, and "illegal" fields in common usage
(e.g., "Fruit-of-the-day:") are mapped onto a heading extension,
unless covered by another section or appendix of this
specification. The same treatment is applied to RFC822 fields
where the content of the field does not conform to RFC822
(e.g., a Date: field with unparseable syntax).
The mapping of the following headings is defined in RFC2157.
MIME-Version: 5
Content-Transfer-Encoding:
Content-Type
Content-ID
Content-Description
5.1.4. Generating the IPM Body
Generation of the IPM Body is defined in RFC2157.
5.1.5. Mappings to the MTS Abstract Service
The MTS.MessageSubmissionEnvelope comprises
MTS.PerMessageSubmissionFields, and
MTS.PerRecipientMessageSubmissionFields. The mandatory parameters
are defaulted as follows.
MTS.PerMessageSubmissionFields.originator-name
This is always generated from SMTP, as defined in Chapter 4.
MTS.PerMessageSubmissionFields.content-type
Set to the value implied by the encoding of the IPM (2 or 22).
MTS.PerRecipientMessageSubmissionFields.recipient-name
These will always be supplied from SMTP, as defined in Chapter 4.
Optional components are omitted, and default components defaulted.
This means that disclosure of recipients is prohibited and conversion
is allowed. There are two exceptions to the defaulting. For
MTS.PerMessageSubmissionFields.per-message-indicators, the following
settings are made:
- Alternate recipient is allowed, as it seems desirable to
maximise the opportunity for (reliable) delivery.
If SMTP is used, Appendix A shall be followed in setting these
parameters.
The trace is set to indicate conversion (described below) and the
encoded information types in the trace is derived from the message
generated by the gateway, and shall reflect all body parts (including
those in enclosed messages). In addition it shall include the
Encoded Information Type "eit-mixer", which is defined in Appendix D.
The presence of the EIT will indicate to the X.400 recipient that a
MIXER conversion has occurred.
MTS.PerMessageSubmissionFields.original-encoded-information-types
will include all of the values used in the trace, unless specified
otherwise in RFC2157.
This type of conversion will prevent the normal loop detection from
working in certain circumstances, and introduces the possiblity of
gateway loops. MIXER gateways shall therefore count the number of
MIXER conversions made. If this count exceeds five in one direction,
the message shall be treated as if a loop has been detected.
The MTS.PerMessageSubmissionFields.content-correlator is encoded as
IA5String, and contains the Subject:, Message-ID:, Date:, and To:
fields (if present) in this order. This includes the strings
"Subject:", "Date:", "To:", "Message-ID:", and appropriate folding to
make the field appear readable. This shall be truncated to MTS.ub-
content-correlator-length (512) characters. In addition, if there is
a "Subject:" field, the MTS.PerMessageSubmissionFields.content-
identifier, is set to a printable string representation of the
contents of it. If the length of this string is greater than
MTS.ub-content-id-length (16), it shall be truncated to 13 characters
and the string "..." appended. Both are used, due to the much larger
upper bound of the content correlator, and that the content id is
available in X.400(1984).
5.1.6. Mappings to the MTA Abstract Service
There is a need to map directly onto some aspects of the MTA Abstract
service, for the following reasons:
- So the MTS Message Identifier can be generated from the RFC
822 Message-ID:.
- So that the submission date can be generated from the
822.Date.
- To prevent loss of trace information
- To prevent RFC822/X.400 looping caused by distribution
lists or redirects
The following mappings are defined.
Message-Id:
If this is present and no Resent: fields are present, the
MTA.PerMessageTransferFields.message-identifier may be generated
from it, using the mappings described in Chapter 4.
This mapping arguably generates messages which do not conform to
US GOSIP (1984 version only), which states:
6.7.e MPDU Identifier Validation
(1) Validation of the GlobalDomainIdentifier component of the MPDU
Identifier is performed on reception of a message (i.e. the result
of a TRANSFER.Indication).
(2) The country name should be known to the validating domain, and
depending on the country name, validation of the
ADMD name may also be possible.
(3) Additional validation of the GlobalDomainIdentifier is
performed against the corresponding first entry in the
TraceInformation. If inconsistencies are found during the
comparison, a non-delivery notice with the above defined reason
and diagnostic code is generated.
(4) A request will be generated to the CCITT for a more meaningful
diagnostic code (such as "InconsistentMPUTIdentifier").
This applies to ADMDs only, and is specified in the 1984 version and
not the 1988 version. Conformance depends on the interpretation of
"inconsistency". The specification makes the most sensible choice,
and so is not being changed in the update from RFC1327.
Date: (and Resent-Date:)
If one or more Resent-Date: fields is present, the most recent
Resent-Date: field shall be used instead of the Date: field in the
following description.
The Date: field is used to set the first component of
MTA.PerMessageTransferFields.trace-information
(MTA.TraceInformationElement). The SMTP originator is mapped into
an MTS.ORAddress, and used to derive
MTA.TraceInformationElement.global-domain-identifier. The
optional components of MTA.TraceInformationElement.domain-
supplied-information are omitted, and the mandatory components are
set as follows:
MTA.DomainSuppliedInformation.arrival-time
This is set to the date derived from Date:
MTA.DomainSuppliedInformation.routing-action
Set to relayed.
The first element of MTA.PerMessageTransferFields.internal-trace-
information is generated in an analogous manner, although this can
be dropped later in certain circumstances (see the procedures for
"Received:"). The MTA.InternalTraceInformationElement.mta-name is
derived from the 822.domain in the 822 MTS Originator address.
Received:
All RFC822 trace is used to derive
MTA.PerMessageTransferFields.trace-information and
MTA.PerMessageTransferFields.internal-trace-information.
Processing of Received: lines follows processing of Date:, and is
done from the bottom to the top of the RFC822 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) shall be retained correctly.
The initial element of MTA.PerMessageTransferFields.trace-
information shall be generated from Date: as described above,
unless the message has previously been in X.400, when it will be
derived from the X.400 trace information.
For each Received: field, the following processing shall be done.
If the "by" part of the received is present and there is an
available MCGAM which can map this domain, use it to derive an
MTS.GlobalDomainIdentifier. Otherwise MTS.GlobalDomainIdentifier
is set from local information. If this is different from the one
in the last element of MTA.PerMessageTransferFields.trace-
information (MTA.TraceInformationElement.global-domain-identifier)
create a new MTA.TraceInformationElement, and optionally remove
MTA.PerMessageTransferFields.internal-trace-information.
Requirements on trace stripping are discussed below.
Then add a new element (MTA.InternalTraceInformationElement) to
MTA.PerMessageTransferFields.internal-trace-information, creating
this if needed. This shall be done, even if nter-MD trace is
created. The MTA.InternalTraceInformationElement.global-domain-
identifier is set to the value derived. The
MTA.InternalTraceInformationElement.mta-supplied-information
(MTA.MTASuppliedInformation) is set as follows:
MTA.MTASuppliedInformation.arrival-time
Derived from the date of the Received: line
MTA.MTASuppliedInformation.routing-action
Set to relayed
The MTA.InternalTraceInformationElement.mta-name is taken from the
"by" component of the "Received:" field, truncated to MTS.ub-mta-
name-length (32). For example:
Received: from computer-science.nottingham.ac.uk by
vs6.Cs.Ucl.AC.UK via Janet with NIFTP id aa03794;
28 Mar 89 16:38 GMT
Generates the string
vs6.Cs.Ucl.AC.UK
The gateway shall add in a single element of trace information,
reflecting the gateway's local information and the time of
conversion. The MTA.InternalTraceInformationElement.mta-supplied-
information (MTA.MTASuppliedInformation) is set as follows:
MTA.DomainSuppliedInformation.arrival-time
Set to the time of conversion
MTA.DomainSuppliedInformation.routing-action
Set to relayed
MTA.AdditionalAcctions.converted-encoded-information-types Set to
correct set of EITs for the message that is generated by the gateway.
This trace element will thus reflect gateway operation as a
conversion.
This trace generation will often lead to generation of substantial
amounts of trace information, which does not reflect X.400 transfers.
Stripping of some of this trace may be necessary in some operational
environments. This stripping shall be considered a function of the
associated X.400 MTA, and not of the MIXER gateway.
5.1.7. Mapping New Fields
This specification defines a number of new fields for Reports,
Notifications and IP Messages. A gateway conforming to this
specification shall map all of these fields to X.400, except as
defined below.
The mapping of two extended fields is particularly important, in
order to prevent looping. "DL-Expansion-History:" is mapped to
MTA.PerMessageTransferFields.extensions.dl-expansion-history X400-
Received: shall be mapped to MTA.PerMessageTransferFields.trace-
information and MTA.PerMessageTransferFields.internal-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, and so the
first element of trace can be taken from the first X400-Received:.
The following fields shall not be mapped, and shall be
- Discarded-X400-MTS-Extensions:
- Message-Type:
- Discarded-X400-IPMS-Extensions:
- X400-Content-Type:
- X400-Originator:
- X400-Recipients:
- X400-MTS-Identifier: Mapping this field would be useful in
some circumstances, but very dangerous in others (e.g.,
following an internet list expansion). Therefore it is not
mapped.
5.1.8. Mapping Delivery Status Notifications to X.400
5.1.8.1. Basic Model
Internet Mail delivery status notifications (DSN) are mapped to X.400
delivery reports. With message mapping, information without a
mapping is carried by an IPM Extension. This cannot be done for
delivery reports. Two mechanisms are used for information where
there is not a direct mapping.
The first mechanism is to define extensions, which allow all of the
DSN information to be carried in the delivery report. This is not
completely satisfactory for two reasons:
1. User defined extensions are supported by the ISO version of
the standard, but not the CCITT one. Therefore,
implementation support for these extensions will not be
universal.
2. X.400 User Agent implementations will not in general
recognise these extensions. Therefore, although the
information will be present, it will often not be available
to the user. This may be very problematic, as this
information may be critical to diagnosing the reason for a
failure.
Therefore a second mechanism is defined. This shall always be used
when the DSN contains non-delivery information, and may be used in
other cases. This mechanism is to map the whole DSN (as if it were
an ordinary multipart) into the return of content. This will make
the DSN information available as a text body part in the outer
message, with the real returned content as an enclosed message. This
mechanism will ensure that information is not lost at the gateway.
5.1.8.2. DSN Extensions
Two X.400 MTS extensions are defined as follows:
dsn-header-list EXTENSION
RFC822FieldList
::= id-dsn-header-list
dsn-field-list EXTENSION
RFC822FieldList
::= id-dsn-field-list
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
extensions may only be used with ISO-10021, and not X.400 (which does
not allow user extensions at the MTS level).
5.1.8.3. DSN to Delivery Report Mapping
Some DSNs are mapped to Delivery Reports and some to IPMs, according
to the value of the action field. The mapping to an IPM is exactly
as for a normal IPM mapping. The choice of IPM and Delivery report
is made for each reported recipient. If this choice is different
for different reported recipients both a Delivery Report and an IPM
shall be generated.
Reports are not be submitted in the X.400 model, and so the report
submission is considered in terms of the MTA Abstract Service. An
MTA.Report is constructed. The MTA.ReportTransferEnvelope.report-
identifier is generated from the Message-Id of the DSN (if present)
and otherwise generated as the MTA would generate one for a submitted
message.
The DSN has an RFC822 header. Trace is mapped in the same manner as
for a message to MTA.ReportTransferEnvelope.trace-information. All
other headers are used to create a dsn-header-list extension, which
is added to MTA.PerReportTransferFields.extensions. The DSN will
have a single SMTP recipient. This is mapped to the
MTA.ReportTransferEnvelope.report-destination-name.
The DSN is then treated as a normal MIME message, and an X.400 IPM is
generated. This IPM is used as
MTA.PerReportTransferFields.returned-content, and its type is used to
set MTA.PerReportTransferFields.content-type. The DSN body part is
mapped as if it was IA5 text/plain.
The mandatory MTA.PerReportTransferFields.subject-identifier shall be
generated from the DSN.per-message-field original-envelope-id, if
this starts with the string "X400-MTS-Identifier: ", and derived from
the rest of the field, which is encoded as EBNF.mts-msg-id. In other
cases, this field shall be generated by the MIXER Gateway.
All other mappings are made from the DSN body part. A dsn-field-list
extension is created and added to
MTA.ReportTransferFields.extensions. This is referred to as the per
report extension list. The DSN.per-message-fields are mapped as
follows:
original-envelope-id-field
reporting-mta-field
dsn-gateway-field
received-from-mta-field
arrival-date-field
extension-field
other
All of these fields are added to the per report extension list.
Currently there are no other mappings defined.
Each reported recipient is considered in turn, and a
MTA.PerRecipientReportTransferFields created for each. The
parameters of this are defaulted as follows:
originally-specified-recipient-number
In general, these are not available, and so are assigned
incrementally.
last-trace-information
The arrival-time is generated from DSN.arrival-date if present,
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
arrival-time. For a NonDeliveryReport, the code mappings are
define in Section 5.1.8.4.
A dsn-field-list extension is created and added to
MTA.PerRecipientTransferFields.extensions. This is referred to as
the per recipient extension list. The DSN.per-recipient-fields are
mapped as follows
original-recipient-field
Mapped to MTA.PerRecipientReportTransferFields.originally-
intended-recipient-name.
final-recipient-field
Mapped to MTA.PerRecipientReportTransferFields.actual-recipient-
name.
action-field
If this is set to "failed", a non-delivery report is generated.
If this is set to "delivered" a delivery report is generated.
Bit one or two of MTA.PerRecipientTransferFields.per-recipient-
indicators is set accordingly. This also controls the encoding of
MTA.PerRecipientTransferFields.last-trace-information, and the
selection of the report type.
For other values of the action-field ("delayed", "relayed",
"expanded"), an IPM is generated. This enables the status
information to be communicated to the X.400 user, without the
confusion of multiple delivery reports.
status-field
This is added to the per report extension list. For non-delivery,
it is also used to generate the reason and diagnostic codes
contained within MTA.PerRecipientReportTransferFields.last-trace.
The mappings are defined below.
remote-mta-field
diagnostic-code-field
last-attempt-date-field
will-retry-until-field
extension-field
other
All of these fields are added to the per recipient extension list.
5.1.8.4. Status Value Mappings
Status values are mapped to X.400 reason and diagnostic codes as
follows.
If a status value is found that is not in this table, the gateway may
use the same mapping as for "X.n.0" (1/None or 0/None), or it may map
to another, configurable code. Implementors are requested to forward
new codes to the mixer list for inclusion in future versions of this
standard. So for instance. "5.2.37", currently undefined, would map
onto the same as "5.2.0", namely 1/None.
DSN code Meaning X400 code Meaning
X.0.0 Other status 1/None
X.1.0 Other Address Status 1/None
X.1.1 Bad mailbox address 1/0 Unrecognized
X.1.2 Bad system address 1/0 Unrecognized
X.1.3 Bad mailbox address syntax 1/0 Unrecognized
X.1.4 Mailbox address ambiguous 1/1
X.1.5 Only used for positive reports, not applicable
X.1.6 Destination mailbox has moved 1/43 New addr unknown
X.1.7 Bad sender's mailbox address syntax 1/11 Invalid arguments
X.1.8 Bad sender's system address 1/11 Invalid arguments
X.2.0 Other or undefined mailbox status 1/None
X.2.1 Mailbox disabled, not accepting 1/4 Recipient unavail
X.2.2 Mailbox full 1/4
X.2.3 Message length exceeds admin limit. 1/7 Content too long
X.2.4 Mailing list expansion problem 1/30 DL expansion fail
X.3.0 Other or undefined system status 0/None
X.3.1 System full 1/2 MTS congestion
X.3.2 System not accepting network messages 1/2 MTS congestion
X.3.3 System not capable of selected feat 1/18 Unsupp crit func
X.3.4 Message too big for system 1/7
X.3.5 System incorrectly configured 1/None
X.4.0 Other or undefined network or routing 0/None
X.4.1 No answer from host 0/None
X.4.2 Bad connection 0/None
X.4.3 Routing server failure 6/None Dir op unsucc.
X.4.4. Unable to route 0/None
X.4.5 Network congestion 1/2 MTS congest.
X.4.6 Routing loop detected 1/3
X.4.7 Delivery time expired 1/5
X.5.0 Other or undefined protocol status 1/None
X.5.1 Invalid command 1/14 Protocol viol.
X.5.2 Syntax error 1/14
X.5.3 Too many recipients 1/16
X.5.4 Invalid command arguments 1/14
X.5.5 Wrong protocol version 1/18 Unsupp.crit.func
X.6.0 Other or undefined media error 2/None Conv. not perf
X.6.1 Media not supported 1/6 EIT unsupp.
X.6.2 Conversion required and prohibited 1/9
X.6.3 Conversion required but not supported 2/8
X.6.4 Conversion with loss performed POSITIVE only
X.6.5 Conversion failed 2/47 Unable to downgrade
X.7.0 Other or undefined security status 1/46
X.7.1 Delivery not authorized, message ref 1/29 No DL submit perm
X.7.2 Mailing list expansion prohibited 1/28
X.7.3 Security conversion req but not poss 1/46 Secure mess. error
X.7.4 Security features not supported 1/46
X.7.5 Cryptographic failure 1/46
X.7.6 Cryptographic algorithm not supported 1/46
X.7.7 Message integrity failure 1/46
5.1.8.5. DSNs that originated in X.400
The mapping of X.400 delivery reports to DSNs will in general provide
sufficient information to make a useful reverse mapping. Messages
will often be mapped multiple times, commonly due to forwarding
messages and to distribution lists. Multiple mappings for delivery
reports will be a good deal less common. For this reason, the
reverse mapping of the X.400 DSN extensions defined in MIXER is
optional.
5.2. Return of Contents
RFC1327 offered two approaches for return of content, as this
service is optional in X.400 and expected in RFC822. MIXER simply
requires that a gateway requests the return of content service from
X.400.
5.3. X.400 -> RFC822: Detailed Mappings
5.3.1. Basic Approach
A single RFC822 message is generated from the incoming IP Message,
Report, or IP Notification. All IPMS.BodyParts are mapped onto a
single RFC822 body. Other services are mapped onto RFC822 header
fields. Where there is no appropriate existing field, new fields are
defined for IPMS, MTS and MTA services.
The gateway mechanisms will correspond to MTS Delivery. As with
submission, there are aspects where the MTA (transfer) services are
also used. In particular, there is an optimisation to allow for
multiple SMTP recipients.
5.3.2. RFC822 Settings
An RFC822 Message has a number of mandatory fields in the RFC822
Header. Some SMTP services mandate specification of an SMTP
Originator. Even in cases where this is optional, it is usually
desirable to specify a value. The following defaults are defined,
which shall be used if the mappings specified do not derive a value:
SMTP Originator
If this is not generated by the mapping (e.g., for a Delivery
Report), a value pointing at a gateway administrator shall be
assigned.
Date:
A value will always be generated
From:
If this is not generated by the mapping, it is assigned equal to
the SMTP Originator. If this is gateway generated, an appropriate
822.phrase shall be added.
At least one recipient field
If no recipient fields are generated, a field "To: list:;", shall
be added.
This will ensure minimal RFC822 compliance. When generating RFC822
headers, folding may be used. It is recommended to do this,
following the guidelines of RFC822.
5.3.3. Basic Mappings
5.3.3.1. Encoded Information Types
This mapping from MTS.EncodedInformationTypes is needed in several
disconnected places. EBNF is defined as follows:
encoded-info = 1#encoded-type
encoded-type = built-in-eit / object-identifier
built-in-eit = "Undefined" ; undefined (0)
/ "Telex" ; tLX (1)
/ "IA5-Text" ; iA5Text (2)
/ "G3-Fax" ; g3Fax (3)
/ "TIF0" ; tIF0 (4)
/ "Teletex" ; tTX (5)
/ "Videotex" ; videotex (6)
/ "Voice" ; voice (7)
/ "SFD" ; sFD (8)
/ "TIF1" ; tIF1 (9)
MTS.EncodedInformationTypes is mapped onto EBNF.encoded-info.
MTS.EncodedInformationTypes.non-basic-parameters is ignored. Built
in types are mapped onto fixed strings (compatible with X.400(1984)
and RFC987), and other types are mapped onto EBNF.object-identifier.
5.3.3.2. Global Domain Identifier
The following simple EBNF is used to represent
MTS.GlobalDomainIdentifier:
global-id = std-or-address
This is encoded using the std-or-address syntax, for the attributes
within the Global Domain Identifier.
5.3.4. Mappings from the IP Message
Consider that an IPM has to be mapped to RFC822. The IPMS.IPM
comprises an IPMS.IPM.heading and IPMS.IPM.body. The heading is
considered first. Some EBNF for new fields is defined:
ipms-field = "Supersedes" ":" 1*msg-id
/ "Expires" ":" date-time
/ "Reply-By" ":" date-time
/ "Importance" ":" importance
/ "Sensitivity" ":" sensitivity
/ "Autoforwarded" ":" boolean
/ "Incomplete-Copy" ":"
/ "Content-Language" ":" 1#language
/ "Message-Type" ":" message-type
/ "Discarded-X400-IPMS-Extensions" ":" 1#object-identifier
/ "Autosubmitted" ":" autosubmitted
importance = "low" / "normal" / "high"
sensitivity = "Personal" / "Private" /
"Company-Confidential"
language = 2*ALPHA [ "(" language-description ")" ]
language-description = printable-string
message-type = "Delivery Report"
/ "InterPersonal Notification"
/ "Multiple Part"
autosubmitted = "not-auto-submitted"
/ "auto-generated"
/ "auto-replied"
/ "auto-forwarded"
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,
which can be mapped onto BCC: (the only RFC822 field which allows
zero recipients).
IPMS.Heading.this-IPM
Mapped to "Message-ID:".
IPMS.Heading.originator
If IPMS.Heading.authorizing-users is present this is mapped to
Sender:, if not to "From:".
IPMS.Heading.authorizing-users
Mapped to "From:".
IPMS.Heading.primary-recipients
Mapped to "To:".
IPMS.Heading.copy-recipients
Mapped to "Cc:".
IPMS.Heading.blind-copy-recipients
Mapped to "Bcc:".
IPMS.Heading.replied-to-ipm
Mapped to "In-Reply-To:".
IPMS.Heading.obsoleted-IPMs
Mapped to the extended RFC822 field "Supersedes:". The replaces
the RFC1327 field "Obsoletes:". Reverse mapping of the RFC1327
field may be supported.
IPMS.Heading.related-IPMs
Mapped to "References:".
IPMS.Heading.subject
Mapped to "Subject:". The contents are converted to ASCII or T.61
(as defined in Section 3.5). CRLF will not be present in a valid
X.400 field. Any CRLF present are not mapped, but are used as
points at which the subject field shall be folded, unless an RFC
1522 encoding is used.
IPMS.Heading.expiry-time
Mapped to the extended RFC822 field "Expires:". The replaces the
RFC1327 field "Expiry-Date:". Reverse mapping of the RFC1327
field may be supported.
IPMS.Heading.reply-time
Mapped to the extended RFC822 field "Reply-By:".
IPMS.Heading.reply-recipients
Mapped to "Reply-To:".
IPMS.Heading.importance
Mapped to the extended RFC822 field "Importance:".
IPMS.Heading.sensitivity
Mapped to the extended RFC822 field "Sensitivity:".
IPMS.Heading.autoforwarded
Mapped to the extended RFC822 field "Autoforwarded:".
The standard extensions (Annex H of X.420 / ISO 10021-7) are mapped
as follows:
incomplete-copy
Mapped to the extended RFC822 field "Incomplete-Copy:".
language
Mapped to the RFC822 field "Content-Language:", defined in RFC
1766 [7]. This mapping may be made without loss of information.
auto-submitted
Map to the extended RFC822 field "Autosubmitted:".
If the RFC822 extended header is found, this shall be mapped onto an
RFC822 header, as described in Section 5.1.2.
If a non-standard extension is found, it shall be discarded, unless
the gateway understands the extension and can perform an appropriate
mapping onto an RFC822 header field. If extensions are discarded,
the list is indicated in the extended RFC822 field "Discarded-X400-
IPMS-Extensions:".
5.3.4.1. Mapping the IPMS Body
The mapping of the IPMS Body is defined in RFC2157.
5.3.4.2. Example Message
An example message, illustrating a number of aspects is given below.
Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with
NIFTP id <7906-0@bells.cs.ucl.ac.uk>;
Thu, 30 May 1991 18:24:55 +0100
X400-Received: by mta "mhs-relay.ac.uk" in /PRMD=uk.ac/ADMD= /C=gb/;
Relayed; Thu, 30 May 1991 18:23:26 +0100
X400-Received: by /PRMD=HMG/ADMD=GOLD 400/C=GB/; Relayed;
Thu, 30 May 1991 18:20:27 +0100
Message-Type: Multiple Part
Date: Thu, 30 May 1991 18:20:27 +0100
X400-Originator: Stephen.Harrison@gosip-uk.hmg.gold-400.gb
X400-MTS-Identifier:
[/PRMD=HMG/ADMD=GOLD 400/C=GB/;PC1000-910530172027-57D8]
Original-Encoded-Information-Types: ia5
X400-Content-Type: P2-1984 (2)
X400-Content-Identifier: Email Problems
From: Stephen.Harrison@gosip-uk.hmg.gold-400.gb (Tel +44 71 217 3487)
Message-ID: <PC1000-910530172027-57D8*@MHS>
To: Jim Craigie <NTIN36@gec-b.rutherford.ac.uk>,
Tony Bates <tony@ean-relay.ac.uk>,
Steve Kille <S.Kille@cs.ucl.ac.uk>
Subject: Email Problems
Sender: Stephen.Harrison@gosip-uk.hmg.gold-400.gb
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=boundary-1
--boundary-1
Content-Type: text/plain; charset=US-ASCII
Hope you gentlemen.......
Regards,
Stephen Harrison
UK GOSIP Project
--boundary-1
Content-Type: message/rfc822
From: Urs Eppenberger <Eppenberger@verw.switch.ch>
Message-ID:
<562*/S=Eppenberger/OU=verw/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS>
To: "Stephen.Harrison" <Stephen.Harrison@gosip-uk.hmg.gold-400.gb>
Cc: kimura@bsdarc.bsd.fc.nec.co.jp
Subject: Response to Email link
Content-Type: multipart/mixed; boundary=boundary-2
--boundary-2
Dear Mr Harrison......
--boundary-2--
--boundary-1--
5.3.5. Mappings from an IP Notification
Because of the service setting, IP Notifications will not usually
need to be mapped by a MIXER gateway. A message is generated, with
the following fields:
From:
Set to the IPMS.IPN.ipn-originator.
To: Set to the recipient from MTS.MessageSubmissionEnvelope.
If there have been redirects, the original address shall be used.
Subject:
Set to the string "X.400 Inter-Personal Notification" for a
receipt notification and to "X.400 Inter-Personal Notification
(failure)" for a non-receipt notification.
Message-Type:
Set to "InterPersonal Notification"
References:
Set to IPMS.IPN.subject-ipm
Discarded-X400-IPMS-Extensions:
Used for any discarded IPN extensions.
The following EBNF is defined for the body of the Message. This
format is defined to ensure that all information from an
interpersonal notification is available to the end user in a uniform
manner.
ipn-body-format = ipn-description <CRLF>
[ ipn-extra-information <CRLF> ]
[ ipn-content-return ]
ipn-description = ipn-receipt / ipn-non-receipt
ipn-receipt = "Your message to:" preferred-recipient <CRLF>
"was received at" receipt-time <CRLF> <CRLF>
"This notification was generated"
acknowledgement-mode <CRLF>
"The following extra information was given:" <CRLF>
ipn-suppl <CRLF>
ipn-non-receipt = "Your message to:"
preferred-recipient <CRLF>
ipn-reason
ipn-reason = ipn-discarded / ipn-auto-forwarded
ipn-discarded = "was discarded for the following reason:"
discard-reason <CRLF>
ipn-auto-forwarded = "was automatically forwarded." <CRLF>
[ "The following comment was made:"
auto-comment ]
ipn-extra-information =
"The following information types were converted:"
encoded-info
ipn-content-return = "The Original Message is not available"
/ "The Original Message follows:"
preferred-recipient = mailbox
receipt-time = date-time
auto-comment = printablestring
ipn-suppl = printablestring
discard-reason = "Expired" / "Obsoleted" /
"User Subscription Terminated" / "IPM Deleted"
acknowledgement-mode = "Manually" / "Automatically"
The mappings for elements of the common fields of IPMS.IPN
(IPMS.CommonFields) onto this structure and the message header are:
subject-ipm
Mapped to "References:"
ipn-originator
Mapped to "From:".
ipn-preferred-recipient
Mapped to EBNF.preferred-recipient
conversion-eits
Mapped to EBNF.encoded-info in EBNF.ipn-extra-information
The mappings for elements of IPMS.IPN.non-receipt-fields
(IPMS.NonReceiptFields) are:
non-receipt-reason
Used to select between EBNF.ipn-discarded and EBNF.ipn-auto-
forwarded
discard-reason
Mapped to EBNF.discard-reason
auto-forward-comment
Mapped to EBNF.auto-comment
returned-ipm
This applies only to non-receipt notifications. EBNF.ipn-
content-return shall always be omitted for receipt notifications,
and always be present in non-receipt notifications. If present,
the second option of EBNF.ipn-content-return is chosen, and the
message is included. In this case, the message is formatted as
multipart/mixed, and the returned message included as
message/rfc822 after the text body part. Otherwise the first
option is chosen.
The mappings for elements of IPMS.IPN.receipt-fields
(IPMS.ReceiptFields) are:
receipt-time
Mapped to EBNF.receipt-time
acknowledgement-mode
Mapped to EBNF.acknowledgement-mode
suppl-receipt-info
Mapped to EBNF.ipn-suppl
An example notification is:
From: Steve Kille <steve@cs.ucl.ac.uk>
To: Julian Onions <jpo@computer-science.nottingham.ac.uk>
Subject: X.400 Inter-personal Notification
Message-Type: InterPersonal Notification
References: <1229.614418325@UK.AC.NOTT.CS>
Date: Wed, 21 Jun 89 08:45:25 +0100