Dennis Davis wrote:
> Exim won't advertise SMTP service extensions -- SIZE, 8BITMIME,
> PIPELINING, STARTTLS, HELP, AUTH, etc -- in response to an HELO
> greeting[1]. Any subsequent attempt by the client to offer AUTH
> should be rejected.
[ cut ]
> [1] I strongly suspect that this is because HELO handling is still
> governed by RFC 821 which didn't know anything about SMTP
> service extensions.
No need to suspect, that's exactly the case. HELO starts an SMTP
session. EHLO starts an ESMTP session. AUTH is an ESMTP service
extension, and is invalid under a standard SMTP session. Hence it is
impossible, with an RFC-compliant server such as Exim, to have an
authenticated session that started with HELO:
220 krellis.org ESMTP Exim 4.63 Thu, 26 Oct 2006 10:56:34 -0400
HELO there
250 krellis.org Hello c-24-7-159-110.hsd1.ca.comcast.net [24.7.159.110]
AUTH PLAIN sldkfjsdfksdf
503 AUTH command used when not advertised
I would have to agree with Philip and the others on this thread, I don't
exactly understand why one would want to block HELO itself, and this
would be an RFC violation if done on a public mail server. If it's
being done on a private system where the OP can be sure that the only
servers that (legitimately) connect will be able to speak ESMTP and
start with EHLO, they can block HELO in the HELO ACL, it just seems
somewhat pointless.
Regards,
Tim
