Re: [exim] Re(2): Forbid HELO

On 10/26/06 4:16 AM, "Bill Hacker (by way of Bill Hacker
<wbh@???>)" <wbh@???> wrote:

> Might not a calling host first HELO and invoke the list of 'advertised'
> services,
The only service at this point is SMTP.

> and only then use an EHLO if such were 'advertised', ELSE not?

EHLO isn't advertised; the connection banner might include "ESMTP" if esmtp
is supported but it is expected that an EHLO will simply be tried if the
connecting thing wants to use esmtp extensions, and fall back to HELO if the
EHLO is rejected.

Part of 3.2 from RFC 2821:

Older SMTP systems which are unable to
support service extensions and contemporary clients which do not
require service extensions in the mail session being initiated, MAY
use HELO instead of EHLO. Servers MUST NOT return the extended
EHLO-style response to a HELO command. For a particular connection
attempt, if the server returns a "command not recognized" response to
EHLO, the client SHOULD be able to fall back and send HELO.

I hadn't remembered the part about modern clients that don't care about the
extensions, but it makes sense. I don't know whether there are any that
matter to the OP.

<Stream of consciousness>
And I had never known about the possible 554 code in the banner (part of
2821 3.1), and the resulting sequence in which anything but QUIT produces
503 bad sequence of commands and the server must wait for the QUIT. I
wonder why a server would be written to do that? "I'm not going to talk to
you but I'm going to waste our resources until you give up properly."
</stream>

--John


--John