Re: [address@hidden: Re: spam]

[Thomas Schwinge]

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: gnu-prog-discuss@gnu.org
> From: bob@proulx.com (Bob Proulx)
> Subject: Re: spam
> 
> Simon Josefsson wrote:
> > Hi all.  How do people handle spam to bug-*@gnu.org 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 -------