Re: [exim] ratelimit on dnsbl offenders?

Pàgina inicial
Delete this message
Reply to this message
Autor: W B Hacker
Data:  
A: exim users
Assumpte: Re: [exim] ratelimit on dnsbl offenders?
B. Cook wrote:
>
>

*snip* (capturing chronic offender IP's to a DB/file for *local* BL use)

>
> Yes that would be ideal, Is there a way to get exim to add something to
> spamdb and/or pf block list until spamdb can be rebuilt..
>
> How can I make exim "do something" (outside of exim) when "something
> happens" (inside exim)?
>
> I didn't think that was possible w/ exim.. but it sounds like you are
> speaking as if you are doing it/have done it.
>
> :)
>
>


Soem htigns are easier than others, but I have yet to find *anything*
'not possible' with Exim, though per-reipient rejection *within*
acl_smtp_data comes close.

here are two hints - one provides 'meat' for massaging into a flat file
or CDB, the other goes into an SQL DB.

Neither act directly, and I do NOT recommend automagically entering them
for 'live' use w/o 'wetware' oversight.

If nothing else, one wants to strip dups. AND insure a proper MTA is not
being unfairly treated over a one-time faux pas.

Ex:

========= to store into an SQL table ======

    set acl_c19 = ${lookup pgsql{INSERT into brownlist \
    (pg_when, pg_why, pg_ip, pg_host) \
                    VALUES 
('$tod_log','LBL','${quote_pgsql:$sender_host_address}','$sender_host_name')}}


==== PostgreSQL has tools to do the statistics, removes dups, et al ===

=== to prep for a .csv or such ======

     logwrite    = \
:panic:,VRL,$sender_host_address,$tod_epoch,$sender_host_name


===

Where 'LBL' was a(nother) Local Blacklist hit, 'VRL' was an infected
attachement. Other codes ID DYNamic IP, RDNs fail, HeLO forgery et al.

Line-wraps abocve to reduce MUA munging - originals are long-lines

CAVEAT: Others here have posted snippets that write far more clever
output, some directly usable in near-real-time.

Likewise 'greylisting' can be bent to NEVER cease deferring identified
chronic offenders, thoug I consider greylisting more resoruce load than
it is worth if better means are in place.

I prefer to do a bit of checking before dropping the hammer, so both of
these are just to provide supporting stats at our shop.

Hardball blocking on IP or network is not to be undertaken casually.

HTH,

Bill