Hi Grant It looked like there wasn't enough interest in testing Google Groups for patches so that idea pretty much got abandoned.
I'm about to go on holiday for a few weeks but I've set myself a task on ZenDesk (our ticketing system) to build a new Mailman server when I return; I'll integrate SpamAssassin into that and we'll run some tests on it. From some of the things I've read, it should be fairly straightforward to then use SpamAssassin to do the filtering and then get Mailman to drop anything that SA has identified as spam (if SA doesn't already drop it). Regards Philip On 26 August 2013 13:57, Grant Likely <grant.lik...@secretlab.ca> wrote: > On Wed, Feb 20, 2013 at 11:07 AM, Philip Colmer > <philip.col...@linaro.org> wrote: > > So we could flip the management of the list on its head, then, and make > the > > list wide open but blacklist spammers ... except that you then find > yourself > > in a reactive mode. In other words, spam gets onto the list because the > list > > is open, so you add the sender's email address to the blacklist, which > works > > until they pick another email address and you are waiting to spot spam > > again. That *potentially* is a tougher approach to take because if > someone > > isn't *actively* blacklisting the spammers, you could end up with a lot > of > > spam on the list once someone finds it. > > > > This may still be a better way to go. I'm not arguing either side :-). > I'm > > just highlighting a potential drawback to going the "open" route. > > I'm going to dig up this old thread issue again. I've got the same > problem on the boot-architecture list, and it probably goes for any of > our "in the open" development lists. I completely agree with Wookey on > this point. Having to manually whitelist developers is the complete > opposite of what is required for development lists because we really > don't know who is going to post. It could be anyone, anywhere and > manual moderation ends up getting in the way of development. The > boot-architecture list isn't working for us at the moment for this > exact reason. > > In my mind, if we have to either actively manage a whitelist or a > blacklist, then we've got a serious problem. Blacklists don't work > anyway for spam because the sender address changes with pretty much > every spam message. It has to be a spam filter implemented on the list > server. We know it is possible because there are lists servers out > there that do in now. vger.kernel.org is a fantastic example. It is > good at filtering spam, handles a huge volume, and there is no > moderation. Creating a new list does not require someone to volunteer > for moderation duties. However, I don't know how complicated it is to > set up. > > How did the test of google groups go for passing patches correctly? If > it handles them okay, then I would be okay with moving > boot-architecture to a google group if it would allow unmoderated > posting. > > g. > > > > > > > On 20 February 2013 10:51, Viresh Kumar <viresh.ku...@linaro.org> wrote: > >> > >> On 20 February 2013 16:19, Wookey <woo...@wookware.org> wrote: > >> > +++ Philip Colmer [2013-02-20 08:36 +0000]: > >> >> I'm not entirely comfortable with blindly white-listing anyone who > >> >> posts > >> >> to linaro-dev with something that doesn't look like spam, for > >> >> several > >> >> reasons: > >> >> 1. That is not a great way to run a moderated mailing list. > >> >> 2. IT aren't going to be in the best position to say whether or > not > >> >> the > >> >> sender should�be able to send to linaro-dev, even if they didn't > >> >> send > >> >> spam. > >> > > >> > Why do we want to block anyone from linaro-dev unless they are > >> > spamming (which would include being too-far off-topic)? > >> > > >> > Arguments about the admin load of moderation, or the difficulties of > >> > spam-filtering accurately on an open list, I can understand; but the > >> > idea that this list should be restricted to only suitably enlightened > >> > people by default seems wrong to me. It should be as open as we can > >> > practically make it, shouldn't it? > >> > >> +1 > >> > >> _______________________________________________ > >> linaro-dev mailing list > >> linaro-dev@lists.linaro.org > >> http://lists.linaro.org/mailman/listinfo/linaro-dev > > > > > > > > _______________________________________________ > > linaro-dev mailing list > > linaro-dev@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/linaro-dev > > >
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
