Milter-greylist

Hi,

I've cross checked code, usage() and man pages for all options (command line
and greylist.conf), and after these changes everything should be consistent:

In greylist.conf.5, line 289, the "verbose" option (enable debug output)
is mentioned to be equivalent to -d, while it is really -v which 
enables debug output.

Additionally, the "lazyaw" option is missing from the greylist.conf
man page.

Other ideas:

The -l command line option (enable debug in acl code) to milter-greylist
doesn't have an equivalent option for greylist.conf - I guess it would
make sense to add this. Could be useful to enable acl debugging on the
fly, and the only other command line options without equivalent greylist.conf
options are -c, -f configfile, -h, and -r (greylist.conf options for
those wouldn't make sense).

Is there anybody running milter-greylist without a greylist.conf ?
One could argue that it makes sense to remove all but those 4 command
line options completely, and leave configuration to greylist.conf.
It's cleaner to update the configuration file than the startup file
to modify milter-greylist behaviour, and the documentation would
become more straight-forward. Opinions, anyone ?

mp.

Martin Paul <martin@...> wrote:
> In greylist.conf.5, line 289, the "verbose" option (enable debug output)
> is mentioned to be equivalent to -d, while it is really -v which 
> enables debug output.
> 
> Additionally, the "lazyaw" option is missing from the greylist.conf
> man page.

Can you send me a ptch for that? (make a jumbo patch that includes your
previous usage() fixup proposal, that will be more convenient for me)

> The -l command line option (enable debug in acl code) to milter-greylist
> doesn't have an equivalent option for greylist.conf - I guess it would
> make sense to add this. Could be useful to enable acl debugging on the
> fly, and the only other command line options without equivalent greylist.conf
> options are -c, -f configfile, -h, and -r (greylist.conf options for
> those wouldn't make sense).
> 
> Is there anybody running milter-greylist without a greylist.conf ?
> One could argue that it makes sense to remove all but those 4 command
> line options completely, and leave configuration to greylist.conf.
> It's cleaner to update the configuration file than the startup file
> to modify milter-greylist behaviour, and the documentation would
> become more straight-forward. Opinions, anyone ?

Removing command line option breaks backward compatibility and it's
annoying for people that use them. I think we should not do that without
a very good reasons. 

But we can undocument some command line options, or state that they are
deprecated and that the config file option should be used instead. We
did it already.

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