http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5486
------- Additional Comments From [EMAIL PROTECTED] 2007-06-01 10:44 -------
Each of fhe following three rawbody rules from 70_sare_obfu1.cf
cause a segfault on the submitted HTML newsletter:
__SARE_OBFU_TBL1, __SARE_OBFU_TBL2, __SARE_OBFU_TBL3
Here is a distilled command-line that does the same when given the
sample message as input:
perl -e 'undef $/; $_=<>;
m{ <td> ( < (?! /? td ) ([^>"] | " [^"]* " )* >)* [a-z] }ix' 0.msg
It was derived from __SARE_OBFU_TBL3 by repeatedly stripping it down
as long as it still caused a failure.
It fails on x86_64-linux-thread-multi, but not on i386-linux-thread-multi
(same version of Linux and its kernel), and not on FreeBSD hosts like
amd64-freebsd or i386-freebsd-64int, perl 5.8.8 throughout.
What is intersting is that SA 3.1.8 with these same rules, same message,
same perl and same host does not stumble on this Perl problem.
I wonder what 3.2 does differently from 3.1.8 when running rawbody
rules on a full text. Here is a proof for the curious that this
problem-rule did work (on 3.1.8):
dbg: rules: ran eval rule __TAG_EXISTS_HEAD ======> got hit
dbg: rules: ran eval rule __TAG_EXISTS_META ======> got hit
dbg: rules: running raw-body-text per-line regexp tests; score so far=0.001
dbg: rules: ran rawbody rule __SARE_OBFU_TBL1 ======> got hit:
"<td style="padding-left: 20px;">
<font style="font-size:10pt;">g</font></td>"
> Anyway, so back to this issue... Yes, if there are core rules which tickle
> the same kind of problem, we can look at doing a work around to avoid it.
> If it's user entered or third-party rules, I don't think there's anything
> we can really do.
I know it is a Perl problem (either call it a bug, or inability to handle
gracefully situations like running out of memory). But an average mail
administrator noticing SA process crashing and causing a mail to be stuck
in a MTA queue will blame the application. We are rarely this fortunate
to be handed a well documented and repeatable 'mystery' case. There is
a good chance that some solution to such case will also apply to a
sizable share of other unresolved mystery cases.
Notice from the above command-line test case how a relatively simple
rule is able to bring down the application. Should people be advised
against writing their own rules in local.cf? Should there be a
rule-approval QA certification mechanism?
I know there is no simple solution. If there is no fix, perhaps there
is a workaround, or a test to detect a buggy Perl, or an improved
debugging printout that can facilitate localizing the problem,
or maybe it would help not to give the whole 50 kB mail in a single
string to rawbody rules. See what makes 3.1.8 survive while 3.2.0
is being brought down.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
