Re: spam filter working, but not well
On 6-nov-2006, at 1:54, John Andersen wrote: On Sunday 05 November 2006 15:48, Brian S. Meehan wrote: Hi all, Spam filtering is working, but I'm getting about half the spam in my mailbox. Anyone have tips on adjustments I could make? Here's what I have in the local.cf file: rewrite_header SUBJECT **SPAM** dns_available yes required_score 4.0 bayes_path /etc/mail/spamassassin/bayesfiles/bayes use_bayes 1 bayes_auto_learn 1 bayes_auto_learn_threshold_spam 10 bayes_file_mode 0777 report_safe 0 trusted_networks 192.168.1.101 bayes_ignore_header X-purgate bayes_ignore_header X-purgate-ID bayes_ignore_header X-purgate-Ad bayes_ignore_header X-GMX-Antispam bayes_ignore_header X-Antispam bayes_ignore_header X-Spamcount bayes_ignore_header X-Spamsensitivity Its not clear if you have network tests running or not. How is spamassassin invoked? and: - have you trained you bayes DB with at least 200 HAM and 200 SPAM? - added some safe rules from SARE (for example with sa-update and the http://saupdates.openprotect.com/ channel?) Peter
Re: spamd scan problem
On 27-okt-2006, at 11:40, Frank van den Diepstraten wrote: ok I understand that, but I wan't to know if this causes the problem. So I want to trie it out without that razor thing... But I can't find the config where it's enabled in. Hi Frank, To disable razor, add the following to your local.cf: use_razor2 0 Peter -Oorspronkelijk bericht- Van: John Andersen [mailto:[EMAIL PROTECTED] Verzonden: vrijdag 27 oktober 2006 11:36 Aan: users@spamassassin.apache.org Onderwerp: Re: FW: spamd scan problem On Friday 27 October 2006 01:32, Frank van den Diepstraten wrote: But now the question is where I can disable this razor thing... No no, you want to ENABLE it on the good system. Razor is wounderfull. It just takes a little bit of time, but not a great deal of CPU load. Razor catches a lot of spam with almost a non-existant false positive rate. -- _ John Andersen
Re: Newbie - Need Help in writing rules
On 26-okt-2006, at 20:07, Chris St. Pierre wrote: On Thu, 26 Oct 2006, san wrote: Hi, How to write a rules to avoid below type of mails or is there a rule already which marks this as spam. Everday i get 3 to 4 mails of this type with one picture image which says GDKI No.1 Entertainment industry. Your help is much appreciated and i started using spam assassin recently and still learning it. Check out the SARE rulesets, ImageInfo, FuzzyOcr, ... Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University Or try sa-update with the openprotect channel, it's easy to setup and you get all the rules needed to catch this spam without having to decide which exact SARE rules to use. You'll find a simple howto at http://saupdates.openprotect.com/ Peter
Re: Any ISP's using SpamAssassin with user customization?
On 26-okt-2006, at 23:01, [EMAIL PROTECTED] wrote: So my shell account may be disappearing soon and I'm looking for a recommendation for an ISP that provides SA but also allows me to apply my own perl filter for any mail that arrives. The latter isn't crucial but it's very prefered. Looking basically for webmail (https) imap4 and the ability to launch my own perlscript for an arriving mail and run my own CPAN modules. so basically a domain account and an associated shell account. Anybody running SA on their own colo setup? If so what does that cost? Would be prepared to colo a mac mini somewhere if it was affordable. Just remembered having seen an advertisement for mac mini colo's: http://www.macminicolo.net/ Website says they do not limit what you do on your macmini in any way. HTH Peter
Re: Which release of spamassassin should I use on a Debian sarge system?
On 14-okt-2006, at 19:33, Bob Proulx wrote: Chris Purves wrote: You can also get newer versions of spamassassin from debian-volatile, which maintains packages that update often (such as spamassassin, antivirus, etc). You would need to add the following to your sources.list (although you'll probably want a closer mirror http://www.debian.org/devel/debian-volatile/volatile-mirrors): deb http://gulus.usherbrooke.ca/debian-volatile stable/volatile- sloppy main Even as a Debian user I was not familiar with volatile-sloppy and needed to do some research. For the benefit other Debian users on the list using spamassassin here is a useful thread about it. http://lists.debian.org/debian-volatile/2006/10/threads.html#4 I definitely recommend that you upgrade your spamassassin. The version currently in volatile is 3.1.5. I can't comment as to the differences between using backports, as others have suggested, or volatile. You'll have to research that yourself. If you use volatile, you won't need to update your preferences file, since there is a very small subset of packages in that repository. The sarge-backports depot is based on the Testing track. Testing is a staging area for Stable. That means that a user who only uses Stable but adds Sarge-Backports can upgrade from one Stable release to the next Stable release automatically and all of the package postprocessing should happen correctly. In general when things are pulled from Unstable, Experimental or from Volatile that is not true and may require administrative action in order to adjust things at the next upgrade. Packages may need to be manually added or removed. Configuration files may not automatically get postprocessing in the same way as a normal upgrade. From the debian volitale page (http://www.debian.org/devel/debian- volatile/): * Packages in debian-volatile cannot require any package outside of stable main (or any later version of it) to run or build. Packages need to be auto-buildable within the same (stable) release. This constraint could be relaxed for the sloppy archive, on case by case basis. That needs to be discussed on the list. * Packages need to be conformant to stable policy; we currently take http://release.debian.org/sarge_rc_policy.txt as a hint about what is ok and what not. * The upgrade path from volatile to the next stable release needs to be at least as easy as for the stable release; version numbers in volatile must not be higher than those in testing, for instance. I understant that to mean that, equal to backports, it should be trivial to upgrade to the next release. How the above applies to spamassasin in the two different depots I don't know because I have not looked specifically. It is probably not terrible for a heads up administrator though. At a guess I would say that volatile is more volatile and sarge-backports is more stable. :-) Bob Peter
Re: can't get Bayesian to work when invoked from postfix - SOLVED
Hi All, With the great help of Michel Valliancourt I managed to solve my bayesian problem. Solution, for the archives, is below On 26-sep-2006, at 21:13, Peter Teunissen wrote: After having trained SA with sufficient amounts of ham spam, I have bayesian testing working. When I test it with spamassassin -D testmessage as root it works flawlessly. But, when postfix invokes spamc with user filter, bayes always fails. I tested this by running spamassassing -D tesmessage as user filter and saw some permission errors as shown in the debug output at the end of this mail. I see two things going wrong: 1. it tries to create userprefs for filter, not lethal I guess. How can I keep SA from doing this when invoked from postfix? I use it system wide, so no user prefs are needed. There's no option for spamc mentioned in the manpage to make it run system wide only. Turned out that since I created the user filter spamd runs as with / dev/null for a home folder. Changed that to the directory where my bayes db resides. Problem 1 solved. 2. More seriously, it cannot access /var/spool/spamassassin, so it can't use the bayes DB or the whitelist. But this directory is world readable and writable: I had, due to a lack of knowledge on unix file permissions, not made the directory accesible to the user SA runs at; it could read and write the dir, but not execute. I changed the directory so it is owned by user filter and chmoded it to 0755. The contents are also owned by filter and chmoded to 0660. Eh voila, bayesian works. Thanks Michel! Peter
can't get Bayesian to work when invoked from postfix
Hi All,
After having trained SA with sufficient amounts of ham spam, I have
bayesian testing working. When I test it with spamassassin -D
testmessage as root it works flawlessly. But, when postfix invokes
spamc with user filter, bayes always fails.
I tested this by running spamassassing -D tesmessage as user filter
and saw some permission errors as shown in the debug output at the
end of this mail.
I see two things going wrong:
1. it tries to create userprefs for filter, not lethal I guess. How
can I keep SA from doing this when invoked from postfix? I use it
system wide, so no user prefs are needed. There's no option for spamc
mentioned in the manpage to make it run system wide only. At the
moment is is invoked as
spamassassin
unix - n n - - pipe
user=filter argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f $
{sender} ${recipient}
2. More seriously, it cannot access /var/spool/spamassassin, so it
can't use the bayes DB or the whitelist. But this directory is world
readable and writable:
mrblue:/home/oneman# ls -lh /var/spool/spamassassin/
total 4.6M
-rw-rw-rw- 1 root root 12K 2006-09-26 20:07 auto-whitelist
-rw-rw-rw- 1 root root 5.1K 2006-09-26 20:07 bayes_journal
-rw-rw-rw- 1 root root 632K 2006-09-26 20:07 bayes_seen
-rw-rw-rw- 1 root root 5.2M 2006-09-26 20:07 bayes_toks
I'm probably missing the obvious, but can someone point out to me
what to change so filter can access /var/spool/spamassassin ?
TIA
Peter
Output of spamassassin debug =
mrblue:#su filter
[EMAIL PROTECTED]:$spamassassin -D testmsg
snip
debug: using /dev/null/.spamassassin for user state dir
debug: mkdir /dev/null/.spamassassin failed: mkdir /dev/null: File
exists at /usr/share/perl5/Mail/SpamAssassin.pm line 1453
File exists
snip
Cannot write to /dev/null/.spamassassin/user_prefs: Not a directory
Failed to create default user preference file /dev/null/.spamassassin/
user_prefs
debug: using /dev/null/.spamassassin/user_prefs for user prefs file
snip
debug: bayes: no dbs present, cannot tie DB R/O: /var/spool/
spamassassin/bayes_toks
debug: Score set 1 chosen.
debug: bayes: no dbs present, cannot tie DB R/O: /var/spool/
spamassassin/bayes_toks
snip
debug: open of AWL file failed: lock: 27966 cannot create tmp
lockfile /var/spool/spamassassin/auto-whitelist.lock.mrblue.27966
for /var/spool/spamassassin/auto-whitelist.lock: Permission denied
snip
debug: auto-learning failed: lock: 27966 cannot create tmp lockfile /
var/spool/spamassassin/bayes.lock.mrblue.27966 for /var/spool/
spamassassin/bayes.lock: Permission denied
snip
