OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: HELO HELO
From: Lawrence Greenfield (leg+andrew.cmu.edu)
Date: Tue Oct 03 2000 - 11:01:00 CDT

One exception to this is RFC2487, STARTTLS, and RFC2554, SMTP AUTH.
After a client negotiates a security or integrity layer, the client
reissues EHLO. I suspect many clients which support AUTH layers will
reissue EHLO after a successful AUTH regardless of whether a layer was
negotiated.

Larry

   Date: Tue, 3 Oct 2000 17:07:33 +0200
   From: Brad Knowles <blkskynet.be>

   At 4:38 PM +0200 2000/10/3, Brad Knowles wrote:

> At 8:05 PM +0200 2000/10/1, Rask Ingemann Lambertsen wrote:
>
>> It is perfectly OK by the RFC's to issue any number of HELO commands.
>
> You know, I'm wondering about this. Reading through RFC 821,
> this does not appear to be the case. The state transition diagram
> in section 4.4 (page 39) seems to contradict this claim -- from the
> beginning state, there is only one possible path for a variety of
> commands (listed as "HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY,
> EXPN, HELP, NOOP, QUIT, TURN", and there aren't any loops. Therefore,
> according to RFC 821, multiple HELO commands is definitely not
> within the specification.

           Checking RFC 1123, it doesn't mention anything new about state
   transitions for HELO, just places some further restrictions on the
   information to be conveyed with this command, and what can/cannot be
   done with that information.

           Checking RFC 1869 (which introduces EHLO), it simply says that
   EHLO can be used everywhere HELO can, and section 4.2 specifically
   says:

   | 4.2. Command syntax
   |
   | The syntax for this command, using the ABNF notation of [2],
   | is:
   |
   | ehlo-cmd ::= "EHLO" SP domain CR LF
   |
   | If successful, the server SMTP responds with code 250. On
   | failure, the server SMTP responds with code 550. On error,
   | the server SMTP responds with one of codes 500, 501, 502,
   | 504, or 421.
   |
   | This command is issued instead of the HELO command, and may
   | be issued at any time that a HELO command would be
   | appropriate. That is, if the EHLO command is issued, and a
   | successful response is returned, then a subsequent HELO or
   | EHLO command will result in the server SMTP replying with
   | code 503. A client SMTP must not cache any information
   | returned if the EHLO command succeeds. That is, a client SMTP
   | must issue the EHLO command at the start of each SMTP session
   | if information about extended facilities is needed.

           In other words, multiple "HELO" or "EHLO" is explicitly *NOT* okay.

           Reading <http://www.imc.org/draft-ietf-drums-smtpupd>, I note
   that in the ninth paragraph of section 4.5.4.1, there is an oblique
   reference to multiple EHLO commands in a single session, but it is
   talking about being careful about caching negative response
   information, and gives me the appearance that they may have
   accidentally written EHLO in a context where they actually meant to
   write MAIL From: (see the last sentence of this paragraph).

           This is the only reference I can find in this document that
   appears to address anything relative to the use of multiple EHLO or
   HELO commands in the same session.

           Contrariwise, I found discussion of the RSET command as being
   logically the same as an EHLO or HELO, but which avoids the issue of
   re-supplying all that information and going through the validation
   procedure that may be associated with that, once this has been done
   once on the connection.

           So far, everything I read leads me to believe that multiple
   HELO/EHLO is not allowed by the RFCs (or the upcoming drafts).

   --
      These are my opinions -- not to be taken as official Skynet policy
   ======================================================================
   Brad Knowles, <blkskynet.be> || Belgacom Skynet SA/NV
   Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124
   Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels
   http://www.skynet.be || Belgium

   "They that can give up essential liberty to obtain a little temporary
   safety deserve neither liberty nor safety."
        -Benjamin Franklin, Historical Review of Pennsylvania.