Milter-greylist

It would be good to have acls read elements from files. Is this this implemented?

For example, right now I have:

dacl blacklist header /Your wife photos attached/ msg "REJECTED"

Instead of editing greylist.conf every time, why not have a file to include this one at a line:

dacl blacklist header "headers.txt" msg "REJECTED"

Same goes with whitelists, etc.

Did I miss something?

D

d d <x55k@...> wrote:

> Same goes with whitelists, etc.
> Did I miss something?

I thought about implementing that some time ago. The real difficulty is
that you get a list of files for which you have to monitor changes.
Reloading them on each ACL evaluation seems a bit silly.

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

On Thu, Aug 26, 2010 at 10:59:48PM -0700, x wrote:
> Just read the files at program startup just like everyone else does or 
> when the program gets a HUP.

That's an old problem: libmilter takes care of signals. As I understand 
it means milter-greylist cannot catch SIGHUP. I would appreciate
a callback for it in the API, but it did not happen.

The way it works now is that we stat(2) the config file on each 
ACl evaluation, and if mtime changed, we reload it.

-- 
Emmanuel Dreyfus
manu@...

x <x55k@...> wrote:

> Fine. What about giving us an option to load a file at startup then?
> You can put a warning saying a restart is required to read changes.

We could do that. We already have lists, their declaration syntax could
be made more general, with two alternative syntaxes

list "badaddr" { bad@... bad@... }
list "badaddr" file "/etc/mail/blacklist.txt"

Would you want to contribute a patch? That should be quite
straightforward.

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

On Fri, Aug 27, 2010 at 12:28:54AM -0700, x wrote:
>> ________________________________
>> From: Emmanuel Dreyfus <manu@...>
>> To: milter-greylist@yahoogroups.com
>> Sent: Fri, August 27, 2010 10:50:43 AM
>> Subject: Re: [milter-greylist] How to use text lists to blacklist headers?
>> 
>> \ufffd 
>> On Thu, Aug 26, 2010 at 10:59:48PM -0700, x wrote:
>> > Just read the files at program startup just like everyone else does or 
>> > when the program gets a HUP.

Why not just "touch" to main configuration file for signaling
the daemon? Easier than a kill ...

>> 
>> That's an old problem: libmilter takes care of signals. As I understand 
>> it means milter-greylist cannot catch SIGHUP. I would appreciate
>> a callback for it in the API, but it did not happen.
>> 
>> The way it works now is that we stat(2) the config file on each 
>> ACl evaluation, and if mtime changed, we reload it.

... and if provided by means of an include-feature every included
configuration too.

> Fine. What about giving us an option to load a file at startup then?
> 
> You can put a warning saying\ufffda restart is required to read changes.
> 

In my opinion, this is only acceptable for small environments. To
suggest a restart after changing only the configuration is too heavy.
Every restart is expensive because the greylisting DB has to be written
out to disk and read back in during startup. The interruption of the
service maybe to long, the peak I/O load of writing/reading the DB is
annoying.

As stated above, I would prefer to change the included file
and get the information provided to touch the main configuration file
forcing a read-in by the daemon ...

Otherwise, some technique using a communication socket/FIFO to talk
with the daemon comes to mind. Just an idea (no Manuel, I don't
have a patch for this already ;) ...)

Johann E. K.

I only know COBOL :) I will have to brush up on that, it was few decades ago that I used it last time :)

Keep us updated please when this feature is implemented Emmanuel.
 
Thanks again for milter-greylist, using it 2 years, no issues.
 
D

--- On Fri, 8/27/10, manu@... <manu@netbsd.org> wrote:

From: manu@... <manu@...>
Subject: Re: [milter-greylist] How to use text lists to blacklist headers?
To: milter-greylist@yahoogroups.com
Date: Friday, August 27, 2010, 6:45 AM


  



x <x55k@...> wrote:

> Fine. What about giving us an option to load a file at startup then?
> You can put a warning saying a restart is required to read changes.

We could do that. We already have lists, their declaration syntax could
be made more general, with two alternative syntaxes

list "badaddr" { bad@... bad@... }
list "badaddr" file "/etc/mail/blacklist.txt"

Would you want to contribute a patch? That should be quite
straightforward.

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

It is not as if we have to restart the daemon every 10 minutes.

I have 430 spams that passed through greylisting last 1 month. 400 of them is 
"Your wifes photo attached" virus or whatever. 


So just add a line to headers file when there is an outbreak and leave it be. 
Whenever the daemon is restarted, that virus would stop passing through once and 
for all.

Yes, this is for small environments. I used to get 50K+ spam a day, now I am 
down to 20 wife photos.

D



In my opinion, this is only acceptable for small environments. To
suggest a restart after changing only the configuration is too heavy.
Every restart is expensive because the greylisting DB has to be written
out to disk and read back in during startup. The interruption of the
service maybe to long, the peak I/O load of writing/reading the DB is
annoying.

As stated above, I would prefer to change the included file
and get the information provided to touch the main configuration file
forcing a read-in by the daemon ...

Otherwise, some technique using a communication socket/FIFO to talk
with the daemon comes to mind. Just an idea (no Manuel, I don't
have a patch for this already ;) ...)

Johann E. K.