Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Thread

lazyaw not working?

lazyaw not working?

2012-05-24 by Peter Bonivart

I have "lazyaw" in my greylist.conf and would have expected the second
connection below not to be delayed since it's from the same server but
it still was.

May 23 00:01:43 sun2 milter-greylist: q4MM1dxL010320: addr
mail4.trafikverket.se[188.121.65.205] from =foo.bar@...>
to <foo@...> delayed for 00:01:00 (ACL 370)
May 23 00:01:43 sun2 sendmail[10320]: q4MM1dxL010320:
from=<prvs=048936c67e=foo.bar@...>, size=17632, class=0,
nrcpts=0, proto=ESMTP, daemon=MTA, relay=mail4.trafikverket.se
[188.121.65.205]

May 23 00:45:20 sun2 milter-greylist: q4MMjF9Q016052: addr
mail4.trafikverket.se[188.121.65.205] from =foo.bar@...>
to <foo@...> delayed for 00:01:00 (ACL 370)
May 23 00:45:20 sun2 sendmail[16052]: q4MMjF9Q016052:
from=<prvs=048936c67e=foo.bar@...>, size=18917, class=0,
nrcpts=0, proto=ESMTP, daemon=MTA, relay=mail4.trafikverket.se
[188.121.65.205]

Also note that the from address is some generated one that
milter-greylist logs incorrectly. The unique from address is what
makes normal autowhitelist not trigger either which I understand but
lazyaw should, right? Am I missing something here?

This is milter-greylist 4.0 if that makes a difference. I can't see
lazyaw mentioned in the changelog since 2.1.4.

/peter

Re: [milter-greylist] lazyaw not working?

2012-05-25 by manu@netbsd.org

Peter Bonivart <shuttlebox@...> wrote:

> I have "lazyaw" in my greylist.conf and would have expected the second
> connection below not to be delayed since it's from the same server but
> it still was.

What is the greylisting delay? Was the second message sent after enough
time to pass?

> This is milter-greylist 4.0 if that makes a difference. I can't see
> lazyaw mentioned in the changelog since 2.1.4.

I do not recall changing it since that time, indeed.

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

RE: [milter-greylist] lazyaw not working?

2012-05-25 by Bruncsak, Attila

> I have "lazyaw" in my greylist.conf and would have expected the second
> connection below not to be delayed since it's from the same server but
> it still was.
> 
> May 23 00:01:43 sun2 milter-greylist: q4MM1dxL010320: addr
> mail4.trafikverket.se[188.121.65.205] from =foo.bar@...>
> to <foo@...> delayed for 00:01:00 (ACL 370)
> May 23 00:01:43 sun2 sendmail[10320]: q4MM1dxL010320:
> from=<prvs=048936c67e=foo.bar@trafikverket.se>, size=17632, class=0,
> nrcpts=0, proto=ESMTP, daemon=MTA, relay=mail4.trafikverket.se
> [188.121.65.205]
> 
> May 23 00:45:20 sun2 milter-greylist: q4MMjF9Q016052: addr
> mail4.trafikverket.se[188.121.65.205] from =foo.bar@...>
> to <foo@...> delayed for 00:01:00 (ACL 370)
> May 23 00:45:20 sun2 sendmail[16052]: q4MMjF9Q016052:
> from=<prvs=048936c67e=foo.bar@...>, size=18917, class=0,
> nrcpts=0, proto=ESMTP, daemon=MTA, relay=mail4.trafikverket.se
> [188.121.65.205]
> 
> Also note that the from address is some generated one that
> milter-greylist logs incorrectly. The unique from address is what
> makes normal autowhitelist not trigger either which I understand but
> lazyaw should, right? Am I missing something here?
> 

Probably you do not have the recipient "foo@..." you
have masked the original recipients for privacy reason.
But the original recipients are the same
on the two set of syslog entries?
Because that must be the case for the whitelisting to work.

Re: [milter-greylist] lazyaw not working?

2012-05-25 by Peter Bonivart

On Fri, May 25, 2012 at 3:51 AM,  <manu@...> wrote:
> Peter Bonivart <shuttlebox@...> wrote:
>
>> I have "lazyaw" in my greylist.conf and would have expected the second
>> connection below not to be delayed since it's from the same server but
>> it still was.
>
> What is the greylisting delay? Was the second message sent after enough
> time to pass?

I use one minute and it was about 45 minutes between those two and
there are lots more examples from the same sender.

timeout 1d
greylist 1m
autowhite 3d

If I get this right: since it's more than one minute (greylist)
between connections from the same server and it's within one day
(timeout for tuples) I should get a three day whitelist (autowhite).

/peter

Re: [milter-greylist] lazyaw not working?

2012-05-25 by Peter Bonivart

On Fri, May 25, 2012 at 8:59 AM, Bruncsak, Attila
<attila.bruncsak@...> wrote:
> Probably you do not have the recipient "foo@..." you
> have masked the original recipients for privacy reason.
> But the original recipients are the same
> on the two set of syslog entries?
> Because that must be the case for the whitelisting to work.

No, it's masked since it's a customer of ours and I don't want to
expose a real address but it's the same recipient in both cases. Not
that it should matter with lazyaw, right? Isn't the point of it just
to look at the sending servers ip address for autowhitelisting? So a
totally different combo of sender/recipient should still be
autowhitelisted if it's from the same server..?

Could it be that the from address is autogenerated which creates a new
tuple each time even for the same sender/recipient? Is that the
problem? But in the example I posted it was actually the same from
address, generated for some reason but still the same in the two
connections so it should have worked but milter-greylist seems to have
a problem with equal signs in the address.

Sendmail logs it correctly as
"from=<prvs=048936c67e=foo.bar@...>" but milter-greylist
logs it as "from =foo.bar@...>".

May 23 00:01:43 sun2 milter-greylist: q4MM1dxL010320: addr
mail4.trafikverket.se[188.121.65.205] from =foo.bar@...>
to <foo@...> delayed for 00:01:00 (ACL 370)
May 23 00:01:43 sun2 sendmail[10320]: q4MM1dxL010320:
from=<prvs=048936c67e=foo.bar@...>, size=17632, class=0,
nrcpts=0, proto=ESMTP, daemon=MTA, relay=mail4.trafikverket.se
[188.121.65.205]

May 23 00:45:20 sun2 milter-greylist: q4MMjF9Q016052: addr
mail4.trafikverket.se[188.121.65.205] from =foo.bar@...>
to <foo@...> delayed for 00:01:00 (ACL 370)
May 23 00:45:20 sun2 sendmail[16052]: q4MMjF9Q016052:
from=<prvs=048936c67e=foo.bar@...>, size=18917, class=0,
nrcpts=0, proto=ESMTP, daemon=MTA, relay=mail4.trafikverket.se
[188.121.65.205]

I have two entries in the greylist.db which I think should be only
one, note the from address error here as well.

188.121.65.205	=hakan.konradsson@...>	<foo@...>	1338013262
AUTO # 2012-05-26 08:21:02
188.121.65.205	=hakan.konradsson@...>	<foo@...>	1338032879
AUTO # 2012-05-26 13:47:59

/peter

Re: [milter-greylist] lazyaw not working?

2012-05-26 by manu@netbsd.org

Peter Bonivart <shuttlebox@...> wrote:

> Sendmail logs it correctly as
> "from=<prvs=048936c67e=foo.bar@...>" but milter-greylist
> logs it as "from =foo.bar@...>".

Here is what we have in the sources:
        /*
         * Strip anything before the last '=' in the
         * source address. This avoid problems with
         * mailing lists using a unique sender address
         * for each retry.
         */
        if ((idx = rindex(tmpfrom, '=')) == NULL)
                idx = tmpfrom;

What I don't get is how you get the same tuple twice in greylist.db.
This looks like a bug. The release you use is 4 years old, I cannot rule
out the possibility that this has been fixed since that time. What about
checking latest 4.4a2? It is intented to be fully backward compatible,
you do not have to change anything to your config.

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

Re: [milter-greylist] lazyaw not working?

2012-05-26 by Rich Graves

FWIW, I am also running lazyaw, but with milter-greylist-4.2.7. Lots of ='s were successfully deduplicated. So this might well have been fixed between 4.0 and 4.2.7. 


I do see one oddity, where the non-AUTO entry for user2 has persisted in greylist.db (dumpfreq 1h; several hours have passed), but both messages were accepted. 


racl greylist default delay 10m autowhite 14d 





94.23.3.184 =carleton.edu@...> <user2@...> 1337962747 
94.23.3.184 =carleton.edu@...> <user1@...> 1339172977 AUTO 


Original delivery attempt deferred: 




May 25 11:08:54 mx2 milter-greylist: q4PG8q7h015401: addr shen.garance.fr[94.23.3.184] from =carleton.edu@...> to <user1@...> delayed for 00:10:00 (ACL 190) 
May 25 11:08:54 mx2 sendmail[15401]: q4PG8q7h015401: from=<newsletter-return-87-user1=carleton.edu@...>, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=shen.garance.fr [94.23.3.184] 
May 25 11:09:07 mx2 milter-greylist: q4PG96T0015451: addr shen.garance.fr[94.23.3.184] from =carleton.edu@...> to <user2@...> delayed for 00:10:00 (ACL 190) 
May 25 11:09:07 mx2 sendmail[15451]: q4PG96T0015451: from=<newsletter-return-87-user2=carleton.edu@...>, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=shen.garance.fr [94.23.3.184] 


Retry succeeded: 


May 25 11:29:34 mx2 milter-greylist: q4PGTXgu023038: addr 94.23.3.184 from =carleton.edu@...> rcpt <user1@...>: autowhitelisted for 336:00:00 
May 25 11:29:34 mx2 sendmail[23038]: q4PGTXgu023038: from=<newsletter-return-87-user1=carleton.edu@...>, size=21976, class=-60, nrcpts=1, msgid=<20120525153104.19027.qmail@...>, proto=ESMTP, daemon=MTA, relay=shen.garance.fr [94.23.3.184] 
May 25 11:29:36 mx2 sendmail[23038]: q4PGTXgu023038: Milter add: header: X-Greylist: Delayed for 00:20:40 by milter-greylist-4.2.7 (mx2.its.carleton.edu [137.22.198.35]); Fri, 25 May 2012 11:29:36 -0500 (CDT) 
May 25 11:29:36 mx2 sendmail[23096]: q4PGTXgu023038: to=<user1@...>, delay=00:00:02, xdelay=00:00:00, mailer=esmtp, pri=249976, relay=mail.carleton.edu. [137.22.198.42], dsn=2.0.0, stat=Sent (Ok: queued as 163A339C2B) 
May 25 11:29:37 mx2 milter-greylist: q4PGTacW023103: addr 94.23.3.184 from =carleton.edu@...> rcpt <user2@...>: autowhitelisted for more 336:00:00 
May 25 11:29:38 mx2 sendmail[23103]: q4PGTacW023103: from=<newsletter-return-87-user2=carleton.edu@...>, size=21976, class=-60, nrcpts=1, msgid=<20120525153104.19027.qmail@...>, proto=ESMTP, daemon=MTA, relay=shen.garance.fr [94.23.3.184] 
May 25 11:29:39 mx2 sendmail[23128]: q4PGTacW023103: to=<user2@...>, delay=00:00:02, xdelay=00:00:00, mailer=esmtp, pri=249976, relay=mail.carleton.edu. [137.22.198.42], dsn=2.0.0, stat=Sent (Ok: queued as 9A94839C25) 
-- 
Rich Graves http://claimid.com/rcgraves 
Carleton.edu Sr UNIX and Security Admin

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.