You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by li...@nerdbynature.de on 2011/11/11 08:27:14 UTC

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!

Re: spamd, postfix & user_prefs

Posted by li...@nerdbynature.de.
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 test@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: spamd, postfix & user_prefs

Posted by David B Funk <db...@engineering.uiowa.edu>.
On Thu, 10 Nov 2011, lists@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
<dbfunk (at) engineering.uiowa.edu>        College of Engineering
319/335-5751   FAX: 319/384-0549           1256 Seamans Center
Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{

Re: spamd, postfix & user_prefs [Can you use fetchmail->procmail->maildir?]

Posted by Noel <no...@gmail.com>.
On 11/11/2011 10:56 PM, lists@nerdbynature.de wrote:
> On Fri, 11 Nov 2011 at 12:03, Martin Gregorie wrote:
>>> Using "per user" AS configuration by receiving MTA is "tricky",
>>> consider e.g. message to multiple local recipients.
> I don't have that many local users on the system and incoming mail is 
> hardly ever addressed to more than one local user. But I'd expect postfix 
> to figure this out and deliver the mail to each user separately, thus 
> allowing for "per user" mail filtering.

You'll need to tell postfix to deliver one recipient at a time to
your filter with "foo_destination_recipient_limit = 1" where foo is
the name of the master.cf transport.  See postfix docs or the
postfix-users list for details. 

>>> Have you considered the following setup?
>>> * fetchmail fetches mail from a remote server,
>>> * fetchmail passes email to procmail script (see "mda" option)
>>> * procmail script does AV and AS scans
>>> * procmail delivers the mail to user's Maildir
> Yeah, I had this before but was using maildrop instead of procmail. But I 
> suspected performance issues with this setup and decided that I want 
> postfix to call all the filters (AV/AS).

Since the majority of delivery processing time is spent doing the
AV/AS filtering, I wouldn't expect much performance difference by
moving those same processes to a different point in the delivery chain.



   -- Noel Jones

Re: spamd, postfix & user_prefs [Can you use fetchmail->procmail->maildir?]

Posted by li...@nerdbynature.de.
On Fri, 11 Nov 2011 at 12:03, Martin Gregorie wrote:
> > Using "per user" AS configuration by receiving MTA is "tricky",
> > consider e.g. message to multiple local recipients.

I don't have that many local users on the system and incoming mail is 
hardly ever addressed to more than one local user. But I'd expect postfix 
to figure this out and deliver the mail to each user separately, thus 
allowing for "per user" mail filtering.

> > Have you considered the following setup?
> > * fetchmail fetches mail from a remote server,
> > * fetchmail passes email to procmail script (see "mda" option)
> > * procmail script does AV and AS scans
> > * procmail delivers the mail to user's Maildir

Yeah, I had this before but was using maildrop instead of procmail. But I 
suspected performance issues with this setup and decided that I want 
postfix to call all the filters (AV/AS).

> BTW, in my experience getmail is a superior drop-in replacement for
> fetchmail and can even use the same MDA script.

fetchmail served me well in all those years, but I just read the 
getmail-FAQ, maybe I should reconsider :-)

Thanks to both of you,
Christian.

[0] http://pyropus.ca/software/getmail/faq.html#faq-about-why
-- 
BOFH excuse #178:

short leg on process table

Re: spamd, postfix & user_prefs [Can you use fetchmail->procmail->maildir?]

Posted by Martin Gregorie <ma...@gregorie.org>.
On Fri, 2011-11-11 at 10:56 +0100, Andrzej Adam Filip wrote:
> lists@nerdbynature.de wrote:
> > [...]
> > 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.
> > [...]
> 
> Using "per user" AS configuration by receiving MTA is "tricky",
> consider e.g. message to multiple local recipients.
> 
> Have you considered the following setup?
> * fetchmail fetches mail from a remote server,
> * fetchmail passes email to procmail script (see "mda" option)
> * procmail script does AV and AS scans
> * procmail delivers the mail to user's Maildir
> 
> I use extended variant of the above configuration for years.
> [Main change avoids delaying email fetching by AV/AS scans.]
> 
You don't need procmail in this setup: fetchmail can run in 'multi-user
mode', which means that it runs the MDA chain for the mail recipient.
 
IIRC the OP will be using the MDA chain anyway, even if it its used
merely to call sendmail (the Postfix version) to send the mail to
localhost:25. Its easy to put spamc as the first command in the MDA and
to pipe its output to sendmail for dispatch to Postfix.

BTW, in my experience getmail is a superior drop-in replacement for
fetchmail and can even use the same MDA script.
 

Martin



Re: spamd, postfix & user_prefs [Can you use fetchmail->procmail->maildir?]

Posted by Andrzej Adam Filip <an...@gmail.com>.
lists@nerdbynature.de wrote:
> [...]
> 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.
> [...]

Using "per user" AS configuration by receiving MTA is "tricky",
consider e.g. message to multiple local recipients.

Have you considered the following setup?
* fetchmail fetches mail from a remote server,
* fetchmail passes email to procmail script (see "mda" option)
* procmail script does AV and AS scans
* procmail delivers the mail to user's Maildir

I use extended variant of the above configuration for years.
[Main change avoids delaying email fetching by AV/AS scans.]

-- 
[pl>en: Andrew] Andrzej Adam Filip : anfi@onet.eu
Boys are beyond the range of anybody's sure understanding, at least
when they are between the ages of 18 months and 90 years.
  -- James Thurber