Mailman 3 July 2010 - 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

Feature request for Mailman 3: Ability to set size limits on a per Topic basis.
by William Bagwell 28 Jul '10

28 Jul '10

I realize Topics are not widely implemented but would love to see this feature for the few lists who do use them. One very non-technical chat list I'm on is almost ten years old and split off of a much older list on the same subject. Last year I helped them move to Mailman from that expensive service whose name I shall not mention. Not only does this list use Topics (16 at the moment) it also allows, even welcomes pictures and allows a few other types of attachments. However, it is always confusing which Topic to use. Not all attachments are pictures... Bottom line is that no matter what naming schema is used *someone* will get confused and then gets yelled at by the current list owner (not me, I ain't taking the job!) for posting attachments to the wrong Topic. Not only is this embarrassing for the 'yellie', it annoys the rest of the members seeing this same scene play out every few months. Worst of all leads to early list owner burn out and good ones as we all know are rather hard to find. If message size limits could be set per topic then an impartial reply-bot would get to be the heavy in private. If this would be too code bloating, then having two (or perhaps three) levels of size limits with each Topic being assigned to a level would work just as well. Thanks. -- William

1 0

Plans for a new 2.1.x release
by Thijs Kinkhorst 28 Jul '10

28 Jul '10

Hi all, I see quite a lot of fixes have accumulated since 2.1.13 was released last december. I was wondering if a new release in the stable series is planned in the near future. At least for Debian's schedule it would be nice to have a 2.1-release sometime this summer. Cheers, Thijs

2 1

Mailman 3 REST API URLs
by Florian Fuchs 23 Jul '10

23 Jul '10

Hi all, I have recently been working on a small REST client library for mailman3 [1]. The purpose of this library is to make it easier for UI developers to access MM3's new REST API. The library will also be used in the MM django UI which is currently being built. Anna Granudd (who is working on the MM django UI as well as the client) and I have been discussing how this library could access and edit mailing list settings - which is not only a question of how the library itself should work, but also what resources should be exposed by the API under which URL. Both the client and the API are still work in progress, so we thought we ask for opinions on how things could be done. For example: At the moment an API request to /3.0/lists/listname(a)example.org exposes only some basic list information. Would it be a good idea to let this URL expose more list details (i.e. all list settings) or would it be better to have a different URL for that? (Something like /3.0/lists/listname(a)example.com/settings). Why a different URL for the settings? Obviously the first option (one URL for all list details) would be simpler and, as a developer, you would have all information at hand with only one call. Wether you use that info to build a detailed settings page or just a small list info page wouldn't matter. On the other hand there are quite a lot of DB fields for every list and that means quite a bit of traffic every time you access them through the API. That's why it could make sense to use different URLs. So if we went for the latter option: Why not go even further and access the settings field by field? Or in smaller groups, i.e.: /3.0/lists/listname(a)example.com/settings/archiving Thanks for your thoughts! Florian [1] https://code.launchpad.net/~flo-fuchs/mailman/restclient/+merge/28522 -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Heckmannufer 2 Telefon +49 30 3013 6756 10997 Berlin Mobil +49 176 2064 0812 Amtsgericht München Partnerschaftsregister PR 563e

3 3

MM3 testserver downtime
by Patrick Ben Koetter 14 Jul '10

14 Jul '10

Due to maintenance - we replace our VM host and migrate from XEN to KVM - mailman.state-of-mind.de will not be available until Friday, July 16th EBD. p@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht München Partnerschaftsregister PR 563

1 0

Re: [Mailman-Developers] password handling in MM3
by David Brown 12 Jul '10

12 Jul '10

[Sorry I'm late... didn't notice this list is set to reply to sender instead of the whole list.] In model/docs/users.txt, it says "Users are entities that represent people. A user has a real name and a password.... " As yet (rev 6869), none of the methods provided in the class User itself make use of that password. LDAP and OpenID are fairly common situations where using Mailman's own username/password is not helpful. I know that one of my major challenges with MM2 was whacking it upside the head hard enough that I could use the AASV's membership database instead of Mailman's users to control access (it sort of half works) and list membership (still using the import script :-( ). An extensible plug-in architecture would be really useful here, I think. You could even have a plug-in that determines what plug-in to hand-off to -- for environments like Ian's where some users use LDAP and some use a stored/hashed password. Presuming the storage mechanism isn't limiting the length of the "password" (i.e., only 32 characters for a hex MD5 or something like that), I think that this field could be overloaded to support a variety of uses and plug-ins. If we used something akin to IRI/URI/URL formatting, the authentication method used for a particular user account could be represented right there. For example, plug-ins that come bundled with Mailman could use the plug-in name in the method part: openid:///myopenidusername.openidprovider.com ldap://ldapserver.example.com/username sha1:///6aafb9bd47e1a38bbb99043c638f192f89c87930 Plug-ins created apart from Mailman could be loaded via a "private" plug-in that loads the user identified by the host.domain part of the URI to protect against name collisions: private://members.aasv.org/whatever_private_data_I_want_goes_here (You could still fall back to the password field containing just a hash and hope/presume it's an unsalted MD5 or something like that.) For web-based authentication, there will need to be some sort of authentication target page that can load the appropriate plug-in. In the example of OpenID, the user might typically be redirected away from the mailman host to the OpenID provider's page, then come back to mailman via GET with validation information in the query. Another issue to consider is that the "real name" attribute of the Mailman User might better be obtained from the external authentication service/plug-in -- such as LDAP or OpenID, (or the AASV member database). Indeed, it seems that the essential role of the Mailman User is to provide a root node for the collection of associated addresses and their memberships. Having the password and real name attributes makes it a lot easier (possible) to install and configure Mailman as a standalone application, but they are somewhat superfluous when they can be obtained from a more authoritative source. Dave -- David Brown dave(a)aasv.org ; webmaster(a)aasv.org -----Original Message----- From: mailman-developers-bounces+dave=aasv.org(a)python.org [mailto:mailman-developers-bounces+dave=aasv.org@python.org] On Behalf Of Anna Granudd Sent: Friday, July 09, 2010 6:12 AM To: Mailman-developers Subject: [Mailman-Developers] password handling in MM3 Hi, when subscribing a user or creating a list in Mailman 3.0 we need to implement the use of a password for security reasons. Later the same password will be used for logging in to the settings pages. At the moment passwords are not handled at all which is why I filed bug #600780 (see [1]). However, we're not sure how to handle the passwords at the moment and would like your help with ideas and possible ways to implement this, which is why I want to start a discussion about the password handling/ login function. What do we need to think of and how should this best be dealt with? Thanks, Anna [1] https://bugs.launchpad.net/mailman/+bug/600780 _______________________________________________ Mailman-Developers mailing list Mailman-Developers(a)python.org http://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: http://mail.python.org/mailman/options/mailman-developers/dave%40aasv.org Security Policy: http://wiki.list.org/x/QIA9

1 0

password handling in MM3
by Anna Granudd 12 Jul '10

12 Jul '10

Hi, when subscribing a user or creating a list in Mailman 3.0 we need to implement the use of a password for security reasons. Later the same password will be used for logging in to the settings pages. At the moment passwords are not handled at all which is why I filed bug #600780 (see [1]). However, we're not sure how to handle the passwords at the moment and would like your help with ideas and possible ways to implement this, which is why I want to start a discussion about the password handling/ login function. What do we need to think of and how should this best be dealt with? Thanks, Anna [1] https://bugs.launchpad.net/mailman/+bug/600780

4 3

mock-ups for user settings page, MM3
by Anna Granudd 05 Jul '10

05 Jul '10

Hi, I'm currently working on the (Django) views for the Mailman 3.0 UI. I looked at what mock-ups were made in the wiki, [1], and realized that so far there are no mock-ups for the user settings page. Therefore, I was wondering if anybody has any thoughts on what to think of when designing this page and how you would like it to look like. We could start with using the old user settings page design from older versions of Mailman and just "freshing it up" a bit or we could make a complete redesign but it would be nice to get some peoples' opinions on what you want before starting (although just writing your thoughts down and emailing them works as well, if you don't feel like creating mock-ups). Thanks, Anna [1] http://wiki.list.org/display/DEV/Web+UI+Mockups

2 1