Mailman 3 March 2015 - Mailman-Developers

Query regarding plugin integration with mailman3
by Aanand Shekhar Roy 01 Mar '15

01 Mar '15

Can someone tell me if the following way is suitable for implementing a plug in on mailman3 : A folder contains all the .py codes needed to implement the plugin feature aimed. In that folder we make an executable file i.e. .sh file, which runs the script that adds the code mentioned above in the right places of mailman3 src code. Regards, Aanand

2 1

Re: [Mailman-Developers] MIME footers
by Barry Warsaw 01 Mar '15

01 Mar '15

On Feb 27, 2015, at 11:46 AM, Murray S. Kucherawy wrote: >How absurd would it be to propose a flag for Mailman that would take your >first case (non-MIME, or single-part text/plain) and convert it to a >multipart/mixed with a child part of the original text/plain, and then >apply the algorithm you have? [...] > >What I'm worried about with such a design is the trivial text/plain >message. Obviously merely appending the footer destroys any hope of >validating only the original content. We'd have to entertain the idea that >Mailman would make the simple message into a multipart/mixed + text/plain, >then append the footer part and sign that; the verifier would drop the >footer and then strip off the MIME to see if it can verify the original >signature that way. That seems like its easy to get wrong, though it's >likely to be a very common case. The biggest downside, and probably the main reason we append the footer text in the text/plain-compatible-charset case is because of crappy MUAs. I think we *still* get complaints about the MIME composition not being rendered very well. Their MUAs will show them attachments without the message content they actually care about. I wish I could say "fix the MUAs" but that's probably been futile since the day email was invented. ;) That said, it's not a totally unreasonable suggestion. I wonder if it makes sense to have that be a user option (then, what's the default, what a standard says, or whatever minimizes user complaints). Cheers, -Barry

4 4

Query regarding ambiguous behavior of REST API due to case-sensitivity of email addresses
by Ankush Sharma 01 Mar '15

01 Mar '15

Hello people, I want to report an issue in Mailman core that drives a bug in the Mailman REST API. I was testing Postorius's *mass subscribe* feature. When an email address associated with an already existing member is used for subscription, the REST API returns a 409 code saying `Member already subscribed` which is good. But, when we use the same email with some letters in different cases, the REST API returns `500' i.e server error occurred which should also return `409`. The Mailman core raises the error *User should have had linked address*, i.e a 500 error code occurs. The screenshots of the above issue:- Case-insensitive email usage: http://postimg.org/image/qgl2piepj/ http://postimg.org/image/s5u5xkuev/ Case-sensitive email usage: http://postimg.org/image/okyaecpvb/ As far as I can understand from the mailman docs http://gnu-mailman.readthedocs.org/en/latest/src/mailman/model/docs/address… <http://gnu-mailman.readthedocs.org/en/latest/src/mailman/model/docs/address…> mailman keeps all email addresses in small cases internally. I tested this again using CURL and REST clients and found that the REST API is failing to return `409' in the latter case. That is, something is wrong with mailman core. Later, I dug in the Mailman core and found out the following things: 1. In /src/mailman/app/membership.py `add_member` function uses *user = user_manager.get_user(email) *to check if the user corresponding the email address already exists or not. Here email is in *preserved case *and it returns the user associated with this email address. Here it does not matter if the email is in *lower case *itself. 2. Later on, in the same function the following code checks if the email is matched: *for address in user.addresses:* * if address.email == email:* * break* Here *email* is in *preserved case* while *address.email *returns a lower case version of email and an *unmatch* occurs. ( sam(a)gmail.com and SAM(a)gmail.com do not matches ofcourse ) But, the thing confuses me is the *assertion error* in case of an unmatch, *User should have had linked address.* What does it signify, as you are using the same email to get the user object and later on matching should be done by bringing the *passed *email in the *lower case *too, i.e ( SAW(a)gmail.com should be brought down to sam(a)gmail.com ) *for address in user.addresses:* * if address.email == email.lower():* * break* It also makes the REST API return `409` in both cases and it should return it too. I have filed a bug ( Bug #1425359 ) for this. I may be interpreting things wrong. In case if it is an architectural aspect related to Mailman core, please explain. In case it is a bug in real, I would love to submit a patch for it. Thanks, Ankush Sharma github.com/black-perl

1 0

Full anonymization
by Rashi Karanpuria 01 Mar '15

01 Mar '15

I have tried to answer the questions listed below. > 1. Who can be trusted? > 2. Who needs to be anonymous? > 3. What are the social threats if anonymity is breached? > 4. What are the technical threats to anonymity (ie, how can it be > breached)? > > >> [1]: >> 1. *Alcoholics list*: >> Here alcoholics suffering and willing to give it up share their >> issues >> and seek help from the community and people of the same type. Trust >> though could act as a plus point here as we are handling a social issue. >> But it still meets its purpose without involving trust as the major work >> is to arrive to a solution and meet people of your type and share the >> pain and get cured. > > Answers: > > 1. The list-admin needs to be trustworthy for starters. The situation > could be > that there is one single person who can be contacted to join this list > (who knows the original email of each user). > > 2. All the subscribers are anonymous among themselves. > > 3. Social implications of breach may be loosing your job? > > 4. The list-admin can be threatened to reveal the identities of > subscribers > (or single subscriber). >> 2. *therapy group*: >> Controlled by the doctor and as he knows everything being the >> list >> moderator he can better help his patients allowing them to mingle >> anonymously and as above it serves the causes aimed at. 1. The list admin needs to be trusted who is the doctor in this case. 2. The patients want to remain anonymous. 3. If anonymity is breached,the doctor loses trust, his shop closes obviously but we can't overlook the mental torture patients will undergo. 4. For eg :the therapy group is for helping psychopaths .The doctor maybe threatened by federal officials if they are in a search of a compulsive killer , they would want to know the details of the specific anonymous users coming under suspicion.(eg. if a patient is discussing his compulsive killing behaviour , they would want to know him for investigation) >> 3. *Drug Peddlers group or mafia asso.*: >> Although we are not aiming at helping this section of people but >> just a >> thought! The king pin is the head and so is supposed to know everything >> but the workers below him need not know him or the co workers. 1. The mafia head (as the list admin) needs to be trusted. 2. The peddlars or workers here need to be anonymous from each other and the head should be anonymous too from the workers. 3. If anonymity is breached in this case it would only benefit the society and the police. 4. First of all it is meant to be a private list so as to bound the subscribers (so only gang members are allowed a subscription) .Also it is hard to catch the mafia let alone threaten him to expose the subscribers :p >> 4. *Whistle Blowers*: >> As mentioned it works on proofs and not trust. Suppose a media house maintains such list where people subscribe to know or to expose ill practices all possible organizations. 1. Here the list admin is the head of the media house needs to be trusted. 2. The whistle blowers need anonymity. 3. The whistle blowers can be fired or fined to expose these matters 4. Technical threats are bribing or threatening the list-admin. >> 5. *Pope Confessions*: >> Similar functioning to therapy group. 1. Pope as the list-admin needs to be trusted 2. Confessors need to be anonymous 3. Confessors might be harassed and Pope might not be trusted again 4. Police or the orthodox might threaten him to reveal the confessors' identity >> 6. *Battered wives*: >> Suffers as if the list moderator knows the users (here wives not >> interested in revealing identities to any one) who will she be so that >> the wives (users) should trust her. Suppose there is an NGO who maintains such a list where the subscribers are specialists of that matter and the suffering wives 1. The NGO head needs to be trusted 2. The wives wish to remain anonymous 3. If the anonymity here is breached NGO loses the trust and it won't remain as a favourable choice anymore. 4. Police may wish to find the assaulters under which the wives are suffering in order to punish them so they may force the NGO to reveal. >> 8. *Teacher Student feedback and discussions*: >> College/School authorities are the list admins and moderators >> here. And >> in such a list lesser the trust better the feedback ;) 1. Institute authorities are the list-admin here and they are trusted 2. Students need anonymity 3. Teacher-Student relationships are spoiled and the teacher might get biased towards that student, 4. technical threats are not expected in this case Regards, Rashi

1 0

Re: [Mailman-Developers] full anonymisation
by Abhilash Raj 01 Mar '15

01 Mar '15

Hi Rashi, On 28 February 2015 at 12:39, Rashi Karanpuria <2013165(a)iiitdmj.ac.in> wrote: > Trying to hide things from list moderator may be a futile approach in case > of mailman, though allowing list moderator to be the supreme boss > decreases the no of user cases it serves for eg. a complaint/suggestion > list in organization mailing lists may end up useless as the head would > know who criticized him but it still covers many critical use cases. > Coming to the present approach we were wondering if trust was more > important than being anonymous I listed the use cases [1] and concluded > that being anonymous is a major feature than being creditable. As in the > whistle blower use case we were discussing, the concern was if we don't > keep the same fake id for an exposer, people won't believe her. But in my > opinion even if she keeps the same fake identity people won't believe her > until she proves or shows that she is telling the truth because the matter > she is exposing is critical and delicate and works on proofs. First thing, I guess you have used list-admin and list-moderator interchangeably. You should know that there are three roles: 1. List Admin 2. List Moderator 3. Site Admin You should be clear about the differences between these three. Next, try to answer four questions for each use case that Steve mentioned: 1. Who can be trusted? 2. Who needs to be anonymous? 3. What are the social threats if anonymity is breached? 4. What are the technical threats to anonymity (ie, how can it be breached)? > [1]: > 1. *Alcoholics list*: > Here alcoholics suffering and willing to give it up share their issues > and seek help from the community and people of the same type. Trust > though could act as a plus point here as we are handling a social issue. > But it still meets its purpose without involving trust as the major work > is to arrive to a solution and meet people of your type and share the > pain and get cured. Answers: 1. The list-admin needs to be trustworthy for starters. The situation could be that there is one single person who can be contacted to join this list (who knows the original email of each user). 2. All the subscribers are anonymous among themselves. 3. Social implications of breach may be loosing your job? 4. The list-admin can be threatened to reveal the identities of subscribers (or single subscriber). Can you try to answer similarly for the other cases? > 2. *therapy group*: > Controlled by the doctor and as he knows everything being the list > moderator he can better help his patients allowing them to mingle > anonymously and as above it serves the causes aimed at. > 3. *Drug Peddlers group or mafia asso.*: > Although we are not aiming at helping this section of people but just a > thought! The king pin is the head and so is supposed to know everything > but the workers below him need not know him or the co workers. > 4. *Whistle Blowers*: > As mentioned it works on proofs and not trust. > 5. *Pope Confessions*: > Similar functioning to therapy group. > 6. *Battered wives*: > Suffers as if the list moderator knows the users (here wives not > interested in revealing identities to any one) who will she be so that > the wives (users) should trust her. > 7. *Tax Evaders*: > Trust here is not required as people believe if the method worked. If you > need trustworthy methods why would you subscribe to such a list. And even > if this list has trust in the form of permanent fake ids the person after > suggesting correct methods first and then lay the traps so people still > can't trust anyone here. > 8. *Teacher Student feedback and discussions*: > College/School authorities are the list admins and moderators here. And > in such a list lesser the trust better the feedback ;) > -- thanks, Abhilash Raj

1 0

Re: [Mailman-Developers] GSOC 15 Interested in project Mailman client written in Javascript
by Abhilash Raj 28 Feb '15

28 Feb '15

Hi Kiran, On 28 February 2015 at 14:42, kiran ps <pskirann(a)gmail.com> wrote: > Hi, > > I'm an Engineering student(computer science) pursuing my degree from > Government Engineering College(Calicut University), Thrissur, India. I went > through Mailman gsoc idea list.I'm interested in the project Mailman client > written in Javascript. > I have good skills in JavaScript, nodejs, angular, python. Right now Mailman3 has only one REST Client which is written in python[1]. This project would involve creating something similar to it in JS. You can get started with mailman by setting up a dev environment using the docs and then try fixing some beginner friendly bugs. You can find links to everything in the wiki page itself. [1]: https://launchpad.net/mailman.client -- thanks, Abhilash Raj

1 0

Mailman 2.1.19 release
by Mark Sapiro 28 Feb '15

28 Feb '15

I am very pleased to announce the release Mailman 2.1.19 final. Python 2.4 is the minimum supported, but Python 2.7 is recommended. This release has several new features, some newly implemented and some backported from the now truly defunct 2.2 branch - there is nothing left in that branch that isn't in this release. There are also bug fixes. See the attached README for more details. Associated with those changes are many things that have i18n impacts including new and modified strings in the message catalog, a new adminaddrchgack.txt template and a minor change to the admindbdetails.html template. I strongly encourage anyone with an interest in translations of Mailman to get this release and help with updating the translations. This is the final release of Mailman 2.1.19, but if I receive additional i18n updates, I will release those later. There have been a few changes since the first candidate release, some of which were in the second and third candidates. - There have been updates to the Romanian, Russian, Polish, Japanese and Interlingua translations. - Mailman's character set for both Romanian and Russian has been changed to utf-8 and Mailman's version updater has been augmented to try to find strings in the old character set in list configurations and convert them. - The admindb held message display has been improved to not break multi-byte characters and not abandon conversion to the list's character set on an invalid character. - There was a new subscribe_auto_approval feature in the first release candidate and this is augmented to accept the @listname syntax. - Organization: headers are now removed from posts to anonymous lists. - The display of real names on the list roster added in the first release candidate has been made conditional on a new ROSTER_DISPLAY_REALNAME mm_cfg.py switch that defaults to No due to privacy concerns. Information on these and other changes in this release are in the attached README and in the NEWS file in the release tarball. Mailman is free software for managing email mailing lists and e-newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, please see: http://www.list.org http://www.gnu.org/software/mailman http://mailman.sourceforge.net/ Mailman 2.1.19 can be downloaded from https://launchpad.net/mailman/2.1/ http://ftp.gnu.org/gnu/mailman/ https://sourceforge.net/projects/mailman/ -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 0

GSoC 2015: brainstorming ideas suitable for beginners?
by Terri Oda 28 Feb '15

28 Feb '15

Hi all, In my role as org admin for Python, I'm trying to make sure we have more beginner-friendly ideas on the GSoC pages, and Mailman's among the groups that doesn't have any. How embarrassing for me as a Mailman developer. ;) It's also a problem for Mailman if we're applying as a separate organization, as Google seldom allows orgs unless they have a reasonable number of ideas suitable for open source newbies. (The idea behind this is that many students are very new to Open Source and we want them to at least get something out of the application process, learn how to set up their environments and learn about what it takes to get hired as a GSoC student. Even if they don't make it in their first year, they'll be much more ready for later years!) I'd love some help brainstorming some actual beginner-friendly ideas, though, because I'm currently all idea'd out. Anyone want to suggest some simpler things they'd like to see in Mailman that we could maybe put on the list? Suggesting and idea does not mean you have to volunteer to mentor them, although I'm always looking for new mentors too! Terri

10 25