Le jeu 26 oct 2006 16:59:28 CEST, « Tim Wilde » à écrit :
> 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.
I agree too, but I get HELO connection only by spammers, and this
could help me to reject some of spam.
I also don't want that somebody bypass an identity of another using
that method.
> 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.
--
Beber -- Email / Jabber (+GMail) : beber^^meleeweb.net
http://www.meleeweb.net
