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.likely@secretlab.ca> wrote:

On Wed, Feb 20, 2013 at 11:07 AM, Philip Colmer
<philip.colmer@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.kumar@linaro.org> wrote:
>>
>> On 20 February 2013 16:19, Wookey <wookey@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