sauser.cf not being read

[britesc]

Hi,
Whatever I put in sauser.cf in ... /localrules does not seem to be being read as none of the actions seem to happen such as add_header etc.

I am using 8.7.1 on Ubuntu 14.04 fresh install of both.

Is there anyway I can check it is being parsed?

Thank you and kind regards,

jB

[DualBoot]

Since 8.7 some parts of the configuration have been moved to other folder.
Like this one /opt/zimbra/common/conf/ .
You can also check amavisd.conf to know where the conf are located.

[britesc]

Hi DualBoot,

Thanks for the reply.
I tried looking in the /opt/zimbra/common/conf/ folder but cannot find anything appropriate to spamassassin conf or rules.
So looked at amavisd.conf and found at line 133 (using nano -c) #$sa_configpath = '/opt/zimbra/conf/spamassassin';
I made a copy of the line and uncommented it so it now looked like $sa_configpath = '/opt/zimbra/conf/spamassassin'; #20161213

I then run zmamavisdctl restart and zmmtactl restart
If I now look at amavisd.conf my line has been removed and the commented out line is back in place.

The same happens if I run zmcontrol restart.

So I am back to square 1 with no ability to read my rules files etc.

I assume this is a bug and not me being stupid (grin)

Thanks and kind regards,

jB

[JDunphy]

For me:

Code: Select all

vi /opt/zimbra/data/spamassassin/localrules/sauser.cf
/opt/zimbra/common/bin/spamassassin --lint
zmantispamctl restart

Note: with 8.7+, I put my perl plugins at: /opt/zimbra/common/lib/perl5/Mail/SpamAssassin/Plugin/

Hint: /opt/zimbra/conf/zmconfigd.cf

Reference: https://wiki.zimbra.com/wiki/Anti-spam_Strategies

[britesc]

Hi JDunphy,

Thanks for the hint about using --lint.
I ran it both with and without the debug switch.
Firstly it reports that the first 2 lines of my sauser.cf have errors.
So I commented them out. But it proves that it is reading the files in /etc/opt/data/spamassassin/localrules/ which I confirmed by using the -D option and watched the whole output.

Code: Select all

#rewrite_subject        1                 #20161205
#subject_tag _STARS(*)_ SPAM _STARS(*)_   #20161212

I cannot find anywhere that says that the above 2 lines are wrong so am baffled?????

But although the files are parsed by the --lint option the contents are not used, even more confusing???

Looks like there is a mess with the spamassassin config and setup in 8.7.1 but I will keep working.
Not sure how to report a bug etc.

Regards,

jB

[JDunphy]

That is really odd.

Did your -D --lint check run under the zimbra user so that you get their perl, modules, etc.

I don't have a ubuntu install to check against but the behavior you describe is so different from my centos 6. That /etc/opt directory should be empty I would think.

perl -V should tell you @INC search preference. I thought zimbra installed their stuff under /opt/zimbra. On a centos 6 host running perl -V as the zimbra user shows:

Code: Select all

  @INC:
    /opt/zimbra/common/lib/perl5/x86_64-linux-thread-multi
    /opt/zimbra/common/lib/perl5/x86_64-linux-thread-multi
    /opt/zimbra/common/lib/perl5
    /usr/local/lib64/perl5
    /usr/local/share/perl5
    /usr/lib64/perl5/vendor_perl
    /usr/share/perl5/vendor_perl
    /usr/lib64/perl5
    /usr/share/perl5
    .

whereas if you run the same command as a non zimbra user

Code: Select all

 @INC:
    /usr/local/lib64/perl5
    /usr/local/share/perl5
    /usr/lib64/perl5/vendor_perl
    /usr/share/perl5/vendor_perl
    /usr/lib64/perl5
    /usr/share/perl5
    .

Do you have a local installation of spamassassin that is taking precedence. I don't know the exact command for your OS ... perhaps dpkg -s spamassassin but in RHEL we do it as:

Code: Select all

yum provides '*/spamassassin'

They use https://bugzilla.zimbra.com to track bugs but I didn't see anything like you are describing.

[britesc]

Hi JDunphy,

And dork of the year goes to ME !!

The data path should have read /opt/zimbra/data/spamassassin/localrules/ etc - I have an fstab bind that moves zimnra to another raid array mounted on /data and I wrote down the wrong path sorry.
I use an SSD with the OS then a 3 Drive Raid 5 to hold the application.
It makes boot up and maintenance really fast.

Anyway I used the Admin Web GUI and typed in *** This is Spam *** when I saved it it was saved to amasvid.conf as $sa_spam_subject_tag = '*** This is Spam ***';
It is not possible to edit the amasvid.conf by hand as it is overwritten on relaunch.

I then did a zmprov gacf | grep -i This ,which gave me zimbraSpamSubjectTag: *** This is Spam ***

From this it looks like ALL configuration details are now held in the main zimbra config I assume this is on LDAP.
The data is written out to the relevant .conf files on startup or change from inside the WEB Admin GUI etc.

I assume it is not only this config line but there is a major naming difference between the zmprov variable and the amasvid variable.
I am going to print out the contents of zmprov gacf and see what relates to amasvid.conf and see if I can use it to make the changes I had listed in sauser.cf.

Stay tuned... More Later

Regards

[JDunphy]

#rewrite_subject 1 #20161205
#subject_tag _STARS(*)_ SPAM _STARS(*)_ #20161212

From my perspective, your rules above have syntax errors for version 3 spamassasin. Ref: https://wiki.apache.org/spamassassin/SubjectRewrite

As an aside:

The latest rules from /opt/zimbra/libexec/zmsaupdate via cron are here.

/opt/zimbra/data/spamassassin/state/3.004001/updates_spamassassin_org

zmsaupdate is a perl script so you can see what commands it calls and perhaps study the rules in this directory to see similar rules for your changes.

Code: Select all

cd /opt/zimbra/data/spamassassin/state/3.004001/updates_spamassassin_org
grep rewrite_header *
local.cf:# rewrite_header Subject *****SPAM*****

or better yet.

Code: Select all

grep Subject /opt/zimbra/data/spamassassin/localrules/salocal.cf
# rewrite_header Subject *****SPAM*****
rewrite_header Subject *SPAM* _STARS(*)_