Rules_Du_Jour

[osiris]

Is Rules_Du_Jour still something admins should put in to use today? And if so, any instructions to how? Cause after reading this guide http://www.zimbra.com/forums/adminis...ems-print.html and followed the instructions at Sietse.Net .

But the rules doesnt seem to be in effect at all, for example http://www.rulesemporium.com/rules/70_sare_evilnum0.cf is one of the downloaded rules containing a lot of addresses which should give a score of 2 (score SARE_EN_A_1XX_2 2.0)(I take..?). But when I grab a few addresses from there and send in an e-mail from my yahoo mail to my zimbra system it doesnt get tagged with the expected 2.0 (at least..).

But when reading that file a bit more from the top:
# Created: 2004-01-02
# Modified: 2005-03-19
makes me wonder if this is heavily outdated and nothing to waste time on...


If its a waste of time, is it any other similar solutions thats updated?

[osiris]

Ok, now I am starting to get seriously confused with zimbra..

Been playing a bit with OpenProtect's SpamAssassin sa-update channel to test, and from I can see there those things are based on the old Rules Du Jour or SARE or what to call it ;p But the guide pasted above works with dirs outside /opt/zimbra, and then it suddenly (after creating various dirs etc that sa-update needed...) takes those (seems also to be rather old..) rules in to consideration. I thaught whole zimbra setup worked inside /opt/zimbra, at least most of it?

Which brings me to ask, which spamassasin setup is supposed to be the running one? The conf and such inside /opt/zimbra/conf/spamassassin or the ones in /var/lib/spamassassin/3.001009/ ? Which also makes me wonder, is maybe the autolearning of spam/ham not working properly cause it trains the spamassasin rules in /opt/zimbra/conf/spamassassin but spamassasin actually uses /var/lib/spamassassin/3.001009/ and so forth.

Anyone can clearify a bit for me?


--PS!--
To keep me even more confused, after making the dirs sa-update (ran as root) told me where missing, and importing default rules + SARE rules there (as explained above) the spamassasin filter works better. Suddenly spam gets much higher score then before and the % of the caught spam went up. and the list of scores is much longer then before (see paste below).. Obviously I have triggered something here, but, its not supposed to be this I way I take, something gotta be wrong somewhere here, just afraid I sit here now with 2 spamassasins, 1 new one now outside(!) /opt/zimbra that actually checks the e-mails that comes in, and one inside /opt/zimbra that gets trained with Junk / Not Junk button of users, but thats actually aint in use at all....

X-Spam-Status: Yes, score=13.362 tagged_above=-10 required=5
	tests=[BAYES_50=0.001, FB_ADD_INCHES=2.131, HTML_MESSAGE=0.001,
	RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1, SARE_SUB_INCHES=0.221,
	URIBL_AB_SURBL=1.86, URIBL_BLACK=1.955, URIBL_JP_SURBL=1.501,
	URIBL_OB_SURBL=1.5, URIBL_SBL=1.499, URIBL_SC_SURBL=0.474,
	URIBL_WS_SURBL=1.5]

[dwmtractor]

OK, this sounds strange. By your description I'm almost certain you have got a double installation of SpamAssassin running. It'd be interesting to have a look at your headers, but I wonder if you've got the mail running through BOTH because they are separate installations??? Sounds weird, but may be possible depending on how the proxy is behaving.

But I think you're playing with fire having multiple installs, and the possibility of breaking something so that all of a sudden your queue freezes b/c amavisd is not managing to get things thru the filters is a real possibility. There have been other threads discussing updating the spamassassin install within /opt/zimbra; I believe they revolved around installing the spamassassin utilities (like sa -update) into the Zimbra installation directory. Unfortunately I'm having trouble coming up with the right search terms to find the thread I know I've seen; perhaps another user will have better luck. At any rate, I can't testify to how well this works because I have not tried it. There is a wiki article about updating ClamAV; I suspect something similar can be done with SpamAssassin as well.

The real issue, getting SpamAssassin updates more frequently than the Zimbra package updates, is partially addressed by this bug, which you should consider visiting and voting for:
Bug 15137 - Breakout RPM packages for ClamAV, SpamAssassin and Others to allow out of cycle updates

There are other threads on this forum discussing the topic as well, particularly this one:
Zimbra ClamAV Security Updates?

Bottom line, I understand why you want to do this, and so do some others. I think perhaps instead of the above thread, a bug/RFE should be filed requesting that the necessary updater tools for SA and Clam both should be integrated into the Zimbra install; feel free to file such a bug if you wish, or I'll do it on the strength of a bit more discussion/feedback.

Cheers,

Dan

[osiris]

Yes, sure seems like that there is 2 running for some weird reason, unsure if the default Red Hat Enterprise Linux 5 comes with spamassasin and that somehow have taken control over the zimbra version of spamassasin.

Doubt the traffic goes trough both, but what it seems like is that traffic actually goes trough the one outside /opt/zimbra , but training of the spamfilter goes to the spamassasin in /opt/zimbra. Which makes the whole solution quite "useless" atm, set in ""s cause it catches spam by all means, but when users use the Junk button the filter in use aint actually in use. These are speculations, but it sure seems like it.

What would you suggest I do to make absolutly sure that it uses only the one in /opt/zimbra (I expect thats whats it supposed to do right?) so I could remove any reference to spamassasin I can find outside /opt/zimbra (is that safe to do?).

A question for later testing, if I send an e-mail, with some text, lets say just some random spam message grabbed from a website posting spam they have recived, but make sure its an e-mail not going above my minimum score. When it reaches my inbox, hit the junk button and run /opt/zimbra/bin/zmtrainsa as zimbra user. Should that e-mail get caught as spam the next time I send it, or after the 2nd time I do that procedure or? Cause I did this test, I marked it as spam about 7 times and it still didnt get marked as spam which was the first thing to make me wonder that something isnt working as it should with spamassasin.

Appricate all the help to resolve this matter.

[phoenix]

There should be no reason why the installed Spamassassin in RHEL should be used rather than the one in Zimbra, the Zimbra SA is called as a perl module and has nothing to do with the RHEL SA (I have SA installed on my system and it's not causing problems).. You should, of course, make sure that the installed SA is disabled from starting, as it's normally run as a daemon.

There should also be no problem running sa-update to update the rules in Zimbra, I used to use rules-du-jour without problems. You should use sa-update and point it to the correct Zimbra directories that contain your rules and use the 'channels' to update them. Details on running sa-update and the channels are on these pages:

SareChannels - Spamassassin Wiki
http://daryl.dostech.ca/sa-update/sa...date-howto.txt
OpenProtect's SpamAssassin sa-update channel
SpamAssassin at Arda.Homeunix.Net

That should point you in the right direction.

[osiris]

Should there not be a sa-update in the zimbra package? Can only find sa-learn, removed now the spamassasin package in RHEL, and all seems to work fine still. But wanted to look more in to the links you pasted, but stoped at the sa-update part.. I expected to find that in /opt/zimbra/libexec but nopes..

[phoenix]

Originally Posted by osiris

Should there not be a sa-update in the zimbra package? Can only find sa-learn, removed now the spamassasin package in RHEL, and all seems to work fine still. But wanted to look more in to the links you pasted, but stoped at the sa-update part.. I expected to find that in /opt/zimbra/libexec but nopes..

We don't supply a copy of sa-update, if you think it should be then then file an RFE.

There is no problem using sa-update from the RHEL installed spamassassin, all it does is update the installed rules.

[osiris]

Thank you for all your help, been very helpfull. Just one last thing about the commands, just to make sure I got the hang of things now..

OpenProtect's SpamAssassin sa-update channel for that link, everything about
gpg --keyserver
gpg --armor etc just as the commands there say, no extra needed, but for the line:
sa-update --gpgkey D1C035168C1EBC08464946DA258CDB3ABDE9DC10 --channel saupdates.openprotect.com

I would actually use:
sa-update --updatedir=/opt/zimbra/conf/spamassassin --gpgkey D1C035168C1EBC08464946DA258CDB3ABDE9DC10 --channel saupdates.openprotect.com

should I also add su - zimbra -c sa-update --updatedir=/opt/zimbra/conf/spamassassin --gpgkey D1C035168C1EBC08464946DA258CDB3ABDE9DC10 --channel saupdates.openprotect.com ? or doesnt that matter at all for this?

[phoenix]

Make sure that you run the script as the Zimbra user or the file ownership will get hosed and also add the --checkonly & -D for a test run to make sure that it works and gives you some debug output. I'd also suggest making a copy of the original rules before running the update, just in case. Don't forget that these changes won't survive any upgrades to Zimbra and will need to be done after an upgrade.

[phoenix]

BTW, you may find that when you run the update with the -D debug option that there's some perl modules not installed - you can install them without problems via YUM.