On Sun, 2011-10-16 at 13:39 -0400, Brian J. Murrell wrote: > On 11-10-16 01:31 PM, Martin Gregorie wrote: > > > > Have you thought of running spamc remotely? This way you could avoid the > > need to login the the server just to process mail. > > Hrm. I'm not sure I follow. The server receives the mail and the > server delivers it to the user's mailbox but on the way it passes > through spamd by way of a call to spamc -- all on the server. > Yep. A brainfart on my part.
> Right. But since I have spamc being called from procmail, they are all > running as the effective user anyway and thus the -u is moot (and > wouldn't work for any value other than the current user anyway). > OK - if the MTA runs spamc (Postfix does this via a service defined as part of its configuration - others MTAs have a similar ability) the -u facility can be used to select the preference file much as it does now, but procmail isn't needed and you'd run a POP server (I like Dovecot 0- zero maintenance: it Just Works) that users use to collect their mail and their MUA can sort mail into spam folders, etc. on their local machines. That only leaves user preferences. Put them where spamd expects to find them, and add a symlink to the user's NFS mount point on the server. This way the mail system works regardless of whether the users are logged in or not and they can edit their preferences same as now when they are connected via NFS. Of course, this assumes that all the procmail recipe does is to run spamc, but you haven't said it does anything else. > Sure, but the problem is in being able to provide spamd with a directory > outside of the users $HOME for his .spamassassin dir. > Use a symlink - see above. Martin
