Re: ISPmail Lenny tutorial ready

[emilio brambilla <emilio@antispam.it>]

hello,

Christoph Haas wrote:

> I have never have experienced such great benefits of greylisting as
> their inventors made it look. There were graphs of mail serves with
> massive inbound spam and it virtually dropped to zero. Somehow the

on the tests I did at the end of the 2006 I had impressive results (it
did not drop to zero spam, but it was able to remove a good 95% of the
spam);

now, after this dicussion I did analyze the last 2 months of logs of a
small mail-hosting server (5000 mailbox from 500 different domain name)
which use greylisting (greylist is configured *after* a few header check
and after the zen.spamhaus.org rbl) and got this results:

Total messages seen:	1846641
accepted immediatly:	1149781 ( 62.3%)
delayed messages:	132635  ( 7.2%)
blocked messages:	564225  ( 30.6%)

now, 30% of messages blocked is more than the number I had in my mind (I
was of the idea greylisting today can only stop a few mail, but it looks
like there still is a lot of zombie not retrying the delivery)

the bad side is the 7.2% of messages delayed (7.2% of the messages
arriving from not-whitelisted ip is very much... it should be intresting
to understand how much of this 7.2% is spam from zombie retrying the
delivery and how much is real ham-mail delayed by the greylisting)

I have no data about how much spam was delivered to the inbox of these
mailboxes (but I know that is "too much" for the experience of a lot of
the users)

> spammers that annoyed me have always a different kind. :) Besides I (and
> some of my users) didn't like the tradeoff of delaying email. ("I
> urgently need this registration email. Where is it gone?")

I agree: greylisting was acceptable (of course not for every
server/user) when it was able to block almost all the spam (in december
2006, with no other antispam systems it was blocking 95% of the spam
getting into my server), but now the performance is too low to
justificate the possible delay of real mail.

maybe now the best (or "less worst") solution is header-check + rbl +
spamassassin


-- 
bye,
emilio