Milter-greylist

Hi,

I just thought of the following feature for milter-greylist, since 
milter-greylist is already familiar with all smtp communications and can 
keep statistics regarding the amount of email blacklisted, whitelisted, 
greylisted and delay times.

What I would ideally like to have is a smtp server whitelist which is 
determined based on a minimum number of accepted messages from this server.

Something along these lines.

/* Servers that sent over 500 accepted emails are whitelisted */
list "clean server" okaddr 500
acl whitelist list "clean server"

Here is a example for a suggestion I made quite a while ago. It also is 
directed mainly for whitelist email servers.
/* Servers that match the MX record for the sender domain are 
whitelisted which match the subnetmask bits */
/* example matches all hosts within a /24 subnet */
list "clean mxrecord" mxaddr 24
acl whitelist list "clean mxrecord"

Perhaps a rrd data collector backend would prove very useful for insight 
into the milter-greylist operation.

What I have now is a combination of shell scripts which grep through the 
log files and then proceed to update the RRD databases with the 
different results.

I can ofcourse also make these scripts available on my website if anyone 
is interested. But a more integrated approach for a RRD data collector 
would definitely be something nice to have.

What I have now looks something like this. 
http://mailtoaster.coltex.nl/spam/index.php
Interestingly it also shows that my backup MX receives almost no email 
at all.

Kind regards,

Seth Mos

> I just thought of the following feature for milter-greylist, since
> milter-greylist is already familiar with all smtp communications and can
> keep statistics regarding the amount of email blacklisted, whitelisted,
> greylisted and delay times.
>
> What I would ideally like to have is a smtp server whitelist which is
> determined based on a minimum number of accepted messages from this server.

it seems that a percentage would make more sense.  and i think it would 
also make sense if it had a lifetime associated with it.  just because a 
server is behaving today doesn't mean it will still be nice next week.

Joe Pruett schreef:
> 
> 
>  > I just thought of the following feature for milter-greylist, since
>  > milter-greylist is already familiar with all smtp communications and can
>  > keep statistics regarding the amount of email blacklisted, whitelisted,
>  > greylisted and delay times.
>  >
>  > What I would ideally like to have is a smtp server whitelist which is
>  > determined based on a minimum number of accepted messages from this 
> server.
> 
> it seems that a percentage would make more sense. and i think it would
> also make sense if it had a lifetime associated with it. just because a
> server is behaving today doesn't mean it will still be nice next week.

Well, a email server stays a email server. So it will re-send the email 
regardless. Thus the motivation for greylisting it seems dubious at first.

If however coupled with a lifetime like the autowhitelist, which was my 
original intention, that would make the best example of reducing the 
impact of grey listing in the enterprise. It would still however achieve 
very good results.

Take my exmaple, apply a 10 day auto whitelist and suddenly it covers 
95% of whitelisting all business communications. In a considerably sized 
company this reduces administration a lot without reducing the grey 
listing benefits.

Kind regards,

Seth Mos

Seth Mos wrote:
 > If however coupled with a lifetime like the autowhitelist, which was my
 > original intention, that would make the best example of reducing the
 > impact of grey listing in the enterprise. It would still however achieve
 > very good results.
 > 
 > Take my exmaple, apply a 10 day auto whitelist and suddenly it covers
 > 95% of whitelisting all business communications. In a considerably sized
 > company this reduces administration a lot without reducing the grey
 > listing benefits.

Isn't that case pretty much covered by the "lazyaw"
option in the configuration file?

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch\ufffdftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M\ufffdn-
chen, HRB 125758,  Gesch\ufffdftsf\ufffdhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

(On the statement print "42 monkeys" + "1 snake":)  By the way,
both perl and Python get this wrong.  Perl gives 43 and Python
gives "42 monkeys1 snake", when the answer is clearly "41 monkeys
and 1 fat snake".        -- Jim Fulton

Oliver Fromme wrote:
>
>
> Seth Mos wrote:
> > If however coupled with a lifetime like the autowhitelist, which was my
> > original intention, that would make the best example of reducing the
> > impact of grey listing in the enterprise. It would still however achieve
> > very good results.
> >
> > Take my exmaple, apply a 10 day auto whitelist and suddenly it covers
> > 95% of whitelisting all business communications. In a considerably sized
> > company this reduces administration a lot without reducing the grey
> > listing benefits.
>
> Isn't that case pretty much covered by the "lazyaw"
> option in the configuration file?
>
However, if the total spam run takes longer than your greylist time, 
wouldn't that allow the messages through then? Or does lazyaw only trip 
off after a (IP, sender, receiver) tuple passes?

Richard Frovarp wrote:
 > Oliver Fromme wrote:
 > > Seth Mos wrote:
 > > > If however coupled with a lifetime like the autowhitelist, which was my
 > > > original intention, that would make the best example of reducing the
 > > > impact of grey listing in the enterprise. It would still however achieve
 > > > very good results.
 > > > 
 > > > Take my exmaple, apply a 10 day auto whitelist and suddenly it covers
 > > > 95% of whitelisting all business communications. In a considerably sized
 > > > company this reduces administration a lot without reducing the grey
 > > > listing benefits.
 > > 
 > > Isn't that case pretty much covered by the "lazyaw"
 > > option in the configuration file?
 > 
 > However, if the total spam run takes longer than your greylist time, 
 > wouldn't that allow the messages through then? Or does lazyaw only trip 
 > off after a (IP, sender, receiver) tuple passes?

The latter.  lazyaw does not change the way tuples are
handled at the greylisting stage.  It only changes the
autowhitelisting so that the whole IP is whitelisted
_after_ a tuple has been accepted from that IP.

I have enabled the lazyaw option since I began to use
milter-greylist a few years ago, and it seems to work
very well.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch\ufffdftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M\ufffdn-
chen, HRB 125758,  Gesch\ufffdftsf\ufffdhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"Python tricks" is a tough one, cuz the language is so clean. E.g.,
C makes an art of confusing pointers with arrays and strings, which
leads to lotsa neat pointer tricks; APL mistakes everything for an
array, leading to neat one-liners; and Perl confuses everything
period, making each line a joyous adventure <wink>.
        -- Tim Peters

Oliver Fromme wrote on Wed, 24 Sep 2008 17:18:23 +0200 (CEST):

> I have enabled the lazyaw option since I began to use
> milter-greylist a few years ago, and it seems to work
> very well.

Indeed, I've been running all my installations with lazyaw for years.

Kai

-- 
Kai Sch\ufffdtzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com