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:
- That is not a great way to run a moderated mailing list.
- 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