> Why do we need to authenticate the user of spamc at all? Are we
> worried about a remote user running spamc on their box and forging mail
> through ours? A local user forging something through our box?
I think this was mentioned in an earlier thread, but as I understand it,
the worry is that a local system user could call spamc with the -u option
to specify a different uid than his/her own, and thus do things like
delivering spam, or inflating auto whitelists so they will accept mail
from spammers.
Purely a malicious thing...
anyway, while on this topic of modifying spamc, can we PLEASE make it have
some way of passing certain info to spamd that it doesn't? Maildrop
(which is about as common as procmail these days, or at least getting to
be so) passes $ENV{HOME} into its xfilters (external scripts) so that
virtual users or users whose mail homedirs and user homedirs are different
can actually get things delivered properly.
my example: I have a bunch of virtual users living in
[EMAIL PROTECTED] - all owned by apache. If I turn
spamassassin on globally, it looks at who owns the spamc process, which is
apache, and then grabs /var/www as its homedir (which is owned/writable by
root, NOT apache). Anyway, security's not an issue since you would just
have to make sure that the calling user owns the destination home
directory (which you should be doing anyway).
And yes, I would contribute a patch for this, but I'm a perl coder, not a
C coder (I'm more than happy to patch spamd, but it wouldn't do any good
without matching spamc support).
-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
