On Wed, 2019-05-29 at 12:47 +0200, Stoiko Ivanov wrote: > On Wed, 29 May 2019 11:31:42 +0200 Matthias Egger <maeg...@ee.ethz.ch> wrote: > > On 28.05.19 10:31, Stoiko Ivanov wrote: > > > with a recent update to the ruleset, we're encountering certain > > > mails, which cause the rule-evaluation to use 100% cpu.
Thanks for the report, Stoiko. > > Your sample just triggered the error and therefore the system started > > blowing off partially :-) So next time, please paste that example to > > e.g. pastebin or github or some website and link to it ;-) > > Aye - sorry for that! I first wanted to open a bug-report at bugzilla, > but since the one which dealt with a similar issue contained the > suggestion to contact the user-list with problems for single rules - I > did just that - without considering those implications! > > Next time I'll definitely take the pastebin-option! Both is good advice, filing a bug report as well as generally using pastebin or similar external method to provide samples... I see this has been filed in bugzilla by now. > > But anyway, can you tell me how you found out __STYLE_GIBBERISH_1 is > > the culprit? I have no clue how to isolate that, since a strace does > > not really help... Or is there some strace for perl which i do not > > know? > > hmm - in that case the way to go was to enable a commented out > debug-statement in the spamassassin source, which lists which rule is > evaluated. (on 3.4.2 installed on a Debian this is > in /usr/share/perl5/Mail/Spamassassin/Plugin/Check.pm - in > do_rawbody_tests - just comment out the if-condition for would_log > > Then you see it in the debug-output Hmm, curious why that would be commented out. It's the rules-all debug area feature that should generally be available since the 3.4 branch, IIRC. spamassassin -D rules-all will then announce regex rules *before* evaluating them, so even long- running regex rules that do not match are easy to identify. -- Karsten Bräckelmann -- open source. hacker. assassin.
