rfc1405.txt

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

   simply choose among one of them, or try them all in cyclic order to
   obtain better performances.

   In order to keep the mapping rules very simple, avoiding the need to
   analyse Mail-11 addresses to distinguish the 'route', 'node' and
   needed to cover the mapping problem.

5.2. Mail-11 --> X.400

    We define the following Domain Defined Attributes to map a Mail-11
   address:

        DD.Dnet
        DD.Mail-11

   We thus define the mapping rule

        route::node::localpart

   maps into

        C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net;
        DD.Mail-11=route::node::localpart;

   with

        xx  = country code of the gateway performing the conversion
        yyy = Admd of the gateway performing the conversion
        zzz = Prmd of the gateway performing the conversion
        ooo = Organisation of the gateway performing the conversion
        uuu = Org. Unit(s) of the gateway performing the conversion
        net = name of the DECnet network (e.g., HEPnet, SPAN,...)

   ('zzz','ooo','uuu' being used or dropped appropriately in order to



Allocchio                                                       [Page 7]

RFC 1405                    Mail-11 Mapping                 January 1993


   identify uniquely within the X.400 MHS the gateway performing the
   conversion).

   The following defaults also apply:

   if 'node' is missing and we are mapping the Mail-11 originator (From)
   then 'node' defaults to the DECnet node name of the gateway (gwnode);

   if 'node' is missing and we are mapping the Mail-11 recipient (To,
   Cc) then 'node' defaults to the DECnet node name of the 'From'
   address.

   if 'DD.Dnet=net' is missing, then it defaults to a value defined
   locally by the gateway: if the gateway is connected to one DECnet
   network only, then 'net' will be the name of this unique network; if
   the gateway is connected to more than one DECnet network, then the
   gateway will establish a 'first choice' DECnet network, and 'net'
   will default to this value.

   In case 'local-part' contains 'x400-text-address' see also section
   6.4.3;

   In case 'local-part' contains 'RFC822-address' see also section
   6.4.4.

5.2.1. Examples

   Let us suppose that:

     the DECnet network name (net) is 'HEP';
     the DECnet node name of the gateway (gwnode) is 'X4TDEC';
     the Country Code of the gateway is 'IT' and its ADMD is 'garr'
     (and these two fields are enough to identify uniquely the gateway
     within the X.400 MHS).

    USER47
     C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=X4TDEC::USER47;

    MYNODE::BETTY
     C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=MYNODE::BETTY;

    BOSTON::CLUS02::GOOFY1::MARY34
     C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=BOSTON::GOOFY1::MARY34;

    UCLA13::MVAX93::MRGATE::"MBOX1::MBX34:MYC3::BOB"
     C=it; ADMD=garr; DD.Dnet=HEP;
     DD.Mail-11=UCLA13::MVAX93::MRGATE::(q)MBOX1::MBX34::MYC3::BOB(q)




Allocchio                                                       [Page 8]

RFC 1405                    Mail-11 Mapping                 January 1993


    MIAMI2::George.Rosenthal
     C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=MIAMI2::George.Rosenthal;

    MRGATE::"C=xx::A=bbb::P=ppp::S=Joe"
     C=it; ADMD=garr; DD.Dnet=HEP;
     DD.Mail-11=X4TDEC::MRGATE::(q)C=xx::A=bbb::P=ppp::S=Joe(q)

    MAINVX::In%"path1!path2!user%dom"
     C=it; ADMD=garr; DD.Dnet=HEP;
     DD.Mail-11=MAINVX::In(p)(q)path1(b)path2(b)user(p)dom(q)

5.3. X.400 encoding of Mail-11 --> Mail-11

   In order to assure path reversibility in case of multiple Mail-
   11/X.400 gateway crossing we must distinguish two cases:

   - DD.Dnet=net is known to the gateway as one of the DECnet networks
     it is connected to. In this case the mapping is trivial:

        C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net;
        DD.Mail-11=route::node::localpart;

   (see sect. 5.2 for explication of 'xx','yyy','zzz','ooo','uuu','net')

   maps into

        route::node::localpart

   - DD.Dnet=net is NOT known to the gateway as one of the DECnet
     networks it is connected to. In this case the mapping rule
     described into section 5.4 apply:

        C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net;
        DD.Mail-11=route::node::localpart;

   maps into

        gwnode::gw%"C=xx;ADMD=yyy;PRMD=www;DD.Dnet=net;
        DD.Mail-11=route::node::localpart;"

5.3.1. Examples

   Let us suppose that:

     the DECnet network name (net) is 'HEP';
     the DECnet node name of the gateway (gwnode) is 'X4TDEC';
     the Country Code of the gateway is 'IT' and its ADMD is 'garr';
     (and these two fields are enough to identify uniquely the gateway



Allocchio                                                       [Page 9]

RFC 1405                    Mail-11 Mapping                 January 1993


     within the X.400 MHS).

     C=it; ADMD=garr; DD.Dnet=HEP;
     DD.Mail-11=X4TDEC::MRGATE::(q)C=ab::A=dsa::P=qwty::OU=mie::S=Cly(q)
       MRGATE::"C=ab::A=dsa::P=qwty::OU=mie::S=Cly"

     C=it; ADMD=garr; DD.Dnet=EASYNET; DD.Mail-11=ROM01::CARLO;
       X4TDEC::gw%"C=it;ADMD=garr;DD.Dnet=EASYNET;
       DD.Mail-11=ROM01::CARLO;"

   (in the above example 'EASYNET' is supposed to be not connected to
   our gateway located on X4TDEC DECnet node).

5.4. X.400 --> Mail-11

   The mapping of an X.400 O/R address into Mail-11 is done encoding the
   various attributes into the X400-text-address as defined in chapter 4
   of RFC1327, and including this as 'f-address'. A 'f-pref' and a the
   DECnet node name of the gateway.

   Thus

      x400-text-address

   will be encoded like

      gwnode::gw%"x400-text-address"

   having spaces dividing attributes as optional.

5.4.1. Example

   Let us suppose that:

     the DECnet node name of the gateway (gwnode) is 'X4TDEC';

   Thus

      C=gb; ADMD=Gold 400; PRMD=AC.UK; O=ucl; OU=cs; G=Jim; S=Clay;

   will be encoded like

    X4TDEC::gw%"/C=gb/A=Gold 400/P=AC.UK/O=ucl/OU=cs/G=Jim/S=Clay"

   or its equivalent with the ";" notation

    X4TDEC::gw%"C=gb;ADMD=Gold 400;PRMD=AC.UK;O=ucl;OU=cs;G=Jim;S=Clay;"




Allocchio                                                      [Page 10]

RFC 1405                    Mail-11 Mapping                 January 1993


5.5. Mail-11 encoding of X.400 --> X.400

   It can happened that Mail-11 is used to relay messages between X.400
   systems; this will mean multiple X.400/Mail-11 gateway crossing and
   we will encounter Mail-11 addresses containing embedded X.400
   informations. In order to assure path reversibility we must then
   distinguish two cases:

   - the embedded X.400 address belongs to a domain whose naming and
     routing rules are known to the global X.400 MHS.  In this case the
     mapping is trivial:

       route::gwnode::gw%"x400-text-address"

   maps into

       x400-text-address

      'route' and 'gwnode' are mapped into X.400 Trace service elements.

   - the encoded X.400 domain does not belong to the global X.400 name
     space. In this case the mapping rule described into section 5.2
     apply:

       route::gwnode::gw%"x400-text-address"

   maps into

       C=xx; ADMD=yyy; DD.Dnet=net;
       DD.Mail-11=route::gwnode::gw(p)(q)x400-text-address(q);

   The latter case  is deprecated and must be regarded as a possible
   temporary solution only, while waiting to include into the global
   X.400 MHS also this domain.

5.5.1. Examples

   Let us suppose that:

     the DECnet network name (net) is 'HEP';
     the DECnet node name of the gateway (gwnode) is 'X4TDEC';
     the Country Code of the gateway is 'IT' and its ADMD is 'garr';
     (and these two fields are enough to identify uniquely the gateway
     within the X.400 MHS).

     X4TDEC::gw%"C=fr;ADMD=atlas;PRMD=ifip;O=poly;S=Moreau;"
       C=fr; ADMD=atlas; PRMD=ifip; O=poly; S=Moreau;




Allocchio                                                      [Page 11]

RFC 1405                    Mail-11 Mapping                 January 1993


     X4TDEC::gw%"C=zz;ADMD= ;PRMD=Botwa;O=Miner;S=Chiuaw;"
       C=it; ADMD=garr; DD.Dnet=HEP;
       DD.Mail-11=X4TDEC::gw(p)(q)C=zz;ADMD= ;
       PRMD=Botwa;O=Miner;S=Chiuaw;(q)

   (in the above example  C=zz is unknown to the global X.400 MHS)

Chapter 6 - Complex mapping

6.1. The protocol triangle

   The bilateral mappings described in chapter 5 must be extended in
   order to cover also the case in which also RFC822 addressing is
   involved, and the following triangular situation occurs:

                                   x.400
                                   /  \
                                  /    \
                                 /      \
                             Mail-11----RFC822

   The X.400 - RFC822 side is fully covered by RFC1327, and the previous
   chapters in this document cover the Mail-11 - X.400 side.

   Currently a number of implementations also perform the mapping along
   the Mail-11 - RFC822 side. The most important among these de facto
   standards are discussed in Appendix A, jointly with a Mail-11 -
   RFC822 mapping scheme which covers this side of the triangle.

6.2. RFC822 mapped in Mail-11

   The 'RFC822-address' is usually included in 'local-part' as

        route::gwnode::gw%"rfc822-address"

   an example

        NVXA23::SMTPGW::in%"[e-mail]"

6.3. Mail-11 mapped in RFC822

   There are different styles in mapping a Mail-11 address in RFC822;
   let's have a short summary.

   - Mail-11 address encoded in "Left Hand Side" (LHS) of RFC822
     address, using "%" syntax or "::" syntax;

        route::node::localpart



Allocchio                                                      [Page 12]

RFC 1405                    Mail-11 Mapping                 January 1993


   maps to

        localpart%node%route@gw-domains

   or

        "route::node::localpart"@gw-domains

   where 'gw-domains' identify uniquely the Mail-11 / RFC822 gateway.

   - Mail-11 address maps partly to LHS and partly to 'domain' part of
     RFC822 address:

        node::localpart

   maps to

        [e-mail]-domains

   - Mail-11 address is completely hidden by a mapping table / directory
     and the resultant RFC822 address contains no trace at all of the
     original address.

   As you could notice, in any of the quoted cases the resultant RFC822
   address is not distinguishable from a genuine RFC822 address.

6.4. Multiple conversions

   Let us now examine briefly the possible situations which involve
   multiple conversions, having one protocol as a relay between the
   other two. This summary suggest some possible enhanced solutions to
   avoid heavy and unduly mappings, but the 'step by step' approach,
   considering blindly one conversion as disjointed to the other, as
   described in the previous sections, can always be used.