spamassassin-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Kettler <>
Subject Re: Warnings in mail.log: "no meta_dependencies defined", "Use of uninitialized value in split", "Use of uninitialized value in concatenation"
Date Fri, 08 Jan 2010 03:09:38 GMT
> 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/ line 414.
>>>>     Use of uninitialized value in split at
>>>>     /usr/share/perl5/Mail/SpamAssassin/Plugin/ 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/ line 1028.
>>>>     last message repeated 1088 times
>>>> and
>>>>     Use of uninitialized value in concatenation (.) or string at
>>>>     /usr/share/perl5/Mail/SpamAssassin/Plugin/ 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.

View raw message