[net.mail.headers] SMTP, 2600, and the security of mail

gds@sri-spam.ARPA (The lost Bostonian) (09/30/86)

> From: Mark Crispin <MRC@SIMTEL20.ARPA>

> The Internet protocols are insecure by nature.  A reasonably suspicious
> host should always record the host name or IP address of the how which
> actually connected to the SMTP server (the real host, not what was
> claimed in a HELO).

If it is true that all IP implementations enable a server program to
determine the IP address of its peer, then the HELO command, and its
response could be eliminated, which would save us a few bytes.
Certainly the response to the HELO is not necessary, since the server
has already identified itself in the opening greeting.

However, I quote from RFC 821, the explanation for HELO:

	This command and an OK reply to it confirm that both the
	sender-SMTP and receiver-SMTP are in the initial state, 
	that is, there is no transaction in progress and all state
	tables and buffes are cleared.

I do not see that there would be a big problem of detecting the initial
state without a HELO.  Other protocols (FTP, NNTP) don't use it.

--gregbo

smb@ucb-vax.ARPA (10/01/86)

It's important to remember that SMTP is used on non-TCP virtual circuits.
For example, some hosts within Bell Labs use it over Datakit(r) VCS connections.
You can't do this nearly as easily with FTP because the semantics of some of
the commands (i.e., PORT and PASSIVE) are intimately tied to TCP and IP.  In
general, though, I regard SMTP as a newer and better protocol than FTP, and
as a better model for other protocols.  The concept of looking for the initial
state is a good one; I've often seen half-open circuits get spliced to due
to software bugs (though not on TCP, of course).