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 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 us a human
oriented mapping (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 -> 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 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 number 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 RFC822 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 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.
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 "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
"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 proposed 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.
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. RFC822 -> X.400
5.1.1. Basic Approach
A single IP Message is generated. 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 RFC822Field
::= id-rfc-822-field
RFC822Field ::= IA5String
The Object Identifier id-rfc-822-field is defined in Appendix D.
To encode any RFC822 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 RFC822 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 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 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
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 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.
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 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.
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 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
RFC822 fields where the content of the field does not
conform to RFC822 (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.
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 a
printable string representation of 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:
- 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 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, although this
may later be dropped (see the procedures for "Received:").
Received:
All RFC822 trace is used to derive
MTA.PerMessageTransferFields.trace-information and
MTA.PerMessageTransferFields.internal-trace-information.
Processing of Received: lines should follow processing of
Date:, and should be done from the the bottom to the top of
the RFC822 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 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:
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.
Two extended fields must be mapped, in order to prevent looping.
"DL-Expansion-History:" is mapped to
MTA.PerMessageTransferFields.extensions.dl-expansion-history.
"Redirection-History:" is mapped to
MTA.PerRecipientMessageTransferFields.extensions.redirection-history.
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 these fields to X.400, with the
exception of "DL-Expansion-History" and "Redirection-History"
described in the previous section. However, it is usually desirable
and beneficial to do so, particularly to facilitate support of a
message traversing multiple gateways. These mappings may be onto
MTA, MTS, or IPMS services.
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 should 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 should 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 should be assigned.
Date:
A value will always be generated
From:If this is not generated by the mapping, it should be
assigned equal to the 822-MTS Originator. If this is
gateway generated, an appropriate 822.phrase should be
added.
At least one recipient field
If no recipient fields are generated, a field "To: list:;",
should be added.
This will ensure minimal RFC822 compliance. When generating RFC
822 headers, folding should be used in an appropriate manner.
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).
IPMS.Heading.this-IPM
Mapped to "Message-ID:".
IPMS.Heading.originator
If IPMS.Heading.authorizing-users is present this is mapped
to Sender:, if not to "From:".
IPMS.Heading.authorizing-users
Mapped to "From:".
IPMS.Heading.primary-recipients
Mapped to "To:".
IPMS.Heading.copy-recipients
Mapped to "Cc:".
IPMS.Heading.blind-copy-recipients
Mapped to "Bcc:".
IPMS.Heading.replied-to-ipm
Mapped to "In-Reply-To:".
IPMS.Heading.obsoleted-IPMs
Mapped to the extended RFC822 field "Obsoletes:"
IPMS.Heading.related-IPMs
Mapped to "References:".
IPMS.Heading.subject
Mapped to "Subject:". The contents are converted to ASCII
(as defined in Chapter 3). Any CRLF are not mapped, but
are used as points at which the subject field must be
folded.
IPMS.Heading.expiry-time
Mapped to the extended RFC822 field "Expiry-Date:".
IPMS.Heading.reply-time
Mapped to the extended RFC822 field "Reply-By:".
IPMS.Heading.reply-recipients
Mapped to "Reply-To:".
IPMS.Heading.importance
Mapped to the extended RFC822 field "Importance:".
IPMS.Heading.sensitivity
Mapped to the extended RFC822 field "Sensitivity:".
IPMS.Heading.autoforwarded
Mapped to the extended RFC822 field "Autoforwarded:".
The standard extensions (Annex H of X.420 / ISO 10021-7) are mapped
as follows:
incomplete-copy
Mapped to the extended RFC822 field "Incomplete-Copy:".
language
Mapped to the extended RFC822 field "Language:", filling in
the two letter code. If possible, the language-description
should be filled in with a human readable description of the
language.
If the RFC822 extended header is found, this should be mapped onto
an RFC822 header, as described in Section 5.1.2.
If a non-standard extension is found, it should be discarded, unless
the gateway understands the extension and can perform an appropriate
mapping onto an RFC822 header field. If extensions are discarded,
the list should be indicated in the extended RFC822 field
"Discarded-X400-IPMS-Extensions:".
The IPMS.Body is mapped into the RFC822 message body. Each
IPMS.BodyPart is converted to ASCII as follows:
IPMS.IA5Text
The mapping is straightforward (see Chapter 3).
IPMS.MessageBodyPart
The X.400 -> RFC822 mapping should be recursively applied,
to generate an RFC822 Message. If present, the
IPMS.MessageBodyPart.parameters.delivery-envelope should be
used for the MTS Abstract Service Mappings. If present, the
IPMS.MessageBodyPart.parameters.delivery-time should be
mapped to the extended RFC822 field "Delivery-Date:".
Other
If other body parts can be mapped to IA5, either by use of
mappings defined in X.408 [CCITT88a], or by other reasonable
mappings, this should be done unless content conversion is
prohibited.
If some or all of the body parts cannot be converted there are three
options. All of these conform to this standard. A different choice
may be made for the case where no body part can be converted:
1. The first option is to reject the message, and send a non-
delivery notification. This must always be done if
conversion is prohibited.
2. The second option is to map a missing body part to something
of the style:
*********************************
There was a foobar here
The widget gateway ate it
*********************************
This will allow some useful information to be transferred.
As the recipient is a human (IPMS), then suitable action
should be available.
3. Finally both can be done. In this case, the supplementary
information in the (positive) Delivery Report should make
clear that something was sent on to the recipient with
substantial loss of information.
Where there is more than one IPMS.BodyPart, the mapping defined by
Rose and Stefferud in [Rose85a], should be used to map the separate
IPMS.BodyParts in the single RFC822 message body. If this is done,
a "Message-Type:" field with value "Multiple part" should be added,
which will indicate to a receiving gateway that the message may be
unfolded according to RFC934.
For backwards compatibility with RFC987, the following procedures
should also be followed. If there are two IA5 body parts, and the
first starts with the string "RFC-822-Headers:" as the first line,
then the remainder of this body part should be appended to the RFC
822 header.
5.3.5. Mappings from an IP Notification
A message is generated, with the following fields:
From:
Set to the MTS.MessageDeliveryEnvelope.other-
fields.originator-name.
To: Set to the IPMS.IPN.ipm-originator.
Subject:
Set to something of the form "X.400 Inter-Personal Receipt
Notification".
Message-Type:
Set to "InterPersonal Notification"
References:
Set to IPMS.IPN.subject-ipm
The following EBNF is defined for the body of the Message. This
format is defined to ensure that all information from an
interpersonal notification is available to the end user in a uniform
manner.
ipn-body-format = ipn-description <CRLF>
[ ipn-extra-information <CRLF> ]
ipn-content-return
ipn-description = ipn-receipt / ipn-non-receipt
ipn-receipt = "Your message to:" preferred-recipient <CRLF>
"was received at" receipt-time <CRLF> <CRLF>
"This notification was generated"
acknowledgement-mode <CRLF>
"The following extra information was given:" <CRLF>
ipn-suppl <CRLF>
ipn-non-receipt "Your message to:"
preferred-recipient <CRLF>
ipn-reason
ipn-reason = ipn-discarded / ipn-auto-forwarded
ipn-discarded = "was discarded for the following reason:"
discard-reason <CRLF>
ipn-auto-forwarded = "was automatically forwarded." <CRLF>
[ "The following comment was made:"
auto-comment ]
ipn-extra-information =
"The following information types were converted:"
encoded-info
ipn-content-return = "The Original Message is not available"
/ "The Original Message follows:"
<CRLF> <CRLF> message
preferred-recipient = mailbox
receipt-time = date-time
auto-comment = printablestring
ipn-suppl = printablestring
non-receipt-reason = "Discarded" / "Auto-Forwarded"
discard-reason = "Expired" / "Obsoleted" /
"User Subscription Terminated"
acknowledgement-mode = "Manually" / "Automatically"
The mappings for elements of the common fields of IPMS.IPN
(IPMS.CommonFields) onto this structure and the message header are:
subject-ipm
Mapped to "References:"
ipm-originator
Mapped to "To:".
ipm-preferred-recipient
Mapped to EBNF.preferred-recipient
conversion-eits
Mapped to EBNF.encoded-info in EBNF.ipn-extra-information
The mappings for elements of IPMS.IPN.non-receipt-fields
(IPMS.NonReceiptFields) are:
non-receipt-reason
Used to select between EBNF.ipn-discarded and
EBNF.ipn-auto-forwarded
discard-reason
Mapped to EBNF.discard-reason
auto-forward-comment
Mapped to EBNF.auto-comment
returned-ipm
If present, the second option of EBNF.ipn-content-return
should be chosen, and an RFC822 mapping of the message
included. Otherwise the first option should be chosen.
The mappings for elements of IPMS.IPN.receipt-fields
(IPMS.ReceiptFields) are:
receipt-time
Mapped to EBNF.receipt-time
acknowledgement-mode
Mapped to EBNF.acknowledgement-mode
suppl-receipt-info
Mapped to EBNF.ipn-suppl
An example notification is:
From: Steve Kille <steve@cs.ucl.ac.uk>
To: Julian Onions <jpo@computer-science.nottingham.ac.uk>
Subject: X400 Inter-personal Receipt Notification
Message-Type: InterPersonal Notification
References: <1229.614418325@UK.AC.NOTT.CS>
Date: Wed, 21 Jun 89 08:45:25 +0100
Your message to: Steve Kille <steve@cs.ucl.ac.uk>
was automatically forwarded.
The following comment was made:
Sent on to a random destination
The following information types were converted: g3fax
The Original Message is not available
5.3.6. Mappings from the MTS Abstract Service
This section describes the MTS mappings for User Messages (IPM and
IPN). This mapping is defined by specifying the mapping of
MTS.MessageDeliveryEnvelope. The following extensions to RFC822 are
defined to support this mapping:
mts-field = "X400-MTS-Identifier" ":" mts-msg-id
/ "X400-Originator" ":" mailbox
/ "X400-Recipients" ":" 1#mailbox
/ "Original-Encoded-Information-Types" ":"
encoded-info
/ "X400-Content-Type" ":" mts-content-type
/ "Content-Identifier" ":" printablestring
/ "Priority" ":" priority
/ "Originator-Return-Address" ":" 1#mailbox
/ "DL-Expansion-History" ":" mailbox ";" date-time ";"
/ "Redirection-History" ":" redirection
/ "Conversion" ":" prohibition
/ "Conversion-With-Loss" ":" prohibition
/ "Requested-Delivery-Method" ":"
1*( labelled-integer )
/ "Delivery-Date" ":" date-time
/ "Discarded-X400-MTS-Extensions" ":"
1#( oid / labelled-integer )
prohibition = "Prohibited" / "Allowed"
mts-msg-id = "[" global-id ";" *text "]"
mts-content-type = "P2" / labelled-integer
/ object-identifer
priority = "normal" / "non-urgent" / "urgent"
redirection = mailbox ";" "reason" "="
redirection-reason
";" date-time
redirection-reason =
"Recipient Assigned Alternate Recipient"
/ "Originator Requested Alternate Recipient"
/ "Recipient MD Assigned Alternate Recipient"
These elements are only appropriate for physical delivery. They
are represented as comments in the "X400-Recipients:" field, as
described in Section 4.6.2.2.
originator-certificate
message-token
content-confidentiality-algorithm-identifier
content-integrity-check
message-origin-authentication-check
message-security-label
proof-of-delivery-request
These elements imply use of security services not available in the
RFC822 environment. If they are marked as critical for transfer
or delivery, then the message should be rejected. Otherwise they
should be discarded.
redirection-history
Each element is mapped to an extended RFC822 field
"Redirection-History:". They should be ordered in the
message header, so that the most recent redirection comes
first (same order as trace).
dl-expansion-history
Each element is mapped to the extended RFC822 field
"DL-Expansion-History:". They should be ordered in the
message header, so that the most recent expansion comes
first (same order as trace).
If any MTS (or MTA) Extensions not specified in X.400 are present,
and they are marked as critical for transfer or delivery, then the
message should be rejected. If they are not so marked, they can
safely be discarded. The list of discarded fields should be
indicated in the extended header "Discarded-X400-MTS-Extensions:".
5.3.7. Mappings from the MTA Abstract Service
There are some mappings at the MTA Abstract Service level which are
done for IPM and IPN. These can be derived from
MTA.MessageTransferEnvelope. The reasons for the mappings at this
level, and the violation of layering are:
- Allowing for multiple recipients to share a single RFC822
message.
- Making the X.400 trace information available on the RFC822
side.
- Making any information on deferred delivery available.
The 822-MTS recipients should be calculated from the full list of
X.400 recipients. This is all of the members of
MTA.MessageTransferEnvelope.per-recipient-fields being passed
through the gateway, where the responsibility bit is set. In
some cases, a different RFC822 message would be calculated for
each recipient. If this is due to differing service requests for
each recipient, then a different message should be generated.
If it is due only to the request for non-disclosure of
recipients, then the "X400-Recipients:" field should be omitted,
and only one message sent.
The following EBNF is defined for extended RFC822 headers:
mta-field = "X400-Received" ":" x400-trace
/ "Deferred-Delivery" ":" date-time
/ "Latest-Delivery-Time" ":" date-time
x400-trace = "by" md-and-mta ";"
[ "deferred until" date-time ";" ]
[ "converted" "(" encoded-info ")" ";" ]
[ "attempted" md-and-mta ";" ]
action-list
";" arrival-time
md-and-mta = [ "mta" mta "in" ] global-id
mta = word
arrival-time = date-time
action-list = 1#action
action = "Redirected"
/ "Expanded"
/ "Relayed"
/ "Rerouted"
If MTA.PerMessageTransferFields.deferred-delivery-time is present,
use it to generate a Deferred-Delivery: field. For some reason,
X.400 does not make this information available at the MTS level on
delivery. X.400 profiles, and in particular the CEN/CENELEC profile
for X.400(1984) [Systems85a], specify that this element must be
supported at the first MTA. If it is not, the function may
optionally be implemented by the gateway: that is, the gateway should
hold the message until the time specified in the protocol element.
Thus, it is expected that the value of this element will often be in
the past. For this reason, the extended RFC822 field is primarily
for information.
Merge MTA.PerMessageTransferFields.trace-information, and
MTA.PerMessageTransferFields.internal-trace-information to produce a
single ordered trace list. If Internal trace from other management
domains has not been stripped, this may require complex interleaving.
Use this to generate a sequence of "X400-Received:" fields. The only
difference between external trace and internal trace will be the
extra MTA information in internal trace elements.
When generating an RFC822 message all trace fields (X400- Received
and Received) should be at the beginning of the header, before any
other fields. Trace should be in chronological order, with the most
recent element at the front of the message. A simple example trace
(external) is:
X400-Received: by /PRMD=UK.AC/ADMD=Gold 400/C=GB/ ; Relayed ;
Tue, 20 Jun 89 19:25:11 +0100
A more complex example (internal):
X400-Received: by mta UK.AC.UCL.CS in
/PRMD=UK.AC/ADMD=Gold 400/C=GB/ ;
deferred until Tue, 20 Jun 89 14:24:22 +0100 ;
converted (undefined, g3fax) ";" attempted /ADMD=Foo/C=GB/ ;
Relayed, Expanded, Redirected ; Tue, 20 Jun 89 19:25:11 +0100
5.3.8. Mappings from Report Delivery
Delivery reports are mapped at the MTS service level. This means
that only reports destined for the MTS user will be mapped. Some
additional services are also taken from the MTA service.
5.3.8.1. MTS Mappings
A Delivery Report service will be represented as
MTS.ReportDeliveryEnvelope, which comprises of per-report-fields
(MTS.PerReportDeliveryFields) and per-recipient-fields.
A message should be generated with the following fields:
From:
An administrator at the gateway system. This is also the
822-MTS originator.
To: A mapping of the
MTA.ReportTransferEnvelope.report-destination-name. This is
also the 822-MTS recipient.
Message-Type:
Set to "Delivery Report".
Subject:
Something of the form "X.400 Delivery Report".
The format of the body of the message is defined to ensure that all
information is conveyed to the RFC822 user in a consistent manner.
This gives a summary of critical information, and then a full listing
of all parameters:
dr-body-format = dr-summary <CRLF>
dr-recipients <CRLF>
dr-extra-information <CRLF>
dr-content-return
dr-content-return = "The Original Message is not available"
/ "The Original Message follows:"
<CRLF> <CRLF> message
dr-summary = "This report relates to your message:" <CRLF>
content-correlator <CRLF> <CRLF>
"of" date-time <CRLF> <CRLF>
"It was generated by:" report-point <CRLF>
"at" date-time <CRLF> <CRLF>
"It was later converted to RFC822 by:" mailbox <CRLF>
"at" date-time <CRLF> <CRLF>
dr-recipients = *(dr-recipient <CRLF> <CRLF>)
dr-recipient = dr-recip-success / dr-recip-failure
dr-recip-success =
"Your message was successfully delivered to:"
mailbox "at" date-time
dr-recip-failure = "Your message was not delivered to:"
mailbox <CRLF>
"for the following reason:" *word
dr-extra-information =
"-----------------------------------------------" <CRLF> <CRLF>
"The following information is derived from the Report" <CRLF>
"It may be useful for problem diagnosis:" <CRLF> <CRLF>
drc-field-list
drc-field-list = *(drc-field <CRLF>)
drc-field = "Subject-Submission-Identifier" ":"
mts-msg-id
/ "Content-Identifier" ":" printablestring
/ "Content-Type" ":" mts-content-type
/ "Original-Encoded-Information-Types" ":"
encoded-info
/ "Originator-and-DL-Expansion-History" ":"
dl-history
/ "Reporting-DL-Name" ":" mailbox