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