Milter-greylist

what i have found is that many spammers will try something once a day
so if you want real results; presume a real server retry's more often
than that so drop things off the grey list in 

timeout 23h  # default is 5d !?

i only autowhite for 2-3d, but that is my preference. again making
these shorter is  agressive AND it should help milter perform better
by keeping the db smaller

it is pretty easy to build a histogram of acl rules hit using
emanual's %A formatting option something like

cut -d: -f6,7  /var/milter-greylist/milter-greylist.log | grep -c
184:tempfail
325

for me this %A option is marvelous (tnx emanual) a script below might
shed insight. i am NOT sure analysis of %E , %R histograms would give
any more insight, but i would welcome you to prove me wrong...

# %E Elapsed time since first delivery attempt
# %R Remaining time before the message gets accepted


#!/usr/bin/perl -w
# for linenos on the command line print out the acl rule from
greylist.conf
# example usage:
#  cut -d: -f6 /var/milter-greylist/milter-greylist.log | sort -u  | 
xargs -n1 mrule
#
# where
#  stat ">>/var/milter-greylist/milter-greylist.log" "%T{%T}
%i:%f:%r:%A:%S\n"

if ( 0 > $#ARGV ) {
        print STDERR "usage: $0 lineno [...]\n";
        exit;
}

open P, "/etc/mail/greylist.conf" || die "$!";

for $lin ( sort {$a <=> $b}  @ARGV ) {
   while (<P>) {
       $rul = $_;
       if ( $lin == $. ) {
           print "$lin: $rul";
           last;
       }
   }
}


--- In milter-greylist@yahoogroups.com, Tom Hedges <tom@...> wrote:
>
> milter-greylist can offer invaluable data regarding what the "magic" 
> number of delay minutes is before purging a greylist entry. By 
> recording the time when an entry enters the the greylist, latest time 
> it was accessed, versus those entries that were auto-whitelisted; a 
> histogram might be constructed to optimize the greylist timeout 
> period. I would assume this would offend no one, and would give each 
> user an insight into how long it takes to get spam-bot's to give up 
> versus the annoying delay joining new BBS's, etc.
> 
> Comments (and flames) are welcomed.
> 
> Tom
>