[ih] Design choices in SMTP

[John Klensin]

John,

We are getting toward distinctions here that probably have little to do
with Ralph's question/ request, but, at the risk of a trip down the rabbit
hole...

IIR, the most common user interfaces to FTP were single command line
things: one source, one destination, one file, no ability (or only obscure
ones) to distinguish between ASCII, EBCDIC, and Binary files; file
structures; transmission modes; and so on.  But the protocol did not
require, or even suggest, a command line interface or those restrictions.
There were more capable interfaces (including just running scripts over
Telnet connections).  With one of those interfaces, if I wanted to transmit
more than one message to the same mailbox, I could certainly do that over a
single TCP connection.  Could I transmit separate messages to different
recipients early on?  Don't remember but I don't recall any version of FTP
that supported mail-related commands (MAIL, MLFL, etc.) that would prohibit
using more than one of those commands, with different user parameters, in
the same FTP (Telnet) session.

Of course, in SMTP, it has always been possible to initiate a session, send
a MAIL command and then send several RCPT commands and DATA (one message,
multiple destinations) and equally possible to send a new MAIL command
after a prior mail transaction was completed and start over (multiple
messages to the same destination host (server), potentially with different
origin and/or destination mailboxes).

So I don't see a difference there.  The 1980 version of FTP (RFC 765/ IEN
149) even contains commands that are obvious predecessors of SMTP's SEND,
SAML, and SOML capabilities.  All of that was removed in RFC 959, after the
publication of the SMTP spec.    One could, on that basis, argue that RFC
765-vintage FTP was really ur-SMTP and we need to talk about earlier times,
but that leads to even worse hair-splitting.

Similarly, the file/directory distinction, as I recall, was (and still is)
an implementation decision on the receiver-SMTP side.  Some treated "Append
to mailbox" as "add another block to an archive-like file", others as "put
it into the mailbox's directory".   Even the distinction between
"archive-like file" and "directory" can be a bit fuzzy: most
implementations of "archives" involve a single file that has to be scanned
sequentially to find and identify the individual files.  That can be a big
deal for a mail-reading split UA protocol like IMAP that does considerable
work on the server side.  As soon as one adds an index to the archive-like
file, allowing one to go to a message directly rather than scanning
sequentially from the beginning, the conceptual difference from a directory
largely vanishes even though it may be very significant to the underlying
file system.

In any event, none of those distinctions about how messages are stored are
visible to SMTP (or even RFC 765-vintage FTP).

I'm not even sure your comment about Multics is completely correct.  There
may be people on this list who would remember or we could check with that
list (or I could get motivated to start digging through documentation I
have here, but I don't feel that motivation rising very quickly at the
moment).  Remember that mail was well-established on CTSS considerably
before Multics stabilized enough to support  end users and that the ring
structure allowed controls that were (and are) not available for file
systems that only support (flat) ACLs or equivalent.  So, was Append access
created specifically for mail?  Don't remember but it somehow does not feel
right.

best,
   john




On Tue, Feb 7, 2023 at 8:52 PM John Day <jeanjour at comcast.net> wrote:

> I am fuzzy on all this but was this always the case?
>
> As John points out, mail was originally part of FTP and mailboxes were
> files not directories. If one had multiple pieces of mail to deliver to the
> same mailbox would they have been done individually or all at once?  If so,
> when did delivering mail one at a time start? In SMTP? When mailboxes
> became directories?
>
> (I would also note that Multics was uneasy giving an anonymous user Write
> access to a file so created Append access for use by mail.)
>
> > On Feb 7, 2023, at 12:26, John Klensin via Internet-history <
> internet-history at elists.isoc.org> wrote:
> >
> > Ralph,
> >
> > I was not involved with the original SMTP design and don't remember ever
> > explicitly discussing those choices, but my guess is that the answer
> would
> > involve at least some of the following:
> >
> > * SMTP was designed along the model of FTP, which preceded it as the mail
> > transport mechanism, and that made the command-response model seem
> natural
> >
> > * At the time SMTP was designed, the network backbone and most
> > communications paths to it were running at 56 Kpbs, agonizingly slow by
> > today's standards.  Computers were much slower too.  Especially because
> all
> > of those round trips were within a single TCP session, that might have
> > contributed to exactly your suggestion that the intent was to get an SMTP
> > session that was doomed to fail over as soon as possible, in particular
> > before the payload was transmitted.
> >
> > * Possibly more significant in retrospect than at the time, but a
> > command-response model like  "did I reach the right server?", "are you
> > willing to accept mail from this address?", "is this destination ok?",
> "how
> > about that destination?"  has some privacy advantages over a "here is the
> > envelope and payload, please do the right thing" model, even if the
> latter
> > is supplemented by a footer that has become common in some places. one
> that
> > essentially says "if this message was not really intended for you, please
> > un-read and delete it" .
> >
> > You didn't ask but I hope your discussion noted that, for situations in
> > which minimizing round trips is considered important, the "pipelining"
> > option was introduced in 1995 (RFC 1854, succeeded by RFC 2920).
> >
> >    john
> >
> >
> > On Tue, Feb 7, 2023 at 11:00 AM Ralph Holz via Internet-history <
> > internet-history at elists.isoc.org> wrote:
> >
> >> Hi everyone,
> >>
> >> During a lecture today, the following question came up: SMTP requires
> quite
> >> a few round-trips to deliver an email. Why was this design choice made,
> >> i.e., why does a submitting client not just send everything to the
> server
> >> in one RTT?
> >>
> >> Apart from the client-server philosophy at play, I am wondering if that
> was
> >> because we wanted a receiver to terminate the delivery process as early
> as
> >> possible, i.e., before sending the body, if anything was amiss.
> >>
> >> Does anyone have insights on that or maybe even know a nice write-up? I
> >> checked a few sites that discuss the history of SMTP, but so far no luck
> >> with this aspect.
> >>
> >> Many thanks,
> >> Ralph
> >> --
> >> Internet-history mailing list
> >> Internet-history at elists.isoc.org
> >> https://elists.isoc.org/mailman/listinfo/internet-history
> >>
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
>
>