Milter-greylist

I will say, p0f support is working good for me so far, in my first 12  
hours of testing :)

I did notice a small unrelated issue, and I don't remember it before, but:

I made a type-o when I edited the config file, and milter-greylist  
just gave up and quit when it auto-reread the config file. Is it  
possible to just spit out an error message to syslog and continue with  
the existing config?

I would make a patch for you, but I'm going be busy till this weekend,  
so if you want to wait that long for me to make one.

I will say, this is one damned good software though. Never had any  
issues with it on my servers (except whatever this libdkim issue is I  
need to track down).

... I encountered the same problem some time ago, so now I don t edit the greylist.conf directly, but rather a master copy , which I validate with

On Wed, Sep 24, 2008 at 09:01:24AM +0200, Benoit Branciard wrote:
> The attached "update-greylistconf" script is the thing I use for this purpose.

I wonder if a command line flag could not help here: milter-greylist -e
would edit a copy of greylist.conf with your favourite $EDITOR, validate
it, and replace the original if the new file is fine. 

That should not be very difficult to implement. Opinion, anyone?

-- 
Emmanuel Dreyfus
manu@...

On Wed, Sep 24, 2008 at 07:50:35AM +0000, Emmanuel Dreyfus wrote:
> On Wed, Sep 24, 2008 at 09:01:24AM +0200, Benoit Branciard wrote:
> > The attached "update-greylistconf" script is the thing I use for this purpose.
> 
> I wonder if a command line flag could not help here: milter-greylist -e
> would edit a copy of greylist.conf with your favourite $EDITOR, validate
> it, and replace the original if the new file is fine. 
> 
> That should not be very difficult to implement. Opinion, anyone?

`-c' perfectly fits my needs.

Emmanuel Dreyfus a \ufffdcrit :
> On Wed, Sep 24, 2008 at 09:01:24AM +0200, Benoit Branciard wrote:
>> The attached "update-greylistconf" script is the thing I use for this purpose.
> 
> I wonder if a command line flag could not help here: milter-greylist -e
> would edit a copy of greylist.conf with your favourite $EDITOR, validate
> it, and replace the original if the new file is fine. 
> 
> That should not be very difficult to implement. Opinion, anyone?
> 

I don't consider this "the rignt way".

1) It add some (minor) complexity tho the daemon itself, while the same 
goal could be achieved by an external program.

2) It is "interactive-oriented" and adds nothing for scipted tasks.

3) It depends on the $EDITOR variable, which in my case never points to 
the right "favourite" editor as I'm too lazy to update it on every 
server I administer (how a nightmare to be sure this variable is OK for 
my personal account, for the root account, in a login/not login shell...).


Another approach which seems rather cute to me would be to handle this 
in the daemon starting script (/etc/init.d/milter-greylist on usual 
System V Unixes):
- "start" command: validates /etc/greylist.conf with "-c", and in case 
of success, copies it to /var/lib/milter-greylist/greylist.conf and 
starts the daemon;
- "stop" stops the daemon (as usual)
- "reload" validates /etc/greylist.conf with "-c", and in case of 
success copies it to /var/lib/milter-greylist/greylist.conf (without 
restarting the daemon)

And of course, milter-greylist would be compiled with a config-file path 
set to /var/lib/milter-greylist/greylist.conf.

Not very difficult to do, and well-suited for packaging milter-greylist 
for various distributions (Debian...)

I could write it some day when I find time to do it.

-- 
Ce message a ete verifie par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a ete trouve.

On Wed, Sep 24, 2008 at 07:24:52AM -0400, Greg Troxel wrote:
> I find milter-greylist's auto-rereading a bit aggressive, and think it
> might be better to just do that on SIGHUP like inetd and others.
> Then one could "/etc/rc.d/milter-greylist reload" or ".. check".

We cannot: the milter API says libmilter takes care of signals.

-- 
Emmanuel Dreyfus
manu@...

Emmanuel Dreyfus wrote:
 > On Wed, Sep 24, 2008 at 07:24:52AM -0400, Greg Troxel wrote:
 > > I find milter-greylist's auto-rereading a bit aggressive, and think it
 > > might be better to just do that on SIGHUP like inetd and others.
 > > Then one could "/etc/rc.d/milter-greylist reload" or ".. check".
 > 
 > We cannot: the milter API says libmilter takes care of signals.

Just a small hint:  Besides signals, there are other
ways for inter-process communication.  For example
UNIX domain sockets, FIFOs, POSIX named semaphores
or SysV semaphores.  Another, very simple way would
be to use an empty "flag file", which milter-greylist
uses to check the mtime instead of the actual conf
file.

However, all of that doesn't solve the real problem:
If the configuration file contains an error, milter-
greylist will terminate.

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

"C++ is the only current language making COBOL look good."
        -- Bertrand Meyer

I agree fully,
If there was any SIMPLE (lets keep the milter daemon as simple as
possible) solution, I would vote for it. Current situation is not nice.
Either:
1. keep the old configuration in case error detection.
2. Bail out but SHOUT LOUDLY

Ondrej
Oliver Fromme wrote:

>
>
> Emmanuel Dreyfus wrote:
> > On Wed, Sep 24, 2008 at 07:24:52AM -0400, Greg Troxel wrote:
> > > I find milter-greylist's auto-rereading a bit aggressive, and think it
> > > might be better to just do that on SIGHUP like inetd and others.
> > > Then one could "/etc/rc.d/milter-greylist reload" or ".. check".
> >
> > We cannot: the milter API says libmilter takes care of signals.
>
> Just a small hint: Besides signals, there are other
> ways for inter-process communication. For example
> UNIX domain sockets, FIFOs, POSIX named semaphores
> or SysV semaphores. Another, very simple way would
> be to use an empty "flag file", which milter-greylist
> uses to check the mtime instead of the actual conf
> file.
>
> However, all of that doesn't solve the real problem:
> If the configuration file contains an error, milter-
> greylist will terminate.
>
> Best regards
> Oliver
>
> -- 
> Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
> Handelsregister: Registergericht Muenchen, HRA 74606, Gesch�ftsfuehrung:
> secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M�n-
> chen, HRB 125758, Gesch�ftsf�hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart
>
> FreeBSD-Dienstleistungen, -Produkte und mehr:
> http://www.secnetix.de/bsd <http://www.secnetix.de/bsd>
>
> "C++ is the only current language making COBOL look good."
> -- Bertrand Meyer
>
>

Ondrej Valousek <webserv@...> wrote:

> 2. Bail out but SHOUT LOUDLY

It does, because milter-greylist has a built-in alert system: if it
dies, mail gets tempfailed, users get frustrated, and your phone rings
:-)

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

manu@... a \ufffdcrit :
> Ondrej Valousek <webserv@...> wrote:
> 
>> 2. Bail out but SHOUT LOUDLY
> 
> It does, because milter-greylist has a built-in alert system: if it
> dies, mail gets tempfailed, users get frustrated, and your phone rings
> :-)
> 

It depends on how you configured your milter in sendmail.cf (with or 
without "F=T").

Either mails get tempfailed and noone can receive anything, either all 
mail pass through whithout being greylisted at all.

But in both cases your phone will ring... :-)

-- 
Ce message a ete verifie par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a ete trouve.

> Emmanuel Dreyfus wrote:
>  > On Wed, Sep 24, 2008 at 07:24:52AM -0400, Greg Troxel wrote:
>  > > I find milter-greylist's auto-rereading a bit aggressive, and 
> think it > > might be better to just do that on SIGHUP like inetd 
> and others. > > Then one could "/etc/rc.d/milter-greylist reload" or 
> ".. check". >  > We cannot: the milter API says libmilter takes care 
> of signals.
> 
> Just a small hint:  Besides signals, there are other
> ways for inter-process communication.  For example
> UNIX domain sockets, FIFOs, POSIX named semaphores
> or SysV semaphores.  Another, very simple way would
> be to use an empty "flag file", which milter-greylist
> uses to check the mtime instead of the actual conf
> file.
> 
> However, all of that doesn't solve the real problem:
> If the configuration file contains an error, milter-
> greylist will terminate.

This used to bother me the first few weeks of using milter-greylist, now,
every single time I make a change to the greylist.conf file, my next command
after saving that file involves a "milter-greylist -cf /etc/mail/greylist".

Get into the habit of doing that and the milter-greylist config error problem
goes away.

Regards,

Michael.

> 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
> 
> "C++ is the only current language making COBOL look good."
>         -- Bertrand Meyer
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
>

Hi Emmanuel,

> If there is auto-reload, it would be nice to read and validate it and
> only swap it in if it's ok.

Is that a feasible option?

Any time I make changes I manually run the -cf, but maybe the above could
automate that procedure?

Michael.

Benoit Branciard <benoit.branciard@...> wrote:

> > It does, because milter-greylist has a built-in alert system: if it
> > dies, mail gets tempfailed, users get frustrated, and your phone rings

> It depends on how you configured your milter in sendmail.cf (with or 
> without "F=T").
> Either mails get tempfailed and noone can receive anything, either all
> mail pass through whithout being greylisted at all.
> But in both cases your phone will ring... :-)

I prefer to tempfail, as milter-greylist also blocks a lot of viruses...

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

> 
> On Wed, Sep 24, 2008 at 07:24:52AM -0400, Greg Troxel wrote:
> > I find milter-greylist's auto-rereading a bit aggressive, 
> and think it
> > might be better to just do that on SIGHUP like inetd and others.
> > Then one could "/etc/rc.d/milter-greylist reload" or ".. check".
> 
> We cannot: the milter API says libmilter takes care of signals.
> 

We can: what the documentation means by this statement is that the
libmilter is signal aware,
signals can be safely used.
I think we had discussion on this topic years ago on this list.

Bests,
Attila