Re: [AMaViS-user] NULL spam_subject_tag still rewrites header (SQL)

[Joel <jdl...@ei...>]

Mark Martinec wrote:
> Joel,
>
>   
>> I have set up Postfix/Amavis on openSuSE 11.2 with the SQL schema from
>> http://www.ijs.si/software/amavisd/README.sql-mysql.txt. I'd like to
>> include the X-Spam headers in all of my e-mail, at least initially while
>> I test things. I created a new policy with spam_tag_level=-999,
>> spam_tag2_level=3, and nothing in spam_subject_tag (so it takes the
>> default of NULL), and I get this on a mail sent with subject "test":
>>
>> X-Spam-Flag: NO
>> X-Spam-Score: -1.975
>> X-Spam-Level:
>> X-Spam-Status: No, score=-1.975 tagged_above=-999 required=3
>> 	tests=[AM:BOOST=-4.155, AWL=-0.719, TVD_SPACE_RATIO=2.899]
>> 	autolearn=no
>> X-Amavis-PenPals: age 6 14:47:14
>> Subject: ***SPAM*** test
>>
>> This seems rather odd to me. It looks like I can make the subject
>> rewrite go away by changing spam_subject_tag to an empty string, but why
>> doesn't NULL do the same thing? And where is that '***SPAM*** ' prepend
>> coming from? I can't find that string anywhere in my amavisd.conf or
>> /etc/spamassassin/* (I've set $sa_spam_subject_tag to some other string,
>> but it does not appear to be used). If a NULL result from the SQL query
>> means "use the default found at X" I'm ok with that, but I'd like to
>> know where I should define that default.
>>     
>
> It is odd. Which version of amavisd? A log at level 5 would explain what
> is going on.
>
> The NULL in a SQL table means: this (sql) lookup table does not have an
> answer, continue lookups with a next lookup table in the corresponding
> @*_maps list of lookup tables. Effectively, a NULL means that static
> lookup tables will provide a result.
>
> Unlike a NULL, an empty string is a definite answer, a search stops
> there, the result of a lookup is an empty string, no remaining statical
> lookup tables are consulted.
>
>   
>> It looks like I can make the subject
>> rewrite go away by changing spam_subject_tag to an empty string,
>> but why doesn't NULL do the same thing?
>>     
>
> The 'spam_subject_tag' SQL field is an implicit first entry in a list
> of lookup tables @spam_subject_tag_maps. By default its only remaining
> element is $sa_spam_subject_tag1. Note a mismatch in names: for historical
> (upward compatibility) reasons this is a default:
>
>   @spam_subject_tag_maps  = ( \$sa_spam_subject_tag1 );
>   @spam_subject_tag2_maps = ( \$sa_spam_subject_tag );
>
> So perhaps your $sa_spam_subject_tag1 is set to '***SPAM*** ' ?
> There is no ***SPAM*** string in the amavisd program itself,
> so it must be coming from your config files or SQL/LDAP lookups.
>
> Btw, the SQL field 'spam_subject_tag2' is the one usually used
> (it applies at tag2_level), not the 'spam_subject_tag' which
> applies at $tag_level.
>
>   Mark
>
>   
Thanks Mark. All that makes sense, including amavis continuing to look
when it gets a NULL from the DB. I just couldn't figure out where it was
getting that new result. I suppose I could have made my post a lot
shorter by just asking that.

Problem was, I was only looking in the obvious places (various conf
files). Upon closer inspection of the construction of $sql_select_policy
in amavisd, I see my error. Particularly:
  # The %k will be replaced by a comma-separated list of query addresses
  # for a recipient (e.g. full address, domain only, catchall)
and the 'ORDER BY users.priority DESC' part. Somehow, I had a policy for
the catchall email (@.) that had spam_subject_tag='***SPAM*** '. It
didn't occur to me that amavis would check more policies than that for
my specific email address. Of course, now it seems obvious that it would
do so.

In short, I removed the spam_subject_tag for that catchall policy, and
all seems to be well.

Thanks again and sorry for the noise,
Joel