> > Matt Doran wrote: >> Matt Kettler wrote: >>> On 1/7/2010 9:14 PM, Matt Doran wrote: >>>> Hi guys, >>>> >>>> I was recently doing some reconfigurating/optimization of our >>>> SpamAssassin setup. And I've started seeing the following entries >>>> in the mail.log. They don't appear for every mail processed, but >>>> it does happen multiple times a day. >>>> >>>> I'm running Debian stable, SpamAssassin 3.2.5 in daemon mode, and >>>> using sa-update to keep the rules up-to-date. I enable the >>>> shortcircuiting plugin to implement some of these optimizations, >>>> and I'm wondering whether this is what introduced these problems. >>>> >>>> >>>> There seems to be 2 classes of warning. The first is this: >>>> >>>> no meta_dependencies defined for SUBJ_RE_NUM at >>>> /usr/share/perl5/Mail/SpamAssassin/Plugin/Check.pm line 414. >>>> Use of uninitialized value in split at >>>> /usr/share/perl5/Mail/SpamAssassin/Plugin/Check.pm line 417. >>>> >>>> These 2 lines are repeated over and over for about 280 different rules. >>>> >>>> >>>> Then next warning is about an "uninitialized value in >>>> concatenation". The warning can look a bit different but it's >>>> always at the same line. Here's some examples: >>>> >>>> Use of uninitialized value in concatenation (.) or string at >>>> /usr/share/perl5/Mail/SpamAssassin/Plugin/Check.pm line 1028. >>>> last message repeated 1088 times >>>> >>>> and >>>> >>>> Use of uninitialized value in concatenation (.) or string at >>>> /usr/share/perl5/Mail/SpamAssassin/Plugin/Check.pm line 1028, >>>> <$tmpfile> line 2290. >>>> >>> <snip> >>>> >>>> I didn't see these warnings before my changes. Any ideas on the >>>> cause of these and how to resolve them? >>> > OK, I think I'm onto something here. The warnings would appear for > the first message processed by that process. I was able to reproduce > by restarting the daemon and sending in a new message. > > >From my experimenting with the shortcircuit plugin I know that it has > the ability to change the order rules are evaluated (based on the > "priority"). So I suspected that the order that rules are evaluated > introduced this problem. I added a short-circuit rule for NO_RELAYS, i.e. > > shortcircuit NO_RELAYS ham > > > If I remove this rule, I no longer see the warnings. Hmmmm. > > So now I need a SA/shortcircuit guru to help me understand what I did > wrong. Is there a way for me to short-circuit when there are no > relays without introducing these problems?
Well, let's back up a bit. NO_RELAYS is an *error*. This should never happen. If it is happening, you very likely have a problem that needs fixing for SA to work accurately. Usually if this is firing off, you've integrated SA in a way that it never sees Recieved: headers generated by your local MTA, which is bad. (all mail should have at least one Received: header before it gets to SA, even if it's just saying "received from localhost by localhost".) Usually this is from a borked MTA layer integration. So, my personal recomendation would be to stop trying to shortcircuit this rule, and figure out why there are no Received: headers in the message.
