Geez I hate Bugzilla and its searches that do not work. SO I don't know if this was a duplicate or not. It now has number 4445. It is a particularly annoying bug.
(A search for "SpamAssassin/PerMsgStatus.pm line 2119" returned a bazillion hits the first dozen of which did not match. Sheesh what a Microsofted tool. No wonder I am allergic to it.) {+_+} ----- Original Message ----- From: "jdow" <[EMAIL PROTECTED]> > error: Insecure dependency in eval while running setuid at > /usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/PerMsgStatus.pm line 2119._ > , continuing > > > Ayup - another one of those horrid problems. > > I am running 3.04 with spamd and spamc. I get this on "full" rules. > However, I do not get it all the time. I get it when email traffic > cues up several messages at once. I am running with spamd options > "-d -c -m5 -Hi -A 192.168.XX.,127. --max-conn-per-child=15". I am > running with per user rules enabled: > ===8<--- > # This is the right place to customize your installation of SpamAssassin. > # > # See 'perldoc Mail::SpamAssassin::Conf' for details of what can be > # tweaked. > # > ########################################################################### > # > rewrite_header Subject *****SPAM***** _SCORE(00)_ ** > # report_safe 1 > clear_trusted_networks > # trusted_networks 212.17.35. > trusted_networks 192.168.XX/24 127/8 207.217.121/24 > internal_networks 192.168.xx/24 > # lock_method flock > use_auto_whitelist 0 > #dns_available yes > dns_available test: wizardess.wiz > bayes_auto_learn 0 > bayes_auto_expire 0 > bayes_auto_learn_threshold_spam 20.0 > bayes_auto_learn_threshold_nonspam 0.1 > allow_user_rules 1 > ===8<--- > There is a local dns available. > > I developed a trap for the problem in procmail. My .procmailrc includes > this recipe (or something relatively close.): > :0 fw > * ^X-NTRACK: Before SA > { > :0 fw > * !^X-Spam-Checker-Version: > { > :0 fw > | nice -n 1 /usr/bin/spamassassin > > # :0 fw > # | Formail -A "X-JdowMissed: SpamAssassin checks bombed first time. > > :0 fw > | sed -e 's/Subject:/Subject: [ZZ Missed]/' > } > } > > I find that the rule results in markups on both spam and ham. It is > marked in such a manner as to make alphabetical searches in > OutlookDepress quite asy at the moment. This is how I can trace the > underlying problem hitting both ham and spam. > > "grep PerMsgStatus.pm /var/log/mail/info" shows that only line 2119 > is hitting. Removing all my user_prefs "full" rules ends the problem. > > This is, however, not a satisfactory solution. The backup run of raw > spamassassin is also an inelegant solution to the problem. However, if > it is the only fix this should be documented. Per user rules are entirely > too useful in the face of threats customized for specific users. This > includes obfuscated base64 encoded email addresses within messages, and > the like. > > If more information is needed, some mail logs, or some of the actual > messages which hit the trap above are needed they, too, can be provided > for your amusement. However, there seems to be no discernable pattern > to the messages other than that they seem to hit only when traffic is > "high" with high being two or three messages to process in one once per > minute fetchmail run on my Earthlink pop3 server. > > {^_^} >