Yahoo Groups archive

Milter-greylist

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

Thread

lazyaw

lazyaw

2005-04-05 by Jacob Garder

Hi!

Does someone have experience or statistics of running greylist with the lazyaw 
option? Does it decrease the efficiency significantly?

As far as I can see if a mailserver with a certain IP-address retries sending a 
mail to me with one sender/reciever tuple, the probability that it would do the 
same with another sender/reciever tuple is pretty high.

In that case what is the point in auto-whitelist according to the (IP-address, 
reciever, sender) tuple and not just the IP-address? What am I missing here?

Best Regards,
Jacob G\ufffdrder

Re: [milter-greylist] lazyaw

2005-04-05 by manu@netbsd.org

Jacob Garder <jacob@...> wrote:

> Does someone have experience or statistics of running greylist with the lazyaw
> option? Does it decrease the efficiency significantly?
> 
> As far as I can see if a mailserver with a certain IP-address retries
> sending a mail to me with one sender/reciever tuple, the probability that
> it would do the same with another sender/reciever tuple is pretty high.
> 
> In that case what is the point in auto-whitelist according to the (IP-address,
> reciever, sender) tuple and not just the IP-address? What am I missing here?

Think about networks running behind NAT with regular SMTP server and
zombies running spam engines. 

-- 
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@...

Re: [milter-greylist] lazyaw

2005-04-05 by Matthias Scheler

On Tue, Apr 05, 2005 at 03:44:26PM +0200, Jacob Garder wrote:
> In that case what is the point in auto-whitelist according to the
> (IP-address, reciever, sender) tuple and not just the IP-address?
> What am I missing here?

A Zombie spam PC which sends an e-mail to "joe@..." and a
few minutes later a e-mail to "tom@..." and gets
whitelisted that way.

"mail.netbsd.org" used an IP address based greylisting approach
initially and it was not very effective.

	Kind regards

-- 
Matthias Scheler                                  http://scheler.de/~matthias/

Re: [milter-greylist] lazyaw

2005-04-06 by Jacob Garder

On Tue, 5 Apr 2005, Matthias Scheler wrote:

>
> On Tue, Apr 05, 2005 at 03:44:26PM +0200, Jacob Garder wrote:
>> In that case what is the point in auto-whitelist according to the
>> (IP-address, reciever, sender) tuple and not just the IP-address?
>> What am I missing here?
>
> A Zombie spam PC which sends an e-mail to "joe@..." and a
> few minutes later a e-mail to "tom@..." and gets
> whitelisted that way.
>
> "mail.netbsd.org" used an IP address based greylisting approach
> initially and it was not very effective.

Thats true...so maybe the lazyaw option should greylist on the 
(IP-address, reciever, sender) tuple, but whitelist only IP-adresses?


/jacob

Re: [milter-greylist] lazyaw

2005-04-08 by manu@netbsd.org

Jacob Garder <jacob@...> wrote:

> Thats true...so maybe the lazyaw option should greylist on the 
> (IP-address, reciever, sender) tuple, but whitelist only IP-adresses?

Isn't this what we currently do?

-- 
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@...

lazyaw

2007-07-13 by Jason Bertoch

Hi all,

	Sorry if this topic has been covered ad nauseum already, I was unable to
find archives for this list.  I found the lazyaw configuration option and would
like to bounce some theories off the list.  It seems to me that once a server
has demonstrated that it will requeue a tempfailed message, there's not much
point in checking future tuples.  Even if the server is a spam source,
greylisting will not have an effect, so one might as well only whitelist the IP.
	I can only think of one scenario where enabling lazyaw would hurt.  If a
server behind a NAT firewall first passes greylisting requirements, gets on the
autowhitelist by IP alone via lazyaw, then another host behind the same firewall
begins spewing directly.  By experience, is this common?  What are the common
views on using lazyaw?  Am I right in assuming that lazyaw enabled will continue
to verify the tuple then, once requeued, whitelist only the sending server's IP?

Thanks in advance,

Jason

Re: [milter-greylist] lazyaw

2007-07-14 by manu@netbsd.org

Jason Bertoch <jason@...> wrote:

>       I can only think of one scenario where enabling lazyaw would hurt.
> If a server behind a NAT firewall first passes greylisting requirements,
> gets on the autowhitelist by IP alone via lazyaw, then another host behind
> the same firewall begins spewing directly.  By experience, is this common?

It can happen, and IMO it will happen more and more often, but your
experience can be much different than mine, depending who you are
exchanging mail with. That's why lazyaw is an option: enabling it is at
your choice and depend of your experience.

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

Re: [milter-greylist] lazyaw

2007-07-21 by Joel Reicher

> 	Sorry if this topic has been covered ad nauseum already, I was unable t
> o
> find archives for this list.  I found the lazyaw configuration option and wou
> ld
> like to bounce some theories off the list.  It seems to me that once a server
> has demonstrated that it will requeue a tempfailed message, there's not much
> point in checking future tuples.

That's probably correct, but as far as I can see there's no way to know
for sure that what your mail server sees is actually a genuine "requeue".

It may be that the spammer decided to do two spam runs that day with the
same envelope sender.

Cheers,

	- Joel

Re: {Disarmed} [milter-greylist] lazyaw

2007-07-25 by Kai Schaetzl

I'm using lazyaw since day 1 and haven't seen any undesired effects, still 
rejecting lots of spam and viruses via greylisting.

Kai

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

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.