"UUCP") appropriate to the gateway should be selected, and its value set. 3. Build the rest of the O/R Name in the local Management Domain agreed manner, so that the O/R Name will receive a correct global interpretation. 4.2.4. X.400 -> RFC 822 There are two basic cases: 1. RFC 822 addresses encoded in X.400. 2. "Genuine" X.400 addresses. This may include symmetrically encoded RFC 822 addresses. When a P1 Recipient O/R Name is interpreted, gatewaying will be selected if there a single special domain defined attribute present ("RFC-822", "JNT-Mail" or "UUCP"). In this case, use mapping A. For other O/R Names which 1. Contain the special attribute. AND 2. Identify the local gateway with the other attributes. Use mapping A. In other cases, use mapping B. Mapping A 1. Map the domain defined attribute value to ASCII, as defined in chapter 3. 2. Where appropriate (P1 recipients), interpret the string according to the semantics implied by the domain defined attribute. Mapping B. This will be used for X.400 addresses which do not use the explicit RFC 822 encoding. 1. Noting the hierarchy specified in 4.3.1, determine the maximum set of attributes which have an associated domain specification. If no match is found, allocate
the domain as the domain specification of the local gateway, and go to step 4. 2. Following the 4.3.1 hierarchy, if each successive component exists, and conforms to the syntax EBNF.domain-syntax (as defined in 4.3.1), allocate the next subdomain. 3. If the remaining components are personal-name components, conforming to the restrictions of 4.2.2, then EBNF.encoded-pn should be derived to form 822.local-part. In other cases the remaining components should simply be encoded as a 822.local-part using the EBNF.std-orname syntax. Where registered domain defined types exist, the DD. syntax should not be used. 4. If this step is reached for an 822-P1 recipient, then the address is invalid. For other addresses, if the derived 822.local-part can only be encoded by use of 822.quoted-string, the gateway may optionally use the ASCII to 822.local-part mapping defined in Appendix A, dependent on the mail protocols of the networks being relayed to. Use of this encoding is discouraged. 4.3. Repeated Mappings The mappings defined are symmetrical across a single gateway, except in certain pathological cases (see chapter 3). However, it is always possible to specify any valid address across a gateway. This symmetry is particularly useful in cases of (mail exploder type) distribution list expansion. For example, an X.400 user sends to a list on an RFC 822 system which he belongs to. The received message will have the originator and any 3rd party X.400 O/R names 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. However, the syntax may be used to source route. For example: X.400 -> RFC 822 -> X.400 C = "UK" ADMD = "BT" PRMD = "AC" "JNT-Mail" = "/PN=Duval/DD.Title=Manager/(a)FR.PTT.Inria"
This will be sent to an arbitrary UK Academic Community gateway by X.400. Then by JNT Mail to another gateway determined by the domain FR.PTT.Inria. This will then derive the X.400 O/R Name: C = "FR" ADMD = "PTT" PRMD = "Inria" PN.S = "Duval" "Title" = "Manager" Similarly: RFC 822 -> X.400 -> RFC 822 "/C=UK/ADMD=BT/PRMD=AC/RFC-822=jj(a)seismo.css.gov/" @monet.berkeley.edu /C=UK/ADMD=BT/PRMD=AC/RFC-822=jj#l#a#r#seismo.css.gov/ @monet.berkeley.edu The second case uses the Appendix A encoding to avoid 822.quoted-text. This will be sent to monet.berkeley.edu by RFC 822, then to the AC PRMD by X.400, and then to firstname.lastname@example.org by RFC 822. 4.4. The full P1 / 822-P1 mapping There are two basic mappings at the P1 level: 1. 822-P1 return address <-> P1.UMPDUEnvelope.originator 2. 822-P1 recipient <-> P1.RecipientInfo 822-P1 recipients and return addresses are encoded as EBNF.822-address. As P1.UMPDUEnvelope.originator is encoded as P1.ORName, mapping 1) has already been specified. P1.RecipientInfo contains a P1.ORName and additional information. The handling of this additional information is now specified. 4.4.1. RFC 822 -> X.400 The following default settings should be made for each component of P1.RecipientInfo. P1.ExtensionIdentifier This can be set systematically by the X.400 system.
P1.RecipientInfo.perRecipientFlag Responsibility Flag should be set. Report Request should be set according to content return policy, as discussed in section 5.3. User Report Request should be set to Basic. P1.ExplicitConversion This optional component should be omitted. 4.4.2. X.400 -> RFC 822 The mapping only takes place in cases where P1.RecipientInfo.perRecipientFlag Responsibility Flag is set. The following treatment should be given to the other P1.RecipientInfo components. P1.ExtensionIdentifier Not used. P1.RecipientInfo.perRecipientFlag If ReportRequest is Confirmed or Audit-and-Confirmed then a delivery report indicating success should be sent by the gateway. This report should use each P1.ReportedRecipientInfo.SupplementaryInformation to indicate the identity of the gateway, and the nature of the report (i.e. only as far as the gateway). Failures will be handled by returning RFC 822 messages, and so User Report Request set to No report is ignored. P1.ExplicitConversion If present, the O/R name should be rejected, unless the requested conversion can be achieved. None of the currently recognised values of this parameter are appropriate to a gateway using this specification.
4.5. The full P2 / RFC 822 mapping All RFC 822 addresses are assumed to use the 822.mailbox syntax. This should include all 822.comments associated with the lexical tokens of the 822.mailbox. All P2.ORNames are encoded within the syntax P2.ORDescriptor, or P2.Recipient (or within Message IDs). An asymmetrical mapping is defined between these components. 4.5.1. RFC 822 -> X.400 The following sequence is followed. 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 P2.ORName as described above. 2. A string should be built consisting of (if present): - The 822.phrase component if it is a 822.phrase 822.route-addr construct. - Any 822.comments, in order, retaining the parentheses. This string should then be encoded into T.61 (as described in chapter 3). If the string is not null, it should be assigned to P2.ORDescriptor.freeformName. 3. P2.ORDescriptor.telephoneNumber should be omitted. 4. In cases of converting to P2.Recipient, P2.Recipient.replyRequest and P2.Recipient.reportRequest should be omitted. If the 822.group construct is present, each included 822.mailbox should be encoded as above. The 822.group should be mapped to T.61, and a P2.ORDesciptor with only a freeformName component built from it. 4.5.2. X.400 -> RFC 822 In the basic case, where P2.ORName is present, proceed as follows. 1. Encode P2.ORName as EBNF.822-address.
2a. If P2.ORDescriptor.freeformName is present, convert it to ASCII (chapter 3), and use use this as the 822.phrase component of 822.mailbox using the 822.phrase 822.route-addr construct. 2b. If P2.ORDescriptor.freeformName 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 P2.ORDescriptor.telephoneNumber is present, this should be placed in a trailing 822.comment. 4. If P2.Recipient.reportRequest has the receiptNotification bit set, then an 822.comment "(Receipt Notification 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. 5. If P2.Recipient.replyRequest is present, an 822.comment "(Reply requested)" or "(Reply not requested)" should be appended to the address, dependent on its value. If P2.ORName is absent, P2.ORDescriptor.freeformName should be converted to ASCII, and used with the RFC 822 822.group syntax: freeformname ":" ";" Steps 3-5 should then be followed. 4.6. Message IDs There is a need to map both ways between 822.msg-id and P2.IPMessageID. A mapping is defined which is symmetrical for non-pathological cases. The mapping allows for the fact that P2.IPMessageID.PrintableString is mandatory for the Cen/Cenelec profile. This allows for good things to happen when messages pass multiple times across the X.400/RFC 822 boundary. A mapping between 822.msg-id and P1.MPDUIdentifier is defined. This allows for X.400 error messages to reference an RFC 822 ID, which is preferable to a gateway generated ID.
4.6.1. P2.IPMessageID -> 822.msg-id P2.IPMessageID.ORName is used to generate an 822.addr-spec, as defined above. P2.IPMessageID.PrintableString is mapped to ASCII, as defined in chapter 3. This string (if it is present and if the value is not "RFC-822") is appended to the front of the 822.local-part of the 822.msg-id, with "*" as a separator. If no ORName is present, an 822.msg-id of the form "PrintableString*@gateway-domain" is generated. 4.6.2. 822.msg-id -> P2.IPMessageID 822.local-part is parsed as: [ printablestring "*" ] real-local-part If EBNF.printablestring is found, it is mapped to PrintableString, and used as P2.IPMessageID.PrintableString. Otherwise P2.IPMessageID.PrintableString is set to "RFC-822". This arbitrary value allows for conformance to Cen/Cenelec. If EBNF.real-local-part is not present, no P2.IPMessageID.ORName is generated. Otherwise, 822.local-part is replaced with EBNF.real-local-part, and 822.addr-spec is mapped to P2.IPMessageID.ORName as defined above. 4.6.3. 822.msg-id -> P1.MPDUIdentifier P1.CountryName is assigned to "", P1.AdministrationDomainName to 822.domain (from 822.msg-id) and P1.MPDUIdentifier.IA5String to 822.local-part (from 822.msg-id). 4.6.4. P1.MPDUIdentifier -> 822.msg-id 822.local-part is set to P1.MPDUIdentifier.IA5String, with any CRLF mapped to SPACE. If P1.CountryName is "", 822.domain is set to P1.AdministrationDomainName; Otherwise to P1.AdministrationDomainName ".." P1.CountryName. If there are any specials, the domain literal encoding should be used.
Chapter 5 -- Protocol Elements 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. This chapter is structured as follows: 5.1. Basic RFC 822 -> X.400 mappings 5.2. A definition of some new RFC 822 elements, and their mapping to X.400. 5.3 Some special handling associated with Return of Contents. 5.4. X.400 -> RFC 822 5.1. RFC 822 -> X.400 First, the basic functions of an 822-P1 protocol should be mapped as follows: 822-P1 Originator Mapped to P1.UMPDUEnvelope.originator (see chapter 4). 822-P1 Recipient Mapped to P1.RecipientInfo (see chapter 4). The RFC 822 headers are used to generate both a P1.UMPDUEnvelope and a P2.Heading. The IP Message will have either one or two P2.BodyParts which will be type P2.IA5Text with no P2.IA5Text.repertoire component. The last P2.BodyPart will contain the RFC 822 message body. If there are any RFC 822 headers which indicate mapping into the P2.BodyPart, then two P2.BodyParts are generated. If a revised version of P2 allowed for extensible header specification, this would be seen as a preferable mapping. The first body part will start with the line: RFC-822-Headers: The rest of this body part will contain all of the headers not otherwise mapped (both 822.field-name and 822.field-body). The order of any such headers should be preserved. Similarly, ordering within P2.Heading and P1.UMPDUEnvelope should reflect ordering within the RFC 822 header. No P1 or P2 optional fields are generated unless specified.
A pro-forma X.400 message is now specified. Some of these defaults may be changed by the values in the RFC 822 message being mapped. The mandatory P1 and P2 components have the following defaults. P1.MPDUIdentifier The default should be unique value generated by the gateway. P1.OriginatorORName Always generated from 822-P1. P1.ContentType P1.ContentType.p2 P1.RecipientInfo These will always be supplied from 822-P1. P1.Trace The last P1.TraceInformation component is generated such that: P1.TraceInformation.GlobalDomainIdentifier is set to the local vaglue. P1.DomainSuppliedInfo.action is set to relayed. P1.DomainSuppliedInfo.arrival is set to the current time. P1.DomainSuppliedInfo.previous may be set if there is anything sensible to set it to. P2.IPMessageID The default should be a unique value generated by the gateway. The following optional parameters should be set: P1.PerMessageFlag The P1.PerMessageFlag.contentReturnRequest bit should be set according to the discussion in section 5.3. The P1.PerMessageFlag.alternateRecipientAllowed bit should be set, as it seems desirable to maximise opportunity for (reliable) delivery.
The RFC 822 headings should be mapped as follows: Received: Fudged onto P1.TraceInformation (try not to grimace too much). P1.DomainSuppliedInfo.action is set to relayed. P1.DomainSuppliedInfo.arrival is set to the date-time component P1.TraceInformation.GlobalDomainIdentifier has P1.CountryName as a null string, and P1..AdministrationDomainName as the domain of the receiving host (if present - null string if not). P1.DomainSuppliedInfo.previous has P1.CountryName as a null string, and P1.AdministrationDomainName has the domain of the sending host with all other information enclosed in round parentheses. The encoding of ASCII to PrintableString (chapter 3) should be used if needed. For example: Received: from 44e.cs.ucl.ac.uk by vax2.Cs.Ucl.AC.UK with SMTP id a002110; 18 Dec 85 10:40 GMT maps to - P1.GlobalDomainIdentifier CountryName = "" AdministrationDomainName = "vax2.Cs.Ucl.AC.UK" P1.DomainSuppliedInfo arrival = 18 Dec 85 10:40 GMT action = relayed previous CountryName = "" AdministrationDomainName = "44e.cs.ucl.ac.uk (with SMTP id a002110)" Date: This is used to set the first component of P1.TraceInformation. The mandatory components are set as follows: P1.GlobalDomainIdentifier CountryName = "" AdministrationDomainName = "" P1.DomainSuppliedInfo arrival = time derived from Date: action = relayed No optional fields are used in the trace.
Message-Id: Mapped to P2.IPMessageID. If the RFC 822 message does not contain a P1-Message-ID: field, the Message-Id: field is also mapped to P1.MPDUIdentifier. For these, and all other fields containing msg-id the mappings of chapter 4 are used for each msg-id. From: If Sender: is present, this is mapped to P2.AuthorisingUsers. If not, it is mapped to P2.Originator. For this, and other components containing addresses, the mappings of chapter 4 are used for each address. Sender: Mapped to P2.Originator. Reply-To: Mapped to P2.Heading.replyToUsers. To: Mapped to P2.Heading.primaryRecipients Cc: Mapped to P2.Heading.copyRecipients. Bcc: Mapped to P2.Heading.blindCopyRecipients. In-Reply-To: Mapped to P2.Heading.inReplyTo for the first (if any) 822.msg-id component. If the field contains an 822.phrase component, or there are multiple 822.msg-id components, the ENTIRE field is passed in the P2.BodyPart. References: Mapped to P2.Heading.crossReferences.
Keywords: Passed in the P2.BodyPart. Subject: Mapped to P2.Heading.subject. The field-body uses the mapping referenced in chapter 3 from ASCII to T.61. Comments: Passed in the P2.BodyPart. Encrypted: Passed in the P2.BodyPart. Resent-* Passed in the P2..BodyPart <8>. Other Fields In particular X-* fields, and "illegal" fields in common usage (e.g. "Fruit-of-the-day:") are passed in the P2.BodyPart. The same treatment should be applied to RFC 822 fields where the content of the field does not conform to RFC 822 (e.g. a Date: field with unparsable syntax). 5.2. Extended RFC 822 Elements -> X.400 First an EBNF definition of a number of extended fields is given, and then a mapping to X.400 is defined. In most cases, the RFC 822 syntax is defined to make this mapping very straightforward, and so no detailed explanation of the mapping is needed. extended-field = "P1-Message-ID" ":" p1-msg-id / "X400-Trace" ":" x400-trace / "Original-Encoded-Information-Types" ":"encoded-info / "P1-Content-Type" ":" p1-content-type / "UA-Content-ID" ":" printablestring / "Priority" ":" priority / "P1-Recipient" : 1 mailbox / "Deferred-Delivery" ":" date-time
/ "Bilateral-Info" ":" bilateral-info / "Obsoletes" ":" 1 msg-id / "Expiry-Date" ":" date-time / "Reply-By" ":" date-time / "Importance" ":" importance / "Sensitivity" ":" sensitivity / "Autoforwarded" ":" boolean p1-msg-id = global-id ";" *text p1-content-type = "P2" / atom x400-trace = global-id ";" "arrival" date-time [ "deferred" date-time ] [ "action" action ] [ "converted" "(" encoded-info ")" ] [ "previous" global-id ] action = "Relayed" / "Rerouted" / escape global-id = c "*" admd [ "*" prmd ] encoded-info = 1 encoded-type encoded-type = "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) / escape priority = "normal" / "non-urgent" / "urgent" / escape bilateral-info = c "*" admd "*" *text importance = "low" / "normal" / "high" / escape sensitivity = "Personal" / "Private" / "Company-Confidential" / escape escape = 1*DIGIT
With the exception of "Bilateral-Info:" and "X400-Trace:", there must be no more than one of each of these fields in an RFC 822 header. Any field beginning with the String "Autoforwarded-" is valid if the field would be syntactically valid with this string removed. The mappings to X.400 are as follows: P1-Message-ID: Mapped to P1.UMPDUEnvelope.MPDUIdentifier. This take precedence over any value derived from Message-ID:. X400-Trace: Mapped to the next component of P1.UMPDUEnvelope.Traceinformation. Care should be taken to preserve order. If one or more of these mappings is made, then a trace component should NOT be generated from the Date: field which should be redundant. This is because the message has previously come from X.400, and the Date: information will be redundant. Note that all trace information (Received: and "X400-Trace:") in the RFC 822 message will be in strict order, with the most recent at the top. This order should be preserved in the mapping. Original-Encoded-Information-Types: This is used to set P1.UMPDUEnvelope.original. P1.EncodedInformationTypes. has bits set according to each of the encoded-info components in this field. Any escape values should not be encoded. P1-Content-Type: If the value is anything other than "P2", the mapping should not be performed (unless the new value has some semantics to the gateway). UA-Content-ID: Mapped to P1.UMPDUEnvelope.UAContentID. Priority: Mapped to P1.UMPDUEnvelope.Priority. An escape value should be encoded as P1.Priority.normal.
P1-Recipient: If this field is set, the P1.PerMessageFlag.discloseRecipients bit should be set. Any of the addresses here which do not correspond to 822-P1 recipients should be added to the P1 recipient list, with the responsibility bit turned off. Deferred-Delivery: Mapped to P1.UMPDUEnvelope.deferredDelivery. Note that the value of this field should always be in the past, as this field should only be present in messages which have come originally from X.400. Thus there should be no implied action. See also the comments on the reverse mapping. Bilateral-Info: No attempt is made to reconvert this information back to X.400. Obsoletes: Mapped to P2.Heading.obsoletes. Expiry-Date: Mapped to P2.Heading.expiryDate. Reply-By: Mapped to P2.Heading.replyBy. Importance: Mapped to P2.Heading.importance. An escape value should be encoded as P2.Heading.importance.normal. Sensitivity: Mapped to P2.Heading.sensitivity. An escape value should be encoded as P2.Heading.sensitivity.normal. Autoforwarded: If this field is present and the value is "TRUE", there will be zero or more field names beginning "Autoforwarded-".
These should be taken, and the string "Autoforwarded-" stripped. These fields, in conjunction with the 822-P1 information should be used to build an IP Message. Any implied actions should be taken. P2.Heading.autoforwarded is set in this message. The other RFC 822 fields are used to build another IP Message, which is used as the single body part of the first message. This mechanism does not nest. 5.3. Return of Contents It is not clear how widely supported X.400 return of contents service will be. However, profiling work suggests that most systems will not support this service. As this service is expected in the RFC 822 world, two approaches are specified (it is not so necessary in the X.400 world, as delivery reports are distinguished from messages). The choice will depend on the service level of the X.400 community being serviced by the gateway. In environments where return of contents is widely supported, the P1.PerMessageFlag content return request bit will be set, and the Report Request bit in P1.PerRecipientFlag will be set to Confirmed, for every message passing from RFC 822 -> X.400. The content return service can then be passed back to the end (RFC 822) user in a straightforward manner. In environments where return of contents is not widely supported, a gateway must make special provisions to handle return of contents. For every message passing from RFC 822 -> X.400, the P1.PerMessageFlag content return request bit will be set, and the Report Request bit in P1.PerRecipientFlag will be set to Confirmed. 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-P1 originator. If no report is received for a recipient, a (timeout) failure notice should be sent to the 822-P1 originator. The gateway may retransmit the X.400 message if it wishes. Delivery confirmations should only be sent back to the 822-P1 originator if the P1.PerRecipientFlag User Report Request bit is set to Confirmed.
5.4. X.400 -> RFC 822 5.4.1. General This section describes how to build a pro-forma message, and then explains how these defaults may be overridden. It should be noted that RFC 822 folding of headers should be used in an appropriate manner. 5.4.2. Service MPDU 126.96.36.199. Probe Any P1.ProbeMPDU should be serviced by the gateway, as there is no equivalent RFC 822 functionality. The value of the reply is dependent on whether the gateway could service a User MPDU with the values specified in the probe. The reply should make use of P1.SupplementaryInformation to indicate that the probe was serviced by the gateway. 188.8.131.52. Delivery Report The 822-P1 components are constructed as follows: 822-P1 Originator This is set to an 822.addr-spec pointing to an administrator at the gateway. 822-P1 Recipient The single recipient is constructed from P1.DeliveryReportEnvelope.originator, using the mappings of chapter 4. The mandatory RFC 822 headers for an RFC 822 pro-forma are constructed as follows: Date: From the P1.DomainSuppliedInfo.arrival component of the first P1.TraceInformation component. From: This is set to the same as the 822-P1 originator. An
appropriate phrase component may be added (e.g. giving the name of the gateway). To: The same as the 822-P1 recipient. A Subject: field should be added, which contains some appropriate words (e.g. "Delivery Report"). The other two P1.DeliveryReportEnvelope parameters should be mapped as follows: P1.DeliveryReportEnvelope.report This should be mapped to a P1-Message-Id: field. P1.DeliveryReportEnvelope.TraceInformation Each component should be mapped to an "X400-Trace:" field. RFC 822 and X.400 ordering should be maintained (see 5.3). The P1.DeliveryReportContent parameters should be mapped to a series of new RFC 822 headers. These new headers are intended for processing in the RFC 822 world. No attempt will be made to reverse the mappings. drc-field = "Delivery-Report-Content-Original" ":" msg-id / "Delivery-Report-Content-Intermediate-Trace" ":" x400-trace / "Delivery-Report-Content-UA-Content-ID" ":" printablestring / "Delivery-Report-Content-Billing-Information" ":" *text / "Delivery-Report-Content-Reported-Recipient-Info" ":" drc-info drc-info = mailbox ";" last-trace ";" "ext" 1*DIGIT "flags" 2DIGIT [ "intended" mailbox ] ";" [ "info" printablestring ]
last-trace = drc-report ";" date-time ";" [ "converted" "(" encoded-info ")" drc-report = "SUCCESS" drc-success / "FAILURE" drc-failure drc-success = date-time ";" 1*DIGIT drc-failure = *text [ ";" *text ] ";" There may be multiple "Delivery-Report-Content-Intermediate-Trace:" and "Delivery-Report-Content-Reported-Recipient-Info:" fields. The msg-id for "Delivery-Report-Content-Original" is derived according to the mapping of chapter 4. EBNF.drc-failure may use numeric values or textual explanation. The latter is preferred. All P1.DeliveryReportContent parameters are mapped to the corresponding component. The order of "Delivery-Report-Content-Intermediate-Trace:" should have the most recently stamped one first. The body of the RFC 822 message should be a human readable description of the critical parts of the P1.DeliveryReportContent. In particular, the failed recipients, and failure reason should be given. Some or all of the original message should be included in the delivery report. The original message will be available at the gateway, as discussed in section 5.3. 5.4.3. User MPDU These elements are the basis for both Status Report and IP Message. The 822-P1 components are constructed as follows: 822-P1 Originator This is derived from P1.UMPDUEnvelope.originator. 822-P1 Recipient Each recipient is constructed from the P1.RecipientInfo, as described in chapter 4. This describes actions as well as format mappings.
The mandatory RFC 822 field pro-forma is derived as follows. In most cases where the P1.UMPDUContent is an IP Message, these defaults will be overridden: Date: From the P1.DomainSuppliedInfo.arrival component of the first P1.TraceInformation component. From: From the P1.UMPDUEnvelope.originator, as defined in chapter 4. To: This default is only required if the generated RFC 822 message has no destination specification. If P1.PerMessageFlag.discloseRecipients is set then it should contain the ORName in each P1.RecipientInfo component. If it is not set, the it should be set to "To: No Recipients Specified : ;". The mappings, and any actions for each P1.UserMPDU element is now considered. P1.MPDUIdentifier Mapped to the extended RFC 822 field "P1-Message-ID:". Note that the sequence CRLF is mapped to SPACE, which makes the mapping irreversible for such cases. P1.UMPDUEnvelope.original Mapped to the extended RFC 822 field "Original-Encoded-Information-Types:". If it contains only P2.IA5Text, the RFC 822 field may be omitted. P1.ContentType As this can currently only have one value, it is not mapped, on the basis that it is redundant. If the field contains any value other than P2, then the UMPDU should be rejected.
P1.UAContentID Mapped to the extended RFC 822 field "UA-Content-Id:". P1.Priority Mapped to the extended RFC 822 field "Priority:". P1.PerMesageFlag This has a number of components: - discloseRecipients If this bit is set, a "P1-Recipient:" field should be generated, and contain each of the P1 recipients. - conversionProhibited If this bit is set, the message should be rejected if it contains P2.BodyPart which is not P2.IA5Text or P2.ForwardedIPMessage. - alternateRecipientAllowed The value of this bit is ignored. - contentReturnRequest The value of this bit is ignored. P1.UMPDUEnvelope.deferredDelivery This should be mapped to the extended RFC 822 field "Deferred-Delivery:". X.400 profiles, and in particular the CEN/CENELEC profile [CEN/CENELEC/85a], specify that this element must be supported at the first MTA. Thus, it is expected that the value of this element will always be in the past. 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 the extended RFC 822 field is just for information.
P1.PerDomainBilateralInformation Each component should be encoded in the extended RFC 822 field "Bilateral-Info:". P1.BilateralInfo should be mapped into ASCII in a manner appropriate to its contents. This submapping is not reversible. P1.TraceInformation This should be mapped to "X400-Trace:", as for the delivery report. 5.4.4. Status Report The entire status report is mapped into the body of the RFC 822 message, in the same manner as for a Delivery Report. An appropriate "Subject:" field should be generated. As status reports cannot be requested from the RFC 822 world, the mapping is not likely to be used a great deal. 5.4.5. IP Message The P1.UMPDUEnvelope pro-forma specification ensures all the 822-P1 information, and a minimal (legal) RFC 822 message. The mappings and actions for the P2.Heading components are now described. Basically, these are interpreted as actions and/or mappings into RFC 822 fields. The following mappings are specified: P2.IPMessageID This is mapped to the field "Message-ID:", according to section 4. P2.Heading.originator If P2.Heading.authorisingUsers is present this is mapped to Sender:, if not to From:. P2.Heading.authorisingUsers Mapped to From:. P2.Heading.primaryRecipients Mapped to To:.
P2.Heading.copyRecipients Mapped to Cc:. P2.Heading.blindCopyRecipients Mapped to Bcc:. P2.Heading.inReplyTo Mapped to In-Reply-To:. P2.Heading.obsoletes Mapped to the extended RFC 822 field "Obsoletes:" P2.Heading.crossReferences Mapped to References:. P2.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. line. P2.Heading.expiryDate Mapped to the extended RFC 822 field "Expiry-Date:". P2.Heading.replyBy Mapped to the extended RFC 822 field "Reply-By:". P2.Heading.replyToUsers Mapped to Reply-To:. P2.Heading.importance Mapped to the extended RFC 822 field "Importance:". P2.Heading.sensitivity Mapped to the extended RFC 822 field "Sensitivity:".
P2.Heading.autoforwarded If it is set to FALSE, it is simply mapped to the extended RFC 822 field "Autoforwarded:". If this is set to TRUE, the P2.Body does not consist of a single P2.ForwardedIPMessage, then there is an X.400 error, and the message should be bounced. Otherwise the following steps are taken. 1. The mappings for all of the message, except the body part are completed. 2. Prepend each RFC 822 fieldname with the string "Autoforwarded-". Mapped to the extended RFC 822 field "Autoforwarded:". 3. Add the field "Autoforwarded:" with value TRUE. 4. Convert the syntax of the P2.ForwardedIPMessage to generate the remaining RFC 822 fields. The P2.Body is mapped into the RFC 822 message body. Each P2.BodyPart is converted to ASCII. If the P2.Body contains a P2.BodyPart not listed here, the entire message should be rejected. If there are exactly two P2.IA5Text body parts, and the first line of the first is "RFC-822-Headers:", then the rest of this first body part should be treated as additional header information for the RFC 822 message. If there is an "In-Reply-To:" field, this should be used to replace any generated In-Reply-To: field. In other cases of multiple P2.BodyPart, the mapping defined by Rose and Stefferud in [Rose85b], should be used to separate the P2.BodyParts in the single RFC 822 message body. Individual body parts are mapped as follows: P2.IA5Text The mapping is trivial. P2.TTX If any P1.Teletex.NonBasicParams are set, the message should be rejected. Otherwise, it should be converted to ASCII according to chapter 3.
P2.SFD An SFD should be converted to ASCII as if it was being rendered on an 79 column ASCII only VDU. It seems likely that many gateways will not support this conversion. In these cases, the message should be rejected. P2.ForwardedIPMessage The P2.ForwardedIPMessage.delivery and P2.ForwardedIPMessage.DeliveryInformation are discarded <9>. The IM-UAPDU should have its syntax mapped (recursively) according to this gatewaying specification. Clearly, it makes no sense to apply any of the actions defined here.
Appendix A -- Quoted String Encodings This Appendix describes a quoting mechanism which may be used to allow general interworking between RFC 822, and variants of RFC 822 which do not support 822.quoted-string. This is important, as the basic X.400 <-> RFC 822 mapping makes use of 822.quoted-string. 1. ASCII <-> 822.atom The following EBNF is specified. atom-encoded = *( a-char / a-encoded-char ) a-char = <any CHAR except specials, SPACE, CTL, "_", and "#"> a-encoded-char = "_" ; (space) / "#u#" ; (_) / "#l#" ; <(> / "#r#" ; <)> / "#m#" ; (,) / "#c#" ; (:) / "#b#" ; (\) / "#h#" ; (#) / "#e#" ; ($=) / "#s#" ; ($/) / "#" 3DIGIT "#" NOTE: There are two encodings of double characters. This is so that systems using this encoding, do not also need to know about the "$" quoting mechanism defined in chapter 4. The 822.3DIGIT in EBNF.a-encoded-char must have range 0-127 (Decimal), and is interpreted in decimal as the corresponding ASCII character. The choice of special abbreviations (as opposed to octal encoding) provided is based on the manner in which this mapping is most frequently used: encoding PrintableString components of O/R names as atom. Therefore, there are special encodings for each of the PrintableString characters not in EBNF.a-char, except ".". Space is given a single character encoding, due to its (expected) frequency of use, and backslash as the RFC 822 single quote character. To encode (ASCII -> atom): all EBNF.a-char are used directly and all other CHAR are encoded as EBNF.a-encoded-char. To decode (822.atom -> ASCII): if 822.atom can be parsed as EBNF.encoded-atom reverse the previous mapping. If it cannot be so parsed, map the characters directly.
2. 822.local-part <-> ASCII A related transformation is for 822.local-part (or other element defined as '822.word ("." 822.word)') where not 822.quoted-text is used. To encode (ASCII -> 822.local-part), all EBNF.a-char and "." are used directly and all other 822.CHAR are encoded as EBNF.a-encoded-char. To decode (822.local-part -> ASCII), first attempt to parse 822.local-part as '822.atom *("." 822.atom)'. If this fails, or if each 822.atom cannot be parsed as EBNF.atom-encoded then map each character directly. Otherwise map each "." directly, and each atom as in the previous section. There are places where it is needed to convert between PrintableString or IA5Text (X.400), and 822.word (RFC 822). word may be encoded as 822.atom (which has a restricted character set) or as 822.quoted-string, which can handle all ASCII characters. If 822.quoted-string is used, clearly the mappings for PrintableString defined in Chapter 3 provide a straightforward mapping. However, some RFC 822 based networks cannot handle the 822.quoted-string format in all cases. This Appendix is for use in these cases. The major requirement for this mapping is the UNIX world, but it may well be needed in other places. These mappings are somewhat artificial, and their usage is discouraged, except in cases where there is no alternative.
Appendix B -- Mappings Specific to JNT Mail This Appendix is specific to the JNT Mail Protocol. It describes specific changes in the context of this protocol. Addressing is not discussed here, as it is covered in Appendix A. 1. Introduction There are four aspects of a gateway which are JNT Mail Specific, in addition to those relating to addressing. These are each given a section of this appendix. 2. Acknowledge-To: This field has no direct functional equivalent in X.400. However, it can be supported to an extent, and can be used to improve X.400 support. When going from JNT Mail to X.400, the User Report Request bits of each P1.RecipientInfo.perRecipientFlag should be set to confirmed. If there is more that one address in the Acknowledge-To: field, or if the one address is not equivalent to the 822-P1 return address, then: a. Acknowledgement(s) should be generated by the gateway. The text of these acknowledgements should indicate that they are generated by the gateway. b. The Acknowledge-To: field should also be passed in the first P2.BodyPart. When going from X.400 to JNT Mail, in cases where P1.RecipientInfo.perRecipientFlag has the user bits set to confirmed the copy of the message to that recipient should have an Acknowledge-To: field containing the P.UMPDUEnvelope.originator. No attempt should be made to map Receipt notification requests onto Acknowledge-To:. This is because no association can be guaranteed between P2 and P1 level addressing information. 3. Trace JNT Mail trace uses the Via: syntax. When going from JNT Mail to X.400, the following mapping onto P1.TraceInformation is used. P1.DomainSuppliedInfo.action is set to relayed. P1.DomainSuppliedInfo.arrival is set to the date-time component
of the Via: field. P1.DomainSuppliedInfo.previous has P1.CountryName as a null string, and P1.AdministrationDomainName as the domain specified in the Via: field. P1.TraceInformation.GlobalDomainIdentifier has P1.CountryName as a null string, and P1.AdministrationDomainName as any commented information in the Via: field. For example: Via: UK.AC.Edinburgh ; 17 Jun 85 9:15:29 BST (EMAS V7) maps to - P1.GlobalDomainIdentifier CountryName = "" AdministrationDomainName = "(EMAS V7)" P1.DomainSuppliedInfo arrival = 17 Jun 85 9:15:29 BST action = relayed previous CountryName = "" AdministrationDomainName = "UK.AC.Edinburgh" 4. Timezone specification The extended syntax of zone defined in the JNT Mail Protocol should be used in the mapping of UTCTime defined in chapter 3. 5. Lack of separate 822-P1 originator specification In JNT Mail the default mapping of the P1.MPDUEnvelope.originator is to the Sender: field. This can cause a problem if the mapping of P2.Heading has already generated a Sender: field. To overcome this, new extended JNT Mail field is defined. This is chosen to align with the JNT recommendation for interworking with full RFC 822 systems [Kille84b]. original-sender = "Original-Sender" ":" mailbox If an IPM has no P2.heading.authorisingUsers component and P2.Heading.originator.ORName is different from P1.UMPDUEnvelope.originator, map P1.MPDUEnvelope.originator onto the Sender: field. If an IPM has a P2.heading.authorisingUsers component, and P2.Heading.originator.ORName is different from P1.UMPDUEnvelope.originator, P1.MPDUEnvelpoe.originator should be
mapped onto the Sender: field, and P2.Heading.originator mapped onto the Original-Sender: field. In other cases the P1.MPDUEnvelope.Originator is already correctly represented. Note that in some pathological cases, this mapping is asymmetrical.
Appendix C -- Mappings Specific to Internet Mail The Simple Mail Transfer Protocol [Postel82a] is used in the ARPA-Internet, and in any network following the US DoD standards for internetwork protocols. This appendix is specific to those hosts which use SMTP to exchange mail. 1. Mapping between O/R names and SMTP addresses The mappings of Chapter 4 are to be used. 2. Use of the ARPA Domain System Whenever possible, domain-qualified addresses should be be used to specify encoded O/R names. These domain encodings naturally should be independent of any routing information. 3. Identification of gateways The ARPA-Internet Network Information Center (NIC) will maintain a list of registered X.400 gateways in the ARPA Internet.
Appendix D -- Mappings Specific to Phonenet Mail There are currently no mappings specific to Phonenet Mail.
Appendix E -- Mappings Specific to UUCP Mail Gatewaying of UUCP and X.400 is handled by first gatewaying the UUCP address into RFC 822 syntax (using RFC 976) [Horton86a] and then gatewaying the resulting RFC 822 address into X.400. For example, an X.400 address Country US Organization Xerox Personal Name John Smith might be expressed from UUCP as inthop!gate!gatehost.COM!/C=US/O=Xerox/PN=John.Smith/ (assuming gate is a UUCP-ARPA gateway and gatehost.COM is an ARPA-X.400 gateway) or inthop!gate!Xerox.COM!John.Smith (assuming that Xerox.COM and /C=US/O=Xerox/ are equivalent.) In the other direction, a UUCP address Smith@ATT.COM, integrated into 822, would be handled as any other 822 address. A non-integrated address such as inthop!dest!user might be handled thought a pair of gateways: Country US ADMD ATT PRMD ARPA Organization GateOrg RFC-822 inthop!dest!user@gatehost.COM or through a single X.400 to UUCP gateway: Country US ADMD ATT PRMD UUCP Organization GateOrg UUCP inthop!dest!user
Appendix F -- Format of Address Mapping Tables There is a need to specify the association between the domain and X.400 namespaces described in 4.2.1. This is defined as a table syntax, but the syntax is defined in a manner which makes it suitable for use with domain nameservers (such as the DARPA Domain nameservers or the UK NRS). The symmetry of the mapping is not clear, so a separate table is specified for each direction. For domain -> X.400: domain-syntax "#" dmn-orname "#" For example: AC.UK#PRMD$DES.ADMD$BT.C$UK# XEROX.COM#O$Xerox.ADMD$ATT.C$US# For X.400 -> domain: dmn-orname "#" domain-syntax "#" EBNF.domain-syntax will be interpreted according to RFC 920. EBNF.dmn-orname will have components ordered as defined in section 4.2.1, and with the most significant component on the RHS.
References Bonacker85a. K.H. Bonacker, U. Pankoke-Babatz, and H. Santo, "EAN - Conformity to X.400 and DFN-Pflichtenheft," GMD (Gesellschaft fur Mathematik und Datenverarbeitung) report, June 1985. CCITT84a. CCITT SG 5/VII, "Recommendations X.400," Message Handling Systems: System Model - Service Elements, October 1984. CCITT84b. CCITT SG 5/VII, "Recommendations X.411," Message Handling Systems: Message Transfer Layer, October 1984. CCITT84c. CCITT SG 5/VII, "Recommendations X.420," Message Handling Systems: Interpersonal Messaging User Agent Layer, October 1984. CCITT84d. CCITT SG 5/VII, "Recommendations X.409," Message Handling Systems: Presentation Transfer Syntax and Notation, October 1984. CEN/CENELEC/85a. CEN/CENELEC/Information Technology/Working Group on Private Message Handling Systems, "FUNCTIONAL STANDARD A/3222," CEN/CLC/IT/WG/PMHS N 17, October 1985. Crocker82a. D.H. Crocker, "Standard of the Format of ARPA Internet Text Messages," RFC 822, August 1982. Horton85a. M.R. Horton, "Draft Standard for ARPA/MHS Addressing Gateways," AT&T Bell Laboratories, October 1985.
Horton86a. M.R. Horton, "UUCP Mail Interchange Format Standard", RFC 976, February 1986. ICL84a. ICL, "Comparison of service elements of Grey Book Mail and X.400," Mailgroup Note 18: Extract from unpublished report for ITSU (Information Technology Standards Unit), July 1984. Kille84a. S.E. Kille, (editor), JNT Mail Protocol (revision 1.0), Joint Network Team, Rutherford Appleton Laboratory, March 1984. Kille84b. S.E. Kille, "Gatewaying between RFC 822 and JNT Mail," JNT Mailgroup Note 15, May 1984. Kille86a. S.E. Kille, "O/R Names in the UK Academic Community," UK Working Document, March 1986. Larmouth83a. J. Larmouth, "JNT Name Registration Technical Guide," Salford University Computer Centre, April 1983. Neufeld85a. G. Neufeld, J. Demco, B. Hilpert, and R. Sample, "EAN: an X.400 message system," in Second International Symposium on Computer Message Systems, Washington, pp. 1-13, North Holland, September 1985. Postel82a. J. Postel, "Simple Mail Transfer Protocol," RFC 821, August 1982. Postel84a. J. Postel and J. Reynolds, "Domain Requirements," RFC 920, October 1984.
Rose85a. M.T. Rose, "Mapping Service Elements between ARPA and MHS," Draft proposal, October 1985. Rose85b. M.T. Rose and E.A. Stefferud, "Proposed Standard for Message Encapsulation," RFC 934, January 1985.
Notes: <0> UNIX is a trademark of Bell Laboratories. <1> The term gateway is used to describe a component performing the protocol mappings between RFC 822 and X.400. This is standard usage amongst mail implementors, but should be noted carefully by transport and network service implementors. (Sometime called a "mail relay".) <2> If the remote protocol is JNT Mail, a notification may also be sent by the recipient UA. <3> The asymmetry occurs where an ASCII string contains the sequence EBNF.ps-encoded-char. This would be mapped directly to PrintableString, but the reverse mapping would be to the value implied by the sequence. <4> It might be suggested that for reasons of elegance, EBNF.ps-delim (left parenthesis) is encoded as EBNF.ps-encoded-char. This is not done, as it it would never be possible to represent a PrintableString containing the character "(" in ASCII. This is because an "(" in ASCII would be mapped to the encoding in PrintableString. <5> In practice, a gateway will need to parse various illegal variants on 822.date-time. In cases where 822.date-time cannot be parsed, it is recommended that the derived UTCTime is set to the value at the time of translation. <6> P2.ORname is defined as P1.ORName. <7> This recommendation may change in the light of CCITT or CEN/CENELEC guidelines on the use of initials. <8> 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. <9> Although this violates chapter 1, part 4, principles 2 and 3, it is suggested that this is justified by principle 1.