[Mimedefang] accept, then scan?
Andy Lyttle
mimedefang at phroggy.com
Fri Sep 21 20:34:39 EDT 2007
> Are you using exotic or custom rulesets, or an older version of
> spamassassin, or an old version of perl? (older than 5.8.8)
Yes, no, and yes. I just upgraded to SA 3.2.3 (from 3.2.1), but I'm
stuck on perl 5.8.0 for now. And I've got custom rulesets out the
wazoo: I'm running a bunch of stuff from SARE, plus my own.
> There are known bugs in older spamassassin rulesets (and some
> SARE rules) that cause the perl regex engine (or some versions
> of the regex engine) to use excessive backtracking in case certain
> long input strings are used. Does the mail that is causing a tempfail
> contain very long lines? If so, there's your problem.
That's probably it. In the sample message I copied for debugging,
INPUTMSG has no long lines (everything's wrapped to around 70ish
characters), but ./Work/msg-24185-3.html does contain long lines.
Would SpamAssassin be looking at this?
> You might be able to catch the misbehaving rule by manually running
> spamassassin on the mail, with debugging enabled. Note: this will
> most likely be a rule that DOES NOT match. Regexes tend to be good
> at finding matches, but bad, worse or extremely bad at not finding
> a match. In fact, most of the perl regex optimizations are aimed at
> failing quickly (and I can seriously recommend perl 5.9.5 or 5.10.0
> if you think you can handle the bleeding edge, because the regex
> engine has had a pretty massive overhaul).
I tried "spamassassin -D < INPUTMSG" and it finished in a few
seconds. Is there something else I can try?
I'll be upgrading from Slackware 9.0 to Slackware 12.0, which will
take perl from 5.8.0 to 5.8.8. Or, I could scrap that and build my
own perl, but I'd rather not, unless there's a really compelling need
to. Beefy CPUs will compensate for a slow regex engine. :-)
~ Andy
More information about the MIMEDefang
mailing list