Milter-greylist

Hi,

  I just implemented the multiple mx feature of milter-greylist on 4
servers, but I have a few questions:

  1- Do I have to put all 4 mx servers in greylist.conf or only the "3
others"?

  2- There is one servers that doesn't seem to work:

- grep mxsync /var/log/maillog returns nothing (while all other
servers do return many syncs)

[root@server2 root]# netstat -an | grep 5252
tcp        0      0 0.0.0.0:5252                0.0.0.0:*            
      LISTEN
tcp        0      0 server2:49417        server1:5252         ESTABLISHED
tcp        0      0 server2:49415        server4:5252          
ESTABLISHED
tcp        0      0 server2:49416        server3:5252           
ESTABLISHED

[root@server4 root]# netstat -an | grep 5252
tcp        0      0 0.0.0.0:5252                0.0.0.0:*            
      LISTEN
tcp        0      0 server4:5252           server1:35182       
ESTABLISHED
tcp        0      0 server4:5252           server2:49415       
ESTABLISHED
tcp        0      0 server4:5252           server3:50223          
ESTABLISHED


On the servers that work ok, I can see this kind of record in my logs:

Dec 11 14:15:37 gateway4 milter-greylist: Incoming MX sync connexion
from 10.10.10.10

But all I can find on server2 is 

Dec 11 15:07:38 gateway2 milter-greylist: Connection to x.x.x.x
established

What should I try next?

Thanks,

Ugo

--- In milter-greylist@yahoogroups.com, "Ugo Bellavance"
<iolubik@y...> wrote:
>
> Hi,
> 
>   I just implemented the multiple mx feature of milter-greylist on 4
> servers, but I have a few questions:
> 
>   1- Do I have to put all 4 mx servers in greylist.conf or only the "3
> others"?
> 
>   2- There is one servers that doesn't seem to work:

<snip>

Sorry, I found it: firewall issue.  server2 was blocking incoming
connexions with iptables rules.

But my question about the config file is still valid and I'd still
like to know whether it is possible to put the milter in learning mode
(feeding the DB with all messages, but causing no delays...
autowhitelisting everything finally.)

Thanks,

Ugo

Ugo Bellavance <iolubik@...> wrote:

> Sorry, I found it: firewall issue.  server2 was blocking incoming
> connexions with iptables rules.
> 
> But my question about the config file is still valid and I'd still
> like to know whether it is possible to put the milter in learning mode
> (feeding the DB with all messages, but causing no delays...
> autowhitelisting everything finally.)

You can patch the milter to replace tempfail by success...

-- 
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org

--- In milter-greylist@yahoogroups.com, manu@n... wrote:
>
> Ugo Bellavance <iolubik@y...> wrote:
> 
> > Sorry, I found it: firewall issue.  server2 was blocking incoming
> > connexions with iptables rules.
> > 
> > But my question about the config file is still valid and I'd still
> > like to know whether it is possible to put the milter in learning mode
> > (feeding the DB with all messages, but causing no delays...
> > autowhitelisting everything finally.)
> 
> You can patch the milter to replace tempfail by success...

Yes... thanks.  But I'm not much of a programmer and I don't really
want to mess anything up.  Would it be possible to implement this as a
parameter in a future release?

Regards,

Ugo

On Mon, Dec 12, 2005 at 03:48:02AM -0000, Ugo Bellavance wrote:
> > You can patch the milter to replace tempfail by success...
> 
> Yes... thanks.  But I'm not much of a programmer and I don't really
> want to mess anything up.  Would it be possible to implement this as a
> parameter in a future release?

Sure, if someone does it. Since you desire the feature, you seem to be
the right person for implementing it. And that's a good opportunity to 
learn about programming.

Quickly hacking it is not difficult, edit miller-greylist.c, and replace
SMFIS_TEMPFAIL by SMFIS_SUCCESS. You can even do a nicer hack by not changing
the occurence after the malloc failure (when you are out of memory, you 
temporarily reject until things get better).

The next step is to add a configuration option, which is a bit more complex,
but after all you just have to replicate what is already done for other 
options, such as noaccessdb. You have to edit the following files, duplicate
the lines where you have noaccessdb and replace noaccessdb by learnmode:
conf_lex.l conf_yacc.y conf.c conf.h

The remaining part is straightforward: replace your SMFIS_SUCCESS change by 
if (conf.c_learnmode) 
	return SMFIS_SUCCESS;
else
	return SMFIS_TEMPFAIL;

After this, be nice and add this new option to the man page (greylist.conf.5),
and contribute the result. 

-- 
Emmanuel Dreyfus
manu@...

--- In milter-greylist@yahoogroups.com, Emmanuel Dreyfus <manu@n...>
wrote:
>
> On Mon, Dec 12, 2005 at 03:48:02AM -0000, Ugo Bellavance wrote:
> > > You can patch the milter to replace tempfail by success...
> > 
> > Yes... thanks.  But I'm not much of a programmer and I don't really
> > want to mess anything up.  Would it be possible to implement this as a
> > parameter in a future release?
> 
> Sure, if someone does it. Since you desire the feature, you seem to be
> the right person for implementing it. And that's a good opportunity to 
> learn about programming.
> 
> Quickly hacking it is not difficult, edit miller-greylist.c, and replace
> SMFIS_TEMPFAIL by SMFIS_SUCCESS. You can even do a nicer hack by not
changing
> the occurence after the malloc failure (when you are out of memory, you 
> temporarily reject until things get better).
> 
> The next step is to add a configuration option, which is a bit more
complex,
> but after all you just have to replicate what is already done for other 
> options, such as noaccessdb. You have to edit the following files,
duplicate
> the lines where you have noaccessdb and replace noaccessdb by learnmode:
> conf_lex.l conf_yacc.y conf.c conf.h
> 
> The remaining part is straightforward: replace your SMFIS_SUCCESS
change by 
> if (conf.c_learnmode) 
> 	return SMFIS_SUCCESS;
> else
> 	return SMFIS_TEMPFAIL;
> 
> After this, be nice and add this new option to the man page
(greylist.conf.5),
> and contribute the result. 

Hi,

did all that, but getting this error when compiling:

[root@mta1 milter-greylist-2.0.2]# make
gcc -g -O2 -Wall -D_XOPEN_SOURCE=500 -D_BSD_SOURCE   -c -o
milter-greylist.o milter-greylist.c
milter-greylist.c: In function `mlfi_envrcpt':
milter-greylist.c:413: error: `SMFIS_SUCCESS' undeclared (first use in
this function)
milter-greylist.c:413: error: (Each undeclared identifier is reported
only once
milter-greylist.c:413: error: for each function it appears in.)
milter-greylist.c: In function `mlfi_eom':
milter-greylist.c:439: error: `SMFIS_SUCCESS' undeclared (first use in
this function)

I don't know where is defined oter "SMFIS_".  Or is it SMFIS_CONTINUE?

I can provide my code if needed.

Regards,

> 
> -- 
> Emmanuel Dreyfus
> manu@n...
>

On Mon, Dec 12, 2005 at 12:28:54PM -0000, Ugo Bellavance wrote:
> did all that, but getting this error when compiling:
> 
> [root@mta1 milter-greylist-2.0.2]# make
> gcc -g -O2 -Wall -D_XOPEN_SOURCE=500 -D_BSD_SOURCE   -c -o
> milter-greylist.o milter-greylist.c
> milter-greylist.c: In function `mlfi_envrcpt':
> milter-greylist.c:413: error: `SMFIS_SUCCESS' undeclared (first use in
> this function)

(snip)

> I don't know where is defined oter "SMFIS_".  Or is it SMFIS_CONTINUE?

Yes, you figured it on your own. 
If someday you don't,the documentation is here:
http://www.milter.org/milter_api/
The return codes are at the bottom of this page:
http://www.milter.org/milter_api/api.html

-- 
Emmanuel Dreyfus
manu@...

Ugo Bellavance wrote on Mon, 12 Dec 2005 12:28:54 -0000:

> I don't know where is defined oter "SMFIS_".  Or is it SMFIS_CONTINUE?

Yeah, no SMFIS_SUCCESS. Here are the constants that are available:

n8:/usr/include/libmilter # grep SMFIS_ *
mfapi.h:**  This may take on one of the SMFIS_* values listed below.
mfapi.h:#define SMFIS_CONTINUE  0
mfapi.h:#define SMFIS_REJECT    1
mfapi.h:#define SMFIS_DISCARD   2
mfapi.h:#define SMFIS_ACCEPT    3
mfapi.h:#define SMFIS_TEMPFAIL  4

Kai

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