rfc1506.txt

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

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



            |       ------------         ---------
            |       |X: RFC 822|<------->|gateway|
            |       ------------         ---------
            | A           |                  ^
            \             |                  |
             \---------------------------------------------
                          |                  |
             /---------------------------------------------
            /             |                  |
            | B           |                  v
            |             |              -----------
            |             |              |Z: X.400 |
            |             |              -----------
            |             |                  .
            |             |                  .
            |             |                  .
            |             |                  .
            |             |                  .
            |             v                  v
            |        ------------         ---------
            |        |Y: RFC 822|<........|gateway|
            |        ------------         ---------

                    Fig. 3.1 The third party problem


         Now if Z wants to 'group reply' to both X and Y, his reply to Y
         will be routed over the gateway in country A, even though Y is
         located in the same country:

                     From: C=B;...;S=Z
                     To:   DD.RFC-822=Y(a)B; C=A;....;O=GW ,
                           DD.RFC-822=X(a)A; C=A;....;O=GW

         The best way to travel for a message from Z to Y would of
         course have been over the gateway in country B:

                     From: C=B;...;S=Z
                     To:   DD.RFC-822=Y(a)B; C=B;....;O=GW ,
                           DD.RFC-822=X(a)A; C=A;....;O=GW

         The third party problem is caused by the fact that routing
         information is mapped into addresses.

         Ideally, the third party problem shouldn't exist. After all,
         address mapping affects addresses, and an address is not a
         route.... The reality is different however. For instance, very



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


         few X.400 products are capable to route messages on the
         contents of a DDA (actually, only RFC 1327 gateways will be
         able to interpret this type of DDA, and who says that the reply
         will pass a local gateway on its route back?).  Similar
         limitations hold for the other direction: an RFC 822 based
         mailer is not even allowed (see [5]) to make routing decisions
         of the content of a left-hand-side encoded X.400 address if the
         domain part is not its own.  So in practice, addressing and
         (thus also mapping) will very well affect routing.

   To make mapping between addresses more user friendly, and to avoid
   the problems shown above, RFC 1327 allows for overruling the default
   left-hand-side encoding and DDA mapping algorithms. This is done by
   specifying associations (mapping rules) between certain domainparts
   and X.400 domains. An X.400 domain (for our purposes; CCITT has a
   narrower definition...) consists of the domain-related SAs of a
   Mnemonic O/R address (i.e., all SAs except PN and CN). The idea is to
   use the similarities between both address spaces, and directly map
   similar address parts onto each other. If, for the domain in the
   address to be mapped, an explicit mapping rule can be found, the
   mapping is performed between:

        localpart     <->   PersonalName
        domainpart    <->   X.400 domain

   The address information of the gateway is only used as an input
   parameter if no mapping rule can be found, i.e., if the address
   mapping must fall back to its default algorithm.

   The complete mapping function can thus be visualised as follows:


          address information of the gateway performing the mapping
                                      |
                                      v
                             +-----------------+
        RFC 822 address <--->| address mapping | <---> X.400 address
                             +-----------------+
                                      ^
                                      |
                    domain associations (mapping rules)

3.3.2.1. PersonalName and localpart mapping

   Since the mapping between these address parts is independent of the
   mapping rules that are used, and because it follows a simple, two-
   way algorithmic approach, this subject is discussed in a separate
   sub-chapter first.



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


   The X.400 PersonalName consists of givenName, initials, and surName.
   RFC 1327 assumes that generationQualifier is not used.

   To map a localpart to an X.400 PN, the localpart is scanned for dots,
   which are considered delimiters between the components of PN, and
   also between single initials. In order not to put too much detail in
   this tutorial, only a few examples are shown here. For the detailed
   algorithm, see RFC 1327, chapter 4.2.1.

        Marshall.Rose             <->   G=Marshall;S=Rose
        M.T.Rose                  <->   I=MT;S=Rose
        Marshall.M.T.Rose         <->   G=Marshall;I=MT;S=Rose

   To map an X.400 PN to an RFC 822 localpart, take the non-empty PN
   attributes, put them into their hierarchical order (G I* S), and
   connect them with periods.

   Some exceptions are caused by the fact that left-hand-side encoding
   can also be mixed with exception mapping. This is shown in more
   detail in the following sub-chapters.

3.3.2.2. X.400 domain and domainpart mapping

   A mapping rule associates two domains: an X.400 domain and an RFC 822
   domain. The X.400 domain is written in the RFC 1327 domain notation
   (See 3.1.3.), so that both domains have the same hierarchical order.
   The domains are written on one line, separated by a '#' sign. For
   instance:

        arcom.ch#ADMD$arcom.C$ch#
        PRMD$tlec.ADMD$ade.C$nl#tlec.nl#

   A mapping rule must at least contain a top level domain and a country
   code. If an address must be mapped, a mapping rule with the longest
   domain match is sought. The associated domain in the mapping rule is
   used as the domain of the mapped address. The remaining domains are
   mapped one by one following the natural hierarchy. Concrete examples
   are shown in the following subchapters.

3.3.2.2.1. X.400 -> RFC 822

   As an example, assume the following mapping rule is defined:

           PRMD$tlec.ADMD$ade.C$nl#tlec.nl#







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


   Then the address C=nl; ADMD=ade; PRMD=tlec; O=you; OU=owe; S=plork

           S      OU  O  PRMD  ADMD  Country
           |      |   |  |     |     |
           plork owe you tlec  ade   nl

   would be mapped as follows. The Surname 'plork' is mapped to the
   localpart 'plork', see chapter 3.3.2.1. The domain

           localpart
              |  sdom3
              |    | sdom2
              |    |   |  sdom1
              |    |   |   |  top-level-domain
              |    |   |   |   |
           plork@         tlec.nl

   The remaining SAs (O and one OU) are mapped one by one following the
   natural hierarchy: O is mapped to sdom2, OU is mapped to sdom3:

           localpart
              | sdom3
              |  | sdom2
              |  |   |  sdom1
              |  |   |   |  top-level-domain
              |  |   |   |    |
           [e-mail]

   Thus the mapped address is:

           [e-mail]

   The table containing the listing of all such mapping rules, which is
   distributed to all gateways world-wide, is normally referred to as
   'mapping table 1'. Other commonly used filenames (also depending on
   which software your are using) are:

           'or2rfc'
           'mapping 1'
           'map1'
           'table 1'
           'X2R'

   As already announced, there is an exceptional case were localpart and
   PN are not directly mapped onto each other: sometimes it is necessary
   to use the localpart for other purposes. If the X.400 address
   contains attributes that would not allow for the simple mapping:




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


           localpart     <->   PersonalName
           domainpart    <->   X.400 domain

   (e.g., spaces are not allowed in an RFC 822 domain, GQ and CN cannot
   be directly mapped into localpart, DDAs of another type than RFC-
   822), such attributes, together with the PN, are left-hand-side
   encoded. The domainpart must still be mapped according to the mapping
   rule as far as possible. This probably needs some examples:

           C=nl; ADMD=ade; PRMD=tlec; O=owe; OU=you; S=plork; GQ=jr
           ->
           /S=plork/GQ=jr/@you.owe.tlec.nl

           C=nl; ADMD=ade; PRMD=tlec; O=owe; OU=spc ctr; OU=u; S=plork
           ->
           "/S=plork/OU=u/OU=spc ctr/"@owe.tlec.nl

   Note that in the second example, 'O=owe' is still mapped to a
   subdomain following the natural hierarchy. The problems start with
   the space in 'OU=spc ctr'.

3.3.2.2.2. RFC 822 -> X.400

   As an example, assume the following mapping rule is defined:

           tlec.nl#PRMD$tlec.ADMD$ade.C$nl#

   Then the address '[e-mail]' :

           localpart
              |  sdom3
              |    | sdom2
              |    |   |  sdom1
              |    |   |   |  top-level-domain
              |    |   |   |   |
           [e-mail]

   would be mapped as follows.

   The localpart 'plork' is mapped to 'S=plork', see chapter 3.3.2.1.

   The domain 'tlec.nl' is mapped according to the mapping rule:

           S     OU  OU  O  PRMD  ADMD  Country
           |                |     |    |
           plork            tlec  ade  nl

   The remaining domains (owe.you) are mapped one by one following the



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


   natural hierarchy: sdom2 is mapped to O, sdom3 is mapped to OU:

           S     OU  OU  O  PRMD  ADMD  Country
           |         |   |  |     |     |
           plork     |   |  tlec  ade   nl
                     owe you

   Thus the mapped address is (in a readable notation):

           C=nl; ADMD=ade; PRMD=tlec; O=you; OU=owe; S=plork

   Had there been any left-hand-side encoded SAs in the localpart that
   didn't represent a complete mnemonic O/R address, the localpart would
   be mapped to those SAs. E.g.,

           "/S=plork/GQ=jr/OU=u/OU=spc ctr/"@owe.tlec.nl
           ->
           C=nl; ADMD=ade; PRMD=tlec; O=owe; OU=space ctr;
           OU=u; S=plork; GQ=jr

   This is necessary to reverse the special use of localpart to left-
   hand-side encode certain attributes. See 3.3.2.2.1.

   You might ask yourself by now why such rules are needed at all. Why
   don't we just use map1 in the other direction? The p