Milter-greylist

I installed milter-greylist about a week or so ago on a low-volume 
production machine (SuSE 9.0) for testing and am very satisfied overall. 
It just looks like I may have to stop it every now and then, so my bayes 
filter may acquire some new information. ;-)

I have a few questions which arose right after installing and configuring, 
but it took me some time to get on this list due to my blacklisting yahoo.
 
1. I'm getting an error 
Milter (greylist): error connecting to filter: Connection refused by 
/var/milter-greylist/milter-greylist.sock 
 
each time I restart the milter with the provided init script. As I heard 
in the meantime this is normal and I don't need to restart/reload the 
milter after configuration changes, so in the future I will rarely need to 
restart the milter. But I still wonder why this happens. I run a different 
milter on another machine which needs to get restarted to take 
configuration changes and there sendmail won't complain.
 
2. compiling with the latest libspf2 throws this linker error 
In file included from /usr/local/include/spf2/spf.h:27, 
                from spf.c:228: 
/usr/local/include/spf2/spf_server.h:23:30: spf_dns_internal.h: No such 
file or directory 
 
I installed libspf2 before compiling the milter. As it turns out the 
spf_dns_internal.h wasn't copied from the source directory to the lib 
includes by make install. It's not clear from your instructions on the 
website if one should install libspf2 or just use the headers in the 
source. I have just used headers from the source without installing in the 
past with other projects, but sometimes you get other linker errors 
because the files in the source may be arranged in a different hierarchy 
than how they get included. So, I think the preferrable method actually is 
to install them? I copied the file to where it was looked for and 
everything worked fine then. If it is a bug then it is a bug in the 
libspf2 install, of course. Nevertheless, I thought it's 
worth mentioning. 
 
3. I set the option "lazyaw". The tuples get still collected in 
greylist.db although only the IP should be relevant now. So, it's not 
clear if it uses IP only or the (IP, sender, recipient) tuple now. Same 
goes for the X-Greylist header, it still says "whitelisted by" all three, 
so it's not clear from there either. 
 
4. X-Greylist is adding quite a long text, it would be nice to have an 
option to either use templates for it or set a "short mode", f.i.: 
X-Greylist: Sender IP whitelisted 
X-Greylist: Delayed 00:30:00 
 
5. I set "greylist 10m", but the milter says "come back in 00:14:00". Is 
there a limit 
of 14 minutes or 4+config minutes? 


Kai

-- 
Kai Sch\ufffdtzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com

I can answer question 1 and 5 myself.

1. I assumed the milter was really getting started since the start script 
says so. Actually, after a restart it is dead. So there's no socket to 
connect to. It seems that the stop start sequence in the init script is 
too fast. It works after inserting a sleep 2. (Didn't try sleep 1.)

2. The Suse init script contains options values that override the 
greylist.conf:
OPTIONS="-T -L 24 -w 14m -P $pidfile -u $user -p $socket"
This should be changed to:
OPTIONS="-P $pidfile -u $user -p $socket" which is equivalent to what the 
other init scripts do. Or, even better, all of this should be fetched from 
greylist.conf, shouldn't it?
I also noticed that the T option doesn't seem to override the options in 
greylist.conf, while the others do.

Kai

-- 
Kai Sch\ufffdtzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com

Kai Schaetzl <maillists@...> wrote:

> I can answer question 1 and 5 myself.
> 
> 1. I assumed the milter was really getting started since the start script
> says so. Actually, after a restart it is dead. So there's no socket to
> connect to. It seems that the stop start sequence in the init script is
> too fast. It works after inserting a sleep 2. (Didn't try sleep 1.)

Can you provide the patch for that?
 
> 2. The Suse init script contains options values that override the 
> greylist.conf:
> OPTIONS="-T -L 24 -w 14m -P $pidfile -u $user -p $socket"
> This should be changed to:
> OPTIONS="-P $pidfile -u $user -p $socket" which is equivalent to what the
> other init scripts do. Or, even better, all of this should be fetched from
> greylist.conf, shouldn't it?

Probably. :-)

> I also noticed that the T option doesn't seem to override the options in
> greylist.conf, while the others do.

It should. Do you contribute the fix? (that's an easy one)

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

wrote on Sat, 10 Dec 2005 19:27:28 +0100:

> It should. Do you contribute the fix? (that's an easy one)

I made my changes only to the deployed files not to the source. I should 
be able to provide a diff against the original or a changed init SuSE init 
script. But I don't want to touch the C source. I have done some C(++) 
coding in the past, but not enough that I could immediately find and 
correct the problem. I didn't have a single look at the code yet. I'm also 
not sure if my observation is correct, that's why I used "doesn't seem". I 
only deduced that from the fact that -T was given as a parameter in the 
init script, but the milter behaved according to greylist.conf settings.

Kai

-- 
Kai Sch\ufffdtzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com

Here's the diff against rc-suse.sh.in. From a short glimpse at 
milter-greylist.c and conf.c/h it looks like it should override. Maybe my 
deduction was wrong.


19c19
< OPTIONS="-T -L 24 -w 14m -P $pidfile -u $user -p $socket"
---
> OPTIONS="-P $pidfile -u $user -p $socket"
42a43
>   sleep 2


Kai

-- 
Kai Sch\ufffdtzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com

Kai Schaetzl wrote on Fri, 09 Dec 2005 19:02:14 +0100:

> 3. I set the option "lazyaw". The tuples get still collected in 
> greylist.db although only the IP should be relevant now. So, it's not 
> clear if it uses IP only or the (IP, sender, recipient) tuple now. Same 
> goes for the X-Greylist header, it still says "whitelisted by" all three, 
> so it's not clear from there either.

One observation regarding this. It seems that not all tuples get removed 
from the greylist once a server is whitelisted, f.i.:

greylist.db:212.66.8.12 <emarlist@...> 
1134412272 # 2005-12-12 19:31:12
greylist.db:212.66.8.12 <emarlist@...> 
1134412274 # 2005-12-12 19:31:14
greylist.db:212.66.8.12 <konlist@...> 
1134678152 AUTO # 2005-12-15 21:22:32

I removed the recipient's for privacy reasons.

The last line moved to the autowhitelist, but the first two lines remained 
in the greylist although a message with exactly this tuple went thru later 
as autowhitelisted. So, lazyaw works for the server, but only the first 
tuple to "initiate" the whitelisting gets removed from the greylist. All 
other remain on it. Will they expire?
Similar question: what happens with tuples that never try again. Will they 
eventually expire, f.i. after the default 72 hours expire for the 
autowhitelist? If not, the file will assemble a lot of garbage over time.


Kai

-- 
Kai Sch\ufffdtzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com