Bug 1145 - RFE: ConfSourceSQL user configs without spamd
Summary: RFE: ConfSourceSQL user configs without spamd
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Libraries (show other bugs)
Version: unspecified
Hardware: Other other
: P2 enhancement
Target Milestone: Future
Assignee: SpamAssassin Developer Mailing List
Depends on:
Reported: 2002-10-23 13:19 UTC by Daniel Rogers
Modified: 2018-09-04 15:46 UTC (History)
3 users (show)

Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Rogers 2002-10-23 13:19:14 UTC
I was trying to set up SQL-based whitelisting yesterday and discovered that SQL
based per-user configs are only available when using spamd.  As we are using
MIMEdefang, this doesn't work for us.

Has no one every wanted this, or is there some reason why SQL configs shouldn't
be available when just using regular spamassassin from the command line or as a
perl module?

Comment 1 Sidney Markowitz 2002-10-23 21:15:27 UTC
This has been discussed on the MIMEDefang mailing list. Because MIMEDefang is a 
milter, it catches the message before alias expansion and before sendmail has 
made a separate copy for each final recipient. There is a sub in MIMEDefang 
that you can use to apply a functoin per recipient, but that would have two 
problems: 1) It causes a lot more processing as sendmail is invoked again over 
the whole message once for each envelope recipient; and 2) It still is 
happening before alias expansion.

David Skoll, the author of MIMEDefang has a commercial product, CanIt-Pro, that 
he says deals with the problems involved and allows MIMEDefang to be used with 
an SQL database of per-user information. But the solution has to be at the 
milter level, and cannot be in SpamAssassin.
Comment 2 Daniel Rogers 2002-10-23 23:07:46 UTC
Well, _sort_ of...

I didn't actually want per-user configs, I just wanted to be able to use @GLOBAL
configs, which should work, as they aren't limited to a particular user.

However, SA doesn't have any capability for SQL, except through spamd.

Comment 3 Duncan Findlay 2002-12-24 20:46:03 UTC
WONTFIX? Definitely not 2.50
Comment 4 Daniel Rogers 2002-12-30 09:22:44 UTC
Out of curiousity, would it be that difficult to move this functionality from
spamd into spamassassin proper?
Comment 5 Justin Mason 2003-02-03 04:57:16 UTC
not really, actually.   But it would definitely take some thought and redesign,
so  it'll have to wait.
Comment 6 Arlo Gilbert 2003-10-16 14:26:18 UTC
actually it's quite easy to fix.

i just posted this on the spamassassin talk list, i assumed it was a bug and took it upon myself to 
fix it.

i'll repost it here:

Spamassassin.pm has a non public sub called init that is called internally from the "check" sub. init 
checks to see if the config files have been loaded yet. If they have been loaded it then proceeds on 
to screen the message for spam. If a config file has not been loaded, it loads it and overwrites any 
custom mail::spamassassin::conf variables with the defaults and the values from the config file. 
Thus the following code is ineffective.

	my $spamtest = Mail::SpamAssassin->new();
	my $status = $spamtest->check($msg);
	      $status->finish ();

by manually calling the non public "init" function via $spamtest->init(1); as show below, one 
forces spamassassin to load the config file and all defaults, then the load_scoreonly_sql function 
loads the appropriate rules and user prefs that are stored in the database. failure to do init(1) prior 
to load_scoreonly_sql results in mysql data being overridden by defaults and config file data.

	my $spamtest = Mail::SpamAssassin->new();
	my $status = $spamtest->check_message_text($msg);
	      $status->finish ();
Comment 7 Justin Mason 2004-02-28 14:02:01 UTC
Upping pri and hoping that Michael will take a look. ;)
Comment 8 Justin Mason 2004-02-28 14:02:26 UTC
changing title.
Comment 9 Duncan Findlay 2004-11-30 19:18:15 UTC
Assigning to Michael, since this is his domain...
Comment 10 Michael Parker 2005-02-18 11:43:26 UTC
Assign back to dev, so someone can feel free to pick it up and work on it.
Comment 11 Daniel Quinlan 2005-03-30 01:08:29 UTC
move bug to Future milestone (previously set to Future -- I hope)
Comment 12 Daniel Rogers 2005-03-30 08:57:30 UTC
Yes, among other things.  :)
Comment 13 AXB 2007-10-31 05:44:16 UTC
If someone has time & energy, could this RFE be considered/reactivated.

Having SQL config using spamassassin (instead od spac/spad) would have often
come in real handy (low traffic systems, dev work, embedded situations, etc)


Comment 14 Kevin A. McGrail 2011-10-28 15:42:14 UTC
This is a good idea to add to SA, however, I use SQL-based prefs all the time using MIMEDefang by calling spamc from MD. 

I based my implementation on this information http://web.archive.org/web/20070425080055/http://www.mimedefang.org/kwiki/index.cgi?SpamassassinSpamcSpamd

Targeting this to 3.4.1.
Comment 15 Mark Martinec 2011-10-28 19:25:43 UTC
> This is a good idea to add to SA, however, I use SQL-based prefs
> all the time using MIMEDefang by calling spamc from MD. 

Btw, SQL-based SpamAssassin prefs are also available with amavisd
since version 2.7.0 (@sa_userconf_maps and @sa_username_maps).

> Targeting this to 3.4.1.

Comment 16 Kevin A. McGrail 2015-04-13 22:57:07 UTC
Pushing to 3.4.2.

But the original problem is fixed.  The enhancement request is to have spamassassin itself (not via API and not via spamc/spamd) able to pull user prefs via sql.

I've never actually checked or needed that since I consider it really part of the setuid part of the spamd service.

But it's an interesting request.

First, it implies that your local.cf is readable by any user including your db credentials.  But perhaps you are running this for testing as the user who owns that file.

Second, we need a param of --sql-user and a function like handle_user_sql that just load_scoreonly_sql for the user specified.  I believe that will only give you the required score threshold.

Is that what you are looking to get?
Comment 17 Kevin A. McGrail 2018-09-04 15:46:29 UTC
Pushing to future release as it's an enhancement and the original ticket issue is handled.