Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!SPAM.ISTC.SRI.COM!gds
From: gds@SPAM.ISTC.SRI.COM.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Tcp/Ip vs a store & forward network
Message-ID: <8704031825.AA11868@spam.istc.sri.com>
Date: Fri, 3-Apr-87 13:45:11 EST
Article-I.D.: spam.8704031825.AA11868
Posted: Fri Apr  3 13:45:11 1987
Date-Received: Sun, 5-Apr-87 04:46:16 EST
References: <8704030246.AA02484@gwen.cs.purdue.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 35
Approved: tcp-ip@sri-nic.arpa


     There is still a hole with current TCP mailers in that often mail
     really travels an extra hop. That is, mail for janedoe@somewhere.edu
     gets sent to the machine at "somewhere.edu", which after accepting the
     mail, turns around and forwards it the machine the user reads mail on.
     I would prefer an acknowledgement that mail has actually been placed
     in the users mailbox, rather than just handing the mail to a
     "reliable" delivering agent at the site.

Like the gentleman from rice said, you don't always know when mail is
placed in the user's mailbox.  It may be a post-office type system,
where mail is read from a mail server, but composed from the mail
client.  Everything is done without forwarding.  When do you decide that
the mail is in the mailbox?

     Domain names were designed to handle lots more than just machine name
     to IP address mappings. At some point, it will (hopefully) be possible
     to register mailboxes in the system. That way, mail sent to
     janedoe@somewhere.edu will not necessarily mean sending the mail to
     "somewhere.edu". Rather, sendmail will find the real agent via
     nameserver queries about "janedoe@somewhere.edu".  Now mail gets sent
     directly to the machine where the user's mailbox resides, and now when
     the mail is no longer in the sender's local queue, it really is in the
     correct mailbox, and not still in transit somewhere.

It still might be in transit somewhere -- the mailbox entries may point
to non-Internet sites which will require at least an extra hop at a mail
bridge.

Does this "ack" scheme imply retransmission of a mail message until a
retransmission timeout?  I would hate to see those old "Message queued
for 3 days -- will try again for another 12 days" messages from mailers
coming to my mailbox again.

--gregbo