Re: spamd log level
On Fri, May 23, 2014 at 09:04:29PM +0200, Karsten Bräckelmann wrote: > On Fri, 2014-05-23 at 11:30 +0200, Alex Andreotti wrote: > > is there a way to configure spamd (without patching it) to log only > > errors? > > AFAIK there is no such option. > > Though isn't that exactly what log levels are for? If you aren't > interested in the info noise, filter it out. See the journalctl > --priority option. My fault, I'm a newbie of systemd/journalctl, should spend more time knowing it. (Even if this experience made me think that every"thing" should have a similar setting, to log errors only) > > journalctl show that idle messages are emitted about every minute > > (circa). > > Ironically, the uninteresting noise you asked to get rid of shows, there > may be some issue with your setup. (Granted, or a deliberate config > decision.) > > The --max-conn-per-child default is 200. Your ratio of child status and > spawning new children in the pasted logs is about 2:1. Did you > deliberately set that option to 2? > > The prefork child status logs are not only informational, but may also > indicate warnings or even error conditions, e.g. in case you get a > consistent high number of non-idle children. Ah! I wasn't aware about --max-conn-per-child, didn't changed it directly but recently have changed --max-children to 7 (one for earch fetchmail instance) where the comment above the setting say "make sure to not use higher than 5" ... I'm using 3 now which I guess are still a way too much for my needs, will investigate for better settings soon. Thank you very much Karsten
Re: autolearn_force
> So, now I am really confused. I think I did everything right in > user_prefs: > > bayes_auto_learn 1 > bayes_auto_learn_threshold_nonspam -2.00 > bayes_auto_learn_threshold_spam 6.00 > bayes_auto_learn_on_error 0 > > [snip] > > tflags URIBL_DBL_SPAM autolearn_force > tflags URIBL_JP_SURBL autolearn_force > tflags URIBL_BLACK autolearn_force > tflags INVALID_DATE autolearn_force > > Nonetheless: > > X-Spam-Score: 6.9 > X-Spam-Tests: BAYES_99=3.5,BAYES_999=0.2,HTML_FONT_LOW_CONTRAST=0.001, > HTML_MESSAGE=0.001,MIME_HTML_ONLY=0.723,RDNS_NONE=0.793,SPF_PASS=-0.001, > T_REMOTE_IMAGE=0.01,URIBL_BLACK=1.7 > X-Spam-Autolearn: no autolearn_force=no And here's a case where it doesn't autolearn ham (same user_prefs as above): X-Spam-Status: No X-Spam-Level: X-Spam-Score: -2.7 X-Spam-Tests: BAYES_00=-1.9,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001,FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001,HTML_MESSAGE=0.001,RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001,SPF_PASS=-0.001 X-Spam-Autolearn: no autolearn_force=no The documentation certainly doesn't say anything like the 3/3 and force mechanism is in place for ham. So this _should_ autolearn. Right? Right?? -- Please *no* private copies of mailing list or newsgroup messages.
Re: autolearn_force
On Thu, 22 May 2014 15:54:42 +0100 RW wrote: Ian> But in fact this is a per-test setting, a subcategory of tflags. Ian> Do I have to specify it separately for every test? Why? RW> The point is to set it for a small number of rules that are RW> sufficiently strong as to guarantee there will be no mislearning in RW> combination with the autolearn as spam threshold. So, now I am really confused. I think I did everything right in user_prefs: bayes_auto_learn1 bayes_auto_learn_threshold_nonspam -2.00 bayes_auto_learn_threshold_spam 6.00 bayes_auto_learn_on_error 0 [snip] tflags URIBL_DBL_SPAM autolearn_force tflags URIBL_JP_SURBL autolearn_force tflags URIBL_BLACK autolearn_force tflags INVALID_DATE autolearn_force Nonetheless: X-Spam-Score: 6.9 X-Spam-Tests: BAYES_99=3.5,BAYES_999=0.2,HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001,MIME_HTML_ONLY=0.723,RDNS_NONE=0.793,SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01,URIBL_BLACK=1.7 X-Spam-Autolearn: no autolearn_force=no One suspect thing I see in the log: May 24 20:29:58 host spamd[13561]: spamd: result: Y 6 - BAYES_99,BAYES_999,HTML_FONT_LOW_CONTRAST,HTM L_MESSAGE,MIME_HTML_ONLY,RDNS_NONE,SPF_PASS,T_REMOTE_IMAGE,URIBL_BLACK scantime=1.9,size=6208,user=itz, uid=1000,required_score=4.3,rhost=127.0.0.1,raddr=127.0.0.1,rport=60231,mid=<23931386609892239320827813 806...@86adv5n4.disabilism.eu>,bayes=1.00,autolearn=no autolearn_force=no Note the 6 - is it possible that SA truncates the score to an integer for this purpose, and then treats it as a strict lower bound - that is, if I set bayes_auto_learn_threshold_spam = 6.00, the lowest score to actually trigger autolearn would be 7? That is the only rational explanation I have, tortured as it is. It sure looks like SA is going out of its way to force me to do manual training :-( -- Please *no* private copies of mailing list or newsgroup messages.
Re: Unexpected missing rule name, failure of spams/spamd to output X-Spam headers
On Sat, 2014-05-24 at 05:04 +0200, Karsten Bräckelmann wrote: > On Sat, 2014-05-24 at 03:28 +0100, Martin Gregorie wrote: > > On Sat, 2014-05-24 at 02:36 +0200, Karsten Bräckelmann wrote: > > > I've looked down the list a couple of times and didn't see anything I > > thought would affect it due to a possibly bad assumption that this sort > > of error would be insulated from the underlying binary code by at least > > one layer of Perl library code. > > Plain spamassassin script works, spamc/d combination does not. Nope, > this is not necessarily related to any Perl code. > OK. > Looking through the full list of upgraded packages, the two SELinux > related ones stick out. In particular, since the client / server > environment is affected, but not the standalone variant of calling the > majority of shared SA Perl code. > SELinux shouldn't be an issue as its running in Permissive, Targeted mode and it hasn't flagged up any warnings. > > > > By "started it", do you mean starting the daemon simply for that test, > > > or did you ping spamd after launching your dev test rig? > > > > Yes, I meant starting it. As I said, this problem surfaced on the box I > > use for SA rules development, actually a Lenovo laptop. Consequently SA > > only runs on it during a rules test: all my test scripts are written to > > start spamd, run the test and stop it. > > > > > Clean room vs. production conditions... > > > > Yes, exactly. > > Nah. I was talking about the difference in your test (manually starting > spamd) and the environment observed to fail (your dev test rig script). > Should be the same as live operation: my scripts use systemctl to start spamd as a systemd-managed service, so spamd is running as root. ps reports the commend line as /bin/spamd -d -c -m5 -H -r /var/run/spamd.pid > Unrelated to the problem at hand, but Fedora 18 and Fedora 20 does not > account for "as near to identical" as reasonably possible. > Sure, but when I set up the test environment I made sure that spamd was always started the same way as it would be in a live environment: the only difference is that its only running when I have testing to do. In any case this is a bit of a blind alley since the testing system was working just as I expected it to yesterday morning and then, after the yum upgrade the unmodified test system no longer worked that way. LATER: This morning I reran some failing examples after rebooting the test machine. No change, so I tried a few stripped-down runs, i.e. I started spamd via a test script that uses systemctl to start or stop it and then used "spamc
