rfc1506.txt

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

   X.400(84) divides layer 7 of the OSI Reference Model into 2
   sublayers, the User Agent Layer (UAL) and the Message Transfer Layer
   (MTL) as shown in the Figure 1.2.

   The MTL is involved in the transport of messages from UA to UA, using
   one or several MTAs as intermediaries. By consequence, routing issues
   are entirely dealt with in the MTL. The MTL in fact corresponds to
   the postal service that forwards letters consisting of an envelope
   and a content. Two protocols, P1 and P3, are used between the MTL
   entities (MTA Entity (MTAE), and Submission and Delivery Entity
   (SDE)) to reliably transport messages. The UAL embodies  peer UA
   Entities (UAE), which interpret the content of a message and offer
   specific services to the application process.  Depending on the
   application to be supported on top of the MTL, one of several end-



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


   to-end protocols (Pc) is used between UAEs. For electronic mail,
   X.400(84) defines the protocol P2 as part of the InterPersonal
   Messaging Service (IPMS). Conceivably other UAL protocols may be
   defined, e.g., a protocol to support the exchange of electronic
   business documents.

       --------------------------------------------------------------
                   -----                          -----
       UA layer    |UAE|<----- P2, Pc ----------->|UAE|
                   -----                          -----
       --------------------------------------------------------------
                   ------          ------         -----
       MTA layer   |MTAE|<-- P1 -->|MTAE|<-- P3-->|SDE|
                   ------          ------         -----
       --------------------------------------------------------------
             xxxE = xxx Entity ;   SDE = Submission & Delivery Entity
       --------------------------------------------------------------
                           Fig. 1.2. X.400 Protocols

   The structure of an InterPersonal Message (IPM) can be visualised as
   in Figure 1.3. (Note that the envelope is not a part of the IPM; it
   is generated by the MTL).

                                                            Forwarded
    Message                                                 IP-message
    -                     ----------      --- ----------    -
    |  message-           |envelope|     /    | PDI    |    |
    |  content   IPM      ----------    /     ----------    |
    |  -         -        ----------   /      ----------    |
    |  |         |  IPM-  |heading |  /       |heading |    |
    |  |         |  body  ---------- /        ----------    |
    |  |         |  -     ----------/         ----------    |
    |  |         |  |     |bodypart|          |bodypart|    |
    |  |         |  |     ----------\         ----------    |
    |  |         |  |     ---------- \        ----------    |
    |  |         |  |     |bodypart|  \       |bodypart|    |
    |  |         |  |     ----------   \      ----------    |
    |  |         |  |          .        \                   |
    |  |         |  |          .         \                  |
    |  |         |  |     ----------      \   ----------    |
    |  |         |  |     |bodypart|       \  |bodypart|    |
    -  -         -  -     ----------        - ----------    -
                                      (PDI = Previous Delivery Info.)
                    Fig. 1.3. X.400 message structure

   An IPM heading contains information that is specific for an
   interpersonal message like 'originator', 'subject', etc. Each
   bodypart can contain one information type, text, voice or as a



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


   special case, a forwarded message. A forwarded message consists of
   the original message together with Previous Delivery Information
   (PDI), which is drawn from the original delivery envelope.

   Early experience with X.400(84) showed that the standard had various
   shortcomings. Therefore CCITT, in parallel with ISO, corrected and
   extended the specification during its 1984 to 1988 study period and
   produced a revised standard [17], which was accepted at the 1988
   CCITT Plenary Meeting [10].  Amongst others, X.400(88) differs from
   X.400(84) in that it defines a Message Store (MS), which can be seen
   as a kind of database for messages. An MS enables the end-user to run
   a UA locally, e.g., on a PC, whilst the messages are stored in the
   MS, which is co-located with the MTA. The MTA can thus always deliver
   incoming messages to the MS instead of to the UA. The MS can even
   automatically file incoming messages according to certain criteria.
   Other enhancements in the 88 version concern security and
   distribution lists.

1.2. What is an RFC ?

   The Internet, a loosely-organised international collaboration of
   autonomous, interconnected networks, supports host-to-host
   communication through voluntary adherence to open protocols and
   procedures defined by Internet Standards. There are also many
   isolated internets, i.e., sets of interconnected networks, that are
   not connected to the Internet but use the Internet Standards. The
   architecture and technical specifications of the Internet are the
   result of numerous research and development activities conducted over
   a period of two decades, performed by the network R&D community, by
   service and equipment vendors, and by government agencies around the
   world.

   In general, an Internet Standard is a specification that is stable
   and well-understood, is technically competent, has multiple,
   independent, and interoperable implementations with operational
   experience, enjoys significant public support, and is recognisably
   useful in some or all parts of the Internet.

   The principal set of Internet Standards is commonly known as the
   "TCP/IP protocol suite". As the Internet evolves, new protocols and
   services, in particular those for Open Systems Interconnection (OSI),
   have been and will be deployed in traditional TCP/IP environments,
   leading to an Internet that supports multiple protocol suites.

   The following organisations are involved in setting Internet
   standards.

   Internet standardisation is an organised activity of the Internet



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


   Society (ISOC). The ISOC is a professional society that is concerned
   with the growth and evolution of the world-wide Internet, with the
   way in which the Internet is and can be used, and with the social,
   political, and technical issues that arise as a result.

   The Internet Engineering Task Force (IETF) is the primary body
   developing new Internet Standard specifications. The IETF is composed
   of many Working Groups, which are organised into areas, each of which
   is co-ordinated by one or more Area Directors.

   The Internet Engineering Steering Group (IESG) is responsible for
   technical management of IETF activities and the approval of Internet
   standards specifications, using well-defined rules. The IESG is
   composed of the IETF Area Directors, some at-large members, and the
   chairperson of the IESG/IETF.

   The Internet Architecture Board (IAB) has been chartered by the
   Internet Society Board of Trustees to provide quality control and
   process appeals for the standards process, as well as external
   technical liaison, organizational oversight, and long-term
   architectural planning and research.

   Any individual or group (e.g., an IETF or RARE working group) can
   submit a document as a so-called Internet Draft. After the document
   is proven stable, the IESG may turn the Internet-Draft into a
   "Requests For Comments" (RFC). RFCs cover a wide range of topics,
   from early discussion of new research concepts to status memos about
   the Internet. All Internet Standards (STDs) are published as RFCs,
   but not all RFCs specify standards. Another sub-series of the RFCs
   are the RARE Technical Reports (RTRs).

   As an example, this tutorial also started out as an Internet-Draft.
   After almost one year of discussions and revisions it was approved by
   the IESG as an Informational RFC.

   Once a document is assigned an RFC number and published, that RFC is
   never revised or re-issued with the same number. Instead, a revision
   will lead to the document being re-issued with a higher number
   indicating that an older one is obsoleted.

1.3. What is RFC 822 ?

   STD 11, RFC 822 defines a standard for the format of Internet text
   messages. Messages consist of lines of text. No special provisions
   are made for encoding drawings, facsimile, speech, or structured
   text. No significant consideration has been given to questions of
   data compression or to transmission and storage efficiency, and the
   standard tends to be free with the number of bits consumed. For



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


   example, field names are specified as free text, rather than special
   terse codes.

   A general "memo" framework is used. That is, a message consists of
   some information in a rigid format (the 'headers'), followed by the
   main part of the message (the 'body'), with a format that is not
   specified in STD 11, RFC 822. It does define the syntax of several
   fields of the headers section; some of these fields must be included
   in all messages.

   STD 11, RFC 822 is used in conjunction with a number of different
   message transfer protocol environments (822-MTSs).

        - SMTP Networks: On the Internet and other TCP/IP networks,
          STD 11, RFC 822 is used in conjunction with two other
          standards: STD 10, RFC 821, also known as Simple Mail
          Transfer Protocol (SMTP) [1], and RFCs 1034 and 1035
          which specify the Domain Name System [3].

        - UUCP Networks: UUCP is the UNIX to UNIX CoPy protocol, which
          is usually used over dialup telephone networks to provide a
          simple message transfer mechanism.

        - BITNET: Some parts of Bitnet and related networks use STD
          11, RFC 822 related protocols, with EBCDIC encoding.

        - 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.

   STD 11, RFC 822 is based on the assumption that there is an
   underlying service, which in RFC 1327 is called the 822-MTS service.
   The 822-MTS 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.

   It is possible to achieve 2) within the RFC 822 header.  Some 822-
   MTS protocols, in particular SMTP, can provide additional
   functionality, but as these are neither mandatory in SMTP, nor
   available in other 822-MTS protocols, they are not considered here.
   Details of aspects specific to two 822-MTS protocols are given in
   Appendices B and C of RFC 1327. 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 heading fields, although some are
   analogous to MTS Service Elements.



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


1.4. What is RFC 1327 ?

   There is a large community using STD 11, RFC 822 based protocols for
   mail services, who will wish to communicate with users of the
   InterPersonal Messaging Service (IPMS) provided by X.400 systems, and
   the other way around. This will also be a requirement in cases where
   RFC 822 communities intend to make a transition to use X.400 (or the
   other way around, which also happens), as conversion will be needed
   to ensure a smooth service transition.

   The basic function of a mail gateway can be described as follows:
   receive a mail from one mail world, translate it into the formats of
   the other mail world and send it out again using the routing rules
   and protocols of that other world.

   Especially if a message crosses more than one gateway, it is
   important that all gateways have the same understanding of how things
   should be mapped. A simple example of what could go wrong otherwise
   is the following: A sends a message to B through a gateway and B's
   reply to A is being routed through another gateway.

   If the two gateways don't use the same mappings, it can be expected
   that the From and To addresses in the original mail and in the answer
   don't match, which is, to say the least, very confusing for the end-
   users (consider what happens if automated processes communicate via
   mail). More serious things can happen to addresses if a message
   crosses more than one gateway on its way from the originator to the
   recipient. As a real-life example, consider receiving a message from:

      Mary Plork <MMP_+a_ARG_+lMary_Plork+r%MHS+d_A0CD8A2B01F54FDC-
      [e-mail]>

   This is not what you would call user-friendly addressing.... RFC 1327
   describes a set of mappings that will enable a more transparent
   interworking between systems operating X.400 (both 84 and 88) and
   systems using RFC 822, or protocols derived from STD 11, RFC 822.

   RFC 1327 describes all mappings in term of X.400(88). It defines how
   these mappings should be applied to X.400(84) systems in its Appendix
   G.

   Some words about the history of RFC 1327: It started out in June
   1986, when RFC 987 defined for X.400(84) what RFC 1327 defines for
   X.400(84 and 88). RFC 1026 specified a number of additions and
   corrections to RFC 987. In December 1989, RFC 1138, which had a very
   short lifetime, was the first one to deal with X.400(88). It was
   obsoleted by RFC 1148 in March 1990. Finally, in May 1992, RFC 1327
   obsoleted all of its ancestors.



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


2. Service Elements

   Both RFC 822 and X.400 messages consist of certain service elements
   (such as 'originator' and 'subject'). As long as a message stays
   within its own world, the behaviour of such service elements is well
   defined. An important goal for a gateway is to maintain the highest
   possible service level when a message crosses the boundary between
   the two mail worlds.

   When a user originates a message, a number of services are available.
   RFC 1327 describes, for each service elements, to what extent it is
   supported for a recipient accessed through a gateway.  There are
   three levels of support:

        - Supported: Some of the mappings are quite straight-forward,
          such as '822.Subject:' <-> 'IPMS.Subject'.

        - Not supported: There may be a complete mismatch: certain