brian@sdcsvax.UCSD.EDU (Brian Kantor) (11/16/87)
RFC 987 June 1986
Mapping between X.400 and RFC 822
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
Kille [Page 43]
RFC 987 June 1986
Mapping between X.400 and RFC 822
/ "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
Kille [Page 44]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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.[0] 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.
Kille [Page 45]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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-".
Kille [Page 46]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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.
Kille [Page 47]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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
5.4.2.1. 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.
5.4.2.2. 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
Kille [Page 48]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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 ]
Kille [Page 49]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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.
Kille [Page 50]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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.
Kille [Page 51]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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.
Kille [Page 52]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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:.
Kille [Page 53]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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:".
Kille [Page 54]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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.
Kille [Page 55]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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.
Kille [Page 56]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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.
Kille [Page 57]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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.
Kille [Page 58]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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
Kille [Page 59]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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
Kille [Page 60]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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.
Kille [Page 61]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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.
Kille [Page 62]
RFC 987 June 1986
Mapping between X.400 and RFC 822
Appendix D -- Mappings Specific to Phonenet Mail
There are currently no mappings specific to Phonenet Mail.
Kille [Page 63]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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
Kille [Page 64]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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.
Kille [Page 65]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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.
Kille [Page 66]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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.
Kille [Page 67]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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.
Kille [Page 68]
RFC 987 June 1986
Mapping between X.400 and RFC 822
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.
Kille [Page 69]