Peter Bowyer wrote:
> On 02/02/07, Alexander Shikoff <minotaur@???> wrote:
> > Hello,
> >
> > To discover some strange issue I've put some additional logging into HELO
> > and RCPT ACLs:
> >
> > acl_check_helo:
> > deny
> > # reject IP-addresses IN HELO/EHLO
> > message = Bad HELO/EHLO
> > condition = ${lookup{$sender_helo_name}nwildlsearch{BL_BAD_HELO}{yes}{no}}
> >
> > acl_check_rcpt:
> > warn
> > logwrite = ---$sender_host_address/$sender_helo_name---
> > [...]
> >
> > After that I got in log:
> >
> > Feb 2 14:31:59 crow exim[39322]: 2007-02-02 14:31:59 H=(201.250.198.147) [201.250.198.147] rejected EHLO or HELO 201.250.198.147: Bad HELO/EHLO
> > Feb 2 14:32:01 crow exim[39322]: 2007-02-02 14:32:01 ---201.250.198.147/---
> > Feb 2 14:32:05 crow exim[39322]: 2007-02-02 14:32:05 H=[201.250.198.147] F=<bjoern.wunderlich@???> rejected RCPT <info@???>: 201.250.198.147 listed by list.dsbl.org
> >
> > Now a riddle: what HELO did remote host send?!
> > Any suggestions?
>
> It sent 201.250.194.147.
>
> Since your HELO ACL rejected the HELO, and the client didn't send
> another one, $sender_helo_name is subsequently blank. A rejection of
> the HELO simply causes the transaction to continue as though no HELO
> had been received.
>
> HELO rejection is generally better done at RCPT time, for this reason
> amongst others.
Of course. There is an alternative of using drop in helo instead of deny.
But there are drawbacks. One useful drop would be if the helo was
"localhost" But that's just my opinion. On my server, I do this and I see
atleast a hundred attempts a day on my primary (which has been shutdown to
the public because of this)
--
Lab tests show that use of micro$oft causes cancer in lab animals
Got Gas???
