We would like to disable posting in mozilla.reps.general via google groups, as spam gets through it. E.g https://groups.google.com/forum/#!topic/mozilla.reps.general/dqYSr6EB984
I think what you may want is for the group to be set to Moderated, which I believe means that all posts come via Mozilla's mailman instance (and its spam filtering) and can be approved or denied by a moderator if they come from someone unknown. Can we try that first? Whatever happens, it will be done by server-ops, not me. Gerv
Assignee: gerv → server-ops
Hey Gerv, Actually the moderation queue in reps-general mailman is unmaintained, and basically whatever is captured by it never gets resolved. Given that and the fact that no one ever posts via google groups I would rather disable posting in google groups and get over spam and moderation once and for all for reps-general.
Surely there's a keen rep who can do the moderation? Are you sure the spam is coming in via Google Groups? I don't know if it's possible to disable posting only from GG; server-ops will need to advise. Gerv
Pierros, who has admin rights on the reps-general mailing list? Can you check if the spammers are subscribed?
I have access on mailman of reps-general. I can confirm that neither of the spammers are subscribed.
So spam is coming from newsgroups or google groups. I personally support disable posting from google groups, but we should ping Council about the policy for this list, time ago it was supposed to be closed to reps only and now anyone can post (even without subscription). Adding Council to the bug.
I agree with Gerv that we should go for moderated and then just ignore the moderation queue. I admin a bunch of lists myself, and it's incredibly rare that something legit gets caught in moderation. In that case, the person can let someone know that their message never showed up (and I think we can also set up automatic replies for messages that were held, so any legit people will know what they have to do). You can also set moderation to allow messages from @mozilla addresses without having to be signed up. That way employees can still engage with Reps without having to take extra steps.
I dont know the reasons that the previous Council voted to keep the list open for anyone to post subscribed or not, probably to be more open to the rest of the world so anyone could easily contact us. I agree with Kensie and Gerv we should go Moderated instead, find someone that could fill the role of the list moderator and keep it clean, there are only a few spammers, so blocking them would easily reduce the spam to zero. According to our Mailing List Policy, the list should be only used for *Updates from council *General webdev updates *Suggestions for improving the program If we can not find a Moderator then for transparency i would like the list to be read-only for non-subscribed.  https://wiki.mozilla.org/ReMo/SOPs/Mailing_List_Policy
Please, can we move this ahead and disable the newsgroup/google groups posting for reps-general? Moderation queue doesn't make any difference since spam is coming from non-subscriber addresses. I don't know if we should change this bug component for this change. Thanks.
Spam is going crazy in reps-general, we have just received 11 messages in a row. Please could you disable this ASAP? Thanks!
You can do this on your own the options are gateway_to_news gateway_to_mail I've set that to no
Oh, didn't know that. Thanks Ed!
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Ed, can we have list archives now on mailman?
Flags: needinfo?(server-ops) → needinfo?(limed)
(In reply to Rubén Martín [:Nukeador] from comment #13) > Ed, can we have list archives now on mailman? Something you can set here https://lists.mozilla.org/admin/reps-general/archive as well. I went ahead and enabled it for you. However the caveat is you have to go to the list archive manually here https://lists.mozilla.org/pipermail/reps-general since we have patched our instance to just send you straight to google groups
You need to log in before you can comment on or make changes to this bug.