Milter-greylist

On Fri, Feb 26, 2016 at 4:03 PM, Mauricio Teixeira
mauricio.teixeira@gmail.com [milter-greylist]
<milter-greylist@yahoogroups.com> wrote:
>
> Guys,
>
> Is there a way to tell milter-greylist to disregard the recipient when making grey list decisions?
>
> Example: if a given server sends a message from no-reply@... to user1@..., it will get grey listed, then white listed 5 minutes later (by my configs). Now, if 10 minutes later the same server uses the same sender to send a message to user2@... it will be grey listed again. I would like to NOT grey list in this case, and simply make grey listing decisions based on sender IP + sender address, regardless of what the recipient address is.

The "lazyaw" option will use only the sending servers IP address, I
think it's either that or all three.

On Fri, Feb 26, 2016 at 12:03:35PM -0300, Mauricio Teixeira mauricio.teixeira@... [milter-greylist] wrote:
> I would like to NOT grey list in this case, and simply make grey
> listing decisions based on sender IP + sender address, regardless of what
> the recipient address is.

I am not sure I understood the problem, what is wrong with this?
racl greylist addr 192.0.2.1 from user@...

-- 
Emmanuel Dreyfus
manu@...

Mauricio Teixeira mauricio.teixeira@... [milter-greylist]
<milter-greylist@yahoogroups.com> wrote:

> "lazyaw" almost did it, but it only white lists the IP, not the sender.

You realize that the sender can be easily forged, right?

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

I do. But that doesn't really matter in our case.

Mauricio Teixeira
(sent from mobile, sorry for my brevity)

Mauricio Teixeira mauricio.teixeira@... [milter-greylist]
<milter-greylist@yahoogroups.com> wrote:

> I do. But that doesn't really matter in our case.

The relevant code is in pending.c:

                        /*
                         * Look for our record
                         */
                        if (ip_match(sa, pending->p_sa, mask) &&
                            ((conf.c_lazyaw == 1) ||
                            ((strcasecmp(from, pending->p_from) == 0) && 
                            (strcasecmp(rcpt, pending->p_rcpt) == 0)))) {


Hacking it in order to change lazyaw semantics and cause it to consider
IP+recpient is easy, you just have one line to move. But that change cannot be
integrated into the sources since the change on lazyaw breaks existing
configurations. 

In order to avoid that and make the change acceptable, it needs to be a
generalization of lazyaw. The configuration option is just a flag for now, it
could get a set of values to consider:
  lazyaw addr            (équivalent to lazya without argument)
  lazyaw addr rcpt     (what you ware looking for)

Implementing this means adding a few lines in conf_yacc.y and of course
replacing the if block quoted above in pending.c by a function call that would
do the mote complex tests.

And there is the F2B_SPICE macro in milter-greylist.h that would become an
inline function with cases depending of lazyaw values. And documentation
update, including your name in the list of milter-greylist authors :-)

The alternative is just moving one line in pending.c and live with a local
patch.

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

> In order to avoid that and make the change acceptable, it needs to be a
> generalization of lazyaw. The configuration option is just a flag for now, it
> could get a set of values to consider:
>   lazyaw addr            (équivalent to lazya without argument)
>   lazyaw addr rcpt     (what you ware looking for)
> 

I would not touch the old good lazyaw option.
Rather add the following extension to both racl and dacl greylist statement:

racl gerylist [lazyawaddr] [lazyawfrom] [lazyawrcpt] ...

That way there is higher flexibility of controlling what should be checked
depending which greylist ACL match generated the whitelist entry.

Defaulting for the compatibility:

If the old good lazyaw option is off, than the traditional greylist entry should be interpreted as before.
If the old good lazyaw option is on, than the traditional greylist entry should be read as
racl greylist lazyawfrom lazyawrctp ...
(No lazyawaddr on!)

For the requirement of Mauricio:
racl greylist lazyawrcpt
only, without lazyawfrom (both sender address and IP matters for AW comparison)

By the way interesting option would be:
racl greylist lazyawfrom lazyawrcpt
If one given sender sent an e-mail successfully to one given recipient,
than no matter from which IP next time (s)he tries to send, it will be no subject of greylisting.

There should be checking that not all the three new options to be on at the same time,
since that would effectively switches off the greylisting.

That may affect the dump file format, has to be checked.

> 
> racl gerylist [lazyawaddr] [lazyawfrom] [lazyawrcpt] ...
> 
> That way there is higher flexibility of controlling what should be checked
> depending which greylist ACL match generated the whitelist entry.
> 

Even better:

racl greylist [awaddr] [awfrom] [awrcpt] ...

Means, what to check from the aw tuple for match.
No new aw... entry means traditional greylist entry (check for what lazyaw tells)
Better backward compatibility.

No need to modify the dump format.

On Mon, Feb 29, 2016 at 11:39:07AM -0300, Mauricio Teixeira mauricio.teixeira@... [milter-greylist] wrote:
> I appreciate your time in explaining what can be done on the source code,
> but in the environment I'm working with it's not acceptable to use patched
> code (hard to maintain). We need to use the code from upstream.

Juste be make sure there is no misunderstanding: my proposal to extend
the lazyaw keyword would be clean enough to make it into the sources:
it does not change previous behavior and just lets administrators configure
fancy things should they need to.

-- 
Emmanuel Dreyfus
manu@...

'Bruncsak, Attila' attila.bruncsak@... [milter-greylist]
<milter-greylist@yahoogroups.com> wrote:

> racl gerylist [lazyawaddr] [lazyawfrom] [lazyawrcpt] ...

Yes, this is even better. Now someone has to implement it :-)

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

Mauricio Teixeira mauricio.teixeira@... [milter-greylist]
<milter-greylist@yahoogroups.com> wrote:

> I get that, but I'm not in a good position to spend time writing decent
> enough C code to be pushed upstream.

Then perhaps you can sponsor someone else to do it?

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