On Mon, 2008-12-22 at 12:12 +0100, Jérôme Blion wrote: > I dislike the way you want to make Spamassassin work. You want to scan > your mails twice. It's a bad idea as it's CPU intensive.
Hi Jérôme, I agree in general with you about CPU usage, however the load average on the servers in question generally runs at or under 1.0, so even with this hit the extra SA invocation is not much of a burden and doesn't noticeably slow things down. There may be resource issues that will turn up later, but at this point it looks good. > My advice would be to let this filter as it is right now. (put a > bigger score on mail you don't want to see at all later). > Then in your .maildroprc, you will juste have to scan headers to > reject mails according to user's preferences The existing system for scanning email on these servers has been all post-receipt. Users (commercial hosting customers) can make several selections in their per-mailbox profiles to enable/disable segregation of viral or spam email, to select the method marking identified spam, and to select 1 of 4 SpamAssassin threshold levels. I have customers who are very skeptical of _any_ system that rejects or discards identified spam outright, so clients can select the SA spam score threshold on a per-mailbox basis and their SA-marked spam is simply quarantined into an IMAP mailbox where they can examine it if they wish. Except for my own personal email, I'm not doing any header scannning in ~/.mailfilters/ (which is what I assume you mean above), only including a global policy file in rcptfilter which implements rejections based on BLOCK* vars set by RBL look-ups in Courier. The system works quite well, and there are a lot of man-hours (mine) put into developing it, and the web UI that customers access to control the filtering policies for their mailboxes. I don't need or want to change this at this point. I just need to implement pre-filtering, rejecting outright any spam with a SA score of 10 or above. It might turn out that I'd get some advantage from pre-marking inbound emails with SA "at the front door" and doing header analysis in smtpfilter based on SA's inserted headers, but I'm going to start with simple mods to the existing system and take it from there. Pushing full SA analysis and markup forward from the delivery phase will remove some of the per-mailbox flexibility I have in the system now, and I'll have to decide how much of this, and the work involved in making the changes, is appropriate. There may be others who would want to pre-filter inbound email and _not_ run SA a second time, and leave no evidence in received email that it was passed through SA at all, and this patch provides them with the option of doing so. The point of the patch is to provide a choice in the matter. The patch doesn't disable modification of incoming email, it just provides a configuration switch to turn modification on or off. The default, in fact, is for the module to work exactly as it does now. Whether you like or dislike the way we handle inbound email analysis here at FMP is another matter altogether. -- Lindsay Haisley | "In an open world, | PGP public key FMP Computer Services | who needs Windows | available at 512-259-1190 | or Gates" | http://pubkeys.fmp.com http://www.fmp.com | | ------------------------------------------------------------------------------ _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
