Milter-greylist

On 2016-12-18 16:25, Greg Troxel gdt@... [milter-greylist] wrote:
> "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.

Could you technically explain the last point please?

Ciao
M.