SMTP and FTP

[KLENSIN@xxxxxxxxxxxxxxx (John C Klensin)]

I want to take seriously, just for a moment or two, a few things that
have been dismissed fairly casually...

Shannon Yeh wrote on Feb 20...
> Why don't we just use FTP to exchange mail, and forget SMTP?

Paul Vixie has also written...
>... a followon to SMTP should put the data into a separate
>TCP connection that has no line boundaries and can thus be written and
>read in large, uninterpreted blocks. ...

And, as part of his lengthy summary on 21 Feb 91, Greg Vaudreuil wrote:
>  If you wany binary transport 1) use ftp or 2) encode it into a
>line-limited mail message.

OK, let's just for a minute, pretend to take this seriously, and assume
someone asked a different question.  That question might be "I want to
send a complex, structured, potentially binary file to someone else,
how should I do it?".  The answer might well be FTP and not MAIL.
Indeed, there is some reverse deja vu about that way to formulate the
question, since the ARPANET went into the electronic mail business via
special FTP verbs.

Now, FTP has provisions to solve problems that we are thrashing around
with in mail.  E.g.,
  -- Binary files are sent, with no difficulties, over eight-bit
connections.
  -- We have good out-of-band facilities for separating the
negotiations from the message.
  -- What is to be sent and received is already negotiated by exchange
of options and preferences, not announced with the potential for an
error response.
  -- There are mechanisms for transmitting structure information,
collections of files that are separate for at least some purposes, etc.

Of course, it has a few disadvantages:
  -- It raises some interesting problems wrt gateways to networks that
don't have a similar model.  There are also no problems with "relay
hosts", since there are no such things.  The latter may be an
advantage; dealing with the former would require being very explicit
about translation of models, not just a few header fields, which would
probably be a good thing too.
  -- There is no provision to send a complex and structured file (or
any other kind of file) without the prior agreement of the recipient.
It is not clear that prohibiting this is a bad idea either.  If it is a
problem, it is easily solved, either by introducing "spool
directories", or "anonymous upload", or by reintroducing something that
works more or less like the MAIL verb worked, back when.

This is *not* a serious proposal that we abandon mail for everything
complex and go to FTP.  It does add another dimension to the "where
does SMTP-extended stop and X.400 start" question, which is--perhaps on
the "other side" of SMTP, "where does SMTP-extended stop and file
transfer begin?"