Milter-greylist

I realize it's probably too late for the next stable and I don't even
know if it has been discussed before but I would really like to see an
include option in greylist.conf similar to what BIND DNS has for
named.conf:

http://www.zytrax.com/books/dns/ch7/include.html

Basically, wherever "include <file>" is encountered it's replaced with
the contents of <file>. Reasons are the same as in the link above.

I'm ok with a change in one of the included files not triggering a
reload but that we have to HUP ourselves. That's not a problem.

What do others think? I love the syntax of greylist.conf and often use
it instead of Sendmail, if only I had the above feature I could
integrate log parsing scripts that would blacklist spammers, I don't
want to mess with the main file for that.

/peter bonivart

shuttlebox <shuttlebox@...> wrote:

> What do others think? I love the syntax of greylist.conf and often use
> it instead of Sendmail, if only I had the above feature I could
> integrate log parsing scripts that would blacklist spammers, I don't
> want to mess with the main file for that.

The include feature would be interesting, but we could also have an ACL
clause to lookup a string from a file. Like we have urlcheck and
ldapcheck:

filecheck "blacklist" "/var/run/blacklist.txt" "%i"
(...)
racl blacklist filecheck "blacklist"

The advantage is that you are less likely to mess the configuration if
you enter badly formatted data. I suspect we can improve the above
syntax to parse more complicated files.

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

On Mon, Feb 27, 2012 at 2:56 AM,  <manu@...> wrote:
> shuttlebox <shuttlebox@...> wrote:
>
>> What do others think? I love the syntax of greylist.conf and often use
>> it instead of Sendmail, if only I had the above feature I could
>> integrate log parsing scripts that would blacklist spammers, I don't
>> want to mess with the main file for that.
>
> The include feature would be interesting, but we could also have an ACL
> clause to lookup a string from a file. Like we have urlcheck and
> ldapcheck:
>
> filecheck "blacklist" "/var/run/blacklist.txt" "%i"
> (...)
> racl blacklist filecheck "blacklist"
>
> The advantage is that you are less likely to mess the configuration if
> you enter badly formatted data. I suspect we can improve the above
> syntax to parse more complicated files.

I would be fine with just being able to read a single column text
file, nothing more complicated than that in my case, I'm thinking
about making some of the lists external so your suggestion would work
for me. The include in BIND is more general though and can outsource
anything that can be in named.conf, however in my case I don't see any
real benefit to that compared to what you suggested.

/peter bonivart

> 
> I realize it's probably too late for the next stable and I don't even
> know if it has been discussed before but I would really like to see an
> include option in greylist.conf similar to what BIND DNS has for
> named.conf:
> 
> http://www.zytrax.com/books/dns/ch7/include.html
> 
> Basically, wherever "include <file>" is encountered it's replaced with
> the contents of <file>. Reasons are the same as in the link above.
> 
> I'm ok with a change in one of the included files not triggering a
> reload but that we have to HUP ourselves. That's not a problem.
> 
> What do others think? I love the syntax of greylist.conf and often use
> it instead of Sendmail, if only I had the above feature I could
> integrate log parsing scripts that would blacklist spammers, I don't
> want to mess with the main file for that.
> 
> /peter bonivart
> 

Hello,

I read through the examples for the "BIND" for the
advantage of having included configuration file.
By my opinion all the 3 arguments are going wrong
on the fact that when there is a new sub-configuration
file generated there has to be a notification system
to be in place (like sending HUP signal to the process)
which must be as priviledged as the BIND process itself.

If you write a code to verify for the new versions
of those files to send a HUP signal as well as you
could write a script instead which concatenates those
files into a single master config file.
(I am already doing that way!
I have a template file plus extractions from different
databases with formating script to generate the ACL
statements into the master config file.)

Syntax verification has to be done in both cases
so no difference on that.

With the include statement more code is required which
leads to bigger running process memory footprint as well
as higher chance having more bug in the code.

Bests,
Attila Bruncsak

This would be a really good feature!

One could plit lengthy files into groups.

It would be possibly "fairly easy" to implement if you do the merge the files just before you check the in the moment?

Jobst


On Mon, Feb 27, 2012 at 02:56:44AM +0100, manu@... (manu@...) wrote:
> shuttlebox <shuttlebox@...> wrote:
> 
> > What do others think? I love the syntax of greylist.conf and often use
> > it instead of Sendmail, if only I had the above feature I could
> > integrate log parsing scripts that would blacklist spammers, I don't
> > want to mess with the main file for that.
> 
> The include feature would be interesting, but we could also have an ACL
> clause to lookup a string from a file. Like we have urlcheck and
> ldapcheck:
> 
> filecheck "blacklist" "/var/run/blacklist.txt" "%i"
> (...)
> racl blacklist filecheck "blacklist"
> 
> The advantage is that you are less likely to mess the configuration if
> you enter badly formatted data. I suspect we can improve the above
> syntax to parse more complicated files.
> 
> -- 
> Emmanuel Dreyfus
> http://hcpnet.free.fr/pubz
> manu@...

-- 
The journey of a thousand steps begins with few hundred forgotten necessities.

  | |0| |   Jobst Schmalenbach, jobst@..., General Manager
  | | |0|   Barrett Consulting Group P/L & The Meditation Room P/L
  |0|0|0|   +61 3 9532 7677, POBox 277, Caulfield South, 3162, Australia

[Reviving an old discussion...]

--- In milter-greylist@yahoogroups.com, shuttlebox <shuttlebox@...> wrote:
>
> I realize it's probably too late for the next stable and I don't even
> know if it has been discussed before but I would really like to see an
> include option in greylist.conf similar to what BIND DNS has for
> named.conf:
> 
> http://www.zytrax.com/books/dns/ch7/include.html
> 
> Basically, wherever "include <file>" is encountered it's replaced with
> the contents of <file>. Reasons are the same as in the link above.
> 
> I'm ok with a change in one of the included files not triggering a
> reload but that we have to HUP ourselves. That's not a problem.
> 
> What do others think? I love the syntax of greylist.conf and often use
> it instead of Sendmail, if only I had the above feature I could
> integrate log parsing scripts that would blacklist spammers, I don't
> want to mess with the main file for that.
> 
> /peter bonivart
>

This would also make distribution maintaining easier. Parts of the file maintained by the distributor (socket location for example) or parts maintained upstream (the list of broken MTAs) can be updated without affecting the main config, that the user surely edited.

So what exactly is the problem about this feature?

Code bloat? The syntax is already quite interesting. It wouldn't add really much more complexity, IMHO.

That said, one option is of course to use m4 or cpp outside of milter-greylist and let m4/cpp create the final config from some source files. Like what sendmail.mc is doing. Then we can use m4's include() and be done.

As one bug part of the shipped config is the list of broken MTAs, it would be good if milter-greylist has a default way of doing this and would do it for that list. That way I get a fresh list on upgrade without having to copy it by hand into my main config.

Cheers

    Elrond

elrond421 <yahoo.com@...> wrote:

> So what exactly is the problem about this feature?

You need to monitor included file changes to detect configuration
changes. Feel free to send a patch to the list.

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

On Sun, May 19, 2013 at 3:43 AM,  <manu@...> wrote:
> elrond421 <yahoo.com@...> wrote:
>
>> So what exactly is the problem about this feature?
>
> You need to monitor included file changes to detect configuration
> changes. Feel free to send a patch to the list.

A simple way would be not to change anything! If we change an included
file we touch the greylist.conf-file ourselves to trigger a reload. I
think those who want this feature would be good with that.

/peter

I do use site-specific configurations (likely anyone does somehow)
by creating a number of files named like "greylist-01-common.conf"
and so on for manual whitelists, balcklists and other exceptions,
some of these are distributed via CVS to maintain commonality of
config on several relays, some files can optionally be local.

There's a cron-script which tries to pull updates from CVS, and if
any exist - in just does "cat greylist-??-*.conf > greylist.conf"
and restarts/refreshes the milter service.

This achieves the same goal as include files in a somewhat more
clumsy way, but without changes to milter-greylist, and works
for years.

Also, user-modifiable include files might be a security-breach
source by fooling the daemon into reading (or doing) something
that it shouldn't. This might be avoidable by some policy in the
milter-greylist (i.e. like sendmail is picky about POSIX flags),
or just make a warning in the docs, but the potential problem
should not be ignored and be kept unaware of. :)

//Jim Klimov