rfc757.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,156 行 · 第 1/3 页

same way that the ITS mail repeater broadcasts messages addressed
to certain mailboxes.)  Special functions might include automatic
hard-copy  creation  or  reply  generation, processing by various
daemons, or any other service found desirable by the host's  user
population  and  administration.    The implementation of fan-out
functions is  up  to  the  local  host,  as  are  any  additional
functions which the user population might wish of its local "mail
room".    Whatever  services  are  available,  the mail room will
distribute the mail to the correct location for each ID.



RFC 757                                            September 1979
Names and Addresses                                        Page 7


2.2.1 Additional delivery options

  It may be desirable to allow mail rooms to accept a username in
place  of  an ID.  Use of a username is a less reliable method of
addressing than use of an ID.

   - A username  may  not  be  sufficiently  unambiguous  for
     getting an ID and host from the network database.

   - Since  a  recipient's  username  may change from time to
     time, there is a chance that the  username  supplied  by
                                  4
     the  sender will be incorrect , or that the host may not
     recognize it.

     Because a recipient's ID  does  not  change  with  time,
     errors  such  as those caused by username changes cannot
     occur if IDs are used.  Similarities or ambiguities  can
     be discovered before delivery occurs, and the sender can
     be prompted for additional identifying information about
     his intended recipient.

   - In  an  even  worse  case,  a correct username can still
     result in an incorrect delivery when it is  paired  with
     an  incorrect  host  or  acted upon by a mail forwarding
             5
     database .

     Because unique IDs are unambiguous, the  possibility  of
     such a situation is eliminated by the use of unique IDs.




_______________
  4
   A particularly insidious source of addressing errors stems
from  the  inconsistent  use of (human) names and initials to
generate  usernames.  The  sender  can   easily   guess   his
recipient's  username incorrectly by using, or failing to use
a combination of initials and last name.    (For  example,  a
user  wishing  to  address  Jim  Miller at BBNA and using the
address "Miller@BBNA"  will  have  his  message  successfully
delivered to Duncan Miller at the same site.)
  5
   The   author  has  observed  a  mail  forwarding  database
redirect messages  correctly  addressed  to  one  JWalker  to
different JWalker at another host.






RFC 757                                            September 1979
Names and Addresses                                        Page 8


2.2.2 Failures

  The case in which the network database is found to be incorrect
has  already been discussed.  It may make sense to mark the entry
as "possibly in error" and to notify both  the  network  database
                6
and the ID owner  when such a situation occurs. In this case mail
delivery  to  the  ID's owner will not occur, but this is not too
bad, considering that that is what happens today when a host does
not recognize a username.

  One additional failure mode, the loss of the  network  database
from  the  net,  must  be considered, even though a well-designed
distributed network database should be robust  enough  to  almost
rule out this possibility.

  If  such  a failure should occur, the local databases should be
able to handle most of the traffic.  What would be  lost  is  the
ability  to  add  new IDs to the network database, the ability to
change hosts for an ID, the ability to  update  local  databases,
and the ability to query the network database.  In essence, there
would be a regression to the state we are in today.

  A  well-administered  network  database  should  be  backed  up
frequently.  Should a catastrophic series  of  hardware  failures
remove  one or more of the network database's hosts from the net,
the database could be moved  elsewhere.    Such  a  change  would
entail  notification  of  all  hosts  on  which  mail originates.
Software which queries the database should be designed to be able
to easily handle such a move.














_______________
  6
   Such notification would presumably  be  by  hardcopy  mail  or
telephone.






RFC 757                                            September 1979
Relationship to TIP Login database                         Page 9


3. Relationship to TIP Login database

  A  number of references to the TIP Login problem and a database
which has been proposed as part of its solution have been made in
this note.  A series of working papers [5] written by Bob Thomas,
Paul Santos, and Jack Haverty describe an approach to TIP  Login.
In  brief,  the method is to build and maintain a distributed TIP
Login database, containing information necessary to allow  a  new
entity  called a "login-host" to decide whether or not to grant a
user access to a given TIP, and whether or not to allow the  user
to make various modifications to the database itself.

  The  TIP  login  database  is derived from a "network user data
base", which contains information above and beyond that necessary
to support TIP login.  This comprehensive database is designed to
support applications other than TIP Login, either directly or  by
means of databases derived from it.

  Contained  in  the  TIP  Login  database  are each user's login
string, a list of TIPs the user  is  authorized  to  access,  the
user's  unique  ID, his password, and any other "permissions" (in
addition to which TIPs may be accessed).  These  permissions  may
indicate  that  the user may create, delete, or modify entries in
the database, to assume other user's roles, and to what extent he
may do so.  The notion  of  permissions  as  developed  by  Steve
Warshall is discussed in an NSW memo [2].

  It  seems entirely reasonable to derive a netmail database from
the same comprehensive database that is designed to  support  TIP
Login.  The concept of a unique ID is supported by that database.
Much  of  the  required  information  for  a  netmail database is
already included, and the maintenance tools necessary  to  modify
it  seem well-suited for the purpose.  The concept of permissions
extends well to the needs of netmail.   Permissions  specific  to
network  mail  might  include, for example, the ability to modify
the delivery host list associated with a given user.

  The  mechanisms  necessary   for   the   maintenance   of   the
comprehensive  network database and its derived databases give us
a netmail database  very  inexpensively.    This  proposal  takes
advantage of that situation.













RFC 757                                            September 1979
Relationship to RFC 753                                   Page 10


4. Relationship to RFC 753

  RFC  753 [4] describes an internetwork message delivery system.
Very briefly, the approach is to  locate  one  or  more  "message
processing  modules"  (or MPMs) on each network.  These MPMs pass
messages across network  boundaries,  and  are  also  capable  of
making  deliveries  to  users on the local network.  The document
also details a proposed message format, along  the  envelope  and
letter  paradigm.    An external "envelope", read by the delivery
system, allows the (unread) message to be  correctly  routed  and
delivered  to  the  proper  recipient.  Groups of messages passed
between a pair of MPMs are sent together in a "mail bag".

  This proposal differs from RFC 753  in  that  it  is  primarily
intended  to  operate  within  a  network  or  a concatenation of
networks using a common host-host protocol, e.g. TCP.  Where  RFC
753   addresses   the   problems  of  internetwork  communication
(differing  message  formats,  complex   routing,   and   correct
identification  of  the proper recipient), this note concentrates
primarily on what can be done within a single protocol.  The  two
are not incompatible.  While a general internetwork protocol must
provide  general  methods  which can be compatible with different
host-host protocols in different networks,  a  proposal  such  as
this  one  can  capitalize  on  the  capabilities, resources, and
policies of a given  catenet  (catenated  network)  such  as  the
ARPAnet/PRnet/SATNET etc.


4.1 Compatibility

  The delivery system described in RFC 753 is compatible with the
system  outlined  here.  Let's examine this for each of the three
basic delivery options performed by the MPM.  (In the  discussion
that  follows, "local networks" means a concatenation of networks
using a common host-host protocol, e.g. TCP.   "Foreign  network"
means  some  network  which  uses a different host-host protocol,
e.g. X.25. (See Figure 4-1.)


4.1.1 Outgoing message


4.1.1.1 RFC 753

  The sender's process hands a message to the local network  MPM.
The message may be destined to an address on the local network or
on  a  foreign network.  In the former case, the MPM performs the
local delivery function (see "Incoming message").  In the  latter
case,  the  MPM  passes the message along to another MPM which is
"closer" to the end user.




RFC 757                                            September 1979
Relationship to RFC 753                                   Page 11




      +---------+  +----------+
      |         |  |          |
      | RCC-NET |  | WIDEBAND |                .......
      |         |  |   NET    |                .     .
      +---------+  |          |                . MPM .
              * *  +----------+                .......
+---------+   * *   *  *   .......                |
|         |   +---------+  .     .           +---------+
| BBN-NET |***|         |__. MPM .  .....    |         |
|         |   | ARPANET |  .......  .   .xxxx| TELENET |
+---------+***|         |***********. G .    |         |
              +---------+***        .....    +---------+
              * *    *  *   **                            .......
       +--------+  +-------+ ***.....    +-------------+  .     .
       |        |  |       |    .   .    |             |--. MPM .
       | SATNET |  | PRNET |    . G .oooo| DIAL-UP NET |  .......
       |        |  |       |    .....    |             |
       +--------+  +-------+             +-------------+




   "Local Nets", TCP based        |    "Foreign Nets", other
 (direct addressing using IP)     |     host-host protocols


*** = TCP   xxx = X.25   ooo = other communications protocol
                        G = gateway



              Figure 4-1: The Internet Environment




4.1.1.2 This proposal

  The  sender's  process  determines the proper host for delivery
given the recipient's unique ID.  If the message is  destined  to
the  local  network, delivery takes place as described earlier in
this proposal.  If the recipient is not local, the message may be
passed to an MPM for foreign delivery.  (A discussion of internet
delivery which does not  presuppose  RFC  753  implementation  is
found later in this note.)

  The  environment  in which the MPM operates does not assume any
knowledge on the part of the local networks about  addressees  on
foreign networks.  Thus there are two possibilities which arise:



RFC 757                                            September 1979
Relationship to RFC 753                                   Page 12


   - The recipient has an ID known to the local networks.

     In  this  case,  the  local  networks supply the RFC 753
     "address".  This can take place in the  local  networks'
     MPM or the user's sending or mail creation process.

   - The recipient is unknown to the local networks.

     Here   the  sender  must  supply  "mailbox"  information
     himself, either explicitly or with  help  of  his  local
     host's database.

  Thus,  outgoing  mail  as  described in this memo is compatible
with RFC 753, with the benefit of reducing the burden on the  MPM
by handling mail deliveries that are local to local networks.


4.1.2 Messages in transit

  Traffic between two MPMs is not affected by this proposal.


4.1.3 Incoming mail

  The MPM on the networks local to the recipient will have access
to  the netmail database, allowing it to translate "mailboxes" to
"addresses".  It can determine the unique ID of the recipient (if
not known), and initiate delivery to that recipient.    Here  RFC
753 and this proposal complement each other very well.

























RFC 757                                            September 1979
Implications of an internetwork message environment       Page 13


5. Implications of an internetwork message environment

  The  scheme described above is based upon the assumption that a
unique identifier can be assigned to each registered recipient of
mail.  Whether or not this uniqueness  can  be  guaranteed  in  a
fairly  unregulated internetwork environment is questionable.  It
is technically feasible, certainly.  The  difficulties  are  more
political, because it is necessary to gain the cooperation of the
administrators  and  user populations of foreign networks.  Let's
assume cooperation, however, and see  what  might  happen  in  an
internet environment.


5.1 Birthplaces

  Each  set  of  local  networks would have its own database, for
ease in access.  It does not seem practical to register  each  ID
in every database, however.  That would be unnecessary, and would
create  access  and  storage  problems  at the network databases.
Here the concept of a "birthplace", or ID origin, may be of use.

  While an ID does not imply where the user is now,  it  can  say