ietf-smtp
[Top] [All Lists]

Re: Submit and HELO (was: Re: RFC2821bis-01 Issue 3: EHLO parameter)

2007-03-31 14:12:57

At 10:33 -0400 on 03/31/2007, John C Klensin wrote about Submit and HELO (was: Re: RFC2821bis-01 Issue 3: EHLO param:

Robert,

I think this is a Submit issue, rather than an SMTP one, so
don't know quite how to summarize it into an issues that is
2821bis-relevant.   If you disagree, please explain.

   john

Yes I agree that it is mainly a Submit issue BUT since 2821bis says that HELO is a valid way of initiating a SMTP Session (although EHLO is the preferred/suggested method) we have a conflict with Submit's requirement for authentication/authorization and at least a note of this is IMO useful in the HELO section (maybe just noting that HELO is not compatible with Submit and pointing at the Submit RFC for details).

My logic on the existence of a conflict is as follows:

 1) To start a SMTP Session, I issue a HELO or EHLO.
2) To connect to an SMTP Server via Port587 (ie: As a MSA session as opposed to a MTA session - IOW: to inject new mail not just pass along preexistent [in the system] mail) the submitter must be authorized to use the Server. 3) The usual way of proving the authority is to issue a EHLO, parse the resultant 220 reply and select from these replies either the AUTH or a SSL-type [TLS?] keyword and respond using the appropriate command and handshake. 4) Since HELO does not return a 220 list to select from, there is no way to do the authorization via a Command (in fact I do not think that such a command is valid in SMTP as opposed to ESMTP mode even with a ESMTP Server) and some other method is needed such as an OOB pre-authorization based on the IPN address that the submitter is using to do the submit (ex: The case where a SMTP AUTH is not needed if you are coming in via connectivity on the ISP's LAN not from the Internet itself).

I may be cutting some corners with my logic above but I think the major steps in reaching my opinion are there.

My point is that when used with SUBMIT the usual ability to start a session with HELO does not seem to be valid and not noting this restriction in the HELO section is a flaw in the documentation. A long winded explanation is not, I think, needed - Only a statement that a Port587/Submission session needs to be authorized and that use of HELO (as opposed to EHLO) puts the Server into a state where such authorization can not be requested/done.

I apologize for the lecture <g>.




--On Saturday, 31 March, 2007 02:09 -0400 "Robert A. Rosenberg"
<hal9001(_at_)panix(_dot_)com> wrote:


 At 06:25 -0400 on 03/30/2007, Hector Santos wrote about Re:
 RFC2821bis-01 Issue 3: EHLO parameter:

 Right, the irony is that the SUBMIT (port 587) is about strong
 authentication at all levels. Yet, it can provide an "lesser
 of all evils" avenue to help resolve this current issue by
 relaxing any strong EHLO/HELO verification that is increasing
 becoming a wide practice for anonymous transactions under
 port 25

 Raising an issue about EHLO/HELO verification and Port
 587/SUBMIT, I have the impression (possibly erroneous) that
 Port587 use requires a SMTP AUTH handshake. If so, then use of
 HELO on Port587 should IMO be banned (ie: Any attempt to use
 it to start the session should be rejected with an invalid
 command reply) since only EHLO will return the 220 list of
 supported commands - in particular the AUTH that lists the
 acceptable Handshake protocols (PLAIN/LOGON/CRAM-MD5/etc.). If
 I go HELO I am not informed of the valid handshake methods
 even if I can assume the AUTH is supported. I've seen sites
 that ONLY offer CRAM-MD5 (but not PLAIN or LOGON) due to PLAIN
 and LOGON being fake "security by obscurity" that fails to
 protect if the session is being monitored/recorded (both send
 a constant reply that just needs to be unBASE64'ed to see the
 actual USERID/PW Pair).

 NOTE: That comment may fork the discussion and trigger the
 need for a new ISSUE Number. Editor/Monitor, please do a
 > RE:/WAS to issue one if appropriate.