On Fri, 12 Sep 2003, Tony Earnshaw wrote:
> Elliot Finley wrote:
>
> > I have this in my acl_smtp_rcpt:
> >
> > deny message = No dictionary attacks!
> > condition = ${if > {$rcpt_fail_count}{1} {yes}{no}}
>
> condition = ${if >{$rcpt_fail_count}{1} {1}}
>
> "works for me". *Test it first!*
A limit of 1 seems rather strong. An inadvertent obsolete address in
an otherwise bona fide list would trigger it, right?
As we discussed here recently, though, this approach (no matter what
limit you set) permits of a trivial workaround for the spammers: they
just have to use RSET.
I was preparing to move towards counting in the call-wide acl_c
variables... i.e I had inserted a "warn" to find out what it would do,
preparatory to using it instead of the existing checks - which are
based on $rcpt_count (the number of attempted rcpt) and
$recipients_count (the number of good recipients), so as not to
penalise just the occasional obsolete address in a large but otherwise
bona-fide addressee list.
[However, I haven't finished that, and this mass worm-fighting
business has taken its toll, so I can't report any results yet.]
Of course, neither option will help if the spammers take to using a
fresh call for each victim address.
> > !verify = recipient
> > delay = ${eval: ($rcpt_fail_count) * 60}s
> > log_message = $rcpt_fail_count failed recipient attempts
In our experience, if we delayed by > 5 minutes then the attacker
would disconnect from their side, and try again. Some of them were
seen to be retrying the same portion of their address list, over and
over and over, in this situation - thus making things worse than they
had been before, rather than better. So keep a close eye on the
consequences of whatever you're trying ;-)
Don't forget that if you _do_ decide to finish the party by refusing
to talk SMTP to them, or even dropping them at the firewall, then
a bona fide sender who has been misidentified has no way to even
contact the postmaster to discuss the problem.
cheers
