Spamassassin emails have wrong perms

[Justin Willmert]

jdow wrote:
> From: "Justin Willmert" <justin at jdjlab.com>
>
>> akonstam at trinity.edu wrote:
>>> On Sun, Jan 29, 2006 at 06:25:42PM -0600, Justin Willmert wrote:
>>>  
>>>> I am hoping somebody can help me solve a problem I am having with 
>>>> procmail and spamassassin (specifically spamd). When spamassassin 
>>>> has marked a message as spam, it gets sorted to a Junk folder, but 
>>>> the problem is that it is owned by root:mail when it should be 
>>>> owned by the user. When this happens, dovecot will not serve the 
>>>> email to the user. I sort other emails into folders with simple 
>>>> matching rules and those work fine. Spamassassin is the only rule 
>>>> that is piped out to a program.
>>>>     
>>> This is sort of a side comment but using spamd with .procmailrc is not
>>> the best approach in my opinion. I beleve the .procmailrc below
>>> provides a better way to do this. The INCLUDERC line runs the
>>> spamassassin program. Spamd should be turned off if you do this.
>>>
>>> PATH=$HOME/bin:/usr/bin:/global/bin:/usr/ucb:/bin:/usr/local/bin:
>>> SHELL=/bin/sh
>>> MAILDIR =       $HOME/Mail      # You'd better make sure it exists
>>> LOGFILE =       $MAILDIR/procmail.log
>>> LOCKFILE=       $HOME/.lockmail
>>>
>>>
>>> #:0c
>>> #!  akonstam at sbcglobal.net
>>>
>>> INCLUDERC=/etc/mail/spamassassin/spamassassin-default.rc
>
> <<<shudder>>>
>
>>> :0
>>> *^Subject:.*\[SPAM\] spamjunk
>>>
>>> :0
>>> *^To:.*fedora-list at redhat.com fedora
>>>
>>> :0
>>> *^To:.*fedora-test-list at redhat.com fedora-test
>>>   
>> Using spamassassin rather than spamc gets around the SELinux issues, 
>> but I've read there are performance gains if you use spamd. I guess 
>> using spamassassin will work for me (my server isn't anywhere near 
>> being maxed out), but I think it'd be a good idea to resolve this 
>> issue for others to use later. I'm going to leave this open for a 
>> while, and if nothing comes of it, I'll post my results to both lists 
>> like I mentioned in another message.
>
> How are you running spamassassin? Are you using anything like amavis?
> If you have only procmail involved in the issue and use it on a per user
> basis then it's really easy to handle.
>
> $HOME/mail/spamjunk
>
> As an example the above disposition line feeds the email to the user's
> mail/spamjunk mbox file. Some appropriate rule ahead of the disposition
> will tell procmail what to send to that folder.
>
> I start my per user .procmailrc file with:
> DROPPRIVS=yes
> LOGNAME=procmail
>
> I include likes like:
> :0:
> * ^From: Postmaster at intellitron.com.au
> /dev/null
>
> :0:
> * ^From: AntiSpam UOL <.*@uol.com.br>
> #/dev/null
> /$HOME/mail/uol_crap
>
> Then I call SpamAssassin with a more complex variant of:
> :0
> * < 500000
> * !^List-Id: .*(spamassassin\.apache.\org)
> | /usr/bin/spamc -t 150 -u jdow
>
> Then I'm done with all mail being delivered to the mail folder and sorted
> by up in the reader with an OE rule for spam.
>
> Note that I pull down mail via a fetchmail, one fetchmail per actual user
> regardless of the number of email accounts that are being fetched from.
>
> {^_^}
> {^_^}
>
No, I'm not using amavis (not exactly sure what it is, but a quick 
search of my HD shows nothing that would be executable (a logwatch 
script and selinux policy is all I found). I right now am just calling 
the /usr/bin/spamassassin. I see that you are using spamc. Do you use 
SELinux on your computer? Do you have your users authenticate through a 
LDAP database (at the system level, not for only spamassassin)? I tried 
using spamc earlier, but I have problems with spamassassin not being 
able to setuid to my users and not being able to connect to the ldap 
port (selinux blocked spamassassin's access to ldap_port_t).

Thanks for the help,
Justin