From petr.hroudny at gmail.com Fri May 1 09:01:32 2009 From: petr.hroudny at gmail.com (=?UTF-8?Q?Petr_Hroudn=C3=BD?=) Date: Fri, 1 May 2009 09:01:32 +0200 Subject: [Mailman-Developers] Proposal: option for UTF-8 emails without base64 encoding Message-ID: Hi all, due to Python defaults, mailman exhibits strange behaviour when processing UTF-8 emails. When no header/footer is configured, mailman passes UTF-8 emails in original form, i.e. 8bit. However, when either header or footer is configured in mailman, it uses Python's libraries to add them and as a side effect it converts 8bit emails into 7bit base64 encoded ones. This is highly undesirable in some cases. For instance, mailinglist might be used to distribute trouble tickets or other content which is expected to be easily parsable by automated text-based utilities. With base64, emails grow in size by 33 % and such emails are getting much higher spam scores since base64 is typically used by spammers to obfuscate the payload. There are of course much more reasons for not using base64 as the primary encoding method for UTF-8 email. The fix is quite simple and is already widely used by other projects. All that needs to be done is to redefine Python's UTF-8 charset properties, i.e. in every place where you have from email.Charset import Charset you need to add: email.Charset.add_charset('utf-8',email.Charset.SHORTEST, None, None) With such setting, mailman will keep the 8bit encoding also when it's adding header/footer and won't downconvert to 7bit+base64. So I'd like to propose the above addition, at least as a configurable option if there's any fear that enabling it by default could cause some problems. Thanks, Petr From barry at list.org Thu May 7 04:41:16 2009 From: barry at list.org (Barry Warsaw) Date: Wed, 6 May 2009 22:41:16 -0400 Subject: [Mailman-Developers] Status of RESTful branch Message-ID: <74CE4A1C-19D7-4B52-88D4-69473D164B39@list.org> At Pycon, several of us sprinted on exposing Mailman 3's administrative interface via RESTful services. I've been making slow but steady progress since then on the infrastructure for this. With the lazr.restful package married to the standard wsgiref module, I now have the basics of its operation working. For example, if you start the rest (http) server, you can now hit http://localhost:8001/3.0/ system and get a JSON response with the Mailman and Python version strings. This is the only URL currently implemented, and it's only GET. Patrick, Andreas, Florian and I worked out some preliminary URL space and we have a basic architectural design here: http://wiki.list.org/display/DEV/PyCon+Sprint+2009 I think this is going to work out pretty well, and now that I have the basics working, my next step is to implement some simple POST, PUT, or DELETE operations. If those also pan out, then I'll be merging my development branch back into the trunk. For now, you can follow along with this branch: lp:~barry/mailman/rest Enjoy, and let me know if you have any questions or comments. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From terri at zone12.com Fri May 8 20:19:47 2009 From: terri at zone12.com (Terri Oda) Date: Fri, 08 May 2009 14:19:47 -0400 Subject: [Mailman-Developers] mailman 3: webinterface: prototype (PDF) In-Reply-To: <20090427211822.GC5398@state-of-mind.de> References: <20090423151623.GH7781@state-of-mind.de> <1D86C4CF-83A1-4574-8D8A-6BA28BBB7A56@list.org> <20090427091110.GA19288@state-of-mind.de> <49F5D8F6.102@zone12.com> <20090427211822.GC5398@state-of-mind.de> Message-ID: <4A0477C3.9070603@zone12.com> Patrick Ben Koetter wrote: >> Can we add a search box for options? It might not be necessary on the >> smaller pages, but the full admin/owner interface looks like it's still >> going to be sufficiently busy that it could help. > > We can. But I, personally, would want to wait for usability test and see if we > can do without it simply because it makes the interface more complex. Well, here's some user data from a recent mailman-users post http://www.mail-archive.com/mailman-users%40python.org/msg53494.html This is a *common* way for people to find things in the current mailman admin interface, sadly. I've watched people do it and had people tell me in person that's how they find things too. Most people who maintain mailing lists do settings changes infrequently, and often under some time pressure. And they never have time to learn the menu hierarchy unless they maintain a lot of different types of lists. And often not even then. There's a lot of options there, and most people nowadays are used to the google method of finding things. ;) I totally understand not wanting to add too much extra, but... my user observations thus far imply that this is a feature that would be used heavily. > The test scenario affects the outcome of the test. We need to standardize the > test before we run it. I might be able to get some people from a usability lab > we work with help us. Let me check that. I'm an academic researcher professionally, so I'm well aware of issues in testing methodologies. But honestly? Don't get caught up in doing Perfect Science here. Even a quick, dirty, messy user study would give us a lot of information that could be useful. The current interface suffers badly from lack of user testing, and I'd hate for the same to be true of the new one. If you need more help with user studies, I should be able get some help from the usability research lab here. I know one of the profs here expressed interest in mailman usability in the past, and we may be able to find people willing to work on the problem. Terri From p at state-of-mind.de Fri May 8 21:46:33 2009 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Fri, 8 May 2009 21:46:33 +0200 Subject: [Mailman-Developers] mailman 3: webinterface: prototype (PDF) In-Reply-To: <4A0477C3.9070603@zone12.com> References: <20090423151623.GH7781@state-of-mind.de> <1D86C4CF-83A1-4574-8D8A-6BA28BBB7A56@list.org> <20090427091110.GA19288@state-of-mind.de> <49F5D8F6.102@zone12.com> <20090427211822.GC5398@state-of-mind.de> <4A0477C3.9070603@zone12.com> Message-ID: <20090508194633.GA11636@state-of-mind.de> * Terri Oda : > Patrick Ben Koetter wrote: >>> Can we add a search box for options? It might not be necessary on >>> the smaller pages, but the full admin/owner interface looks like >>> it's still going to be sufficiently busy that it could help. >> >> We can. But I, personally, would want to wait for usability test and see if we >> can do without it simply because it makes the interface more complex. > > Well, here's some user data from a recent mailman-users post > > http://www.mail-archive.com/mailman-users%40python.org/msg53494.html > > This is a *common* way for people to find things in the current mailman > admin interface, sadly. I've watched people do it and had people tell > me in person that's how they find things too. Most people who maintain > mailing lists do settings changes infrequently, and often under some > time pressure. And they never have time to learn the menu hierarchy > unless they maintain a lot of different types of lists. And often not > even then. There's a lot of options there, and most people nowadays are > used to the google method of finding things. ;) > > I totally understand not wanting to add too much extra, but... my user > observations thus far imply that this is a feature that would be used > heavily. Agreed. If it helps we will find a place for it. >> The test scenario affects the outcome of the test. We need to standardize the >> test before we run it. I might be able to get some people from a usability lab >> we work with help us. Let me check that. > > I'm an academic researcher professionally, so I'm well aware of issues > in testing methodologies. But honestly? Don't get caught up in doing > Perfect Science here. Even a quick, dirty, messy user study would give Believe me. I won't. ;) > us a lot of information that could be useful. The current interface > suffers badly from lack of user testing, and I'd hate for the same to be > true of the new one. Yes. > If you need more help with user studies, I should be able get some help > from the usability research lab here. I know one of the profs here > expressed interest in mailman usability in the past, and we may be able > to find people willing to work on the problem. That would be the perfect opportunity. Please ask him if he's still interested. The question is: How do I get there. I life in Munich, Germany. p at rick -- 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 Amtsgericht M?nchen Partnerschaftsregister PR 563 From cmpalmer at garp.metalab.unc.edu Sat May 9 20:41:40 2009 From: cmpalmer at garp.metalab.unc.edu (=?iso-8859-1?Q?Crist=F3bal?= Palmer) Date: Sat, 9 May 2009 14:41:40 -0400 Subject: [Mailman-Developers] Proposal: option for UTF-8 emails without base64 encoding In-Reply-To: References: Message-ID: <20090509184140.GJ7333@garp.metalab.unc.edu> On Fri, May 01, 2009 at 09:01:32AM +0200, Petr Hroudn? wrote: > With base64, emails grow in size by 33 % and such emails > are getting much higher spam > scores since base64 is typically used by spammers to obfuscate the > payload. There are of course > much more reasons for not using base64 as the primary encoding method > for UTF-8 email. +1 for the proposed switch away from base64. This will be a boon for ibiblio lists. Thanks, -- Crist?bal Palmer ibiblio.org systems administrator cdla.unc.edu research assistant From barry at list.org Fri May 15 04:54:44 2009 From: barry at list.org (Barry Warsaw) Date: Thu, 14 May 2009 22:54:44 -0400 Subject: [Mailman-Developers] Proposal: option for UTF-8 emails without base64 encoding In-Reply-To: References: Message-ID: <223519D4-193B-4234-A6F3-3DB475C10869@list.org> On May 1, 2009, at 3:01 AM, Petr Hroudn? wrote: > due to Python defaults, mailman exhibits strange behaviour when > processing UTF-8 emails. > When no header/footer is configured, mailman passes UTF-8 emails in > original form, i.e. 8bit. > However, when either header or footer is configured in mailman, it > uses Python's libraries to > add them and as a side effect it converts 8bit emails into 7bit base64 > encoded ones. Just to be clear, we're talking about headers and footers added by appending the text to the main body, right? When headers and footers are attached via MIME, Mailman always does the right thing? > This is highly undesirable in some cases. For instance, mailinglist > might be used to distribute > trouble tickets or other content which is expected to be easily > parsable by automated text-based > utilities. With base64, emails grow in size by 33 % and such emails > are getting much higher spam > scores since base64 is typically used by spammers to obfuscate the > payload. There are of course > much more reasons for not using base64 as the primary encoding method > for UTF-8 email. One option of course would be to simply not add headers and footers for these types of mailing lists. Another option, which I proposed in bug 373083, is to add an option to force a mailing list to always attach headers and footers as MIME. You risk some users not seeing them because their MUA doesn't display them inline and they don't know how to click on the attachments, but I think that's an acceptable risk for the minority of mailing lists that care about this. At least for MM2.1. > The fix is quite simple and is already widely used by other projects. > All that needs to be done is > to redefine Python's UTF-8 charset properties, i.e. in every place > where you have > > from email.Charset import Charset > > you need to add: > > email.Charset.add_charset('utf-8',email.Charset.SHORTEST, None, None) > > With such setting, mailman will keep the 8bit encoding also when it's > adding header/footer and won't downconvert to 7bit+base64. So I'd like > to propose the above addition, at least as a configurable option > if there's any fear that enabling it by default could cause some > problems. I'll note that you don't need to change Mailman at all do to this. You simply need to add this to your mm_cfg.py file and I'll bet it will just work for you. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From barry at list.org Fri May 15 23:12:23 2009 From: barry at list.org (Barry Warsaw) Date: Fri, 15 May 2009 17:12:23 -0400 Subject: [Mailman-Developers] [Mailman-Users] Deleting messages from archive.... In-Reply-To: <20090515210454.GC27487@charite.de> References: <20090515210454.GC27487@charite.de> Message-ID: <63C063C4-9362-4352-B7FB-E90A0E7D7044@list.org> On May 15, 2009, at 5:04 PM, Ralf Hildebrandt wrote: > * Mark Sapiro : >> Charles Gregory wrote: >>> >>> Has anyone ever developed a point-n-click tool to delete >>> a message from an archive, preferably by just eliminating the >>> From/To/Subject and body, but leaving the links intact, with >>> a placeholder message that says "message content removed", etc? >> >> >> Not as far as I know. > > It would totally rule. Especially on python.org, where people regret > posting their full name because "employers tend to google them", and > then come running to us, asking "Please remove my name". > > Fucktards. > > But I like the idea of such a function. I've long thought that all archives should be vended dynamically rather than statically, of course with a cache to improve performance as necessary. This would allow you to do lots of interesting things, such as add links dynamically (e.g. "bug 12345" pointing to your bug tracker), or on-the-fly modification of archive style or anti-spam obfuscation, with the proper cache invalidation. This would also allow you to "delete" a message from the archive, by laying down a marker that causes the program to instead return a "not available" or cleansed message without affecting the underlying data. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From hopkinsju at umsystem.edu Sat May 16 03:10:54 2009 From: hopkinsju at umsystem.edu (Hopkins, Justin) Date: Fri, 15 May 2009 20:10:54 -0500 Subject: [Mailman-Developers] Set cookies for global authentication Message-ID: Hey all, I manage approx 50 discussion lists using the mailman system. The nature of our organization is that one member is more than likely subscribed to more than just 1 list. One issue that has come up among the membership is the desire to authenticate only once and then be permitted to access the private archives for all lists that they are subscribed to without logging in again. I've noticed that using administrative credentials created a cookie named 'site' whereas a normal login creates a cookie identifying the users email address and the individual list. Has anyone worked on changing this functionality, or is it planned for Mailman 3? I've scoured list archives and the internet in general and haven't found even a hint that anyone is working on this or even feels like it's worth complaining about. Thoughts? Cheers, Justin J. Hopkins MOBIUS, Internet Applications Specialist hopkinsju at umsystem.edu From petr.hroudny at gmail.com Fri May 15 09:09:51 2009 From: petr.hroudny at gmail.com (=?UTF-8?Q?Petr_Hroudn=C3=BD?=) Date: Fri, 15 May 2009 09:09:51 +0200 Subject: [Mailman-Developers] Proposal: option for UTF-8 emails without base64 encoding In-Reply-To: <223519D4-193B-4234-A6F3-3DB475C10869@list.org> References: <223519D4-193B-4234-A6F3-3DB475C10869@list.org> Message-ID: 2009/5/15 Barry Warsaw : >> The fix is quite simple and is already widely used by other projects. >> All that needs to be done is >> to redefine Python's UTF-8 charset properties, i.e. in every place >> where you have >> >> from email.Charset import Charset >> >> you need to add: >> >> email.Charset.add_charset('utf-8',email.Charset.SHORTEST, None, None) >> >> With such setting, mailman will keep the 8bit encoding also when it's >> adding header/footer and won't downconvert to 7bit+base64. So I'd like >> to propose the above addition, at least as a configurable option >> if there's any fear that enabling it by default could cause some problems. > > I'll note that you don't need to change Mailman at all do to this. ?You > simply need to add this to your mm_cfg.py file and I'll bet it will just > work for you. It works indeed! Just a slightly different syntax needs to be used: import email.Charset email.Charset.add_charset('utf-8',email.Charset.SHORTEST, None, None) It might probably make sense to document this somewhere, or perhaps introduce a new config option for MM2.2 which will do this. Almost all MTAs today are 8bit clean, so having an option to work in 8bit mode will surely be attractive for many. Thanks, Petr P.S. I responded to your other comments into bug #373083 notes. From adam-mailman at amyl.org.uk Mon May 18 02:31:37 2009 From: adam-mailman at amyl.org.uk (Adam McGreggor) Date: Mon, 18 May 2009 01:31:37 +0100 Subject: [Mailman-Developers] Set cookies for global authentication In-Reply-To: References: Message-ID: <20090518003137.GL1427@amyl.org.uk> On Fri, May 15, 2009 at 08:10:54PM -0500, Hopkins, Justin wrote: > One issue that has come up among the membership > is the desire to authenticate only once and then be permitted to access > the private archives for all lists that they are subscribed to without > logging in again. > > Has anyone worked on changing this functionality, or is it planned for Hum, we're sort of doing something like that, at least for lists-admin. () might be a starting point for you. (and also ()) (In our case authentication works via Apache Basic Auth, unix groups, and password-generation scripts () it should be quite trivial to implement using LDAP, too.) -- ``What lawyers call intellectual property is no more than theft from the public domain.'' (Andy Mueller-Maguhn) From mark at msapiro.net Mon May 18 03:37:28 2009 From: mark at msapiro.net (Mark Sapiro) Date: Sun, 17 May 2009 18:37:28 -0700 Subject: [Mailman-Developers] Set cookies for global authentication In-Reply-To: Message-ID: Hopkins, Justin wrote: > >I manage approx 50 discussion lists using the mailman system. The nature >of our organization is that one member is more than likely subscribed to >more than just 1 list. One issue that has come up among the membership >is the desire to authenticate only once and then be permitted to access >the private archives for all lists that they are subscribed to without >logging in again. > >I've noticed that using administrative credentials created a cookie >named 'site' whereas a normal login creates a cookie identifying the >users email address and the individual list. > >Has anyone worked on changing this functionality, or is it planned for >Mailman 3? I've scoured list archives and the internet in general and >haven't found even a hint that anyone is working on this or even feels >like it's worth complaining about. Did you look at ? The very first paragraph says in part "Many things that people have been wanting for years will be addressed, most notably a unified user database ...". The unified user database will address this and several other issues involving user email addresses, roles, authentication, etc. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at list.org Mon May 18 15:41:05 2009 From: barry at list.org (Barry Warsaw) Date: Mon, 18 May 2009 09:41:05 -0400 Subject: [Mailman-Developers] Set cookies for global authentication In-Reply-To: References: Message-ID: <5EBA6B30-C35C-4FD3-94D6-EA5F7E5CDB0C@list.org> On May 15, 2009, at 9:10 PM, Hopkins, Justin wrote: > Has anyone worked on changing this functionality, or is it planned for > Mailman 3? I've scoured list archives and the internet in general and > haven't found even a hint that anyone is working on this or even feels > like it's worth complaining about. This will be the case in MM3, because you'll have just one 'account' under the unified user database. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From hopkinsju at umsystem.edu Mon May 18 16:15:05 2009 From: hopkinsju at umsystem.edu (Hopkins, Justin) Date: Mon, 18 May 2009 09:15:05 -0500 Subject: [Mailman-Developers] Set cookies for global authentication In-Reply-To: References: Message-ID: Mark, > Did you look at ? The very first paragraph > says in part "Many things that people have been wanting for years will > be addressed, most notably a unified user database ...". I hadn't seen that no. Thanks for pointing it out. Until Mailman 3 is released, I'm going to look at the approach Adam is using. Thanks Adam. Cheers, Justin From stephen at xemacs.org Fri May 22 06:27:35 2009 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 22 May 2009 13:27:35 +0900 Subject: [Mailman-Developers] Should Mailman provide periodic activity summaries to list owners? Message-ID: <87ab55g3t4.fsf@uwakimon.sk.tsukuba.ac.jp> A quick search didn't find anything, so I'll do a more careful check and if there's nothing I'll add a tracker RFE and a short wiki page of the imagined feature, probably on Monday. Unfortunately, I can't volunteer to implement at this time. Details: I noticed that we've been getting a lot of posts from users who are being quite diligent about following up on their own issues, to the extent of their knowledge and accesses, but for one reason or another are not using the logs. Would it be desirable and feasible to send a periodic (options: daily, weekly, monthly, never) activity summary to list owners (similar to the tracker summaries that many trackers send to associated mailing lists)? If someone's list is having problems, then they could get access via the admin interface, which would simply wrap the text report which would be generated for mailing in an HTML PRE element, making for trivial implementation (once the report itself is implemented, of course). Something like Week of May 17-23, 2009 44 incoming messages processed (42 posts, 2 other) 1 message automatically discarded 2 messages held (1 non-member, 1 spam filter) of which 2 messages were approved 41 messages distributed to members 2 weekly digests produced (maximum size reached 1 time(s)) 20 SMTP errors occurred of which 18 posts handled normally by bounce processing 2 subscription requests (probable backscatter) Abstract of discarded messages From: hormel at 163.com To: resident at whitehouse.gov Subject: We cannot transfer $1 million to you without account information Message-ID: Abstract of held messages not configured. Abstract of SMTP errors not configured. From iane at sussex.ac.uk Fri May 22 10:58:13 2009 From: iane at sussex.ac.uk (Ian Eiloart) Date: Fri, 22 May 2009 09:58:13 +0100 Subject: [Mailman-Developers] Should Mailman provide periodic activity summaries to list owners? In-Reply-To: <87ab55g3t4.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87ab55g3t4.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <5004DDA42EA6D3397936593D@lewes.staff.uscs.susx.ac.uk> There's already a script, "mmdsr" knocking about that does this. There's a version at , but I'm not sure whether it's the latest version --On 22 May 2009 13:27:35 +0900 "Stephen J. Turnbull" wrote: > A quick search didn't find anything, so I'll do a more careful check > and if there's nothing I'll add a tracker RFE and a short wiki page of > the imagined feature, probably on Monday. Unfortunately, I can't > volunteer to implement at this time. > > Details: > > I noticed that we've been getting a lot of posts from users who are > being quite diligent about following up on their own issues, to the > extent of their knowledge and accesses, but for one reason or another > are not using the logs. > > Would it be desirable and feasible to send a periodic (options: daily, > weekly, monthly, never) activity summary to list owners (similar to > the tracker summaries that many trackers send to associated mailing > lists)? > > If someone's list is having problems, then they could get access via > the admin interface, which would simply wrap the text report which > would be generated for mailing in an HTML PRE element, making for > trivial implementation (once the report itself is implemented, of > course). > > Something like > > Week of May 17-23, 2009 > > 44 incoming messages processed (42 posts, 2 other) > > 1 message automatically discarded > 2 messages held (1 non-member, 1 spam filter) of which > 2 messages were approved > 41 messages distributed to members > 2 weekly digests produced (maximum size reached 1 time(s)) > 20 SMTP errors occurred of which > 18 posts handled normally by bounce processing > 2 subscription requests (probable backscatter) > > Abstract of discarded messages > > From: hormel at 163.com To: resident at whitehouse.gov > Subject: We cannot transfer $1 million to you without account information > Message-ID: > > Abstract of held messages not configured. > > Abstract of SMTP errors not configured. > > _______________________________________________ > 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 stephen at xemacs.org Fri May 22 14:25:17 2009 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 22 May 2009 21:25:17 +0900 Subject: [Mailman-Developers] Should Mailman provide periodic activity summaries to list owners? In-Reply-To: <5004DDA42EA6D3397936593D@lewes.staff.uscs.susx.ac.uk> References: <87ab55g3t4.fsf@uwakimon.sk.tsukuba.ac.jp> <5004DDA42EA6D3397936593D@lewes.staff.uscs.susx.ac.uk> Message-ID: <87vdnte34i.fsf@uwakimon.sk.tsukuba.ac.jp> Ian Eiloart writes: > There's already a script, "mmdsr" knocking about that does this. There's a > version at > , Sure, but that script requires being mailman in a shell on the host. The people I'm worried about mostly don't have those privileges, and for debugging an urgent problem you'd want it available on-demand. From mark at msapiro.net Fri May 22 16:16:20 2009 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 22 May 2009 07:16:20 -0700 Subject: [Mailman-Developers] Should Mailman provide periodic activity summaries to list owners? In-Reply-To: <87vdnte34i.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: Stephen J. Turnbullwrote: >Ian Eiloart writes: > > > There's already a script, "mmdsr" knocking about that does this. There's a > > version at > > , The latest version can be found at . >Sure, but that script requires being mailman in a shell on the host. >The people I'm worried about mostly don't have those privileges, and >for debugging an urgent problem you'd want it available on-demand. I don't think it would be too difficult to refactor mmdsr as a python script that could be run on demand through a CGI or to run it via cron as it is currently designed and cache the output to be served by a CGI. The real issue is that mmdsr is a global report. Stephen appears to be thinking more of a list specific report for list owners. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From adam-mailman at amyl.org.uk Fri May 22 16:55:24 2009 From: adam-mailman at amyl.org.uk (Adam McGreggor) Date: Fri, 22 May 2009 15:55:24 +0100 Subject: [Mailman-Developers] Should Mailman provide periodic activity summaries to list owners? In-Reply-To: References: <87vdnte34i.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20090522145524.GU1677@amyl.org.uk> On Fri, May 22, 2009 at 07:16:20AM -0700, Mark Sapiro wrote: > The real issue is that mmdsr is a global report. Stephen appears to be > thinking more of a list specific report for list owners. My mailman stats script accepts an arguement, which if specified will run for that arguement, assuming it to be a listname; if no arguement (or 'ALL', it runs through the whole lot) It's something I cobbled together in bash; but doesn't seem to be in my public code repo at the mo. -- "The lamps are going out all over Europe; we shall not see them lit again in our lifetime." (Attrib. Edward Grey, 1914) From stephen at xemacs.org Fri May 22 17:18:13 2009 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 23 May 2009 00:18:13 +0900 Subject: [Mailman-Developers] Should Mailman provide periodic activity summaries to list owners? In-Reply-To: References: <87vdnte34i.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <87r5yhdv4a.fsf@uwakimon.sk.tsukuba.ac.jp> Mark Sapiro writes: > The real issue is that mmdsr is a global report. Stephen appears to be > thinking more of a list specific report for list owners. Yes. From amk at amk.ca Tue May 26 03:22:13 2009 From: amk at amk.ca (A.M. Kuchling) Date: Mon, 25 May 2009 21:22:13 -0400 Subject: [Mailman-Developers] Should Mailman provide periodic activity summaries to list owners? In-Reply-To: <87ab55g3t4.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87ab55g3t4.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20090526012124.GA158@andrew-kuchlings-macbook.local> On Fri, May 22, 2009 at 01:27:35PM +0900, Stephen J. Turnbull wrote: > Would it be desirable and feasible to send a periodic (options: daily, > weekly, monthly, never) activity summary to list owners (similar to > the tracker summaries that many trackers send to associated mailing > lists)? There's also the bounce-analysis branch I have on Launchpad, which adds the message-ID to Mailman's internal logs in various places and adds a bounce-stats script that correlates the Mailman and Postfix logs to produce some statistics. It would be better if Mailman tracked these statistics internally, but my employer needed the feature in Mailman 2.1 and I didn't want to make our Mailman branch diverge even further. --amk From jenred at gmail.com Wed May 27 21:57:11 2009 From: jenred at gmail.com (Jennifer Redman) Date: Wed, 27 May 2009 12:57:11 -0700 Subject: [Mailman-Developers] Mailman 2.1x Authentication LDAP and OpenID - SQL Member Adaptor Message-ID: <93f118f0905271257y279de9ccj8a2f52c3d2936e7b@mail.gmail.com> Hello, One of the Systers' Google Summer of Code Projects is abstracting Mailman authentication for use with other application frameworks via LDAP and potentially OpenID, using a SQL Member Adaptor. If anyone has a good round-up of existing code or efforts to do this in MM 2x (using a SQL Member Adaptor) or would be interested in providing some mentoring support to our GSoC student leading the project (particularly with regards to doing things the "Mailman Way"), please let me know. If you are interested in contributing to the project, with either some mentoring or code contributions -- please join our development mailing list - http://www.systers.org/mailman/listinfo/systers-dev. Thanks, Jennifer From areguera at allmail.net Thu May 28 17:34:38 2009 From: areguera at allmail.net (Alain Reguera Delgado) Date: Thu, 28 May 2009 11:34:38 -0400 Subject: [Mailman-Developers] Mailman-2.1.9: User Interface Customization Message-ID: <1243524878.25979.1317653405@webmail.messagingengine.com> Hello, As part of a web redesign I've customized mailman-2.1.9 user interface. I would like to know if these changes are useful for the project somehow. http://wiki.centos.org/WebsiteVer2/WebEnvironment/Mailman Thanks for this great software. Best Regards, -- Alain Reguera Delgado areguera at allmail.net -- http://www.fastmail.fm - Access your email from home and the web From barry at list.org Fri May 29 16:35:16 2009 From: barry at list.org (Barry Warsaw) Date: Fri, 29 May 2009 10:35:16 -0400 Subject: [Mailman-Developers] Should Mailman provide periodic activity summaries to list owners? In-Reply-To: <87ab55g3t4.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87ab55g3t4.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <3126CE5A-5E29-4563-89A8-397176771DA3@list.org> On May 22, 2009, at 12:27 AM, Stephen J. Turnbull wrote: > Would it be desirable and feasible to send a periodic (options: daily, > weekly, monthly, never) activity summary to list owners (similar to > the tracker summaries that many trackers send to associated mailing > lists)? > > If someone's list is having problems, then they could get access via > the admin interface, which would simply wrap the text report which > would be generated for mailing in an HTML PRE element, making for > trivial implementation (once the report itself is implemented, of > course). My plan is to collect this information in Mailman 3, making it available via the web ui and admin REST interface. Adding an email reporting infrastructure would not be difficult, once the basic information is being collected. We write much of this to the log files (with more consistent formatting in MM3), but I'd also like to write it to a database table. That last bit isn't implemented yet. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From barry at list.org Fri May 29 16:36:45 2009 From: barry at list.org (Barry Warsaw) Date: Fri, 29 May 2009 10:36:45 -0400 Subject: [Mailman-Developers] Should Mailman provide periodic activity summaries to list owners? In-Reply-To: <20090526012124.GA158@andrew-kuchlings-macbook.local> References: <87ab55g3t4.fsf@uwakimon.sk.tsukuba.ac.jp> <20090526012124.GA158@andrew-kuchlings-macbook.local> Message-ID: <945D08DD-69C6-465F-991D-66E1869502EF@list.org> On May 25, 2009, at 9:22 PM, A.M. Kuchling wrote: > On Fri, May 22, 2009 at 01:27:35PM +0900, Stephen J. Turnbull wrote: >> Would it be desirable and feasible to send a periodic (options: >> daily, >> weekly, monthly, never) activity summary to list owners (similar to >> the tracker summaries that many trackers send to associated mailing >> lists)? > > There's also the bounce-analysis branch I have on Launchpad, which > adds the message-ID to Mailman's internal logs in various places and > adds a bounce-stats script that correlates the Mailman and Postfix > logs to produce some statistics. When Andrew told me about this, I thought it was such a good idea, I fixed MM3's log writing call sites to do the same. :) -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From barry at python.org Fri May 29 21:48:09 2009 From: barry at python.org (Barry Warsaw) Date: Fri, 29 May 2009 15:48:09 -0400 Subject: [Mailman-Developers] Mailman 2.1x Authentication LDAP and OpenID - SQL Member Adaptor In-Reply-To: <93f118f0905271257y279de9ccj8a2f52c3d2936e7b@mail.gmail.com> References: <93f118f0905271257y279de9ccj8a2f52c3d2936e7b@mail.gmail.com> Message-ID: <88CF36E4-69B8-4E9A-A196-A917D6C03271@python.org> On May 27, 2009, at 3:57 PM, Jennifer Redman wrote: > Hello, > One of the Systers' Google Summer of Code Projects is abstracting > Mailman > authentication for use with other application frameworks via LDAP and > potentially OpenID, using a SQL Member Adaptor. > > If anyone has a good round-up of existing code or efforts to do this > in MM > 2x (using a SQL Member Adaptor) or would be interested in providing > some > mentoring support to our GSoC student leading the project > (particularly with > regards to doing things the "Mailman Way"), please let me know. > > If you are interested in contributing to the project, with either some > mentoring or code contributions -- please join our development > mailing list > - http://www.systers.org/mailman/listinfo/systers-dev. I'm going to concentrate on MM3, but at the recent UDS (Ubuntu Developer Summit), I spoke with one of my colleagues who's working on a plugin for MM3 and LDAP. I would of course love to see contributions for any of LDAP, and OpenID for MM3. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: