Re: [Exim] spam delay trick and smtp_accept_count patch.

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Martin Evans
Datum:  
To: Alan J. Flavell
CC: Exim users list
Betreff: Re: [Exim] spam delay trick and smtp_accept_count patch.
On Mon, 2004-02-02 at 13:11, Alan J. Flavell wrote:
> On Mon, 2 Feb 2004, Martin Evans wrote:
>


> warn set acl_m2 = $tod_epoch
>
> and then, when I decide that I'm going to try the timeout trick, I
> compute the residual time
>
>               set acl_m2 = ${eval:XX+$acl_m2-$tod_epoch}

>
> where XX is the desired delay in seconds. If the result is positive,
> then the delay is started. Usually the adjustment, compared to the
> fixed delay, is only a couple of seconds, but occasionally the
> adjustment is as much as 10-20 seconds.
>
> If folks all were to use the same delay, then the abusers would just
> need to set their timeouts slightly larger. But suffice it to say
> that the delay we're currently using is larger than 60s, but less than
> 99s - but if the abusers start setting their timers to 100s, that's no
> problem, we can deal with that!


Thats very precise. However, I dont think the absolute value of the
timeout matters too much just as long as it is less that 5 mins. I was
planning on just delaying by 60s (and letting the dns responses add a
little randomness).

>
> There are various criteria for our ACL to try applying this timeout -
> basically it's used if the call is suspicious, but not sufficiently so
> as to cause outright rejection. Criteria are such as:
>
> - unqualified HELO
> - HELO is one from a common list of fraudulent HELOs (such as
> hotmail.com, compuserve.com, msn.com, yahoo.co.uk...) that doesn't
> jive with the calling IP's PTR
> - calling host name contains the substring dsl or dial(up|in|-|\.)
>
> Last time I evaluated the efficacy of this feature, it looked as if
> only about 1 in 3 of the transactions where the delay was used were
> actually convinced by it to go away. So, it's not without its use,
> but a bit disappointing.


Thanks if that only works at 1/3 then it is still helpful. I'm a bit
unclear, do you delay all messages with the above properties or just the
RBLed ones?

> smtp_accept_max = 100
> smtp_accept_reserve = 50
> smtp_accept_max_per_host = 9


We have similar settings. In the past, on days where the internet seems
to be problematic, I've seen our relays clog up with connections that
are just taking too long to complete... which is why I'm concerned about
not delaying connections from non-RBLed hosts.

Many thanks,
Martin.


--
-- Dr MDT Evans, Computing Services, Queen Mary, University of London