rfc1405.txt

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

6.4.1. X.400 --> RFC822 --> Mail-11

   We apply the RFC1327 rules to the first step, obtaining an RFC822
   address which can be mapped in Mail-11 using the 'f-address' field,
   as described in section 6.2.

   an example:

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

   maps accordingly to RFC1327 to

      [e-mail]



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


   and finally becomes

      SMTPGW::In%"[e-mail]"

   where 'SMTPGW' is the DECnet node name of the machine running the
   RFC822 to Mail-11 gateway.

6.4.2. Mail-11 --> RFC822 --> X.400

   Some of the possible mapping described in section 6.3 apply to the
   Mail-11 address, hiding completely its origin. The RFC1327 apply on
   the last step.

   an example:

      RELAY::MYNODE::BETTY

   could map into RFC822 as

      [e-mail]

   and accordingly to RFC1327

      C=it; A=garr; P=dom1; O=gw1; OU=RELAY; S=BETTY(p)MYNODE;

   where 'dnet.gw1.it' is the domain of the machine running the Mail-11
   to RFC822 gateway.

6.4.3. X.400 --> Mail-11 --> RFC822

   The X.400 address is stored into Mail-11 'f-address' element as
   described in sections 5.3 and 5.4; then if the Mail-11 to RFC822
   gateway is able to understand the presence of a 'x400-text-address'
   into the Mail-11 address, then it applies RFC1327 to it, and encodes
   header. Otherwise it applies the rules described in 6.3

   an example:

     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"

   If the Mail-11 to RFC822 gateway recognise the x400-text-address,
   then the address becomes, accordingly to RFC1327

     [e-mail]



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


   and the following RFC822 header line is added

     Received: from X4TDEC with DECnet (Mail-11) on xx-xxx-xxxx.

   Otherwise one of the dumb rules could produce

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

6.4.4. RFC822 --> Mail-11 --> X.400

   The RFC822 address is encoded in Mail-11 f-address element as
   described in sect. 6.2; then if the Mail-11 to X.400 gateway is able
   to understand the presence of an 'RFC822-address' into the Mail-11
   address, then it applies RFC1327 to it, and encodes 'route' and
   applies the rules described in 5.2 and 5.5.

   an example:

      [e-mail]

   will be encoded like

      SMTPGW::In%"[e-mail]"

   If the Mail-11 to X.400 gateway recognise the RFC822-address, then
   the address becomes, accordingly to RFC1327

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

   and a 'trace' record is added into the X.400 P1 data, stating that a
   node named SMTPGW was crossed.

   Otherwise dumb rule produces

      C=it; ADMD=garr; DD.Dnet=HEP;
      DD.Mail-11=SMTPGW::In(p)(q)Jim.Clay(a)cs.UCL.AC.UK(q)

6.4.5. RFC822 --> X.400 --> Mail-11

   We apply RFC1327 to the first conversion, obtaining an X.400 address.
   Then the rules described in sections 5.3 and 5.4 are used to store
   the X.400 address as 'x400-text-address' into the Mail-11

   an example:

      [e-mail]

   maps accordingly to RFC1327 to



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


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

   and finally becomes

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

   where 'SMTPGW' is the DECnet node name of the machine running the
   X.400 to Mail-11 gateway.

6.4.6. Mail-11 --> X.400 --> RFC822

   The Mail-11 address is encoded as specified in sections 5.2 and 5.5;
   then RFC1327 is used to convert the address in RFC822.

   an example:

      RELAY::MYNODE::BETTY

   maps into X.400 as

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

   and accordingly to RFC1327

      "/C=it/A=garr/DD.Dnet=HEP/DD.Mail-11=RELAY::MYNODE::BETTY"@gw2.it

   where 'gw2.it' is the domain of the machine running the RFC1327
   gateway.

Appendix A Mail-11 - RFC822 mapping

A.1 Introduction

   The implementation of a Mail-11 - RFC822 gateway was faced by many
   software developers independently, and was included in many mail
   products which were running on both VAX/VMS and UNIX systems. As
   there was not a unique standard mapping way, the implementations
   resulted into a number of possible variant methods to map a Mail-11
   address into an RFC822 one. Some of these products became then
   largely widespread, starting to create a number of de facto mapping
   methods.

   In this small appendix some sort of standardisation of the mapping
   problem is considered, trying to be compatible with the existing
   installed software. We must also remind that, in some cases, only
   simple Mail-11 addresses could be mapped into RFC822, having complex
   ones producing all sort of quite strange results.




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


   On the other hand, the mapping of an RFC822 address in Mail-11 was
   quite straightforward, resulting in a common definition which uses
   "Mail-11 foreign mail protocol" to design an RFC822 address:

      [[node::][node::]...]prot%"rfc-822-address"

   or

      [node::][node::]...]::"rfc-822-address"

A.2 De facto implementations

   A considerable number of de-facto implementations of Mail-11/RFC822
   gateways is existing. As said in the introduction, the mapping of
   RFC822 addresses in Mail-11 is accomplished using the foreign mail
   protocol syntax and is thus unique.

   On the other hand, Mail-11 addresses are encoded in RFC822 syntax in
   various ways. Here are the most common ones:

        a) "node::user"@gateway-address
        b) user%node@gateway-address
        c) [e-mail]
        d) user%node.dnet@gateway-address

   Let's have a quick look to these different choices.

   a - This form simply encloses as quoted Left Hand Side string the
       original Mail-11 address into the RFC822 address of the
       Mail-11/RFC822 gateway. This method is fully conformant with
       RFC822 syntax, and the Mail-11 address is left untouched; thus
       no encoding rules need to applied to it.

   b - As one will immediately notice, this form has nothing in it
       indicating the address is a Mail-11 one; this makes the encoding
       indistinguishable from a similar encoding of RSCS (BITnet)
       addresses used by some IBM VM Mailer systems. It should thus be
       deprecated.

   c - In this case a sort of 'reserved word' (decnet)  embedded into
       the address itself identifies the presence of a Mail-11 original
       address preceding it. The decoding is possible, dropping
       'domains' and extracting 'user' and 'node' parts. However complex
       Mail-11 addresses cannot be mapped properly in this syntax, and
       there is no specific rule for adding the 'domains' part of the
       address.





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


   d - In this case again there is a 'reserved word' (dnet)  which make
       possible the identification of the original Mail-11 address;
       'gateway-address' points to the Mail-11/RFC822 gateway and 'node'
       and 'user' information can be easily drawn from the address.
       However complex Mail-11 addresses cannot be embedded easily into
       this syntax.

A.3 Recommended mappings

   From the examples seen in the previous paragraphs we can derive a
   canonical form for representing the mapping between Mail-11 and
   RFC822.

A3.1 RFC822 mapped in Mail-11

   The mapping of an RFC822 address in Mail-11 is straightforward, using
   the "Mail-11 foreign mail protocol" syntax. The two possible variants
   are:

      [[node::][node::]...]prot%"rfc-822-address"

   or

      [node::][node::]...]::"rfc-822-address"

A3.2 Mail-11 mapped in RFC822

   RFC822 foresee a canonical form for representing non-RFC822
   addresses: put the foreign address in local part (Left Hand Side,
   LHS) is a form as similar as possible to its original syntax. Thus
   the suggested mapping is:

      "Mail-11-address"@gateway-address

   This format assures also the return path via the appropriate gateway.

A.4 Conclusions

   A standard way of mapping Mail-11 addresses into RFC822 and vice
   versa is feasible. A suggestion is thus made to unify all existing
   and future implementations. It should be noted, however, that there
   is no way to specify in these mappings the name of the decnet
   community owning the encoded address, as it was done for X.400, thus
   the implementation of the 'intelligent' gateway in this case is
   impossible.






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


Acknowledgements

   I wish to thank all those people who read the first draft and
   contributed a lot with their useful suggestions to the revision of
   this document, in particular RARE WG1 and IETF X.400 ops group
   members and S. Hardcastle-Kille.

References

   [1]  CCITT, "CCITT Recommendations X.400-X.430", Message Handling
        Systems: Red Book, October 1984.

   [2]  CCITT, "CCITT Recommendations X.400-X.420", Message Handling
        Systems: Blue Book, November 1988.

   [3]  Crocker, D., "Standard of the Format of ARPA Internet Text
        Messages", STD 11, RFC 822, UDel, August 1982.

   [4]  Kille, S., "Mapping Between X.400 and RFC 822", UK Academic
        Community Report (MG.19) / RFC 987, June 1986.

   [5]  Kille, S., "Mapping Between X.400(1988) / ISO 10021 and RFC
        822", RFC 1327, March 1992.

   [6]  Digital Equipment Corp.;, "VAX/VMS Mail Utility".

   [7]  Joiner Associates Inc., "Jnet User's Manual".

   [8]  PMDF User's Guide.

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   Claudio Allocchio
   Cosine S2.2
   Sincrotrone Trieste
   Area di Ricerca
   Padriciano 99
   I 34012 Trieste
   Italy

   Phone:   [phone]
   Fax:     [phone]
   EMail:  [e-mail]
           C=it; A=garr; P=Trieste; O=Elettra; S=Allocchio; G=Claudio;



Allocchio                                                      [Page 19]