Milter-greylist

running CentOS 5.5 + postfix 2.3

using the follow line in my config

racl greylist default delay 4m addheader "X-Greylist-OS: %Fx"


however I get the follow error

milter-greylist: smfi_getsymval failed for {if_addr}


and %Fx always return an empty value.

Does milter-greylist support postfix+p0f ???

gitoshi <gitoshi@...> wrote:

> Does milter-greylist support postfix+p0f ???

Not yet, but that seems easy to fix.

The p0f interface require the local interface IP address. Sendmail makes
it available through the {if_addr} macro, and milter-greylist can read
it using this:
    smfi_getsymval(priv->priv_ctx, "{if_addr}")

Unfortunately, Postfix does not provide this macro. If you only have one
public IP, then you can hack milter-greylist to hardcode it. 
In p0f.c:p0f_lookup() you can set your own address instead of going
through the code block you are currently failing:

    if ((daddr = smfi_getsymval(priv->priv_ctx, "{if_addr}")) == NULL) {
        mg_log(LOG_DEBUG, "smfi_getsymval failed for {if_addr}");
        return -1;
    }

Replacing it by something like this should do the trick:
    daddr = "192.0.2.1";


But this is a hack, and I think we can do better. I wonder if it would
make sense to add a configuration option to specify the mail server
public IP address to work around this Postfix missing feature. It will
certainly break on machines with multiples IP. Opinions anyone? Any
better idea?

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

manu@... writes:

> gitoshi <gitoshi@...> wrote:
>
>> Does milter-greylist support postfix+p0f ???
>
> Not yet, but that seems easy to fix.
>
> The p0f interface require the local interface IP address. Sendmail makes
> it available through the {if_addr} macro, and milter-greylist can read
> it using this:
>     smfi_getsymval(priv->priv_ctx, "{if_addr}")
>
> Unfortunately, Postfix does not provide this macro. If you only have one
> public IP, then you can hack milter-greylist to hardcode it. 
> In p0f.c:p0f_lookup() you can set your own address instead of going
> through the code block you are currently failing:
>
>     if ((daddr = smfi_getsymval(priv->priv_ctx, "{if_addr}")) == NULL) {
>         mg_log(LOG_DEBUG, "smfi_getsymval failed for {if_addr}");
>         return -1;
>     }
>
> Replacing it by something like this should do the trick:
>     daddr = "192.0.2.1";
>
>
> But this is a hack, and I think we can do better. I wonder if it would
> make sense to add a configuration option to specify the mail server
> public IP address to work around this Postfix missing feature. It will
> certainly break on machines with multiples IP. Opinions anyone? Any
> better idea?


I have run into this as well.

How hard is it to patch postfix?  I would think postfix people would
look upon this reasonably, and we could certainly put the patch in
pkgsrc.
I have been meaning to do this, but lack of p0f has not been high on my
list of problems to solve lately.

Greg Troxel <gdt@...> wrote:

> How hard is it to patch postfix?  

No idea, I have not looked at the code at all. But indeed this is the
right way, we just need someone to do it.


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

here the workaround

Some Milter applications use the "{if_addr}" macro to recognize local mail; this macro does not exist in Postfix. Workaround: use the "{client_addr}" macro instead. 

http://www.postfix.org/MILTER_README.html#workarounds

however I´dont like the idea of patch my stable MTA.
Lot of people stick to only stable/precompile packages.


--- In milter-greylist@yahoogroups.com, manu@... wrote:

>
> Greg Troxel <gdt@...> wrote:
> 
> > How hard is it to patch postfix?  
> 
> No idea, I have not looked at the code at all. But indeed this is the
> right way, we just need someone to do it.
> 
> 
> -- 
> Emmanuel Dreyfus
> http://hcpnet.free.fr/pubz
> manu@...
>

Hi,

Here is another workaround. :)

In <ii4dot+3247@...>
  "[milter-greylist] Re: p0f + postfix" on Sun, 30 Jan 2011 19:22:05 -0000,
  "gitoshi" <gitoshi@...> wrote:

> here the workaround
> 
> Some Milter applications use the "{if_addr}" macro to recognize local mail;
> this macro does not exist in Postfix. Workaround: use the "{client_addr}" macro
> instead.
> 
> http://www.postfix.org/MILTER_README.html#workarounds
> 
> however I´dont like the idea of patch my stable MTA.
> Lot of people stick to only stable/precompile packages.

{client_addr} returns SMTP client's IP address not Postfix's
interface IP address. So we can't use it as {if_addr}
replacement.

milter manager 1.6.5 (*) can solve it. :)
(*) http://milter-manager.sourceforge.net/

milter manager is a meta-milter. milter manager works
between MTA and milters:

                                   <-> milter1
  MTA (Postfix) <-> milter manager <-> milter2
                                   <-> milter3

milter manager can set any milter macros. They includes
{client_addr}.

                                   <-------------> milter1 (milter-greylist)
                                    {client_addr}
  MTA (Postfix) <-> milter manager <-------------> milter2
                    {client_addr}   {client_addr}
                        (new!)     <-------------> milter3
                                    {client_addr}

milter manager uses netstat(8) and SMTP client's IP address
and port for resolving MTA's interface IP address.


If you follow the install documentation, you can use the
above configuration:
  http://milter-manager.sourceforge.net/reference/install-to-centos.html


Thanks,
--
kou

Kouhei Sutou <kou@...> wrote:

> {client_addr} returns SMTP client's IP address not Postfix's
> interface IP address. So we can't use it as {if_addr}
> replacement.

As I understand, fixing the thing id therefore beyond what we can do in
milter-greylist.

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

Hi,

In <1jvycn0.1r1md0uergtzvM%manu@...>
  "Re: [milter-greylist] Re: p0f + postfix" on Mon, 31 Jan 2011 09:22:37 +0100,
  manu@... wrote:

>> {client_addr} returns SMTP client's IP address not Postfix's
>> interface IP address. So we can't use it as {if_addr}
>> replacement.
> 
> As I understand, fixing the thing id therefore beyond what we can do in
> milter-greylist.

I agree.


Thanks,
--
kou