|Summary:||RFE: specifiy a user_prefs file location via spamc -z|
|Product:||Spamassassin||Reporter:||Andrew Ott <aott>|
|Component:||spamc/spamd||Assignee:||SpamAssassin Developer Mailing List <dev>|
|Bug Depends on:||5138|
Patch to spamd.raw
Patch to spamc.c
Patch to libspamc.c
Patch to libspamc.h
Description Andrew Ott 2005-06-15 14:03:26 UTC
I'm using the Courior mail system, and it is running spamc from a xfilter rule in the .mailfilter file that is in each users directory. This puts the user_prefs file in /home/"webaccountname"/popaccounts/"domainname"/"emailusername"/.spamassassi n/userprefs this makes it imposible to do a --virtual-config-dir so what i did is patched spamc and spamd to handle spamc passing a user_prefs directory to spamd to use. This adds a --spamc-configs option to spamd so it knows to use the directory from spamc and when calling spamc it adds a -z path-to- user_prefs-file option. This also adds a UserPrefs section to the protocal. I would really like to see this in the upcoming versions of spamassassin, as I think it would be usefull for some people. I will attach the patch files against the 3.0.4 source to this message. Thank you.
Comment 5 Michael Parker 2005-06-15 14:11:37 UTC
Subject: Re: Allowed to specifiy a user_prefs file location via spamc >------- Additional Comments From firstname.lastname@example.org 2005-06-15 14:06 ------- >Created an attachment (id=2939) > --> (http://bugzilla.spamassassin.org/attachment.cgi?id=2939&action=view) >Patch to libspamc.c > > This breaks binary compatibility and is not complete, you'll have to pass things along for learning/reporting as well. Michael
Comment 6 Bob Menschel 2005-07-03 18:27:34 UTC
Triage: Per Michael's comment, this is complex enough to warrant a provisional 3.2 target.
Comment 7 Justin Mason 2006-10-19 06:38:26 UTC
I would prefer to implement bug 5138. Once that's done, that allows clean implementation of this bug; if the plugin APIs can read random headers from the request, and if spamc was extended to allow a random header (something like "UserMetadata: foo") to be set from a spamc command line switch, then you could do something like - spamc -z /path/to/whatever - request contains UserMetadata: /path/to/whatever - plugin reads that "UserMetadata" header from the request, and uses it to find user_prefs file anyway, right now this isn't planned (patches welcome), so setting milestone to Future.