[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