Milter-greylist

Hi,

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?

Ciao!
Marcus

"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.

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.

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

>> 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?

What I mean is that if a host gets put on an RBL that indicates such bad
behavior that people want to delay mail for 12h, then it's likely that
other anti-spam software will apply other penalties to that host, such
as high scores, just rejecting SMTP connections, etc.    So if the big
problem is that when it's taken off the list you think the greylist
timer should drop to 15m immediately, but that it still gets 12h from
the time it first tried, that's perhaps not as serious as what other
people will be doing based on having been on this blocklist.

19 \u0434\u0435\u043a\u0430\u0431\u0440\u044f 2016�\u0433. 0:30:00 CET, "Greg Troxel gdt@... [milter-greylist]" <milter-greylist@yahoogroups.com> \u043f\u0438\u0448\u0435\u0442:
>
>"Marcus Schopen lists-yahoogroups@... [milter-greylist]"
><milter-greylist@yahoogroups.com> writes:
>
>>> 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?
>
>What I mean is that if a host gets put on an RBL that indicates such
>bad
>behavior that people want to delay mail for 12h, then it's likely that
>other anti-spam software will apply other penalties to that host, such
>as high scores, just rejecting SMTP connections, etc.    So if the big
>problem is that when it's taken off the list you think the greylist
>timer should drop to 15m immediately, but that it still gets 12h from
>the time it first tried, that's perhaps not as serious as what other
>people will be doing based on having been on this blocklist.

On a similar note: sometimes we have spam bursts where a "legit" but abused mail server sent out spam. It may have got greylisted, but got autowhited on timeout and resubmission of a message, and only some hours later that IP got into DNS RBLs because its infestation continues and spam level got to a critical threshold of the honeypots. But our relay already trusts the host as previously autowhited (and the trust continues as we get new spams regularly).

Is there a way to do enforce some checks (like DNS RBL) for *auto*whited hosts as well (but avoid the re-check for manual/ldap/dnswl etc. whitelists)?

Jim
--
Typos courtesy of K-9 Mail on my Samsung Android

Hi Greg,

On 2016-12-19 00:30, Greg Troxel gdt@... [milter-greylist] wrote:
> "Marcus Schopen lists-yahoogroups@... [milter-greylist]"
> <milter-greylist@yahoogroups.com> writes:
> 
>>> 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?
> 
> What I mean is that if a host gets put on an RBL that indicates such 
> bad
> behavior that people want to delay mail for 12h, then it's likely that
> other anti-spam software will apply other penalties to that host, such
> as high scores, just rejecting SMTP connections, etc.    So if the big
> problem is that when it's taken off the list you think the greylist
> timer should drop to 15m immediately, but that it still gets 12h from
> the time it first tried, that's perhaps not as serious as what other
> people will be doing based on having been on this blocklist.

My point for a longer delay is: if a host is blacklisted on some RBLs 
(and not listed on a white list like dnswl.org/wl.mailspike.net), but 
doesn't reach a RBL score to get hard rejected, the host might comes up 
on further blacklists while the longer delay. That's the reason, why I 
don't let run those hosts in the standard greylisting delay of 15 
minutes. A delay of 12 hours might be a little bit special, but it's my 
private mail host, just for my personal mails. I reduced it for some 
testing down to 2 hours.

Ciao
Marcus