Re: SA not picking up rules from /var/lib/spamassassin/
On Wed, Jan 13, 2010 at 10:11 AM, Geoff Soper wrote: > > OK, I'm slightly confused as to what the advice is here. Is there consensus > on SAREs? Should I still use them (via the channel list described at > http://wiki.apache.org/spamassassin/SareChannels ) or is it better not to > use them? I get the impression that there is consensus on the OpenProtect > channel being a bad thing. I have been using the list here, with good results. Of the two groups of rules he lists, I regularly update the first group and only updated the second group once (just to get them - they aren't updated any more, so no point in pulling them regularly): http://khopesh.com/wiki/Anti-spam -- -ste
Re: SA not picking up rules from /var/lib/spamassassin/
On Wed, Jan 13, 2010 at 8:53 AM, Geoff Soper wrote: > I've now added the saupdates.openprotect.com > channel which contains recommended SAREs rules and all is working! I thought I read that no one should be using openprotect as it's hoplessly out of date. ?? -- -ste
Re: Should I use greylisting
> Personally, I didn't like the added delay for first-time mails, which is > why I chose to greylist only on blocklists, but for a minimal effort my > spam was significantly reduced. what are you using to greylist based on blocklists? I use maRBL. The latest version lets me greylist (I use sqlgrey, but there are others) anyone who is found on whatever RBLs I configure it to check, and any connection that comes from a Windows box (the vast majority of which are botnet zombies). It has had an immense impact on the amount of spam that gets through to be looked at by SA & clamav. I've been very happy with it. -- -ste
Lint messages from sa-update
Both of my systems reported: Subroutine __CTYPE_HTML_head_test redefined at /tmp/.spamassassin25471WRu8v8tmp/20_ratware.cf, rule __CTYPE_HTML, line 6. Subroutine __FROM_EBAY_head_test redefined at /tmp/.spamassassin25471WRu8v8tmp/80_additional.cf, rule __FROM_EBAY, line 6. Subroutine __HAS_RCVD_head_test redefined at /tmp/.spamassassin25471WRu8v8tmp/20_compensate.cf, rule __HAS_RCVD, line 6. Subroutine __THEBAT_MUA_head_test redefined at /tmp/.spamassassin25471WRu8v8tmp/20_ratware.cf, rule __THEBAT_MUA, line 6. Subroutine SUBJECT_DIET_head_test redefined at /tmp/.spamassassin25471WRu8v8tmp/20_head_tests.cf, rule SUBJECT_DIET, line 6. Subroutine __AOL_FROM_head_test redefined at /tmp/.spamassassin25471WRu8v8tmp/20_ratware.cf, rule __AOL_FROM, line 6. Subroutine FROM_BLANK_NAME_head_test redefined at /tmp/.spamassassin25471WRu8v8tmp/20_head_tests.cf, rule FROM_BLANK_NAME, line 6. Subroutine __CT_TEXT_PLAIN_head_test redefined at /tmp/.spamassassin25471WRu8v8tmp/20_head_tests.cf, rule __CT_TEXT_PLAIN, line 6. Subroutine __MIME_VERSION_head_test redefined at /tmp/.spamassassin25471WRu8v8tmp/20_head_tests.cf, rule __MIME_VERSION, line 6. Subroutine __RATWARE_0_TZ_DATE_head_test redefined at /tmp/.spamassassin25471WRu8v8tmp/20_ratware.cf, rule __RATWARE_0_TZ_DATE, line 6. Subroutine __TOCC_EXISTS_head_test redefined at /tmp/.spamassassin25471WRu8v8tmp/20_head_tests.cf, rule __TOCC_EXISTS, line 6. Subroutine __NONEMPTY_BODY_body_test redefined at /tmp/.spamassassin25471WRu8v8tmp/20_meta_tests.cf, rule __NONEMPTY_BODY, line 10. These weren't fatal, the rules were loaded and amavisd restarted, but I'm not used to getting output from my script. Is something wrong here, or are these redefinitions harmless? -- -ste
Re: No hits on SARE rules.
On 1/1/07, Shaun T. Erickson <[EMAIL PROTECTED]> wrote: Ok, this is interesting. :) The follow-up to this is that I just got spam that was hit by the SARE rules, so it's working now. Additionally, Razor2 & DCC are now working, as well. So the only mystery is why everything installed where it did. I'm guessing that since it's a standalone build of perl, that it compiled it's prefix (/usr/local/perl-5.8.8) into every module as I built and installed them via CPAN, using that version of perl ... just a guess. Btw, thanks for the help everyone. It was your combined knowledge that helped me get it running. -- -ste
Re: No hits on SARE rules.
Ok, this is interesting. :) I removed all SA installations, except for the one under /usr/local/perl-5.8.8. I moved my sa-update-keys directory to /usr/local/perl-5.8.8/etc/mail/spamassassin. I modified my nightly script to use /usr/local/perl-5.8.8/bin/sa-update. I ran my nightly script. Now it has re-downloaded all of my sare rules and so forth to /usr/local/perl-5.8.8/var/spamassassin/3.001007/ When I run amavisd debug-sa, it now finds all the rules that were just downloaded to the above location. I presume I can get rid of the now useless and never used copies that are under /var/lib/spamassassin/... I'm not used to seeing everything under the perl install though ... -- -ste
Re: No hits on SARE rules.
On 1/1/07, Gary V <[EMAIL PROTECTED]> wrote: When you run amavisd debug-sa does it say you are using?: Module Mail::SpamAssassin 3.001007 Yes. Have you run 'sa-update'? I'm wondering if you have files in /var/lib/spamassassin/3.001007/ Yes, I see stuff in there, and in the directories I see the normal SA rules and the SARE rules. If so, you should see something similar to: <...> dbg: config: read file /etc/spamassassin/init.pre That's where it goes astray (?) and uses everything from /usr/local/perl-5.8.8/etc/mail/spamassassin -- -ste
Re: No hits on SARE rules.
Ok. I'm starting to understand this now. I've built perl 5.8.8 and pointed my existing amavisd-new at it, by editing its first line. I then added, via CPAN, any module it complained was missing, each time I tried to run it, until it no longer complained of anything missing (that was required, anyway - I seem to have a fair number of optional modules that start like auto::something that I'm missing and not sure how to get). amavisd is definitely looking at perl 5.8.8 as is evident from it's out put. In fact it's using /usr/local/perl-5.8.8/etc/mail/spamassassin/local.cf as it's config file and the *.pre files it's using are in the same directory and the rules it's loading are in /usr/local/perl-5.8.8/share/spamassassin. It doesn't appear to be reading any other local.cf. I'll work on removing any other versions of SA on the system, except the one under perl 5.8.8. What else can I do to get this to work? I think I'm making progress at least. :) -- -ste
Re: No hits on SARE rules.
On 1/1/07, Gary V <[EMAIL PROTECTED]> wrote: You must be running SA 3.1.4 or older and amavisd-new 2.4.2 or older. Nope. SA 3.1.7 & amavisd-new 2.4.4. I see in amavisd, the line you suggested I add is actually there, but commented out, as a comment there indicates that SA should be able to handle this on it's own. This is a RH9 system (my client won't let me upgrade). I had previously built perl 5.8.7 and installed it in /usr/local/perl-5.8.7 and changed the first line of amavisd to point to it instead of the system perl. Is changing that one line sufficient to insure that that version of perl is the only one that amavis will use for everything perl (including SA)? Since I have some indication that there might be a problem with that version of perl, I'm now building 5.8.8 and will point amavis at that. Anything else I should do? Of course, I'll install all needed module into this new version, via CPAN. -- -ste
Re: No hits on SARE rules.
On 1/1/07, Shaun T. Erickson <[EMAIL PROTECTED]> wrote: What am I doing wrong? I just ran amavisd with the debug-sa option, and as near as I can tell, it appears to only be using the original ruleset - and doesn't even seem to know that I am pulling new rules down with sa-update. I must have missed some important configuration step somewhere ... -- -ste
No hits on SARE rules.
I have two identically (or so I thought) configured mail servers, each pulling down SARE rules (successfully, I might add). One of them shows hits on SARE rules all the time - the other one, never. Aside from simply configuring sa-update to pull the rules down, I'm wondering if there is something I've forgotten to do, on the one server, to actually put them into effect - aside from restarting SA, which has been done numerous times. SA is called by amavisd-new, in both cases, which is restarted any time the rules are updated. What am I doing wrong? -- -ste
Re: SA-UPDATE and recent branches/3.1 rules? or Did I miss an SA version update?
Regardless of the reason, is my SA now broken, and in any case, how do I recover from this? -- -ste
spam from "kntr" top level domain
I'm seeing hundreds of connection attempts from systems claiming to be in the kntr top level domain, on a client's mailserver. I haven't seen these on my own server. Is this new, or are they just finally getting around to a server I admin, so I'm now noticing it? Anyone else seeing this? -- -ste
Re: rules_du_jour question
On 10/29/06, Leander Koornneef <[EMAIL PROTECTED]> wrote: In my experience, using the default sa-update channel, the openprotect channel, auto-whitelisting, proper bayes training(!), pyzor, razor, dcc, SPF and DNS blacklists wil get you a spam detection rate >99%. I'm doing all that, now, I think. The auto-whitelisting seems to be happening on it's own (it does say 'auto' after all, lol), as I see the auto-whitelist file in amavis' .spamassassin directory growing. Likewise, I see the bayes_* files growing, as well. At some point, when it has seen enough stuff, it will just kick in on it's own, yes? I have a feeling that that will not be for quite some time though, as virtually all the spam never makes it onto my system, thanks to the postfix rules I have in place. Amavis/Clamav/Spamassassin have an easy job here. ;) I will have to train it on spam that it misses though. I think I saw a way to have the amavis account pull down and train on the contents of my 'missed_spam' imap folder, via fetchmail ... Also, I generally use X-Spam-Level = 3 as the cutoff value in my email client to filter spam out of my Inbox. I rarely have any false positives. I currently have mine set at 5, but I might go lower after I see how it works for a while. -- -ste
Re: rules_du_jour question
On 10/29/06, Leander Koornneef <[EMAIL PROTECTED]> wrote: If you are using spamassassin 3.1, you can use sa-update to get the SARE rulesets from the channel provided by http://saupdates.openprotect.com/. This negates the necessity to run rulesdujour alongside sa-update. This channel consists only of "safe" rules. Ok. I've set that up and run it and now I have the standard set or rules and the safe sare rules under "/var/lib/spamassassin/3.001007". Two questions: Do many people use the non-sare rulesets that I see are available via rules_du_jour (i.e., TRIPWIRE ANTIDRUG RANDOMVAL BOGUSVIRUS ZMI_GERMAN)? Are those something I'd still likely want to get via rules_du_jour? rules_du_jour restarts amavisd-new after it runs, but sa-update doesn't. Do most people run it out of cron and simply append an (without the quotes, of course) " && /etc/init.d/amavis reload" to the command line? Or is there another, more preferred method? Sorry for sounding clueless. I've never tried using rulsets other than what came with SA before. :) -- -ste
rules_du_jour question
I've just downloaded this and set it up. I see there are MANY rulesets I can choose from, but I have no idea if they are all 'safe' (not even sure what I mean by that). Is there a subset of all these rulesets, that "everybody" uses, or does everyone use all of them? How do you decide which to use and which not to use? -- -ste
Re: Confused about getting plugins to work.
On 10/28/06, Shaun T. Erickson <[EMAIL PROTECTED]> wrote: The current problem is that Pyzor times out trying to contact it's remote server: Because this server (66.250.40.33:24441) - which I got from multiple tries at running 'pyzor discover' - isn't responding. This one (82.94.255.100:24441) - which I got after googling the problem a bit - responds instantly, so pyzor is working now. Now on to see if I can get dcc working. :) -- -ste
Re: Confused about getting plugins to work.
On 10/28/06, Clifton Royston <[EMAIL PROTECTED]> wrote: Did you run the "discover" mode on Razor yet? You need to manually run that (as the user and with the home directory Razor will be running as, in your case amavis) for it to latch onto some servers to use. Yes, and Razor2 is working fine now. The current problem is that Pyzor times out trying to contact it's remote server: -sh-3.00$ pyzor -d check < /tmp/1161702248.P5785Q0M834460.scudder.smxy.org:2,S calculated digest: 925c4bff8e17dd59686ea225f2d2a962e0d8f972 sending: 'User: anonymous\nTime: 1162081338\nSig: ce252b1b6d494ce8e66bc268402a36ad444cc7a0\n\nOp: check\nOp-Digest: 925c4bff8e17dd59686ea225f2d2a962e0d8f972\nThread: 17857\nPV: 2.0\n\n' 66.250.40.33:24441 TimeoutError: Seems to happen each time. -- -ste
Re: Confused about getting plugins to work.
On 10/28/06, Theo Van Dinter <[EMAIL PROTECTED]> wrote: If you want to see Razor debug output, run a message through in the way I mentioned before, ala: spamassassin -D razor2 < message_file > /dev/null will show you only razor2 debug output (most of which will look like output from "razor-check -d", btw). Ok. After moving the .razor home directory to amavis' home directory, where amavis kept trying to recreate it, chowning/chgrping to amavis, it seems to be running just fine, except that I'm not seeing any indication of it in the headers. I think this is because amavis won't mention it unless it gets a hit, which razor hasn't done ... yet. -- -ste
Re: Confused about getting plugins to work.
On 10/28/06, Theo Van Dinter <[EMAIL PROTECTED]> wrote: On Sat, Oct 28, 2006 at 03:12:16PM -0400, Shaun T. Erickson wrote: > Yes, I've gone to the SA site, and read what I can find on these three > plugins, but it's still not clear to me how to enable them and see > that they are actually being used. The short version is to uncomment the loadplugin lines in the *.pre files, and then do "spamassassin --lint -D" and see that the plugins are loaded. I was discovering that on my own ... glad to see I was on the right track, and that I'm not totally clueless after all. :) Ok, concentrating on razor for now ... I removed "use_razor 1" from local.cf, since you said it isn't needed. I just have the module loaded in init.pre. When I run the lint command, I see that it says: [22571] dbg: razor2: local tests only, skipping Razor I tried setting "local_tests_only 0" in local.cf, but lint says it can't parse that, so I removed it. I haven't yet found where to enable this, and I'm not sure why I have to, as documentation I've read says it's on be default. -ste
Confused about getting plugins to work.
I am setting up a new server to replace an old one. The old server ran a version of spamassassin prior to it's use of plugins. I've got my new server up and running (CentOS 4.4) nicely, with amavisd-new (v2.4.3) calling spamassassin (v3.1.7), and SA's default settings are tagging most spam as such. I want to add pyzor, razor and dcc to the mix. Yes, I've gone to the SA site, and read what I can find on these three plugins, but it's still not clear to me how to enable them and see that they are actually being used. Let's start with razor. In /etc/mail/spamassassin/init.pre, I added: loadplugin Mail::SpamAssassin::Plugin::Razor2 In /etc/mail/spamassassin/local.cf, I added: use_razor2 1 I made razor a home directory of "/etc/mail/spamassassin/.razor". I had the perl-Razor-Agent-2.40-1.2.el4.rf rpm installed, but that didn't seem to provide the razor-admin command, so I installed the razor-agents-2.40-1.2.el4.rf rpm, which did. I then ran: razor-admin -home=/etc/mail/spamassassin/.razor -register razor-admin -home=/etc/mail/spamassassin/.razor -create razor-admin -home=/etc/mail/spamassassin/.razor -discover I then restarted amavisd-new. I see no indication that razor is actually being used, nor do I see any errors in my maillog. For pyzor, I loaded the plugin in init.pre and added "use_pyzor 1" in local.cf. I created a home directory for it and added "pyzor_options --homedir /etc/mail/spamassassin/.pyzor" to local.cf. I then went to run: pyzor --homedir /etc/mail/spamassassin/.pyzor discover except that I don't seem to have the pyzor command on my system, nor can I find an rpm that includes it, to install. So, I've commented out the pyzor entries in local.cf and init.pre for now. As for dcc, I enabled the plugin in init.pre and added "use_dcc 1" to local.cf but I saw no effect and have commented those entries out for now. I'm rather confused at this point and it would seem that I don't know what I'm doing. I don't remember these being at all difficult to set up, in the pre-plugin days, but I doubt it's an SA problem. More likely, I'm seriously lacking clue and I'm hoping someone here can help. Thank you, in advance. -- -ste
Re: Book has gone to press
Martin Schröder wrote: On 2004-10-07 10:37:32 -0400, Chris Santerre wrote: http://www.packtpub.com/book/spamassassin "Release date November 1999" Yes, it should be at the press by now. :-) Best regards Martin PS: If it applies to SA3, the description should mention that. Hmm. When I go to that link, it says the release date is October 2004. What are you looking at? -ste
Re: Book has gone to press
Chris Santerre wrote: http://www.packtpub.com/book/spamassassin How does this book compare to the O'Reilly book, by Schwartz? -ste
