822.local-part. In other cases the remaining components are
simply encoded as 822.local-part using the
EBNF.std-or-address syntax. If necessary, the
822.quoted-string encoding is used. The following are
examples of legal quoting: "a b".c@x; "a b.c"@x. Either
form may be generated, but the latter is preferred.
If the derived 822.local-part can only be encoded by use of
822.quoted-string, then use of the mapping defined
in [Kille89b] may be appropriate. Use of this mapping is
discouraged.
4.4. Repeated Mappings
There are two types of repeated mapping:
1. A recursive mapping, where the repeat is within one gateway
2 A source route, where the repetition occurs across multiple
gateways
4.4.1. Recursive Mappings
It is possible to supply an address which is recurive 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 RFC822 address, and then back to the
X.400 address:
C = "XX"
ADMD = "YY"
O = "ZZ"
Surname = "Smith"
In some situations this type of recursion may be frequent. It is
important that 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 RFC822 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 RFC822) 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 RFC822 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 = "Griddle MHS Providers"
Organisation = "Widget Corporation"
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 RFC822 and X.400 services are partitioned.
The syntax may be used to source route. THIS IS STRONGLY
DISCOURAGED. For example:
X.400 -> RFC822 -> 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:
RFC822 -> X.400 -> RFC822
"/C=UK/ADMD=BT/PRMD=AC/RFC-822=jj(a)seismo.css.gov/"@monet.berkeley.edu
This will be sent to monet.berkeley.edu by RFC822, then to the AC
PRMD by X.400, and then to jj@seismo.css.gov by RFC822.
4.5. Directory Names
Directory Names are an optional part of O/R Name, along with O/R
Address. The RFC822 addresses are mapped onto the O/R Address
component. As there is no functional mapping for the Directory Name
on the RFC822 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.
Note:There is ongoing work on specification of a "user friendly"
format for directory names. If this is adopted as an
internet standard, it will be recommended, but not required,
for use here.
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. RFC822 -> 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 are made for each component of
MTS.PerRecipientMessageSubmissionFields.
recipient-name
This is derived from the 822-MTS recipient by the basic
ORAddress mapping.
originator-report-request
This is be set according to content return policy, as
discussed in Section 5.2.
explicit-conversion
This optional component is omitted, as this service is not
needed
extensions
The default value (no extensions) is used
4.6.2. X.400 -> RFC822
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 RFC822 fields are added for the MTS Originator and Recipients.
The information discarded at the 822-MTS level will be present in
these fields. In some cases a (positive) delivery report will be
generated.
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 is
discarded. (Note that it will be presented to the user, as described
in 4.6.2.2).
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, where the
responsibility bit is set, onto an 822-MTS recipient.
4.6.2.2. Generation of RFC822 Headers
Not all per-recipient information can be passed at the 822-MTS level.
For this reason, two new RFC822 headers are created, in order to
carry this information to the RFC822 recipient. These fields are
"X400-Originator:" and "X400-Recipients:".
The "X400-Originator:" field is 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 shall be
represented in an 822.comment.
Recipient names, taken from each value of
MTS.OtherMessageDeliveryFields.this-recipient-name and
MTS.OtherMessageDeliveryFields.other-recipient-names are made
available to the RFC822 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 RFC822 recipient, as the "X400-Recipients field is only
given one address.
There is a problem if there are multiple RFC822 recipients, and
disclosure of recipients is prohibited. Two options are allowed:
1. Generate one copy of the message for each RFC822 recipient,
with the "X400-Recipients field correctly set to the
recipient of that copy. This is functionally correct, but
is likely to be more expensive.
2. Discard the per-recipient information, and insert a field:
X400-Recipients: non-disclosure:;
This is the recommended option.
A third option of ignoring the disclosure flag is not allowed. If
any MTS.ORName.directory-name is present, it shall be represented in
an 822.comment.
If MTS.OtherMessageDeliveryFields.orignally-intended-recipient-name
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 descrined in Section
5.3.6. Other information is represented in an 822.comment associated
associated with MTS.OtherMessageDeliveryFields.this-recipient-name,
The message may be delivered to different RFC822 recipients, and so
several addresses in the "X400-Recipients:" field may have such
comments. The non-commented recipient is the RFC822 recipient. The
EBNF of the comment is:
redirect-comment =
[ "Originally To:" ] mailbox "Redirected"
[ "Again" ] "on" date-time
"To:" redirection-reason
redirection-reason =
"Recipient Assigned Alternate Recipient"
/ "Originator Requested Alternate Recipient"
/ "Recipient MD Assigned Alternate Recipient"
It is derived from
MTA.PerRecipientMessageTransferFields.extension.redirection-history.
An example of this is:
X400-Recipients: postmaster@widget.com (Originally To:
sales-manager@sales.widget.com Redirected
on Thu, 30 May 91 14:39:40 +0100 To: Originator Assigned
Alternate Recipient postmaster@sales.widget.com 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 RFC822
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.
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)".
4.6.2.3. Delivery Report Generation
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 RFC822 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
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 RFC822 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 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. RFC822 -> X.400
To derive IPMS.ORDescriptor from an RFC822 address.
1. Take the address, and extract an EBNF.822-address. 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 IMPS.ORDescriptor.formal-name.
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 use a human oriented
mapping (as described in Chapter 3). 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.reply-request and
IPMS.RecipientSpecifier.notification-requests are set to default
values (none and false).
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, and a IPMS.ORDescriptor with only an
free-form-name component built from it.
4.7.2. X.400 -> RFC822
Mapping from IPMS.ORDescriptor to RFC822 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
822.route 822.addr-spec, then a 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:
(Tel +44-1-387-7050)
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)" is appended to the address.
If both receipt and non-receipt notfications are requested,
the comment relating to the latter may be omitted, to make
the RFC822 address cleaner. 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)" is appended to the address.
If IPMS.ORDescriptor.formal-name is absent, IPMS.ORDescriptor.free-
form-name is converted to ASCII, and used as 822.phrase within the
RFC822 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 RFC822 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/RFC822
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
systematic manner. The mapping is defined so that the possibility of
clashes is 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. The upper
bound on this component is 64. The options for handling this are
discussed in Section 5.1.3.
4.7.3.2. IPMS.IPMIdentifier represented in RFC822
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=Dietrich/O=Siemens/ADMD=DBP/C=DE/"@MHS>
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 RFC822 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 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 "InReply-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 is encouraged to recognise message
IDs generated by RFC987. This is not required.
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
5.1.1. Basic Approach
A single IP Message is generated from an RFC822 message The RFC822
headers are used to generate the IPMS.Heading. The IP Message will
have one IA5 IPMS.BodyPart containing the RFC822 message body.
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"). Structured 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 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 RFC822 message. The exception is
where there is a "Comments:" field in the RFC822 header.
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 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 is likely 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.
If the Free Form name is truncated, it may lead to breaking
RFC822 comments, which will cause an awkward reverse
mapping.
These options have different advantages and disadvantages, and the
choice will depend on the exact application of the gateway.
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.
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 should be mapped to a zero length sequence.
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
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 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 shall 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 is applied to RFC
822 fields where the content of the field does not conform
to RFC822 (e.g., a Date: field with unparseable syntax).
5.1.4. 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 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 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.
- Content return request is set according to the issues
discussed in Section 5.2.
MTS.PerMessageSubmissionFields.original-encoded-information-types is
a set of one element BuiltInEncodedInformationTypes.ia5-text.
The MTS.PerMessageSubmissionFields.content-correlator is encoded as
IA5String, and contains the Subject:, Message-ID:, Date:, and
To: fields (if present). This includes the strings "Subject:",
"Date:", "To:", "Message-ID:", and appropriate folding. 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 should 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.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:
- So the the MTS Message Identifier can be generated from the
RFC822 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, the
MTA.PerMessageTransferFields.message-identifier is 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 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 be done from the the bottom to the top of the RFC822
header (i.e., in chronological order). When other trace
elements are processed (X400-Received: in all cases and Via:
if Appendix B is supported), the relative ordering shall be
retained correctly. The initial element of
MTA.PerMessageTransferFields.trace-information will be
generated already (from Date:), unless the message has
previously been in X.400, when it will be derived from the
X.400 trace information.
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 shall be done in cases where the message is
being transferred to another 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
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
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. This will depend on bilateral
agreement with the ADMD.
5.1.6. Mapping New Fields
This specification defines a number of new fields for Reports,
Notifications and IP Messages in Section 5.3. As this specification
only aims to preserve existing services, a gateway conforming to this
specification does not need to map all of these fields to X.400.
Two extended fields must be mapped, in order to prevent looping.
"DL-Expansion-History:" is mapped to
MTA.PerMessageTransferFields.extensions.dl-expansion-history X400-
Received: must 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 should 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:.
Some field that shall not be mapped, and should be discarded. The
following cannot be mapped back:
- Discarded-X400-MTS-Extensions:
- Message-Type:
- Discarded-X400-IPMS-Extensions:
If Message-Type: is set to "Multiple Part", then the messge is
encoded according to RFC934, and this may be mapped on to the
corresponding X.400 structures.
The following may cause problems, due to other information not being
mapped back (e.g., extension numbers), or due to changes made on the
RFC822 side due to list expansion:
- X400-Content-Type:
- X400-Originator:
- X400-Recipients:
- X400-MTS-Identifier:
Other fields may be either discarded or mapped to X.400. It is
usually desirable and beneficial to do map, particularly to
facilitate support of a message traversing multiple gateways. These
mappings may be onto MTA, MTS, or IPMS services. The level of
support for this reverse mapping should be indicated in the gateway
conformace statement.
5.2. Return of Contents
It is not clear how widely supported the X.400 return of contents
service will be. Experience with X.400(1984) suggests that support
of this service may not be universal. As this service is expected in
the RFC822 world, two approaches are specified. The choice will
depend on the use of X.400 return of contents withing the X.400
community being serviced by the gateway.
In environments where return of contents is widely supported, content
return can be requested as a service. The content return service can
then be passed back to the end (RFC822) user in a straightforward
manner.
In environments where return of contents is not widely supported, a
gateway must make special provision to handle return of contents.
For every message passing from RFC822 -> X.400, content return
request will not be requested, and report request always will be.
When the delivery report comes back, the gateway can note that the
message has been delivered to the recipient(s) in question. If a
non-delivery report is received, a meaningful report (containing some
or all of the original message) can be sent to the 822-MTS
originator. If no report is received for a recipient, a (timeout)
failure notice shall be sent to the 822-MTS originator. The gateway
may retransmit the X.400 message if it wishes. When this approach is
taken, routing must be set up so that error reports are returned
through the same MTA. This approach may be difficult to use in
conjunction with some routing strategies.
5.3. X.400 -> RFC822
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 822-MTS recipients.
5.3.2. RFC822 Settings
An RFC822 Service requires to have a number of mandatory fields in
the RFC822 Header. Some 822-MTS services mandate specification of
an 822-MTS 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:
822-MTS 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 822-MTS 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 = "Obsoletes" ":" 1#msg-id
/ "Expiry-Date" ":" date-time
/ "Reply-By" ":" date-time
/ "Importance" ":" importance
/ "Sensitivity" ":" sensitivity
/ "Autoforwarded" ":" boolean
/ "Incomplete-Copy" ":"
/ "Language" ":" language
/ "Message-Type" ":" message-type
/ "Discarded-X400-IPMS-Extensions" ":" 1#oid
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"
The mappings and actions for the IPMS.Heading is 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 should be discarded, execpt 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