Another call for improvements

[Ken A]

Dhawal Doshy wrote:
> Ken A wrote:
>> I know you just got back from vacation, so please take it easy and 
>> file this somewhere deep in the pile.. :-)
>>
>> Per user S.A. scores would be nice. There are times when whitelisting 
>> isn't enough, especially as mail from .CN continues to be both very 
>> spammy and increasingly more necessary for business. :-\
> 
> Ken, have a look at the 'SQLSpamSettings.pm' from the mailwatch 
> project.. you do not have to use mailwatch to use this module unless you 
> need a front-end to manage the scores.. even if you use the front-end 
> you do not have to use the SQL Logging function from mailwatch, which 
> tends to get resource hungry.

This looks to be an SQL implementation of a .rules file, and very handy 
for building front-ends to manage the HIGH/LOW spam thresholds, but not 
really what I'm looking for. I want to be able to set per user scores on 
every rule in SA, similar to what's possible using SA alone.

The Mail::SpamAssassin API allows an optional $userprefs_filename 
parameter that contains the path to a per user S.A. prefs file, but I'm 
not sure what would be involved in using this with MailScanner, or if 
it's even possible with MailScanner.

Thanks,
Ken A.
Pacific.Net


> There is also a per-user / per-domain blacklist/whitelist module 
> available if you require one.
> 
> - dhawal
> 
>> Thanks,
>> Ken A.
>> Pacific.Net
>>
>> Julian Field wrote:
>>> Any of you got any features which you really need?
>>> I don't guarantee to implement them, or even consider them :-)
>>>
>>> Anything you don't like, anything you particularly like (gratitude is 
>>> always welcome :-) I'm a right sucker for it :-)
>>>
>>> At the moment there aren't any features people want, other than a 
>>> 200% speed improvement which I've done my best for in the past.
>>>
>>> Don't ignore anything you have asked for in the past, consider them 
>>> forgotten :-(
>>>
>>> Regards,
>>> Jules.