[address@hidden: Re: spam]

[Alfred M. Szmidt]

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: 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 -------