Mailman 3 May 2016 - Mailman-Developers

before next release: disable backscatter in default installation
by Jo Rhett 07 Nov '22

07 Nov '22

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 works". We also object to having to teach people how to fix their mailman installations because it's not documented in the current manual. This is *exactly* like Sendmail 14 years ago. We didn't accept it then, and Sendmail fixed the problem. RESOLUTION: Mailman default installation should not backscatter in a default configuration. 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by default. Nearly everyone uses web based signup. 2. Discard or hold messages from non-subscribers by default. I would think that it would be perfectly reasonable to have documentation on how to enable the 1980s-style -request / -subscribe etc aliases. However this documentation should have a note that this is against the AUP of nearly every network provider, and enabling it will likely cause them to get listed in various blacklists as a backscatter source. FYI: I know that this goes against the instincts of many old-time mailing list advocates here. But after dealing with a 10k/hour backscatter DoS my tolerance for this problem is understandably limited. Yes, it was a sweet day back in the 1980s. I was running a mailing list server and several UUCP gateways at the time, so I remember them well. But those days are past, and we need to deal with the reality of today. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

21 168

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 22 May '16

22 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