brian@sdcsvax.UCSD.EDU (Brian Kantor) (11/16/87)
UCL Technical Report 120
Mailgroup Note 19
Network Working Group S.E. Kille
Request for Comments: 987 University College London
June 1986
Mapping between X.400 and RFC 822
Status of This Memo
This RFC suggests a proposed protocol for the ARPA-Internet
community, and requests discussion and suggestions for improvements.
Distribution of this memo is unlimited.
This document describes a set of mappings which will enable
interworking between systems operating the CCITT X.400 (1984) series
of protocols [CCITT84a], and systems using the RFC 822 mail protocol
[Crocker82a], or protocols derived from RFC 822. The approach aims
to maximise the services offered across the boundary, whilst not
requiring unduly complex mappings. The mappings should not require
any changes to end systems.
This specification should be used when this mapping is performed on
the ARPA-Internet or in the UK Academic Community. This
specification may be modified in the light of implementation
experience, but no substantial changes are expected.
Kille [Page 1]
RFC 987 June 1986
Mapping between X.400 and RFC 822
Chapter 1 -- Overview
1.1. X.400
The X.400 series protocols have been defined by CCITT to provide
an Interpersonal Messaging Service (IPMS), making use of a store
and forward Message Transfer Service. It is expected that this
standard will be implemented very widely. As well as the base
standard (X.400), work is underway on various functional standards
of profiles which specify how X.400 will be used in various
communities. Many of the major functional standards (e.g. from
CEPT, CEN/CENELEC, and NBS) are likely to be similar. Some of the
decisions in this document are in the light of this work. No
reference is given, as these documents are not currently stable.
1.2. RFC 822
RFC 822 evolved as a messaging standard on the DARPA (the US
Defense Advanced Research Projects Agency) Internet. It is
currently used on the ARPA-Internet in conjunction with two other
standards: RFC 821, also known as Simple Mail Transfer Protocol
(SMTP) [Postel82a], and RFC 920 which is a specification for a
domain name system and a distributed name service [Postel84a].
RFC 822, or protocols derived from RFC 822 are used in a number of
other networks. In particular:
UUCP Networks
UUCP is the UNIX to UNIX CoPy protocol <0>, which is usually
used over dialup telephone networks to provide a simple
message transfer mechanism. There are some extensions to
RFC 822, particularly in the addressing. They are likely to
use domains which conform to RFC 920, but not the
corresponding domain nameservers [Horton86a].
CSNET
Some portions of CSNET will follow the ARPA-Internet
protocols. The dialup portion of CSNET uses the Phonenet
protocols as a replacement for RFC 821. This portion is
likely to use domains which conform to RFC 920, but not the
corresponding domain nameservers.
BITNET
Some parts of BITNET use RFC 822 related protocols, with
EBCDIC encoding.
Kille [Page 2]
RFC 987 June 1986
Mapping between X.400 and RFC 822
JNT Mail Networks
A number of X.25 networks, particularly those associated
with the UK Academic Community, use the JNT (Joint Network
Team) Mail Protocol, also known as Greybook [Kille84a].
This is used with domains and name service specified by the
JNT NRS (Name Registration Scheme) [Larmouth83a].
The mappings specified here are appropriate for all of these
networks.
1.3. The Need for Conversion
There is a large community using RFC 822 based protocols for mail
services, who will wish to communicate with X.400 systems. This
will be a requirement, even in cases where communities intend to
make a transition to use of X.400, where conversion will be needed
to ensure a smooth service transition. It is expected that there
will be more than one gateway <1>, and this specification will
enable them to behave in a consistent manner. These gateways are
sometimes called mail relays. Consistency between gateways is
desirable to provide:
1. Consistent service to users.
2. The best service in cases where a message passes through
multiple gateways.
1.4. General Approach
There are a number of basic principles underlying the details of
the specification.
1. The specification should be pragmatic. There should not
be a requirement for complex mappings for 'Academic'
reasons. Complex mappings should not be required to
support trivial additional functionality.
2. Subject to 1), functionality across a gateway should be as
high as possible.
3. It is always a bad idea to lose information as a result of
any transformation. Hence, it is a bad idea for a gateway
to discard information in the objects it processes. This
includes requested services which cannot be fully mapped.
4. All mail gateways actually operate at exactly one level
Kille [Page 3]
RFC 987 June 1986
Mapping between X.400 and RFC 822
above the layer on which they conceptually operate. This
implies that the gateway must not only be cognisant of the
semantics of objects at the gateway level, but also be
cognisant of higher level semantics. If meaningful
transformation of the objects that the gateway operates on
is to occur, then the gateway needs to understand more
than the objects themselves.
1.5. Gatewaying Model
1.5.1. X.400
The CCITT X.400 series recommendations specify a number of
services and protocols. The services are specified in X.400.
Two of these services are fundamental to this document:
1. The Message Transfer Service, which can be provided by
either the P1 or P3 protocols, which are specified in
X.411 [CCITT84b]. This document talks in terms of P1,
but the mappings are equally applicable to P3.
2. The Interpersonal Messaging Service (IPMS), which is
provided by the P2 protocol specified in X.420
[CCITT84c].
This document considers only IPMS, and not of any other usage
of the Message Transfer Service. This is reasonable, as
RFC 822, broadly speaking, provides a service corresponding to
IPMS, and no services other than IPMS have been defined over
the Message Transfer Service. As none of the RTS (Reliable
Transfer Service) service elements is available to the IPMS
user, this level and lower levels are of no concern in this
gatewaying specification. Note that in this memo "IP" means
"InterPersonal" (not Internet Protocol).
The Message Transfer Service defines an end-to-end service over
a series of Message Transfer Agents (MTA). It also defines a
protocol, P1, which is used between a pair of MTAs. This
protocol is simply a file format (Message Protocol Data Unit,
or MPDU), transferred between two MTAs using the RTS. There
are three types of MPDU:
User MPDU
This contains envelope information, and uninterpreted
contents. The envelope includes an ID, an originator, a
Kille [Page 4]
RFC 987 June 1986
Mapping between X.400 and RFC 822
list of recipients, and trace information. It is used to
carry data for higher level services.
Probe
This contains only envelope information. It is used to
determine whether a User UMPDU could be delivered to a
given O/R (originator/recipient) name.
Delivery Report
This contains envelope information, and specified
contents. It is used to indicate delivery success or
failure of a User or Probe MPDU over the Message Transfer
Service.
IPMS (P2) specifies two content types for the P1 User MPDU
(User Agent Protocol Data Units or UAPDU):
Interpersonal Message (IM-UAPDU)
This has two components: a heading, and a body. The body
is structured as a sequence of body parts, which may be
basic components (e.g.IA5 text, or G3 fax), or IP
Messages. The header contains end to end user
information, such as subject, primary recipients (To:),
and priority. The validity of these fields is not
guaranteed by the Message Transfer Service. This
provides the basic IPMS.
Status Report (SR-UAPDU)
This UAPDU has defined contents. It is used to indicate
that a message has been received by a User Agent. It
does not have to be implemented.
1.5.2. RFC 822
RFC 822 is based on the assumption that there is an underlying
service, which is here called the 822-P1 service. The 822-P1
service provides three basic functions:
1. Identification of a list of recipients.
2. Identification of an error return address.
3. Transfer of an RFC 822 message.
Kille [Page 5]
RFC 987 June 1986
Mapping between X.400 and RFC 822
It is possible to achieve 2) within the RFC 822 header. Some
822-P1 protocols, in particular SMTP, can provide additional
functionality, but as these are neither mandatory in SMTP, nor
available in other 822-P1 protocols, they are not considered
here. Details of aspects specific to a number of 822-P1
protocols are given in appendices B to E. An RFC 822 message
consists of a header, and content which is uninterpreted ASCII
text. The header is divided into fields, which are the
protocol elements. Most of these fields are analogous to P2
header elements, although some are analogous to P1 envelope
elements.
1.5.3. The Gateway
Given this functional description of the two protocols, the
functional nature of a gateway can now be considered. It would
be elegant to consider the 822-P1 service mapping onto P1 and
RFC 822 mapping onto P2, but reality just does not fit.
Therefore one must consider that P1 or P1 + P2 on one side are
mapped into RFC 822 + 822-P1 on the other in a slightly tangled
manner. The details of the tangle will be made clear in
chapter 5. The following basic mappings are thus proposed.
When going from RFC 822 to X.400, an RFC 822 message and the
associated 822-P1 information is always mapped into an IM-UAPDU
and the associated P1 envelope. Going from X.400 to RFC 822,
an RFC 822 message and the associated 822-P1 information may be
derived from:
1. A Delivery Report MPDU
2. An SR-UAPDU and the associated P1 envelope.
3. An IM-UAPDU and the associated P1 envelope.
Probe MPDUs must be processed by the gateway - this is
discussed in chapter 5. Any other User MPDUs are not mapped by
the gateway, and should be rejected at the gateway.
Kille [Page 6]
RFC 987 June 1986
Mapping between X.400 and RFC 822
1.6. Document Structure
This document has five chapters:
1. Overview - this document.
2. Service Elements - This describes the (end user) services
mapped by a gateway.
3. Basic mappings - This describes some basic notation used
in chapters 3-5, the mappings between character sets, and
some fundamental protocol elements.
4. Addressing - This considers the mapping between X.400 O/R
names and RFC 822 addresses, which is a fundamental
gateway component.
5. Protocol Elements - This describes the details of all
other mappings.
There are also six appendices:
A. Quoted String Encodings.
B. Mappings Specific to JNT Mail.
C. Mappings Specific to Internet Mail.
D. Mappings Specific to Phonenet Mail.
E. Mappings Specific to UUCP Mail.
F. Format of Address Tables.
1.7. Acknowledgements
This document is eclectic, and credit should be given:
- Study of the EAN X.400 system code which performs this
function [Neufeld85a]. Some detailed clarification was
made by the DFN report on EAN [Bonacker85a].
- An unpublished ICL report, which considered a subset of
the problem [ICL84a].
- A document by Marshall Rose [Rose85a].
Kille [Page 7]
RFC 987 June 1986
Mapping between X.400 and RFC 822
- A document by Mark Horton [Horton85a]. The string
encodings of chapter 3 were derived directly from this
work, as is much of chapter 4.
- Discussion on a number of electronic mailing lists.
- Meetings in the UK and the US.
Kille [Page 8]
RFC 987 June 1986
Mapping between X.400 and RFC 822
Chapter 2 -- Service Elements
RFC 822 and X.400 provide a number of services to the end user. This
document describes the extent to which each service can be supported
across an X.400 <-> RFC 822 gateway. The cases considered are single
transfers across such a gateway, although the problems of multiple
crossings are noted where appropriate.
When a service element is described as supported, this means that
when this service element is specified by a message originator for a
recipient behind a gateway, that it is mapped by the gateway to
provide the service implied by the element. For example, if an
RFC 822 originator specifies a Subject: field, this is considered to
be supported, as an X.400 recipient will get a subject indication.
Support implies:
- Semantic correspondence.
- No loss of information.
- Any actions required by the service element.
For some services, the corresponding protocol elements map well, and
so the service can be fully provided. In other cases, the service
cannot be provided, as there is a complete mismatch. In the
remaining cases, the service can be partially fulfilled. The level
of partial support is summarised.
NOTE: It should be clear that support of service elements on
reception is not a gatewaying issue. It is assumed that all
outbound messages are fully conforming to the appropriate
standards.
2.1. RFC 822
RFC 822 does not explicitly define service elements, as distinct
from protocol elements. However, all of the RFC 822 header
fields, with the exception of trace, can be regarded as
corresponding to implicit RFC 822 service elements. A mechanism
of mapping used in several cases, is to place the text of the
header into the body of the IP Message. This can usually be
regarded as partial support, as it allows the information to be
conveyed to the end user even though there is no corresponding
X.400 protocol element. Support for the various service elements
(headers) is now listed.
Kille [Page 9]
RFC 987 June 1986
Mapping between X.400 and RFC 822
Date:
Supported.
From:
Supported. For messages where there is also a sender field,
the mapping is to "Authorising Addresses", which has subtly
different semantics to the general RFC 822 usage of From:.
Sender:
Supported.
Reply-To:
Supported.
To:
Supported.
Cc:
Supported.
Bcc:
Supported.
Message-Id:
Supported.
In-Reply-To:
Supported, for a single reference in msg-id form. Other
cases are passed in the message text.
References:
Supported.
Keywords:
Passed in the message text.
Kille [Page 10]
RFC 987 June 1986
Mapping between X.400 and RFC 822
Subject:
Supported.
Comments:
Passed in the message text.
Encrypted:
Passed in the message text. This may not be very useful.
Resent-*
Passed in the message text. In principle, these could be
supported in a fuller manner, but this is not suggested.
Other Fields
In particular X-* fields, and "illegal" fields in common
usage (e.g. "Fruit-of-the-day:") are passed in the message
text.
2.2. X.400
When mapping from X.400 to RFC 822, it is not proposed to map any
elements into the body of an RFC 822 message. Rather, new RFC 822
headers are defined. It is intended that these fields will be
registered, and that co-operating RFC 822 systems may use them.
Where these new fields are used, and no system action is implied,
the service can be regarded as being almost supported. Chapter 5
describes how to map these new headers in both directions. Other
elements are provided, in part, by the gateway as they cannot be
provided by RFC 822. Some service elements are are marked N/A
(not applicable). These elements are only applicable to User
Agent / Message Transfer Agent interaction and have no end-to-end
implication. These elements do not need to be mapped by the
gateway.
2.2.1. Message Transfer Service Elements
Access Management
N/A.
Kille [Page 11]
RFC 987 June 1986
Mapping between X.400 and RFC 822
Content Type Indication
Not mapped. As it can only have one value (P2), there is
little use in creating a new RFC 822 header field, unless it
was to distinguish delivery reports.
Converted Indication
Supported by a new RFC 822 header.
Delivery Time Stamp Indication
N/A.
Message Identification
Supported, by use of a new RFC 822 header. This new header
is required, as X.400 has two message-ids whereas RFC 822
has only one.
Non-delivery Notification
Not supported, although in general an RFC 822 system will
return errors as IP messages. In other elements, this
pragmatic result is treated as effective support of this
service element.
Original Encoded Information Types Indication
Supported as a new RFC 822 header.
Registered Encoded Information Types
N/A.
Submission Time Stamp Indication
Supported.
Alternate Recipient Allowed
Not supported. Any value is ignored by the gateway.
Deferred Delivery
Support is optional. The framework is provided so that
messages may be held at the gateway. However, a gateway
Kille [Page 12]
RFC 987 June 1986
Mapping between X.400 and RFC 822
following this specification does not have to do this. This
is in line with the emerging functional standards.
Deferred Delivery Cancellation
Supported.
Delivery Notification
Supported at gateway. Thus, a notification is sent by the
gateway to the originator <2>.
Disclosure of Other Recipients
Supported by use of a new RFC 822 header.
Grade of Delivery Selection
Supported as a new RFC 822 header. In general, this will
only be for user information in the RFC 822 world.
Multi-Destination Delivery
Supported.
Prevention of Non-delivery Notification
Not Supported, as there is no control in the RFC 822 world
(but see Non-delivery Notification).
Return of Contents
This is normally the case, although the user has no control
(but see Non-delivery Notification).
Conversion Prohibition
Supported. Note that in practice this support is restricted
by the nature of the gateway.
Explicit Conversion
Supported, for appropriate values (See the IPMS Typed Body
service element).
Kille [Page 13]
RFC 987 June 1986
Mapping between X.400 and RFC 822
Implicit Conversion
Supported, in the sense that there will be implicit
conversion to IA5 in cases where this is practical.
Probe
Supported at the gateway (i.e. the gateway services the
probe).
Alternate Recipient Assignment
N/A.
Hold for Delivery
N/A.
2.2.2. Interpersonal Message Service Elements
IP-message Identification
Supported.
Typed Body
Supported. IA5 is fully supported. ForwardedIPMessage is
supported, with some loss of information. A subset of TTX
is supported (see section 5 for the specification of this
subset), with some loss of information. SFD may be
supported, with some loss of information. TTX and SFD are
only supported when conversion is allowed. Other types are
not supported.
Blind Copy Recipient Indication
Supported.
Non-receipt Notification
Not supported.
Receipt Notification
Not supported.
Kille [Page 14]
RFC 987 June 1986
Mapping between X.400 and RFC 822
Auto-forwarded Indication
Supported as new RFC 822 header.
Originator Indication
Supported.
Authorising User's Indication
Supported, although the mapping (From:) is not quite the
same.
Primary and Copy Recipients Indication
Supported.
Expiry Date Indication
Supported as new RFC 822 header. In general, only human
action can be expected.
Cross Referencing Indication
Supported.
Importance Indication
Supported as new RFC 822 header.
Obsoleting Indication
Supported as new RFC 822 header.
Sensitivity Indication
Supported as new RFC 822 header.
Subject Indication
Supported.
Reply Request Indication
Supported as comment next to address.
Kille [Page 15]
RFC 987 June 1986
Mapping between X.400 and RFC 822
Forwarded IP-message Indication
Supported, with some loss of information.
Body Part Encryption Indication
Not supported.
Multi-part Body
Supported, with some loss of information, in that the
structuring cannot be formalised in RFC 822.
Kille [Page 16]
RFC 987 June 1986
Mapping between X.400 and RFC 822
Chapter 3 -- Basic Mappings
3.1. Notation
The P1 and P2 protocols are encoded in a structured manner
according to the X.409 specifications, whereas RFC 822 is text
encoded. To define a detailed mapping, it is necessary to refer
to detailed protocol elements in each format. This is described.
3.1.4. RFC 822
Structured text is defined according to the Extended Backus
Naur Form (EBNF) defined in section 2 of RFC 822 [Crocker82a].
In the EBNF definitions used in this specification, the syntax
rules given in Appendix D of RFC 822 are assumed. When these
EBNF tokens are referred to outside an EBNF definition, they
are identified by the string "882." appended to the beginning
of the string (e.g. 822.addr-spec). Additional syntax rules,
to be used throughout this specification are defined in this
chapter.
The EBNF is used in two ways.
1. To describe components of RFC 822 messages (or of
822-P1 components). In this case, the lexical analysis
defined in section 3 of RFC 822 should be used. When
these new EBNF tokens are referred to outside an EBNF
definition, they are identified by the string "EBNF."
appended to the beginning of the string (e.g.
EBNF.bilateral-info).
2. To describe the structure of IA5 or ASCII information
not in an RFC 822 message. In these cases, tokens will
either be self delimiting, or be delimited by self
delimiting tokens. Comments and LWSP are not used as
delimiters.
3.1.5. X.409
An element is referred to with the following syntax, defined in
EBNF:
element = protocol "." definition *( "." definition )
protocol = "P1" / "P2"
definition = identifier / context
identifier = ALPHA *< ALPHA or DIGIT or "-" >
context = "[" 1*DIGIT "]"
Kille [Page 17]
RFC 987 June 1986
Mapping between X.400 and RFC 822
For example, P2.Heading.subject defines the subject element of
the P2 heading. The same syntax is also used to refer to
element values. For example,
P1.EncodedInformationTypes.[0].g3Fax refers to a value of
P1.EncodedInformationTypes.[0] .
3.2. ASCII and IA5
A gateway will interpret all IA5 as ASCII. Thus, they are treated
identically for the rest of this document.
3.3. Universal Primitives
There is a need to convert between ASCII text, and some of the
Universal Primitive types defined in X.409 [CCITT84d]. For each
case, an EBNF syntax definition is given, for use in all of this
specification. All EBNF syntax definitions of Universal
Primitives are in lower case, whereas X.409 primitives are
referred to with the first letter in upper case. Except as noted,
all mappings are symmetrical.
3.3.1. Boolean
Boolean is encoded as:
boolean = "TRUE" / "FALSE"
3.3.2. NumericString
NumericString is encoded as:
numericstring = *DIGIT
3.3.3. PrintableString
PrintableString is a restricted IA5String defined as:
printablestring = *( ps-char / ps-delim )
ps-char = 1DIGIT / 1ALPHA / " " / "'" / "+" / ")"
/ "," / "-" / "." / "/" / ":" / "=" / "?"
ps-delim = "("
A structured subset of EBNF.printablestring is now defined.
This can be used to encode ASCII in the PrintableString
character set.
Kille [Page 18]
RFC 987 June 1986
Mapping between X.400 and RFC 822
ps-encoded = *( ps-char / ps-encoded-char )
ps-encoded-char = "(a)" ; (@)
/ "(p)" ; (%)
/ "(b)" ; (!)
/ "(q)" ; (")
/ "(u)" ; (_)
/ "(" 3DIGIT ")"
The 822.3DIGIT in EBNF.ps-encoded-char must have range 0-127
(Decimal), and is interpreted in decimal as the corresponding
ASCII character. Special encodings are given for: at sign (@),
percent (%), exclamation mark/bang (!), double quote ("), and
underscore (_). These characters are not included in
PrintableString, but are common in RFC 822 addresses. The
abbreviations will ease specification of RFC 822 addresses from
an X.400 system.
An asymmetric mapping between PrintableString and ASCII can now
be defined <3>. To encode ASCII as PrintableString, the
EBNF.ps-encoded syntax is used, with all EBNF.ps-char AND
EBNF.ps-delim mapped directly <4>. All other 822.CHAR are
encoded as EBNF.ps-encoded-char. There are two cases of
encoding PrintableString as ASCII. If the PrintableString can
be parsed as EBNF.ps-encoded, then the previous mapping should
be reversed. If not, it should be interpreted as
EBNF.printablestring.
Some examples are now given. Note the arrows which indicate
asymmetrical mappings:
PrintableString ASCII
'a demo.' <-> 'a demo.'
foo(a)bar <-> foo@bar
(q)(u)(p)(q) <-> "_%"
(a) <-> @
(a) <- (a)
(040)a(041) -> (a)
(040)(a) -> (@
((a) <- (@
The algorithm is designed so that it is simple to use in all
common cases, so that it is general, and so that it is
straightforward to code. It is not attempting to minimise the
number of pathological cases.
Kille [Page 19]
RFC 987 June 1986
Mapping between X.400 and RFC 822
3.3.4. T.61String
T.61 strings are, in general, only used for conveying human
interpreted information. Thus, the aim of a mapping should be
to render the characters appropriately in the remote character
set, rather than to maximise reversibility. The mappings
defined in the CEN/CENELEC X.400 functional standard should be
used [CEN/CENELEC/85a]. These are based on the mappings of
X.408 (sections 4.2.2 and 5.2.2).
3.3.5. UTCTime
Both UTCTime and the RFC 822 822.date-time syntax contain: Year
(lowest two digits), Month, Day of Month, hour, minute, second
(optional), and Timezone. 822.date-time also contains an
optional day of the week, but this is redundant. Therefore a
symmetrical mapping can be made between these constructs <5>.
The UTCTime format which specifies the timezone offset should
be used, in line with CEN/CENELEC recommendations.
Kille [Page 20]
RFC 987 June 1986
Mapping between X.400 and RFC 822
Chapter 4 -- Addressing
Addressing is probably the trickiest problem of an X.400 <-> RFC 822
gateway. Therefore it is given a separate chapter. This chapter, as
a side effect, also defines a standard textual representation of
X.400 addresses.
Initially we consider an address in the (human) mail user sense of
"what is typed at the mailsystem to reference a human". A basic
RFC 822 address is defined by the EBNF EBNF.822-address:
822-address = [ route ] addr-spec
In an 822-P1 protocol, the originator and each recipient should be
considered to be defined by such a construct. In an RFC 822 header,
the EBNF.822-address is encapsulated in the 822.address syntax rule,
and there may also be associated comments. None of this extra
information has any semantics, other than to the end user.
The basic X.400 address is defined by P1.ORName. In P1 all recipient
P1.ORnames are encapsulated within P1.RecipientInfo, and in P2 all
P2.ORNames <6> are encapsulated within P2.ORDescriptor.
It can be seen that RFC 822 822.address must be mapped with
P2.ORDescriptor, and that RFC 822 EBNF.822-address must be mapped
with P1.ORName (originator) and P1.RecipientInfo (recipients).
This chapter is structured as follows:
4.1 Introduction.
4.2 A textual representation of P1.ORName. This is needed for
the later mappings, and as a side effect provides a standard
representation for O/R names.
4.3 Mapping between EBNF.822-address and P1.ORName
4.4 The Full P1 / 822-P1 Mapping
4.5 The Full P2 / RFC 822 Mapping
4.6 Mapping Message-IDs.
Kille [Page 21 "