[Mimedefang] Passing username to SpamAssassin for user preferences

[Caruso, Anthony J.]

All:

With the new SQL features in SA3, I was wandering if anyone has explored
passing 'username' to SpamAssassin (SA) via the spam_assassin_init(;$)
subroutine in mimedefang.pl (similar to using -u in spamd)?  [A question
regarding how to pass username was posed 6/23/03, with no answer].  I am
working on enhancing our install and users' interaction w/ spam filtering
(like prefs, false positive recovery, and maybe even per-user basian rules).

Since MimeDefang (MD) is running under the 'defang' user, SA won't be able
to determine the correct username for a message (at least that's the way I
read Mail::SA).

_________________________
My Goals:
Each users can specify their config info via a web interface to the database
(similar to the "Using SQL" paper in the SA Wiki).
Multiple domains are supported
User's don't need accounts on the box (all virt users, etc).

The reason for letting SA handle this is for whitelist/blacklist, rbl checks
etc.  Though I think the SA threshold cannot be controlled through this
mechanism since SA really cannot manipulate the message (that's MD's job).

_________________________
My thoughts:
1.  Change prototype spam_assassin_is_spam(;$) to take 2 optional arguments
(or remove the prototype - eeek!)
2.  Change each subsequent prototype for 
	spam_assassin_check
	spam_assassin_status
	spam_assassin_init
3.  In spam_assassin_init, define username => $optionallyPassedUsername in
the new method of MAIL::SpamAssassin
4.  Then, from mimedefang-filter, we can call spam_assassin_check (username,
configfile) (or vise versa).

This should allow the SQL definitions in the SA configfile to be used for
looking up userprefs and let SA do the math for each config option.

I've already defined the schema for my db, and parts of the web interface.
Now I am working on the username part of the problem.

_________________________
Questions:
1.  Is mimedefang.pl the best place to make these modifications?
2.  If this were to become part of the standard MD, are any of the core
developers opposed to the placement of these modifications?
3.  Anyone got better ideas?

Thanks in advance.

-Tony


This email message and any attachments are for the sole use of the intended recipient(s) and contain confidential and/or proprietary information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.