Mailman 3 March 2015 - Mailman-Developers

Re: [Mailman-Developers] Contributing to GNU Mailman (GSOC '15)
by Ankush Jindal 16 Mar '15

16 Mar '15

Hi, I now understand there projects a lot more than I did when I previously posted. I want to work on the 'Dashboard for Admins', I have worked in some details that I think should be in the admin page. 1. This would be the main page - https://moqups.com/jindal.ankush95@gmail.com/2Mm42VyL/p:ae312b9e8 1. The admin can mass subscribe from the 'Subscriber Request' widget https://moqups.com/jindal.ankush95@gmail.com/2Mm42VyL/p:af543c52c 2. The List settings would take user to a different page for managing a particular list - modify list name, delete list, info about the list, admin/moderator role management, current subscribers (mass ban and unsubscribe, though I know that ban would mostly occur through next point) 3. The 'Mail approvals' give a stat and clicking on a particular list or list from 'list archive page' would take admin to https://moqups.com/jindal.ankush95@gmail.com/2Mm42VyL/p:a5a5aaa3c 1. The activities are grouped in a sense that the admin can look on new, pending mail requests and also look at posts that are marked as moderation needed. 2. When admin clicks on some post from the left pane, the right pane would focus on that particular post. Admin can then accept, reject or mark the post as pending and can also ban the user from there. 3. The subscribers link in the left pane would show all the subscribers to that list and the admin can then ban/unsubscribe from there. 4. The List Setting link will take to point (1b) 2. I also think a need for user page ( different from the subscriber's page, this could be viewed by the public and not only other fellow subscribers. The motivation behind it is that a user could also be an admin too and thus there is a need for consistency. Like this https://moqups.com/jindal.ankush95@gmail.com/2Mm42VyL/p:a459f6c6a) 1. From here user can have profile control https://moqups.com/jindal.ankush95@gmail.com/2Mm42VyL/p:a16afdd67 2. User can go to the admin dashboard from there. And start a list. Coming to execution of the design, I ought to aim for completing point (1) completely at the start and then going to point (2) (which I think is doable as well). As of now, I haven't worked on any bug as of yet, I will asap set the development environment, look at the code and report back to you. Do give remarks to this workflow. -Ankush Jindal Student, IIT Mandi, India Phone: +91-9805901195 Github: travis-bickle

1 0

[Queries] Related to List Styles in mailman
by Stephen J. Turnbull 15 Mar '15

15 Mar '15

prakhar joshi writes: > hi, > I am Prakhar Joshi (irc name :- _pjoshi). I have few things to discuss > about the storage of new styles for the list that will be created through > rest API. I think we should create a separate table for the list styles and > there we can add the entries for the newly created styles in those tables. > Now we have to work around for storing these default styles in the > database. Here what I think is we can do it in 2 ways :- > 1) We have two default entries in the table and can only have "GET" > request for these two and "GET"/"POST" request for rest of the entries in > the table. > 2) We can have these 2 default styles out of the table and these 2 can > be called as they are now from their places in the web interface directly. What are the advantages and disadvanatages of the two approaches as far as you are concerned? Steve

2 1

Reagarding A "Dashboard for Admins/Owners/Moderators"
by Stephen J. Turnbull 15 Mar '15

15 Mar '15

Shreyas Lakhe writes: > Ihttps://moqups.com/srlakhe/weZugpFL The "I" is a typo? Note that Activity should be tri-state: approved, rejected, pending. In the case of held messages, there may be more states (each reason for holding mail could be treated as a separate state).

1 0

Re: [Mailman-Developers] GSOC, Anonymous Lists
by Stephen J. Turnbull 15 Mar '15

15 Mar '15

Pavan Koli writes: (a generally good description of an approach to the problem) > hidden from him. But if someone tries to spam the mailing list, > that person can be caught by noting his anonymous id. I'm not sure what use case you have in mind. Why would a spammer post to the anonymous list from the same address twice? If subscription (and posting) requires owner approval, such spamming is very rare anyway. > 3. I didn't come across a single mailing list for whistleblowers, > activists, or people trading very sensitive information. You won't. They have alternative channels for transmitting information, just like spies employed by governments or corporations. > Mail spoofing attempts can be stopped by encrypting mails, Encrypted lists is a different use case. You'd use digital signatures in this case. > using PGP, but there is one problem. The person encrypting the mail > would have to share their public key with everyone on the mailing > list, which can be a tedious task as the mailing lists keep on > changing in size, Key distribution in this case is easy. Just post it to the mailing list. :-) > and also mails can be leaked if public key falls into wrong hands. This isn't a real use case. Think carefully about your definition of "wrong hands" in the context of "whistleblower". > I've come up with a solution for this, these mailing lists will be > kept in a very different category from others. Here when ever a > user will register, they'll have to also provide their public key. This is in fact the same basic approach as a previous GSoC project which hasn't been integrated yet. > Problem- The list manager has to be authentic, using their public > key list subscribers can verify their authenticity I don't understand what you mean. > (Or I propose a public key for the list itself and then people can > use it to verify lists authenticity). I think this is the right solution anyway. One possibility would be to use DKIM signature technology (RFC 6376, I think).

1 0

Gsoc 2015 : A Dashboard for Admins/Owners/Moderators
by Heshan Jayasinghe 15 Mar '15

15 Mar '15

Hi, I am Heshan Jayasinghe.I am 2nd year undergraduate in University of Moratuwa,Srilanka.I am an Open source developer and i really like to contribute your company in this GSOC 2015.In my university i did several android base applications.and noSQL (RDF) based web applications.i am good at in front end development in HTML java script and ajax I am interested on your project "A Dashboard for Admins/Owners/Moderators".I read your Documentation given about these projectI want to know the path I should follow to contribute your company. I am looking forward for your reply regards, Heshan Jayasinghe.

3 2

Reagarding A "Dashboard for Admins/Owners/Moderators"
by Shreyas Lakhe 15 Mar '15

15 Mar '15

Hi, I have started working on making a more detailed prototype for the "Dashboard for Admins/Owners/Moderators" project and I am thinking about including the following features in the admin interface: 1.General options(modifying list name , info, admins) 2.Password options(change the owners and administrators password) 3.Membership management(subscribe users, unsubscribe users with mass subscription/removal options) 4.Tending to pending moderator requests The above mentioned points could be the base admin interface: To allow the admins to manage multiple lists we could have: 1.add a new list 2.remove a list (1 & 2 would be primary) The other features would be grouped into two categories 1. a common listing of pending messages and requests for lists from the last seven days 2. a list by list listing of the pending messages and requests , wherein the above admin interface would work for individual lists Here is a link implementing some of the features. Ihttps://moqups.com/srlakhe/weZugpFL Suggestions on it are welcome. Thanks, Shreyas Lakhe

1 0

Re: [Mailman-Developers] GSOC, Anonymous Lists
by Pavan Koli 15 Mar '15

15 Mar '15

> >I have the same doubt. You need to define "anonymous list". In > particular, specify who is, and who is not, supposed to be able to > >1. See email addresses of subscribers. > >2. Figure out whether two posts are from the same person. > as well whether you need to > >3. Ensure that subscribers' posts can't be spoofed. > These sites already are using anonymous lists http://www.na.org.za/mailing-lists, http://www.12stepforums.net/mailinglist.html, http://www.e-aa.org/maillist.html. >From the above I deduced that there can be three different use cases. 1. The list manager is a doctor, treating their patients. In this case they'll be able to view patients e-mail ids. The e-mail ids will be mapped to something like "anonymous_timestamp@domain". The list manager in this case will have an interface where the anonymous ids will be listed along with the real e-mail ids. This shall help them know whether two posts are from the same patients or not. Also be able to communicate with patients, if time arises.This list can be like an online support group where the list manager is the doctor and the members are his patients. Lists like http://www.12stepforums.net/mailinglist.html, will come under that category. 2. The second use case can be when the list manager himself cannot be trusted with the details, like suppose there is an online mailing list for drug addicts to overcome their addiction, created by an ex-drug addict. But we cannot trust our mail ids with this person, as we don't know clearly his intentions. In this cases where the list manager cannot be trusted fully or the list manager has no use, knowing my email id. Here the list manager won't have any interface mapping anonymous ids with the original ids. But can identify if two mails are by the same user or not by seeing the header- From: anonymous id, on the two mails. Lists like http://ottawana.org/, here members help each other, in such case the list manager has no business knowing e-mail ids of members as he is not offering any help, like the doctor in the previous case, so it would remain hidden from him. But if someone tries to spam the mailing list, that person can be caught by noting his anonymous id. 3. I didn't come across a single mailing list for whistleblowers, activists, or people trading very sensitive information. Suppose there is a group of whistleblowers and journalists, who are connected with this mailing list. Obviously in this case the list manager won't be able to note my real e-mail id, but can verify me using my public key(X.509 certificate), the mails in such cases would be regarding national interests. Hence, there can be hacking attempts on the database or mail spoofing attempts. Hacking attempts can be made futile as the people registering for this mailing list are definitely not going to register with their actual mail ids, hence even if those stored mail ids are exposed. There is very less chance of them getting caught. Sites like (http://www.sendanonymousemail.net/, http://www.33mail.com/, https://www.hushmail.com/) provide anonymous mail id creation. Mail spoofing attempts can be stopped by encrypting mails, using PGP, but there is one problem. The person encrypting the mail would have to share their public key with everyone on the mailing list, which can be a tedious task as the mailing lists keep on changing in size, and also mails can be leaked if public key falls into wrong hands. I've come up with a solution for this, these mailing lists will be kept in a very different category from others. Here when ever a user will register, they'll have to also provide their public key. So now it will work in this way- *User A will encrypt a message using his private key(PGP) and send on the mailing list. *On receiving a message, it will de decrypted by the public key provided from the database. *Now a sessions key will be generated, and it will be encrypted for different users using their public keys. So suppose ABC is a sessions key and user B, user C and user D are there. The sessions key will be encrypted differently for different user using their public key. (Although another way can be used is to encrypt the contents of the message using the public keys of users, so every message will be encrypted differently depending on the users public key. But in this situation there can be a lot of time loss as the time taken would increase with the size of the mailing list, but it can be implemented in cases where security is more important than time, so it'll depend on further details like size of the list) *The message contents will be encrypted using the sessions keys to overcome the time overhead associated as mentioned above. *The users will first decrypt the sessions key using their private keys and use it (session key) for decrypting the original message. This can be thought as a safe method as people trying to spoof the messages won't be able to do anything which is what I suppose. Maintaining a mail archive or not will be the decision of the mailing list managers. This case doesn't necessarily apply to whistleblowers only, another use case can be between police and secret informants. Informants can pass messages through the mailing list. Problem- The list manager has to be authentic, using their public key list subscribers can verify their authenticity(Or I propose a public key for the list itself and then people can use it to verify lists authenticity). Authenticity can be done using public key and using X.509 Certificate, more info here- http://en.wikipedia.org/wiki/X.509. Working of PGP key- http://www.makeuseof.com/tag/pgp-me-pretty-good-privacy-explained/ Idea for sessions keys usage, also how to prevent identity spoofing- http://en.wikipedia.org/wiki/GNU_Privacy_Guard#Process The encrypting and decrypting can be implemented by putting appropriate code in the pipelines process of the respective queues. Sorry for such a long message, suggestion and criticism is welcome. I want to know areas where this mailing list would fail, in its work of keeping its members anonymous, should I go forward with creating a project proposal with this Idea for GSoC? -- Pavan Shankar Koli GitHub- www.github.com/pkoli Website- www.techjugaadcenter.me/pkoli

1 0

Fwd: GSoC 15
by Stephen J. Turnbull 15 Mar '15

15 Mar '15

Please *always* include the project you're working on in the subject and again in the text. Shreyas Lakhe writes: > I have started working on making a more detailed prototype and I am > thinking about including the following features in > the admin interface: > > 1.General options(modifying list name , info, admins) > 2.Password options(change the owners and administrators password) > 3.Membership management(subscribe users, unsubscribe users with mass > subscription/removal options) > 4.Tending to pending moderator requests > > The above mentioned points could be the base admin interface: > To allow the admins to manage multiple lists we could have: > 1.add a new list > 2.remove a list > (1 & 2 would be primary) > The other features would be grouped into two categories > 1. a common listing of pending messages and requests for lists from the > last seven days > 2. a list by list listing of the pending messages and requests , wherein > the above admin interface would work for individual lists > > Here is a link implementing some of the features. > Ihttps://moqups.com/srlakhe/weZugpFL

1 0

Regarding Subscribe/unsubscribe policy for lists Edit
by Stephen J. Turnbull 15 Mar '15

15 Mar '15

Ashish Kumar writes: > Hi, > > I have been contributing to mailman since last two weeks. I found this bug > in the list "Subscribe/unsubscribe policy for lists" [ > https://bugs.launchpad.net/postorius/+bug/1095552]. > > Can someone please tell me what's the current status of this bug and how > may I help in fixing it. The status is whatever is posted to the bug. The people who are following the bug may be working on it but most likely are hoping to hear somebody is fixing it. If you're interested in working on it tell us what you propose to do to fix it (even if at the moment that's limited to "studying postorius code", which you should already have checked out ;-). Steve

1 0

GSOC 2015: Seeking Information
by Stephen J. Turnbull 15 Mar '15

15 Mar '15

Nakul Gulati writes: > After reading about mailman and going through the code base and > scope of different ideas, my interest align with the project > *Mailman Client written in Javascript* in particular. Hence, I'd > like to pursue it as part of GSOC 2015. Sounds good to me. See http://turnbull.sk.tsukuba.ac.jp/Blog/SPAM.txt for hints on how to write a proposal. > I would like to discuss further about the project. There's nothing to discuss until you tell us what you think needs to be done. See Mentors Are Not Teachers on the wiki (which I just wrote and posted): http://wiki.list.org/DEV/Google_Summer_of_Code_2015

1 0