Mailman 3 March 2015 - Mailman-Developers

[Queries] Related to List Styles in mailman
by prakhar joshi 15 Mar '15

15 Mar '15

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. I will really need to discuss these things. Any new suggestions are also welcome. Thanks, Prakhar Joshi DA-IICT,Gandhinagar

1 0

Some bare minimums for submitting patches (GSoC students take note)
by Barry Warsaw 15 Mar '15

15 Mar '15

A quick note for GSoC students, although this can apply to anyone submitting merge proposals to the core. You really need to run the test suite before submitting your branch. If the test suite fails, I am going to mark your branch 'needs fixing' and move on. Of course, ideally your branch would include any tests needed to illustrate the problem too. If there are no tests, then it's a red flag to me that maybe the fix doesn't actually fix the problem. One technique I use when looking at your branch is to unapply the fix and just run your tests. If I see a failure, that's a *good* thing because I then expect to reapply your fix to see the failure go away. This is just an extension of test driven development (TDD) of which I'm a fan. As we say, "untested code is broken code". Cheers, -Barry

1 0

Re: [Mailman-Developers] full anonymisation approach
by Rashi Karanpuria 15 Mar '15

15 Mar '15

> Aside: I think if you actually use such a list you'll discover that > most "shy" people are far more afraid of being flamed than they are of > social stigma *outside* of the discussion thread. OTOH, it is likely > to bring out the worst in trolls. IMHO YMMV etc. We can't overlook the fact here that shy people and most of the others facing one social stigma or other do benefit from anonymous conversations and 12-step program lays focus on such websites. Though one of the many ill-effects is that some people may get dependent on the virtual society totally avoiding confrontation from the real one as referenced in [1]. Second ill effect is that internet anonymity is more vulnerable to abuses as people don't hold any responsibility of their behaviour in such a system. Hence, internet anonymity is a double edged sword (reference [2]). The shortcomings are considerably significant but we can't overlook the advantages of using anonymity to treat such cases as the research suggests. > > > In my opinion the requirements are: > > 1) Keeping list members anonymous from each other. > > OK, that follows from the above motivation. However, do you want the > list identity to be consistent within threads, or will you assign a > new list identity to a poster address for each post? Do you want list > identity to be consistent across threads, or will you assign a new > list identity to a poster address each time they first post to a new > thread? I plan on keeping list identity of a poster constant in a thread, i.e., I generate a new list identity for a first post to a new thread. Reasons of this were mentioned by me in http://www.mail-archive.com/mailman-developers%40python.org/msg15283.html > If identity is consistent within threads but not across > threads, how do you determine that two posts are in different threads? > For example, if post B points to post A in the References field, but > the subject was changed in a significant way (ie, other than listrivia > prefixes, Re: and friends, and whitespace changes that occasionally > creep in due to mishandling of folding whitespace), are they in > different threads? I had been following this topic on discussions list by Aanand Shekhar Roy and had also read about it online as I had realised that grouping messages in threads is a trivial necessity for my implementation. Hence we will not be relying on the subject header of a mail because of the problems you have mentioned. So, we will be using the In-Reply-To header of the mail to map the messages to their respective threads. Hence tweaking with subject will not be treated as a new thread as long as the user is using Reply-To feature, which is essential while conversating in a thread. Also using references won't be reliable as after the length of thread becomes large few entries from the references are dropped > > 2) Not allowing any way out for revealing any one's identity except > > if the user chooses to reveal it himself. > > That's not a reasonable requirement. It is often possible to deduce > an author's identity from their choice of argument or writing style, > or their employer's automatically added footer. You could argue that > message content is a user choice, but I don't think many users would > be happy with that point of view. > > I think you want to limit yourself to stuff that MUAs and MTAs put in > the headers, including but not limited to originator addresses, > display names, and comments. Speaking of "originator", what do you > propose to do about non-subscribers who are CC'd? > We can remove the CC and BCC fields as if sent to a non-subscriber using CC the original id of the originator will be displayed and if a subscriber is CC'd then the mail bounces as posting address is a fake address. The originator can use one of the many available anonymous mailer services for personal anonymous mails. > You might also propose removing standard signatures (ie, everything > after a string matching "\n-- \n"). > > Removing other footers is much more chancy, but you could try to catch > them. > Yes, we can modify all footers and signatures in handlers. > I'm not sure that requirements 1) - 3) are a good fit for several of > your use cases, but these requirements seem like a reasonable start. I'll try to improvise on this part. Regards Rashi

2 3

Contributing to GNU Mailman (GSOC '15)
by Ankush Jindal 14 Mar '15

14 Mar '15

Hi Sir, I am Ankush Jindal, pursuing Computer Science from IIT Mandi, India. I have hands on with both python and javascript. I would definitely want to work this summer for GNU Mailman. I however, would like to suggest a modified version of already proposed project(s). I went through 16 Brainstorm Ideas For Mailman’s Web Interface <http://blog.linuxgrrl.com/2012/03/13/mailman-brainstorm/> and I thought of integrating point 6, 9, 11, 12, 13 and 14. That is, I am picturing mailman with- A) User Profile ( http://wiki.list.org/DEV/Google_Summer_of_Code_2015#Subscriber_profile_pages ) B) Admin Page ( http://wiki.list.org/DEV/Google_Summer_of_Code_2015#A_Dashboard_for_Admins.… ) C) Give more UX controls to the mail list like timeline, metadata, user and post filtering and anonymous posting ( http://wiki.list.org/DEV/Google_Summer_of_Code_2015#Anonymous_lists, this could be a stretch goal) However, I have a little hesitation that I am a little late in discussing the project and I am really sorry for it. I promise to make it up to you, if you could advise me some particular warm-up tasks or some other exercise that you require from me, given the time-frame, I would be more than happy to do so. Do give remarks to this bunch of projects. Looking forward to it. -Ankush Jindal Student, IIT Mandi, India Phone: +91-9805901195 Github: travis-bickle

1 0

Fwd: GSoC 15
by Shreyas Lakhe 14 Mar '15

14 Mar '15

Hi, 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 Suggestions on it are welcome. Thanks, Shreyas Lakhe

1 0

Regarding Subscribe/unsubscribe policy for lists Edit
by Ashish Kumar 14 Mar '15

14 Mar '15

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. Thank you Ashish Kumar

1 0

Re: [Mailman-Developers] Regarding Subscriber profile pages project
by Abhilash Raj 13 Mar '15

13 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 13 March 2015 05:25 PM, Ashish Kumar wrote: > Hi, > > From the description, I think we need to complete following steps: > 1. Create a form to take user information. 2. lists in which user > want to show its user info 3. Option for user to select lists to > share user info Yes, we would need 1) since persona authentication just gives us subcriber's email address. But that obviously needs to be only optional. Also, 'Profile Pages' would list his subscriptions and other information so that needs to be added too. > We need to add tests also for verifying each logic. Can someone > please correct me If I am right about my assumptions. > > I have a question if there is any special interface required for > list moderator or owner? Yes, but that is altogether another project idea, the Admin/Mod dashboard one. - -- thanks, Abhilash -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVA9NZAAoJEJ2bK6Bh0KZ8aqEQAMHB6npY+8bzMSI9AxzUtOU7 TT3lIt7h17D78DLAkAt0+Q/TNeD4OV3eoApCizfIKraoAbgHAepWvz21jkOxRXb7 jRSAa4oskJ2Qq/zZBfIXIO1f5ImjaBMx/flHhatzTSJ5t5KG58N872tHKgWXaLAn IK8oxdM3gZQbXju0NaJoEBU14XiyBM4vSdAz7LfZx1QLlyK9uo/wt4YlTfG5gBHo 8qEyoplOv1QSIXCerUPw/Q3Y4SaGbtL7wRGScVj9BH6b0SaQx7aEGTH/QKXwZxIo DIKdE5jY/3MufMkzxLOW43V2FA7OycwSipeqZ42n3w1BO1WLba7+FRIo8vdoBF5/ 1zEMmjCP5ffk3NH5j2dJTrfUqtwydxZfyoKxm3AkyXKN18N7tv1fGtr+LdL6tkIA lQN/zDiq4Koi4H9H7YkIryCeX3bRyC8FcCEquJ8K0KqiJbrD43yD+bJv+pBKOzXv /ttuHXmExGnvnln9bJnmdgVbw9PgFQzCTdWiYy2RRy+5kGC7WPgXX/JHBdzvSF2A HoqrAA17Td5BIeQAit3o4z4JapASDw7FmEm9lB2zKUlgBwv2Hj2SHeDmPHjtwW60 oGL0bnAa0eknZ2bfJRgTyb6ddrJLF20PXLU/uCj3nPVhr0k0PhpQdvL8i6PEJuf5 gen7YUNUZLkwop1/Q+99 =2fHq -----END PGP SIGNATURE-----

1 0

Re: [Mailman-Developers] Regarding Anonymous lists
by Abhilash Raj 13 Mar '15

13 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ashish, On Friday 13 March 2015 05:20 PM, Ashish Kumar wrote: > Hi, > > In Anonymous list project, We need to implement a strong > cryptographic algorithms which encrypts the coming email address > and store the encrypted code and before sending email to these > lists we need to decrypt the encrypted code and then send the mail > to original one. > > We can make use of hashsalt type techniques for password storage. > > Can someone acknowledge If I am right about it. If you are following the discussions on mailman-developers about discussions on project ideas, in your case particularly Anonymous List project, you'd know that encryption is not required to make someone anonymous on mailing lists. You just need to hide their real identity from other subscribers. Please read through the archives for other details. - -- thanks, Abhilash -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVA9IuAAoJEJ2bK6Bh0KZ8b10P/iw1ZN9nMfB2h0DcTgL29RKr LhTdvmqM1DfDJkUwIaSgCQTDB73lAyaW+BaBkcayx8s42Y1/KWWK2KCCzOiRelbd ETk37kYRXKOjGpYYMYRzScT7q8xl91DgLT2ghvL4/UkPWq/li2P9eyrtoYMHRGUj mwBgWgzls41ZMLu7To5DprtUGcjLPeG/5FPlWhE37HpVhfETI1yv6KE+c1sMzvnd BvVuuald3Wlvsj7tXYbYCTrxo4yCSCXzMClnrdn7CSrltsH6nmO9+2h1xRA/iq87 GjarSyvRrGUakdkIyiiIYlXx8un3YEAsC2FJU//6Bo6w5SkkhmZDjgSVEEWWz0sW tRWgR8Ahhsbsj4El23R5zgDF0nQnOtbeD3zG56EWAP7yq1h2vPELmyT3J5GwbgNI p7AY70nsi1zbt8ebQc6SkPvX6rv96sPomrLXTh3UNjPTIjSjK8mvz98qc4X6lT9s 5+AvIz7VWUfYioawp91cHCI7Y6LNpVdSICzyIhcpzuQsQEwWrsZ4IYQVZs058hgX w7CW/M+lyDbzNrkk9ImHawgs2noyCq5K/J4torn0RWFufAF6jE15o+CLYCp1/oGe uNhQq8L35GlJ7mK9GW33ZIfMmVDx55DHdk+eUZIvqG2aROv1QJVdDMVv+8P+TdVF JNnZ2ngBIe9wQJ/PLYq1 =9WGD -----END PGP SIGNATURE-----

1 0

Re: [Mailman-Developers] GSOC 2015: Seeking Information
by Abhilash Raj 13 Mar '15

13 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Nakul, On Saturday 14 March 2015 05:50 AM, Nakul Gulati wrote: > Hi, > > I am a undergraduate student pursuing Computer Science from NIIT > University, Neemrana, India. Currently in my 3rd year I'm expected > to graduate in summer 2016. > > I have experience in working on a variety of projects and have a > wide skill set with skill proficiency ranging from moderate to > high. The following is the link <http://goo.gl/UNLshD> to my > resume for more information about me. > > 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. As you would have already read in the Ideas Page, this project requires you to implement mailman.client in Javascript with proper npm integration and test framework. You may not implement each and every API in the summer, but the production quality code and good testing framework is a must. Also, as a part of application process you'd have to fix atleast one bug in any of the mailman projects listed on the Ideas Page. In case you have doubts, you are welcome to discuss it here or on the #mailman channel on Freenode. - -- thanks, Abhilash -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVA8xiAAoJEJ2bK6Bh0KZ8KY8QALesfYLgpr0Q5qRhBBYhnhcM 7PLtg23i9s0e7QTGCVthyR0Y1fEWYtnBj7l6gxGX8Mftw1/rmouWwP/sfqKCSrGb XLJZBMpiSkoLtW4MhV/AI2pnocXNx4Zr6lBJiregPYq/SxP6BP2vWHhUIkE4kSUi /1LH3IwOV+AZ87ekoPq9fydNq4wNGaqPcPmeGqRHClip9kO5bOg9TXXnl5xuvBLw SO746/Tf5DfvSubdAGCrrZzFzn2WXl/4xO7N5CmZOvDeJh18YoRBcioW/5Ye6eqP BeWKkbUFcDr1hVk2px6skq52OEAgm/Byl/llwuLpX8u8CxhAbxFKQnvbmj/5f2jK 1gK+0/a3qyfocYH2Ai04zgEuQ3qh2zGHgfamtDVeCuyuBHxpVYPY2VYPYTr3TnXI VrKSAGk5f3ATj4Oc1Qq1yFuPJNTrUjH3ucP2lr3tjPLo1UMV2ZXro96ZerpRSYFi VwPwJFUa33r0mEwMAMg+Y+9qS7hFR+SGZ00diLztnEe5MyyM2zynLLjC5Cflnz8W IpWOyJvQIyAgaipmDZ5tsCL5YxAOtuWp/QJPfEijhh6EDzTrigUVvAXEkNdkEwGb rUbtc3dCygPio27Ky+fT0fnT9Wb/2MaV2lRYXibPdsUKpamrNVF5ntqm10XAu2c4 dVzxfFJGxVtxmuzvowMz =kKI+ -----END PGP SIGNATURE-----

1 0

Discussion about Mailman plugins(GSOC 2015)
by Stephen J. Turnbull 13 Mar '15

13 Mar '15

Prakash kumar writes: > As mentioned on the ideas page I read the working of both chains.py > and pipelines.py and understood the basic architecture of mailman. I'm really having trouble with this interest in "plugins" as opposed to "rules for chains" and "handlers for pipelines". To install a rule or handler is a three-step process done by the site administrator: 1. Write or download a module containing some code using a simple plugin API; the code has access to all Mailman features. 2. Save/copy the module to .../rules or .../handlers. 3. Configure the global pipeline in mailman.cfg or individual pipelines in list configurations. That looks rather "pluggable" to me. What does a "plugin" give that improves on this process?

2 1