S.Kille@CS.UCL.AC.UK (Steve Kille) (07/14/89)
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
2. To ensure preservation of order over multiple mappings.
There are three places where an order must be specified:
1. The text encoding (std-or-address) of MTS.ORAddress as used |
in the local-part of an RFC 822 address. An order is needed |
for those components which may have multiple values
(Organisational Unit, and Domain Defined Attributes). When |
generating an 822.std-or-address, components of a given type |
shall be in hierarchical order with the most significant |
component on the RHS. If there is an Organisation |
Attribute, it shall be to the right of any Organisational |
Unit attributes. These requirements are for the following |
reasons: |
- Alignment to the hierarchy of other components in RFC |
822 addresses (thus, Organisational Units will appear |
in the same order, whether encoded on the RHS or LHS). |
- Backwards compatibility with RFC 987/1026. |
- To ensure that gateways generate consistent addresses. |
This is both to help end users, and to generate |
identical message ids. |
Further, it is recommended that all other attributes are |
generated according to this ordering, so that all attributes |
so encoded follow a consistent hierarchy. |
There will be some cases where an X.400 O/R address of this |
encoding will be generated by an end user from external |
information. The ordering of attributes may be inverted or |
mixed. For this reason, the following heuristics may be |
applied: |
- If there is an Organisation attribute to the left of |
any Org Unit attribute, assume that the hierarchy is |
inverted. |
- If an inversion of the Org Unit hierarchy generates a |
valid address, when the preferred order does not, |
assume that the hierarchy is inverted. |
2. For the Organisational Units (OU) in MTS.ORAddress, the
Kille [page 48]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
first OU in the SEQUENCE is the most significant, as
specified in X.400.
3. For the Domain Defined Attributes in MTS.ORAddress, the
First Domain Defined Attribute in the SEQUENCE is the most
significant.
Note that although this ordering is mandatory for this
mapping, there are NO implications on ordering significance
within X.400, where this is a Management Domain issue.
4.3.4. RFC 822 -> X.400
There are two basic cases:
1. X.400 addresses encoded in RFC 822. This will also include
RFC 822 addresses which are given reversible encodings.
2. "Genuine" RFC 822 addresses.
The mapping should proceed as follows, by first assuming case 1).
STAGE I. |
1. If the 822-address is not of the form:
local-part "@" domain
go to stage II. |
NOTE:It may be appropriate to reduce a source route address
to this form by removal of all bar the last domain. In
terms of the design intentions of RFC 822, this would
be an incorrect action, and so is not specified as a
part of this mapping. However, in most real cases, it
will do the "right" thing and provide a better service
to the end user. This is a reflection on the excessive |
and inappropriate use of source routing in RFC 822 |
based systems.
2. Attempt to parse domain as:
*( domain-syntax "." ) known-domain
Kille [page 49]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
Where known-domain is the longest possible match in a list
of gatewayed domains. If this fails, and the domain does
not explicitly identify the local gateway, go to stage II. |
If it succeeds, allocate the attributes associated with
EBNF.known-domain, and systematically allocate the
attributes implied by each EBNF.domain-syntax component. If
the domain explicitly identifies the gateway, allocate no
attributes.
3. If the local-part contains any characters not in
PrintableString, go to stage II. |
4. If the 822.local-part uses the 822.quoted-string encoding, |
remove this quoting. Parse the (unquoted) 822.local-part |
according to the EBNF EBNF.std-or-address. If this parse
fails, parse the local-part according to the EBNF
EBNF.encoded-pn. If this also fails, go to stage II. |
Otherwise, the result is a set of type/value pairs. If the |
values generated conflict with those derived in step 2 |
(e.g., a duplicated country attribute), the domain should be |
assumed to be an RFC 987 gateway. In this case, take only |
the LHS derived attributes. Otherwise add LHS and RHS |
derived attributes together.
5. Associate the EBNF.attribute-value syntax (determined from
the identified type) with each value, and check that it
conforms. If not, go to stage II. |
6. Ensure that the set of attributes conforms both to the
MTS.ORAddress specification and to the restrictions on this
set given in X.400. If not go to stage II. |
7. Build the O/R Address from this information.
STAGE II. |
This will only be reached if the RFC 822 EBNF.822-address is not
a valid X.400 encoding. If the address is an 822-MTS recipient
address, it must be rejected, as there is a need to interpret
such an address in X.400. For the 822-MTS return address, and
any addresses in the RFC 822 header, they should now be encoded
as RFC 822 addresses in an X.400 O/R Name:
Kille [page 50]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
1. Convert the EBNF.822-address to PrintableString, as
specified in Chapter 3.
2. The "RFC-822" domain defined attribute should be generated
from this string.
3. Build the rest of the O/R Address in the local Management
Domain agreed manner, so that the O/R Address will receive a
correct global interpretation.
Note that the domain defined attribute value has a maximum length
of MTS.ub-domain-defined-attribute-value-length (128). If this
is exceeded by a mapping at the MTS level, then the gateway
should reject the message in question. If this occurs at the |
IPMS level, then the action should depend on the policy being |
taken, which is discussed in Section 5.1.3.
4.3.5. X.400 -> RFC 822
There are two basic cases:
1. RFC 822 addresses encoded in X.400.
2. "Genuine" X.400 addresses. This may include symmetrically
encoded RFC 822 addresses.
When a MTS Recipient O/R Address is interpreted, gatewaying will
be selected if there a single "RFC-822" domain defined attribute
present. In this case, use mapping A. For other O/R Addresses
which
1. Contain the special attribute.
AND
2. Identifies the local gateway or any other known gateway with |
the other attributes.
use mapping A. In other cases, use mapping B. |
NOTE: |
A pragmatic approach would be to assume that any O/R |
Address with the special domain defined attribute identifies |
Kille [page 51]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
an RFC 822 address. This will usually work correctly, but |
is in principle not correct.
Mapping A
1. Map the domain defined attribute value to ASCII, as defined
in Chapter 3.
Mapping B.
This will be used for X.400 addresses which do not use the
explicit RFC 822 encoding.
1. For all string encoded attributes, remove any leading or |
trailing spaces, and replace adjacent spaces with a single |
space. |
2. Noting the hierarchy specified in 4.3.1, determine the
maximum set of attributes which have an associated domain
specification. If no match is found, allocate the domain as
the domain specification of the local gateway, and go to
step 4. |
3. Following the 4.3.1 hierarchy and noting any omitted
components implied by the mapping tables, if each successive
component exists, and conforms to the syntax
EBNF.domain-syntax (as defined in 4.3.1), allocate the next
subdomain. At least one component must remain unused. |
4. If the remaining components are personal-name components,
conforming to the restrictions of 4.2.1, then EBNF.encoded-
pn should be derived to form 822.local-part. In other cases
the remaining components should simply be encoded as a
822.local-part using the EBNF.std-or-address syntax. If |
necessary, the 822.quoted-string encoding should be used. |
5. If this step is reached for an 822-MTS recipient, then the
address is invalid. For other addresses, use a domain which
identifies the local gateway, and build 822.local-part from
the entire O/R Address using the EBNF.std-or-address syntax.
If the derived 822.local-part can only be encoded by use of
822.quoted-string, the gateway may optionally use the ASCII
to 822.local-part mapping defined in Appendix A, dependent
Kille [page 52]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
on the mail protocols of the networks being relayed to. Use
of this encoding is discouraged.
4.4. Repeated Mappings
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 O/R 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
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 specifies: |
Joe.Soap@Widget.PTT.XY
This is routed to a gateway, which generates: |
C = "XY"
ADMD = "PTT"
PRMD = "Widget MHS Inc"
Organisation = "Widget"
Surname = "Soap"
Given Name = "Joe"
This is then routed to another gateway where the mapping is |
reversed to give: |
Joe.Soap@Widget.PTT.XY
Here, use of the gateway is transparent. |
Mappings will only be symmetrical where mapping tables are |
defined. In other cases, the reversibility is more important, |
due to the (far too frequent) cases where RFC 822 and X.400
Kille [page 53]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
services are partitioned.
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 O/R Address:
C = "FR"
ADMD = "ATLAS"
PRMD = "Inria"
PN.S = "Duval"
"Title" = "Manager"
Similarly:
RFC 822 -> X.400 -> RFC 822
"/C=UK/ADMD=BT/PRMD=AC/RFC-822=jj(a)seismo.css.gov/"@monet.berkeley.edu
/C=UK/ADMD=BT/PRMD=AC/RFC-822=jj#l#a#r#seismo.css.gov/@monet.berkeley.edu
The second case uses the Appendix A encoding to avoid
822.quoted-text. This will be sent to monet.berkeley.edu by RFC
822, then to the AC PRMD by X.400, and then to jj@seismo.css.gov
by RFC 822.
4.5. Directory Names
Directory Names are an optional part of O/R Name, along with O/R
Address. The RFC 822 addresses are mapped onto the O/R Address
component. As there is no functional mapping for the Directory
Name on the RFC 822 side, a textual mapping should be 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
Kille [page 54]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
given, but this seems preferable to the significant extra
complexity of adding a full mapping for Directory Names.
4.6. MTS Mappings
The basic mappings at the MTS level are:
1) 822-MTS originator ->
MTS.PerMessageSubmissionFields.originator-name
MTS.OtherMessageDeliveryFields.originator-name ->
822-MTS originator |
2) 822-MTS recipient ->
MTS.PerRecipientMessageSubmissionFields
MTS.OtherMessageDeliveryFields.this-recipient-name ->
822-MTS recipient
822-MTS 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 onto MTS.ORName.
4.6.1. RFC 822 -> X.400
From the 822-MTS Originator, use the basic ORAddress mapping, to
generate MTS.PerMessageSubmissionFields.originator-name
(MTS.ORName), without a DirectoryName.
For recipients, the following settings should be made for
each component of MTS.PerRecipientMessageSubmissionFields.
recipient-name
This should be derived from the 822-MTS recipient by the
basic ORAddress mapping.
originator-report-request
This should be set according to content return policy, as
discussed in Section 5.2. |
explicit-conversion
This optional component should be omitted, as this service
is not needed
Kille [page 55]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
extensions
The default value (no extensions) should be used
4.6.2. X.400 -> RFC 822
The basic functionality is to generate the 822-MTS originator and |
recipients. There is information present on the X.400 side,
which cannot be mapped into analogous 822-MTS services. For this
reason, new RFC 822 fields are added for the MTS Originator and
Recipients. The information discarded at the 822-MTS level
should be present in these fields. There may also be the need to |
generate a delivery report. |
4.6.2.1. 822-MTS Mappings
Use the basic ORAddress mapping, to generate the 822-MTS |
originator (return address) from
MTS.OtherMessageDeliveryFields.originator-name (MTS.ORName). If
MTS.ORName.directory-name is present, it should be discarded. |
The 822-MTS recipient is conceptually generated from
MTS.OtherMessageDeliveryFields.this-recipient-name. This is done |
by taking MTS.OtherMessageDeliveryFields.this-recipient-name, and |
generating an 822-MTS 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 822-MTS recipients on a single
message. This is unacceptable, and so layering is violated. The
mapping needs to use the MTA level information, and map each
value of MTA.PerRecipientMessageTransferFields.recipient-name
onto an 822-MTS recipient. |
4.6.2.2. Generation of RFC 822 Headers |
As not all per-recipient information can be passed at the 822-MTS |
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 should be set to the same value |
as the 822-MTS originator. In addition, if |
MTS.OtherMessageDeliveryFields.originator-name (MTS.ORName) |
contains MTS.ORName.directory-name then this Directory Name |
should be represented in an 822.comment. |
Kille [page 56]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
Recipient names, taken from each value of
MTS.OtherMessageDeliveryFields.this-recipient-name and |
MTS.OtherMessageDeliveryFields.other-recipient-names should be
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. If
any MTS.ORName.directory-name is present, it should be
represented in an 822.comment. If |
MTS.OtherMessageDeliveryFields.orignally-intended-recipient-name |
is present, then it should be represented in an associated |
822.comment, starting with the string "Originally Intended |
Recipient".
In addition the following per-recipient services from |
MTS.OtherMessageDeliveryFields.extensions should be 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 may be chosen by the implementor. If the paramter |
has a default value, then no comment should be inserted. |
requested-delivery-method |
physical-forwarding-prohibited |
"(Physical Forwarding Prohibited)". |
physical-forwarding-address-request |
"(Physical Forwarding Address Requested)". |
physical-delivery-modes |
registered-mail-type |
recipient-number-for-advice |
physical-rendition-attributes |
physical-delivery-report-request |
"(Physical Delivery Report Requested)". |
proof-of-delivery-request |
"(Proof of Delivery Requested)". |
Kille [page 57]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
4.6.2.3. Delivery Report Generation |
If MTA.PerRecipientMessageTransferFields.per-recipient-indicators
requires a positive delivery notification, this should be
generated by the gateway. Supplementary Information should be
set to indicate that the report is gateway generated.
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 should be used to generate
MTS.MTSIdentifier.global-domain-identifier.
MTS.MTSIdentifier.local-identifier should be set to the
822.msg-id, including the braces "<" and ">". If this string is
longer than MTS.ub-local-id-length (32), then it should be
truncated to this length.
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 should include all 822.comments associated with the lexical
tokens of the 822.mailbox. In the IPMS O/R Names are encoded as
MTS.ORName. This is used within the IPMS.ORDescriptor,
IPMS.RecipientSpecifier, and IPMS.IPMIdentifier. An asymmetrical
mapping is defined between these components.
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. This can
be derived trivially from either the 822.addr-spec or
Kille [page 58]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
822.route-addr syntax. This is mapped to MTS.ORName as
described above, and used as IMPS.ORDescriptor.formal-name.
2. A string should 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 should then be encoded into T.61 (as described
in Chapter 3). If the string is not null, it should be
assigned to IPMS.ORDescriptor.free-form-name.
3. IPMS.ORDescriptor.telephone-number should be omitted.
If IPMS.ORDescriptor is being used in IPMS.RecipientSpecifier,
IPMS.RecipientSpecifier.reply-request and |
IPMS.RecipientSpecifier.notification-requests should be set to |
default values (none and false).
If the 822.group construct is present, any included
822.mailbox should be encoded as above to generate a separate
IPMS.ORDescriptor. The 822.group should be mapped to T.61, and a
IPMS.ORDescriptor with only an free-form-name component built
from it.
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
follows.
1. Encode IPMS.ORDescriptor.formal-name (MTS.ORName) as
EBNF.822-address.
2a. If IPMS.ORDescriptor.free-form-name is present, convert it
to ASCII (Chapter 3), and use this as the 822.phrase
component of 822.mailbox using the 822.phrase 822.route-addr
construct.
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
Kille [page 59]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
822.route 822.addr-spec, then a 822.phrase taken from
822.local-part should be added.
3 If IPMS.ORDescriptor.telephone-number is present, this
should be placed in an 822.comment, with the string "Tel ". |
The normal international form of umber should be used. For |
example: |
(Tel +44-1-387-7050)
4. If IPMS.ORDescriptor.formal-name.directory-name is present,
then a text representation should be 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)" should be appended to the
address. The effort of correlating P1 and P2 information is
too great to justify the gateway sending Receipt
Notifications.
6. If IPMS.RecipientSpecifier.reply-request is True, an
822.comment "(Reply requested)" should be appended to the
address.
If IPMS.ORDescriptor.formal-name is absent,
IPMS.ORDescriptor.free-form-name should be converted to ASCII,
and used as 822.phrase within the RFC 822 822.group syntax. For
example:
Free Form Name ":" ";"
Steps 3-6 should then be 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 allows for good things to
happen when messages pass multiple times across the X.400/RFC 822
Kille [page 60]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
boundary.
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 reasons:
- 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 manner which cannot be generated naturally. In |
practice, a form is chosen where the likelyhood of generation is |
low enough to be treated as impossible.
4.7.3.1. 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. |
4.7.3.2. 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 built as |
[ printablestring ] "*" [ std-or-address ]
with EBNF.printablestring being the |
IPMS.IPMIdentifier.user-relative-identifier, and std-or-address |
being an encoding of the IPMS.IPMIdentifier.user. If necessary, |
the 822.quoted-string encoding is used. For example: |
<"147*/S=DUMITRESCU/O=ap11/PRMD=SIEMENS MCHP04/ADMD=DBP/C=DE/"@MHS>
Kille [page 61]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
4.7.3.3. 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 O/R Address components
derived from it are used to set IPMS.IPMIdentifier.user.
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.
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 RFC 822 |
generated ID.
Otherwise, the ID is X.400 generated. Use the
IPMS.IPMIdentifer.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.IPMIdentifer.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 "Reply-To:" and "References:", the encoding 822.phrase may be |
used as an alternative to 822.msg-id. This is mapped with |
IPMS.IPMIdentifer, by a simple mapping with |
IPMS.IPMIdentifer.user-relative-identifier. |
Kille [page 62]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
4.7.3.6. RFC 987 backwards compatibility |
The mapping proposed 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 is encouraged |
to recognise message IDs generated by RFC 987.
Kille [page 63]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
Chapter 5 - Detailed Mappings
This chapter gives 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
5.1.1. Basic Approach
A single IP Message is generated. The RFC 822 headers are used
to generate the IPMS.Heading. The IP Message will have one IA5
IPMS.BodyPart containing the RFC 822 message body.
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:
rfc-822-field HEADING-EXTENSION
VALUE RFC822Field
::= id-rfc-822-field
RFC822Field ::= IA5String |
The Object Identifier id-rfc-822-field is defined in Appendix D. |
Kille [page 64]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
To encode any RFC 822 Header using this extension, the |
RFC822Field should be set to the 822.field omitting the |
trailing CRLF (e.g., "Fruit-Of-The-Day: Kiwi Fruit"). Structured
fields should be unfolded. There should be no space before the |
":". The reverse mapping builds the RFC 822 field in a
straightforward manner.
5.1.3. Generating the IPM
The IPM (IPMS Service Request) is generated according to the
rules of this section. The IPMS.IPM.body usually consists of one |
IPMS.BodyPart of type IPMS.IA5TextbodyPart with
IPMS.IA5TextBodyPart.parameters.repertoire set to the default
(ia5) which contains the body of the RFC 822 message. The |
exception is where there is a "Comments:" field in the RFC 822 |
header.
If no specific 1988 features are used, the IPM generated
should be encoded as content type 2. Otherwise, it should be
encoded as content type 22. The latter will always be the case
if extension header fields are generated.
When generating the IPM, the issue of upper bounds must be |
considered. At the MTS and MTA level, this specification is |
strict about enforcing upper bounds. Three options are available |
at the IPM level. Use of any of these options conforms to this |
standard. |
1. Ignore upper bounds, and generate messages in the natural |
manner. This assumes that if any truncation is done, it |
will happen at the recipient UA. This will maximise |
transfer of information, but may break some recipient UAs. |
2. Reject any inbound message which would cause a message |
violating constraints to be generated. This will be robust, |
but may prevent useful communication. |
3. 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. |
These choices have different advantages and disadvantages, and |
the choice will depend on the exact application of the gateway. |
Kille [page 65]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
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 should
be generated by the gateway. With the exception of "Received:", |
the values of multiple fields should be merged (e.g., If there |
are two "To:" fields, then the mailboxes of both should be used).
Information should be generated from the standard RFC 822 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 msg-id the mappings of Chapter 4 are used
for each 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.
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.
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 several |
values, they are mapped to IPMS.Heading.related-IPMs, along |
Kille [page 66]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
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
mapping referenced in Chapter 3 from ASCII to T.61.
Comments:
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: ". This body part should precede |
the other one.
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.
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 should be applied to
RFC 822 fields where the content of the field does not
conform to RFC 822 (e.g., a Date: field with unparsable
syntax).
5.1.4. Mappings to the MTS Abstract Service
The MTS.MessageSubmissionEnvelope comprises |
MTS.PerMessageSubmissionFields, and |
MTS.PerRecipientMessageSubmissionFields. The mandatory |
parameters should be defaulted as follows.
Kille [page 67]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
MTS.PerMessageSubmissionFields.originator-name
This is always generated from 822-MTS, 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 822-MTS, as defined in
Chapter 4.
Optional components should be left out, and default components
defaulted, with two exceptions. For
MTS.PerMessageSubmissionFields.per-message-indicators, the
following settings should be made:
- Alternate recipient should be allowed, as it seems desirable
to maximise the opportunity for (reliable) delivery.
- Content return request should be set according to the issues
discussed in Section 5.2.
MTS.PerMessageSubmissionFields.original-encoded-information-types
should be made a set of one element
BuiltInEncodedInformationTypes.ia5-text.
The MTS.PerMessageSubmissionFields.content-correlator should be |
encoded as IA5String, and contain the Subject:, Message-ID:, |
Date:, and To: fields (if present). This should include the |
strings "Subject:", "Date:", "To:", "Message-ID:", and |
appropriate folding. This should be truncated to |
MTS.ub-content-correlator-length (512) characters. In addition, |
if there is a "Subject:" field, the |
MTS.PerMessageSubmissionFields.content-identifier, should be set |
to the contents of it, truncated to MTS.ub-content-id-length |
(16). 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.5. 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:
Kille [page 68]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
- So the 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 RFC 822/X.400 looping caused by distribution |
lists or redirects
The following mappings are defined.
Message-Id:
If this is present, the
MTA.PerMessageTransferFields.message-identifier should be
generated from it, using the mappings described in
Chapter 4.
Date:
This is used to set the first component of
MTA.PerMessageTransferFields.trace-information
(MTA.TraceInformationElement). The 822-MTS originator
should be 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
should be generated in an analogous manner.
Received:
All RFC 822 trace is used to derive
MTA.PerMessageTransferFields.trace-information and
MTA.PerMessageTransferFields.internal-trace-information.
Processing of Received: lines should follow processing of
Kille [page 69]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
Date:, and should be done from the the bottom to the top of
the RFC 822 header (i.e., in chronological order). If other
trace elements are processed (Via:, X400-Received:), care |
should be taken to keep the relative ordering correct. The
initial element of
MTA.PerMessageTransferFields.trace-information will be
generated already (from Date:).
Consider the Received: field in question. If the "by" part
of the received is present, use it to derive an
MTS.GlobalDomainIdentifier. 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.
This removal should be done in cases where the message is
being transferred to another MTA or MD where there is no |
bilateral agreement to preserve internal trace beyond the
local MD. The trace creation is as for internal trace
described below, except that no MTA field is needed.
Then add a new element (MTA.InternalTraceInformationElement)
to MTA.PerMessageTransferFields.internal-trace-information,
creating this if needed. This shall be done, even if |
inter-MD trace is created. The
MTA.InternalTraceInformationElement.global-domain-identifier
should be set to the value derived. The
MTA.InternalTraceInformationElement.mta-supplied-information
(MTA.MTASuppliedInformation) should be 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 should be |
taken from the "by" component of the "Received:" field, |
truncated to MTS.ub-mta-name-length (32). For example:
Kille [page 70]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
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 |
Note that before transferring the message to some ADMDs, |
additional trace stripping may be required, as the implied path |
through multiple MDs would violate ADMD policy. |