Mailman-Developers May 2016

mailman-developers@python.org

9 participants
21 discussions

Translation
by Simon Hanna 11 Jan '17

11 Jan '17

Hi, I just completed setting up the Mailman 3 projects on zanata.org They can be found here: https://translate.zanata.org/project/view/mailman https://translate.zanata.org/project/view/postorius https://translate.zanata.org/project/view/hyperkitty I'm hesitating to ask people to translate because zanata is really slow and I'm afraid of scaring people away from translating mailman in the future :D Anyhow, I'm writing to ask for your opinions. What do you think about zanata? Maybe you can try translating a couple of things and report how you feel about it. I stumbled across a few other open source solutions: https://translatewiki.net http://pootle.locamotion.org/ https://demo.weblate.org/ This mediagoblin issue discussed some alternatives when they switched away from transifex. https://issues.mediagoblin.org/ticket/913 There seems to be a pootle server run by gnu itself. https://chapters.gnu.org/pootle/ What do you think? Simon

4 9

Project Update : Message Queues based email archiver
by Anirudh Dahiya 27 May '16

27 May '16

Hi The community bonding period was well utilized in finalizing design, besides other things.I also made a prototype <https://gitlab.com/anirudhdahiya9/message-queues-prototypes> 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_)

1 0

Some Doubtful Attributes
by Harshit Bansal 26 May '16

26 May '16

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

1 0

Re: [Mailman-Developers] Code Duplicacy
by Barry Warsaw 24 May '16

24 May '16

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

1 0

Code Duplicacy
by Harshit Bansal 24 May '16

24 May '16

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.

1 0

Re: [Mailman-Developers] Authorization System in Core
by Ankush Sharma 23 May '16

23 May '16

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 <https://gitlab.com/black-perl/mailman-client.js>. Thanks ! Ankush Sharma ECE IV IIT-BHU Varanasi-221005 http://black-perl.in Linkedin <https://www.linkedin.com/in/ankushsharma003> On Sun, May 22, 2016 at 3:20 AM, Harshit Bansal <harshitbansal2015(a)gmail.com > 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(a)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.ec… > > Security Policy: http://wiki.list.org/x/QIA9 >

1 0

Re: [Mailman-Developers] Authorization System in Core
by Simon Hanna 23 May '16

23 May '16

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.

4 3

Re: [Mailman-Developers] Authorization System in Core
by Simon Hanna 21 May '16

21 May '16

>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.

2 1

Authorization System in Core
by Harshit Bansal 21 May '16

21 May '16

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

1 0

FWD: [dmarc-ietf] Last Call: <draft-ietf-dmarc-interoperability-15.txt> (Interoperability Issues Between DMARC and Indirect Email Flows) to Informational RFC
by Stephen J. Turnbull 21 May '16

21 May '16

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' > <draft-ietf-dmarc-interoperability-15.txt> 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(a)ietf.org mailing lists by 2016-06-03. Exceptionally, comments may be > sent to iesg(a)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(a)ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers May 2016