Re: [exim] Penalty Box - Caching Sebder Verify Data

Top Page
Delete this message
Reply to this message
Author: Bill Hacker
Date:  
To: exim-users
Subject: Re: [exim] Penalty Box - Caching Sebder Verify Data
Marc Perkel wrote:
> ok - for those of you who want to try this - and perhaps improve it -
> I've developed a new trick for caching sender verify callouts and
> putting spammers in a penalty box to prevent having to do repeated
> callouts and spam filtering for the same spammers.
>
> Overview ----
>
> Basically this is like greylisting except that it is open and is
> triggered by an initial sin on the part of the sender. If the sender
> sends me a high scoring spam - or the sender verify fails - the email
> address is put in a list and is blocked for up to one hour. A cron job
> clears the list hourly.
>
> I'm using the latest Exim snapshot to do this. And it is required for
> accuracy.
>
> In the ACL - the defer ....
>
> defer    senders = /var/spool/spam/from-spam.txt
>            message = FROM Address temporary BLOCK!

>
>
> An ACL that captures the Sender Verify Fail .....
>
> drop    message = REJECTED - Sender Verify Failed - error code 
> \"$sender_verify_failure\"\n\n\
> The return address you are using for this email message <$sender_address>\
> does not seem to be a working account.
>    log_message = REJECTED - Sender Verify Failed - error code 
> \"$sender_verify_failure\"
>    !domains = +no_verify
>    !verify = sender/callout=2m,defer_ok
>    condition = ${if eq{recipient}{$sender_verify_failure}}
>    condition = ${run{/etc/exim/scripts/from-spam 
> $sender_address}{yes}{yes}}

>
> A filter rule that adds to the list
>
> # -- Penalty Box for Spammers
>
> if "$h_X-Spam-Level:" contains "********************"
> then
> logfile /var/spool/spam/from-spam.txt
> logwrite "$sender_address"
> endif
>
> The script that the run command runs .....
>
> echo "$*" >> /var/spool/spam/from-spam.txt
>
> And the hourly cron task that clears out the penalty box.
>
> true > /var/spool/spam/from-spam.txt
>
> This can probably be done better - but it seems to be working really well.
>
>


Too fatigued to try just now, but .....

I am interested in time-stamping entries so as to remove those over an
hour old, rather than all entries every hour regardless of age.

Some may be only a few seconds or minutes old, so you presently have a
'mean' age of thirty minutes or thereabouts with a very wide
distribution, do you not?

Ex: 25% could be 15 minutes old, 10% could be only six minutes old, etc.

What if..... instead of writing all to one file, one wrote each entry
*as* a file, but within a bespoke directory?

- Then, at some interval (10 minutes?) deleted anyhting in that
directory older than (55?) minutes. Or similar...

Storage needs should remain reasonable, and a 'quota' could be emplaced
to guard against a runway situation.. (failure of the chron script..).

Seems as if it would still be a lightweight process compared to SQL
calls, though 'leaner' DB's could be used effectively - perhaps, for
efficiency, in combination with other white/black listing tools....

Bill Hacker