You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by jdow <jd...@earthlink.net> on 2005/07/01 05:28:21 UTC

Re: error: Insecure dependency in eval while running setuid at /usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/PerMsgStatus.pm line 2119._ , continuing

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" <jd...@earthlink.net>


> 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.
>
> {^_^}
>