On Fri, Sep 16, 2005 at 09:00:46PM +0200, Alfred M. Szmidt wrote: > What do people think about the following to reduce spam on bug-hurd > and help-hurd?
Yes, that's definitively a sound approach that is working very well for other lists. Shouldn't commit-hurd, l4-hurd and web-hurd also be filtered? I don't know--I have a nearly perfectly working filter. Why is posting to commit-hurd allowed, at all? > might shut some people up that have been > voicing their opinion about spam to bug-hurd/help-hurd. Indeed, I've heard several people stating that they're not subscribed to the Hurd's mailing lists because of the low signal to noise ratio (regarding spam that is, not the re-posting of patches all the time...). I second that Alfred should take care that these measures get implemented. I'd volunteer to help reviewing the messages that need to be reviewed manually. Below, I re-quoted the proposal, if someone wants to re-view it again. Regards, Thomas > ------- 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
