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 recursive at a single gateway. For example: C = "XX" ADMD = "YY" O = "ZZ" "RFC-822" = "Smith(a)ZZ.YY.XX" This is mapped first to an RFC 822 address, and then back to the X.400 address: C = "XX" ADMD = "YY" O = "ZZ" Surname = "Smith" In some situations this type of recursion may be frequent. It is important where this occurs, that no unnecessary protocol conversion occurs. This will minimise loss of service. 4.4.2. Source Routes The mappings defined are symmetrical and reversible across a single gateway. The symmetry is particularly useful in cases of (mail exploder type) distribution list expansion. For example, an X.400 user sends to a list on an RFC 822 system which he belongs to. The received message will have the originator and any 3rd party X.400 OR Addresses in correct format (rather than doubly encoded). In cases (X.400 or RFC 822) where there is common agreement on gateway identification, then this will apply to multiple gateways. When a message traverses multiple gateways, the mapping will always be reversible, in that a reply can be generated which will correctly reverse the path. In many cases, the mapping will also be symmetrical, which will appear clean to the end user. For example, if countries "AB" and "XY" have RFC 822 networks, but are interconnected by X.400, the following may happen: The originator specifies: Joe.Soap@Widget.PTT.XY
This is routed to a gateway, which generates: C = "XY" ADMD = "PTT" PRMD = "Griddle MHS Providers" Organization = "Widget Corporation" Surname = "Soap" Given Name = "Joe" This is then routed to another gateway where the mapping is reversed to give: Joe.Soap@Widget.PTT.XY Here, use of the gateway is transparent. Mappings will only be symmetrical where mapping equivalences are defined. In other cases, the reversibility is more important, due to the (far too frequent) cases where RFC 822 and X.400 services are partitioned. The syntax may be used to source route. THIS IS STRONGLY DISCOURAGED. For example: X.400 -> RFC 822 -> X.400 C = "UK" ADMD = "Gold 400" PRMD = "UK.AC" "RFC-822" = "/PN=Duval/DD.Title=Manager/(a)Inria.ATLAS.FR" This will be sent to an arbitrary UK Academic Community gateway by X.400. Then it will be sent by JNT Mail to another gateway determined by the domain Inria.ATLAS.FR (FR.ATLAS.Inria). This will then derive the X.400 OR Address: C = "FR" ADMD = "ATLAS" PRMD = "Inria" PN.S = "Duval" "Title" = "Manager"
Similarly: RFC 822 -> X.400 -> RFC 822 "/RFC-822=jj(a)seismo.css.gov/PRMD=AC/ADMD=BT/C=GB/"@monet.berkeley.edu This will be sent to monet.berkeley.edu by RFC 822, then to the AC PRMD by X.400, and then to email@example.com by RFC 822. 4.5. Directory Names Directory Names are an optional part of OR Name, along with OR Address. The RFC 822 addresses are mapped onto the OR Address component. As there is no functional mapping for the Directory Name on the RFC 822 side, a textual mapping is used. There is no requirement for reversibility in terms of the goals of this specification. There may be some loss of functionality in terms of third party recipients where only a directory name is given, but this seems preferable to the significant extra complexity of adding a full mapping for Directory Names. The Directory Name shall be represented within an RFC 822 comment using the comaptible formats of RFC 1484 or RFC 1485. It is recommended that the directory string format of RFC 1485 is used . The User Friendly Name form of RFC 1484 may be used . 4.6. MTS Mappings The basic mappings at the MTS level are: 1) SMTP originator -> MTS.PerMessageSubmissionFields.originator-name MTS.OtherMessageDeliveryFields.originator-name -> SMTP originator 2) SMTP recipient -> MTS.PerRecipientMessageSubmissionFields MTS.OtherMessageDeliveryFields.this-recipient-name -> SMTP recipient SMTP recipients and return addresses are encoded as EBNF.822-address. The MTS Originator is always encoded as MTS.OriginatorName, which maps onto MTS.ORAddressAndOptionalDirectoryName, which in turn maps onto MTS.ORName.
4.6.1. RFC 822 -> X.400 MTS Mappings From the SMTP Originator, use the basic ORAddress mapping, to generate MTS.PerMessageSubmissionFields.originator-name (MTS.ORName), without a DirectoryName. For recipients, the following settings are made for each component of MTS.PerRecipientMessageSubmissionFields. recipient-name This is derived from the SMTP recipient by the basic ORAddress mapping. originator-report-request This may either be set to "delivery-report", or set according to SMTP extensions as set out in Appendix A. 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 -> RFC 822 MTS Mappings The basic functionality is to generate the SMTP originator and recipients. There is information present on the X.400 side, which cannot be mapped into analogous SMTP services. For this reason, new RFC 822 fields are added for the MTS Originator and Recipients. The information discarded at the SMTP level will be present in these fields. In some cases a (positive) delivery report will be generated. 220.127.116.11. SMTP Mappings Use the basic ORAddress mapping, to generate the SMTP originator (return address) from MTS.OtherMessageDeliveryFields.originator-name (MTS.ORName). If MTS.ORName.directory-name is present, it is discarded. (Note that it will be presented to the user, as described in 18.104.22.168). The mapping uses the MTA level information, and maps each value of MTA.PerRecipientMessageTransferFields.recipient-name, where the responsibility bit is set, onto an SMTP recipient. Note:The SMTP recipient is conceptually generated from MTS.OtherMessageDeliveryFields.this-recipient-name. This is done by taking MTS.OtherMessageDeliveryFields.this-recipient-name, and generating an SMTP recipient according to the basic ORAddress
mapping, discarding MTS.ORName.directory-name if present. However, if this model was followed exactly, there would be no possibility to have multiple SMTP recipients on a single message. This is unacceptable, and so layering is violated. 22.214.171.124. Generation of RFC 822 Headers Not all per-recipient information can be passed at the SMTP level. For this reason, two new RFC 822 headers are created, in order to carry this information to the RFC 822 recipient. These fields are "X400-Originator:" and "X400-Recipients:". The "X400-Originator:" field is set to the same value as the SMTP originator. In addition, if MTS.OtherMessageDeliveryFields.originator-name (MTS.ORName) contains MTS.ORName.directory-name then this Directory Name shall be represented in an 822.comment. Recipient names, taken from each value of MTS.OtherMessageDeliveryFields.this-recipient-name and MTS.OtherMessageDeliveryFields.other-recipient-names are made available to the RFC 822 user by use of the "X400-Recipients:" field. By taking the recipients at the MTS level, disclosure of recipients will be dealt with correctly. However, this conflicts with a desire to optimise mail transfer. There is no problem when disclosure of recipients is allowed. Similarly, there is no problem if there is only one RFC 822 recipient, as the "X400-Recipients" field is only given one address. There is a problem if there are multiple RFC 822 recipients, and disclosure of recipients is prohibited. In this case, discard the per-recipient information. 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 described in Section 5.3.6. Other information is represented in an 822.comment associated with MTS.OtherMessageDeliveryFields.this-recipient-name, The message may be delivered to different RFC 822 recipients, and so several addresses in the "X400-Recipients:" field may have such comments. The non-commented recipient is the RFC 822 recipient. The EBNF of the comment is defined by redirect-comment.
redirect-comment = redirect-first *( redirect-subsequent ) redirect-first = "Originally To:" mailbox "Redirected on" date-time "To:" redirection-reason redirect-subsequent = mailbox "Redirected Again on" date-time "To:" redirection-reason redirection-history-item = "intended recipient" mailbox "redirected to" redirection-reason "on" date-time redirection-reason = "Recipient Assigned Alternate Recipient" / "Originator Requested Alternate Recipient" / "Recipient MD Assigned Alternate Recipient" / "Directory Look Up" / "Alias" It is derived from MTA.PerRecipientMessageTransferFields.extension.redirection-history. The values are taken from the X.400(92) Implementor's guide (Version 13, July 1995). The first three values are in X.400(88). The fourth value is in X.400(92), but has the name "recipient-directory- substitution-alternate-recipient". An example of this with two redirects is: X400-Recipients: firstname.lastname@example.org (Originally To: email@example.com Redirected on Thu, 30 May 91 14:39:40 +0100 To: Originator Requested Alternate Recipient firstname.lastname@example.org Redirected Again on Thu, 30 May 91 14:41:20 +0100 To: Recipient MD Assigned Alternate Recipient) In addition the following per-recipient services from MTS.OtherMessageDeliveryFields.extensions are represented in comments if they are used. None of these services can be provided on RFC 822 networks, and so in general these will be informative strings associated with other MTS recipients. In some cases, string values are defined. For the remainder, the string value shall be chosen by the implementor. If the parameter has a default value, then no comment shall be inserted when the parameter has that default value. 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)". 126.96.36.199. Delivery Report Generation If SMTP is used, the behaviour is specified in Appendix A. In other cases, if MTA.PerRecipientMessageTransferFields.per-recipient- indicators requires a positive delivery notification, this shall be generated by the gateway. Supplementary Information shall be set to indicate that the report is gateway generated. This information shall include the name of the gateway generating the report. 4.6.3. Message IDs (MTS) A mapping from 822.msg-id to MTS.MTSIdentifier is defined. The reverse mapping is not needed, as MTS.MTSIdentifier is always mapped onto new RFC 822 fields. The value of MTS.MTSIdentifier.local-part will facilitate correlation of gateway errors. To map from 822.msg-id, apply the standard mapping to 822.msg-id, in order to generate an MTS.ORAddress. The Country, ADMD, and PRMD components of this are used to generate MTS.MTSIdentifier.global- domain-identifier. MTS.MTSIdentifier.local-identifier is set to the 822.msg-id, including the braces "<" and ">". If this string is longer than MTS.ub-local-id-length (32), then it is truncated to this length. The reverse mapping is not used in this specification. It would be applicable where MTS.MTSIdentifier.local-identifier is of syntax 822.msg-id, and it algorithmically identifies MTS.MTSIdentifier.
4.7. IPMS Mappings All RFC 822 addresses are assumed to use the 822.mailbox syntax. This includes all 822.comments associated with the lexical tokens of the 822.mailbox. In the IPMS OR Names are encoded as MTS.ORName. This is used within the IPMS.ORDescriptor, IPMS.RecipientSpecifier, and IPMS.IPMIdentifier. An asymmetrical mapping is defined between these components. 4.7.1. RFC 822 -> X.400 To derive IPMS.ORDescriptor from an RFC 822 address. 1. Take the address, and extract an EBNF.822-address. Any source routing shall be removed. This can be derived trivially from either the 822.addr-spec or 822.route-addr syntax. This is mapped to MTS.ORName as described above, and used as 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 using a human oriented mapping (as described in Section 3.5). If the string is not null, it is assigned to IPMS.ORDescriptor.free-form-name. 3. IPMS.ORDescriptor.telephone-number is omitted. If IPMS.ORDescriptor is being used in IPMS.RecipientSpecifier, IPMS.RecipientSpecifier.reply-request and IPMS.RecipientSpecifier.notification-requests are set to default values (false and none). If the 822.group construct is present, any included 822.mailbox is encoded as above to generate a separate IPMS.ORDescriptor. The 822.group is mapped to T.61 (as described in Section 3.5), and a IPMS.ORDescriptor with only an free-form-name component built from it. 4.7.2. X.400 -> RFC 822 Mapping from IPMS.ORDescriptor to RFC 822 address. In the basic case, where IPMS.ORDescriptor.formal-name is present, proceed as follows.
1. Encode IPMS.ORDescriptor.formal-name (MTS.ORName) as EBNF.822-address. 2a. If IPMS.ORDescriptor.free-form-name is present, convert it to ASCII or T.61 (Section 3.5), 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 an 822.phrase taken from 822.local-part is added. 3 If IPMS.ORDescriptor.telephone-number is present, this is placed in an 822.comment, with the string "Tel ". The normal international form of number is used. For example: (Tel +44-181-333-7777) 4. If IPMS.ORDescriptor.formal-name.directory-name is present, then a text representation is placed in a trailing 822.comment. 5. If IPMS.RecipientSpecifier.report-request has any non- default values, then an 822.comment "(Receipt Notification Requested)", and/or "(Non Receipt Notification Requested)", and/or "(IPM Return Requested)" may be appended to the address. "(Receipt Notification Requested)" may be used to infer "(Non Receipt Notification Requested)". The effort of correlating P1 and P2 information is too great to justify the gateway sending Receipt Notifications. In RFC 1327, inclusion of these comments was mandatory. Experience has shown that the clutter and confusion caused to RFC 822 users does not justify the information conveyed. Implementors are recommended to not include these comments. Unless an application is found where retention of these comments is desirable, they will be dropped from the next version. 6. If IPMS.RecipientSpecifier.reply-request is True, an 822.comment "(Reply requested)" is appended to the address. If IPMS.ORDescriptor.formal-name is absent, IPMS.ORDescriptor.free- form-name is converted to ASCII (see section 3.5), and used as 822.phrase within the RFC 822 822.group syntax. For example: Free Form Name ":" ";"
Steps 3-6 are then followed. 4.7.3. IP Message IDs There is a need to map both ways between 822.msg-id and IPMS.IPMIdentifier. This allows for X.400 Receipt Notifications, Replies, and Cross References to reference an RFC 822 Message ID, which is preferable to a gateway generated ID. A reversible and symmetrical mapping is defined. This provides fully reversible mappings when messages pass multiple times across the X.400/RFC 822 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 low enough to be treated as impossible. 188.8.131.52. 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. 184.108.40.206. IPMS.IPMIdentifier represented in RFC 822 The 822.domain of 822.msg-id is set to the value "MHS". The 822.local-part of 822.msg-id is constructed by building a string of syntax EBNF.id-loc from IPMS.IPMIdentifier. id-loc ::= [ printablestring ] "*" [ std-or-address ]
EBNF.printablestring is the IPMS.IPMIdentifier.user-relative- identifier, and EBNF.std-or-address being an encoding of the IPMS.IPMIdentifier.user derived according to this specification. 822.local-part is derived from EBNF.id-loc, if necessary using the 822.quoted-string encoding. For example: <"147*/S=Dietrich/O=Siemens/ADMD=DBP/C=DE/"@MHS> 220.127.116.11. 822.msg-id -> IPMS.IPMIdentifier If the 822.local-part can be parsed as: [ printablestring ] "*" [ std-or-address ] and the 822.domain is "MHS", then this ID was X.400 generated. If EBNF.printablestring is present, the value is assigned to IPMS.IPMIdentifier.user-relative-identifier. If EBNF.std-or-address is present, the OR Address components derived from it are used to set IPMS.IPMIdentifier.user. Otherwise, this is an RFC 822 generated ID. In this case, set IPMS.IPMIdentifier.user-relative-identifier to a printable string encoding of the 822.msg-id without the angle braces and omit IPMS.IPMID.user. 18.104.22.168. IPMS.IPMIdentifier -> 822.msg-id If IPMS.IPMIdentifier.user is absent, and IPMS.IPMIdentifier.user- relative-identifier mapped to ASCII and angle braces added parses as 822.msg-id, then this is an RFC 822 generated ID. Otherwise, the ID is X.400 generated. Use the IPMS.IPMIdentifier.user to generate an EBNF.std-or-address form string. Build the 822.local-part of the 822.msg-id with the syntax: [ printablestring ] "*" [ std-or-address ] The printablestring is taken from IPMS.IPMIdentifier.user-relative- identifier. Use 822.quoted-string if necessary. The 822.msg-id is generated with this 822.local-part, and "MHS" as the 822.domain. 22.214.171.124. Phrase form In "In-Reply-To:" and "References:", the encoding 822.phrase may be used as an alternative to 822.msg-id. To map from 822.phrase to IPMS.IPMIdentifier, assign IPMS.IPMIdentifier.user-relative- identifier to the phrase. When mapping from IPMS.IPMIdentifier for "In-Reply-To:" and "References:", if IPMS.IPMIdentifier.user is
absent and IPMS.IPMIdentifier.user-relative-identifier does not parse as 822.msg-id, generate an 822.phrase rather than adding the domain MHS. 126.96.36.199. RFC 987 backwards compatibility The mapping defined here is different to that used in RFC 987, as the RFC 987 mapping lead to changed message IDs in many cases. Fixing the problems is preferable to retaining backwards compatibility. An implementation of this standard may recognise message IDs generated by RFC 987. This is not recommended. RFC 987 generated encodings may be recognised as follows. When mapping from X.400 to RFC 822, if the IPMS.IPMIdentifier.user- relative-identifier is "RFC-822" the id is RFC 987 generated. When mapping from RFC 822 to X.400, if the 822.domain is not "MHS", and the 822.local-part can be parsed as [ printablestring ] "*" [ std-or-address ] then it is RFC 987 generated. In each of these cases, it is recommended to follow the RFC 987 rules. Chapter 5 - Detailed Mappings This chapter specifies detailed mappings for the functions outlined in Chapters 1 and 2. It makes extensive use of the notations and mappings defined in Chapters 3 and 4. 5.1. RFC 822 -> X.400: Detailed Mappings The mapping of RFC 822/MIME messages to X.400 InterPersonal Messages is described in Sections 5.1.1 to 5.1.7. Mapping of NOTARY format delivery status notifications, which are all messages of type multipart/report and subtype delivery-status-notifications to X.400 delivery reports is covered in Section 5.1.8. 5.1.1. Basic Approach A single IP Message is generated from an RFC 822 message. The RFC 822 headers are used to generate the IPMS.Heading. Some RFC 822 fields cannot be mapped onto a standard IPM Heading field, and so an extended field is defined in Section 5.1.2. This is then used for fields which cannot be mapped onto existing services.
The message is submitted to the MTS, and the services required can be defined by specifying MTS.MessageSubmissionEnvelope. A few parameters of the MTA Abstract service are also specified, which are not in principle available to the MTS User. Use of these services allows RFC 822 MTA level parameters to be carried in the analogous X.400 service elements. The advantages of this mapping far outweigh the layering violation. 5.1.2. X.400 Extension Field An IPMS Extension is defined: 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 822 Header using this extension, an RFC822Field element is built using the 822.field omitting the trailing CRLF (e.g., "Fruit-Of-The-Day: Kiwi Fruit"). All fields shall be unfolded. There shall be no space before the ":". The reverse mapping builds the RFC 822 field in a straightforward manner. This RFC822Field is appended to the RFC822FieldList, which is added to the IPM Heading as an extension field. 5.1.3. Generating the IPM The IPM (IPMS Service Request) is generated according to the rules of this section. The IPMS.IPM.body is generated from the RFC 822 message body in the manner described in Section 5.1.5. If no specific 1988 features are used, the IPM generated is encoded as content type 2. Otherwise, it is encoded as content type 22. The latter will always be the case if extension heading fields are 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 822 comments and RFC 1522 encoding. Note:This approach removes a choice of options given in RFC 1327, based on operational experience. The rest of this section concerns IPMS.IPM.heading (IPMS.Heading). The only mandatory component of IPMS.Heading is the IPMS.Heading.this-IPM (IPMS.IPMIdentifier). A default is generated by the gateway. With the exception of "Received:", the values of multiple fields are merged (e.g., If there are two "To:" fields, then the mailboxes of both are merged to generate a single list which is used in the IPMS.Heading.primary-recipients. Information shall be generated from the standard RFC 822 Headers as follows: 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 822, 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 . 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 822 fields where the content of the field does not conform to RFC 822 (e.g., a Date: field with unparseable syntax). The mapping of the following headings is defined in RFC 2157. 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 2157. 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 2157. This type of conversion will prevent the normal loop detection from working in certain circumstances, and introduces the possiblity of gateway loops. MIXER gateways shall therefore count the number of MIXER conversions made. If this count exceeds five in one direction, the message shall be treated as if a loop has been detected. The MTS.PerMessageSubmissionFields.content-correlator is encoded as IA5String, and contains the Subject:, Message-ID:, Date:, and To: fields (if present) in this order. This includes the strings "Subject:", "Date:", "To:", "Message-ID:", and appropriate folding to make the field appear readable. This shall be truncated to MTS.ub- content-correlator-length (512) characters. In addition, if there is a "Subject:" field, the MTS.PerMessageSubmissionFields.content- identifier, is set to a printable string representation of the contents of it. If the length of this string is greater than MTS.ub-content-id-length (16), it shall be truncated to 13 characters and the string "..." appended. Both are used, due to the much larger upper bound of the content correlator, and that the content id is available in X.400(1984).
5.1.6. Mappings to the MTA Abstract Service There is a need to map directly onto some aspects of the MTA Abstract service, for the following reasons: - So the MTS Message Identifier can be generated from the RFC 822 Message-ID:. - So that the submission date can be generated from the 822.Date. - To prevent loss of trace information - To prevent RFC 822/X.400 looping caused by distribution lists or redirects The following mappings are defined. Message-Id: If this is present and no Resent: fields are present, the MTA.PerMessageTransferFields.message-identifier may be generated from it, using the mappings described in Chapter 4. This mapping arguably generates messages which do not conform to US GOSIP (1984 version only), which states: 6.7.e MPDU Identifier Validation (1) Validation of the GlobalDomainIdentifier component of the MPDU Identifier is performed on reception of a message (i.e. the result of a TRANSFER.Indication). (2) The country name should be known to the validating domain, and depending on the country name, validation of the ADMD name may also be possible. (3) Additional validation of the GlobalDomainIdentifier is performed against the corresponding first entry in the TraceInformation. If inconsistencies are found during the comparison, a non-delivery notice with the above defined reason and diagnostic code is generated. (4) A request will be generated to the CCITT for a more meaningful diagnostic code (such as "InconsistentMPUTIdentifier").
This applies to ADMDs only, and is specified in the 1984 version and not the 1988 version. Conformance depends on the interpretation of "inconsistency". The specification makes the most sensible choice, and so is not being changed in the update from RFC 1327. Date: (and Resent-Date:) If one or more Resent-Date: fields is present, the most recent Resent-Date: field shall be used instead of the Date: field in the 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 822 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 822 header (i.e., in chronological order). When other trace elements (in particular X400-Received:) are processed the relative ordering (top to bottom of the header) shall be retained correctly. The initial element of MTA.PerMessageTransferFields.trace- information shall be generated from Date: as described above, unless the message has previously been in X.400, when it will be derived from the X.400 trace information.
For each Received: field, the following processing shall be done. If the "by" part of the received is present and there is an available MCGAM which can map this domain, use it to derive an MTS.GlobalDomainIdentifier. Otherwise MTS.GlobalDomainIdentifier is set from local information. If this is different from the one in the last element of MTA.PerMessageTransferFields.trace- 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 188.8.131.52. 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. 184.108.40.206. 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). 220.127.116.11. 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 822 header. Trace is mapped in the same manner as for a message to MTA.ReportTransferEnvelope.trace-information. All other headers are used to create a dsn-header-list extension, which is added to MTA.PerReportTransferFields.extensions. The DSN will have a single SMTP recipient. This is mapped to the 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 18.104.22.168. 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. 22.214.171.124. 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 126.96.36.199. 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 offered two approaches for return of content, as this service is optional in X.400 and expected in RFC 822. MIXER simply requires that a gateway requests the return of content service from X.400. 5.3. X.400 -> RFC 822: Detailed Mappings 5.3.1. Basic Approach A single RFC 822 message is generated from the incoming IP Message, Report, or IP Notification. All IPMS.BodyParts are mapped onto a single RFC 822 body. Other services are mapped onto RFC 822 header fields. Where there is no appropriate existing field, new fields are defined for IPMS, MTS and MTA services. The gateway mechanisms will correspond to MTS Delivery. As with submission, there are aspects where the MTA (transfer) services are also used. In particular, there is an optimisation to allow for multiple SMTP recipients.