Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Russ Allbery <[EMAIL PROTECTED]> writes:
>> I adopt no particular spam filtering rules at the SMTP layer, but I use >> bogofilter (a Bayesian-trained spam filter) to pre-process my mail and >> weed out the spam. The chances of me noticing a false positive are >> non-zero but fairly low. It is plausible that some users trying to >> contact me about my packages would have their mail filtered out and >> thereby receive no response from me. (It's unlikely, or I wouldn't use >> this spam filtering method, but bogofilter is not immune to false >> positives.) > Do you drop the mail on the floor, give a connection-level error, or > send a bounce? For various reasons related to my mail filtering setup, I do not do spam processing until after mail delivery, which means that the mail is effectively dropped on the floor. (Some of it really is; some of it goes into a spam folder that I scan daily, but the chances of me missing a false positive among the other 1,000 messages per day is high.) Once the message has been accepted at the SMTP layer, it's very bad form to generate a bounce message, since your server then hits other people with virus backscatter. I still have a few qmail servers in production use that I need to find time to convert to Postfix, but I try pretty hard to avoid creating any new backscatter problems and /dev/null frequently spammed addresses in qmail until I have a chance to do that conversion. One of the things that means is that unless you're the original accepting mail server, you generally should not be bouncing the mail. If I were going to bounce the spam, I would have to do it at the stanford.edu mail servers, not at the final destination mail server. I doubt Stanford would be particularly pleased with me embedding my spam detection logic into our main relay systems. Please don't underestimate the problems caused by backscatter. Nearly all of my current virus load is backscatter traffic, and each time a new virus comes out I tend to get a hundred copies and several hundred to a thousand bounce messages claiming I sent it. > Really, this isn't mindless on my part: I've been stuck before with this > problem, and I don't ever want to be stuck again, because some mail > server has an over eager rule which prevents them from even hearing > about the problem while it's going on. I understand your feelings, but the only result you're going to get from forbidding Debian developers to use many widely used and effective forms of spam filtering is going to be a sudden lack of Debian developers. I will respectfully explain my spam filtering rules to anyone who asks, and I will try to minimize false positives, but should Debian actually demand that I go back to dealing with over 5,000 spam messages per day via manual sorting (and it's probably doubled at this point) in order to participate in the project, I'd probably have to just find some other project to contribute to. > The specific cases *I'm* bothered by are methods which prevent all mail, > of whatever content, from arriving from particular validly-configured > hosts. One component of the rules applied by Stanford's spam filtering setup, which my bogofilter setup takes as partial input, are host-based origin rules. The reason why such rules are used is because they are *extremely* effective (high spam catch rate, very low false positive rate). Spam filtering is a statistical operation. I'm not going to stop using rules that I know are effective via hard statistical evidence for reasons not backed up by similar hard evidence. Plus, I really don't think there's any way that one can achieve, let alone mandate, zero false positives -- as previously mentioned, purely human spam filtering does not have zero false positives. There are some filtering techniques that I personally consider too aggressive, but I think you're going to be hard-pressed to build any sort of objective criteria that can actually be measured at a distance. The resulting fight over applying any rule like this would, I think, hurt the project considerably more than occasionally losing mail from users. Frankly, anyone who uses e-mail these days is used to mail going occasionally missing; I know average users, not technical experts, who use spam rejection rules so harsh that I would never consider them. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
