Subject: RE: Blast from the past

From: vint cerf <[email-masked]>
Date: Thu, 25 Jan 2001 22:21:43 -0500

we never actually did this though

vint

At 05:52 PM 1/25/2001 -0800, Peter Ford wrote:

>Ah, dual stacks, a time tested transition strategy.  But there was some Application Layer Gateway cruft (ALG) although not at the level of sophistication and beauty of a NAT ...
>
>From RFC 801: 
>
>Because all hosts can not be converted to TCP simultaneously, and 
>   some will implement only IP/TCP, it will be necessary to provide 
>   temporarily for communication between NCP-only hosts and TCP-only 
>   hosts.  To do this certain hosts which implement both NCP and IP/TCP 
>   will be designated as relay hosts.  These relay hosts will support 
>   Telnet, FTP, and Mail services on both NCP and TCP.  These relay 
>   services will be provided  beginning in November 1981, and will be 
>   fully in place in January 1982. 
>
>   Initially there will be many NCP-only hosts and a few TCP-only hosts, 
>   and the load on the relay hosts will be relatively light.  As time 
>   goes by, and the conversion progresses, there will be more TCP 
>   capable hosts, and fewer NCP-only hosts, plus new TCP-only hosts. 
>   But, presumably most hosts that are now NCP-only will implement 
>   IP/TCP in addition to their NCP and become "dual protocol" hosts. 
>   So, while the load on the relay hosts will rise, it will not be a 
>   substantial portion of the total traffic.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 25 Jan 2001 20:33:23 -0800

>we never actually did this though

except for email...

> >Ah, dual stacks, a time tested transition strategy.  But there was some 
> Application Layer Gateway cruft (ALG) although not at the level of 
> sophistication and beauty of a NAT ...

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464

---

From: vint cerf <[email-masked]>
Date: Thu, 25 Jan 2001 23:41:26 -0500

my recollection is that we did very little email conversion - but
maybe I am thinking just about ftp?

vint

---

From: Alan Bawden <[email-masked]>
Date: Thu, 25 Jan 2001 23:44:48 -0500 (EST)

Date: Thu, 25 Jan 2001 20:33:23 -0800
   From: Dave Crocker <[email-masked]>
   Cc: Peter Ford <[email-masked]>, Bob Braden <[email-masked]>,
	   [email-masked], [email-masked], [email-masked],
	   [email-masked], [email-masked], [email-masked]

   except for email...

Will you people -please- stop CC'ing [email-masked] with this
conversation?  Please?  Pretty please?

---

From: Dave Crocker <[email-masked]>
Date: Thu, 25 Jan 2001 21:41:19 -0800

>maybe I am thinking just about ftp?

well, you gave udel an arpa contract to do an ncp/tcp email gateway.

but, then, I didn't stay around to implement it myself...

somebody convinced me to work on developing a separate email service.

d/

=-=-=-=-=

---

From: John C Klensin <[email-masked]>
Date: Fri, 26 Jan 2001 15:14:50 -0500

--On Thursday, 25 January, 2001 23:41 -0500 vint cerf
<[email-masked]> wrote:

> my recollection is that we did very little email conversion -
> but maybe I am thinking just about ftp?

With FTP, the mail was delivered more or less into the space of
the receiving user.  So any conversations that were done (and I
can't remember much, if anything) would have needed to be done in
what we would now call the receiving MUA -- there really was no
_mail_ transport process.

I don't recall any application-level conversions between
NCP-based mail transport and the TCP-based.  Note that SMTP was
designed to run transparently over either and that RFC 821
contains sections that explain how to interpret the standard in
the two (and other) environments.

Where we did have a good deal of mail conversion action was at
less-well-designed transport boundaries or systems.  E.g.,
BITNET-Internet was a relatively big deal, and CSNet-Internet and
UUCP Mail-Internet were presumably also significant.

     john

---

From: Dave Crocker <[email-masked]>
Date: Sat, 27 Jan 2001 06:26:35 -0600

>_mail_ transport process.

architecturally, the MAIL commands within FTP were identical to SMTP.  They 
were an email transport protocol.

Both delivermail/Sendmail and MMDF were alive an kicking before 
RFC821.  The introduction of SMTP did not alter the roles or basic system 
processing of either of these applications.  It just added one more 
transport protocol to their set.  That is, however we would characterize 
their behaviors now, such as distinguishing activities within the MUA 
versus elsewhere -- it was the same before SMTP.

There were other email processes that worked the same way, but the only one 
I know any details about was the MMDF predecessor that we did at Rand in 
1978.  My impression is that the Multics NCP email software had a similar 
architecture.

d/

=-=-=-=-=

---

From: John C Klensin <[email-masked]>
Date: Sat, 27 Jan 2001 13:59:37 -0500

My apologies -- I should have been more precise about chronology.
When we _first_ did mail-over-FTP, the norm was to deliver more
or less directly into the user's file system.  The notion of
"spooling" or "mail store" mail-receiving processes came later --
in the Multics case, not much later, as it became clear that
direct-to-user-space delivery raised some security issues that no
one was happy about-- but well before SMTP.

So Dave, and his chronology, are quite correct.

     john

--On Saturday, 27 January, 2001 06:26 -0600 Dave Crocker
<[email-masked]> wrote:

>> can't remember much, if anything) would have needed to be done
>> in what we would now call the receiving MUA -- there really
>> was no _mail_ transport process.
> 
> architecturally, the MAIL commands within FTP were identical to
> SMTP.  They were an email transport protocol.
> 
> RFC821.  The introduction of SMTP did not alter the roles or
> basic system processing of either of these applications.  It
> just added one more transport protocol to their set.  That is,
> however we would characterize their behaviors now, such as
> distinguishing activities within the MUA versus elsewhere -- it
> was the same before SMTP.
> 
> There were other email processes that worked the same way, but
> the only one I know any details about was the MMDF predecessor
> that we did at Rand in 1978.  My impression is that the Multics
> NCP email software had a similar architecture.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 30 Jan 2001 00:44:15 -0800

>one was happy about-- but well before SMTP.

Hmmm.  It occurs to me that what you have highlighted is another Internet 
demonstration that scaling imposes more stringent demands.

However this was perhaps one of the earliest examples of social effects -- 
larger communities have less average trustworthiness? -- than technical ones.

d/

---

From: John C Klensin <[email-masked]>
Date: Tue, 30 Jan 2001 08:19:40 -0500

--On Tuesday, 30 January, 2001 00:44 -0800 Dave Crocker
<[email-masked]> wrote:

> Hmmm.  It occurs to me that what you have highlighted is
> another Internet demonstration that scaling imposes more
> stringent demands.

Probably

> However this was perhaps one of the earliest examples of social
> effects -- larger communities have less average
> trustworthiness? -- than technical ones.

I wasn't significantly involved in the decision (Jeff or others
might remember), but keep in mind that Multics had very
significant security features: either mailboxes had to be moved
to an inner ring (which was eventually done) or there needed to
be a spool.  An essentially application process (relatively low
privs as system sorts of things went) really couldn't write into
a user directory in the user ring without either very funny
access or a huge security hole.  

So, while I agree with your conclusion, I suspect the reason for
this particular decision was not social, but system architecture
and, with it, another conclusion we often reach: if the security
model and mechanisms are designed in from the beginning, the
right sorts of things tend to fall into place without horrible
retrofits that almost never quite do the job.

    john