SA Bugzilla – Bug 1145
RFE: ConfSourceSQL user configs without spamd
Last modified: 2018-09-04 15:46:29 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? Dan.
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.
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. Dan.
WONTFIX? Definitely not 2.50
Out of curiousity, would it be that difficult to move this functionality from spamd into spamassassin proper?
not really, actually. But it would definitely take some thought and redesign, so it'll have to wait.
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(); $spamtest->load_scoreonly_sql($username); my $status = $spamtest->check($msg); $status->rewrite_mail(); $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(); $spamtest->init(1); $spamtest->load_scoreonly_sql($username); my $status = $spamtest->check_message_text($msg); $status->rewrite_mail(); $status->finish ();
Upping pri and hoping that Michael will take a look. ;)
changing title.
Assigning to Michael, since this is his domain...
Assign back to dev, so someone can feel free to pick it up and work on it.
move bug to Future milestone (previously set to Future -- I hope)
Yes, among other things. :)
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) thx Alex
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.
> 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. Ok.
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?
Pushing to future release as it's an enhancement and the original ticket issue is handled.