4.4.1. Recursive Mappings
It is possible to supply an address which is recursive at a single
gateway. For example:
C = "XX"
ADMD = "YY"
O = "ZZ"
"RFC-822" = "Smith(a)ZZ.YY.XX"
This is mapped first to an RFC 822 address, and then back to the
C = "XX"
ADMD = "YY"
O = "ZZ"
Surname = "Smith"
In some situations this type of recursion may be frequent. It is
important where this occurs, that no unnecessary protocol conversion
occurs. This will minimise loss of service.
4.4.2. Source Routes
The mappings defined are symmetrical and reversible across a single
gateway. The symmetry is particularly useful in cases of (mail
exploder type) distribution list expansion. For example, an X.400
user sends to a list on an RFC 822 system which he belongs to. The
received message will have the originator and any 3rd party X.400 OR
Addresses in correct format (rather than doubly encoded). In cases
(X.400 or RFC 822) where there is common agreement on gateway
identification, then this will apply to multiple gateways.
When a message traverses multiple gateways, the mapping will always
be reversible, in that a reply can be generated which will correctly
reverse the path. In many cases, the mapping will also be
symmetrical, which will appear clean to the end user. For example,
if countries "AB" and "XY" have RFC 822 networks, but are
interconnected by X.400, the following may happen: The originator
This is routed to a gateway, which generates:
C = "XY"
ADMD = "PTT"
PRMD = "Griddle MHS Providers"
Organization = "Widget Corporation"
Surname = "Soap"
Given Name = "Joe"
This is then routed to another gateway where the mapping is reversed
Here, use of the gateway is transparent.
Mappings will only be symmetrical where mapping equivalences are
defined. In other cases, the reversibility is more important, due to
the (far too frequent) cases where RFC 822 and X.400 services are
The syntax may be used to source route. THIS IS STRONGLY
DISCOURAGED. For example:
X.400 -> RFC 822 -> X.400
C = "UK"
ADMD = "Gold 400"
PRMD = "UK.AC"
"RFC-822" = "/PN=Duval/DD.Title=Manager/(a)Inria.ATLAS.FR"
This will be sent to an arbitrary UK Academic Community gateway by
X.400. Then it will be sent by JNT Mail to another gateway
determined by the domain Inria.ATLAS.FR (FR.ATLAS.Inria). This will
then derive the X.400 OR Address:
C = "FR"
ADMD = "ATLAS"
PRMD = "Inria"
PN.S = "Duval"
"Title" = "Manager"
RFC 822 -> X.400 -> RFC 822
This will be sent to monet.berkeley.edu by RFC 822, then to the
AC PRMD by X.400, and then to email@example.com by RFC 822.
4.5. Directory Names
Directory Names are an optional part of OR Name, along with OR
Address. The RFC 822 addresses are mapped onto the OR Address
component. As there is no functional mapping for the Directory Name
on the RFC 822 side, a textual mapping is used. There is no
requirement for reversibility in terms of the goals of this
specification. There may be some loss of functionality in terms of
third party recipients where only a directory name is given, but this
seems preferable to the significant extra complexity of adding a full
mapping for Directory Names.
The Directory Name shall be represented within an RFC 822 comment
using the comaptible formats of RFC 1484 or RFC 1485. It is
recommended that the directory string format of RFC 1485 is used
. The User Friendly Name form of RFC 1484 may be used .
4.6. MTS Mappings
The basic mappings at the MTS level are:
1) SMTP originator ->
2) SMTP recipient ->
SMTP recipients and return addresses are encoded as EBNF.822-address.
The MTS Originator is always encoded as MTS.OriginatorName, which
maps onto MTS.ORAddressAndOptionalDirectoryName, which in turn maps
4.6.1. RFC 822 -> X.400 MTS Mappings
From the SMTP Originator, use the basic ORAddress mapping, to
generate MTS.PerMessageSubmissionFields.originator-name (MTS.ORName),
without a DirectoryName.
For recipients, the following settings are made for each component of
This is derived from the SMTP recipient by the basic ORAddress
This may either be set to "delivery-report", or set according to
SMTP extensions as set out in Appendix A.
This optional component is omitted, as this service is not needed
The default value (no extensions) is used
4.6.2. X.400 -> RFC 822 MTS Mappings
The basic functionality is to generate the SMTP originator and
recipients. There is information present on the X.400 side, which
cannot be mapped into analogous SMTP services. For this reason, new
RFC 822 fields are added for the MTS Originator and Recipients. The
information discarded at the SMTP level will be present in these
fields. In some cases a (positive) delivery report will be generated.
22.214.171.124. SMTP Mappings
Use the basic ORAddress mapping, to generate the SMTP originator
(return address) from MTS.OtherMessageDeliveryFields.originator-name
(MTS.ORName). If MTS.ORName.directory-name is present, it is
discarded. (Note that it will be presented to the user, as described
The mapping uses the MTA level information, and maps each value of
MTA.PerRecipientMessageTransferFields.recipient-name, where the
responsibility bit is set, onto an SMTP recipient.
Note:The SMTP recipient is conceptually generated from
MTS.OtherMessageDeliveryFields.this-recipient-name. This is done
by taking MTS.OtherMessageDeliveryFields.this-recipient-name, and
generating an SMTP recipient according to the basic ORAddress
mapping, discarding MTS.ORName.directory-name if present.
However, if this model was followed exactly, there would be no
possibility to have multiple SMTP recipients on a single message.
This is unacceptable, and so layering is violated.
126.96.36.199. Generation of RFC 822 Headers
Not all per-recipient information can be passed at the SMTP level.
For this reason, two new RFC 822 headers are created, in order to
carry this information to the RFC 822 recipient. These fields are
"X400-Originator:" and "X400-Recipients:".
The "X400-Originator:" field is set to the same value as the SMTP
originator. In addition, if
MTS.OtherMessageDeliveryFields.originator-name (MTS.ORName) contains
MTS.ORName.directory-name then this Directory Name shall be
represented in an 822.comment.
Recipient names, taken from each value of
MTS.OtherMessageDeliveryFields.other-recipient-names are made
available to the RFC 822 user by use of the "X400-Recipients:" field.
By taking the recipients at the MTS level, disclosure of recipients
will be dealt with correctly. However, this conflicts with a desire
to optimise mail transfer. There is no problem when disclosure of
recipients is allowed. Similarly, there is no problem if there is
only one RFC 822 recipient, as the "X400-Recipients" field is only
given one address.
There is a problem if there are multiple RFC 822 recipients, and
disclosure of recipients is prohibited. In this case, discard the
If any MTS.ORName.directory-name is present, it shall be represented
in an 822.comment.
is present, then there has been redirection, or there has been
distribution list expansion. Distribution list expansion is a per-
message option, and the information associated with this is
represented by the "DL-Expansion-History:" field described in Section
5.3.6. Other information is represented in an 822.comment associated
with MTS.OtherMessageDeliveryFields.this-recipient-name, The message
may be delivered to different RFC 822 recipients, and so several
addresses in the "X400-Recipients:" field may have such comments.
The non-commented recipient is the RFC 822 recipient. The EBNF of the
comment is defined by redirect-comment.
redirect-comment = redirect-first *( redirect-subsequent )
redirect-first = "Originally To:" mailbox "Redirected on"
date-time "To:" redirection-reason
redirect-subsequent = mailbox "Redirected Again on"
date-time "To:" redirection-reason
redirection-history-item = "intended recipient" mailbox
"redirected to" redirection-reason
"Recipient Assigned Alternate Recipient"
/ "Originator Requested Alternate Recipient"
/ "Recipient MD Assigned Alternate Recipient"
/ "Directory Look Up"
It is derived from
The values are taken from the X.400(92) Implementor's guide (Version
13, July 1995). The first three values are in X.400(88). The
fourth value is in X.400(92), but has the name "recipient-directory-
substitution-alternate-recipient". An example of this with two
X400-Recipients: firstname.lastname@example.org (Originally To:
Redirected on Thu, 30 May 91 14:39:40 +0100
To: Originator Requested Alternate Recipient
Redirected Again on Thu, 30 May 91 14:41:20 +0100
To: Recipient MD Assigned Alternate Recipient)
In addition the following per-recipient services from
MTS.OtherMessageDeliveryFields.extensions are represented in comments
if they are used. None of these services can be provided on RFC 822
networks, and so in general these will be informative strings
associated with other MTS recipients. In some cases, string values
are defined. For the remainder, the string value shall be chosen by
the implementor. If the parameter has a default value, then no
comment shall be inserted when the parameter has that default value.
"(Physical Forwarding Prohibited)".
"(Physical Forwarding Address Requested)".
"(Physical Delivery Report Requested)".
"(Proof of Delivery Requested)".
188.8.131.52. Delivery Report Generation
If SMTP is used, the behaviour is specified in Appendix A. In other
cases, if MTA.PerRecipientMessageTransferFields.per-recipient-
indicators requires a positive delivery notification, this shall be
generated by the gateway. Supplementary Information shall be set to
indicate that the report is gateway generated. This information
shall include the name of the gateway generating the report.
4.6.3. Message IDs (MTS)
A mapping from 822.msg-id to MTS.MTSIdentifier is defined. The
reverse mapping is not needed, as MTS.MTSIdentifier is always mapped
onto new RFC 822 fields. The value of MTS.MTSIdentifier.local-part
will facilitate correlation of gateway errors.
To map from 822.msg-id, apply the standard mapping to 822.msg-id, in
order to generate an MTS.ORAddress. The Country, ADMD, and PRMD
components of this are used to generate MTS.MTSIdentifier.global-
domain-identifier. MTS.MTSIdentifier.local-identifier is set to the
822.msg-id, including the braces "<" and ">". If this string is
longer than MTS.ub-local-id-length (32), then it is truncated to this
The reverse mapping is not used in this specification. It would be
applicable where MTS.MTSIdentifier.local-identifier is of syntax
822.msg-id, and it algorithmically identifies MTS.MTSIdentifier.
4.7. IPMS Mappings
All RFC 822 addresses are assumed to use the 822.mailbox syntax.
This includes all 822.comments associated with the lexical tokens of
the 822.mailbox. In the IPMS OR Names are encoded as MTS.ORName.
This is used within the IPMS.ORDescriptor, IPMS.RecipientSpecifier,
and IPMS.IPMIdentifier. An asymmetrical mapping is defined between
4.7.1. RFC 822 -> X.400
To derive IPMS.ORDescriptor from an RFC 822 address.
1. Take the address, and extract an EBNF.822-address. Any
source routing shall be removed. This can be derived trivially
from either the 822.addr-spec or 822.route-addr syntax. This is
mapped to MTS.ORName as described above, and used as
2. A string shall be built consisting of (if present):
- The 822.phrase component if the 822.address is an
822.phrase 822.route-addr construct.
- Any 822.comments, in order, retaining the parentheses.
This string is then encoded into T.61 using a human oriented
mapping (as described in Section 3.5). If the string is not
null, it is assigned to IPMS.ORDescriptor.free-form-name.
3. IPMS.ORDescriptor.telephone-number is omitted.
If IPMS.ORDescriptor is being used in IPMS.RecipientSpecifier,
IPMS.RecipientSpecifier.notification-requests are set to default
values (false and none).
If the 822.group construct is present, any included 822.mailbox is
encoded as above to generate a separate IPMS.ORDescriptor. The
822.group is mapped to T.61 (as described in Section 3.5), and a
IPMS.ORDescriptor with only an free-form-name component built from
4.7.2. X.400 -> RFC 822
Mapping from IPMS.ORDescriptor to RFC 822 address. In the basic
case, where IPMS.ORDescriptor.formal-name is present, proceed as
1. Encode IPMS.ORDescriptor.formal-name (MTS.ORName) as
2a. If IPMS.ORDescriptor.free-form-name is present, convert it
to ASCII or T.61 (Section 3.5), and use this as the 822.phrase
component of 822.mailbox using the 822.phrase 822.route-addr
2b. If IPMS.ORDescriptor.free-form-name is absent. If
EBNF.822-address is parsed as 822.addr-spec use this as the
encoding of 822.mailbox. If EBNF.822-address is parsed as
822.route 822.addr-spec, then an 822.phrase taken from
822.local-part is added.
3 If IPMS.ORDescriptor.telephone-number is present, this is
placed in an 822.comment, with the string "Tel ". The normal
international form of number is used. For example:
4. If IPMS.ORDescriptor.formal-name.directory-name is present,
then a text representation is placed in a trailing 822.comment.
5. If IPMS.RecipientSpecifier.report-request has any non-
default values, then an 822.comment "(Receipt Notification
Requested)", and/or "(Non Receipt Notification Requested)",
and/or "(IPM Return Requested)" may be appended to the address.
"(Receipt Notification Requested)" may be used to infer "(Non
Receipt Notification Requested)". The effort of correlating P1
and P2 information is too great to justify the gateway sending
In RFC 1327, inclusion of these comments was mandatory.
Experience has shown that the clutter and confusion caused to
RFC 822 users does not justify the information conveyed.
Implementors are recommended to not include these comments.
Unless an application is found where retention of these comments
is desirable, they will be dropped from the next version.
6. If IPMS.RecipientSpecifier.reply-request is True, an
822.comment "(Reply requested)" is appended to the address.
If IPMS.ORDescriptor.formal-name is absent, IPMS.ORDescriptor.free-
form-name is converted to ASCII (see section 3.5), and used as
822.phrase within the RFC 822 822.group syntax. For example:
Free Form Name ":" ";"
Steps 3-6 are then followed.
4.7.3. IP Message IDs
There is a need to map both ways between 822.msg-id and
IPMS.IPMIdentifier. This allows for X.400 Receipt Notifications,
Replies, and Cross References to reference an RFC 822 Message ID,
which is preferable to a gateway generated ID. A reversible and
symmetrical mapping is defined. This provides fully reversible
mappings when messages pass multiple times across the X.400/RFC 822
An important issue with messages identifiers is mapping to the exact
form, as many systems use these ids as uninterpreted keys. The use
of table driven mappings is not always symmetrical, particularly in
the light of alternative domain names, and alternative management
domains. For this reason, a purely algorithmic mapping is used. A
mapping which is simpler than that for addresses can be used for two
- There is no major requirement to make message IDs "natural"
- There is no issue about being able to reply to message IDs.
(For addresses, creating a return path which works is more
important than being symmetrical).
The mapping works by defining a way in which message IDs generated on
one side of the gateway can be represented on the other side in a
systematic manner. The mapping is defined so that the possibility of
clashes is low enough to be treated as impossible.
184.108.40.206. 822.msg-id represented in X.400
IPMS.IPMIdentifier.user is omitted. The IPMS.IPMIdentifier.user-
relative-identifier is set to a printable string encoding of the
822.msg-id with the angle braces ("<" and ">") removed. The upper
bound on this component is 64. The options for handling this are
discussed in Section 5.1.3.
220.127.116.11. IPMS.IPMIdentifier represented in RFC 822
The 822.domain of 822.msg-id is set to the value "MHS". The
822.local-part of 822.msg-id is constructed by building a string of
syntax EBNF.id-loc from IPMS.IPMIdentifier.
id-loc ::= [ printablestring ] "*" [ std-or-address ]
EBNF.printablestring is the IPMS.IPMIdentifier.user-relative-
identifier, and EBNF.std-or-address being an encoding of the
IPMS.IPMIdentifier.user derived according to this specification.
822.local-part is derived from EBNF.id-loc, if necessary using the
822.quoted-string encoding. For example:
18.104.22.168. 822.msg-id -> IPMS.IPMIdentifier
If the 822.local-part can be parsed as:
[ printablestring ] "*" [ std-or-address ]
and the 822.domain is "MHS", then this ID was X.400 generated. If
EBNF.printablestring is present, the value is assigned to
IPMS.IPMIdentifier.user-relative-identifier. If EBNF.std-or-address
is present, the OR Address components derived from it are used to set
Otherwise, this is an RFC 822 generated ID. In this case, set
IPMS.IPMIdentifier.user-relative-identifier to a printable string
encoding of the 822.msg-id without the angle braces and omit
22.214.171.124. 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 RFC 822 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.
126.96.36.199. 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
188.8.131.52. RFC 987 backwards compatibility
The mapping defined here is different to that used in RFC 987, as the
RFC 987 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 RFC 987. This is not recommended.
RFC 987 generated encodings may be recognised as follows. When
mapping from X.400 to RFC 822, if the IPMS.IPMIdentifier.user-
relative-identifier is "RFC-822" the id is RFC 987 generated. When
mapping from RFC 822 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 RFC 987 generated. In each of these cases, it is
recommended to follow the RFC 987 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. RFC 822 -> X.400: Detailed Mappings
The mapping of RFC 822/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 RFC 822 message. The RFC
822 headers are used to generate the IPMS.Heading.
Some RFC 822 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 RFC 822 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:
RFC822FieldList ::= SEQUENCE OF RFC822Field
RFC822Field ::= IA5String
The Object Identifier id-rfc-822-field-list is defined in Appendix D.
To encode any RFC 822 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 RFC 822 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 RFC 822 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
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 RFC 822
comments and RFC 1522 encoding.
Note:This approach removes a choice of options given in RFC 1327,
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 RFC 822 Headers as follows:
Ignore (Handled at MTS level)
Ignore (Handled at MTA level)
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.
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
Mapped to IPMS.Heading.originator. Because X.400 does not have
the same From/Sender distinction as RFC 822, this mapping is not
always natural and may lead to unexpected results in some cases.
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.
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
Mapped to IPMS.Heading.related-IPMs.
Mapped onto a heading extension.
Mapped to IPMS.Heading.subject. The field-body uses the human
oriented mapping referenced in Section 3.3.4.
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
Mapped onto a heading extension.
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.
This field is defined in RFC 1766 . 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.
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 RFC 822 fields
where the content of the field does not conform to RFC 822
(e.g., a Date: field with unparseable syntax).
The mapping of the following headings is defined in RFC 2157.
5.1.4. Generating the IPM Body
Generation of the IPM Body is defined in RFC 2157.
5.1.5. Mappings to the MTS Abstract Service
The MTS.MessageSubmissionEnvelope comprises
MTS.PerRecipientMessageSubmissionFields. The mandatory parameters
are defaulted as follows.
This is always generated from SMTP, as defined in Chapter 4.
Set to the value implied by the encoding of the IPM (2 or 22).
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
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.
will include all of the values used in the trace, unless specified
otherwise in RFC 2157.
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
- So that the submission date can be generated from the
- To prevent loss of trace information
- To prevent RFC 822/X.400 looping caused by distribution
lists or redirects
The following mappings are defined.
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 RFC 1327.
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
The Date: field is used to set the first component of
(MTA.TraceInformationElement). The SMTP originator is mapped into
an MTS.ORAddress, and used to derive
optional components of MTA.TraceInformationElement.domain-
supplied-information are omitted, and the mandatory components are
set as follows:
This is set to the date derived from Date:
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.
All RFC 822 trace is used to derive
Processing of Received: lines follows processing of Date:, and is
done from the bottom to the top of the RFC 822 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-
create a new MTA.TraceInformationElement, and optionally remove
Requirements on trace stripping are discussed below.
Then add a new element (MTA.InternalTraceInformationElement) to
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.MTASuppliedInformation) is set as follows:
Derived from the date of the Received: line
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
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:
Set to the time of conversion
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
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
The mapping of two extended fields is particularly important, in
order to prevent looping. "DL-Expansion-History:" is mapped to
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
- 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
5.1.8. Mapping Delivery Status Notifications to X.400
184.108.40.206. 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
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
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.
220.127.116.11. DSN Extensions
Two X.400 MTS extensions are defined as follows:
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).
18.104.22.168. 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
The DSN has an RFC 822 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
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
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:
In general, these are not available, and so are assigned
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 22.214.171.124.
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
Mapped to MTA.PerRecipientReportTransferFields.originally-
Mapped to MTA.PerRecipientReportTransferFields.actual-recipient-
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.
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.
All of these fields are added to the per recipient extension list.
126.96.36.199. Status Value Mappings
Status values are mapped to X.400 reason and diagnostic codes as
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
188.8.131.52. 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
5.2. Return of Contents
RFC 1327 offered two approaches for return of content, as this
service is optional in X.400 and expected in RFC 822. MIXER simply
requires that a gateway requests the return of content service from
5.3. X.400 -> RFC 822: Detailed Mappings
5.3.1. Basic Approach
A single RFC 822 message is generated from the incoming IP Message,
Report, or IP Notification. All IPMS.BodyParts are mapped onto a
single RFC 822 body. Other services are mapped onto RFC 822 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.