Bug 5776

do you use allow_user_rules?

have you additional rules defined in /etc/mail/spamassassin ?

does "spamassassin --lint" pass?

oh -- for reference, line 1026 is marked by ### below:


sub hash_line_for_rule {
  my ($self, $pms, $rulename) = @_;
  return "\n".'#line 1 "'.                           ###
        $pms->{conf}->{source_file}->{$rulename}.
        ', rule '.$rulename.',"';
}

> do you use allow_user_rules?
>
>

No.

> have you additional rules defined in /etc/mail/spamassassin ?
>
>
Yes.

Ah! It seems to be caused by my shortcircuit.cf, modified from the one on the SA
wiki
(http://wiki.apache.org/spamassassin/ShortcircuitingRuleset)

If I comment out the following rule:

# simple, non-network-based whitelists, locally-generated messages,
# messages via a trusted relay chain, simple, non-network based blacklists
meta SC_HAM
(USER_IN_WHITELIST||USER_IN_DEF_WHITELIST||USER_IN_ALL_SPAM_TO||NO_RELAYS||USER_IN_BLACKLIST_TO||USER_IN_BLACKLIST)
priority SC_HAM -1000
shortcircuit SC_HAM ham
score SC_HAM -20

the error stops.

> does "spamassassin --lint" pass?
>
>
Yes

I had the same problem when I upgraded from 3.2.3 to 3.2.5. Downgrading to 3.2.4 did not solve it, but returning to 3.2.3 did. 

I also narrowed it down to the ShortCircuit plugin, when disabled it stopped filling my log files.

Removing the lines suggested in the previous entry also made it go away, although these seem like they were useful short-circuits.

This is happening to me also on a few boxes, but I have one where it is not running the same spamassassin packages.  

I can't find allow_user_rules anywhere in the config directory, so I'm assuming I'm running whatever is default.

spamassassin --lint passes.

quite a few rules additional rules are defined as well.

Disabling the shortcut plugin in v320.pre fixes it.

I'm just adding short circuiting now, so I have no idea if this was a problem with previous builds or a regression.

I can provide additional debugging if required.

Forgot to mention, this is happening to me on Intel/Linux, so it's not a Solaris or Sun specific bug.

I just tested this on another box with the same linux version and packages but couldn't reproduce it.  I then took one of the spamd boxes that had the issue out of RR DNS and did some testing with it.  I couldn't reproduce it with any sample messages I had (ones that SC'd, and ones that didn't), so it's either a load issue or a formatting issue on incoming email.  The first and second messages scanned after putting it back into RR DNS both triggered the error.  It also appears to have crippled the chances for new children to start, it seems to get hung at 2 children.

Unlike the original poster, my spamd is pretty much unusable when it's spewing that many log entries and I have to disable the plugin again.

> Unlike the original poster, my spamd is pretty much unusable when it's spewing
> that many log entries and I have to disable the plugin again.

Are you saying that you're disabling the Check plugin?  Don't do that.  Without that plugin your SA install will not scan messages at all and should be producing loud warnings.

(In reply to comment #8)
> > Unlike the original poster, my spamd is pretty much unusable when it's spewing
> > that many log entries and I have to disable the plugin again.
> 
> Are you saying that you're disabling the Check plugin?  Don't do that.  Without
> that plugin your SA install will not scan messages at all and should be
> producing loud warnings.
> 


No, I disabled the shortcircuit plugin.

I've noticed the default 

shortcircuit USER_IN_WHITELIST       on
shortcircuit USER_IN_DEF_WHITELIST   on
shortcircuit USER_IN_ALL_SPAM_TO     on
shortcircuit SUBJECT_IN_WHITELIST    on
shortcircuit USER_IN_BLACKLIST       on
shortcircuit USER_IN_BLACKLIST_TO    on
shortcircuit SUBJECT_IN_BLACKLIST    on

doesn't seem to cause the errors but adding

shortcircuit SC_HAM ham

breaks it.  Should it be   "shortcircuit SC_HAM  on  ham" maybe?

Any chance this will get fixed in 3.3.0?  I can't find any commits that appear to touch this.  I've noticed a severe lack of others having this issue - is there something we can do to debug why we're having the problem and others aren't?

This is perl, v5.10.0 built for i686-linux-thread-multi

Intel hardware, Linux 2.6.26 i686.

What changed here between 3.2.3 and 3.2.4?

> Any chance this will get fixed in 3.3.0?  I can't find any commits that appear
> to touch this.  I've noticed a severe lack of others having this issue - is
> there something we can do to debug why we're having the problem and others
> aren't?
> This is perl, v5.10.0 built for i686-linux-thread-multi
> Intel hardware, Linux 2.6.26 i686.
> What changed here between 3.2.3 and 3.2.4?

I can't reproduce this with current 3.3 SVN code when running a command-line
spamassassin, even when using the mentioned rules. No idea.

moving most remaining 3.3.0 bugs to 3.3.1 milestone

these were not supposed to go to security!  moving back out of that component, but now probably to the wrong components :( , but better than nothing.

these were not supposed to go to security!  moving back out of that component, but now probably to the wrong components :( , but better than nothing.

reassigning, too

I've updated to a newer version of Debian (Lenny) and am using 3.3.0 and I re-enabled the Short Circuit plugin and am no longer seeing this problem.

> I've updated to a newer version of Debian (Lenny) and am using 3.3.0 and I
> re-enabled the Short Circuit plugin and am no longer seeing this problem.

Thanks! I'm closing this as resolved. Please re-open if the problem reappears.