Milter-greylist

Do the entries in the Greylist.conf sync with peers? I know I could use one common Greylist.conf file and scp it out to each of my mx servers, but then each server would have themselves listed as a peer. One other thought was that maybe milter-greylist uses mxsync to send permanent whitelisted servers between peers. Is this true?

Any ideas would be appreciated.

Brian.

Brian Snead <BSnead@...> wrote:

> Do the entries in the Greylist.conf sync with peers? I know I could use
> one common Greylist.conf file and scp it out to each of my mx servers,
> but then each server would have themselves listed as a peer. One other
> thought was that maybe milter-greylist uses mxsync to send permanent
> whitelisted servers between peers. Is this true?

I have a script that scp the greylist.conf file on my MX servers and
then cat >> a greylist.conf.local which contains the peer entries.

I'm not sure it's worth adding complicated features in mxsync for this.
Complicated features means bugs, bugs may mean security holes, and
security holes leads to the dark side of the force.

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

Would you be willing to share the script. I agree that the mxsync should not sync the conf file, but I think you can make a case for it treating each mx servers' hardcoded addr records on startup?

Thankyou,
Brian.

-----Original Message-----
From: manu@... [mailto:manu@...]
Sent: Wednesday, June 23, 2004 2:40 PM
To: milter-greylist@yahoogroups.com
Subject: Re: [milter-greylist] Greylist.conf Sync Question


Brian Snead <BSnead@infosysnetworks.com> wrote:

> Do the entries in the Greylist.conf sync with peers? I know I could use
> one common Greylist.conf file and scp it out to each of my mx servers,
> but then each server would have themselves listed as a peer. One other
> thought was that maybe milter-greylist uses mxsync to send permanent
> whitelisted servers between peers. Is this true?

I have a script that scp the greylist.conf file on my MX servers and
then cat >> a greylist.conf.local which contains the peer entries.

I'm not sure it's worth adding complicated features in mxsync for this.
Complicated features means bugs, bugs may mean security holes, and
security holes leads to the dark side of the force.

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...



 
Yahoo! Groups Links

Brian Snead <BSnead@...> wrote:

> Would you be willing to share the script. I agree that the mxsync should
> not sync the conf file, but I think you can make a case for it treating
> each mx servers' hardcoded addr records on startup?

Well, there is nothing exciting here:
 
On each MX, I have /etc/mail/greylist.conf.local that contains the peer
statements

The script that pushes the new configuration does that:

MX="mx1.example.net mx2.example.net mx3.example.net"
for m in $MX ; do 
        scp greylist.conf $m:/etc/mail/
        ssh $m cat /etc/mail/greylist.conf.local \
                >> /etc/mail/greylist.conf
done

And everything is done with RSA keys so that it won't ask a password.
You can do it with an unprivilegied account, it just needs to have a
write right on /etc/mail/greylist.conf on each MX server.

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

It never ceases to amaze me how easy things are to do in Linux. Your 
script is great and I will implement it.

I do have one question, I see that you don't restart the milter after 
changing the conf file. Does the milter dynamically read the conf file, 
or do we have to restart after each change?

Thanks
Brian.

manu@... wrote:

>Brian Snead <BSnead@...> wrote:
>
>  
>
>>Would you be willing to share the script. I agree that the mxsync should
>>not sync the conf file, but I think you can make a case for it treating
>>each mx servers' hardcoded addr records on startup?
>>    
>>
>
>Well, there is nothing exciting here:
> 
>On each MX, I have /etc/mail/greylist.conf.local that contains the peer
>statements
>
>The script that pushes the new configuration does that:
>
>MX="mx1.example.net mx2.example.net mx3.example.net"
>for m in $MX ; do 
>        scp greylist.conf $m:/etc/mail/
>        ssh $m cat /etc/mail/greylist.conf.local \
>                >> /etc/mail/greylist.conf
>done
>
>And everything is done with RSA keys so that it won't ask a password.
>You can do it with an unprivilegied account, it just needs to have a
>write right on /etc/mail/greylist.conf on each MX server.
>
>  
>

brian Snead <BSnead@...> wrote:

> It never ceases to amaze me how easy things are to do in Linux. Your 
> script is great and I will implement it.

Well, I'd even say that things are simple on Unix systems: I don't run
MX on my mail servers.
 
> I do have one question, I see that you don't restart the milter after
> changing the conf file. Does the milter dynamically read the conf file,
> or do we have to restart after each change?

It's in the documentation: the file is reloaded when a new mail reach
the RCPT stage and the config file was modified. As most parameters are
dynamically changable, you should never need to restart milter-greylist,
except for rebooting the machine, upgrading milter-greylist, changing
the socket, or changing the user running milter-greylist.

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

Dear all,

I'd installed  <milter-greylist> and <milter-regex> with sendmail on  
the same FreeBSD machines.

I wonder if there are obvious differences in performance (and others, if 
any) on the issue of the
running order of <milter-regex> and <milter-greylist> with sendmail. 
--That is, if there are difference between the following two 
configuration  sendmail options:  (sendmail.cf)

> O InputMailFilters=greylist,milter-regex,clamav        (e.g.,  running 
> greylist first)

> O InputMailFilters=milter-regex,greylist,clamav      (e.g., running 
> milter-regex first)



-cschen

C.S.Chen <cschen@...> wrote:

> I wonder if there are obvious differences in performance (and others, if
> any) on the issue of the
> running order of <milter-regex> and <milter-greylist> with sendmail. 
> --That is, if there are difference between the following two 
> configuration  sendmail options:  (sendmail.cf)

milter-greylist will reject at the RCPT stage. If you use milter-regex
as a content filter, order makes no difference, because milter-greylist
will always has done his job when milter-regex will check the DATA
stage.

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

manu@... wrote:

>C.S.Chen <cschen@...> wrote:
>  
>
>>I wonder if there are obvious differences in performance (and others, if
>>any) on the issue of the
>>running order of <milter-regex> and <milter-greylist> with sendmail. 
>>--That is, if there are difference between the following two 
>>configuration  sendmail options:  (sendmail.cf)
>>    
>>
>
>milter-greylist will reject at the RCPT stage. If you use milter-regex
>as a content filter, order makes no difference, because milter-greylist
>will always has done his job when milter-regex will check the DATA
>stage.
>

So, do you mean that <milter-regex> and <milter-greylist> runs 
concurrently instead of sequentially ?

> O InputMailFilters=milter-regex,greylist,clamav,spamc

However, in the above configuration, as I observed from some system log 
excerpt, since a connection had been rejected by
<milter-regex>, the  <spamass-milter> (or spamc )  seemed to receive the 
same connection with NULL content (because it is
rejected by milter-regex in the first phase).

=======================================================================================
Jul 12 09:44:24 ns2 milter-regex[14311]: 218.164.157.97: 
cb_connect('218-164-157-97.dynamic.hinet.net', '218.164.157.97')
Jul 12 09:44:24 ns2 milter-regex[14311]: 218.164.157.97: REJECT: 
Rejected, SPAM from TwIspBL (Ra-1); any problem, call +886-3-
5731721 !, From: , To: , Subject:
Jul 12 09:44:24 ns2 milter-regex[14311]: 218.164.157.97: cb_close()
Jul 12 09:44:24 ns2 spamass-milter[216]: NULL context in mlfi_close! 
Should not happen!
Jul 12 09:44:24 ns2 sm-mta[42921]: i6C1iOwL042921: Milter: connect: 
host=218-164-157-97.dynamic.hinet.net, addr=218.164.157.97
, rejecting commands
======================================================================================

-cschen

C.S.Chen <cschen@...> wrote:

> So, do you mean that <milter-regex> and <milter-greylist> runs 
> concurrently instead of sequentially ?

Here is roughtly how it works

foreach stage in (connect, helo, from, rcpt, headers, body, disconnect)
        foreach milter in (<configured milters>)
                callback $milter's $stage function
-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...