Bug 4405

Summary: RFE: specifiy a user_prefs file location via spamc -z
Product: Spamassassin Reporter: Andrew Ott <aott>
Component: spamc/spamdAssignee: SpamAssassin Developer Mailing List <dev>
Status: NEW ---    
Severity: enhancement    
Priority: P2    
Version: 3.0.4   
Target Milestone: Future   
Hardware: All   
OS: Linux   
Whiteboard:
Bug Depends on: 5138    
Bug Blocks:    
Attachments: 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 1 Andrew Ott 2005-06-15 14:05:05 UTC
Created attachment 2937 [details]
Patch to spamd.raw
Comment 2 Andrew Ott 2005-06-15 14:05:36 UTC
Created attachment 2938 [details]
Patch to spamc.c
Comment 3 Andrew Ott 2005-06-15 14:06:06 UTC
Created attachment 2939 [details]
Patch to libspamc.c
Comment 4 Andrew Ott 2005-06-15 14:06:36 UTC
Created attachment 2940 [details]
Patch to libspamc.h
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 aott@actcom.net  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.