From anirudhdahiya9 at gmail.com Thu May 5 08:45:47 2016 From: anirudhdahiya9 at gmail.com (Anirudh Dahiya) Date: Thu, 5 May 2016 18:15:47 +0530 Subject: [Mailman-Developers] GSoc - Blog Posts Message-ID: Hi I have updated my blog with a few posts about my experiences while applying for GSoC and explaining my proposal. I welcome everyone to have a look, opinions/suggestions welcome in the comments. codefullofsummer.blogspot.in Cheers Anirudh Dahiya (irc spark) From anirudhdahiya9 at gmail.com Sat May 7 06:44:07 2016 From: anirudhdahiya9 at gmail.com (Anirudh Dahiya) Date: Sat, 7 May 2016 16:14:07 +0530 Subject: [Mailman-Developers] Message queue based archiver - Requesting opinions/suggestions on design architecture Message-ID: Hi I am working on implementing message queue based archiving system as part of my GSoC project. Just yesterday, me and Florian(my mentor) were discussing possible architectural choices, and decided to approach the mailman-developer community for opinions. Right now, the archiving happens something like this - [image: Plugin.png] We were discussing the architectural design for the proposed system to be plugged. We considered two choices - I. The first one we looked at involved an additional interface between the backends and IArchiver. The job of this interface would be to decide to which backend to approach for a particular archive, and subsequently send the mail to that backend. The advantage I saw here was that archives/webapps that would be developed in future would then be able to attach to the our system, and not disturb IArchiver. II. To this, Florian suggested, and I realized later after some thought, that choosing backend + the archive right at the IArchiver stage seems more sensible. This information can be stored in mailman.cfg, following the current way it works for archiving. It seems more simple and follows the way archiving is done up untill now. I later realised that since we'll have to add info about which archive subscribes to which mailing lists(actually stored the other way round), in our first design, we would eventually have to add information at the "Our interface" level. Thus better to do all this at one place, i.e. the IArchiver interface level, which the second design proposes. One thing I learnt from reading backends' documentation is that they encourage several clients(archives in our case) plugged into the same message queue system, rather than defining a queue system for each archive. This saves space, and processor time(for the backend server running in the background). These are our thoughts, I'd love to hear opinions and suggestions to design choices. Regards Anirudh Dahiya (irc spark) From anirudhdahiya9 at gmail.com Sat May 7 15:41:38 2016 From: anirudhdahiya9 at gmail.com (Anirudh Dahiya) Date: Sun, 8 May 2016 01:11:38 +0530 Subject: [Mailman-Developers] Facing build Issues Postorius Message-ID: Hi I updated my builds and am facing the following error : InvalidTemplateLibrary: Invalid template library specified. ImportError raised when trying to load 'postorius.templatetags.membership_helpers': cannot import name MailingList I tried building on my other machine and faced the same error. Complete traceback : http://dpaste.com/3WG8XQ5 Thanks Anirudh (irc spark) From simon.hanna at serve-me.info Sun May 8 14:12:19 2016 From: simon.hanna at serve-me.info (Simon Hanna) Date: Sun, 8 May 2016 20:12:19 +0200 Subject: [Mailman-Developers] Facing build Issues Postorius In-Reply-To: References: Message-ID: <9ea4e2a8-9371-ebce-88d7-86bdf618e1a9@serve-me.info> On 05/07/2016 09:41 PM, Anirudh Dahiya wrote: > Hi > I updated my builds and am facing the following error : > InvalidTemplateLibrary: Invalid template library specified. ImportError > raised when trying to load 'postorius.templatetags.membership_helpers': > cannot import name MailingList > I tried building on my other machine and faced the same error. > Complete traceback : http://dpaste.com/3WG8XQ5 > Thanks > Anirudh > (irc spark) I guess it's caused by an out of date mailmanclient installation inside one of your virtualenvs. Can you try clearing them out? The issue is caused by the following import: from mailmanclient._client import MailingList This import should not be there. We should not import via "private" things. Currently the MailingList is imported for additional functionality, but it's not actually being used inside Postorius. I guess a safer option would be to use postorius.models.List instead. We should be using these classes inside Postorius anyway. From harshitbansal2015 at gmail.com Mon May 9 15:51:10 2016 From: harshitbansal2015 at gmail.com (Harshit Bansal) Date: Tue, 10 May 2016 01:21:10 +0530 Subject: [Mailman-Developers] Blog Message-ID: Hi, I have been a little bit inactive these days as I am stuck in my end semester exams. However, I have been able to take out some time and update my blog with a few posts explaining my proposal and my experiences of GSOC. I invite all of you to have a look at my blog here: https://contributingtofoss.blogspot.com/ Comments/suggestions are most welcomed. Thanks, Harshit Bansal From aditi.medha96 at gmail.com Thu May 12 07:06:54 2016 From: aditi.medha96 at gmail.com (ADITI GUPTA) Date: Thu, 12 May 2016 16:36:54 +0530 Subject: [Mailman-Developers] Systers Mailman3 Message-ID: Hello, I am Aditi Gupta. I got selected for GSoC'16 Systers Mailman Project. I cloned systers repositories of mailman3, mailmanclient, postorius and hyperkitty from github. Also, I cloned the postorius_standalone and hyperkitty_standalone from gitlab for testing purposes. On running setup.py in postorius_standalone , I am getting deprecation warning because postorius of systers is using older version of Django. Also,I am getting "ImportError: No module named middleware". This is the traceback : http://pastebin.com/D1c4XCHe Regards, Aditi -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2016-05-12 16:33:16.png Type: image/png Size: 98270 bytes Desc: not available URL: From simon.hanna at serve-me.info Thu May 12 10:43:08 2016 From: simon.hanna at serve-me.info (Simon Hanna) Date: Thu, 12 May 2016 16:43:08 +0200 Subject: [Mailman-Developers] Systers Mailman3 In-Reply-To: References: Message-ID: <49360769-98b6-aa70-f639-879403814305@serve-me.info> On 05/12/2016 01:06 PM, ADITI GUPTA wrote: > Hello, > I am Aditi Gupta. I got selected for GSoC'16 Systers Mailman Project. Congrats. > I cloned systers repositories of mailman3, mailmanclient, postorius and > hyperkitty from github. Their versions are OLD! It doesn't look like they contain any changes. You should consider creating forks on gitlab so you can keep up to date and submit merge requests once in a while. > Also, I cloned the postorius_standalone and > hyperkitty_standalone from gitlab for testing purposes. postorius_standalone and hyperkitty_standalone are synced with their respective repositories on gitlab. They don't care about versions and releases (for now, maybe for ever). You shouldn't use them with anything other than the master branches of the gitlab repos. > On running setup.py > in postorius_standalone , I am getting deprecation warning because > postorius of systers is using older version of Django. There is nothing to install in postorius_standalone. It doesn't even contain a setup.py Also if they are using an older version of django there is nothing we can do about it. We are currently supporting what django supports. That is versions 1.8 and 1.9. All other versions are considered insecure! I don't think anyone will support you with any forks of the main repository. You should follow the official wiki and adhere to it, if you want people here to help you. https://wiki.list.org/DEV/Home The setup instructions is probably what you are looking for https://wiki.list.org/DEV/SetupDevEnvironment > Also,I am getting "ImportError: No module named middleware". Use the latest versions, and if you still run into issues, I'll help you work them out. (You might want to try the irc first to see if someone is available) > This is the traceback : http://pastebin.com/D1c4XCHe Screenshots are pretty useless FYI. :-) Simon From aditi.medha96 at gmail.com Fri May 13 04:19:11 2016 From: aditi.medha96 at gmail.com (ADITI GUPTA) Date: Fri, 13 May 2016 13:49:11 +0530 Subject: [Mailman-Developers] Regarding System set up Message-ID: Hello, I am trying to set up the environment on my system. On running python manage.py runserver in postorius_standalone, I am getting the following error. Traceback : https://www.irccloud.com/pastebin/WeKBXjGx/ Regards, Aditi From adityadivekar03 at gmail.com Fri May 13 05:52:47 2016 From: adityadivekar03 at gmail.com (Aditya Divekar) Date: Fri, 13 May 2016 15:22:47 +0530 Subject: [Mailman-Developers] Regarding System set up In-Reply-To: References: Message-ID: Hi! It seems you ran into the error due to the incompatible falcon version. You should have falcon==0.3 installed for the setup to work for older Mailman versions. However, this error doesn't occur with the latest Mailman version 3.1.0 So you should upgrade your Mailman version and the issue would be solved. You can pull the Mailman master branch from Gitlab and then re-run the setup. Aditya. From stephen at xemacs.org Sun May 15 13:18:53 2016 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Mon, 16 May 2016 02:18:53 +0900 Subject: [Mailman-Developers] Regarding System set up In-Reply-To: References: Message-ID: <22328.44925.823127.349750@turnbull.sk.tsukuba.ac.jp> By the way, Aditi is my student under the Systers org. Please take good care of her! Thanks to Simon and Aditya for getting started already! :-) Aditya Divekar writes: > It seems you ran into the error due to the incompatible falcon version. > You should have falcon==0.3 installed for the setup to work for older > Mailman versions. > > However, this error doesn't occur with the latest Mailman version 3.1.0 > So you should upgrade your Mailman version and the issue would be solved. > You can pull the Mailman master branch from Gitlab and then re-run the setup. I would recommend that you have two full suites locally, something like gsoc2016 -+--- gnu ---+- mailman | | | +- mailmanclient : : | +- bin, include, lib for venv | +- systers -+- mailman | +- mailmanclient : +- bin, include, lib for venv This will allow you to configure each suite appropriately. The systers venv at least, and possibly the gnu venv, should *not* use --system-site-packages, so that you can have private and fixed versions of external packages like Falcon and Django. This will cost some disk space, but measured in 10s of MB I suppose. From simon.hanna at serve-me.info Tue May 17 05:15:14 2016 From: simon.hanna at serve-me.info (Simon Hanna) Date: Tue, 17 May 2016 11:15:14 +0200 Subject: [Mailman-Developers] Translating notifications raised by mailman-core in postorius Message-ID: Hi, Currently Postorius handles form submissions like this: 1. Check to see if inputs are malformed, raise error if so 2. Submit to mailman-core and see what the response is. - ConnectionError: Mailman-core is unreachable, display error message - Success: Display some success notification - HttpError: This happens when mailman-core rejects the request for some reason. Currently the HttpErrors are passed without modification to the user in a notification. Postorius should have some way of translating these. We can't translate the raw messages because they sometimes contain specific strings like emails and it would require us to manually add the strings to the .pot files. Theoretically the core could translate the messages before passing them to postorius. This would require core to know about the language it should translate to. I don't think this is a very good approach because we would have to make sure we offer the same languages for core and postorius and I'm not sure how we would pass the languages to core... I propose core to return an error code with each request. That way postorius can add strings for all the errors that it cares about and translate them accordingly. This would require an api change. Since 3.1 would change the api anyway, it would be nice to include the changes there. What do you think of my proposal? Do you have a better idea? The specifics have to be worked out of course. Simon From simon.hanna at serve-me.info Tue May 17 09:31:33 2016 From: simon.hanna at serve-me.info (Simon Hanna) Date: Tue, 17 May 2016 15:31:33 +0200 Subject: [Mailman-Developers] [Mailman-i18n] Translation of Mailman 3 In-Reply-To: <22296.16208.742523.449355@turnbull.sk.tsukuba.ac.jp> References: <570D766A.9040509@serve-me.info> <570D7892.3000207@msapiro.net> <20160420095815.0f175625@subdivisions.wooz.org> <22296.16208.742523.449355@turnbull.sk.tsukuba.ac.jp> Message-ID: On 04/21/2016 04:47 AM, Stephen J. Turnbull wrote: > -i18n removed, I'm not subscribed. > > Barry Warsaw writes: > > > We need a Mailman 3 translation champion, someone who understand > > the technical and more importantly, social issues involved, and can > > spend time and energy on helping bring a good story to fruition. > > I'm happy to give wide latitude to the champion to help shape a > > solution that works for us. Maybe that's you Simon? > > I can help somewhat, I know the technology, I have a "friend in the > business" (a lawyer buddy who's heavily invested in legal translation > software), I've been involved with the Mailman and Debian translation > communitiess in the past. But right now I'm "busy as Barry", and for > the near future GSoC is going to sop up most of my Mailman time. I guess I could take some sort of lead on that. I played around a little with pootle and I really like it. It's easy to use, fast and anyone that registers can start translating. The main question would be selfhosting vs using gnu's hosted version. GNU is using v 2.5. 2.7.3 is the current version which changed quite a bit. The newer version has some sort of revision support has the ability to add comments to translations. The biggest change is that adding new files/ updating them requires filesystem access in 2.7.3 So I think that GNU is going to stick to 2.5 for the time being. Selfhosting would have a couple of upsides * Easier access to generated po files (scriptable) * Easier upgrade of po files * More features (v2.7.3) pootle has a couple of features that I think are nice to have. * Offline translation support (they have a very nice peace of software called virtaal) * Terminology support (we provide recommended translations for common words) * Used by (big) organizations (mozilla, document foundation, ...) * Relatively fine grained permissions (users can get permissions based on languages as well as projects The trend seems to be to use self hosted pootle servers, at least mozilla and libreoffice do, there are probably more. I don't think selfhosting would be that hard. It's based on python+django and uses redis. If you want I can spin up an instance on my server and provide interested people credentials to play with. (existing demo instances don't allow adding/managing projects) From barry at list.org Tue May 17 10:06:30 2016 From: barry at list.org (Barry Warsaw) Date: Tue, 17 May 2016 10:06:30 -0400 Subject: [Mailman-Developers] [Mailman-i18n] Translation of Mailman 3 In-Reply-To: References: <570D766A.9040509@serve-me.info> <570D7892.3000207@msapiro.net> <20160420095815.0f175625@subdivisions.wooz.org> <22296.16208.742523.449355@turnbull.sk.tsukuba.ac.jp> Message-ID: <20160517100630.5f815773.barry@wooz.org> Hi Simon, On May 17, 2016, at 03:31 PM, Simon Hanna wrote: >I guess I could take some sort of lead on that. I played around a little >with pootle and I really like it. It's easy to use, fast and anyone that >registers can start translating. Just by way of comparison, have you played with Zanata yet? How would you compare the two systems? >The main question would be selfhosting vs using gnu's hosted version. I'd really prefer not to self-host. I don't think we're a big enough organization to commit to long-term maintenance. I'm not at all questioning your eagerness, abilities, and availability, but life has a way of throwing curve balls at us[*] and I worry about 5 years in the future if interests or availability changes. Also, I wonder if we wouldn't be giving up some economies of scale by sharing translation infrastructure with other projects. >If you want I can spin up an instance on my server and provide >interested people credentials to play with. (existing demo instances >don't allow adding/managing projects) If the i18n community wants to play with a pootle, I think that's fine. We can certainly use it to compare against other services. From my perspective, I don't have too many requirements, other than that we can upload .pot files and download .po files when it makes sense for the project, which would be disconnected from the timeline for translators to submit translations. Right now for MM2.1, Mark has to request updates timed to his releases, and I really want to avoid that. IWBNI whatever system we choose had nice git integration, but that's not required. My only other requirement is that whatever we choose be comfortable enough that translators *want* to use it. As a pretty typical monolinguist, I'm definitely not qualified to judge that. Cheers, -Barry [*] Is that a euphemism that translates outside of North America? ;) From barry at list.org Tue May 17 10:40:57 2016 From: barry at list.org (Barry Warsaw) Date: Tue, 17 May 2016 10:40:57 -0400 Subject: [Mailman-Developers] Translating notifications raised by mailman-core in postorius In-Reply-To: References: Message-ID: <20160517104057.6cbc89fe.barry@wooz.org> On May 17, 2016, at 11:15 AM, Simon Hanna wrote: >Theoretically the core could translate the messages before passing them >to postorius. This would require core to know about the language it >should translate to. I don't think this is a very good approach because >we would have to make sure we offer the same languages for core and >postorius and I'm not sure how we would pass the languages to core... Probably Accept-Language could be used to specify that, but I (think I) agree it's not the right approach. My only hesitation is to remember that Postorius isn't technically the only web front-end that could be connected to the core. If some homegrown ui also wanted translations, it's not clear how much they could leverage of existing work if all the translations lived in Postorius. >I propose core to return an error code with each request. That way >postorius can add strings for all the errors that it cares about and >translate them accordingly. This would require an api change. Since 3.1 >would change the api anyway, it would be nice to include the changes there. If we're going to return an application-specific error code (in addition to the HTTP response code we already return), then I think it means we'll be returning a JSON structure even on error conditions. Right now, JSON is only returned on success, and strings are returned on errors. If we say in API 3.1 that JSON is always returned, then we have some additional options. What makes the most sense to me would be to always return a dictionary with some well-defined keys. That at least gives us a chance to evolve the API probably without having to rev the API version in the future. One problem with returning Mailman-specific error codes is that we'll need *a lot* of them. Essentially one for every error condition in the REST API. I've always found such arrangements a nightmare to maintain and debug. Error codes have no obvious meaning so the mapping of code to meaning always has to be looked up. We could segment the error space so that there's some semantic equivalence (e.g. 01xx means a list-specific error, 02xx means a membership-specific error, etc.) but there's always some twisting that goes on the keep those up-to-date and meaningful within the semantics we give them. And it's still not enough, because as you point out, there is always going to be variable data that has to be associated with the error. A good example is when a mailing list is created within a nonexistent domain. The error reason is something like: 'Domain does not exist: example.net' which gets interpolated on the server side. So obviously an error code like 0135 won't help because you could only translate that to 'Domain does not exist' without also knowing the name of the domain that failed. So now we also have to include some variable data in the JSON response. Which leads me to think, why do we need error codes when we already have a format perfectly suited to the cause, and which we already use internally for other translatable contexts, i.e. PEP 292 strings ($-strings). Thus, our error responses could be something like: { 'reason': 'Domain does not exist: example.net', 'template': 'Domain does not exist: $domain', 'data': { 'domain': 'example.net', }, } 'reason' would always be the interpolated English (i.e. source) string. 'template', and 'data' should be obvious. We need a separate namespace for the interpolation data. A front-end could just use the English reason, or it could translate the template and interpolate the data dictionary into it. Making this change would be a lot of work, but it could be done in several branches. One branch would provide the infrastructure to return JSON error responses. These would only be done for API 3.1, and possibly you'd also want to check the Accept header to make sure the client is prepared to accept JSON. Then all of the error reporting call sites would have to be changed to pass in the template and data dictionaries, with the helpers doing the interpolation for 'reason' and the setting up of the response correctly. Then tests and documentation. :) If you like the general approach we can hash out implementation details. Given however that Pycon is near and I *really* want to get 3.1 out during Pycon and there are already at least two big features that still have to be added (unsubscription workflow and template support), it might be better to defer this to core 3.2 and API 3.2. That way, we can get it right without rushing it in. Cheers, -Barry From stephen at xemacs.org Sat May 21 03:48:22 2016 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 21 May 2016 16:48:22 +0900 Subject: [Mailman-Developers] FWD: [dmarc-ietf] Last Call: (Interoperability Issues Between DMARC and Indirect Email Flows) to Informational RFC In-Reply-To: <20160520134205.328.49041.idtracker@ietfa.amsl.com> References: <20160520134205.328.49041.idtracker@ietfa.amsl.com> Message-ID: <22336.4806.101166.450996@turnbull.sk.tsukuba.ac.jp> Hi, all This IETF work affects us all, so I'm reposting here so those with the interest can participate. "Indirect mail flows" includes but is not limited to mailing lists. "DMARC" is the protocol which Yahoo! and AOL used to unsubscribe thousands of innocent list members in April 2014. This Internet Draft is about to be promoted to RFC, so this is really the last chance to get any changes made. (You can comment on a Request for Comments, but you'll never get one changed. :-) For our purposes, "interoperability" means best practices for both email providers and mailing list operators to avoid reoccurance of that "April Fool's Joke". If you haven't participated in IETF work before, you might want to run your comments by us (or me personally, if you prefer) before sending them off to the IESG. RFC-ese is not really English. ;-) I'll be happy to provide translation of portions of interest on request. My personal opinion is that the last draft I looked at (#12) was very good, but the more eyes the better. Reply-To set to mailman-users, but personal replies to me also welcome. Please don't reply-all. Also, there is no chance that DMARC "p=reject" itself is going away, so let's not rehash that issue. Standards-geek-ily y'rs, The IESG writes: > > The IESG has received a request from the Domain-based Message > Authentication, Reporting & Conformance WG (dmarc) to consider the > following document: > - 'Interoperability Issues Between DMARC and Indirect Email Flows' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf at ietf.org mailing lists by 2016-06-03. Exceptionally, comments may be > sent to iesg at ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > DMARC introduces a mechanism for expressing domain-level policies and > preferences for email message validation, disposition, and reporting. > The DMARC mechanism can encounter interoperability issues when > messages do not flow directly from the author's administrative domain > to the final recipients. Collectively these email flows are referred > to as indirect email flows. This document describes interoperability > issues between DMARC and indirect email flows. Possible methods for > addressing interoperability issues are presented. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > dmarc mailing list > dmarc at ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > From harshitbansal2015 at gmail.com Sat May 21 17:50:51 2016 From: harshitbansal2015 at gmail.com (Harshit Bansal) Date: Sun, 22 May 2016 03:20:51 +0530 Subject: [Mailman-Developers] Authorization System in Core In-Reply-To: References: Message-ID: Hi, Earlier, while discussing the permission system for manging styles, it was decided that the permissions system should be enforced in the core rather than in the postorius since otherwise it can be bypassed(deliberately or undeliberately). But one thing that I think I forgot to discuss was that currently there is no authorisation system in the core and now I am unable to figure out that how could the permissions be enforced in the core without an authorisation system. Should I workout an authorisation system for the core first or enforce permissions in postorius only? Thanks, Harshit Bansal From simon.hanna at serve-me.info Sat May 21 18:00:12 2016 From: simon.hanna at serve-me.info (Simon Hanna) Date: Sun, 22 May 2016 00:00:12 +0200 Subject: [Mailman-Developers] Authorization System in Core In-Reply-To: References: Message-ID: <3E54FAE6-FA8C-4CCA-B942-3B09CEAC608D@serve-me.info> >Hi, >Earlier, while discussing the permission system for manging styles, it >was >decided that the permissions system should be enforced in the core >rather >than in the postorius since otherwise it can be bypassed(deliberately >or >undeliberately). But one thing that I think I forgot to discuss was >that >currently there is no authorisation system in the core and now I am >unable >to figure out that how could the permissions be enforced in the core >without an authorisation system. >Should I workout an authorisation system for the core first or enforce >permissions in postorius only? Can you elaborate a little more? What do you want to use the authorization for? Why isn't doing it in postorius safe enough? -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From harshitbansal2015 at gmail.com Sat May 21 18:08:50 2016 From: harshitbansal2015 at gmail.com (Harshit Bansal) Date: Sun, 22 May 2016 03:38:50 +0530 Subject: [Mailman-Developers] Authorization System in Core In-Reply-To: <3E54FAE6-FA8C-4CCA-B942-3B09CEAC608D@serve-me.info> References: <3E54FAE6-FA8C-4CCA-B942-3B09CEAC608D@serve-me.info> Message-ID: Hi Simon, This is the discussion that I was referring to: Harshit Bansal writes: > I think the "Permissions Systems" would have nothing to do with the > core. It would be related to Postorius. We will have to create a style > model separately in Postorius which would store the style name and the > user who created it. Then only the user who has created the style > would be granted the permission to edit it. Stephen J. Turnbull wrote: Then there is no *permissions* system! For example, one project last year created a Javascript client -- that would completely bypass the "permissions" system as you describe it. You could imagine that style changes are a "friendly users" feature, and so the "style owner" system would be a *safety* feature of the Postorius UI rather than an *authorization* feature of styles. But in an enterprise context (eg, a virtual hosting service), I'm sure that users will think of it as an authorization system. While at present it seems unlikely that there would be multiple interfaces on one hosting service, you never know what users will do[1]. Also, it would not be obvious to somebody who installed the node.js Mailman client that they are likely bypassing "security" as documented in the typical Mailman manuals and tutorials that you would find on the web. Thanks, Harshit Bansal >Hi, >Earlier, while discussing the permission system for manging styles, it >was >decided that the permissions system should be enforced in the core >rather >than in the postorius since otherwise it can be bypassed(deliberately >or >undeliberately). But one thing that I think I forgot to discuss was >that >currently there is no authorisation system in the core and now I am >unable >to figure out that how could the permissions be enforced in the core >without an authorisation system. >Should I workout an authorisation system for the core first or enforce >permissions in postorius only? Can you elaborate a little more? What do you want to use the authorization for? Why isn't doing it in postorius safe enough? -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ Mailman-Developers mailing list Mailman-Developers at python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/harshitbansal2015%40gmail.com Security Policy: http://wiki.list.org/x/QIA9 From simon.hanna at serve-me.info Sat May 21 18:54:04 2016 From: simon.hanna at serve-me.info (Simon Hanna) Date: Sun, 22 May 2016 00:54:04 +0200 Subject: [Mailman-Developers] Authorization System in Core In-Reply-To: References: <3E54FAE6-FA8C-4CCA-B942-3B09CEAC608D@serve-me.info> Message-ID: On 05/22/2016 12:08 AM, Harshit Bansal wrote: > Hi Simon, > This is the discussion that I was referring to: > > Harshit Bansal writes: > > > I think the "Permissions Systems" would have nothing to do with the > > core. It would be related to Postorius. We will have to create a style > > model separately in Postorius which would store the style name and the > > user who created it. Then only the user who has created the style > > would be granted the permission to edit it. > > Stephen J. Turnbull wrote: > > Then there is no *permissions* system! For example, one project last > year created a Javascript client -- that would completely bypass the > "permissions" system as you describe it. You could imagine that style > changes are a "friendly users" feature, and so the "style owner" > system would be a *safety* feature of the Postorius UI rather than an > *authorization* feature of styles. But in an enterprise context (eg, > a virtual hosting service), I'm sure that users will think of it as an > authorization system. While at present it seems unlikely that there > would be multiple interfaces on one hosting service, you never know > what users will do[1]. Also, it would not be obvious to somebody who > installed the node.js Mailman client that they are likely bypassing > "security" as documented in the typical Mailman manuals and tutorials > that you would find on the web. > > Thanks, > Harshit Bansal > >>Hi, >>Earlier, while discussing the permission system for manging styles, it >>was >>decided that the permissions system should be enforced in the core >>rather >>than in the postorius since otherwise it can be bypassed(deliberately >>or >>undeliberately). But one thing that I think I forgot to discuss was >>that >>currently there is no authorisation system in the core and now I am >>unable >>to figure out that how could the permissions be enforced in the core >>without an authorisation system. >>Should I workout an authorisation system for the core first or enforce >>permissions in postorius only? After reading this and your proposal, I'm wondering why you want to add the permission system in postorius. You are storing the styles in core, and grant permissions based on list/domain/site ownerships. All this information is in core. Currently mailmanclient exposes everything, not caring about permissions. You have admin rights, whoever uses mailmanclient has to manage access on their own. We currently have @list_moderator_required that we use in postorius. We are not doing anything with domain or site owners, but they should be pretty easy to implement. While in theory it would be possible to enforce permissions in core about who is allowed to call specific rest calls, this would require a lot of changes. I'm not sure we want to go this way. There are some things in core, that suggest that this might come sometime. (Users have passwords and you can authenticate them) But I guess this is somewhat legacy and will be dropped sometime in the future. From stephen at xemacs.org Sat May 21 20:30:39 2016 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sun, 22 May 2016 09:30:39 +0900 Subject: [Mailman-Developers] Authorization System in Core In-Reply-To: References: <3E54FAE6-FA8C-4CCA-B942-3B09CEAC608D@serve-me.info> Message-ID: <22336.64943.414413.97807@turnbull.sk.tsukuba.ac.jp> Simon Hanna writes: > While in theory it would be possible to enforce permissions in core > about who is allowed to call specific rest calls, this would > require a lot of changes. I'm not sure we want to go this way. Mailman is used in a lot of enterprises contexts, where the system administrators would like to distribute the components across various hosts. Also, the Mailman subscription database itself may be sensitive. Eventually we're going to have to face this issue, although maybe not now. For the styles, I don't think they're particularly sensitive. As I indicated in the quoted passage, we can simply interpret the "permissions" as a way to protect users from doing stupid things rather than an authn/authz system. In that case it's fine to do it in Postorius. > There are some things in core, that suggest that this might come > sometime. (Users have passwords and you can authenticate them) But > I guess this is somewhat legacy and will be dropped sometime in the > future. Yes, but it would be dropped in favor of OAuth or similar. From barry at list.org Sun May 22 18:54:29 2016 From: barry at list.org (Barry Warsaw) Date: Sun, 22 May 2016 18:54:29 -0400 Subject: [Mailman-Developers] Authorization System in Core In-Reply-To: References: <3E54FAE6-FA8C-4CCA-B942-3B09CEAC608D@serve-me.info> Message-ID: <20160522185429.4e6d3fee.barry@wooz.org> On May 22, 2016, at 12:54 AM, Simon Hanna wrote: >While in theory it would be possible to enforce permissions in core about who >is allowed to call specific rest calls, this would require a lot of >changes. I'm not sure we want to go this way. I've resisted this for a long time, and I may continue to do so :). I definitely consider the current REST API a privileged, administrative API for integrating known, trusted components. It should never be published on any public IP address. This isn't going to change. A while back, Andrew Stuart wrote an authenticating proxy server he called "mailmania"[1] which does exactly as Simon proposes above. It authenticates users and maps their roles to allowed REST calls. It could be exposed on a public IP and used to script the core. I'd like to either promote mailmania to a official subproject, or fork it, clean it up, and offer something much like it, either as a subproject (likely at first) or as an optional component of the core. Andrew has donated this to the FSF so we can use what we want, but I think he doesn't have time these days to develop it. I'd like to come up with a better name :). Anyway, that's the direction I think such a permission system should go in. Cheers, -Barry [1] https://gitlab.com/astuart/mailmania From andrew.stuart at supercoders.com.au Sun May 22 19:13:06 2016 From: andrew.stuart at supercoders.com.au (Andrew Stuart) Date: Mon, 23 May 2016 09:13:06 +1000 Subject: [Mailman-Developers] Authorization System in Core In-Reply-To: <20160522185429.4e6d3fee.barry@wooz.org> References: <3E54FAE6-FA8C-4CCA-B942-3B09CEAC608D@serve-me.info> <20160522185429.4e6d3fee.barry@wooz.org> Message-ID: You are most welcome to do as you wish with Mailmania, rename, fork, rebuild, whatever - I?m not precious about it - it is owned by the FSF and GPL licensed. It might be just a good ?first try? and point the way to a better solution. It certainly would benefit from a cleanup from a more experienced Python developer than me - whilst I did everything I could to make it consistent I have no doubt much could be done to improve it. As Barry says, Mailmania puts a server layer in front of the Mailman REST API that allows authenticated public access to the Mailman REST server. It uses the Mailman conceptual authorisation model and implements that as a concrete set of authorisation rules. It also includes an unfinished solution for archiving inbound mail to sqlite for full text indexing and integration with Apache Tika for extraction of text from documents attached to emails. I apologise for effectively having abandoned it but I would say it is (or was last I looked) fully working with over 700 tests. I just don?t have time to fit it in to everything in life right now.. If anyone does want to do any work on it I?ll do my level best to help them get it running, understand it and problem solve any issues. I?m working on other stuff but still watching this list so I?ll try to respond ASAP to any questions?. thanks as From ankush.sharma.ece12 at iitbhu.ac.in Mon May 23 01:55:24 2016 From: ankush.sharma.ece12 at iitbhu.ac.in (Ankush Sharma) Date: Mon, 23 May 2016 11:25:24 +0530 Subject: [Mailman-Developers] Authorization System in Core In-Reply-To: References: Message-ID: Hi Harshit, Their is no authentication system(OAuth etc.) set up between core and client for now. The client uses plain HTTP calls to communicate to the core. So, anyone with the credentials can alter any such permissions in the core. So, for now core and client should reside on the same host. So, I guess it would be better to implement the permissions stuff on the postorius side as others pointed out ! PS : I worked on the Node.js mailman client last year. You can refer it here . Thanks ! Ankush Sharma ECE IV IIT-BHU Varanasi-221005 http://black-perl.in Linkedin On Sun, May 22, 2016 at 3:20 AM, Harshit Bansal wrote: > Hi, > Earlier, while discussing the permission system for manging styles, it was > decided that the permissions system should be enforced in the core rather > than in the postorius since otherwise it can be bypassed(deliberately or > undeliberately). But one thing that I think I forgot to discuss was that > currently there is no authorisation system in the core and now I am unable > to figure out that how could the permissions be enforced in the core > without an authorisation system. > Should I workout an authorisation system for the core first or enforce > permissions in postorius only? > > Thanks, > Harshit Bansal > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > https://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: > http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: > https://mail.python.org/mailman/options/mailman-developers/ankush.sharma.ece12%40itbhu.ac.in > > Security Policy: http://wiki.list.org/x/QIA9 > From harshitbansal2015 at gmail.com Tue May 24 14:18:01 2016 From: harshitbansal2015 at gmail.com (Harshit Bansal) Date: Tue, 24 May 2016 23:48:01 +0530 Subject: [Mailman-Developers] Code Duplicacy Message-ID: Hi, I was writing the new 'IStyle' interface and after completing some part of it I realised that the code has become a bit repetitive as all the styleable attributes which are present in src/interfaces/mailinglist.py are to be copied to src/interfaces/styles.py in IStyle interface. For example, advertised = Attribute( """Advertise this mailing list when people ask for an overview of the available mailing lists.""") This piece of code is now present in both src/interfaces/mailinglist.py and src/interfaces/styles.py. Is there any way to correct it or is it fine? One approach that I am able to think of is to write one seperate interface containning all the styleable attributes and implement that interface both in src/model/mailinglist.py and src/model/styles.py. Thanks, Harshit Bansal. From barry at list.org Tue May 24 15:22:46 2016 From: barry at list.org (Barry Warsaw) Date: Tue, 24 May 2016 15:22:46 -0400 Subject: [Mailman-Developers] Code Duplicacy In-Reply-To: References: Message-ID: <20160524152246.66621c0b.barry@wooz.org> On May 24, 2016, at 11:48 PM, Harshit Bansal wrote: >I was writing the new 'IStyle' interface and after completing some part of >it I realised that the code has become a bit repetitive as all the >styleable attributes which are present in src/interfaces/mailinglist.py are >to be copied to src/interfaces/styles.py in IStyle interface. For example, > >advertised = Attribute( > """Advertise this mailing list when people ask for an overview of the >available mailing lists.""") > >This piece of code is now present in both src/interfaces/mailinglist.py and >src/interfaces/styles.py. This is in some respects a quirk held over from Mailman 2. The MailList class is a mixin of several other classes which hold both settings and functionality (methods). During the port to Mailman 3, I essentially collapsed all of that into a single MailingList class. Styles are a separate thing bolted onto the side of that, which is why they're implemented as applying to a mailing list only at creation time. You're right that a style has many of those attributes, but also keep in mind that a style can have a *subset* of attributes, as you should be able to see in the existing style classes. Styles are meant to be composable, so for example, you could define an "announce-only" style that only modifies some of the related attributes, but allows others to be defined in other style classes. MailingList instances OTOH contain all the style related attributes. >Is there any way to correct it or is it fine? One approach that I am able to >think of is to write one seperate interface containning all the styleable >attributes and implement that interface both in src/model/mailinglist.py and >src/model/styles.py. I'm not sure. Given that styles can be partial collections of attributes, maybe it doesn't make sense to name them all in the IStyle interface. Leaving them only in the IMailingList doesn't have much of a functional effect; in this case the interface isn't much more than documentation and marker (it declares the @implementor class as being of that interface so it's easier to look up). Cheers, -Barry From harshitbansal2015 at gmail.com Thu May 26 14:16:50 2016 From: harshitbansal2015 at gmail.com (Harshit Bansal) Date: Thu, 26 May 2016 23:46:50 +0530 Subject: [Mailman-Developers] Some Doubtful Attributes In-Reply-To: References: Message-ID: Hi, While categorising the styleable attributes I have come across some attributes which are defined but never used in the code. Some of these attributes are: forward_auto_discard non_member_rejection_notice member_rejection_notice bounce_score_threshold bounce_notify_owner_on_disable bounce_notify_owner_on_removal forward_auto_discards max_days_to_hold digest_is_default mime_is_default_digest scrub_nondigest obscure_addresses Some of the attributes are present only in src/utilities/tests/test_import.py. A list of such attributes is as follows: bounce_you_are_disabled_warnings bounce_info_stale_after accept_these_nonmembers discard_these_nonmembers reject_these_nonmembers What should be done to these attributes? For now, I have included them in the model. Also in src/mailman/styles/base.py line no. 129, we are setting up an non-existing attribute as follows: mlist.topics_userinterest = {} But the IMailinglist doesn't contain any such attribute. Thanks, Harshit Bansal From anirudhdahiya9 at gmail.com Fri May 27 07:22:23 2016 From: anirudhdahiya9 at gmail.com (Anirudh Dahiya) Date: Fri, 27 May 2016 16:52:23 +0530 Subject: [Mailman-Developers] Project Update : Message Queues based email archiver Message-ID: Hi The community bonding period was well utilized in finalizing design, besides other things.I also made a prototype for RabbitMQ Message Queue during this period, and shared it with Florian(and now with you :) ) Also, I learnt about tox, unittest, and studied the codebase and tests for existing archivers and runner. All the progress and designs made during the community bonding period has been documented by me in my blog post - https://codefullofsummer.blogspot.in/ Regards Anirudh Dahiya (irc spark_) From simon.hanna at serve-me.info Sat May 28 16:27:27 2016 From: simon.hanna at serve-me.info (Simon Hanna) Date: Sat, 28 May 2016 22:27:27 +0200 Subject: [Mailman-Developers] [Mailman-i18n] Translation of Mailman 3 In-Reply-To: <20160517100630.5f815773.barry@wooz.org> References: <570D766A.9040509@serve-me.info> <570D7892.3000207@msapiro.net> <20160420095815.0f175625@subdivisions.wooz.org> <22296.16208.742523.449355@turnbull.sk.tsukuba.ac.jp> <20160517100630.5f815773.barry@wooz.org> Message-ID: <7b9c8001-d4bc-e232-be2a-7e6c702f42bb@serve-me.info> On 05/17/2016 04:06 PM, Barry Warsaw wrote: > Hi Simon, > > On May 17, 2016, at 03:31 PM, Simon Hanna wrote: > >> I guess I could take some sort of lead on that. I played around a little >> with pootle and I really like it. It's easy to use, fast and anyone that >> registers can start translating. > > Just by way of comparison, have you played with Zanata yet? How would you > compare the two systems? I used Zanata, but found it not very intuitive to use. It's also painfully slow. I'm unaware of any big projects that use zanata. Well openstack does, but they use a self hosted version and that one is not faster. I'm not sure how Mailman 2 was translated, but I guess most of the translators did it offline. You can download translation files from pootle and later upload them. So anyone that doesn't want to translate in the browser, can still do it offline. > >> The main question would be selfhosting vs using gnu's hosted version. > > I'd really prefer not to self-host. I don't think we're a big enough > organization to commit to long-term maintenance. I'm not at all questioning > your eagerness, abilities, and availability, but life has a way of throwing > curve balls at us[*] and I worry about 5 years in the future if interests or > availability changes. Also, I wonder if we wouldn't be giving up some > economies of scale by sharing translation infrastructure with other projects. > >> If you want I can spin up an instance on my server and provide >> interested people credentials to play with. (existing demo instances >> don't allow adding/managing projects) > > If the i18n community wants to play with a pootle, I think that's fine. We > can certainly use it to compare against other services. > > From my perspective, I don't have too many requirements, other than that we > can upload .pot files and download .po files when it makes sense for the > project, which would be disconnected from the timeline for translators to > submit translations. Right now for MM2.1, Mark has to request updates timed > to his releases, and I really want to avoid that. IWBNI whatever system we > choose had nice git integration, but that's not required. With pootle you can always download a snapshot for a language. I don't think any of the translation software out there has a real git integration. > > My only other requirement is that whatever we choose be comfortable enough > that translators *want* to use it. As a pretty typical monolinguist, I'm > definitely not qualified to judge that. > > Cheers, > -Barry > > [*] Is that a euphemism that translates outside of North America? ;) If you watch American TV shows, you know that it's origin is baseball So If you give me the ok, I write the gnu pootle maintainers and ask them to create three projects for us. I guess we could add links in postorius and hyperkitty that request assistance with translation. From stephen at xemacs.org Sat May 28 16:56:36 2016 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sun, 29 May 2016 05:56:36 +0900 Subject: [Mailman-Developers] [Mailman-i18n] Translation of Mailman 3 In-Reply-To: <7b9c8001-d4bc-e232-be2a-7e6c702f42bb@serve-me.info> References: <570D766A.9040509@serve-me.info> <570D7892.3000207@msapiro.net> <20160420095815.0f175625@subdivisions.wooz.org> <22296.16208.742523.449355@turnbull.sk.tsukuba.ac.jp> <20160517100630.5f815773.barry@wooz.org> <7b9c8001-d4bc-e232-be2a-7e6c702f42bb@serve-me.info> Message-ID: <22346.1540.187377.818103@turnbull.sk.tsukuba.ac.jp> Simon Hanna writes: > I used Zanata, but found it not very intuitive to use. It's also > painfully slow. Thanks for your efforts here, it's very helpful. > So If you give me the ok, I write the gnu pootle maintainers and ask > them to create three projects for us. +1 from me. Pootle is widely used so it's not the worst alternative. Steve