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