Bug 1145

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.