Re: report_safe 0 doesn't work
On Mar 1, 2011, at 9:50 AM, Karsten Bräckelmann wrote: On Tue, 2011-03-01 at 09:28 -0800, macke...@animalhead.com wrote: On Mar 1, 2011, at 6:35 AM, Karsten Bräckelmann wrote: Since an upgrade. Sounds like the new SA installation actually uses a different site-config dir -- and probably prefix altogether. The spamassassin(1) man page will tell you, section Configuration Files. Note that in the same list of paths also is a version tagged one, just in case you're looking at the old man page. I grepped all the files/direcs noted in SPAMASSASSIN(1) and Mail::SpamAssassin::Conf(3), the former included /var/db/spamassassin/3.003001 in its default list and /usr/local/etc/mail/spamassassinin its site-specific list (the latter is where my local.cf with report_safe 0 is located) Running spamassassin with the -D debug switch also will tell you the correct path. animalhead:~ $ spamassassin -D Mar 1 09:12:23.566 [68051] dbg: logger: adding facilities: all Mar 1 09:12:23.566 [68051] dbg: logger: logging level is DBG Mar 1 09:12:23.566 [68051] dbg: generic: SpamAssassin version 3.3.1 Mar 1 09:12:23.566 [68051] dbg: generic: Perl 5.010001, PREFIX=/usr/ local, DEF_RULES_DIR=/usr/local/share/spamassassin, LOCAL_RULES_DIR=/ etc/mail/spamassassin, LOCAL_STATE_DIR=/var/lib/spamassassin ^ There's a severe difference to the man-pages you just quoted. How did you install SA? It appears you ended up with two different installations, though both being 3.3.1. Installing SA 3.3.1 via CPAN cleared up problems from a failed attempt by our hosting provider to update something on the server (they never said exactly what), which left SA inoperative. (It cleared up problems except for this one -- how SA tagged spam.) The original SA install years ago was using a script from our hosting provider. [...] Mar 1 09:12:23.605 [68051] dbg: dns: is Net::DNS::Resolver available? yes Mar 1 09:12:23.605 [68051] dbg: dns: Net::DNS version: 0.66 At this point, spamassassin waits for input on STDIN. Run the debugging with lint, which uses an internal mail. The command below will grep out the site-config directory used. spamassassin -D --lint 21 | grep site rules animalhead:~ $ spamassassin -D --lint 21 | grep site rules Mar 2 07:33:27.529 [75068] dbg: config: using /etc/mail/ spamassassin for site rules pre files Mar 2 07:33:27.566 [75068] dbg: config: using /etc/mail/ spamassassin for site rules dir animalhead:~ $ sudo find /etc -name local.cf /etc/mail/spamassassin/local.cf animalhead:~ $ sudo find /usr -name local.cf /usr/local/etc/mail/spamassassin/local.cf So I edited etc/mail/spamassassin/local.cf to include report_safe 0. Probably all will be well now. This problem may go back further than the 3.1.1 install. I have a vague memory of trying to tweak some scoring coefficients years ago, without SA noticing those changes. A plain 'spamassassin --lint' does not generate any warnings, right? Right. Thanks very much, cmac
report_safe 0 doesn't work
In my file /usr/local/etc/mail/spamassassin/local.cf there are 4 comment lines and 1 active line: ## SA-VINSTALL VERSION: 3.2.5 # Add your own customisations to this file. See 'man Mail::SpamAssassin::Conf' # for details of what can be tweaked. # report_safe 0 The active line ends with a return. I've grepped all the configuration files and directories noted in the man pages, and can see no non-comment line that changes report_safe. Since a recent upgrade to SA 3.3.1, SA attaches emails that it tags, rather than just adding headers as the report_safe line above intends. This complaint is similar to one sent to this forum on or about April 1 2010. That correspondent had to reinstall SA and the local.cf file in order to get his report_safe 0 to work. I'm lazy and hope that someone who reads this will know a simpler solution. Thanks, cmac www.animalhead.com
Re: report_safe 0 doesn't work
On Mar 1, 2011, at 6:35 AM, Karsten Bräckelmann wrote: On Tue, 2011-03-01 at 06:00 -0800, macke...@animalhead.com wrote: In my file /usr/local/etc/mail/spamassassin/local.cf there are 4 comment lines and 1 active line: report_safe 0 Since a recent upgrade to SA 3.3.1, SA attaches emails that it tags, rather than just adding headers as the report_safe line above intends. Since an upgrade. Sounds like the new SA installation actually uses a different site-config dir -- and probably prefix altogether. The spamassassin(1) man page will tell you, section Configuration Files. Note that in the same list of paths also is a version tagged one, just in case you're looking at the old man page. I grepped all the files/direcs noted in SPAMASSASSIN(1) and Mail::SpamAssassin::Conf(3), the former included /var/db/spamassassin/3.003001 in its default list and /usr/local/etc/mail/spamassassinin its site-specific list (the latter is where my local.cf with report_safe 0 is located) Running spamassassin with the -D debug switch also will tell you the correct path. animalhead:~ $ spamassassin -D Mar 1 09:12:23.566 [68051] dbg: logger: adding facilities: all Mar 1 09:12:23.566 [68051] dbg: logger: logging level is DBG Mar 1 09:12:23.566 [68051] dbg: generic: SpamAssassin version 3.3.1 Mar 1 09:12:23.566 [68051] dbg: generic: Perl 5.010001, PREFIX=/usr/ local, DEF_RULES_DIR=/usr/local/share/spamassassin, LOCAL_RULES_DIR=/ etc/mail/spamassassin, LOCAL_STATE_DIR=/var/lib/spamassassin Mar 1 09:12:23.566 [68051] dbg: config: timing enabled Mar 1 09:12:23.567 [68051] dbg: config: score set 0 chosen. Mar 1 09:12:23.569 [68051] dbg: util: running in taint mode? yes Mar 1 09:12:23.569 [68051] dbg: util: taint mode: deleting unsafe environment variables, resetting PATH Mar 1 09:12:23.569 [68051] dbg: util: PATH included '/sbin', keeping snip Mar 1 09:12:23.583 [68051] dbg: util: final PATH set to: /sbin:/bin:/ usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/usr/ local/apache2/bin:/home/sakomina/bin:/usr/local/bin/db47 Mar 1 09:12:23.605 [68051] dbg: dns: no ipv6 Mar 1 09:12:23.605 [68051] dbg: dns: is Net::DNS::Resolver available? yes Mar 1 09:12:23.605 [68051] dbg: dns: Net::DNS version: 0.66 Should it say when it reads a config file? Thanks, cmac
Re: sa-learn error message
Thank you to both responders. Did I read something that said that the digit after bayes db version indicated the version of Berkeley DB that's installed on the system? Like 0 means 1.x... Google shows various messages like bayes db version 2 is not able to be used, aborting! which would seem to indicate that 0 is not indicative of the problem I saw. Perhaps the reason that the bug report lists 0 is that Berkeley DB version 1.x does not include an integrated locking mechanism, but higher versions are reputed to have such a mechanism. Before I got your responses, I got my courage up and went on to run $ sa-learn --no-sync --ham ham (ham is the name of a directory in the current working directory) $ sa-learn --sync and everything went well. This sort of indicates that the DB isn't hopelessly corrupt. Please, where is this DB that I should back up? I wrote a GP Berkeley DB rebuilding program that reads all of the key/ value pairs in a DB, and writes all of those for which the key and value are defined and of non-zero length, to a new DB. I could try running that and see if the new DB is significantly smaller than the old, which for my DBs indicates that it's time to use the new DB. Theo, do you know if SA uses any entries with null keys or values, that are needed for proper operation? It would be easy to keep entries with null values; I wrote the program to discard them because my DBs don't use such entries. Thanks, Craig MacKenna On Jan 17, 2008, at 1:50 PM, Theo Van Dinter wrote: On Thu, Jan 17, 2008 at 03:28:06PM -0600, Steven Stern wrote: bayes db version 0 indicates your bayes file is corrupt. It should be version 3. Do you have a backup? SQL or .db? It doesn't necessarily mean there's corruption, in fact, since the learning continued and seemed to finish ok, it's unlikely to be corruption. See http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3563 for a possible libdb issue which causes it. -- Randomly Selected Tagline: And the No. 1 response that you'll need to memorize if you plan to bet your business on Windows 2000: 'You want fries with that?' - Nicholas Petreley
Training Q
Hi SA experts, We have procmail filters that see emails before SA. They can: 1. whitelist emails direct to our Inbox, 2. send emails to direct to the bit bucket (/dev/null) 3. send emails to the Junk folder for review, or 4. leave them for processing by SA. So SA never sees the emails in categories 1-3. SA can also send emails to /dev/null or send emails to the Junk folder for review. I've been saving up emails with which to train SA's Bayesian filters for some time now, in 3 categories: a. spam that was sent to the Junk folder by custom filters and SA, b. spam that got through, and c. ham for the same data range (last 6 months) So, all 3 categories include emails that SA has already seen and presumably included in its Bayesian filters, and emails that it has never seen. My question is, should I write a program to take out emails that SA has already seen before I send them through Bayesian processing, or is it smart enough not to process those again? Best Regards, Craig MacKenna
