(Top posting to preserve content and present a short additional comment.)
This appears to be fixable with an upgrade of perl. I had been running
perl5 5.8.5 for Mandrake 10.1. I am now running 5.8.6 per Fedora Core 4
and am not seeing this problem. It may be a perl problem rather than a
SpamAssassin problem. (If it does hit again and get trapped I'll make a
note of it here.)
{^_^}
----- Original Message -----
From: "jdow" <[EMAIL PROTECTED]>
To: "spamassassin-users" <users@spamassassin.apache.org>
Subject: error: Insecure dependency in eval while running setuid at
/usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/PerMsgStatus.pm line 2119._
, continuing
> 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.
>
> {^_^}
>
