> 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

Reply via email to