Closed Bug 1150740 Opened 11 years ago Closed 11 years ago

Please create anonymized mailman list at delphi@mozilla.org

Categories

(Infrastructure & Operations :: Infrastructure: Mail, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mailcamillefrancois, Assigned: limed)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.104 Safari/537.36 Steps to reproduce: Would you help me set up an anonymised private mailman list at delphi@mozilla.org? We will need it for a cyber security study (see https://wiki.mozilla.org/Netpolicy/Cybersecurity_Delphi) in order for participants to talk to each other without knowing who is behind each statement and who is in the list. I understand that masking participant email addresses is an option in the mailman setup—can you confirm? The messages sent to delphi@mozilla.org could then either appear as coming from a pseudonym or number assigned to real email address or could appear as being sent from the list itself?
Assignee: mitchell → infra
Component: Miscellaneous → Infrastructure: Mail
Product: mozilla.org → Infrastructure & Operations
QA Contact: limed
Its possible, sort of? The options that you are looking for is anonymous_list = True But there are 2 other options that you might want to take a look at as well is: first_strip_reply_to = yes reply_goes_to_list = poster This might not give you 100% of what you want though (more info here[1]). I myself haven't played around with this option so I am not 100% on how this would work, so if you want we can go ahead and create the list for you but you might want to test and play around with the settings to see if this gives you the result that you want/need [1]: https://mail.python.org/pipermail/mailman-users/2010-October/070484.html
Let's create the list and see how it works, then tweak if needed. I think we want anonymous_list = True; we also want first_strip_reply_to = yes; and I think we can leave reply_goes_to_list blank, but we might need to change that to set it = poster later. Basically, we don't want to enable any option to write back just to the individual sender; we want the *only* reply option to be a reply-all to the list, anonymized so that nobody knows who wrote any of the content. (I know this is an unusual circumstance, but this is a time-limited list only, alive for 2 weeks then ended.)
Summary: Please create anonymized mailman list at delphi@mozilla.com → Please create anonymized mailman list at delphi@mozilla.org
List has been created and made mchris@mozilla.com the admin
Assignee: infra → limed
Let me know how this works out for you guys, reopen if you need anything else.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Hi Ed, thanks a lot! Last important question on our end: is there a way for admin to see who engaged with the list? For the research we won't need to know who is behind each email sent to the list, though it would be very helpful to have an idea of how many people are engaging with the list. For instance, as an admin if I read 40 messages on the list, do I have a way to find out if it's coming from 2 people talking back and forth or if it is the product of a conversation between 30 members of the list? Thanks again for the help.
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
(In reply to Camille Francois from comment #5) > Hi Ed, thanks a lot! > Last important question on our end: is there a way for admin to see who > engaged with the list? > For the research we won't need to know who is behind each email sent to the > list, though it would be very helpful to have an idea of how many people are > engaging with the list. > For instance, as an admin if I read 40 messages on the list, do I have a way > to find out if it's coming from 2 people talking back and forth or if it is > the product of a conversation between 30 members of the list? > Thanks again for the help. I don't believe so, there are mail logs that get logged on the server and mailman does not make that data available.
Hi Ed et al, Can we work to strip out SPF headers in the emails? They're seeing e.g. these: ""Received-SPF: pass (google.com: domain of cfrancois@mozilla.com designates 209.85.216.54 as permitted sender) client-ip=209.85.216.54; "" Here's a tip from a friend on relevant scripts/solutions: modify /usr/lib/mailman/Mailman/Handlers/Cleanse.py to add the following underneath if mlist.anonymous_list: del msg['received-spf'] del msg['authentication-results'] del msg['domainkey-signature'] del msg['dkim-signature'] rm Cleanse.py[oc] python -O -c 'import py_compile; py_compile.compile("Cleanse.py")' python -c 'import py_compile; py_compile.compile("Cleanse.py")' http://blog.wtwf.com/2008/03/anonymous-mailman-lists.php/
We don't really want to make changes to the source if we can help it. As it stands now we have already made changes to the source code and many times it has caused us more trouble than we would like. On top of that this change involves every list anonymous list, while this might be an ideal list configuration for you guys it might not be what other people want so I am inclined to not make this change, not to mention that some of these header values involves things that are related to spam prevention, so removal of this might increase spam count
That makes sense Ed. We'll think about / look into any solutions that wouldn't involve code change, recognizing that there probably aren't any. :-) Certainly not a show-stopper, but wanted to tee it up for thought / possibilities. Much appreciate the response!
(In reply to mchris from comment #9) > That makes sense Ed. We'll think about / look into any solutions that > wouldn't involve code change, recognizing that there probably aren't any. :-) > > Certainly not a show-stopper, but wanted to tee it up for thought / > possibilities. Much appreciate the response! No problem, let me know what else I can help with
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.