Milter-greylist

On Feb 8, 2008 3:43 PM, Eduardo Casarero
<eduardo.casarero@...> wrote:
>  i'm asking because i have lot of memory used by greylisting, and before
> buying more ram im trying to save as much as i can.

How long do you retain the tuples (timeout)? The default is 5 days, I
lowered it to one day and the database shrunk accordingly with no ill
effects that I could see.

-- 
/peter

On Feb 8, 2008 5:01 PM, Eduardo Casarero
<eduardo.casarero@...> wrote:
>  yes i could do that, but my users are pretty sensible in "delay" issues.

How would that affect delay? A server that doesn't retry within 24h
isn't very likely to retry at all in my opinion. It's not possible
from our side to control how long the delay is after we temp fail the
other side in the first place, the only way to minimize delay for the
"innocent" is to use whitelisting. I find using dnswl.org makes the
need for static whitelisting (read user complaints) a lot less.

-- 
/peter

Eduardo Casarero wrote:
> 
> On Fri, 2008-02-08 at 16:46 +0100, shuttlebox wrote:
>> On Feb 8, 2008 3:43 PM, Eduardo Casarero
>> <eduardo.casarero@ 
>> <mailto:eduardo.casarero%40informaticaavanzada.com.ar>informaticaavanz 
>> <mailto:eduardo.casarero%40informaticaavanzada.com.ar>ada.com.ar 
>> <mailto:eduardo.casarero%40informaticaavanzada.com.ar>> wrote:
>> > i'm asking because i have lot of memory used by greylisting, and before
>> > buying more ram im trying to save as much as i can.
>>
>> How long do you retain the tuples (timeout)? The default is 5 days, I
>> lowered it to one day and the database shrunk accordingly with no ill
>> effects that I could see.
> yes i could do that, but my users are pretty sensible in "delay" issues.

You're confusing the "autowhite" period with the "timeout".

"timeout" applies to tuples that haven't successfully passed the greylist. It 
essentially defines how long MG will continue to wait for a retry from a given host.

"autowhite" applies to tuples that *have* passed the greylist. This affects 
delay in follow-on communications.

As for your original question: lazyaw and/or subnetmatch, should reduce the 
number of tupples in your greylist, thus the size of the greylist database. How 
much of an impact this has depends on your mail flow.

Another factor to check for is dictionary attacks. They've got a strong tendency 
to flood your greylist database if you don't have appropriate countermeasures.

Assuming you've only got one domain (or all your domains have the same users), 
you might want to run this little command:

cut -f3 greylist.db | cut -d \@ -f1 | tr -t '[:upper:]' '[:lower:]' | sort | 
uniq -c | sort -n

Which will run a quick report of how many entries each recipient username has in 
your greylist.db. It's very handy

ie, some entries from my run come back as:
      29 <webmaster
      32 <illustrateonqchy
      83 <farmnaktulf
     362 <mkettler

The middle two are obvious dictionary attacks. A few is OK, but if you've got a 
lot, you might want to start looking at countermeasures.

Matt Kettler wrote on Fri, 08 Feb 2008 12:10:10 -0500:

> As for your original question: lazyaw and/or subnetmatch, should reduce the 
> number of tupples in your greylist,

AFAIR, it doesn't. Tuples get stored as without lazyaw, just that the sender 
mail address gets ignored. Just storing what is really necessary depending on 
the "greylist mode" would indeed be helpful I think.

Kai

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

Kai Schaetzl wrote:
> Matt Kettler wrote on Fri, 08 Feb 2008 12:10:10 -0500:
> 
>> As for your original question: lazyaw and/or subnetmatch, should reduce the 
>> number of tupples in your greylist,
> 
> AFAIR, it doesn't. Tuples get stored as without lazyaw, just that the sender 
> mail address gets ignored. Just storing what is really necessary depending on 
> the "greylist mode" would indeed be helpful I think.

It won't change the size of the tuple record, but it will save space in that you 
you won't have one entry for every sender.

ie: joe@... 1.2.3.4 sends you email, gets delayed, then a whitelist 
entry is created.

later jane@... 1.2.3.4 sends you email. With lazyaw, that email goes 
through, and no new entry is created. Without lazyaw, she gets delayed, and then 
another entry is created.

In this over-trivialized example lazyaw would reduce your greylist db by 50%.

In reality, how much these will help depends a lot on your email.

Matt Kettler wrote on Wed, 20 Feb 2008 12:07:33 -0500:

> later jane@... 1.2.3.4 sends you email. With lazyaw, that email goes 
> through, and no new entry is created.

Ah, I didn't know that. Thanks, Matt.

Kai

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