Milter-greylist

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.