Milter-greylist

Howdy -

I've just implemented milter-greylist again, and I was curious as to 
whether there is any reporting available. I'd like to know how many or 
what percentage of messages get dumped by milter-greylist.

Anyone got any tips or tricks for doing that?

Thanks!
TC

Thomas Cameron <thomas.cameron-NGNQ62rjTJDc+919tysfdA@...>
writes:

> I've just implemented milter-greylist again, and I was curious as to 
> whether there is any reporting available. I'd like to know how many or 
> what percentage of messages get dumped by milter-greylist.
>
> Anyone got any tips or tricks for doing that?

greylisting does (still) a great job.  But nolisting outperforms
its. E.g. in

                   http://ensc.de/rate-year-2008.png

it is easy to see when we enabled nolisting.  For reference, current
statistics looks like

                   http://ensc.de/rate-year-2012.png


Enrico

On 2013-04-08 05:20, Thomas Cameron wrote:
> Howdy -
>
> I've just implemented milter-greylist again, and I was curious as to
> whether there is any reporting available. I'd like to know how many or
> what percentage of messages get dumped by milter-greylist.
>
> Anyone got any tips or tricks for doing that?

The greylisting database file (/var/milter-greylist/greylist.db or
somesuch in your system), should contain the current list of addresses
in both grey and auto-white stages. For the tool to be effective, you
should also pick and use a DNS RBL resource to verify that the source
addresses which did pass to auto-whiting are not yet well-known spam
sources.

Then you can see something like this:

# tail /var/milter-greylist/greylist.db
...
# Summary: 4488 records, 4336 greylisted, 152 whitelisted

Here, of 4.5k source hosts over the past few days (3 days or whatever
your limit is) only 150 were not known spam sources and did try twice
and were accepted to next stages in spam-filtering or mail delivery ;)

HTH,
//Jim Klimov

Enrico Scholz <enrico.scholz@...-chemnitz.de> wrote:

> greylisting does (still) a great job.  But nolisting outperforms
> its. 

It's odd that spammers did not yet adapt to nolisting, as it is really
easy to work around. I wonder how long it will work.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

On Tue, Apr 9, 2013 at 5:27 AM,  <manu@...> wrote:
> Enrico Scholz <enrico.scholz@...-chemnitz.de> wrote:
>
>> greylisting does (still) a great job.  But nolisting outperforms
>> its.
>
> It's odd that spammers did not yet adapt to nolisting, as it is really
> easy to work around. I wonder how long it will work.

Couldn't you make the exact same argument about greylisting? After all
they are very similar and all about if they resend or not. Nolisting
to me is just a poor mans implementation of greylisting. There should
be a huge overlap between the two.

On Tue, Apr 09, 2013 at 09:01:50AM +0200, Peter Bonivart wrote:
> Couldn't you make the exact same argument about greylisting? 

I do not think so.

Working around greylisting means maintaining a queue. Since spammers
use botnet, resources are free for them but they are not infinite. 
If the greylisting delay is long enough, we observe they do not afford it.

Beside this, greylisting does not scale for really huge domains, which 
means that the incensive for working it around remains low: gmail, hyahoo,
hotmail and other monsters will never use it.

-- 
Emmanuel Dreyfus
manu@...

On 2013-04-09 09:08, Emmanuel Dreyfus wrote:
> On Tue, Apr 09, 2013 at 09:01:50AM +0200, Peter Bonivart wrote:
>  > Couldn't you make the exact same argument about greylisting?
>
> I do not think so.
>
> Working around greylisting means maintaining a queue. Since spammers
> use botnet, resources are free for them but they are not infinite.
> If the greylisting delay is long enough, we observe they do not afford it.

 From our practice, I'd add that greylisting works to a large
extent thanks to coupling with DNS RBLs, including dial-up
RBL lists. While the message from an unknown untrusted source
host is being delayed from coming into our relay, other letters
from this host might hit an RBL honeypot system and by the time
that greylisting permits the message in based on just the fact
of retry after a given timeout, it would be denied based on DNS
RBL hit. Proper emails from extranet are accepted on the MSA
port (587/tcp) with authentication and STARTTLS, so we should
have no spam that seems to be sent from one of our users to
another - as well as no harmful filtering enforced onto proper
authenticated users from random internet hosts.

This does of course require considerable delays on newly
greylisted contacts, which does sometimes cause grief from
our users; we use about 25 minutes typically (because many
legitimate hosts retry their submissions after half an hour
and then less often) so that greylist's impact is smaller
for legitimate mail, effecting a 30-minute delay usually.

We have long thought of implementing some "smart" filters
like SpamAssassin, but in fact the computationally cheap
methods like banner delay, DNS RBL, greylisting and regex
matching on host names (i.e. static-12-34-56-78.dialup.net)
do an extremely good job without hogging the CPU. We do get
one or two spams a day occasionally, usually from compromised
legitimate hosts or via our whitelists (honeypot receivers
or managers who chose to fight spam in their mail agents
rather than delay business mail), but this is not enough
of a threat to filter the rest of accepted mail with content
filters. In fact, with a reasonably long auto-white-list
(i.e. weeks) we get most of the benefit (bad guys are
still chopped off by DNS RBL - if they are caught) with
least downside (legit mails, even from "rare" counteragents,
pass quickly).

HTH,
//Jim Klimov
A happy user for about a decade ;)

On Tue, Apr 09, 2013 at 03:08:09PM +0200, Jim Klimov wrote:
> This does of course require considerable delays on newly
> greylisted contacts, which does sometimes cause grief from
> our users;

I address that by having user-configurable recipient-dependent
greylisting delays. They can choose no greylisting, 15mn greylisting,
15mn greylisting + 12h for hosts in SOBRS DUN (DSL and cable hosts).

People that want no delay have no delay. People that want filtering
get filtering. And they can change it whenver they want.

-- 
Emmanuel Dreyfus
manu@...