I actually set it up a bit different, the greylist is a standard
greylist, but I use a combo of greylisting and spamassassin scoring to
place people into one of four tables, table 1 and table 2 have expire
timers set on entries, with table twos timer being advanced with every
successful message. The cleanup routines remove all expired records and
vacuum the database.
Table 1 - the greylist, the standard grey type list with a hard set 14
minute retry timer, if you retry within a 14 minute the timer keeps
getting set forward. So you HAVE to wait 15 minutes before a retry, this
list is per message, I keep track of the sending message id.
Table 2 - Those people that pass the greylist are added to table 2, here
I keep track of the number of messages they send and the average spam
score for the sender/ip combo. They of course are not delayed any longer
by the greylist.
Table 3 - If you send 20+ messages in a 1 week period and your average
spam score is less then 3 you are added to this list, it is your basic
whitelist where messages are no longer scored, only virus checked.
During all this I run a SQL statement to count the number of records in
the database, it the result % 200 is 0 - 3 then I run database cleanup
routines. What all this does is create a self maintained and self
cleaning filter.
So far 1 out of 27,000+ messages has made it though all the checks. But
my testing was cut short by my employer because in my managers words,
"We don't have a spam problem."
What he means is that until someone complains about the level of spam
received he is not going to spend time on a solution. We already have
content filters, but loose rules still allow a high level of spam.
Who knows, someday I may get to turn my system back on and see how well
it keeps up.
:) I love exim, without it my method would not have been implemented.
-----Original Message-----
From: ianf@??? [
mailto:ianf@hetzner.co.za] On Behalf Of Ian
FREISLICH
Sent: Wednesday, August 17, 2005 7:47 AM
To: Wintrode, Jerry R.
Subject: Re: [exim] Postgres Lookup failure..
"Jerry Wintrode" wrote:
>
>
> I have the following in my configure file:
>
> GREYLIST_TEST = SELECT CASE \
> WHEN now() - block_expires > 0 THEN 2 \
> ELSE 1\
> END \
> FROM relaytofrom \
> WHERE relay_ip='${quote_pgsql:$sender_host_address}' \
> AND =
> from_domain='${quote_pgsql:$sender_address_domain}'
>
> GREYLIST_ADD = INSERT INTO relaytofrom (relay_ip, from_domain) \
> VALUES ( '${quote_pgsql:$sender_host_address}, \
> '${quote_pgsql:$sender_address_domain}')
>
>
>
>
> And the following acl_check_data entries:
>
> # Greylist config
> #
> warn set acl_m7 = ${lookup pgsql{GREYLIST_TEST}{$value}{0}}
> defer message = Temporary Local Error. Please try again later.
> condition = ${if eq{$acl_m7}{0}{1}}
> condition = ${lookup pgsql{GREYLIST_ADD}{yes}{no}}
> defer condition = ${if eq{$acl_m7}{1}{1}}
Jerry, can I make a few suggestions about greylisting from my
experience?
I find that doing greylisting in acl_smtp_predata saves recieving mail
twice. Also you need to be careful how you greylist the null sender
since you might land up in a greylist war with a host performing
callouts. I also maintain a whitelist since there is no point in
continuing to greylist a host that has retried. All hosts that retry
get added to the whitelist.
I'll happily share my configuration (tables, stored procedures and exim
configure) for greylisting if you're interested.
Ian
--
Ian Freislich
