Kevin Reed wrote:
> [Used the wrong email address, try it again]
>
> Noticed that I was getting pounded by an IP after a drop in one of my HELO
> ACL checks.
>
> 2003-07-29 13:54:35 H=12-254-182-31.client.attbi.com [12.254.182.31]
> rejected EHLO or HELO 209.114.190.200: HELO of this system's IP
> 2003-07-29 13:54:36 H=12-254-182-31.client.attbi.com [12.254.182.31]
> rejected EHLO or HELO 209.114.190.200: HELO of this system's IP
> 2003-07-29 13:54:38 H=12-254-182-31.client.attbi.com [12.254.182.31]
> rejected EHLO or HELO 209.114.190.200: HELO of this system's IP
> 2003-07-29 13:54:39 H=12-254-182-31.client.attbi.com [12.254.182.31]
> rejected EHLO or HELO 209.114.190.200: HELO of this system's IP
>
> More than 1000 of them...
>
> Apparently, they are just reconnecting?
>
> The ACL is...
>
> # Don't HELO with my IP!!!
> drop message = You may not use an HELO of this system's IP
> address
> log_message = HELO of system's hostname
> condition = ${if
> eq{$sender_helo_name}{209.114.190.200}{yes}{no}}
>
> Other than blocking that IP, is there another way to deal with this? I've
> seen this now several times on different IP's.
>
I think it is better to reject/drop at the RCPT stage - check the HELO
in the RCPT ACL.
Also, use a 'delay =' modifier. In combination with a limited number of
connections per IP this will limit the 'hammering'.
I've never used 'drop' though and do not know how in works together with
delay =. The delay works fine with accept and reject.
BTW, does anyone have thoughts about using a delay when accepting mail
from suspicious sources that you might not want to block fully?
Thomas
