You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by "Lichtinger, Bernhard" <Be...@lrz.de> on 2026/01/21 15:45:26 UTC
How to debug SA to identify long running body check?
Hello,
I am looking for hints how i can identify which body rule leads to 100% CPU and unusual long run time for spamassassin.
I already managed to narrow it down to malformed, "recursive-looking" mailto: URIs/anchor-tags within the body.
The users mail client managed with each iteration of citing the previous conversation to add one more level of "recursion" to this pattern.
It looks like this in the plain text mail body:
One Person <so...@hotmail.com><mailto:s=
omeone@hotmail.com<ma...@hotmail.com>><mailto:someone@hotmail.com=
<ma...@hotmail.com><mailto:someone@hotmail.com<mailto:someone@hot=
mail.com>>><ma...@hotmail.com><mailto:=
someone@hotmail.com<ma...@hotmail.com>><mailto:someone@hotmail.co=
m<ma...@hotmail.com><mailto:someone@hotmail.com<mailto:someone@ho=
tmail.com>>>><ma...@hotmail.com><mailt=
o:someone@hotmail.com<ma...@hotmail.com>><mailto:someone@hotmail.=
com<ma...@hotmail.com><mailto:someone@hotmail.com<mailto:someone@=
hotmail.com>>><ma...@hotmail.com><mail=
to:someone@hotmail.com<ma...@hotmail.com>><mailto:someone@hotmail=
.com<ma...@hotmail.com><mailto:someone@hotmail.com<mailto:someone=
@hotmail.com>>>>>>
This one takes about 30sec to finish.
A block of about double this size takes already about 4min to finish.
I suspect some catastrophic backtracking is happening with such a text in the body.
My open question is: which regex is causing this?
Best regards,
Bernhard
Re: How to debug SA to identify long running body check?
Posted by "Lichtinger, Bernhard" <Be...@lrz.de>.
> Am 22.01.2026 um 10:51 schrieb Matus UHLAR - fantomas <uh...@fantomas.sk>:
>
> e-mail address in form:
> [a-z0-9_.-]{1-64}\@[a-z0-9_.-]{1-255}
>
> should be safer ...according to rfc5321, localpart is 64 chars max, domain 255 max)
Yes, that is even better.
But there is a little mistake in your regex, the quantifier needs "," and not "-" ;)
This regex will do:
[a-z0-9_.-]{1,64}\@[a-z0-9_.-]{1,255}
Thank you all,
Bernhard
Re: How to debug SA to identify long running body check?
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>> Am 21.01.2026 um 16:56 schrieb Bill Cole <sa...@billmail.scconsult.com>:
>>
>> You can go looking for any instances of '.*' in your rules as a start,
>> but I don't think your problem here is regex backtracking but rather DNS.
>> All of those addresses will generate multiple DNS queries, and if they
>> are not all identical (I assume that you have replaced the real
>> addresses) they will each go out to the net for resolution.
> It is all the same address, I only replaced the local part of the original
> address.
>> This can be particularly problematic if you do not have a fully recursive
>> nameserver running on the same machine (or at worst, same LAN segment) to
>> do all DNS resolution for your MTA. That means something OTHER THAN
>> dnsmasq, which is only fit for low-volume end user name resolution.
On 21.01.26 17:10, Lichtinger, Bernhard wrote:
> DNS is not the problem, we use unbound. And I also did some tests with
> spamassassin -L with the same results.
Caching does not fix an issue if the issue is in sending multiple different
requests, just FYI.
> But your hint to look for '.*' pushed me into the right direction.
>
> I figured out to run spamassassin with perl -d:Trace then I saw the output
> stalled always after logging the same custom rule of my ruleset and this
> one was the culprit:
>
>/(password|credential|access to|account|\S+\@\S+|e-?mail).{1,70}(is expiring|expires?|(has )?expired|set to expire)/i
>
>after changing it to
>/(password|credential|access to|account|[a-z0-9_.-]+\@[a-z0-9_.-]+|e-?mail).{1,70}(is expiring|expires?|(has )?expired|set to expire)/i
I guess that the issue wasn't not just in the "\S" vs "[a-z0-9_.-]", but
also in the "\+" vs "{1,...}"
e-mail address in form:
[a-z0-9_.-]{1-64}\@[a-z0-9_.-]{1-255}
should be safer
...according to rfc5321, localpart is 64 chars max, domain 255 max)
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759
Re: How to debug SA to identify long running body check?
Posted by "Lichtinger, Bernhard" <Be...@lrz.de>.
> Am 21.01.2026 um 16:56 schrieb Bill Cole <sa...@billmail.scconsult.com>:
>
> You can go looking for any instances of '.*' in your rules as a start, but I don't think your problem here is regex backtracking but rather DNS. All of those addresses will generate multiple DNS queries, and if they are not all identical (I assume that you have replaced the real addresses) they will each go out to the net for resolution.
It is all the same address, I only replaced the local part of the original address.
> This can be particularly problematic if you do not have a fully recursive nameserver running on the same machine (or at worst, same LAN segment) to do all DNS resolution for your MTA. That means something OTHER THAN dnsmasq, which is only fit for low-volume end user name resolution.
DNS is not the problem, we use unbound. And I also did some tests with spamassassin -L with the same results.
But your hint to look for '.*' pushed me into the right direction.
I figured out to run spamassassin with perl -d:Trace then I saw the output stalled always after logging the same custom rule of my ruleset and this one was the culprit:
/(password|credential|access to|account|\S+\@\S+|e-?mail).{1,70}(is expiring|expires?|(has )?expired|set to expire)/i
after changing it to
/(password|credential|access to|account|[a-z0-9_.-]+\@[a-z0-9_.-]+|e-?mail).{1,70}(is expiring|expires?|(has )?expired|set to expire)/i
everything is OK again.
Best regards,
Bernhard
Re: How to debug SA to identify long running body check?
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 2026-01-21 at 10:45:26 UTC-0500 (Wed, 21 Jan 2026 15:45:26 +0000)
Lichtinger, Bernhard <us...@spamassassin.apache.org>
is rumored to have said:
> This one takes about 30sec to finish.
> A block of about double this size takes already about 4min to finish.
>
> I suspect some catastrophic backtracking is happening with such a text in the body.
> My open question is: which regex is causing this?
You can go looking for any instances of '.*' in your rules as a start, but I don't think your problem here is regex backtracking but rather DNS. All of those addresses will generate multiple DNS queries, and if they are not all identical (I assume that you have replaced the real addresses) they will each go out to the net for resolution.
This can be particularly problematic if you do not have a fully recursive nameserver running on the same machine (or at worst, same LAN segment) to do all DNS resolution for your MTA. That means something OTHER THAN dnsmasq, which is only fit for low-volume end user name resolution.
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire