Hi Jeffrey, > I don't want to run Spamassassin for all users in every domain (i.e., > spamproxyd). I also would prefer that Sendmail do it's MTA > job. The key here is, I want to be able to easily configure the > Spamassassin service for multiple virtual domains, and I want it to > be as efficient as possible in the process. Anyone have this? > If not, I'll proceed working on: > - Sendmail 8.12.2 > - Spamc & Spamd > - Me writing a Sendmail milter filter that does the above
I think you should have a look at mimedefang (http://www.roaringpenguin.com/mimedefang/), it'll help with several of the things you'd need: - sendmail 8.12.2 - uses a concept like spamd/spamc, (mimedefang-multiplexor) - added possibilities: remove attachments, mangle filnames and mimetypes based on file extensions and/or mime types (think .vbs/.shs/.com/.exe/.scr....), virus scanner integration mimedefang is written in perl as well and interfaces with spamassassin using Mail::Spamassassin directly. When using the mimedefang-multiplexor, it manages a bunch of preloaded perl processess to do the actual work. The one part that's still missing with this is having the functionality configurable per user. Adding this will be trickier than a simple database lookup: since a message can be for several recipients and these recipients can have different preferences, a message to several recipients would have to be resent once for each recipient with only these copies being actually scanned for spam (and the original has to be discarded). there's an example with wimedefang on how to do this based on domain instead of recipient, but it should be fairly straightforward to adapt. I have a similar setup myself, but with a smaller userbase so I decided to treat it somewhat differently: a) using a milter interface, you get the chance to not only modify/tag spam mail but also to actually bounce it at the SMTP level. I think this is much preferable to dropping/deleting mail afterwards in the delivery process because you don't get a "black hole" effect - esp. in case of false positives. The sender gets a clean error message back from your mailserver. I keep the treshhold for this fairly high (17), so false positives are very unlikely. b) for the mails with hits > 0 and < 17, I add a header line like "X-Spam-Level: **** (4.4)". For messages > SA spam treshhold, add another header "X-Spam-Warning: SpamAssassin says this message is SPAM". The end users can now add local filters based on these headers and fine-tune the cutoff - level by changing th number of "*" characters in their filter rules. Bye, Martin _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
