Hi, I'm trying to update SpamAssassin rules but I get stuck to this version: svn917659. Is it the last version available? I'm a bit perplex because some IPs are officially blacklisted on 10 different RBLs but SpamAssassin is still not detecting their messages as Spam... Are you guys experiencing the same kind of problem? Thanks in advance for your help!
OK, I just run sa-update -D and I learn a lot already! For instance, I can see my version of SpamAssassin is outdated (v 3.3.2) when SA official website is mentioning that: Regular updates of SpamAssassin 3.2.x rules stopped in 2008. Accuracy depends on more recent rules. Upgrade to 3.3.0 or newer. Would that explain my problem with rules not being updated? I run the latest version of ISPConfig, so I don't see why SpamAssassin is so old... Thanks!
Spamassassin is provided by your operating system, quite independent of ispconfig. You don't mention what OS this is on, maybe debian wheezy? If so, you could get SA 3.4.0 from wheezy-backports, more easily than upgrading your whole OS. But unless you have a reason you can't, you might want to schedule a time to upgrade at some point, as other software gets better too (eg. php versions). https://packages.debian.org/search?keywords=spamassassin
Looks like this is the version of the sa-update script; that won't change nearly as often as the rules themselves. Code: root@host:~# sa-update --version sa-update version svn1475932 running on Perl version 5.14.2 root@host:~# grep version /var/lib/spamassassin/3.004000/updates_spamassassin_org.cf # UPDATE version 1742071 root@host:~# (on a wheezy host running SA 3.4.0 from wheezy-backports) No, you have 3.3.2, which is newer than 3.2.x that warns you about, so that won't prevent rules from updating. Check /var/lib/spamassassin/3.003002/ and see what the latest file timestamps are; if they're not terribly old (maybe a few days, or even weeks at times), sa-update is getting new rules. If they are quite old, you might check and make sure there is a cronjob set to run sa-update. That older version certainly could explain Spamassassin not working as well. For the RBL issue specifically, do you happen to see URIBL_BLOCKED hitting a lot? If so you need to use a different DNS server, eg. setup a local caching server right on your mail server.
Oh waw, thank you so much Jesse for all of this information! Your're right about the svn number, sorry about that. My rules are using this number: 1742071, which seems to be the same as yours ;-) You're right again concerning SpamAssassin version: 3.3.2 is high enough to get rules updated apparently! I've read too quickly :-/ I noticed something though, concerning the default cron job visible in /etc/cron.daily/spamassassin : Code: CRON=0 I guess I have to change this to 1 in order to turn the lights on? About SpamAssassin version, the fact that it's disabled during ISPConfig installation in profit of Amavis is confusing me though. It it's disabled, why would it be important to be up to date? For your last question about URIBL_BLOCKED, I can't see anything at all because nothing is applied. No rule at all. Which means I can't see any score in the header. Same behaviour as clean emails actually. Really annoying... Thanks again for your great help!
Yes, set that in /etc/default/spamassassin. Do you mean the spamassassin daemon, spamd? Ispconfig uses amavisd-new, which loads and uses spamassassin perl libraries directly, it doesn't hand the message to spamd for scanning, so spamd can be disabled. Does amavis seem to get the message at all (eg. maybe there is a X-Virus-Scanned: header added)? What did you mean by saying spamassassin was disabled during ispconfig installation? You could download the ispconfig tarball and run update.php from it to reconfigure your services again if that is in question. (Or possibly you have everything installed, you just need to set the right spamfilter policy for this domain in the ispconfig gui?)
I just did that, thanks! Do I need to restart SpamAssassin or anything? I guess not but just in case. I'm referring to this in the install process: Code: service spamassassin stop systemctl disable spamassassin To me, this is not Spamd but SpamAssassin that is disabled... Also, when I check in /etc/default/spamassassin, I see this at the top: Code: # Change to one to enable spamd ENABLED=1 Yes, it seems to be scanned! I see the specific header for this ( X-Virus-Scanned : Debian amavisd-new at xxxxxx.com). Nothing else though. It's like nothing was suspicious for SpamAssassin, though the simple IP is itself present in like 10 RBLs already. Which is insane imho :-/ And my spam filters are really agressive. The first level is at 0, while the second one is at 0.5. All in all I would say SA does his job for 95% maybe. What,s bothering me is that for the remaining 5%, there's not even a small score. It's considered as clean. Hence my initial question
Nope, the cronjob runs every day already, it just exits immediately if CRON=0. That disables the spamassassin service, aka spamd. This is fine/good, as amavisd-new doesn't use it. Ah, so most spam does have a header for X-Spam-Status and friends?
Perfect! The cron job ran properly last night. It's just giving me some errors for permission reasons but that's another issue we can fix pretty easily. OK, sorry I just got a bit confused here ;-) Yep! It's just some of them (~5%) that have nothing else than the "X-Virus-Scanned" mention. Except from the usual headers off course ("Return-Path","Received"). As an example, this is the kind of IP that is used by spammers. This only "detail" should trigger SpamAssassin in my opinion: http://mxtoolbox.com/SuperTool.aspx?action=blacklist:68.235.36.140&run=toolpage
