user_prefs
I have searched for several hours and can't seem to find the answer to this. I've found close answers, but not complete. I have SA set up as individual users. When a new user is created SA creates a new user_prefs file for them. This file contains two prefs. required_score 7 and rewrite_header subject SPAM. I am trying to find out if I can change some prefs so that the new user_prefs file will contain my prefs when it is newly created. I have changed prefs in user_prefs.template and that didn't make any difference. I assume this template is supposed to be used by SA to create the new user_prefs, but it doesn't seem so. Where can I add my own prefs so the newly created defualt user_prefs file is loaded with what I want? Thanks. - /etc/mail/spamassassin/user_prefs.template: Default user preferences, for system admins to create, modify, and set defaults for users' preferences files. Takes precedence over the above prefs file, if it exists. Do not put system-wide settings in here; put them in a file in the "/etc/mail/spamassassin" directory ending in ".cf". This file is just a template, which will be copied to a user's home directory for them to change. - $USER_HOME/.spamassassin/user_prefs: User preferences file. If it does not exist, one of the default prefs file from above will be copied here for the user to edit later, if they wish. Unless you're using spamd, there is no difference in interpretation between the rules file and the preferences file, so users can add new rules for their own use in the "~/.spamassassin/user_prefs" file, if they like. (spamd disables this for security and increased speed.) Access over 1 million songs - Yahoo! Music Unlimited.
user_prefs
I am re-submitting this question for help: I have searched for several hours and can't seem to find the answer to this. I've found close answers, but not complete. I have SA set up as individual users. When a new user is created SA creates a new user_prefs file for them. This file contains two prefs. required_score 7 and rewrite_header subject SPAM. I am trying to find out if I can change some prefs so that the new user_prefs file will contain my prefs when it is newly created. I have changed prefs in user_prefs.template and that didn't make any difference. I assume this template is supposed to be used by SA to create the new user_prefs, but it doesn't seem so. Where can I add my own prefs so the newly created defualt user_prefs file is loaded with what I want? Thanks. - /etc/mail/spamassassin/user_prefs.template: Default user preferences, for system admins to create, modify, and set defaults for users' preferences files. Takes precedence over the above prefs file, if it exists. Do not put system-wide settings in here; put them in a file in the "/etc/mail/spamassassin" directory ending in ".cf". This file is just a template, which will be copied to a user's home directory for them to change. - $USER_HOME/.spamassassin/user_prefs: User preferences file. If it does not exist, one of the default prefs file from above will be copied here for the user to edit later, if they wish. Unless you're using spamd, there is no difference in interpretation between the rules file and the preferences file, so users can add new rules for their own use in the "~/.spamassassin/user_prefs" file, if they like. (spamd disables this for security and increased speed.) Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates.
user_prefs
Thanks Karl and Nick, Yes, the new account user_prefs is being created (I'm creating it from Plesk BTW) however the new user_prefs seems to be created with default values from I don't know where and not those values in either of the two .template files. That's my problem in a nut shell. Maybe this isn't a SpamAssassin process and that all new user_prefs files are created with these default values and then it's the admins or users job to edit the user_prefs or cp the .template file into /.spamassassin/ Thats what I am trying to figure out. It appears to be more manual than automagic. I now think spamassassin creates new user_prefs and does not use the .template files to do so. Then the admin copies the .template file to the user_prefs or either just edits the new user_prefs. Is this a correct assumption? I'm unique in that I am the sole "creator" for this server and basically for the most part all users are "me". I have a couple of other users, but they do not have access beyond Plesk and FTP. If it's not GUI, they don't have a clue. Wes Want to start your own business? Learn how on Yahoo! Small Business.
user_prefs
I installed postfix-2.2.8 amavisd-new-2.4.1 clamav-0.88.6 and spamassassin-3.1.3 I would like to use local Bayesian database for each user. Example For andrea user I created the directory /home/andrea/.spamassassin and with sa-learn (ham/spam) I created in that directory bayes_* with user ham/spam e-mail. Then I created in that directory user_prefs file and I put it bayes_path /home/andrea/.spamassassin/bayes bayes_file_mode 0770 I would test what I did. How can I do?Spamassassin should to use andrea bayesian database for andrea e-mail and not sharing bayesian database(these are in /var/amavis/.spamassassin) Thank Andrea
user_prefs
I would like to suppress user_prefs and stick with a single site-wide user_prefs. I don't think I actually need to do much for this. But I get a lot of warnings. I also want to be able to switch users for the bayes list (SQL) but continue using the same prefs for all users. If I call signal_user_changed() won't that also start a process to find/create user specific preferences?
user_prefs
cannot write to /var/www/.spamassassin/user_prefs: No such file or directory failed to create default user preference file /var/www/.spamassassin/user_prefs I never ever ever ever want to try to create a user_prefs file. How do I make sure I never do this?
Re: user_prefs
twofers wrote: I am re-submitting this question for help: I have searched for several hours and can't seem to find the answer to this. I've found close answers, but not complete. I have SA set up as individual users. When a new user is created SA creates a new user_prefs file for them. This file contains two prefs. required_score 7 and rewrite_header subject SPAM. I am trying to find out if I can change some prefs so that the new user_prefs file will contain my prefs when it is newly created I have changed prefs in user_prefs.template and that didn't make any difference. I assume this template is supposed to be used by SA to create the new user_prefs, but it doesn't seem so. Where can I add my own prefs so the newly created defualt user_prefs file is loaded with what I want? I dont know of a spamassassin way but have you thought of putting a line in /etc/skel/.bashrc that copies your user_prefs into their ~/.spamassassin dir when the users is created ? This would also update the user_prefs when they log in if you have updated yours. Generally users wont have access to other users home dirs so you could copy/link your user_prefs to somewhere like /var/tmp/spam/user_prefs and have an entry such as cp -f /var/tmp/spam/user_prefs ~/.spamassassin/ in /etc/skel/.bashrc . Just an idea. Nick .
Re: user_prefs
On Sun, 2006-11-12 at 02:06 -0800, twofers wrote: > I am trying to find out if I can change some prefs so that the new > user_prefs file will contain my prefs when it is newly created. > > I have changed prefs in user_prefs.template and that didn't make any > difference. I assume this template is supposed to be used by SA to > create the new user_prefs, but it doesn't seem so. The user_prefs file should be created in ~/.spamassassin/user_prefs. Is it? And if it is, does it contain your templated stuff? Aside from putting the user-specific config in the right place, spamassassin has to been told to use it. In your site-local spamassassin config file (probably /etc/mail/spamassassin/local.cf) or in a separate .cf file in the same directory as that file, add this line: allow_user_rules 1 This is however a bad idea unless you have very trustworthy users. Also note this (from the spamassassin man page): Note that it is not currently possible to use "allow_user_rules" to modify an existing system rule from a "user_prefs" file with "spamd". You saw this mentioned in the user_prefs stuff you quoted: [...]users can add new rules for their own use in the "~/.spamassassin/user_prefs" file, if they like. (spamd disables this for security and increased speed.) Regards, K. -- ~~~ Karl Auer ([EMAIL PROTECTED]) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob)
Re: user_prefs
On Tue, Dec 05, 2006 at 07:51:32PM +0100, Andrea Bencini wrote: > I would test what I did. How can I do?Spamassassin should to use andrea > bayesian database for andrea e-mail and not sharing bayesian database(these > are in /var/amavis/.spamassassin) If running SA in site-wide mode (such as using Amavis), you can't have per-user configs or databases. If you want per-user stuff, you have to run SA at delivery time, which typically happens through something like procmail. -- Randomly Selected Tagline: "Say "No" to cannabalism: Friends don't let friends eat friends." - Jeff Stilson pgpyGwfef0ZIL.pgp Description: PGP signature
MySQL user_prefs
Hi. I'm trying to setup Spamassassin to use user_prefs from MySQL for a Qmail/Vpopmail installation. I addedd this in /etc/spamassassin/local.cf: user_scores_dsn DBI:mysql:spamassassin:localhost user_scores_sql_usernamespamassassin user_scores_sql_passwordspampass And in /etc/default/spamassassin: OPTIONS="--max-children 5 --helper-home-dir -q -x -v" Now spamd is running as "/usr/sbin/spamd --max-children 5 --helper-home-dir -q -x -v -d --pidfile=/var/run/spamd.pid". But if I try "cat sample-spam.txt | spamc", i don't see the "retrieving prefs for from SQL server" message, so I think MySQL user_prefs are not used. Is it possible to store vpopmail's user_prefs in MySQL? I wish to have "local.cf" configurations used by default, and MySQL for the preferences of the user which are in the database. Anyone could help me, please? Thank you very much and goodbye! Luca. _ Ogni ricerca da questo sito, una donazione per i bambini rifugiati http://click4thecause.live.com/Search/Charity/Default.aspx?locale=it-it
Re: user_prefs
On Thu, 28 Jun 2007, Tom Allison wrote: cannot write to /var/www/.spamassassin/user_prefs: No such file or directory failed to create default user preference file /var/www/.spamassassin/user_prefs I never ever ever ever want to try to create a user_prefs file. How do I make sure I never do this? Using the '-x' or '--nocreate-prefs' switch will tell spamassassin to not create the user_prefs file. This can be found by using: spamassassin -h Also, if you are using the '-c' switch when starting spamd, remove it. '-c' tells spamd to create user_prefs files.
Re: user_prefs
OK, thanks. I'm not using spamassassin or spamd. I'm using Mail::SpamAssassin in a perl script. What does '-x' do for Mail::SpamAssassin? On Jun 28, 2007, at 9:23 PM, Duane Hill wrote: On Thu, 28 Jun 2007, Tom Allison wrote: cannot write to /var/www/.spamassassin/user_prefs: No such file or directory failed to create default user preference file /var/ www/.spamassassin/user_prefs I never ever ever ever want to try to create a user_prefs file. How do I make sure I never do this? Using the '-x' or '--nocreate-prefs' switch will tell spamassassin to not create the user_prefs file. This can be found by using: spamassassin -h Also, if you are using the '-c' switch when starting spamd, remove it. '-c' tells spamd to create user_prefs files.
Re: user_prefs
On Fri, 29 Jun 2007 at 19:43 -0400, [EMAIL PROTECTED] confabulated: OK, thanks. I'm not using spamassassin or spamd. I'm using Mail::SpamAssassin in a perl script. What does '-x' do for Mail::SpamAssassin? Nothing being you are calling SA directly from perl. You should set dont_copy_prefs to 1 in your call to: $t = Mail::SpamAssassin->new(); Taken from: http://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin.html ... dont_copy_prefs If set to 1, the user preferences file will not be created if it doesn't already exist. (default: 0)
user_prefs not used
Hi all,
I am using spamd and calling spamc from .procmail using
| /usr/bin/spamc -u chris
Only the rules in /ec/mail/spamassassin/local.cf are being processed.
My $HOME/.spamassassin/user_prefs file is not being used!
/etc/mail/spamassassin/local.cf has allow_user_rules 1 in it but I can
not get it working!
Any help would be apprecriated.
Thanks,
Chris
--
/* _\|/_
(o o)
+oOO-{_}-OOo---+
|Chris Willard <[EMAIL PROTECTED]> |
| |
|I'm clinging to sanity by a thread. Hand me the scissors, willya?|
| |
+-*/
customized default user_prefs
the current default user_prefs file contains ### # How many points before a mail is considered spam. # required_score5 ... snip .. # score SUBJ_ILLEGAL_CHARS 0 is there any way that this file be created with 0 contents and without those commented lines?
user_prefs not recognized?
Hi, I want my users (it's a small at-home setup of fetchmail, postfix, SA and courier-imap) to be able to whitelist certain users. This is what my various config files look like: $ tail -n1 /etc/spamassassin/local.cf allow_user_rules1 $ cat ~/.spamassassin/user_prefs headerL_TO_ME ToCc =~ /ron\.l\.johns...@cox\.net/ describe L_TO_ME Email addressed to me score L_TO_ME 0.010 whitelist_from nytdir...@nytimes.com After adding allow_user_rules to local.cf, I bounced SA by doing: # /etc/init.d/spamassassin restart The L_TO_ME stuff I got from the wiki page: http://wiki.apache.org/spamassassin/UserPrefRuleTest If relevant, this is Debian Sid, running v3.3.0-1 Thanks -- Ron Johnson, Jr. Jefferson LA USA "If God had wanted man to play soccer, he wouldn't have given us arms." Mike Ditka
user_prefs questions/problem
I have SA set up and working (mostly) on my mail machine, however I've put the following into my user_prefs: whitelist_from *...@zyngamail.com and whitelist_from_rcvd *...@zyngamail.com zyngamail.com and whitelist_allows_relays *...@zyngamail.com when email comes in from them it is flagged as spam. Here is an example spam report from the headers: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on helium.inexs.com X-Spam-Flag: YES X-Spam-Level: * X-Spam-Status: Yes, score=5.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FSL_HELO_NON_FQDN_1,HTML_MESSAGE,MIME_HEADER_CTYPE_ONLY, MIME_HTML_ONLY,RDNS_NONE,SPF_FAIL,TO_NO_BRKTS_NORDNS_HTML +autolearn=disabled version=3.3.1 X-Spam-Report: * 0.0 FSL_HELO_NON_FQDN_1 FSL_HELO_NON_FQDN_1 * 0.9 SPF_FAIL SPF: sender does not match SPF record (fail) * [SPF failed: Please see +http://www.openspf.org/Why?s=mfrom;id=notifications%2Bvvvo8mu4wy%40zyngamail.co +m;ip=10.49.16.82;r=helium.inexs.com] * 0.0 HTML_MESSAGE BODY: HTML included in message * 1.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from +author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature * 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.0 MIME_HEADER_CTYPE_ONLY 'Content-Type' found without required MIME * headers * 0.0 TO_NO_BRKTS_NORDNS_HTML To: misformatted and no rDNS and HTML +only I have contacted them about their SPF failure, and am awaiting a response, but I don't see any reference to my whitelisting, is it not working as I anticipated? If it is there, and I just don't see it, let me know where, and how to increase it's score to ensure whitelisted emails are not flagged as spam. thanks, -chuck --
user_prefs not working
Hi I have a user_prefs file in the home-dir of one user. In that file are these two lines: use_dma_spam_mailbox = true spam_mailbox_name = MYSPAM In the system-prefs are these two lines: # use_dma_spam_mailbox = false # spam_mailbox_name = SPAM The Spammail don't get to the MYSPAM mailbox. When I change the system-prefs so the two lines look like this: use_dma_spam_mailbox = true # spam_mailbox_name = SPAM then Spammail goes into mailbox SPAM instead of MYSPAM What's wrong with my settings? Thanks for any help Marcel +--- mailto:[EMAIL PROTECTED] otherto:[EMAIL PROTECTED]
user_prefs migration script
Hey all, I was migrating over to SQL, and I've written a script that allows users to migrate their prefs into (and out of) a SQL database, including some command line switches for root to be able to migrate all users in at once. My code's not the cleanest in the world, but I'm trying. I wrote it as a stub so my existing tools to edit prefs files would still work. I don't know if I've duplicated any effort here, but would anyone be interested in such a script? Should I submit it as a bug report or just provide a link? Do I need to sign away anything if I wanted to "contribute" it to the actual SA base? Please let me know. -Dan Mahoney (www.gushi.org/updateprefs.pl) -- "A mother can be an inspiration to her little son, change his thoughts, his mind, his life, just with her gentle hum." -No Doubt, "Different People", from "Tragic Kingdom" Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---
user_prefs score value
Using spamassassin 3.0.0 on my ISP whatever I set the score to in my rule set, when the event is triggered the score is always 1. I am using the following as a test add_header all tf Score Values (_TESTSSCORES(,)_) rawbody TF_RAWBODY_WARNING_1 /message\.scr/i score TF_RAWBODY_WARNING_1 20 As spamassassin is running on my ISP I can not give very many details about the setup, they have been unable to answer this question and I have been unable to find the answer either!
local.cf, user_prefs etc
Hello folks! I use 3.4.1 freebsd version with compiled rules. Please, give me advice how I could use local config file to override downloaded default values? All my attemps were unsuccessful. I placed local.cf and user_prefs files in /root/spamassassin /etc/mail/spamassassin /usr/local/etc/mail/spamassassin /usr/local/share/spamassassin - no way to replace default values like blacklist_from or required_score. I need help :) Rgds, db
user_prefs not working
Running SA on a Cpanel VPS that had an outage yesterday, when it came back up SA is not using any of the user_prefs files in the individual accounts. Support doesn't know what to do. The user_prefs are still in the proper places but just not being read, or not influencing the scores, no whitelists, etc. Can anyone offer troubleshooting advice that I can use directly or pass along to the support folks? Thanks.
file user_prefs update
Hi, I have use SA 3.1.9 (with maia-1.0.2 and amavisd-new-2.2.1), the bayes files are updated correctly but user_prefs is updated in '/root/.spamassassin' and not in '/var/amavisd/.spamassassin'. In particular in: [EMAIL PROTECTED] scripts]# ls -l /var/amavisd/.spamassassin/ totale 52 -rwxr-x--- 1 amavis amavis 12288 4 lug 05:06 auto-whitelist -rwxr-x--- 1 amavis amavis 12288 3 lug 15:47 bayes_seen -rwxr-x--- 1 amavis amavis 24576 3 lug 15:47 bayes_toks -rwxr-x--- 1 amavis amavis 1487 29 giu 16:42 user_prefs instead in: [EMAIL PROTECTED] ~]# ls -l /root/.spamassassin/ totale 4 -rw-r--r-- 1 root root 1487 2 lug 19:30 user_prefs My local.cf is: [EMAIL PROTECTED] ~]# cat /etc/mail/spamassassin/local.cf rewrite_header Subject [SPAM] bayes_path /var/amavisd/.spamassassin/bayes auto_whitelist_path /var/amavisd/.spamassassin/auto-whitelist Thanks. -- Salvatore.
spamd, postfix & user_prefs
Hi there,
my spamd seems to ignore the ~/.spamassassin/user_prefs file.
I've searched the archives about this issue, the closest one[0] I came
across was:
> [...] users can add new rules for their own use in the
> "~/.spamassassin/user_prefs" file, if they like.
> (spamd disables this for security and increased speed.)
I'm using SA 3.3.1 (from Debian/stable) and enabled 'allow_user_rules'
in local.cf. I intend to use only required_score, whitelist_from
and score - as I understand the comment above, these are not "rules" and
a per-user user_prefs should be evaluated even w/o 'allow_user_rules'.
When attaching strace(1) to the spamd processes it shows that only
/var/mail/.spamassassin/* is being read, but nothing in /home/*
is ever read. Even if it's a permission issue, I'd expect at least an
-EACCES.
The setup is as follows:
* fetchmail fetches mail from a remote server,
* delivers to postfix (localhost:25)
* Postfix delivers to clamsmtpd (for virus-checking) which passes
the message back to postfix, which in turn
* passes it to a spamassassin service
* maildrop delivers the mail to the user's Maildir.
--- master.cf
spamassassin unix - n n - - pipe
user=mail argv=/usr/bin/spamc -e /usr/sbin/sendmail -oi -f \
${sender} ${recipient}
[...]
maildrop unix - n n - - pipe
flags=DRhu argv=/usr/bin/maildrop -d ${recipient}
-
When email is being fetched I can see that "spamc -e ..." is being
spawned and spamd:783 is being connected to.
When running "spamassassin -D < mail.eml" manually as a user, my
user_prefs is of course read and evaulated correctly.
So, I really like to know why it is ignored when SA is called from
Postfix. Any ideas?
Thanks,
Christian.
[0] http://article.gmane.org/gmane.mail.spam.spamassassin.general/90462
--
BOFH excuse #356:
the daemons! the daemons! the terrible daemons!
Scoring in user_prefs
I would like to add a score in user_prefs based on the To header (I have an email that collects several email addresses and I want to add some spamishness indicators). Does the user_prefs understand the same syntax as the local.cf file? And what would be the best way to say: If the to field is u...@example.com add 1.0 top the spam score header __TO_EXAMPLE To =~ /user\@example.com/ score __TO_EXAMPLE 1.0 ? -- It was intended that when Newspeak had been adopted once and for all and Oldspeak forgotten, a heretical thought...should be literally unthinkable, at least so far as thought is dependent on words.
loadplugin TextCat from user_prefs
b> http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5675 >> > Don't put loadplugin statements into your .cf files >> .cf files? I put it in user_prefs! -- my best guess as to how to >> use this jazz. b> *DEFINITELY* not in your user_prefs. b> The Mail::SpamAssassin::Conf document is quite clear that b> loadplugin is an administrator setting. No administrator settings b> should be in your user_prefs, as they will be ignored by spamd for b> security reasons, although a normal call to "spamassassin" will run b> them. Yes, I never use spamd(1) and always use spamassassin(1). OK, I see See "Mail::SpamAssassin::Plugin" for more details on writing plugins. But nothing about more details on how to _run_ them. Anyway, here's what I have in user_prefs: loadplugin Mail::SpamAssassin::Plugin::VBounce score BOUNCE_MESSAGE 5 loadplugin Mail::SpamAssassin::Plugin::AntiVirus body MICROSOFT_EXECUTABLE eval:check_microsoft_executable() score MICROSOFT_EXECUTABLE 5 body MIME_SUSPECT_NAME eval:check_suspect_name() score MIME_SUSPECT_NAME 5 loadplugin Mail::SpamAssassin::Plugin::MIMEHeader mimeheader J_YUCK_ATTACHMENT Content-type =~ /\.(exe|scr|pif|zip)"$/i score J_YUCK_ATTACHMENT 5 mimeheader J_MSDOWNLOAD Content-type =~ /application\/x-msdownload;/ score J_MSDOWNLOAD 11 loadplugin Mail::SpamAssassin::Plugin::TextCat #I hate ru: ok_languages af am ar be bg ca cs da de el en es fa fi fr he hi hr hu hy id it ja ka ko mr ms ne nl no pl pt qu ro sk sq sr sv sw ta th tl tr uk vi zh add_header all languages _LANGUAGES_ #score UNWANTED_LANGUAGE_BODY 11 I was doing great, having a good time until --lint complained about UNWANTED_LANGUAGE_BODY, so I had to comment it out. Anyway, big mystery: how does one enjoy UNWANTED_LANGUAGE_BODY? I wish to only edit user_prefs, not gumming up anything else.
custom user_prefs file spamc
Hello, I'm setting up a gateway spamfilter mailserver. And I like to be able to give with spamc the path to the user_prefs file for the right domain. So the user does not exists, so I can not use the -U option. I have read this patch http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4405 and I was wondering if this is the only solution? Or will it become possible with a future version? I'm now using: spamd + spamc version 3.2.3 on a Fedora 8 system. Kind regards Maarten
custom user_prefs file spamc
Hello, I'm setting up a gateway spamfilter mailserver. And I like to be able to give with spamc the path to the user_prefs file for the right domain. So the user does not exists, so I can not use the -U option. I have read this patch http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4405 and I was wondering if this is the only solution? Or will it become possible with a future version? I'm now using: spamd + spamc version 3.2.3 on a Fedora 8 system. Kind regards Maarten
user_prefs: mind the linebreak
RP> Mind the linebreak :-) That reminds me of this MINOR ITEM, Currently, each rule or configuration setting must fit on one-line; multi-line settings are not supported yet.
user_prefs / shared bayes database
Well I took this idea and also tried to create a single bayes database but it doesn't seem to be working. In local.cf I added bayes_path /var/spool/bayes_db/ and bayes_file_mode 0770 and allow_user_rules 1 I also created mkdir /var/spool/bayes_db and chmod 0770 /var/spool/bayes_db Then I copied a bayes_toks and bayes_seen from a users /.spamassassin directory into /bayes_db/ That didn't seem to work, so I took one users /.spamassassin/user_prefs file and added the bayes_path and bayes_file_mode to it but that still didn't seem to make it work. Can someone tell me what I might be doing wrong? or am I just totally off base? Thanks.Karl Auer <[EMAIL PROTECTED]> wrote: On Sun, 2006-11-12 at 02:06 -0800, twofers wrote:> I am trying to find out if I can change some prefs so that the new> user_prefs file will contain my prefs when it is newly created.> > I have changed prefs in user_prefs.template and that didn't make any> difference. I assume this template is supposed to be used by SA to> create the new user_prefs, but it doesn't seem so.The user_prefs file should be created in ~/.spamassassin/user_prefs. Isit? And if it is, does it contain your templated stuff?Aside from putting the user-specific config in the right place,spamassassin has to been told to use it. In your site-local spamassassinconfig file (probably /etc/mail/spamassassin/local.cf) or in aseparate .cf file in the same directory as that file, add this line:allow_user_rules 1This is however a bad idea unless you have very trustworthy users. Alsonote this (from the spamassassin man page):Note that it is not currently possible to use"allow_user_rules" to modify an existing system rulefrom a "user_prefs" file with "spamd".You saw this mentioned in the user_prefs stuff you quoted:[...]users can add new rules for their own use in the"~/.spamassassin/user_prefs" file, if they like.(spamd disables this for security and increased speed.)Regards, K.-- ~~~Karl Auer ([EMAIL PROTECTED]) +61-2-64957160 (h)http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) Everyone is raving about the all-new Yahoo! Mail beta.
Re: user_prefs not used
Are you saying that you have separate rules in user_prefs and those rules are
not being processed? or are you talking about just configuration lines in
user_prefs like use_bayes 1?
Wes
Chris Willard <[EMAIL PROTECTED]> wrote:
Hi all,
I am using spamd and calling spamc from .procmail using
| /usr/bin/spamc -u chris
Only the rules in /ec/mail/spamassassin/local.cf are being processed.
My $HOME/.spamassassin/user_prefs file is not being used!
/etc/mail/spamassassin/local.cf has allow_user_rules 1 in it but I can
not get it working!
Any help would be apprecriated.
Thanks,
Chris
--
/* _\|/_
(o o)
+oOO-{_}-OOo---+
|Chris Willard |
| |
|I'm clinging to sanity by a thread. Hand me the scissors, willya?|
| |
+-*/
-
Sponsored Link
$200,000 mortgage for $660/mo - 30/15 yr fixed, reduce debt, home equity -
Click now for info
Re: user_prefs not used
Did you restart spamd after changing any options? Loren
Re: user_prefs not used
Hi Loren!
On Tue, 21 Nov 2006, Loren Wilton wrote:
> Did you restart spamd after changing any options?
Yes. It made no difference.
Regards,
Chris
--
/* _\|/_
(o o)
+oOO-{_}-OOo+
|Chris Willard <[EMAIL PROTECTED]>|
| |
|The four food groups: Fast, Frozen, Instant and Chocolate.|
| |
+--*/
Re: user_prefs not used
Hi Wes!
On Tue, 21 Nov 2006, twofers wrote:
> Are you saying that you have separate rules in user_prefs and those rules are
> not being processed? or are you talking about just configuration lines in
> user_prefs like use_bayes 1?
Yes - it does not process the seperate rules that are in user_prefs.
Regards,
Chris
--
/* _\|/_
(o o)
+oOO-{_}-OOo-+
|Chris Willard <[EMAIL PROTECTED]> |
||
|What was the best thing BEFORE sliced bread?|
||
+---*/
Re: user_prefs not used
Have you run spamassassin -D --lint? to check for syntax, etc. errors?
Wes
Chris Willard <[EMAIL PROTECTED]> wrote:
Hi Wes!
On Tue, 21 Nov 2006, twofers wrote:
> Are you saying that you have separate rules in user_prefs and those rules are
> not being processed? or are you talking about just configuration lines in
> user_prefs like use_bayes 1?
Yes - it does not process the seperate rules that are in user_prefs.
Regards,
Chris
--
/* _\|/_
(o o)
+oOO-{_}-OOo-+
|Chris Willard |
| |
|What was the best thing BEFORE sliced bread?|
| |
+---*/
-
Sponsored Link
Rates near 39yr lows. $510,000 Loan for $1698/mo - Calculate new house payment
Re: user_prefs not used
Hi Wes!
On Wed, 22 Nov 2006, twofers wrote:
> Have you run spamassassin -D --lint? to check for syntax, etc. errors?
I did not run it with the debug option. When I did this a found a few
problems including one with my firewall!
Thank's for your help. I should be able to work out the rest.
Regards,
Chris
>
--
/* _\|/_
(o o)
+oOO-{_}-OOo+
|Chris Willard <[EMAIL PROTECTED]>|
| |
|.666 - good beastball batting average. |
| |
+--*/
Re: user_prefs not recognized?
On Thu, 2010-03-04 at 14:36 -0600, Ron Johnson wrote:
> I want my users (it's a small at-home setup of fetchmail, postfix,
> SA and courier-imap) to be able to whitelist certain users.
You do *not* need allow_user_rules, to enable per-user whitelist_* or
blacklist_* settings.
See the docs [1], and pay special attention to the first sentence in the
User Preferences section. Also note that Whitelist and Blacklist Options
is a sub-section of this. :)
On a related note, the plain whitelist_from without a rcvd or auth
constraint is dangerous to use. If possible, always use the constraint
ones, and the plain one strictly as a fall-back if there is no other
possibility -- and you really need the whitelist. In almost all cases,
you don't, and the real problem (if any) goes by unnoticed.
> This is what my various config files look like:
>
> $ tail -n1 /etc/spamassassin/local.cf
> allow_user_rules1
>
> $ cat ~/.spamassassin/user_prefs
> headerL_TO_ME ToCc =~ /ron\.l\.johns...@cox\.net/
> describe L_TO_ME Email addressed to me
> score L_TO_ME 0.010
For this, you need allow_user_rules 1.
> whitelist_from nytdir...@nytimes.com
For this, you don't.
However, you did *not* show any evidence, headers, or whatever, that the
L_TO_ME user rule does not work...
How is SA called? Are you using per-user configuration?
[1] http://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_Conf.html
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: user_prefs not recognized?
On 2010-03-04 15:13, Karsten Bräckelmann wrote:
On Thu, 2010-03-04 at 14:36 -0600, Ron Johnson wrote:
I want my users (it's a small at-home setup of fetchmail, postfix,
SA and courier-imap) to be able to whitelist certain users.
You do *not* need allow_user_rules, to enable per-user whitelist_* or
blacklist_* settings.
See the docs [1], and pay special attention to the first sentence in the
User Preferences section. Also note that Whitelist and Blacklist Options
is a sub-section of this. :)
Already read this:
full/3.3.x/doc/Mail_SpamAssassin_Conf.html#user_preferences
On a related note, the plain whitelist_from without a rcvd or auth
constraint is dangerous to use. If possible, always use the constraint
ones, and the plain one strictly as a fall-back if there is no other
possibility -- and you really need the whitelist. In almost all cases,
you don't, and the real problem (if any) goes by unnoticed.
Right. I wanted to get the "simple stuff" working first; then the
more complicated configurations.
This is what my various config files look like:
$ tail -n1 /etc/spamassassin/local.cf
allow_user_rules1
$ cat ~/.spamassassin/user_prefs
headerL_TO_ME ToCc =~ /ron\.l\.johns...@cox\.net/
describe L_TO_ME Email addressed to me
score L_TO_ME 0.010
For this, you need allow_user_rules 1.
whitelist_from nytdir...@nytimes.com
For this, you don't.
OK.
However, you did *not* show any evidence, headers, or whatever, that the
L_TO_ME user rule does not work...
In Thunderbird View->"Message Source", I searched for L_TO_ME.
Am I fundamentally *wrong* about something here?
How is SA called?
(Lines manually "continued" for easy reading.)
# grep spam /etc/postfix/master.cf
smtp inet n - n - - \
smtpd -o content_filter=spamfilter:
spamfilter unix - n n - - pipe flags=Rq user=spamfilter \
argv=/usr/local/bin/spamfilter.sh \
-f ${sender} -- ${recipient}
Are you using per-user configuration?
I think so. But that "user=spamfilter" makes me now think
otherwise. I set this up years ago, and only now care about
whitelisting.
[1] http://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_Conf.html
--
Ron Johnson, Jr.
Jefferson LA USA
"If God had wanted man to play soccer, he wouldn't have given
us arms." Mike Ditka
Re: user_prefs not recognized?
On Thu, 2010-03-04 at 15:41 -0600, Ron Johnson wrote:
> On 2010-03-04 15:13, Karsten Bräckelmann wrote:
> > On a related note, the plain whitelist_from without a rcvd or auth
> > constraint is dangerous to use. If possible, always use the constraint
> > ones, and the plain one strictly as a fall-back if there is no other
> > possibility -- and you really need the whitelist. In almost all cases,
> > you don't, and the real problem (if any) goes by unnoticed.
>
> Right. I wanted to get the "simple stuff" working first; then the
> more complicated configurations.
> > How is SA called?
>
> (Lines manually "continued" for easy reading.)
>
> # grep spam /etc/postfix/master.cf
> smtp inet n - n - - \
>smtpd -o content_filter=spamfilter:
> spamfilter unix - n n - - pipe flags=Rq user=spamfilter \
>argv=/usr/local/bin/spamfilter.sh \
>-f ${sender} -- ${recipient}
>
> >Are you using per-user configuration?
>
> I think so. But that "user=spamfilter" makes me now think
> otherwise.
Hardly a postfix expert here, but I believe you are doing your spam
filtering as the user spamfilter. Site-wide configuration, not per-user.
The $HOME used is the one of spamfilter.
Someone correct me, if I'm wrong. :)
> I set this up years ago, and only now care about whitelisting.
I'd suggest to do it right from the beginning. That is, exclusively use
the constraint rcvd or auth whitelisting variants. Also, is there any
valid reason you need this to be per-user? As opposed to maintain a
clean whitelisting site-wide anyway.
Also, as I previously hinted -- a *need* for whitelisting often is
caused by some mis-configuration or training. Whitelisting is very
rarely necessary. Do you really need it?
guenther
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: user_prefs not recognized?
On 2010-03-05 10:14, Karsten Bräckelmann wrote:
On Thu, 2010-03-04 at 15:41 -0600, Ron Johnson wrote:
On 2010-03-04 15:13, Karsten Bräckelmann wrote:
[snip]
How is SA called?
(Lines manually "continued" for easy reading.)
# grep spam /etc/postfix/master.cf
smtp inet n - n - - \
smtpd -o content_filter=spamfilter:
spamfilter unix - n n - - pipe flags=Rq user=spamfilter \
argv=/usr/local/bin/spamfilter.sh \
-f ${sender} -- ${recipient}
Are you using per-user configuration?
I think so. But that "user=spamfilter" makes me now think
otherwise.
Hardly a postfix expert here, but I believe you are doing your spam
filtering as the user spamfilter. Site-wide configuration, not per-user.
The $HOME used is the one of spamfilter.
Hmmm.
Someone correct me, if I'm wrong. :)
>
I set this up years ago, and only now care about whitelisting.
I'd suggest to do it right from the beginning. That is, exclusively use
the constraint rcvd or auth whitelisting variants. Also, is there any
valid reason you need this to be per-user? As opposed to maintain a
clean whitelisting site-wide anyway.
My wife and I don't need to white-list the same people.
Also, as I previously hinted -- a *need* for whitelisting often is
caused by some mis-configuration or training. Whitelisting is very
rarely necessary. Do you really need it?
I have noticed lately (maybe after the 3.3.0 upgrade) that the
bayesian filter quite often thinks that ham is really 50%
probability spam, sometimes even 100% spam. SA then adds a big
section to the email saying why it thinks the message is spam.
Does sa-learn know to skip over such stuff?
--
Ron Johnson, Jr.
Jefferson LA USA
"If God had wanted man to play soccer, he wouldn't have given
us arms." Mike Ditka
Re: user_prefs not recognized?
On 2010-03-04 15:41, Ron Johnson wrote:
On 2010-03-04 15:13, Karsten Bräckelmann wrote:
[snip]
How is SA called?
(Lines manually "continued" for easy reading.)
# grep spam /etc/postfix/master.cf
smtp inet n - n - - \
smtpd -o content_filter=spamfilter:
spamfilter unix - n n - - pipe flags=Rq user=spamfilter \
argv=/usr/local/bin/spamfilter.sh \
-f ${sender} -- ${recipient}
Are you using per-user configuration?
I think so. But that "user=spamfilter" makes me now think otherwise. I
set this up years ago, and only now care about whitelisting.
Definitely looks like SA isn't being run from the individual users's
accounts.
m...@haggis:~$ spamassassin -D --lint 2> SA-debug.output.txt
m...@haggis:~$ grep user_prefs SA-debug.output.txt
Mar 5 11:32:48.538 [11220] dbg: config: using \
"/home/me/.spamassassin/user_prefs" for user prefs file
Mar 5 11:32:48.538 [11220] dbg: config: read \
file /home/me/.spamassassin/user_prefs
r...@haggis:~# spamassassin -D --lint 2> SA-debug.output.txt
r...@haggis:~# grep user_prefs SA-debug.output.txt
r...@haggis:~#
--
Ron Johnson, Jr.
Jefferson LA USA
"If God had wanted man to play soccer, he wouldn't have given
us arms." Mike Ditka
Re: user_prefs not recognized?
Ron Johnson wrote: > > My wife and I don't need to white-list the same people. But if it simplifies the configuration, is there any harm in having everything on a global whitelist? How often are you likely to receive spam from someone your wife wanted whitelisted? -- Bowie
Re: user_prefs not recognized?
On Fri, 2010-03-05 at 11:19 -0600, Ron Johnson wrote:
> On 2010-03-05 10:14, Karsten Bräckelmann wrote:
> > I'd suggest to do it right from the beginning. That is, exclusively use
> > the constraint rcvd or auth whitelisting variants. Also, is there any
> > valid reason you need this to be per-user? As opposed to maintain a
> > clean whitelisting site-wide anyway.
>
> My wife and I don't need to white-list the same people.
So what? Would you consider the same mail spam, that your wife wants to
whitelist? Splitting this across users appears to be nothing but a
maintenance overhead in such a case.
> > Also, as I previously hinted -- a *need* for whitelisting often is
> > caused by some mis-configuration or training. Whitelisting is very
> > rarely necessary. Do you really need it?
>
> I have noticed lately (maybe after the 3.3.0 upgrade) that the
> bayesian filter quite often thinks that ham is really 50%
> probability spam, sometimes even 100% spam. SA then adds a big
> section to the email saying why it thinks the message is spam.
So your problem is a badly trained Bayes. Whitelisting is not going to
fix your real issue.
> Does sa-learn know to skip over such stuff?
sa-learn exclusively is run manually, and will learn according to what
you explicitly requested. Two things to keep in mind:
(a) Given your site-wide setup, do not run sa-learn as the recipient
user. But run it as your spamfilter user.
(b) Be careful to either train on dedicated learning mail folders only,
or after you expunged the folder. Without that expunge (compact in TB
lingo) [1], "deleted" messages in fact are not physically removed. This
results in training on messages that are believed by the user to be
removed, but in fact are not. A dirty corpus.
[1] Compact is an operation on the source folder. Emptying the Trash in
TB will not do it. The Trash holds a *copy*.
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: user_prefs not recognized?
On Fri, 2010-03-05 at 11:41 -0600, Ron Johnson wrote:
> On 2010-03-04 15:41, Ron Johnson wrote:
> > spamfilter unix - n n - - pipe flags=Rq user=spamfilter \
> > argv=/usr/local/bin/spamfilter.sh \
> > -f ${sender} -- ${recipient}
> Definitely looks like SA isn't being run from the individual users's
> accounts.
While I agree, given the above postfix conf, this is a wrong conclusion
based on the commands below.
> m...@haggis:~$ spamassassin -D --lint 2> SA-debug.output.txt
You are running SA as the user 'me'. Postfix does not.
> m...@haggis:~$ grep user_prefs SA-debug.output.txt
> Mar 5 11:32:48.538 [11220] dbg: config: using \
> "/home/me/.spamassassin/user_prefs" for user prefs file
You are seeing pure DEBUG messages there. This will not be output
without the -D switch.
> r...@haggis:~# spamassassin -D --lint 2> SA-debug.output.txt
> r...@haggis:~# grep user_prefs SA-debug.output.txt
No ~/.spamassassin/ dir? Not created either, or maybe created for the
first time? Anyway, postfix doesn't call SA as root.
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
auto-whitelist and user_prefs
I installed postfix-2.6.5 amavis-new-2.6.4 spamassassin-3.3.0 amavis home is /var/spool/amavisd I create /var/spool/amavisd/.spamassassin (drwx--) Now I want create in this directory auto-whitelist and user_prefs files. How can I do? Thanks Andrea
Re: user_prefs questions/problem
On Sat, 2010-09-18 at 15:57 -0500, Chuck Campbell wrote:
> I have SA set up and working (mostly) on my mail machine, however I've put the
> following into my user_prefs:
>
> whitelist_from *...@zyngamail.com
This generally is not a good idea, and it is much better to use the con-
strained variants, whitelist_from_rcvd or whitelist_auth. Besides, it
renders the following entries redundant... ;)
> whitelist_from_rcvd *...@zyngamail.com zyngamail.com
> whitelist_allows_relays *...@zyngamail.com
The second argument to whitelist_from_rcvd is matched against the rDNS.
> X-Spam-Status: Yes, score=5.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
> DKIM_VALID_AU,FSL_HELO_NON_FQDN_1,HTML_MESSAGE,MIME_HEADER_CTYPE_ONLY,
> MIME_HTML_ONLY,RDNS_NONE,SPF_FAIL,TO_NO_BRKTS_NORDNS_HTML
> * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily
> * valid
> * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
> * 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
But there is no rDNS.
> If it is there, and I just don't see it, let me know where, and how to
> increase it's score to ensure whitelisted emails are not flagged as spam.
Nope, the whitelisting did not trigger indeed. The rcvd one did not,
because there is no rDNS. Dunno why the unconstrained didn't fire, you
did not provide the relevant headers.
Anyway, assuming at least one of the matched addresses for whitelisting
(see the docs) matches the message, and seeing that DKIM is valid (even
though they borked rDNS), you probably should try whitelist_auth.
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: user_prefs questions/problem
On Sat, 18 Sep 2010, Chuck Campbell wrote:
I have SA set up and working (mostly) on my mail machine, however I've put the
following into my user_prefs:
whitelist_from *...@zyngamail.com
and
whitelist_from_rcvd *...@zyngamail.com zyngamail.com
and
whitelist_allows_relays *...@zyngamail.com
when email comes in from them it is flagged as spam.
Here is an example spam report from the headers:
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on helium.inexs.com
X-Spam-Flag: YES
X-Spam-Level: *
X-Spam-Status: Yes, score=5.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,FSL_HELO_NON_FQDN_1,HTML_MESSAGE,MIME_HEADER_CTYPE_ONLY,
MIME_HTML_ONLY,RDNS_NONE,SPF_FAIL,TO_NO_BRKTS_NORDNS_HTML
+autolearn=disabled
[snip..]
I have contacted them about their SPF failure, and am awaiting a response, but
I don't see any reference to my whitelisting, is it not working as I
anticipated?
If it is there, and I just don't see it, let me know where, and how to
increase it's score to ensure whitelisted emails are not flagged as spam.
thanks,
-chuck
I assume when you say "into my user_prefs" you mean the per-user prefs
(as opposed to the site-wide config).
Have you enabled per-user prefs in the site-wide config? (default is not
enabled). Is SA integrated in your mail system in a way that it "knows"
the user name of the recipient? (some integration methods do not make that
info avaialble to SA so the per-user prefs don't work).
Have you checked to make sure that your user_prefs are available/readable
to the SA daemon?
Try putting those white-list statements in the global "local.cf" config
file (do a --lint check & what ever steps are necessary to restart SA so
that it will see the changes) and then test to see if the whitelist works.
If it does then there's an issue with your per-user prefs, if not then
there's an issue with the white-listing itself.
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: user_prefs questions/problem
On lør 18 sep 2010 23:26:45 CEST, Karsten Bräckelmann wrote whitelist_from *...@zyngamail.com This generally is not a good idea, and it is much better to use the con- strained variants, whitelist_from_rcvd or whitelist_auth. Besides, it renders the following entries redundant... ;) i will vote for this to be removed in 3.4.x, or should it be called whitelistaassin :) whitelist_from have pratical examples of working as expected ? -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: user_prefs questions/problem
On Sat, 2010-09-18 at 18:46 -0500, Dave Funk wrote:
> On Sat, 18 Sep 2010, Chuck Campbell wrote:
> > I have SA set up and working (mostly) on my mail machine, however I've put
> > the
> > following into my user_prefs:
> > I don't see any reference to my whitelisting, is it not working as I
> > anticipated?
> I assume when you say "into my user_prefs" you mean the per-user prefs
> (as opposed to the site-wide config).
>
> Have you enabled per-user prefs in the site-wide config? (default is not
White and blacklist options are user preferences.
I assume you are thinking allow_user_rules, aren't you? That indeed
defaults to disabled, but applies to rule definitions only.
> enabled). Is SA integrated in your mail system in a way that it "knows"
> the user name of the recipient? (some integration methods do not make that
> info avaialble to SA so the per-user prefs don't work).
> Have you checked to make sure that your user_prefs are available/readable
> to the SA daemon?
This, however, is a good point indeed. :)
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: user_prefs questions/problem
On Sat, Sep 18, 2010 at 06:46:18PM -0500, Dave Funk wrote: > On Sat, 18 Sep 2010, Chuck Campbell wrote: > > >I have SA set up and working (mostly) on my mail machine, however I've put > >the > >following into my user_prefs: > > > >whitelist_from *...@zyngamail.com > >and > >whitelist_from_rcvd *...@zyngamail.com zyngamail.com > >and > >whitelist_allows_relays *...@zyngamail.com > > > > > >when email comes in from them it is flagged as spam. > > > >Here is an example spam report from the headers: > > > >X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on helium.inexs.com > >X-Spam-Flag: YES > >X-Spam-Level: * > >X-Spam-Status: Yes, score=5.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, > > DKIM_VALID_AU,FSL_HELO_NON_FQDN_1,HTML_MESSAGE,MIME_HEADER_CTYPE_ONLY, > > MIME_HTML_ONLY,RDNS_NONE,SPF_FAIL,TO_NO_BRKTS_NORDNS_HTML > >+autolearn=disabled > [snip..] > >I have contacted them about their SPF failure, and am awaiting a response, > >but > >I don't see any reference to my whitelisting, is it not working as I > >anticipated? > > > >If it is there, and I just don't see it, let me know where, and how to > >increase it's score to ensure whitelisted emails are not flagged as spam. > > > >thanks, > >-chuck > First, thanks for the reply. > I assume when you say "into my user_prefs" you mean the per-user prefs > (as opposed to the site-wide config). yes, those in the /home/user/.spamassassin/user_prefs file > > Have you enabled per-user prefs in the site-wide config? (default is not > enabled). Is SA integrated in your mail system in a way that it "knows" Not sure where to enable this. Will dig more in the docs. > the user name of the recipient? (some integration methods do not make that > info avaialble to SA so the per-user prefs don't work). > Have you checked to make sure that your user_prefs are available/readable > to the SA daemon? How do I test this? > > Try putting those white-list statements in the global "local.cf" config > file (do a --lint check & what ever steps are necessary to restart SA so > that it will see the changes) and then test to see if the whitelist works. Done this in /etc/mail/spamassassin/local.cf waiting for appropriate message(s) to arrive and check headers. > If it does then there's an issue with your per-user prefs, if not then > there's an issue with the white-listing itself. I'll be back...
Re: user_prefs questions/problem
On Mon, 20 Sep 2010, Chuck Campbell wrote:
> > enabled). Is SA integrated in your mail system in a way that it "knows"
>
> Not sure where to enable this. Will dig more in the docs.
>
> > the user name of the recipient? (some integration methods do not make that
> > info avaialble to SA so the per-user prefs don't work).
> > Have you checked to make sure that your user_prefs are available/readable
> > to the SA daemon?
>
> How do I test this?
Assuming you're running spamd with standard logging enabled, look at the
spamd logs. You should see the username associated in each log entry. EG:
Sep 20 17:39:24 server33 spamd[20757]: spamd: connection from
s-l104.engr.uiowa.edu [128.255.17.210] at port 36478
Sep 20 17:39:24 server33 spamd[20757]: spamd: checking message
<20100920163923.oyqyrtl...@mx1.whitebeek.com> for astockda:115
Sep 20 17:39:25 server33 spamd[20757]: spamd: identified spam (29.1/6.0) for
astockda:115 in 1.2 seconds, 19513 bytes.
Sep 20 17:39:25 server33 spamd[20757]: spamd: result: Y 29 -
BAYES_99,COMBINED_FROM,FS_DEGREE,FVGT_m_MULTI_ODD2,HTML_90_100,HTML_MESSAGE,HTML_TAG_BALANCE_BODY,HTML_TINY_FONT,L_CLAMAV,MY_CLAMAV,RAZOR2_CF_RANGE_51_100,RAZOR2_CF_RANGE_E8_51_100,RAZOR2_CHECK,SPF_PASS,T__BOTNET_NOTRUST,T__MY_CLAMAV,URIBL_BLACK,URIBL_JP_SURBL,URIBL_OB_SURBL,URIBL_WS_SURBL
scantime=1.2,size=19513,user=astockda,uid=115,required_score=6.0,rhost=s-l104.engr.uiowa.edu,raddr=128.255.17.210,rport=36478,mid=<20100920163923.oyqyrtl...@mx1.whitebeek.com>,bayes=1,autolearn=spam
That "for astockda" and "user=astockda" part is the username that spamd
received from the milter that I use to connect sendmail to spamd
To check user_prefs readablilty, do this:
1) on the machine running spamd (or what ever SA mechanism) login (or su)
to the user in question.
2) create or obtain a test mail message, store in a text file.
3) run it thru spamassassin in debug mode:
% spamassassin -D < test-message.txt > /tmp/test.out 2>&1
Then grep for 'user' in the output file:
% grep user /tmp/test.out
[21751] dbg: config: using "/home/bill/.spamassassin" for user state dir
[21751] dbg: config: using "/home/bill/.spamassassin/user_prefs" for user prefs
file
[21751] dbg: config: read file /home/bill/.spamassassin/user_prefs
[21751] dbg: Botnet: adding (\b|\d)user(\b|\d) to botnet_clientwords
Note the line that says "read file /home/bill/.spamassassin/user_prefs"
that file should exist and be readable by your spamd process AND be the
file that you've put the user config stuff in.
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: user_prefs questions/problem
> > > > Try putting those white-list statements in the global "local.cf" config > > file (do a --lint check & what ever steps are necessary to restart SA so > > that it will see the changes) and then test to see if the whitelist works. > > Done this in /etc/mail/spamassassin/local.cf > > waiting for appropriate message(s) to arrive and check headers. OK, this works properly now, and I see a USER_IN_WHITELIST under spam tests. How do I sort out the per_user prefs issues I've got (they clearly aren't working). I need to find where to look for info on how to turn them on. thanks, -chuck
Re: user_prefs questions/problem
On Tue, 2010-09-21 at 17:18 -0500, Chuck Campbell wrote:
> > > Try putting those white-list statements in the global "local.cf" config
> > > file (do a --lint check & what ever steps are necessary to restart SA so
> > > that it will see the changes) and then test to see if the whitelist works.
> >
> > Done this in /etc/mail/spamassassin/local.cf
> >
> > waiting for appropriate message(s) to arrive and check headers.
>
> OK, this works properly now, and I see a USER_IN_WHITELIST under spam tests.
>
> How do I sort out the per_user prefs issues I've got (they clearly aren't
> working).
>
> I need to find where to look for info on how to turn them on.
As I said in a previous reply, white and blacklist options *are* per
user settings and do not need to be turned on -- or rather, cannot be
turned off as user settings for that matter.
If the same (user) settings work in site-wide config, but not in
user_prefs, the issue most likely is that the user_prefs are not used
for some reason.
There are some relevant spamd command line options, that might cause
this. And of course, using some glue to SA that does not provide the
user for per-user settings to work at all comes to mind.
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: user_prefs questions/problem
On 9/18/2010 4:57 PM, Chuck Campbell wrote: > I have SA set up and working (mostly) on my mail machine, however I've put the > following into my user_prefs: > > whitelist_from *...@zyngamail.com > and > whitelist_from_rcvd *...@zyngamail.com zyngamail.com > and > whitelist_allows_relays *...@zyngamail.com > > > when email comes in from them it is flagged as spam. > > Here is an example spam report from the headers: > > X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on helium.inexs.com > X-Spam-Flag: YES > X-Spam-Level: * > X-Spam-Status: Yes, score=5.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, > DKIM_VALID_AU,FSL_HELO_NON_FQDN_1,HTML_MESSAGE,MIME_HEADER_CTYPE_ONLY, > MIME_HTML_ONLY,RDNS_NONE,SPF_FAIL,TO_NO_BRKTS_NORDNS_HTML > +autolearn=disabled > version=3.3.1 > X-Spam-Report: > * 0.0 FSL_HELO_NON_FQDN_1 FSL_HELO_NON_FQDN_1 > * 0.9 SPF_FAIL SPF: sender does not match SPF record (fail) > * [SPF failed: Please see > +http://www.openspf.org/Why?s=mfrom;id=notifications%2Bvvvo8mu4wy%40zyngamail.co > +m;ip=10.49.16.82;r=helium.inexs.com] > Your trusted_networks is broken. SA thinks that helium.inexs.com is not a part of your normal mail delivery, and thus is assuming that is the originating outside server for zynga. Looking at the message you sent to the list, helium is actually your server.
Re: user_prefs questions/problem
Follow-up to self. *gnarf*
On Wed, 2010-09-22 at 00:35 +0200, Karsten Bräckelmann wrote:
> On Tue, 2010-09-21 at 17:18 -0500, Chuck Campbell wrote:
> > > Done this in /etc/mail/spamassassin/local.cf
> > > waiting for appropriate message(s) to arrive and check headers.
> >
> > OK, this works properly now, and I see a USER_IN_WHITELIST under spam tests.
You did keep a sample this time, so you don't have to wait for another
one, right? ;)
> > How do I sort out the per_user prefs issues I've got (they clearly aren't
> > working).
> If the same (user) settings work in site-wide config, but not in
> user_prefs, the issue most likely is that the user_prefs are not used
> for some reason.
Key for debugging is to have a sample, and to reproduce the issue by
passing the sample to SA exactly as your mail processing chain would.
(IIRC you didn't mention how you integrate SA.)
> There are some relevant spamd command line options, that might cause
> this. And of course, using some glue to SA that does not provide the
> user for per-user settings to work at all comes to mind.
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: user_prefs not working
At 06:15 AM 4/19/2005, Marcel Hochuli wrote: Hi I have a user_prefs file in the home-dir of one user. In that file are these two lines: use_dma_spam_mailbox = true spam_mailbox_name = MYSPAM In the system-prefs are these two lines: # use_dma_spam_mailbox = false # spam_mailbox_name = SPAM The Spammail don't get to the MYSPAM mailbox. When I change the system-prefs so the two lines look like this: use_dma_spam_mailbox = true # spam_mailbox_name = SPAM then Spammail goes into mailbox SPAM instead of MYSPAM What's wrong with my settings? Umm, asside from the fact that those aren't SpamAssassin settings at all? SpamAssassin doesn't do mailbox delivery. At all. It has no settings that even vaguely resemble the ones you mention above. Those settings are settings for communigate, not spamassassin and thus will not be honored by spamassassin in user_prefs.
Re: user_prefs not working
ahh! - thanks for the hint Then it's CGPSA which transports mails to and from SpamAssassin. I have to set these parameters in CGPSAs user-config-files. I'll try that next, thank you Marcel ___ Am 19.04.2005 um 15:59 schrieb Matt Kettler: At 06:15 AM 4/19/2005, Marcel Hochuli wrote: Hi I have a user_prefs file in the home-dir of one user. In that file are these two lines: use_dma_spam_mailbox = true spam_mailbox_name = MYSPAM In the system-prefs are these two lines: # use_dma_spam_mailbox = false # spam_mailbox_name = SPAM The Spammail don't get to the MYSPAM mailbox. When I change the system-prefs so the two lines look like this: use_dma_spam_mailbox = true # spam_mailbox_name = SPAM then Spammail goes into mailbox SPAM instead of MYSPAM What's wrong with my settings? Umm, asside from the fact that those aren't SpamAssassin settings at all? SpamAssassin doesn't do mailbox delivery. At all. It has no settings that even vaguely resemble the ones you mention above. Those settings are settings for communigate, not spamassassin and thus will not be honored by spamassassin in user_prefs.
Re: user_prefs migration script
On Thu, 26 May 2005, Dan Mahoney, System Admin wrote: Hey, posted this a few days ago with some questions. Did anyone get it or is my mailer being stupid? Hey all, I was migrating over to SQL, and I've written a script that allows users to migrate their prefs into (and out of) a SQL database, including some command line switches for root to be able to migrate all users in at once. My code's not the cleanest in the world, but I'm trying. I wrote it as a stub so my existing tools to edit prefs files would still work. I don't know if I've duplicated any effort here, but would anyone be interested in such a script? Should I submit it as a bug report or just provide a link? Do I need to sign away anything if I wanted to "contribute" it to the actual SA base? Please let me know. -Dan Mahoney (www.gushi.org/updateprefs.pl) -- "Station!" -Bill & Ted's Bogus Journey Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---
Re: user_prefs migration script
> Hey, posted this a few days ago with some questions. Did anyone get it or > is my mailer being stupid? It showed up. Guess nobody commented on it, but it sounds like a neat tool if you are using SQL. Loren
Re: user_prefs score value
At 07:37 AM 10/25/2004 +, tadeusz ferenc wrote: Using spamassassin 3.0.0 on my ISP whatever I set the score to in my rule set, when the event is triggered the score is always 1. I am using the following as a test add_header all tf Score Values (_TESTSSCORES(,)_) rawbody TF_RAWBODY_WARNING_1 /message\.scr/i score TF_RAWBODY_WARNING_1 20 As spamassassin is running on my ISP I can not give very many details about the setup, they have been unable to answer this question and I have been unable to find the answer either! Does your ISP use spamd? (most large sites do). If so, did they (foolishly) set allow_user_rules to 1? If not, any rules in user_prefs should be ignored. The fact that your rule is even executed is a security hole.
spamass-milter vs user_prefs
I'm trying to get spamass-milter with user_prefs to work, the only solution what i found yet is to use a global user_prefs with the spamd virtual-config-dir option. Is there a configuration possible which allows individual user_prefs with spamass-milter ? go
user_prefs rules throwing errors
I have narrowed down a couple of rules in my user_prefs file, either of which are creating an error in my log file: "Insecure dependency in eval while running setuid at /usr/local/lib/perl5/site_perl/5.8.4/Mail/SpamAssassin/Conf/Parser.pm line 913" The two rules are: # body PATENT_BIZ /based patent business/i score PATENT_BIZ-2.0 describe PATENT_BIZ Reduce score for someone with comments about my business # body YOUR_PATENT/your patents/i score YOUR_PATENT -2.0 describe YOUR_PATENTReduce score for someone with comments about my patents # When I comment them both out, the error goes away. Is there a syntax error that I'm not aware of with these? I used them successfully with older versions of SA but I'm at version 3.1.0 and am getting the error message and it is killing SA from completion. Jim Smith
Re: local.cf, user_prefs etc
Am 21.05.2015 um 15:48 schrieb Dmitry Baronov: Hello folks! I use 3.4.1 freebsd version with compiled rules. Please, give me advice how I could use local config file to override downloaded default values? All my attemps were unsuccessful. I placed local.cf and user_prefs files in /root/spamassassin /etc/mail/spamassassin /usr/local/etc/mail/spamassassin /usr/local/share/spamassassin - no way to replace default values like blacklist_from or required_score did you restart SA after the changes? no need to test blindly, the correct folder contains "init.pre" and other .pre files and besides that Sa should not run as root "/root/spamassassin" is wrong anyways because it would be "/root/.spamassassin" signature.asc Description: OpenPGP digital signature
Re: local.cf, user_prefs etc
On Thu, 21 May 2015, Dmitry Baronov wrote:
Hello folks!
I use 3.4.1 freebsd version with compiled rules.
Please, give me advice how I could use local config file to override
downloaded default values?
All my attemps were unsuccessful.
I placed local.cf and user_prefs files in /root/spamassassin
/etc/mail/spamassassin /usr/local/etc/mail/spamassassin
/usr/local/share/spamassassin - no way to replace default values like
blacklist_from or required_score.
I need help :)
Rgds,
db
First, how are you using spamassassin?
Are you using the 'spamd' daemon and feeding it spam via "spamc" (from a
procmail receipt or a postfix filter, or a milter)?
Are you using the spamassassin program itself from procmail?
Are you using some kind of dedicated mail filtering package such as
mimedefang or amavis which instantiates an instance of spamassassin within
its own process via the spamassassin APIs?
The first two methods use the standard spamassassin config files, the last
one may ignore standard spamassassin config files and use its own.
For the first two you need to determine which config files are being used
as it's possible that your SA kit was built with non-standard internal settings.
Invoke spamassassin with the "--lint -D" flags and it will tell you which
config files it's using. The 'local' variants of the config files that it
says it's reading are the ones you want to modify.
For the last method you'll have to consult the relevant documentation.
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: local.cf, user_prefs etc
I use spamassassin with CommuniGatePro cgpsa helper, . With Spamassassin 3.3.2 I had ability to customize default values in local.cf file. With 3.4.x I lost this ability i can't find again :/ 21.05.2015 17:33, Dave Funk пишет: On Thu, 21 May 2015, Dmitry Baronov wrote: Hello folks! I use 3.4.1 freebsd version with compiled rules. Please, give me advice how I could use local config file to override downloaded default values? All my attemps were unsuccessful. I placed local.cf and user_prefs files in /root/spamassassin /etc/mail/spamassassin /usr/local/etc/mail/spamassassin /usr/local/share/spamassassin - no way to replace default values like blacklist_from or required_score. I need help :) Rgds, db First, how are you using spamassassin? Are you using the 'spamd' daemon and feeding it spam via "spamc" (from a procmail receipt or a postfix filter, or a milter)? Are you using the spamassassin program itself from procmail? Are you using some kind of dedicated mail filtering package such as mimedefang or amavis which instantiates an instance of spamassassin within its own process via the spamassassin APIs? The first two methods use the standard spamassassin config files, the last one may ignore standard spamassassin config files and use its own. For the first two you need to determine which config files are being used as it's possible that your SA kit was built with non-standard internal settings. Invoke spamassassin with the "--lint -D" flags and it will tell you which config files it's using. The 'local' variants of the config files that it says it's reading are the ones you want to modify. For the last method you'll have to consult the relevant documentation.
Re: local.cf, user_prefs etc
On 5/22/2015 4:35 AM, Dmitry Baronov wrote: I use spamassassin with CommuniGatePro cgpsa helper, . With Spamassassin 3.3.2 I had ability to customize default values in local.cf file. With 3.4.x I lost this ability i can't find again :/ Nothing in 3.4.x has removed any such feature. I would run spamassassin --version from the command line, confirm it's 3.4.x and then run: spamassassin -D --lint 2>&1 | grep LOCAL_RULES_DIR Look for this output and make sure your local.cf is in the correct directory: May 22 08:02:17.521 [6463] dbg: generic: Perl 5.008008, PREFIX=/usr/local, DEF_RULES_DIR=/usr/local/share/spamassassin, LOCAL_RULES_DIR=/etc/mail/spamassassin, LOCAL_STATE_DIR=/var/lib/spamassassin You can also run spamassassin --lint to see if there are any errors in your local.cf, etc. Regards, KAM
Re: local.cf, user_prefs etc
On Fri, 22 May 2015 08:13:05 -0400 Kevin A. McGrail wrote: > On 5/22/2015 4:35 AM, Dmitry Baronov wrote: > > I use spamassassin with CommuniGatePro cgpsa helper, . > > > > With Spamassassin 3.3.2 I had ability to customize default values > > in local.cf file. > > With 3.4.x I lost this ability i can't find again :/ > Nothing in 3.4.x has removed any such feature. > > I would run spamassassin --version from the command line, confirm > it's 3.4.x and then run: > > spamassassin -D --lint 2>&1 | grep LOCAL_RULES_DIR > > Look for this output and make sure your local.cf is in the correct > directory: > > May 22 08:02:17.521 [6463] dbg: generic: Perl 5.008008, > PREFIX=/usr/local, DEF_RULES_DIR=/usr/local/share/spamassassin, > LOCAL_RULES_DIR=/etc/mail/spamassassin, > LOCAL_STATE_DIR=/var/lib/spamassassin According to this: http://www.tffenterprises.com/cgpsa/ it's using SpamAssassin as a library, so those locations are set by CGPSA
Re: local.cf, user_prefs etc
On 5/22/2015 8:24 AM, RW wrote: On Fri, 22 May 2015 08:13:05 -0400 Kevin A. McGrail wrote: On 5/22/2015 4:35 AM, Dmitry Baronov wrote: I use spamassassin with CommuniGatePro cgpsa helper, . With Spamassassin 3.3.2 I had ability to customize default values in local.cf file. With 3.4.x I lost this ability i can't find again :/ Nothing in 3.4.x has removed any such feature. I would run spamassassin --version from the command line, confirm it's 3.4.x and then run: spamassassin -D --lint 2>&1 | grep LOCAL_RULES_DIR Look for this output and make sure your local.cf is in the correct directory: May 22 08:02:17.521 [6463] dbg: generic: Perl 5.008008, PREFIX=/usr/local, DEF_RULES_DIR=/usr/local/share/spamassassin, LOCAL_RULES_DIR=/etc/mail/spamassassin, LOCAL_STATE_DIR=/var/lib/spamassassin According to this: http://www.tffenterprises.com/cgpsa/ it's using SpamAssassin as a library, so those locations are set by CGPSA Perhaps posting at cgpsa-disc...@mail.tffenterprises.com would be better then?
Re: local.cf, user_prefs etc
Thanks a lot! 22.05.2015 15:40, Kevin A. McGrail пишет: On 5/22/2015 8:24 AM, RW wrote: On Fri, 22 May 2015 08:13:05 -0400 Kevin A. McGrail wrote: On 5/22/2015 4:35 AM, Dmitry Baronov wrote: I use spamassassin with CommuniGatePro cgpsa helper, . With Spamassassin 3.3.2 I had ability to customize default values in local.cf file. With 3.4.x I lost this ability i can't find again :/ Nothing in 3.4.x has removed any such feature. I would run spamassassin --version from the command line, confirm it's 3.4.x and then run: spamassassin -D --lint 2>&1 | grep LOCAL_RULES_DIR Look for this output and make sure your local.cf is in the correct directory: May 22 08:02:17.521 [6463] dbg: generic: Perl 5.008008, PREFIX=/usr/local, DEF_RULES_DIR=/usr/local/share/spamassassin, LOCAL_RULES_DIR=/etc/mail/spamassassin, LOCAL_STATE_DIR=/var/lib/spamassassin According to this: http://www.tffenterprises.com/cgpsa/ it's using SpamAssassin as a library, so those locations are set by CGPSA Perhaps posting at cgpsa-disc...@mail.tffenterprises.com would be better then?
Re: local.cf, user_prefs etc
On 5/22/15 8:13 AM, Kevin A. McGrail wrote: On 5/22/2015 4:35 AM, Dmitry Baronov wrote: I use spamassassin with CommuniGatePro cgpsa helper, . With Spamassassin 3.3.2 I had ability to customize default values in local.cf file. With 3.4.x I lost this ability i can't find again :/ Nothing in 3.4.x has removed any such feature. I would run spamassassin --version from the command line, confirm it's 3.4.x and then run: spamassassin -D --lint 2>&1 | grep LOCAL_RULES_DIR Look for this output and make sure your local.cf is in the correct directory: May 22 08:02:17.521 [6463] dbg: generic: Perl 5.008008, PREFIX=/usr/local, DEF_RULES_DIR=/usr/local/share/spamassassin, LOCAL_RULES_DIR=/etc/mail/spamassassin, LOCAL_STATE_DIR=/var/lib/spamassassin You can also run spamassassin --lint to see if there are any errors in your local.cf, etc. Regards, KAM Interestingly, SA puts mine /usr/local/perl-5.14.1/etc/mail/spamassassin But, that doesn't account for the ~/.spamassassin/user_prefs file, which I presume should be located anyhow, where I have my custom rules. I compiled SA from source using my own similarly-compiled perl, which is probably why the PATH is funky here. Thanks
custom rules within user_prefs
Hi all, long-time SpamAssassin user. I released an open-source web-based training script for CPanel hosting users to train spam/ham based on various configurations, and it's been very well received with a handful of CPanel-based hosting groups that I've shown it to. Check out http://iandouglas.com/page.php?3 if anyone's interested. Introductions aside, I shut down my own hosting business in 2004 after 7 successful years, and now host a handful of domains with various CPanel-based hosting groups. I found this wiki reference today after searching around for how to let users write their own custom SA rules within user_prefs: http://wiki.apache.org/spamassassin/WritingRules "Note: if you use spamd, rules placed in user_prefs will be IGNORED by default. If you add the allow_user_rules option to your local.cf you can get spamd to honor them. However, before you enable it, you should know that this is disabled by default for security reasons. In theory a malicious local user might be able to exploit spamd with a clever regex and gain root permissions. I know of no specific vulnerabilities of this type in spamassassin at this time, but it is a possibility. I'd only turn this on if you trust your local users not to try to hack root." I was curious whether the security implications as mentioned in the wiki page referenced above have been addressed at all, and whether or not it would be considered relatively 'safe' yet to let users write their own SA rules within their user_prefs, or perhaps a compromise of listing the individual users within the local.cf file instead of a global "let everyone do it" setting? Thanks for any thoughts, -id
Re: user_prefs not working
John Tice wrote: > Running SA on a Cpanel VPS that had an outage yesterday, when it came > back up SA is not using any of the user_prefs files in the individual > accounts. Support doesn't know what to do. The user_prefs are still in > the proper places but just not being read, or not influencing the > scores, no whitelists, etc. Can anyone offer troubleshooting advice > that I can use directly or pass along to the support folks? Thanks. In general it sounds like SA is no longer being called as the desired user, and is instead always executing as something like root or mail. That's the typical cause of this kind of stuff. How's SA being called? are they using spamc/spamd and passing spamc a -u parameter? Or are they relying on some other part of the system su'ing to the desired user before calling spamc? I suppose it's possible file permissions got screwed up in the outage, so they could also try running spamassassin --lint (which should be SILENT) and then spamassassin -D --lint while su'ed to a user to make sure it's reading all the files correctly. > >
Re: spamd, postfix & user_prefs
On Thu, 10 Nov 2011, li...@nerdbynature.de wrote:
Hi there,
my spamd seems to ignore the ~/.spamassassin/user_prefs file.
I've searched the archives about this issue, the closest one[0] I came
across was:
> [...] users can add new rules for their own use in the
> "~/.spamassassin/user_prefs" file, if they like.
> (spamd disables this for security and increased speed.)
I'm using SA 3.3.1 (from Debian/stable) and enabled 'allow_user_rules'
in local.cf. I intend to use only required_score, whitelist_from
and score - as I understand the comment above, these are not "rules" and
a per-user user_prefs should be evaluated even w/o 'allow_user_rules'.
When attaching strace(1) to the spamd processes it shows that only
/var/mail/.spamassassin/* is being read, but nothing in /home/*
is ever read. Even if it's a permission issue, I'd expect at least an
-EACCES.
The setup is as follows:
* fetchmail fetches mail from a remote server,
* delivers to postfix (localhost:25)
* Postfix delivers to clamsmtpd (for virus-checking) which passes
the message back to postfix, which in turn
* passes it to a spamassassin service
* maildrop delivers the mail to the user's Maildir.
--- master.cf
spamassassin unix - n n - - pipe
user=mail argv=/usr/bin/spamc -e /usr/sbin/sendmail -oi -f \
${sender} ${recipient}
[...]
maildrop unix - n n - - pipe
flags=DRhu argv=/usr/bin/maildrop -d ${recipient}
-
When email is being fetched I can see that "spamc -e ..." is being
spawned and spamd:783 is being connected to.
When running "spamassassin -D < mail.eml" manually as a user, my
user_prefs is of course read and evaulated correctly.
So, I really like to know why it is ignored when SA is called from
Postfix. Any ideas?
Thanks,
Christian.
How are you telling spamc who the user is? For per-user specific
rules spamc has to know who the user is to go get their rules.
This is accomplished by one of two methods, either use the '-u username'
optional argument or have the process invoking spamc run as the
desired user. Usually that is done at delivery time (such as in a
procmail recipe).
Looking at your config snippets, it looks like you're running spamc
as "user=mail" and there's no sign of a '-u' argument to spamc.
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: spamd, postfix & user_prefs
On Fri, 11 Nov 2011 at 02:36, David B Funk wrote:
> How are you telling spamc who the user is? For per-user specific
> rules spamc has to know who the user is to go get their rules.
> This is accomplished by one of two methods, either use the '-u username'
Hah! Perfect, thank you! I've added "-u ${user}" to Postfix' master.cf
file and it seems to work so far:
-
spamassassin unix - n n - - pipe
user=mail argv=/usr/bin/spamc -u ${user} -e /usr/sbin/sendmail -oi \
-f ${sender} ${recipient}
-
> optional argument or have the process invoking spamc run as the
> desired user. Usually that is done at delivery time (such as in a
> procmail recipe).
Yeah, I think I had this before: I was calling spamc from maildrop (via
~/.mailfilter) but I suspected it to be a performance killer and wanted
Postfix to do this for me. Not sure if that makes sense at all.
What puzzles me now, is how "spamc" is now able to run as a different
user. "spamd" is running as root, with two child process as "mail":
root 29159 1 0 23:07 ?00:00:01 /usr/sbin/spamd
mail 29160 29159 0 23:07 ?00:00:03 spamd child
mail 29161 29159 0 23:07 ?00:00:02 spamd child
Neither "spamd" nor "spamc" has the sgid/suid bit set and when mail
arrives, "spamc" is indeed spawned as user "mail":
---
mail 31727 0.0 0.1 15216 1384 ?Ss 23:19 0:00
/usr/bin/spamc -u christian -e /usr/sbin/sendmail -oi -f t...@example.com
christian@localhost
---
Of course, user "mail" is allowed to peek into ~/.spamassassin/ - does
that mean that spamc is not really switching its effective user id?
Thanks again!
Christian.
--
BOFH excuse #10:
hardware stress fractures
Re: Scoring in user_prefs
LuKreme wrote: > > I would like to add a score in user_prefs based on the To header (I have an > email that collects several email addresses and I want to add some > spamishness indicators). > > Does the user_prefs understand the same syntax as the local.cf file? And what > would be the best way to say: > > If the to field is u...@example.com add 1.0 top the spam score > > header __TO_EXAMPLE To =~ /user\@example.com/ > score __TO_EXAMPLE 1.0 If you want to put full rules in user_prefs files, you'll need to set allow_user_rules in the main configuration. man Mail::SpamAssassin::Conf and scroll down to the "RULE DEFINITIONS AND PRIVILEGED SETTINGS" section. -kgd
Re: Scoring in user_prefs
On 08 Nov 2013, at 13:42 , Kris Deugau wrote: > If you want to put full rules in user_prefs files, you'll need to set > allow_user_rules in the main configuration. > > man Mail::SpamAssassin::Conf and scroll down to the "RULE DEFINITIONS > AND PRIVILEGED SETTINGS" section. Thank you! -- It wasn't that her [Susan's] parents didn't believe in such things. They didn't need to believe in them. They knew they existed. They just wished they didn't.
Re: Scoring in user_prefs
On 08 Nov 2013, at 13:42 , Kris Deugau wrote: > man Mail::SpamAssassin::Conf and scroll down to the "RULE DEFINITIONS > AND PRIVILEGED SETTINGS" section. Oh, well, crap. Yeah, that's not going to happen. OK, time to come up with another way of doing this... ZZ er.. right. -- "What if your DOPE was on fire?" "Impossible, sir, it's in Johnson's underwear."
Re: loadplugin TextCat from user_prefs
[EMAIL PROTECTED] wrote: > loadplugin Mail::SpamAssassin::Plugin::TextCat > #I hate ru: > ok_languages af am ar be bg ca cs da de el en es fa fi fr he hi hr hu hy id > it ja ka ko mr ms ne nl no pl pt qu ro sk sq sr sv sw ta th tl tr uk vi zh > add_header all languages _LANGUAGES_ > #score UNWANTED_LANGUAGE_BODY 11 > > I was doing great, having a good time until --lint complained about > UNWANTED_LANGUAGE_BODY, so I had to comment it out. > > Anyway, big mystery: how does one enjoy UNWANTED_LANGUAGE_BODY? > I wish to only edit user_prefs, not gumming up anything else. > Sorry, that's nearly impossible from pure user_prefs, and the only way it would be possible would involve severely hacking up the spamassasssin. You really need to have that plugin loaded from a .pre file. It must be loaded before the default ruleset is read, because that's where the UNWANTED_LANGUAGE_BODY rule is declared. If the plugin is not loaded at the time the default ruleset is read, the rule is skipped and never even read in. user_prefs is the absolute last thing read by spamassasssin, at that point, it's vastly too late to try to load a plugin that impacts the default rulesets. Those rules are already long since gone, files read and those rules were skipped because their plugin wasn't loaded. The whole concept of using .pre files was created because of the exact problem. They are loaded first, before anything else, to ensure your plugins are available before any rules files are read. Rather than guming things up by trying to load standard plugins in your user_prefs, enable textcat in the standard v310.pre file that is already created for you, you just need to remove a single # from the start of the line. This really is the only reasonable way to do it. Your other alternatives include: 1) Copying parts of the default ruleset into your user_prefs. However, this effectively inhibits sa-update from updating the rules. 2) hacking the source code so user_prefs is loaded before the default ruleset. Neither of those is particularly pretty, and would certainly be by far more prone to "gum things up" than using the .pre files as they're designed.
user_prefs rules not being used
I'm running SpamAssassin version 3.1.8 on SuSE 9.3. Spamassassin is invoked through amavisd. I have a series of whitelist_from commands in my /etc/mail/spamassassin/local.cf, which spamassassin recognizes. I also have allow_user_rules 1 in my local.cf. However, when I edit .spamassassin/user_prefs in my home directory to add further whitelist_from commands, spamassassin doesn't see them. Is there any obvious reason why? Tnx in advance. -- Alayne McGregor alayne at twobikes.ottawa.on.ca "I propose a new standard by which to judge mainstream literature. The more often a fantasy reader thinks, 'Oh, just forget all that and go save the world, will you?' the lower the quality of the book." -- Janni Lee Simner
Re: custom user_prefs file spamc
Maarten wrote: Hello, I'm setting up a gateway spamfilter mailserver. And I like to be able to give with spamc the path to the user_prefs file for the right domain. So the user does not exists, so I can not use the -U option. I have read this patch http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4405 and I was wondering if this is the only solution? Or will it become possible with a future version? Can you use the--virtual-config-dir option to spamd? This would allow you to use spamc -u, but the user invoked is a virtual user that is just a directory name, and doesn't cause spamd to try to setuid to it.
Re: user_prefs: mind the linebreak
MK> Why would there ever be a problem fitting on one line? Lines aren't MK> limited to 80 characters or anything silly like that.. MK> That sounds a bit like complaining that a ship must fit in the water.. MK> There's a whole ocean out there, so who cares if you can't put one MK> boat in 2 rain puddles.. Call me old fashioned, but I still want to be able to keep lines to a length I prefer. Yes I imagine your world probably looks like editing a Wikipedia article with its long lines, but in mine, emacs: toggle-truncate-lines is an interactive compiled Lisp function in `simple.el'. Toggle whether to fold or truncate long lines for the current buffer. With arg, truncate long lines iff arg is positive. Both are uncomfortable with long lines. Also how do you print long lines on a line printer? Never mind. Anyway, maybe http://en.wikipedia.org/wiki/Carriage_return http://en.wikipedia.org/wiki/Newline talk about the problem, maybe not. Don't tell me I'm the only one who is still line-length aware.
Re: user_prefs: mind the linebreak
[EMAIL PROTECTED] wrote: MK> Why would there ever be a problem fitting on one line? Lines aren't MK> limited to 80 characters or anything silly like that.. MK> That sounds a bit like complaining that a ship must fit in the water.. MK> There's a whole ocean out there, so who cares if you can't put one MK> boat in 2 rain puddles.. Call me old fashioned, but I still want to be able to keep lines to a length I prefer. Call me older fashioned.. I consider line-wrapping a bit too "fancy" for my config editing preferences.
RE: user_prefs: mind the linebreak
> -Original Message- > From: Matt Kettler [mailto:[EMAIL PROTECTED] > Sent: Tuesday, 19 February 2008 4:43 p.m. > To: [EMAIL PROTECTED] > Cc: users@spamassassin.apache.org > Subject: Re: user_prefs: mind the linebreak > > [EMAIL PROTECTED] wrote: > > MK> Why would there ever be a problem fitting on one line? Lines aren't > > MK> limited to 80 characters or anything silly like that.. > > > > MK> That sounds a bit like complaining that a ship must fit in the > water.. > > MK> There's a whole ocean out there, so who cares if you can't put one > > MK> boat in 2 rain puddles.. > > > > Call me old fashioned, but I still want to be able to keep lines to a > > length I prefer. > > > Call me older fashioned.. I consider line-wrapping a bit too "fancy" for > my config editing preferences. Line wrapping in config is bad. I've had several instances of an editor in linux that I won't name where I've lost config data because of it wrapping lines instead of just displaying it off page until I'm ready to see it. This seems to happen a lot more frequently with terminal emulation, however, usually when SSH'd into a linux box using an emu like putty. And they still haven't got terminal emulation correct, after all these years. Admittedly if you stick to 80x25 you're probably a bit better off, but 80x25 don't cut it on a 21 inch LCD. Cheers, Mike
Re: user_prefs: mind the linebreak
MK> Call me older fashioned.. I consider line-wrapping a bit too "fancy" MK> for my config editing preferences. I see, you must have a billion column wide terminal or something. Oops. You whippersnappers don't call them terminals these days. Anyway, I swear I am not dreaming: $ info make We split each long line into two lines using backslash-newline; this is like using one long line, but is easier to read. http://en.wikipedia.org/wiki/Backslash#Usage So OK call me a user with disabilities then, but don't hinder my accessibility. Please spamassassin implement backslash-newline like make, sh, etc.
Re: user_prefs: mind the linebreak
Michael Hutchinson wrote: Line wrapping in config is bad. I've had several instances of an editor in linux that I won't name where I've lost config data because of it wrapping lines instead of just displaying it off page until I'm ready to see it. This seems to happen a lot more frequently with terminal emulation, however, usually when SSH'd into a linux box using an emu like putty. And they still haven't got terminal emulation correct, after all these years. Admittedly if you stick to 80x25 you're probably a bit better off, but 80x25 don't cut it on a 21 inch LCD. tip: Terraterm can be set to scale terminal size to match window size, and the right versions can do ssh..
Re: user_prefs: mind the linebreak
[EMAIL PROTECTED] wrote: > MK> Call me older fashioned.. I consider line-wrapping a bit too "fancy" > MK> for my config editing preferences. > > I see, you must have a billion column wide terminal or something. > Oops. You whippersnappers don't call them terminals these days. > Anyway, I swear I am not dreaming: > $ info make > We split each long line into two lines using backslash-newline; this is > like using one long line, but is easier to read. > http://en.wikipedia.org/wiki/Backslash#Usage > > So OK call me a user with disabilities then, but don't hinder my > accessibility. Please spamassassin implement backslash-newline like > make, sh, etc. For what? The only config lines that I can think of that are really long are for rules. We're certainly not going to go sticking backslashes in the middle of regexes. Daryl
Re: user_prefs: mind the linebreak
This is bug 5442, btw.
On Mon, 2008-02-18 at 23:54 -0500, Daryl C. W. O'Shea wrote:
> For what? The only config lines that I can think of that are really
> long are for rules. We're certainly not going to go sticking
> backslashes in the middle of regexes.
Not necessarily in the middle of REs, but what about before them?
describe __MY_VERY_OWN_RULE I dont forget my own rule, do I
header __MY_VERY_OWN_RULE X-Spam-Relays-Untrusted =~ m,(long)? re,
There's plenty of whitespace and opportunity to support basic line
continuation between the tokens.
header __MY_VERY_OWN_RULE X-Spam-Relays-Untrusted =~ \
m,this long re won't wrap even with old school terminals,
Also, meta rules tend to get really long, and it would make a difference
if one can fold them.
FWIW, I'd appreciate this, too. :)
guenther
--
char *t="[EMAIL PROTECTED]";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Proper use of user_prefs "whitelist"
I've been having some difficulty with the user_prefs and the whitelist_* fucntions. I read the examples etc, and I believe these are correct, but clearly certain email is still being tagged (see below). I wonder if someone can help clarify what I'm doing wrong here. First, here are the directives in my ~/.spamassassin/user_prefs file, as it applies to this instance: whitelist_from_rcvd spamassassin.apache.org hermes.apache.org whitelist_from *.apache.org Here is the Sendmail log, showing the rejection: Apr 13 11:52:24 mail sm-mta[34951]: k3DFqNBR034951: from=<[EMAIL PROTECTED]>, size=17514, class=-60, nrcpts=1, msgid=<[EMAIL PROTECTED]>, proto=SMTP, daemon=MTA, relay=hermes.apache.org [209.237.227.199] Apr 13 11:52:26 mail sm-mta[34951]: k3DFqNBR034951: Milter add: header: X-Spam-Flag: YES Apr 13 11:52:26 mail sm-mta[34951]: k3DFqNBR034951: Milter add: header: X-Spam-Status: Yes, score=9.0 required=5.0 tests=HTML_00_10,HTML_MESSAGE,\n\tJ_CHICKENPOX_12,J_CHICKENPOX_33,RCVD_IN_SORBS,SARE_BIZOP,\n\tSARE_COLLEGE_SCAM,TVD_FUZZY_DEGREE autolearn=no version=3.1.1 Apr 13 11:52:26 mail sm-mta[34951]: k3DFqNBR034951: Milter: data, reject=550 5.7.1 Blocked by SpamAssassin Apr 13 11:52:26 mail sm-mta[34951]: k3DFqNBR034951: to=<[EMAIL PROTECTED]>, delay=00:00:02, pri=155514, stat=Blocked by SpamAssassin Thanks in advance
only user_prefs from root read
hello,
Spamassassin has been working for a few days now, i'm quite satisfied
with it (actually i haven't got a single spam since then :) )
my only problem:
it seems that spamass doesn't/cann't read the individual user_prefs
files.
i use a sendmail dual configuration, amavisd-new, and spamass-milter
here some config files/outputs
-
root 21075 1 0 22:51:33 ? 0:05 /opt/csw/bin/perl
-T /opt/csw/bin/spamd -d -u spamd
root 21080 1 0 22:51:51 ?
0:02 /opt/csw/sbin/spamass-milter -p /var/run/spamass.sock -f
spamd 21077 21075 0 22:51:40 ? 0:10 /opt/csw/bin/perl
-T /opt/csw/bin/spamd -d -u spamd
spamd 21076 21075 3 22:51:40 ? 1:13 /opt/csw/bin/perl
-T /opt/csw/bin/spamd -d -u spamd
#less /etc/mail/sendmail-rx.mc
...
INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass.sock, F=T,
T=C:15m;S:4m;R:4m;E:10m')dnl
define(`confMILTER_MACROS_CONNECT',`b, j, _, {daemon_name}, {if_name},
{if_addr}')dnl
...
-
#less /opt/csw/etc/spamassassin/local.cf
allow_user_rules 1
clear_report_template
clear_unsafe_report_template
required_score 3
use_bayes 1
bayes_auto_learn 1
i use
spamass_milter 0.3.0
spamassassin3.1.3
on a
#uname -a
SunOS name 5.10 Generic_118822-25 sun4u sparc SUNW,Ultra-4
what did i do wrong?
Thanks!
Alex Thor.
SA: user_prefs contains required 4.97,
I have had required_score 3.97 since 4/1/09 but spamassassin email says X-Spam-Report: ... Content analysis details: (18.4 points, 4.0 required) also MISSING_DATE 3.0 should be 2.97 and MISSING_MID 3.0 should be 2.97 I had these values several days ago! Any ideas?? ls -l /var/run/spamd -rw-r--r-- 1 5 Apr 3 12:02 spamd.pid Current user_prefs can always be seen at http://www.real-world-systems.com/mail/user_prefs.html Thanks
Spamd losing scores from user_prefs
Greetings, This is a weird one. After restarting spamd, and running tests with 'spamc -l -r < file' on a spam that triggers a custom rule, my rule is scored correctly 5 times. On the 6th test, it reverts to the default score of 1.0. Placing the rule in local.cf fixes this (at least up to 10-12 iterations). Changing the score from "5.0" to "5.0 5.0 5.0 5.0" has no effect. Using the '(4)' syntax does not work, the default of 1.0 is used. Changing the score in user_prefs within the first 5 tests after restart results in user_prefs being re-read, and the altered score being used. I should point out that the rules this problem is occurring with are defined in user_prefs, so there is no doubt whatsoever that the file is being found and read (can't be permissions etc). The rule is created and described properly. It just isn't being scored properly. The 'spamassassin' command has no problem getting the right score. Does anyone know why this might be happening? Is this an obscure feature, or should I report it as a bug? Has anyone else had similar problems? A quick search brought up too many irrelevant results to show if anyone else has posted about this... I'm running SpamAssassin 3.0.2, on RedHat 9, with Perl 5.8.0. Built as an RPM from tarball. Thanks for any help or suggestions you might have. :-) Regards, Paul
spamd, user_prefs and required scores
I'm running SpamAssassin 3.0.0 on a Red Hat Linux 9 system (2.4.27). The mail server is running sendmail 8.12.11. Users turn spamassassin on or off for their accounts by using procmail rules to call spamc. There are many users doing this, and it has worked perfectly until now. When I upgraded to SA 3.0.0 (following all of the upgrade notes, etc. carefully), I began to notice that some messages would arrive in my mailbox with the required number of hits set to different values. Sometimes it would be 7 (our system default), othertimes a different value like 5 or 8. While trying to solve this, I discovered that the values for all messages would remain at 7 for a while after the spamd process was restarted. Then I discovered where the other scores were coming from. There are a few "power users" on the system who have custom user_prefs files in ~/.spamassassin. The required scores in these few user_prefs files were the same scores I was seeing randomly appear in messages to all users. At that point, I started tweaking these few user_prefs files to different values to see what would happen. Sure enough, a portion of the messages in my mailbox started to have these values as the required score. The first thing I noticed with the upgrade is that SA now runs with some child processes. It seems that each child process will "remember" the required_score value that it picked up from a user_prefs file and apply that to future messages until a new required_score is written over it. Has anyone else experienced this problem? I will try to set up a separate installation with a similar software configuration to see if I can duplicate the problem. FYI, spamd is running with the following arguments: spamd -u spamd -d --socketpath=/var/run/spamd -s local4 And our /etc/mail/spamassassin/local.cf contains the following: lock_method flock use_bayes 1 bayes_auto_learn 0 bayes_path /etc/mail/spamassassin/bayes required_score 7.00 fold_headers 0 report_safe 0 clear_headers add_header all Status _YESNO_ (_HITS_/_REQD_ _TESTS(,)_ Bayes: _BAYES_) skip_rbl_checks 1 dns_available no use_razor2 no Thanks in advance for any info, Phil
Re: spamass-milter vs user_prefs
At 04:30 PM 12/21/2004, [EMAIL PROTECTED] wrote: I'm trying to get spamass-milter with user_prefs to work, the only solution what i found yet is to use a global user_prefs with the spamd virtual-config-dir option. Is there a configuration possible which allows individual user_prefs with spamass-milter ? In general this is only possible if the milter either setuid's itself to the recipient, or passes the -u parameter to spamc. spamass-milter should support this for single-recipient messages where the recipient address has a local user account... You might be suffering from problems due to aliases, virtual users, or other things. This seems relevant: http://savannah.nongnu.org/support/?func=detailitem&item_id=101005
User_prefs or sql prefs, faster?
Which is faster? Using the standard SA setup or using Mysql prefs and databases?
Web interface for managing user_prefs
We use spamassassin via sendmail, spamass-milter, spamc/spamd on Fedora. We are looking for a way to enable users to manage their own user_prefs file through a web interface. There is a nice plug-in for squirrelmail (an open source webmail product, http://www.squirrelmail.org) that enables users to edit spamassasin preferences but it stores the results in a squirrelmail data directory in a file with a name like “username.spam” owned by apache (instead of storing it in the $HOME/.spamassasin/user_prefs file owned by the user). I was hoping to be able to configure spamd to look in this file for the user preferences. It looks like it would be possible to do this via the –p flag if we were using spamassassin but there does not seem to be an equivalent flag for spamd. The work-around we are contemplating is to define the $HOME/.spamassassin/user_prefs file as a symbolic link to the /squirrelmail/data/username.spam file for each user but, before we go down that road, I’d like to ask the list members if you have a better idea for enabling users to manage their user_prefs. (It does seem pretty weird to ask our users to use a webmail client to modify their spamassassin preferences even if they do not use the webmail client to read their email!) Thanks - Michael Fahy CTO Chapman University 714.997.6879 [EMAIL PROTECTED]
Re: user_prefs rules throwing errors
From: "Jim Smith" <[EMAIL PROTECTED]>
I have narrowed down a couple of rules in my user_prefs file, either of
which are creating an error in my log file:
"Insecure dependency in eval while running setuid at
/usr/local/lib/perl5/site_perl/5.8.4/Mail/SpamAssassin/Conf/Parser.pm line
913"
The two rules are:
#
body PATENT_BIZ /based patent business/i
score PATENT_BIZ -2.0
describe PATENT_BIZ Reduce score for someone with comments about my
business
#
body YOUR_PATENT /your patents/i
score YOUR_PATENT -2.0
describe YOUR_PATENT Reduce score for someone with comments about my
patents
#
When I comment them both out, the error goes away. Is there a syntax error
that I'm not aware of with these? I used them successfully with older
versions of SA but I'm at version 3.1.0 and am getting the error message and
it is killing SA from completion.
What does "spamassassin --lint" say? It looks like the rules are line
wrapped perhaps inappropriately.
{^_^}
Re: user_prefs rules throwing errors
Welcome to the club. This has been happening sporadically since 3.0.0. But it seems that nobody has been able to come up with a solid testcase that will always fail. It seems that you have in some way, at least on your system. There is at least one BZ ticket open on this. Loren
RE: user_prefs rules throwing errors
The wrapping is an email thing; in user_prefs body, score, & describe are
each on a line. There are no errors in lint. The only clue that something is
amiss (other than SA not marking up the headers) is the error in the log
file.
Jim
> -Original Message-
> From: jdow [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 12, 2006 8:29 PM
> To: users@spamassassin.apache.org
> Subject: Re: user_prefs rules throwing errors
>
> From: "Jim Smith" <[EMAIL PROTECTED]>
>
> >I have narrowed down a couple of rules in my user_prefs
> file, either of
> > which are creating an error in my log file:
> > "Insecure dependency in eval while running setuid at
> >
> /usr/local/lib/perl5/site_perl/5.8.4/Mail/SpamAssassin/Conf/Pa
> rser.pm line
> > 913"
> >
> > The two rules are:
> > #
> > body PATENT_BIZ /based patent business/i
> > score PATENT_BIZ -2.0
> > describe PATENT_BIZ Reduce score for someone with comments about my
> > business
> > #
> > body YOUR_PATENT /your patents/i
> > score YOUR_PATENT -2.0
> > describe YOUR_PATENT Reduce score for someone with comments about my
> > patents
> > #
> >
> > When I comment them both out, the error goes away. Is there
> a syntax error
> > that I'm not aware of with these? I used them successfully
> with older
> > versions of SA but I'm at version 3.1.0 and am getting the
> error message and
> > it is killing SA from completion.
>
> What does "spamassassin --lint" say? It looks like the rules are line
> wrapped perhaps inappropriately.
>
> {^_^}
>
RE: user_prefs rules throwing errors
> Welcome to the club. Gee it's such an honor to be part of that club . This has been a slippery thing for me as well. If I restart SA, it will go away for a while and those rules will work correctly for approx 6-12 hours. When it starts misbehaving, I can take the two rules out and it works fine. Put them back in, and it chokes immediately. Restart and I get another several hours of trouble-free operation. Since I'm stuck inside today due to the blizzard in Connecticut, I've had lots of time to swap rules in my procmail & user_prefs file in & out until I was able to narrow the error down to those two rules. I'm not familiar with BZ but let me know if my info can help out. Regards, Jim Smith > -Original Message- > From: Loren Wilton [mailto:[EMAIL PROTECTED] > Sent: Sunday, February 12, 2006 8:40 PM > To: users@spamassassin.apache.org > Subject: Re: user_prefs rules throwing errors > > Welcome to the club. This has been happening sporadically > since 3.0.0. But > it seems that nobody has been able to come up with a solid > testcase that > will always fail. It seems that you have in some way, at > least on your > system. > > There is at least one BZ ticket open on this. > > Loren >
Re: user_prefs rules throwing errors
Jim Smith wrote: Welcome to the club. Gee it's such an honor to be part of that club . This has been a slippery thing for me as well. If I restart SA, it will go away for a while and those rules will work correctly for approx 6-12 hours. When it starts misbehaving, I can take the two rules out and it works fine. Put them back in, and it chokes immediately. Restart and I get another several hours of trouble-free operation. Since I'm stuck inside today due to the blizzard in Connecticut, I've had lots of time to swap rules in my procmail & user_prefs file in & out until I was able to narrow the error down to those two rules. I'm not familiar with BZ but let me know if my info can help out. Please add yourself to the CC: list on this bug. http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3838 Also, if you can _attach_ a copy of the rules causing the problem to the bug and comment on exactly which versions you see the problem, and which you don't see the problem (with these rules). Further, if you can attach a copy of a message that triggers the problem with these rules, there's a far better chance of it getting fixed. Thanks, Daryl
