RE: [Mimedefang] Passing username to SpamAssassin for user prefer ences
David: All good points, thanks. The idea of creating my own SA object is one of those obvious things overlooked as one digs through the weeds of the code. Duh! Thanks for the input. -Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David F. Skoll Sent: Monday, November 01, 2004 7:40 AM To: '[EMAIL PROTECTED]' Subject: Re: [Mimedefang] Passing username to SpamAssassin for user preferences On Sun, 31 Oct 2004, Caruso, Anthony J. wrote: > 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). Well, that's why we sell CanIt-PRO! :-) > My thoughts: > 1. Change prototype spam_assassin_is_spam(;$) to take 2 optional arguments > (or remove the prototype - eeek!) I don't plan on making any changes to the spam_assassin functions. If you want this level of control, simply create your own Mail::SpamAssassin object and manipulate it directly. > 1. Is mimedefang.pl the best place to make these modifications? Not as far as I'm concerned. > 2. If this were to become part of the standard MD, are any of the core > developers opposed to the placement of these modifications? Yup. This can be done in the filter without any changes to mimedefang.pl. And while I'm happy to release MIMEDefang under the GPL, these sorts of changes are uncomfortably close to eating into CanIt and CanIt-PRO territory. Unfortunately, we have to make a living too. :-) Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang This email message and any attachments are for the sole use of the intended recipient(s) and contain confidential and/or privileged 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. 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. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Passing username to SpamAssassin for user preferences
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. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
