At 10:33 -0400 on 03/31/2007, John C Klensin wrote about Submit and
HELO (was: Re: RFC2821bis-01 Issue 3: EHLO param:
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.
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
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
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"
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
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.