Milter-greylist

"Marcus Schopen lists-yahoogroups@... [milter-greylist]"
<milter-greylist@yahoogroups.com> writes:

> my standard greylist delay is 15 minutes (ACL name = GL_STD). For hosts 
> which are listed on one blacklist, I set a longer delay of 12 hours (ACL 
> name = GL_DNSBL). A few days ago a host was greylisted with a longer 
> delay, because at first connect its IP was listed on spamcop RBL (= ACL 
> GL_DNSBL). After two hours the host was removed from the spamcop list, 
> but the greylisting delay didn't change to the standard greylisting 
> delay of 15 minutes, but the host had to overcome the full time of 12 
> hours delay to its end (GL_DNSBL). I set log ACLs in the greylist.conf 
> to see which ALCs were hit after the IP was removed from the blacklist. 
> It was die ACL for the standard greylist delay of 15 minutes (GL_STD). 
> In my understanding this is wrong. If the short delay ALC GL_STD is hit, 
> but the database keeps a longer delay, the delay should be reduced at 
> least to the delay time of the shorter delay. But what happens in to 
> opposite case? A short delay is hit and counting down. Within this 
> timeslot the host is hit by a longer delay ACL? Not sure how to solve 
> this case?

Probably, I think it is working as designed, in that the result of ACL
lookup is put in the delay database.

What you seem to want, which seems reasonable, is to redo the acl lookup
each time, and take the newly-computed delay plus the recorded
first-attempt time and compare.

So I would suggest reading the sources to see if the above theory is
right, and if so it's definitely going to be a code change.  I am not
sure everyone wants to redo the dns lookups every time, vs letting the
original entry be used.

On the other hand, a host being on a bad blocklist leading to big delays
and getting taken off is going to cause all sorts of problems, and
people delaying mail for 12h instead of 15m does not seem likely to rise
to the top.