rfc1506.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                      J. Houttuin
Request for Comments:  1506                           RARE Secretariat
RARE Technical Report: 6                                   August 1993


        A Tutorial on Gatewaying between X.400 and Internet Mail

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Introduction

   There are many ways in which X.400 and Internet (STD 11, RFC 822)
   mail systems can be interconnected. Addresses and service elements
   can be mapped onto each other in different ways. From the early
   available gateway implementations, one was not necessarily better
   than another, but the sole fact that each handled the mappings in a
   different way led to major interworking problems, especially when a
   message (or address) crossed more than one gateway. The need for one
   global standard on how to implement X.400 - Internet mail gatewaying
   was satisfied by the Internet Request For Comments 1327, titled
   "Mapping between X.400(1988)/ISO 10021 and RFC 822."

   This tutorial was produced especially to help new gateway managers
   find their way into the complicated subject of mail gatewaying
   according to RFC 1327. The need for such a tutorial can be
   illustrated by quoting the following discouraging paragraph from RFC
   1327, chapter 1: "Warning: the remainder of this specification is
   technically detailed. It will not make sense, except in the context
   of RFC 822 and X.400 (1988). Do not attempt to read this document
   unless you are familiar with these specifications."

   The introduction of this tutorial is general enough to be read not
   only by gateway managers, but also by e-mail managers who are new to
   gatewaying or to one of the two e-mail worlds in general. Parts of
   this introduction can be skipped as needed.

   For novice end-users, even this tutorial will be difficult to read.
   They are encouraged to use the COSINE MHS pocket user guide [14]
   instead.

   To a certain extent, this document can also be used as a reference
   guide to X.400 <-> RFC 822 gatewaying. Wherever there is a lack of
   detail in the tutorial, it will at least point to the corresponding
   chapters in other documents. As such, it shields the RFC 1327 novice



RARE Working Group on Mail and Messaging (WG-MSG)               [Page 1]

RFC 1506        X.400-Internet Mail Gatewaying Tutorial      August 1993


   from too much detail.

Acknowledgements

   This tutorial is heavily based on other documents, such as [2], [6],
   [7], [8], and [11], from which large parts of text were reproduced
   (slightly edited) by kind permission from the authors.

   The author would like to thank the following persons for their
   thorough reviews: Peter Cowen (Nexor), Urs Eppenberger (SWITCH), Erik
   Huizer (SURFnet), Steve Kille (ISODE Consortium), Paul Klarenberg
   (NetConsult), Felix Kugler (SWITCH), Sabine Luethi.

Disclaimer

   This document is not everywhere exact and/or complete in describing
   the involved standards. Irrelevant details are left out and some
   concepts are simplified for the ease of understanding. For reference
   purposes, always use the original documents.
































RARE Working Group on Mail and Messaging (WG-MSG)               [Page 2]

RFC 1506        X.400-Internet Mail Gatewaying Tutorial      August 1993


Table of Contents

       1. An overview of relevant standards ........................   4
         1.1. What is X.400 ? ......................................   5
         1.2. What is an RFC ? .....................................   8
         1.3. What is RFC 822 ? ....................................   9
         1.4. What is RFC 1327 ? ...................................  11
       2. Service Elements .........................................  12
       3. Address mapping ..........................................  14
         3.1. X.400 addresses ......................................  15
           3.1.1. Standard Attributes ..............................  15
           3.1.2. Domain Defined Attributes ........................  17
           3.1.3. X.400 address notation ...........................  17
         3.2. RFC 822 addresses ....................................  19
         3.3. RFC 1327 address mapping .............................  20
           3.3.1. Default mapping ..................................  20
             3.3.1.1. X.400 -> RFC 822 .............................  20
             3.3.1.2. RFC 822 -> X.400 .............................  22
           3.3.2. Exception mapping ................................  23
             3.3.2.1. PersonalName and localpart mapping ...........  25
             3.3.2.2. X.400 domain and domainpart mapping ..........  26
               3.3.2.2.1. X.400 -> RFC 822 .........................  27
               3.3.2.2.2. RFC 822 -> X.400 .........................  28
         3.4. Table co-ordination ..................................  31
         3.5. Local additions ......................................  31
         3.6. Product specific formats .............................  32
         3.7. Guidelines for mapping rule definition ...............  34
       4. Conclusion ...............................................  35
       Appendix A. References ......................................  36
       Appendix B. Index  (Only available in the Postscript version)  37
       Appendix C. Abbreviations ...................................  37
       Appendix D. How to access the MHS Co-ordination Server ......  38
       Security Considerations .....................................  39
       Author's Address ............................................  39

















RARE Working Group on Mail and Messaging (WG-MSG)               [Page 3]

RFC 1506        X.400-Internet Mail Gatewaying Tutorial      August 1993


1. An overview of relevant standards

   This chapter describes the history, status, future, and contents of
   the involved standards.

   There is a major difference between mail systems used in the USA and
   Europe. Mail systems originated mainly in the USA, where their
   explosive growth started as early as in the seventies. Different
   company-specific mail systems were developed simultaneously, which,
   of course, led to a high degree of incompatibility. The Advanced
   Research Projects Agency (ARPA), which had to use machines of many
   different manufacturers, triggered the development of the Internet
   and the TCP/IP protocol suite, which was later accepted as a standard
   by the US Department of Defense (DoD). The Internet mail format is
   defined in STD 11, RFC 822 and the protocol used for exchanging mail
   is known as the simple mail transfer protocol (SMTP) [1]. Together
   with UUCP and the BITNET protocol NJE, SMTP has become one of the
   main de facto mail standards in the US.

   Unfortunately, all these protocols were incompatible, which explains
   the need to come to an acceptable global mail standard.  CCITT and
   ISO began working on a norm and their work converged in what is now
   known as the X.400 Series Recommendations. One of the objectives was
   to define a superset of the existing systems, allowing for easier
   integration later on. Some typical positive features of X.400 are the
   store-and-forward mechanism, the hierarchical address space and the
   possibility of combining different types of body parts into one
   message body.

   In Europe, the mail system boom came later. Since there was not much
   equipment in place yet, it made sense to use X.400 as much as
   possible right from the beginning. A strong X.400 lobby existed,
   especially in West-Germany (DFN). In the R&D world, mostly EAN was
   used because it was the only affordable X.400 product at that time
   (Source-code licenses were free for academic institutions).

   At the moment, the two worlds of X.400 and SMTP are moving closer
   together. For instance, the United States Department of Defense, one
   of the early forces behind the Internet, has decided that future DoD
   networking should be based on ISO standards, implying a migration
   from SMTP to X.400. As an important example of harmonisation in the
   other direction, X.400 users in Europe have a need to communicate
   with the Internet. Due to the large traffic volume between the two
   nets it is not enough interconnecting them with a single
   international gateway.  The load on such a gateway would be too
   heavy. Direct access using local gateways is more feasible.

   Although the expected success of X.400 has been a bit disappointing



RARE Working Group on Mail and Messaging (WG-MSG)               [Page 4]

RFC 1506        X.400-Internet Mail Gatewaying Tutorial      August 1993


   (mainly because no good products were available), many still see the
   future of e-mail systems in the context of this standard.

   And regardless if in the long run X.400 will or will not take over
   the world of e-mail systems, SMTP cannot be neglected over the next
   ten years. Especially the simple installation procedures and the high
   degree of connectivity will contribute to a growing number of RFC 822
   installations in Europe and world-wide in the near future.

1.1. What is X.400 ?

   In October 1984, the Plenary Assembly of the CCITT accepted a
   standard to facilitate international message exchange between
   subscribers to computer based store-and-forward message services.
   This standard is known as the CCITT X.400 series recommendations
   ([16], from now on called X.400(84)) and happens to be the first
   CCITT recommendation for a network application. It should be noted
   that X.400(84) is based on work done in the IFIP Working Group 6.5,
   and that ISO at the same time was proceeding towards a compatible
   document. However, the standardisation efforts of CCITT and ISO did
   not converge in time (not until the 1988 version), to allow the
   publication of a common text.

   X.400(84) triggered the development of software implementing (parts
   of) the standard in the laboratories of almost all major computer
   vendors and many software houses. Similarly, public carriers in many
   countries started to plan X.400(84) based message systems that would
   be offered to the users as value added services. Early
   implementations appeared shortly after first drafts of the standard
   were published and a considerable number of commercial systems are
   available nowadays.

   X.400(84) describes a functional model for a Message Handling System
   (MHS) and associates services and protocols. The model illustrated in
   Figure 1.1. defines the components of a distributed messaging system.

   Users in the MHS environment are provided with the capability of
   sending and receiving messages. Users in the context of an MHS may be
   humans or application processes. The User Agent (UA) is a process
   that makes the services of the MTS available to the user. A UA may be
   implemented as a computer program that provides utilities to create,
   send, receive and perhaps archive messages. Each UA, and thus each
   user, is identified by a name (each user has its own UA).








RARE Working Group on Mail and Messaging (WG-MSG)               [Page 5]

RFC 1506        X.400-Internet Mail Gatewaying Tutorial      August 1993


    -----------------------------------------------------------------
    |                user        user   Message Handling Environment|
    |                 |            |                                |
    |     ----------------------------------------------------------|
    |     |           |            |    Message Handling System    ||
    |     |         ----          ----                             ||
    |     |         |UA|          |UA|                             ||
    |     |         ----          ----                             ||
    |     |           |             |                              ||
    |     |       -------------------------------------------------||
    |     |       |   |             |   Message Transfer System   |||
    |     | ----  |  -----         -----                          |||
    |user-|-|UA|--|--|MTA|         |MTA|                          |||
    |     | ----  |  -----         -----                          |||
    |     |       |    \             /                            |||
    |     |       |     \           /                             |||
    |     |       |      \         /                              |||
    |     |       |       \       /                               |||
    |     |       |        \     /                                |||
    |     | ----  |         -----                                 |||
    |user-|-|UA|--|---------|MTA|                                 |||
    |     | ----  |         -----                                 |||
    |     |       -------------------------------------------------||
    |     ----------------------------------------------------------|
    -----------------------------------------------------------------
                    Fig. 1.1. X.400 functional model

   The Message Transfer system (MTS) transfers messages from an
   originating UA to a recipient UA. As implied by the Figure 1.1, data
   sent from UA to UA may be stored temporarily in several intermediate
   Message Transfer Agents (MTA), i.e., a store-and- forward mechanism
   is being used. An MTA forwards received messages to a next MTA or to
   the recipient UA.