Mailman 3 May 2016 - Mailman-Developers

before next release: disable backscatter in default installation
by Jo Rhett Nov. 7, 2022

Nov. 7, 2022

Hi. There's a fairly simple problem here that needs to be addressed. And it's mostly a documentation/install problem. I'm hoping we can get this resolved before the next release. PROBLEM: Mailman comes out of the box ready to backscatter spam people. Yes, it's easy enough to fix. But because it comes stock this way, and is documented to install this way, most people install it to do this. Those of us who work in abuse departments are tired of hearing "well that's how Mailman … [View More]

21 168

Translation
by Simon Hanna Jan. 11, 2017

Jan. 11, 2017

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 … [View More]

4 9

Project Update : Message Queues based email archiver
by Anirudh Dahiya May 27, 2016

May 27, 2016

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 -… [View More]

1 0

Some Doubtful Attributes
by Harshit Bansal May 26, 2016

May 26, 2016

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/… [View More]

1 0

Re: [Mailman-Developers] Code Duplicacy
by Barry Warsaw May 24, 2016

May 24, 2016

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 … [View More]

1 0

Code Duplicacy
by Harshit Bansal May 24, 2016

May 24, 2016

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 … [View More]

1 0

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

May 23, 2016

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://… [View More]

1 0

Re: [Mailman-Developers] Authorization System in Core
by Simon Hanna May 22, 2016

May 22, 2016

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 … [View More]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. [View Less]

4 3

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

May 21, 2016

>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 >… [View More]

2 1

Authorization System in Core
by Harshit Bansal May 21, 2016

May 21, 2016

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 … [View More]

1 0