Mapping between X.400 and RFC 822
RFC 987
|
Document |
Type |
|
RFC - Unknown
(June 1986; No errata)
|
|
Authors |
|
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 987 (Unknown)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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.
Show full document text