[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: address@hidden: Re: spam]
Re: address@hidden: Re: spam]
Sat, 24 Sep 2005 17:20:07 -0400
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
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.
> ------- Start of forwarded message -------
> Date: Fri, 16 Sep 2005 11:45:21 -0600
> To: address@hidden
> From: address@hidden (Bob Proulx)
> Subject: Re: spam
> Simon Josefsson wrote:
> > Hi all. How do people handle spam to address@hidden 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.
> 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
> 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 to your list too.
>  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.
> ------- End of forwarded message -------