Multiple HELO/EHLO?

[Brad Knowles <[e-mail]>]

Folks,

	This question recently came up on the postfix-users mailing list, 
and I was wondering if I could get some clarification here.

	I have reviewed 
<http://www.ietf.org/internet-drafts/draft-ietf-drums-smtpupd-13.txt>, 
and it does not appear to say anything definitive on this subject, 
and in particular appears to actually confuse the issue somewhat.


	Some background.  RFC 821 appears to be contradictory on this 
matter.  In section 4.1.1, on page 19, it says:

          HELLO (HELO)

             This command is used to identify the sender-SMTP to the
             receiver-SMTP.  The argument field contains the host name of
             the sender-SMTP.

             The receiver-SMTP identifies itself to the sender-SMTP in
             the connection greeting reply, and in the response to this
             command.

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

	This doesn't appear to address the issue one way or the other. 
However, on pages 26 & 27, it says (in part):

          TURN (TURN)

             This command specifies that the receiver must either (1)
             send an OK reply and then take on the role of the
             sender-SMTP, or (2) send a refusal reply and retain the role
             of the receiver-SMTP.

			[ ... deletia ... ]

          There are restrictions on the order in which these command may
          be used.

             The first command in a session must be the HELO command.
             The HELO command may be used later in a session as well.  If
             the HELO command argument is not acceptable a 501 failure
             reply must be returned and the receiver-SMTP must stay in
             the same state.

			[ ... deletia ... ]

	Which appears to explicitly allow multiple HELO commands in a 
single session.  Of course, this is the section about TURN and not 
HELO, so one might question how much validity

	However, sections 4.3 and 4.4 (which I won't quote here) appear 
to contradict this claim.  In particular, the state diagram show in 
section 4.4 doesn't have any loops in it, and therefore would appear 
to be a one-way only progression.


	From what I've been able to determine, RFC 1123 doesn't appear to 
help one way or the other on this matter.  However, RFC 1869 appears 
to be pretty clear (section 4.2, pages 3 & 4):

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 particular, the second sentence of the second paragraph of 
section 4.2 from RFC 1869 would seem to directly contradict the quote 
from RFC 821 that would appear to allow multiple HELO/EHLO commands, 
and since this is in the section about EHLO/HELO, and this RFC is a 
recommended standard (#10, according to RFC 2600), this would appear 
to me to take precedence.


	Now, the only section of the current draft that I was able to 
find that appears to address this issue at all is the ninth paragraph 
of section 4.5.4.1:

At the same time, SMTP clients SHOULD use great care in caching
negative responses from servers.  In an extreme case, if EHLO is issued
multiple times during the same SMTP connection, different answers may
be returned by the server. More significantly, 5yz responses to the
MAIL command MUST NOT be cached.

	In this case, it would appear to me that the use of "EHLO" in 
this context may actually have meant to be "MAIL", and this was 
mis-typed.



	Regardless of whether or not it is correct to have multiple 
HELO/EHLO commands in a single session, may I suggest that in the 
first discussion of each command that there be an explicit statement 
about how many times that command may be specified in a single 
session, and how many times it may be specified in a single 
transaction?

	This information may well be elsewhere in the draft, but if it 
is, I was unable to find it.  IMO, specifically mentioning something 
like this where each and every command is described would help to 
reduce confusion on the part of individuals who are writing MTAs, or 
who are attempting to interpret them when discussing certain features 
with MTA authors.


	Thanks!

--
   These are my opinions -- not to be taken as official Skynet policy
======================================================================
Brad Knowles, <[e-mail]>                || Belgacom Skynet SA/NV
Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124
Phone/Fax: [phone]             || 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.