> On Nov 12, 2021, at 10:35 PM, Henrik K <h...@hege.li> wrote:
>
> On Fri, Nov 12, 2021 at 07:49:00PM -0800, John Hardin wrote:
>>
>> What would be helpful here would be logging of when a rule *starts*
>> evaluation. Normally that would be painful, but for tracking a runaway it
>> would be useful. Perhaps I can code up something to capture that and log it
>> on a timeout...
>
> It already exists
>
> spamassassin -D all,rules-all < msg
>
Ah, that was useful.
Seeing:
...
Nov 15 16:09:40.479 [54834] dbg: check: uri_block_cidr list
54.69.70.160-54.69.70.160 65.181.64.0-65.181.127.255 97.74.42.81-97.74.42.81
98.124.199.1-98.124.199.1 167.114.67.88-167.114.67.88
173.45.101.58-173.45.101.58 185.53.128.0-185.53.131.255
192.31.186.4-192.31.186.4 192.99.0.0-192.99.255.255
194.213.125.57-194.213.125.57
Nov 15 16:11:50.610 [54834] dbg: check: uri_local_bl http.sh addrs
...
Nov 15 16:16:00.876 [54834] dbg: async: timing: 5.193 .
dns:A:100.136.134.134.psbl.surriel.com
Nov 15 16:16:00.876 [54834] dbg: async: timing: 5.199 .
dns:A:100.136.134.134.dnsbl.sorbs.net
Nov 15 16:16:00.876 [54834] dbg: async: timing: 385.726 X A:http.sh
Nov 15 16:16:00.876 [54834] dbg: async: timing: 385.726 X NS:http.sh
...
Why would resolving http.sh take this long? And can we bring down the timeout?
Hard to imagine DNS requests taking more than a couple of seconds.
-Philip