What do people think about the following to reduce spam on bug-hurd and help-hurd? It won't clean up the old archives, but it will clean up future archives and might shut some people up that have been voicing their opinion about spam to bug-hurd/help-hurd.
------- Start of forwarded message ------- Date: Fri, 16 Sep 2005 11:45:21 -0600 To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] (Bob Proulx) Subject: Re: spam Simon Josefsson wrote: > Hi all. How do people handle spam to [EMAIL PROTECTED] addresses? I am helping with a number of the bug lists. A small number of us including Karl and Stepan and Jim have worked together to develop a remote mail interface plugin-like process for mailman. The result is that spam is kept off of the mailing lists keeping them useful for real discussion. Bug posters may send messages from any address and do not be subscribed to post. It takes very little manual effort to maintain. See the bug-gnu-utils archive for an example of how effective this can be on a busy list. http://lists.gnu.org/archive/html/bug-gnu-utils/2005-09/threads.html How this works: Messages in the subscriber list or whitelist have no delays imposed upon them. Normal discussion proceeds unimpeded. The remote mailing list plugin robot receives the moderator messages sent by mailman and categorizes the messages with SpamAssassin. The Bayes engine is used to learn statistically from the messages. Continuous training is done to keep the Bayes engine updated. The result of the catagorization is fed back into mailman. Messages that are very likely to be spam are discarded automatically. A local record is kept of those messages and reviewed by a human. Any miscatagorizations may be retrieved and posted by a human. Messages from new non-subscriber addresses are seen in the normal mailman interface, reviewed, approved, and added to the whitelist. Subsequent messages from that user now in the whitelist are passed through without delay. Only the initial contact is delayed for human review. Bug posters do not need to be subscribed. One downside to the current system is that forged mail from a subscriber or whitelisted address is not caught and will be passed through. Mostly this means virus email. But improvement in virus filtering at gnu.org has reduced this problem. But occasionally a forged email slips through. > I find myself coming to a point where I no longer have time to follow > these aliases for bug reports because of the signal to noise ratio. > Filtering these e-mail aliases manually is stealing valuable time that > I could have spent on maintaining or developing my software packages. I would like maintainers to have time to maintain their packages without needing to spend time dealing with the day to day issues of the mailing lists. The lists should just work. Unfortunately the Internet is a hostile place and the gnu.org mailing lists do need some attention. I am trying to help by volunteering my time to make the project maintainer's time more productive. I would be happy to help you with your mailing lists too. If you have a mailing list and are feeling overwhelmed with spam then let me offer the the same service used on the bug-gnu-utils and many others[1] to your list too. Bob [1] There are actually a number of lists using the remote mail robot processor. You may already be subscribed to one or more of these lists. Here is a list of gnu.org mailing lists handled this way. If you think it has been effective there then you will probably find it useful on your mailing list too. autoconf autoconf-maintainers autoconf-patches automake automake-patches bison-patches bug-autoconf bug-bash bug-bison bug-coreutils bug-findutils bug-gnu-utils bug-gnulib bug-grep bug-hello bug-m4 bug-texinfo grep-commit help-bison help-gnu-utils help-texinfo m4-commit m4-discuss m4-patches ------- End of forwarded message ------- _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
