Timo Neuvonen wrote:
> Season's Greetings (sorry I'm late) to everyone!
>
> I'm trying to find out a "simplest possible" way to
> implement greylisting with exim 4.6x
>
> Everything I found about this seems to be rather old...
> is greylisting still something reasonable to do today?
Not a big fan of it here, other 'fingerprints' of arriving traffic have
generally been lighter-weight and give very good results.
That said, if/as/when applied to traffic we woudl probably otherwise reject
outright (and NOT to traffic we would otherwise accept), it can be a lite-weight
'second chance' for arrivals from servers with dodgy configuration/DNS, etc.
We are using Heiko Schlittermann's script:
http://www.schlittermann.de/doc/grey.html
- applying it in three different places:
-- as ~grey to arrivals without rDNS
-- as ~blue to arrivals with rDNS, valid, but mismatched HELO
-- as ~red to arrivals with both 'wrong' and/or RBL hit(s).
Delays independently adjusted according to one's goals.
In our case, we run chron scripts to clear each dirtree daily, so bad-actors
have to start over each day.
*OTOH* - we 'whitelist' arrivals from places we send to, so once a
flawed-but-otherwise-legitimate arrival has had a response, they no longer hit
these lists at all.
Left to run for 4 weeks w/o any cleardown, a 'du' on the the ~red dirtree once
grew to 250+MB.
>
> My server is running on FC5, with self-compiled exim. So eg.
> debian-targeted packages would require a lot of modifications.
>
AFAIK, the self-compiled setup shoudl make his script a drop-in fit for you.
We had to make very minor tweaks to adapt to differences in FreeBSD shell and
other utilities, but none to adapt to Exim.
> The server in question has a relatively small amount of traffic,
> on average much less than one (to be accepted) message in a
> minute. So, my idea is that all greylist database housekeeping
> could propably be re-run after every received message if it
> helps anyhow to keep things simple.
>
This one seems to scale well enough for loads around 10 times that, and needs no
db (well the fs *is* a db of sorts..).
Can't say what it would do under really *serious* load, as we don't have such here.
> This page seems to contain most of the reasonable-looking
> links I've found:
> http://spamlinks.net/filter-server-greylist.htm#implement-exim
>
> So far, these two look the most interesting:
> http://www.sigsegv.cx/exim-greylist-2.html
> http://llab.zhitomir.net/?greylist
>
> The first one looks definetely simple -until I read the footnotes:
> "don't use until you add this-and-that"
>
> The latter one is based on perl, but that wouldn't definetely
> be a performance issue in my environment. And it would keep
> the exim.conf clean. But just noticed it's "the first release from
> 2003". As not a perl-coder, I'm not able to analyze the code...
> does it work perfectly well, or was it maybe found to be
> impossible to fix and develop any further (since there is no
> 2nd release in 3 1/2 years).
>
> Does anyone have a good suggestion for a *simple*
> greylisting conf? It doesn't have to be performance-optimized,
> no need for extensive logging features, etc. But something that
> would keep it's database clean without manual MySQL sessions.
>
See above.
http://www.schlittermann.de/doc/grey.html
>
> Thanks for any help already in advance. I'm somehow a little
> bit lost now with this greylisting issue...
>
> - Timo
>
>
HTH,
Bill
