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. > spamc takes -d -p and -u options, which should do exactly what you want: > -d gives the host name (default is localhost) > -p is the port (default 783) > -u is the username 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). > This way you can go on calling spamc from the procmail recipe so it > would remain invisible to the users. Sure, but the problem is in being able to provide spamd with a directory outside of the users $HOME for his .spamassassin dir. > You'd store user preferences on the server as individual files Which is what I want to do, outside of their usual $HOME which actually lives on their own machine and is NFS mounted on the server (currently). > or in a > MySQL database as others have described. Yeah, just not interested in doing that much re-engineering when simply being able to provide spamd with a different path for ~/.spamassassin should suffice. > The worst case would be that > your users may have to log in to the server to change their preferences, Well, they will get their ~/.spamassassin dir as an NFS mount from the server, so same difference really. > unless, that is, you go the MySQL way and provide, say, a simple PHP > script to maintain them via an in-house Apache web server. Yeah, not going there. It's overkill and too much work to achieve what I want. I do appreciate the suggestions though. b.
signature.asc
Description: OpenPGP digital signature
