Richard Stallman writes: > It sounds like this new spam technique is becoming xommon. > Would it make sense for Mailman's defaults to DTRT for it, > or reduce the amount of customization users need to do?
No. Mailman really shouldn't be doing any spam filtering at all. It needs filtering, yes, but that's because authorized users will often send posts that violate the list's rules. OTOH, it is by far best to do generic spam filtering at the inbound MTA. There are excellent programs such as SpamAssassin and SpamBayes written for this purpose. They have actively maintained rule sets, because spam filtering is their primary purpose. These programs are filters; they can also be inserted in the mail pipeline on the delivery side (eg, by calling out from procmail) or in Mailman itself (with a simple Handler). However this has the disadvantage that only Mailman, and not other system users, is protected from spam. Filters integrated with the MTA are often more parsimonious with system resources (eg, the "fork tax"), and have the advantage that in some cases the mail can be refused at the SMTP level, which avoids first-order backscatter and sometimes provides more information to victims of false positives. Nevertheless, in these "late pipeline" configurations they will surely do a better job than Mailman itself can. Adding spam filtering to Mailman itself may improve matters for people who do a poor job of spam filtering in the first place. On the other hand, it is very likely to occasionally make it difficult for legitimate users to get their mail through to the list because they get caught by some arcane rule. ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
