sa-learn --ham not running from horde/imp.

[Sahil Tandon <sa...@hamla.org>]

I understand my problem might be rooted in Horde, amavisd-new, or 
Postfix.  However, I want to be sure it's not a fundamental 
misunderstanding (on my part) of how SA should be setup.

Postfix filters mail via amavisd-new (which calls SA).  Everything runs 
smoothly except the "Report as Spam" link for users viewing messages via 
webmail.  When clicked, it successfully sends a message to postmaster, 
and unsuccessfully calls sa-learn.  This is what I see in my logs (sorry 
for line wraps):

lock: 94539 cannot create tmp lockfile 
/root/.spamassassin/bayes.lock.sphinx.hamla.org.94539 for 
/root/.spamassassin/bayes.lock: Permission denied
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
         LC_ALL = (unset),
         LANG = "en_US"
     are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
bayes expire_old_tokens: lock: 95562 cannot create tmp lockfile 
/root/.spamassassin/bayes.lock.sphinx.hamla.org.95562 for 
/root/.spamassassin/bayes.lock: Permission denied

lock: 95562 cannot create tmp lockfile 
/root/.spamassassin/bayes.lock.sphinx.hamla.org.95562 for 
/root/.spamassassin/bayes.lock: Permission denied

The relevant line in my IMP conf.php:

$conf['spam']['program'] = '/usr/local/bin/sa-learn --spam';

I googled for the error but cannot find a proper solution.  Right now, 
/root/.spamassassin is a symlink to /var/amavis/.spamassassin; the files 
therein (i.e. the bayes_* files) are chown'd vscan:vscan.  They are 
updated when SA *itself* notices spam above a certain threshold, rejects 
those messages, and auto-learns their spammy existence.

How to get 'sa-learn --spam' from webmail to co-exist peacefully with my 
current setup?

--
Sahil Tandon

Re: sa-learn --ham not running from horde/imp.

[Thomas Bolioli <tp...@terranovum.com>]

What is likely happening is that sa-learn is running as root, with 
nobody's permissions since apache su's itself to nobody by default on RH 
9/FC1 (I am assuming this version of linux from the LC_ALL/LANG issue, 
although mac osx is a possibility). When you click the link in horde, it 
is executing that code ('/usr/local/bin/sa-learn --spam') as the user 
that the webserver is running under (nobody), not the user you are 
logged into horde with (sahil?). Therfore, you are not actually learning 
against the user's (sahil) bayes db. When apache su's to nobody, it 
looses rights to root's resources but su is notorius for not fully 
assuming the su'd (nobody) persona. Part of that is intentional, part of 
it is not. That is why sa-learn is picking up root's id as the one to 
try and run under but fails to have the required perms to accomplish 
anything. Oh yeah, I forgot to elucidate that sa-learn figures out the 
.spamassassin directory from the currently logged in user's home dir as 
reported by the env vars. Those are effected by su'ing to a new user. 
One example is that the 2.6X versions do not run properly under sudo but 
do under su. The reason, although I have never looked into it directly, 
are likely the difference between the behavior of su and sudo in how 
they set env variables.
Possible fixes:
1) don't use hordes reporting util (recommended)
2) run the webserver as root and use the command ('su -c 
/usr/local/bin/sa-learn --spam $user' or something like it. Do man su or 
su --help for more info) where $user is horde's global variable for the 
currently logged on user. (*NOT* recommended. Major security issues there)
3) attempt to run the command from 2 under the su'd nobody user. It may 
work since sometimes su is broken depending on your build of perl, etc 
(although it has been 6 months since I used RH, I do not believe their 
stock perl build was broken). It may revert to the parent processes 
rights instead of seeing nobody and su without a password needed. This 
is highly unlikely of working but it is worth a shot. It will take no 
time to try and can't hurt if it works. Since if it works, you have 
bigger problems that you can do little to fix. Although I stress, I do 
not think it will work.
I hope that helps,
Tom

Sahil Tandon wrote:

> I understand my problem might be rooted in Horde, amavisd-new, or 
> Postfix.  However, I want to be sure it's not a fundamental 
> misunderstanding (on my part) of how SA should be setup.
>
> Postfix filters mail via amavisd-new (which calls SA).  Everything 
> runs smoothly except the "Report as Spam" link for users viewing 
> messages via webmail.  When clicked, it successfully sends a message 
> to postmaster, and unsuccessfully calls sa-learn.  This is what I see 
> in my logs (sorry for line wraps):
>
> lock: 94539 cannot create tmp lockfile 
> /root/.spamassassin/bayes.lock.sphinx.hamla.org.94539 for 
> /root/.spamassassin/bayes.lock: Permission denied
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
>         LC_ALL = (unset),
>         LANG = "en_US"
>     are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
> bayes expire_old_tokens: lock: 95562 cannot create tmp lockfile 
> /root/.spamassassin/bayes.lock.sphinx.hamla.org.95562 for 
> /root/.spamassassin/bayes.lock: Permission denied
>
> lock: 95562 cannot create tmp lockfile 
> /root/.spamassassin/bayes.lock.sphinx.hamla.org.95562 for 
> /root/.spamassassin/bayes.lock: Permission denied
>
> The relevant line in my IMP conf.php:
>
> $conf['spam']['program'] = '/usr/local/bin/sa-learn --spam';
>
> I googled for the error but cannot find a proper solution.  Right now, 
> /root/.spamassassin is a symlink to /var/amavis/.spamassassin; the 
> files therein (i.e. the bayes_* files) are chown'd vscan:vscan.  They 
> are updated when SA *itself* notices spam above a certain threshold, 
> rejects those messages, and auto-learns their spammy existence.
>
> How to get 'sa-learn --spam' from webmail to co-exist peacefully with 
> my current setup?
>
> -- 
> Sahil Tandon

spamc/spamd or spamassassin

[Roel Bindels <ro...@protomation.com>]

Hello,

I installed the new version 3.0.0 of SA. I tried to run as spamd/spamc but
somehow there is no flag in the mailheader that indicates it has beeing
checked.

When I changes the spamc call in procmailrc to spamassassin then it all
works fine. Has anyone an idea what this problem could be

In the mail log I can see that with the spamd/spamc the mail is beeing
checked. but all messages are clean.(what's incorrect)

I really want to change my setup to the spamd/spamc config, so any ideas are
welcome.

greetings
Roel Bindels

Re: sa-learn --ham not running from horde/imp.

[sa...@hamla.org]

Quoting Matt Kettler <mk...@comcast.net>:

> I assume you've got some bayes_path statement in your local.cf forcing SA
> to use that path. Note: if it's set to /root/* I'd suggest changing it to
> /var/amavis/*, unless you want to make root's homedir world-readable.

I do not set bayes_path in local.cf; I will do so tonight, and define it as
/var/amavis/.spamassassin/.

> Note: this process will cause your bayes DB to change ownership randomly.
> It shouldn't matter as long as the file remains world rw, which it should
> with the bayes_file_mode setting in place.

That's fine.  I would like users to "Report as Spam" any messages they deem
nefarious, and then (ideally) SA will use the updated DB to block future spam
with similar attributes.  Per-user DB's are not necessary as I don't want to
throw mysql into the mix just yet.

Thanks for your advice - will try it out tonight and report the results.

--
Sahil Tandon

Re: sa-learn --ham not running from horde/imp.

[Matt Kettler <mk...@comcast.net>]

At 11:37 PM 10/12/2004 -0400, Sahil Tandon wrote:
>I googled for the error but cannot find a proper solution.  Right now, 
>/root/.spamassassin is a symlink to /var/amavis/.spamassassin; the files 
>therein (i.e. the bayes_* files) are chown'd vscan:vscan.  They are 
>updated when SA *itself* notices spam above a certain threshold, rejects 
>those messages, and auto-learns their spammy existence.
>
>How to get 'sa-learn --spam' from webmail to co-exist peacefully with my 
>current setup?

I assume you've got some bayes_path statement in your local.cf forcing SA 
to use that path. Note: if it's set to /root/* I'd suggest changing it to 
/var/amavis/*, unless you want to make root's homedir world-readable.

when doing a single global bayes DB, add the following config option to SA:

          bayes_file_mode 777

Note that it's a mask and it's used in making directories, so it should be 
777 not 666. SA won't make the bayes DB executable, but it will add the x 
bit to temp directories.

 From there, be sure the directory is world rwx and the directories above 
are at least world r_x.

Lastly, chmod 666 the bayes_* files.

Note: this process will cause your bayes DB to change ownership randomly. 
It shouldn't matter as long as the file remains world rw, which it should 
with the bayes_file_mode setting in place.