rfc976.txt

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

RFC 976                                                    February 1986
UUCP Mail Interchange Format Standard


             and bang paths

                  rmail host1!host2!user

             but we assume nothing more about the host.  If we have
             no information about a host, we can treat it as class 1
             with no problems, since we make no assumptions about
             how it will handle hybrid addresses.

   Class 2   Old style UUCP ! routing, and 4.2BSD style domain
             parsing.  We assume the capabilities of class 1, plus
             the ability to understand

                  rmail user@domain

             if the "domain" is one outside the UUCP zone which
             the host knows about.  Class 2 hosts do not necessarily
             understand domain!user or have routers.  Hosts in non-

             UUCP RFC-920 domains are considered class 2, even though
             they may not understand host!user.

   Class 3   All class 1 and 2 features are present.  In addition,
             class 3 hosts must be able to route UUCP mail for hosts
             that are not immediately adjacent and also understand
             the syntax

                  rmail domain!user

             as described above.  All gateways into UUCP must be
             class 3.

   This document describes what class 3 hosts must be able to process.
   Classes 1 and 2 already exist, and will continue to exist for a long
   time, but are viewed as "older systems" that may eventually be
   upgraded to class 3 status.

3.  Algorithm

   The algorithm for delivering a message to an address "user@domain"
   over UUCP links can be summarized as follows:

      a.  If the address is actually of the form @domain1:user@domain2,
          the "domain" used for the remainder should be "domain1"
          instead of "domain2", and the bang form reads
          domain1!domain2!user.



Horton                                                          [Page 7]



RFC 976                                                    February 1986
UUCP Mail Interchange Format Standard


      b.  Determine d: the most specific part of "domain" that is
          recognized locally.  This part will be a suffix of "domain".
          This can be done by scanning through a table with entries that
          go from specific to general, comparing entries with "domain"
          to see if the entries are at the tail of "domain".  For
          example, with the address "[e-mail]", if the local
          host recognizes "uucp" and "att.com", d would be "att.com".
          The final entry in the table will be the null string, matching
          any completely unrecognized domain.

      c.  Look in the found table entry for g: the name of the
          "gateway", and for r: a UUCP !-style route to reach g.  G is
          not necessarily directly connected to the local host, but
          should be viewed as a gateway into the d domain.  (The values
          of g and r for a given d may be different on different hosts,
          although g will often be the same.)

      d.  Look at the beginning of r to find the "next hop" host n. N
          will always be directly connected to the local host.

      e.  Determine, if possible, the class of g and n.

      f.  Create an appropriate destination string s to be interpreted
          by n.  (See below.)

      g.  Pass the message off to n with destination information s.

      In an environment with other types of networks that do not use
      UUCP !  parsing, the table will probably contain additional
      information, such as which type of link to use.  The path
      information may be replaced in other environments by information
      specific to the network.

      The first entries in the table mentioned in part (b) are normally
      very specific, and allow well known routes to be constructed
      directly instead of routing through the domain tree.  The domain
      tree should be reserved for cases where no better information is
      available, or where traffic is very light, or where the default
      route is the best available.  If a better route is available, that
      information can be put in the table.  If a host has any
      significant amount of traffic sent to a second host, it is
      normally expected that the two hosts will set up a direct UUCP
      link and make an entry in their tables to send mail directly, even
      if they are in separate domains.  Routing tables should be
      constructed to try to keep paths short and inexpensive for as much
      traffic as possible.



Horton                                                          [Page 8]



RFC 976                                                    February 1986
UUCP Mail Interchange Format Standard


      Here are some hints for the construction of the destination string
      n (step f above.) The "envelope recipient" information (the
      argument(s) to rmail) may be in either domain ! form
      (host.com!user) or domain @ form ([e-mail]) as long as the
      sending site is sure the next hop is class 3.  If the next hop is
      not class 3, or the sending site is not sure, the ! form should be
      used, if possible, since it is hard to predict what the next hop
      would do with a hybrid address.

      If the gateway is known to be class 3, domain ! form may be used,
      but if the sending site is not sure, and the entire destination
      string was matched in the lookup (rather than some parent domain),
      the 6 letter ! form should be used: r!user, for example:
      dumbhost!host!user.  If the gateway appears to actually be a
      gateway for a subdomain, e.g. because a parent domain was matched,
      (such as the address [e-mail], where host.gateway.com
      was not found but gateway.com was) it can be assumed to be at
      class 3.  This allows routes such as
      dumbhost!domain!host.domain.com!user to be used with a reasonable
      degree of safety.  If a direct link exists to the destination
      host, the user@domain syntax or the domain!user syntax may be
      used.

      All hosts conforming to this standard are class 3, and all
      subdomain gateways must be class 3 hosts.

4.  Example

   Suppose host A.D.COM sends mail to host C.D.COM.  Let's suppose that
   the 6 letter names for these hosts are aname and dname, and that the
   intermediate host to be routed through has name bname.

   The user on A types

      mail [e-mail]

   The user interface creates a file such as

      Date:  9 Jan 1985   8:39 EST
      From: [e-mail] (My Name)
      Subject: sample message
      To: [e-mail]

      This is a sample message

   and passes it to the transport mechanism with a command such as



Horton                                                          [Page 9]



RFC 976                                                    February 1986
UUCP Mail Interchange Format Standard


      sendmail [e-mail] < file

   The transport mechanism looks up a route to c.d.com.  It does not
   find c.d.com in its database, so it looks up d.com, and finds that
   the path is bname!dname!%s, and that c.d.com is a class 3 host.
   Plugging in c.d.com!user, it gets the path bname!dname!c.d.com!user.
   (If it had found c.d.com with path bname!cname!%s, it would have
   omitted the domain from the resulting path: bname!cname!user, since
   it is not sure whether the destination host is class 1, 2, or 3.)

   It prepends a From_ line and passes it to uux:

      uux - bname!rmail dname!c.d.com!user < file2

   where file2 contains

      From A.D.COM!user Wed Jan  9 12:43:35 1985 remote from aname Date:
      9 Jan 1985   8:39 EST
      From: [e-mail] (My Name)
      Subject: sample message
      To: [e-mail]

      This is a sample message

   (Note the blank line at the end of the message - at least one blank
   line is required.) This results in the command

      rmail dname!c.d.com!user

   running on B.  B prepends its own from line and passes the mail
   along:

      uux - dname!rmail c.d.com!user < file3

   where file3 contains

      From nuucp Wed Jan  9 12:43:35 1985 remote from bname >From
      A.D.COM!user Wed Jan  9 11:21:48 1985 remote from aname Date:  9
      Jan 1985   8:39 EST
      From: [e-mail] (My Name)
      Subject: sample message
      To: [e-mail]

      This is a sample message





Horton                                                         [Page 10]



RFC 976                                                    February 1986
UUCP Mail Interchange Format Standard


   The command

      rmail c.d.com!user

   is run on C, which stacks the From_ lines

      From bname!aname!A.D.COM!user Wed Jan  9 12:43:35 1985 Date:  9
      Jan 1985   8:39 EST
      From: [e-mail] (My Name)
      Subject: sample message
      To: [e-mail]

      This is a sample message

   and stores the message locally, probably in this same format.

5.  Summary

   Hosts conforming to this standard should accept all of the following
   forms:

      rmail localuser               (no !%@ in user)
      rmail hosta!hostb!user        (no !%@ in user)
      rmail user@domain             (only . in domain)
      rmail domain!user             (at least 1 . in domain)
      rmail domain.!user            (in case domain has no dots)

   The "envelope" portion of the message ("From_" lines) should conform
   to existing conventions, using ! routing.  The "heading" portion of
   the message (the Word: lines such as Date:, From:, To:, and Subject:)
   must conform to RFC-822.  All header addresses must be in the @ form.
   The originating site should ensure that the addresses conform to
   RFC-822, since no requirement is placed on forwarding sites or
   gateways to transform addresses into legal RFC-822 format.  (Such
   forwarding sites and gateways should NOT, however, change a legal
   RFC-822 address such as user@domain into an illegal RFC-822 address
   such as gateway!user@domain, even if forwarding to a class 1 UUCP
   host.)

6.  References

   [1]  Postel, J., "Simple Mail Transfer Protocol", RFC-821,
        USC/Information Sciences Institute, August, 1982.

   [2]  Crocker, D., "Standard for the Format of ARPA Internet Text
        Messages", RFC-822, Department of Electrical Engineering,
        University of Delaware, August, 1982.


Horton                                                         [Page 11]



RFC 976                                                    February 1986
UUCP Mail Interchange Format Standard


   [3]  Postel, J., and J. K. Reynolds, "Domain Requirements", RFC-920,
        USC/Information Sciences Institute, October, 1984.















































Horton                                                         [Page 12]