From anna.granudd at gmail.com Mon Jul 5 15:52:37 2010 From: anna.granudd at gmail.com (Anna Granudd) Date: Mon, 5 Jul 2010 15:52:37 +0200 Subject: [Mailman-Developers] mock-ups for user settings page, MM3 Message-ID: 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 From p at state-of-mind.de Mon Jul 5 22:41:06 2010 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Mon, 5 Jul 2010 22:41:06 +0200 Subject: [Mailman-Developers] mock-ups for user settings page, MM3 In-Reply-To: References: Message-ID: <20100705204105.GA2490@state-of-mind.de> Anna, * Anna Granudd : > 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 there are non on purpose at the moment. The proposed way to get a design was a) adopt a new logo b) develop new color set c) create a new grid d) create a new design. > 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 For the moment - this is my personal opinion - we should use logical, structured markup. Plain HTML. Design is important, but nothing without groundwork based on proper organisation of options and good HTML. > 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). I think we need to decide on UI standards (do we need a 'save' button or not etc.) and a new organisation of options first and then aim for design. p at 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 From anna.granudd at gmail.com Fri Jul 9 12:11:50 2010 From: anna.granudd at gmail.com (Anna Granudd) Date: Fri, 9 Jul 2010 12:11:50 +0200 Subject: [Mailman-Developers] password handling in MM3 Message-ID: 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 From iane at sussex.ac.uk Fri Jul 9 12:29:27 2010 From: iane at sussex.ac.uk (Ian Eiloart) Date: Fri, 09 Jul 2010 11:29:27 +0100 Subject: [Mailman-Developers] password handling in MM3 In-Reply-To: References: Message-ID: <0CA4ADBC661C080F89DD0ACF@lewes.staff.uscs.susx.ac.uk> --On 9 July 2010 12:11:50 +0200 Anna Granudd wrote: > 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? Most importantly, passwords must be securely hashed, so that they can't be read by the site or list admins, or by third parties. That means that password resets must be offered to users, instead of password reminders. Also, for sites like mine, it would be nice to have more than one password store. For example, I'd like to have users with addresses in the sussex.ac.uk domain authenticated against my current LDAP db, but non-local users authenticate against some other db (perhaps a different branch of the LDAP tree, but perhaps something local). > Thanks, > Anna > > > [1] https://bugs.launchpad.net/mailman/+bug/600780 > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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/iane%40sussex.a > c.uk > > Security Policy: http://wiki.list.org/x/QIA9 -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From larryt at winfirst.com Sun Jul 11 00:28:59 2010 From: larryt at winfirst.com (larryt at winfirst.com) Date: Sat, 10 Jul 2010 15:28:59 -0700 (PDT) Subject: [Mailman-Developers] password handling in MM3 In-Reply-To: References: Message-ID: <20100710152859.AWV98556@ms1.mc.surewest.net> Whatever else you do, include OpenID client support. Look at Armin Ronacher's Flask-OpenID extension for how to do it. That's just passwd and authentication, of course. There's still authorization to think through. -larry ---- Original message ---- >Date: Fri, 9 Jul 2010 12:11:50 +0200 >From: mailman-developers-bounces+larryt=winfirst.com at python.org (on behalf of Anna Granudd ) >Subject: [Mailman-Developers] password handling in MM3 >To: Mailman-developers > >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 at 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/larryt%40winfirst.com > >Security Policy: http://wiki.list.org/x/QIA9 From CNulk at scu.edu Mon Jul 12 19:05:03 2010 From: CNulk at scu.edu (C Nulk) Date: Mon, 12 Jul 2010 10:05:03 -0700 Subject: [Mailman-Developers] password handling in MM3 In-Reply-To: <0CA4ADBC661C080F89DD0ACF@lewes.staff.uscs.susx.ac.uk> References: <0CA4ADBC661C080F89DD0ACF@lewes.staff.uscs.susx.ac.uk> Message-ID: <4C3B4B3F.4020205@scu.edu> Ian Eiloart wrote: > > --On 9 July 2010 12:11:50 +0200 Anna Granudd > wrote: > >> 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? > > Most importantly, passwords must be securely hashed, so that they > can't be > read by the site or list admins, or by third parties. > > That means that password resets must be offered to users, instead of > password reminders. > > Also, for sites like mine, it would be nice to have more than one > password > store. For example, I'd like to have users with addresses in the > sussex.ac.uk domain authenticated against my current LDAP db, but > non-local > users authenticate against some other db (perhaps a different branch > of the > LDAP tree, but perhaps something local). Agreed, passwords must be securely hashed. No one should be able to reverse the hash to derive a password. I toss would also like to have multiple authentication stores whether via LDAP or intrinsic to default Mailman. Likewise, I would also like to have multiple membership stores, obviously the default intrinsic Mailman member store, but also LDAP, database, etc. Optimally, if both multiple password/member stores are combined, when a member authenticates, the member is looked up in the appropriate password/member store for validity whether it be LDAP, a database, or Mailman intrinsic. Likewise, a posting to a list should send a message to members listed in all password/member stores associated with the list. Thanks, Chris > >> Thanks, >> Anna >> >> >> [1] https://bugs.launchpad.net/mailman/+bug/600780 >> _______________________________________________ >> Mailman-Developers mailing list >> Mailman-Developers at 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/iane%40sussex.a >> >> c.uk >> >> Security Policy: http://wiki.list.org/x/QIA9 > > > > -- > Ian Eiloart > IT Services, University of Sussex > 01273-873148 x3148 > For new support requests, see http://www.sussex.ac.uk/its/help/ > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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/cnulk%40scu.edu > > Security Policy: http://wiki.list.org/x/QIA9 From dave at aasv.org Mon Jul 12 20:25:40 2010 From: dave at aasv.org (David Brown) Date: Mon, 12 Jul 2010 14:25:40 -0400 Subject: [Mailman-Developers] password handling in MM3 Message-ID: <001701cb21ef$a1ea2c50$e5be84f0$@aasv.org> [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 at aasv.org ; webmaster at aasv.org -----Original Message----- From: mailman-developers-bounces+dave=aasv.org at python.org [mailto:mailman-developers-bounces+dave=aasv.org at 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 at 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 From p at state-of-mind.de Wed Jul 14 16:22:52 2010 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Wed, 14 Jul 2010 16:22:52 +0200 Subject: [Mailman-Developers] MM3 testserver downtime Message-ID: <20100714142251.GG27752@state-of-mind.de> 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 at 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 From f at state-of-mind.de Tue Jul 20 16:50:34 2010 From: f at state-of-mind.de (Florian Fuchs) Date: Tue, 20 Jul 2010 16:50:34 +0200 Subject: [Mailman-Developers] Mailman 3 REST API URLs Message-ID: <74752974-F202-4CE5-B981-3ABF002FC716@state-of-mind.de> 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 at 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 at 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 at 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 From mss at apache.org Tue Jul 20 21:49:40 2010 From: mss at apache.org (Malte S. Stretz) Date: Tue, 20 Jul 2010 21:49:40 +0200 Subject: [Mailman-Developers] Mailman 3 REST API URLs In-Reply-To: <74752974-F202-4CE5-B981-3ABF002FC716@state-of-mind.de> References: <74752974-F202-4CE5-B981-3ABF002FC716@state-of-mind.de> Message-ID: <201007202149.42534.mss@apache.org> On Tuesday 20 July 2010 16:50:34 Florian Fuchs wrote: >[...] >> For example: At the moment an API request to > /3.0/lists/listname at 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 at 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 at example.com/settings/archiving My 2 cents: I think the one-file-per-option interface is the optimal REST interface because you don't have to cope with some weird format like JSON or XML or whatever. Just PUT your value there and GET it later as text/plain. Just like /sys or Plan9 or mlmmj's config works :) With Perl's lwp-request installed all I'd need to do to read or change a setting is GET -C user:pass \ https://lists.example.com/api/lists/foo at lists.example.com/real_name echo "foo" | PUT -C user:pass \ https://lists.example.com/api/lists/foo at lists.example.com/real_name And to add a user maybe echo | PUT -C user:pass \ https://lists.example.com/api/lists/foo at lists.example.com/subscribers/user at example.net echo John Doe | PUT -C user:pass \ https://lists.example.com/api/lists/foo at lists.example.com/subscribers/user at example.net/name And to list all users GET -C user:pass \ https://lists.example.com/api/lists/foo at lists.example.com/subscribers Quite elegant I think :) Of course the API could also allow posting and retrieving JSON (or...) based on Content-Type and Accept-Content-Type. Cheers, Malte From barry at list.org Fri Jul 23 10:56:29 2010 From: barry at list.org (Barry Warsaw) Date: Fri, 23 Jul 2010 10:56:29 +0200 Subject: [Mailman-Developers] Mailman 3 REST API URLs In-Reply-To: <74752974-F202-4CE5-B981-3ABF002FC716@state-of-mind.de> References: <74752974-F202-4CE5-B981-3ABF002FC716@state-of-mind.de> Message-ID: <20100723105629.093f4bb3@snowdog> On Jul 20, 2010, at 04:50 PM, Florian Fuchs wrote: >For example: At the moment an API request >to /3.0/lists/listname at 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 at example.com/settings). I don't think these need to be mutually exclusive, but of course it's a matter of deciding which approach is more useful to implement first. I think the former will be easier to implement from the server side. Both will accomplish what you want and will have different performance characteristics. For example, GET on /3.0/lists/listname at example.com can return the entire representation of the mailing list object. POSTs to this would *replace* the state of the object with the new state, but PATCH (which is a non-standard HTTP verb though supported in e.g. httplib2 IIUC) will allow you to modify a small subset of the list's attributes. This can be much more efficient if you're patching a bunch of attributes at the same time because you'll only need to make one request. I think it comes down to what wui interactions you expect to implement. If you think it'll be more common to change one attribute at a time, then perhaps we should implement lists/settings/foo first, but if you think it'll be more common to change a number of settings in a batch, then implementing PATCH on the list object first would be better. (Aside: I'm not actually sure how best to implement lists/settings/foo ;) >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 at example.com/settings/archiving I suppose we could implement categories but I see these as an artificial organization in Mailman 3. Mailman 2 had them as an artifact of the implementation, but I never really liked it. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Fri Jul 23 10:59:00 2010 From: barry at list.org (Barry Warsaw) Date: Fri, 23 Jul 2010 10:59:00 +0200 Subject: [Mailman-Developers] Mailman 3 REST API URLs In-Reply-To: <201007202149.42534.mss@apache.org> References: <74752974-F202-4CE5-B981-3ABF002FC716@state-of-mind.de> <201007202149.42534.mss@apache.org> Message-ID: <20100723105900.1aed9872@snowdog> On Jul 20, 2010, at 09:49 PM, Malte S. Stretz wrote: >I think the one-file-per-option interface is the optimal REST >interface because you don't have to cope with some weird format like >JSON or XML or whatever. Just PUT your value there and GET it later >as text/plain. Just like /sys or Plan9 or mlmmj's config works :) Except that MM3's REST interface currently only supports JSON. There's no reason why we couldn't support other content types, except for the missing cycles to do so. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Fri Jul 23 10:59:00 2010 From: barry at list.org (Barry Warsaw) Date: Fri, 23 Jul 2010 10:59:00 +0200 Subject: [Mailman-Developers] Mailman 3 REST API URLs In-Reply-To: <201007202149.42534.mss@apache.org> References: <74752974-F202-4CE5-B981-3ABF002FC716@state-of-mind.de> <201007202149.42534.mss@apache.org> Message-ID: <20100723105900.1aed9872@snowdog> On Jul 20, 2010, at 09:49 PM, Malte S. Stretz wrote: >I think the one-file-per-option interface is the optimal REST >interface because you don't have to cope with some weird format like >JSON or XML or whatever. Just PUT your value there and GET it later >as text/plain. Just like /sys or Plan9 or mlmmj's config works :) Except that MM3's REST interface currently only supports JSON. There's no reason why we couldn't support other content types, except for the missing cycles to do so. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From thijs at debian.org Wed Jul 28 14:35:07 2010 From: thijs at debian.org (Thijs Kinkhorst) Date: Wed, 28 Jul 2010 14:35:07 +0200 Subject: [Mailman-Developers] Plans for a new 2.1.x release Message-ID: <201007281435.13158.thijs@debian.org> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From mark at msapiro.net Wed Jul 28 15:56:22 2010 From: mark at msapiro.net (Mark Sapiro) Date: Wed, 28 Jul 2010 06:56:22 -0700 Subject: [Mailman-Developers] Plans for a new 2.1.x release In-Reply-To: <201007281435.13158.thijs@debian.org> References: <201007281435.13158.thijs@debian.org> Message-ID: <4C503706.6090009@msapiro.net> On 7/28/2010 5:35 AM, Thijs Kinkhorst wrote: > > 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. 2.1.14 is currently targeted for Sept 20. This date is somewhat arbitrary, but I will be traveling in August and don't plan a release candidate until I return. This will be around the last week of August. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From William at alt-config.net Wed Jul 28 20:03:17 2010 From: William at alt-config.net (William Bagwell) Date: Wed, 28 Jul 2010 14:03:17 -0400 Subject: [Mailman-Developers] Feature request for Mailman 3: Ability to set size limits on a per Topic basis. Message-ID: <201007281403.18049.William@alt-config.net> 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