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
pgppSMBGYqOQP.pgp
Description: Signature numérique PGP
-- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
