Hi Guys,
I really don't know whom to direct this mail to and hence the wide spread.
Problem: When we send a mail to kernel mailing lists with linaro-dev or linaro-kernel in cc, and we get replies to those mails, sometimes the mails from outside people doesn't reach us back on linaro mailing lists. And i hope the reason behind that is those people aren't subscribed to these lists.
For me it makes some sense to allow anyone to send mails to this list. Can that request be considered?
I believe the idea behind blocking such use is for protecting against spam mails, but these mails/replies are really important and we certainly need them delivered to us.
One solution (don't know if its possible) would be to monitor mails from non-subscribers and few people from Linaro can permit them on daily/hourly basis, so that we don't get any spam mails, but that would be a burden.
-- viresh
On Wed, Feb 20, 2013 at 10:35 AM, Viresh Kumar viresh.kumar@linaro.org wrote:
Hi Guys,
I really don't know whom to direct this mail to and hence the wide spread.
Problem: When we send a mail to kernel mailing lists with linaro-dev or linaro-kernel in cc, and we get replies to those mails, sometimes the mails from outside people doesn't reach us back on linaro mailing lists. And i hope the reason behind that is those people aren't subscribed to these lists.
Yes that is the reason
For me it makes some sense to allow anyone to send mails to this list. Can that request be considered?
I believe the idea behind blocking such use is for protecting against spam mails, but these mails/replies are really important and we certainly need them delivered to us.
One solution (don't know if its possible) would be to monitor mails from non-subscribers and few people from Linaro can permit them on daily/hourly basis, so that we don't get any spam mails, but that would be a burden.
Yes, the moderator lets these emails in and whitelists known upstream developers upon request. Please let Anmar or Philip know any such email addresses.
On 20 February 2013 11:00, Amit Kucheria amit.kucheria@linaro.org wrote:
Yes, the moderator lets these emails in and whitelists known upstream developers upon request. Please let Anmar or Philip know any such email addresses.
Okay. I got this.
But what i requested was a bit more than that... In current case somebody has to ask moderators to whitelist few mainline developers, but many a times when we are in cc of original mail, we don't realize that mails aren't reaching everybody on list.
The idea i had was, moderators should monitor all the mails which aren't being delivered to our lists, check if they are spam or not, in case they aren't spam (which is pretty easy to find), add senders mail id in whitelist (or whatever it is called).
That would make things work quickly and would be much more efficient.
-- viresh
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. 3. The whitelist is going to start getting *very* big very quickly, reducing the effectiveness of the mailing system and of the moderation function.
This may need a bit more thought, I suspect. I suggest that there should be more than one non-IT person with administrator access to the list so that the moderator queue can be checked more frequently that is currently being done at the moment.
Philip
On 20 February 2013 05:49, Viresh Kumar viresh.kumar@linaro.org wrote:
On 20 February 2013 11:00, Amit Kucheria amit.kucheria@linaro.org wrote:
Yes, the moderator lets these emails in and whitelists known upstream developers upon request. Please let Anmar or Philip know any such email addresses.
Okay. I got this.
But what i requested was a bit more than that... In current case somebody has to ask moderators to whitelist few mainline developers, but many a times when we are in cc of original mail, we don't realize that mails aren't reaching everybody on list.
The idea i had was, moderators should monitor all the mails which aren't being delivered to our lists, check if they are spam or not, in case they aren't spam (which is pretty easy to find), add senders mail id in whitelist (or whatever it is called).
That would make things work quickly and would be much more efficient.
-- viresh
On 20 February 2013 14:06, Philip Colmer philip.colmer@linaro.org wrote:
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. 3. The whitelist is going to start getting very big very quickly, reducing the effectiveness of the mailing system and of the moderation function.
I understand your viewpoint, but the most important part is: mails should reach everybody as soon as possible. Currently few of them are never reaching us :)
This may need a bit more thought, I suspect. I suggest that there should be more than one non-IT person with administrator access to the list so that the moderator queue can be checked more frequently that is currently being done at the moment.
That's a good one and from their rather than blindly adding people to white-list, developers can actually decide pick people they trust.
I am ready to be part of this team of non-IT people.
-- viresh
+++ 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?
Wookey
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
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.
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
I understand your viewpoint, but the most important part is: mails should reach
everybody as soon as possible. Currently few of them are never reaching us :)
There does appear to be some tech issues with this list too, I was being blocked from posting to the list and after some investigation our IT department responded with:
"Their DNS servers not configured with MX records properly for us to deliver emails to them."
Now, this could quite easily be just a difference in configuration and not very good wording from our IT guys, or there could be a real problem.
We have hard coded DNS entries so hopefully this reply will hit the list. ;-)
Figured it was worth pointing out as some of the issues may not be just to do with whitelisting.
Mark
Mark
I can solve the MX record issue.
In *theory*, if a system is trying to send email and it cannot find an MX record, it *should* fall back to looking for an A record (which does exist) but not everything follows that.
Philip
On 20 February 2013 11:11, Mark Hambleton mark.hambleton@broadcom.comwrote:
I understand your viewpoint, but the most important part is: mails
should reach****
everybody as soon as possible. Currently few of them are never reaching
us :)****
There does appear to be some tech issues with this list too, I was being blocked from posting to the list and after some investigation our IT department responded with:****
"Their DNS servers not configured with MX records properly for us to deliver emails to them." ****
Now, this could quite easily be just a difference in configuration and not very good wording from our IT guys, or there could be a real problem.****
We have hard coded DNS entries so hopefully this reply will hit the list. ;-)****
Figured it was worth pointing out as some of the issues may not be just to do with whitelisting.****
Mark****
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
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
Philip you have also mlmmj for moderation as well for those that dont sign up to the lists. Libreoffice use it and you moderate it via email which i find very handy.
On Tue, Aug 27, 2013 at 11:02 AM, Philip Colmer philip.colmer@linaro.orgwrote:
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
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev