[ On Friday, September 27, 2002 at 14:11:58 (-0400), Greg Ward wrote: ]
> Subject: Re: [Exim] Duplicate HELO/EHLO
>
> On 27 September 2002, David Chait said:
> > I am starting to see this on occasion, which results in legitimate mail
> > being bounced, has anyone else run across this, and if so how do I get
> > around it? Exim 4.x on RH 7.3
> >
> > host amdext.amd.com [139.95.251.1]: 503 amdext.amd.com Duplicate HELO/EHLO
>
> That's weird. As I understand it, you're allowed to say HELO or EHLO as
> many times as you like, and the server should just reset itself each
> time.
Yes, that's right. RFC 821 says:
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
However it also says:
A mail
transaction may be aborted by the RSET command.
Which implies by ommission that when you're in in the middle of a
transaction you have to RSET before you can say HELO again.
In the end though RFC 821 says:
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.
which all but says explicitly that any pending incomplete transaction is
aborted by another HELO, just as if RSET had been sent first.
RFC 2821 agrees that multiple greetings are allowed by saying:
4.1.4 Order of Commands
There are restrictions on the order in which these commands may be
used.
A session that will contain mail transactions MUST first be
initialized by the use of the EHLO command. An SMTP server SHOULD
accept commands for non-mail transactions (e.g., VRFY or EXPN)
without this initialization.
An EHLO command MAY be issued by a client later in the session. If
it is issued after the session begins, the SMTP server MUST clear all
buffers and reset the state exactly as if a RSET command had been
issued. In other words, the sequence of RSET followed immediately by
EHLO is redundant, but not harmful other than in the performance cost
of executing unnecessary commands.
which also says fairly clearly that an RSET is not necessary before
another EHLO, even if a mail transaction is open (elsewhere 2821 also
says RSET aborts any incomplete transaction).
I should note that in Smail a second greeting command is not itself
alone sufficient to restore state after a previous greeting attempt has
been rejected (eg. due to a DNSRBL or any of the other administrative
access control lists), with the premise being that if you've been told
to bugger off and bounce the message after sending your greeting then
you've got no business sending any more commands of any kind except
QUIT, and especially not another greeting. However in the about-to-be-
released Smail code I've allowed an RSET command to fully restore state
as a compromise since this makes testing by a human user a little easier
(you don't have to disconnect and reconnect if you make a mistake in the
greeting, or if you're testing the rejection mechanism, etc.).
--
Greg A. Woods
+1 416 218-0098; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
