Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!yale!decvax!ucbvax!SPAM.ISTC.SRI.COM!gds
From: gds@SPAM.ISTC.SRI.COM (The lost Bostonian)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: SMTP, 2600, and the security of mail
Message-ID: <8609301729.AA22542@spam.istc.sri.com>
Date: Tue, 30-Sep-86 13:29:00 EDT
Article-I.D.: spam.8609301729.AA22542
Posted: Tue Sep 30 13:29:00 1986
Date-Received: Fri, 3-Oct-86 05:32:27 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 25
Approved: tcp-ip@sri-nic.arpa

> 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