From bjdean at bjdean.id.au Fri May 6 06:22:38 2011 From: bjdean at bjdean.id.au (Bradley Dean) Date: Fri, 06 May 2011 14:22:38 +1000 Subject: [Mailman-Developers] Converting the Mailman wiki Message-ID: <4DC3778E.3000806@bjdean.id.au> Greetings folks, I'm part of the new group that John Sullivan of the FSF has brought together to look at migrating the Mailman wiki from Confluence to MoinMoin. We've all just been introduced to each other so we're still very much at the beginning of getting ourselves organised; I've said that I would get in contact with you to ask a few initial questions to help us on our way. So - here we go, and in no particular order: * It looks like confluence supports XML exports for the purpose of backup/restore Have you done this? If the confluence database is in a proprietary format I would this this might be the best way to get at the data. I would also think that it might contain the most complete version of the data (apart from direct access to the database) in terms of preserving meta-data like authorship and version history. * If the export is not available / possible for some reason what would you suggest would be the best approach for us to access the wiki? Do we just need accounts within the wiki, or do we need an account on the hosting server? * A rather open-ended question - but what is your priority in terms of the migration? By this I mean: - which content from the wiki (could be all of it!) - how much meta-data (version history, authors, etc.) - administrative data like users and logins (nb. it may not be possible to bring passwords across) And of course any other comments and suggestions are very welcome. Cheerio, Brad -- Bradley Dean Email: bjdean at bjdean.id.au Skype: skype at bjdean.id.au Mobile(Aus): +61-413014395 WWW: http://bjdean.id.au/ S/MIME: http://bjdean.id.au/certs/email-public-rsa.txt From barry at list.org Fri May 6 17:14:45 2011 From: barry at list.org (Barry Warsaw) Date: Fri, 6 May 2011 11:14:45 -0400 Subject: [Mailman-Developers] Converting the Mailman wiki In-Reply-To: <4DC3778E.3000806@bjdean.id.au> References: <4DC3778E.3000806@bjdean.id.au> Message-ID: <20110506111445.69773c88@neurotica.wooz.org> Hi Bradley, On May 06, 2011, at 02:22 PM, Bradley Dean wrote: >I'm part of the new group that John Sullivan of the FSF has brought together >to look at migrating the Mailman wiki from Confluence to MoinMoin. Excellent! >We've all just been introduced to each other so we're still very much at the >beginning of getting ourselves organised; I've said that I would get in >contact with you to ask a few initial questions to help us on our way. > >So - here we go, and in no particular order: > > * It looks like confluence supports XML exports for the purpose of > backup/restore Have you done this? If the confluence database is in a > proprietary format I would this this might be the best way to get at the > data. I would also think that it might contain the most complete version > of the data (apart from direct access to the database) in terms of > preserving meta-data like authorship and version history. The administrative interface does have options to download for backup an XML dump of the data. There's currently a big red warning saying it's disabled "for security purposes", so I don't really know if it works, or what it gives you. I'm certainly willing to give at least one member of your team administrative access, and we can verify with the hosting provider that you should be able to get the XML dump. If that's not enough data to do the job, then we'll talk to the hosting provider about getting what you need. > * If the export is not available / possible for some reason what would you > * suggest would be the best approach for us to access the wiki? Do we just > * need accounts within the wiki, or do we need an account on the hosting > * server? We don't have accounts on the hosting server, but Contegix's customer support has always been very good about responding to our requests, so I'm confident we can get you the data you'll need. > * A rather open-ended question - but what is your priority in terms of the > * migration? By this I mean: > - which content from the wiki (could be all of it!) Yes, I'd like to import everything, including attachments. A couple of things though: * We have a number of groups to manage write permission and such. We've used that to control wiki spam. I don't know enough about Moin's user and permission model to know how that will map, but if possible I'd like to keep as close to the current arrangement as possible. * Some pages are private to the steering committee. However, I *think* there's only one such page and it's pretty out of date, so I really don't care if we just remove it. * We have a nice u/i mockup plugin called Balsamiq, which (you guessed it) is not free software. Okay, so we'll lose that, but I'd like to at least keep png/jpg/gif/pdf of the existing mockups. > - how much meta-data (version history, authors, etc.) We'd definitely like to keep history. Authors I suppose will be difficult if we don't import the user database (I don't know what if any of that is available in the XML dump). Ideally, we'd like to keep as much metadata as is available. > - administrative data like users and logins (nb. it may not be possible > - to bring passwords across) Right. I'm okay if people have to do a password reset to gain access. Ideally we'd at least port over the users. I'm also okay if that's not possible. >And of course any other comments and suggestions are very welcome. Nothing more from me at the moment. Mark might have additional comments since he's probably the most frequent author on the wiki. Thanks for your help! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From mark at msapiro.net Fri May 6 18:27:20 2011 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 06 May 2011 09:27:20 -0700 Subject: [Mailman-Developers] Converting the Mailman wiki In-Reply-To: <20110506111445.69773c88@neurotica.wooz.org> References: <4DC3778E.3000806@bjdean.id.au> <20110506111445.69773c88@neurotica.wooz.org> Message-ID: <4DC42168.10801@msapiro.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/6/2011 8:14 AM, Barry Warsaw wrote: > > * We have a number of groups to manage write permission and such. We've used > that to control wiki spam. I don't know enough about Moin's user and > permission model to know how that will map, but if possible I'd like to keep > as close to the current arrangement as possible. Moin supports groups and access controls by group. Management of these is different from Confluence, but I think it can map reasonably well. > * Some pages are private to the steering committee. However, I *think* > there's only one such page and it's pretty out of date, so I really don't > care if we just remove it. Moin can handle this. > Right. I'm okay if people have to do a password reset to gain access. > Ideally we'd at least port over the users. I'm also okay if that's not > possible. I think it will be possible to port the existing usernames, and as long as we have email addresses for them, they can do a password reset. There is an issue in that Moin likes CamelCase UserNames. It's not a requirement, but without it, the username doesn't link to the user's home page. User home pages are not required, but they can be handy. I don't know if it's relevant at this point since we've already decided on Moin, but if anyone wants to look at or even play with a small Moin wiki, go to , and if you have any questions after looking/playing, ask me. It's OK to add pages to this wiki, but I will probably delete them after a short time. > Nothing more from me at the moment. Mark might have additional comments since > he's probably the most frequent author on the wiki. Thanks for your help! I don't have anything at the moment beyond what's above. - -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD4DBQFNxCFoVVuXXpU7hpMRAlm1AJY4YqnCyXoa5RebQY0jSkQhSyylAJ9lkj01 gcMrXbP1HXXSg+hpHjEXIQ== =eG/R -----END PGP SIGNATURE----- From bjdean at bjdean.id.au Mon May 9 16:30:12 2011 From: bjdean at bjdean.id.au (Bradley Dean) Date: Tue, 10 May 2011 00:30:12 +1000 Subject: [Mailman-Developers] Converting the Mailman wiki In-Reply-To: <20110506111445.69773c88@neurotica.wooz.org> References: <4DC3778E.3000806@bjdean.id.au> <20110506111445.69773c88@neurotica.wooz.org> Message-ID: <4DC7FA74.3050900@bjdean.id.au> Hi Barry and co., On 07/05/11 01:14, Barry Warsaw wrote: >> I'm part of the new group that John Sullivan of the FSF has brought together >> to look at migrating the Mailman wiki from Confluence to MoinMoin. > > Excellent! Though there's not much there at the moment you can see what we're up to here: https://gitorious.org/confluence2moinmoin https://gitorious.org/confluence2moinmoin/pages/Home http://lists.bjdean.id.au/cgi-bin/mailman/listinfo/mmwiki > The administrative interface does have options to download for backup an XML > dump of the data. There's currently a big red warning saying it's disabled > "for security purposes", so I don't really know if it works, or what it gives > you. I'm certainly willing to give at least one member of your team > administrative access, and we can verify with the hosting provider that you > should be able to get the XML dump. If that's not enough data to do the job, > then we'll talk to the hosting provider about getting what you need. If one of you has access to export the backup XML and send it through to me (or point me to a download URL if it's large) I would think that would be sufficient. We shouldn't need ongoing access to Confluence. I would expect that we could analyse the initial data dump, build and test the conversion process and then ask for one more export just before the switch-over. On the other hand if you'd prefer us to make the export please set up an account for me and I'll see what I can do (I'm not familiar with Confluence, so it might take me longer to find it and check that the export was running as expected). > Nothing more from me at the moment. Mark might have additional comments since > he's probably the most frequent author on the wiki. I agree with Mark's comments on MoinMoin - it does support most of what you asked for in terms of history, attachments, groups and private pages. User groups and accesses can be defined in anticipation of the existence of a user account (ie you can define an acl which refers to a user that doesn't exist yet). There's a bit of a security problem there so I would think we'd also create user accounts with a random password and the user's email address - which can then be used for a reset. Until we see the XML export we can't really say how much of that data we can get to in order to transform it across - but I'd be surprised if a lot of that data was not available. I was going to say that our meta-data (other than author and revisions) support is a bit limited in moin1, however looking at the wiki pages in Confluence is doesn't look like there's much more there (or at least it's not being used). There may be better support in moin2 howver our advice from Thomas Waldmann of MoinMoin (http://moinmo.in/ThomasWaldmann) is that we should be aiming for 1.9 as 2 is not yet ready for production. > Thanks for your help! No worries! Thanks for Mailman! Cheerio, Brad -- Bradley Dean Email: bjdean at bjdean.id.au Skype: skype at bjdean.id.au Mobile(Aus): +61-413014395 WWW: http://bjdean.id.au/ S/MIME: http://bjdean.id.au/certs/email-public-rsa.txt From cjac at colliertech.org Fri May 13 19:01:28 2011 From: cjac at colliertech.org (C.J. Adams-Collier KF7BMP) Date: Fri, 13 May 2011 10:01:28 -0700 Subject: [Mailman-Developers] List Administration Manual r2.1 Message-ID: <1305306088.6945.61.camel@calcifer> Hello folks, I'm putting together a proposal for the use of mailman to a potential client and would like to deliver a complete set of documentation. The List Administration Manual looks like it's nearly finished and just needs a bit of work by a technical writer with experience in the subject area. I've been participating in mailman lists since at least 2002 and administering and moderating successful and unsuccessful lists on my own hardware and others' since 2003. I have also racked up about 9 months of experience developing LaTeX documents during grad school. I still consider myself a bit of a neophyte in this area and will be needing some help setting up the LaTeX environment for compiling the .dvi files. At this point, I installed the python-sphinx package (debian) and copied the /usr/share/sphinx/texinputs/howto.cls it provides to the build directory. I am getting the following error and would appreciate any insight you can provide. Cheers, C.J. $ latex mailman-admin.tex This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) entering extended mode (./mailman-admin.tex LaTeX2e <2009/09/24> Babel and hyphenation patterns for english, usenglishmax, dumylang, noh yphenation, loaded. (./howto.cls Document Class: howto 2008/10/18 Document class (Sphinx HOWTO) (/usr/share/texmf-texlive/tex/latex/base/article.cls Document Class: article 2007/10/19 v1.4h Standard LaTeX document class (/usr/share/texmf-texlive/tex/latex/base/size10.clo))) ! Undefined control sequence. l.7 \release {1.0} -------------- 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 Fri May 13 21:14:18 2011 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 13 May 2011 12:14:18 -0700 Subject: [Mailman-Developers] List Administration Manual r2.1 In-Reply-To: <1305306088.6945.61.camel@calcifer> References: <1305306088.6945.61.camel@calcifer> Message-ID: <4DCD830A.1010908@msapiro.net> On 5/13/2011 10:01 AM, C.J. Adams-Collier KF7BMP wrote: > > I have also racked up about 9 months of experience developing LaTeX > documents during grad school. I still consider myself a bit of a > neophyte in this area and will be needing some help setting up the LaTeX > environment for compiling the .dvi files. At this point, I installed > the python-sphinx package (debian) and copied > the /usr/share/sphinx/texinputs/howto.cls it provides to the build > directory. I am getting the following error and would appreciate any > insight you can provide. I'm not sure about the specific error you are encountering. I've never used Sphinx on these .tex files. The documentation package is built with the old Python mkhowto script. This script can be found at . It has several dependencies, and I don't remember what they all are. To make the various files from mailman-admin.tex, you do mkhowto --all --dir /path/to/html/dir mailman-admin.tex where /path/to/html/dir is the directory to receive the HTML manual. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From cjac at colliertech.org Fri May 13 22:01:59 2011 From: cjac at colliertech.org (C.J. Adams-Collier KF7BMP) Date: Fri, 13 May 2011 13:01:59 -0700 Subject: [Mailman-Developers] List Administration Manual r2.1 In-Reply-To: <4DCD830A.1010908@msapiro.net> References: <1305306088.6945.61.camel@calcifer> <4DCD830A.1010908@msapiro.net> Message-ID: <1305316919.6945.102.camel@calcifer> On Fri, 2011-05-13 at 12:14 -0700, Mark Sapiro wrote: > On 5/13/2011 10:01 AM, C.J. Adams-Collier KF7BMP wrote: > > > > I have also racked up about 9 months of experience developing LaTeX > > documents during grad school. I still consider myself a bit of a > > neophyte in this area and will be needing some help setting up the LaTeX > > environment for compiling the .dvi files. At this point, I installed > > the python-sphinx package (debian) and copied > > the /usr/share/sphinx/texinputs/howto.cls it provides to the build > > directory. I am getting the following error and would appreciate any > > insight you can provide. > > > I'm not sure about the specific error you are encountering. I've never > used Sphinx on these .tex files. The documentation package is built with > the old Python mkhowto script. This script can be found at > . > It has several dependencies, and I don't remember what they all are. > > To make the various files from mailman-admin.tex, you do > > mkhowto --all --dir /path/to/html/dir mailman-admin.tex > > where /path/to/html/dir is the directory to receive the HTML manual. Thank you Mark. It seems the magic conjuration must be invoked similarly to: $ sudo apt-get install python-old-doctools $ rm -f howto.cls $ mkdir /tmp/html $ /usr/lib/python2.5/doc/tools/mkhowto --all --dir /tmp/html mailman-admin.tex > /dev/null 2>&1 $ evince mailman-admin.pdf Good enough for government work. Now to add some content. -------------- 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 cs5070214 at cse.iitd.ac.in Sun May 15 14:33:44 2011 From: cs5070214 at cse.iitd.ac.in (Dushyant Bansal) Date: Sun, 15 May 2011 18:03:44 +0530 Subject: [Mailman-Developers] Apache configuration: Web Interface for archives in mm3 Message-ID: <4DCFC828.2000909@cse.iitd.ac.in> Hi all, I am a gsoc candidate with mailman. I'll be working on archives UI and Search functionality. I'll be blogging about my progress here: http://db42.wordpress.com As my first task is to complete the UI part of the archives, I am trying to get started with pipermail UI. My first question is - Is it possible to view archives via web interface on mailman 3. If yes, can somebody please guide me or provide me hints to make it work. Thanks, Dushyant Bansal From benedict.stein at googlemail.com Sun May 15 18:15:08 2011 From: benedict.stein at googlemail.com (Benedict Stein) Date: Sun, 15 May 2011 18:15:08 +0200 Subject: [Mailman-Developers] Apache configuration: Web Interface for archives in mm3 In-Reply-To: <4DCFC828.2000909@cse.iitd.ac.in> References: <4DCFC828.2000909@cse.iitd.ac.in> Message-ID: Did i understand something incorrectly or is the Django UI only a config website ? Why don't we have all UI parts within the Django project (which I'll support during gsoc ;-)) Einen sch?nen Tag w?nscht: Benedict Stein (versendet ?ber Gmail-Webinterface) 2011/5/15 Dushyant Bansal > Hi all, > I am a gsoc candidate with mailman. I'll be working on archives UI and > Search functionality. I'll be blogging about my progress here: > http://db42.wordpress.com > > As my first task is to complete the UI part of the archives, I am trying to > get started with pipermail UI. > My first question is - Is it possible to view archives via web interface on > mailman 3. > If yes, can somebody please guide me or provide me hints to make it work. > > Thanks, > Dushyant Bansal > > _______________________________________________ > 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/benedict.stein%40googlemail.com > > Security Policy: http://wiki.list.org/x/QIA9 > From barry at python.org Mon May 16 16:36:12 2011 From: barry at python.org (Barry Warsaw) Date: Mon, 16 May 2011 10:36:12 -0400 Subject: [Mailman-Developers] Apache configuration: Web Interface for archives in mm3 In-Reply-To: <4DCFC828.2000909@cse.iitd.ac.in> References: <4DCFC828.2000909@cse.iitd.ac.in> Message-ID: <20110516103612.3e359fc4@neurotica.wooz.org> Welcome Dushyant and our other GSoC students! BTW, I was mostly off-line last week attending the Ubuntu Developer Summit in Budapest. I'm back now so you can ping me on IRC if you want to chat. On May 15, 2011, at 06:03 PM, Dushyant Bansal wrote: >I am a gsoc candidate with mailman. I'll be working on archives UI and Search >functionality. I'll be blogging about my progress here: >http://db42.wordpress.com > >As my first task is to complete the UI part of the archives, I am trying to >get started with pipermail UI. My first question is - Is it possible to view >archives via web interface on mailman 3. If yes, can somebody please guide >me or provide me hints to make it work. The Pipermail archiver in MM3 currently integrates with Apache the same way that Mailman 2.1 did, so it's best to follow those directions for now. This may eventually change, and the instructions are largely untested for MM3, but that's the best way to try to make it work for now. -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 Mon May 16 16:42:12 2011 From: barry at list.org (Barry Warsaw) Date: Mon, 16 May 2011 10:42:12 -0400 Subject: [Mailman-Developers] Apache configuration: Web Interface for archives in mm3 In-Reply-To: References: <4DCFC828.2000909@cse.iitd.ac.in> Message-ID: <20110516104212.50530525@neurotica.wooz.org> On May 15, 2011, at 06:15 PM, Benedict Stein wrote: >Did i understand something incorrectly or is the Django UI only a config >website ? That is currently the case, yes. >Why don't we have all UI parts within the Django project (which I'll support >during gsoc ;-)) It's a good question. There are two things that will influence design decisions for Pipermail's web ui. First, I would eventually like to split Pipermail into a separate sub-package of Mailman, so that it could be used independently, or easily thrown out if someone wants a different archiver. It would also allow Pipermail to advance on a different schedule than the core engine. Second, Pipermail has always generated static HTML files, so the "web ui" such as it is, is basically just Apache vending those static HTML files. Now, I've long thought that it would be better, and technically feasible, to generate the archive HTML on the fly, when a message is requested (with appropriate caching for performance). Doing dynamic generation of those pages would allow for some interesting ideas, such as changing content filtering more easily (e.g. address obfuscation, hyperlinking special text like bug numbers, etc.). But that's also a major redesign of the Pipermail architecture. -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 Mon May 16 17:09:51 2011 From: barry at list.org (Barry Warsaw) Date: Mon, 16 May 2011 11:09:51 -0400 Subject: [Mailman-Developers] List Administration Manual r2.1 In-Reply-To: <1305316919.6945.102.camel@calcifer> References: <1305306088.6945.61.camel@calcifer> <4DCD830A.1010908@msapiro.net> <1305316919.6945.102.camel@calcifer> Message-ID: <20110516110951.55bf0cfe@neurotica.wooz.org> On May 13, 2011, at 01:01 PM, C.J. Adams-Collier KF7BMP wrote: >Good enough for government work. Now to add some content. Thanks C.J. for taking this on, and thanks Mark for helping out with the old doc toolset. For Mailman 3, we are using the reStructuredText format and Sphinx tools. I wouldn't mind it if someone wanted to port the old Mailman 2.1 LaTeX documentation to reST. 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 janssen at parc.com Mon May 16 19:30:02 2011 From: janssen at parc.com (Bill Janssen) Date: Mon, 16 May 2011 10:30:02 PDT Subject: [Mailman-Developers] Apache configuration: Web Interface for archives in mm3 In-Reply-To: <20110516104212.50530525@neurotica.wooz.org> References: <4DCFC828.2000909@cse.iitd.ac.in> <20110516104212.50530525@neurotica.wooz.org> Message-ID: <53223.1305567002@parc.com> Barry Warsaw wrote: > Second, Pipermail has always generated static HTML files, so the "web ui" such > as it is, is basically just Apache vending those static HTML files. Now, I've > long thought that it would be better, and technically feasible, to generate > the archive HTML on the fly, when a message is requested (with appropriate > caching for performance). This is what UpLib does. Actually, it does two things: it generates the static HTML (for the obsolete first-generation UI), but it also generates on-the-fly pages when a page is requested (the more modern, but still needing-to-be-updated current UI). Since UpLib can also process photos, Web pages, Powerpoint decks, Word, PDF, etc., it can display attachments next to the mail message as thumbnails with links to the attachment document. It's a tad tricky to display those documents -- for years I've been using a Java applet, but that's clearly not the wave of the tablet future, so I've been playing with the gnubook code as an alternative. Bill From barry at list.org Mon May 16 19:59:17 2011 From: barry at list.org (Barry Warsaw) Date: Mon, 16 May 2011 13:59:17 -0400 Subject: [Mailman-Developers] Apache configuration: Web Interface for archives in mm3 In-Reply-To: <53223.1305567002@parc.com> References: <4DCFC828.2000909@cse.iitd.ac.in> <20110516104212.50530525@neurotica.wooz.org> <53223.1305567002@parc.com> Message-ID: <20110516135917.429834d0@neurotica.wooz.org> On May 16, 2011, at 10:30 AM, Bill Janssen wrote: >Since UpLib can also process photos, Web pages, Powerpoint decks, Word, >PDF, etc., it can display attachments next to the mail message as >thumbnails with links to the attachment document. It's a tad tricky to >display those documents -- for years I've been using a Java applet, but >that's clearly not the wave of the tablet future, so I've been playing >with the gnubook code as an alternative. I think it would be very cool to build an Uplib adapter for the IArchiver interface in MM3. I can imagine it wouldn't be too difficult, and the nice thing is that in MM3, you can have any number of archivers available or enabled. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From cs5070214 at cse.iitd.ac.in Sat May 21 20:19:31 2011 From: cs5070214 at cse.iitd.ac.in (Dushyant Bansal) Date: Sat, 21 May 2011 23:49:31 +0530 Subject: [Mailman-Developers] Apache configuration: Web Interface for archives in mm3 In-Reply-To: <20110516103612.3e359fc4@neurotica.wooz.org> References: <4DCFC828.2000909@cse.iitd.ac.in> <20110516103612.3e359fc4@neurotica.wooz.org> Message-ID: <4DD80233.2040206@cse.iitd.ac.in> On Monday 16 May 2011 08:06 PM, Barry Warsaw wrote: > The Pipermail archiver in MM3 currently integrates with Apache the same way > that Mailman 2.1 did, so it's best to follow those directions for now. This > may eventually change, and the instructions are largely untested for MM3, but > that's the best way to try to make it work for now. The apache configuration worked for me. Actually, there was one more problem. Pipermail was not generating static html files in the correct way. Each of the static html files just contained the path to the required template files. In function quick_maketext(), in file Archiver/HyperArch.py: template, filepath = find(templatefile, mailing_list=mlist, language=lang.code) Here, find() just returns the path of template file to the 'template' variable whereas, it should return the contents of the template file. In version 2.1, Utils.findtext() works fine. template, filepath = Utils.findtext(templatefile, lang=lang, raw=True, mlist=mlist) So, after modifying find(), I can see Pipermail archives through a web interface. Now, I'll start looking at Yian's code on UI. Regards, Dushyant From stf at eisenbits.com Sun May 22 13:10:49 2011 From: stf at eisenbits.com (=?UTF-8?B?U3RhbmlzxYJhdyBGaW5kZWlzZW4=?=) Date: Sun, 22 May 2011 13:10:49 +0200 Subject: [Mailman-Developers] GnuPG support Message-ID: <4DD8EF39.2080100@eisenbits.com> Hi I have a feature idea: GnuPG encryption and signing. Each list (or just the Mailman instance) has a private/public keypair. Each list subscriber can share her/his public key with Mailman. When sending mail to the list, the user can encrypt it with the list public key. Then Mailman decrypts the mail, and encrypts it back with each subscriber's key. This increases privacy: it will be harder for, for instance, subscriber's server administrator to read her/his mail. What do you think? -- Eisenbits - proven software solutions: http://www.eisenbits.com/ OpenPGP: E3D9 C030 88F5 D254 434C 6683 17DD 22A0 8A3B 5CC0 From mark at msapiro.net Sun May 22 16:03:55 2011 From: mark at msapiro.net (Mark Sapiro) Date: Sun, 22 May 2011 07:03:55 -0700 Subject: [Mailman-Developers] GnuPG support In-Reply-To: <4DD8EF39.2080100@eisenbits.com> Message-ID: Stanislaw Findeisen wrote: > >I have a feature idea: GnuPG encryption and signing. See and . -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From stf at eisenbits.com Mon May 23 00:27:57 2011 From: stf at eisenbits.com (=?UTF-8?B?U3RhbmlzxYJhdyBGaW5kZWlzZW4=?=) Date: Mon, 23 May 2011 00:27:57 +0200 Subject: [Mailman-Developers] GnuPG support In-Reply-To: References: Message-ID: <4DD98DED.6090808@eisenbits.com> On 2011-05-22 16:03, Mark Sapiro wrote: > Stanislaw Findeisen wrote: >> I have a feature idea: GnuPG encryption and signing. > > > See and > . So?... What's the problem with that patch? Why isn't it a part of Mailman? -- Eisenbits - proven software solutions: http://www.eisenbits.com/ OpenPGP: E3D9 C030 88F5 D254 434C 6683 17DD 22A0 8A3B 5CC0 From stephen at xemacs.org Mon May 23 07:47:09 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Mon, 23 May 2011 14:47:09 +0900 Subject: [Mailman-Developers] GnuPG support In-Reply-To: <4DD98DED.6090808@eisenbits.com> References: <4DD98DED.6090808@eisenbits.com> Message-ID: <877h9iarz6.fsf@uwakimon.sk.tsukuba.ac.jp> Stanis?aw Findeisen writes: > On 2011-05-22 16:03, Mark Sapiro wrote: > > Stanislaw Findeisen wrote: > >> I have a feature idea: GnuPG encryption and signing. > > > > > > See and > > . > > So?... What's the problem with that patch? Why isn't it a part of Mailman? Did you read the post? The author of the patch didn't consider it ready for production use and posted it "as is" for interested and capable parties, while Mailman 2.1 is the stable branch, so it won't be applied "as is". Nobody else (including the core developers) stepped up to improve and maintain it, so (1) you can use it "as is" (and keep reapplying it as you update Mailman), or (2) you can do the work to make it production-ready, in which case it might be applied (but Mailman 2 is pretty near end-of-life so it might not), or (3) you can wait for somebody else to do it, in which case it may or may not be part of the distribution for the initial release of Mailman 3, but probably will be incorporated fairly quickly as such things go (it's reasonably frequently requested), or (4) you can pay somebody to do the work, in which case it seems pretty likely that it will be ready for Mailman 3. Note the emphasis on the word "you". What happens to open source software is as much *your* choice as anyone else's. Put on your Nikes and Just Do It! From barry at list.org Mon May 23 16:52:40 2011 From: barry at list.org (Barry Warsaw) Date: Mon, 23 May 2011 10:52:40 -0400 Subject: [Mailman-Developers] GnuPG support In-Reply-To: <4DD8EF39.2080100@eisenbits.com> References: <4DD8EF39.2080100@eisenbits.com> Message-ID: <20110523105240.02a29454@neurotica.wooz.org> On May 22, 2011, at 01:10 PM, Stanis?aw Findeisen wrote: >I have a feature idea: GnuPG encryption and signing. > >What do you think? It's an idea which has been floating around for many years, and as you've seen there are tentative patches in that direction. My own take on the matter is that I think it would be a very interesting and useful feature, but I'm not in favor of adding this to Mailman 2. If you're interested in pursuing this idea further, Mailman 3 is the place to do so. My own inclination is that most sites won't need this, so it should be available as a plugin, with official/unofficial status conferred depending on its stability, documentation, tests, copyright assignments, and general usability. This is exactly the right mailing list to discuss design and implementation of such a feature for Mailman 3. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From stephen at xemacs.org Tue May 24 05:01:49 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 24 May 2011 12:01:49 +0900 Subject: [Mailman-Developers] GnuPG support In-Reply-To: <20110523105240.02a29454@neurotica.wooz.org> References: <4DD8EF39.2080100@eisenbits.com> <20110523105240.02a29454@neurotica.wooz.org> Message-ID: <87vcx0ajj6.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > My own inclination is that most sites won't need this, FWIW, I disagree. Much of the world is moving in the direction of personal IDs, perhaps backed up by an organization (eg, OpenID), rather than IDs tied to a host. Given the prevalence of systems "for the rest of us (who don't have a clue about PGP)", I doubt it will be a majority, but I bet you would get a lot of uptake if it were available. > so it should be available as a plugin, Yes, it should be available as a Handler (or whatever the corresponding component of MM3 architecture is). It's not at all clear to me where in the stack of filters it belongs, and I can easily imagine people wanting to make it early or late. We won't know until we see the practice. BTW, I hate that word, "plugin", which reminds of the hero of "Alice's Restaurant" getting "detected, inspected, injected, and neee-glected, with no part left untouched". Almost certainly you can be a lot more specific about *where* it fits into the architecture, such as "Handler". As far as customizing the pipeline goes, it would be cool if there were a GUI which allowed moving/inserting/deleting Handlers (a la Emacs's "list" widget in Customize). From terri at zone12.com Tue May 24 09:22:48 2011 From: terri at zone12.com (Terri Oda) Date: Tue, 24 May 2011 03:22:48 -0400 Subject: [Mailman-Developers] [GSoC] And they're off! Message-ID: <4DDB5CC8.7060102@zone12.com> Our summer of code students officially started coding on Monday, and they're already working hard! Those of you interested in following what they're doing more closely should check out their blogs: * Dushyant's been busy going through last year's use cases and figuring out how to get things set up and integrated: http://db42.wordpress.com/ * Drew's been trying to grok the internals of pipermail... and a bit of everything else: http://drodmansoc.blogspot.com/ * Benste's been busy understanding the flow of the interface: http://benste.blogspot.com/search/label/gsoc2011 I particularly like Benste's post with a graphical map of the existing interface. Oi, it's complex! http://benste.blogspot.com/2011/05/mailman-20-existing-menu-structure.html Here's to a great first week! Terri From barry at list.org Tue May 24 13:29:51 2011 From: barry at list.org (Barry Warsaw) Date: Tue, 24 May 2011 07:29:51 -0400 Subject: [Mailman-Developers] [GSoC] And they're off! In-Reply-To: <4DDB5CC8.7060102@zone12.com> References: <4DDB5CC8.7060102@zone12.com> Message-ID: <20110524072951.2473caaf@neurotica.wooz.org> On May 24, 2011, at 03:22 AM, Terri Oda wrote: >Our summer of code students officially started coding on Monday, and they're >already working hard! > >Those of you interested in following what they're doing more closely should >check out their blogs: Impressive! -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 Tue May 24 14:07:56 2011 From: barry at list.org (Barry Warsaw) Date: Tue, 24 May 2011 08:07:56 -0400 Subject: [Mailman-Developers] GnuPG support In-Reply-To: <87vcx0ajj6.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4DD8EF39.2080100@eisenbits.com> <20110523105240.02a29454@neurotica.wooz.org> <87vcx0ajj6.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20110524080756.3d0ffdb8@neurotica.wooz.org> On May 24, 2011, at 12:01 PM, Stephen J. Turnbull wrote: >Barry Warsaw writes: > > > My own inclination is that most sites won't need this, > >FWIW, I disagree. Much of the world is moving in the direction of >personal IDs, perhaps backed up by an organization (eg, OpenID), >rather than IDs tied to a host. Given the prevalence of systems "for >the rest of us (who don't have a clue about PGP)", I doubt it will be >a majority, but I bet you would get a lot of uptake if it were >available. Right, I'm not saying there won't be an important constituency that will use a feature like this, but I don't think it will be anywhere near a majority of sites. IME, it's daunting enough to explain *what* pk encryption and digital signatures are to laypeople, let alone explaining why they would want it, and how to set up their mail systems to use it. I personally wish encrypted email was more prevalent, but it's often difficult to get technically savvy friends of mine to use it. > > so it should be available as a plugin, > >Yes, it should be available as a Handler (or whatever the >corresponding component of MM3 architecture is). It's not at all >clear to me where in the stack of filters it belongs, and I can easily >imagine people wanting to make it early or late. We won't know until >we see the practice. Agreed. I'd like to see some experimentation in this area before we commit the project to supporting something specific. I do think the MM3 platform is able to support prototypes right now. >BTW, I hate that word, "plugin", which reminds of the hero of "Alice's >Restaurant" getting "detected, inspected, injected, and neee-glected, >with no part left untouched". Almost certainly you can be a lot more >specific about *where* it fits into the architecture, such as >"Handler". MM2's notion of Handlers is essentially split into two separate pipelines in MM3. There are a set of rules which get run very early on, and each rule registers "did I match or not?". This is where for example, a digital signature could be checked instead of an origination header for more accurate determination of membership. The rules are actually connected in a "chain" and every mailing list has a default rule chain that it runs messages through. Naturally, you can define different chains, with different sets of rules to do whatever you want during this phase of processing. Each link in the chain actually marries a rule with an action. If the rule hits, the action runs. Actions can be any number of things, such as calling a function, jumping to or detouring through another chain, or deferring action until later. The docs have more detail, but I think it's a fairly powerful paradigm for the work done during the "moderation phase" of message processing. There are default chains for accepting, holding, and discarding messages, and others. Once you've run through the rule chain and you've decided to accept the message, it's time to run through the mailing list's pipeline of handlers. These are very similar (in some cases identical modulo refactoring) to MM2's handlers, except they only do the job of preparing the message for delivery, or sending a copy of the message to another queue. Handlers here do the things you expect, they add the message headers and footers, add the RFC 2369 headers, calculate the recipients, etc. It's here that a handler to decrypt a message against the list's public key would likely be done. I wouldn't re-encrypt the message in a handler though, even though that does open a larger window of opportunity when the decrypted message is flowing through the system (the window can't be totally avoided I think). Finally, once a message is ready to be delivered, it's sent to the outgoing queue (via a handler of course), where a delivery module is called to do the actually conversation with the MTA. I've got bulk and verp delivery classes defined, and I think this is where you'd encrypt the message to the recipient's key. I think this functionality could be added by subclassing the VERPDelivery or perhaps IndividualDelivery class, but some refactoring might be necessary to tie up the loose ends. The IndividualDelivery class implements callbacks for each recipient so I think that's where you could encrypt the message in a subclass. >As far as customizing the pipeline goes, it would be cool if there >were a GUI which allowed moving/inserting/deleting Handlers (a la >Emacs's "list" widget in Customize). That would be very cool. I see it more as part of a style editor for mailing lists, where you could define basic styles such as 'discussion' or 'announce' lists, name the styles, and then apply any named style to a mailing list. Most of the infrastructure is there to support this, but it's not well exposed in the REST API yet, and of course designing a sensible web u/i would be the tricky part. Hope that helps! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From benedict.stein at googlemail.com Tue May 24 13:39:46 2011 From: benedict.stein at googlemail.com (Benedict Stein) Date: Tue, 24 May 2011 13:39:46 +0200 Subject: [Mailman-Developers] Proposal for a new menu grouping in MM3 webUI Message-ID: <1306237186.2736.72.camel@vaio-fe31m> As introduced by terry yesterday I'm the one who will support the development of the WebUI which should be published together with MM3 - or even better as a standalone Django Application using the REST-Api. Those who already saw my Blogpost know what I'm talking about now - the new menu grouping. I've created a mindmap showing a possible regrouping of menu items. Florian asked me only to use these which are already available in the REST API. Just in case you didn't read my Blog yet - I've attached the image. Feel free to give any feedback you like, but I'm especially interested in the following things: 1. Digest ? volume : Do you really need this internal value to be displayed in the WebUI ? 2. What do you think about regrouping all List related mail adresses from General Options to a special "Mail " section 3. Same like 2. but formatting options 4. Sorting out all kind of notifications 5. showing stats within the archives view instead of the config Thanks for you help improving this work. benste -------------- next part -------------- A non-text attachment was scrubbed... Name: mm3_menu_idea.png Type: image/png Size: 283724 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From barry at list.org Tue May 24 14:23:48 2011 From: barry at list.org (Barry Warsaw) Date: Tue, 24 May 2011 08:23:48 -0400 Subject: [Mailman-Developers] Proposal for a new menu grouping in MM3 webUI In-Reply-To: <1306237186.2736.72.camel@vaio-fe31m> References: <1306237186.2736.72.camel@vaio-fe31m> Message-ID: <20110524082348.5a58594e@neurotica.wooz.org> On May 24, 2011, at 01:39 PM, Benedict Stein wrote: >1. Digest ? volume : > Do you really need this internal value to be displayed in the >WebUI ? I think this would only be useful information wherever you had a control to explicitly start a new volume. What might actually be interesting is to show the current volume number and the accumulated size of the current volume, along with a button to explicitly send out the current volume and increment the volume number. (It might also be interesting to show some historical data about the digests, e.g. when they went out and how big they were. This isn't currently being collected though.) >2. What do you think about regrouping all List related mail adresses >from General Options to a special "Mail " section Since those are read-only, it might be useful to have an "information" page for the list, detailing useful things like this that can't be changed. >3. Same like 2. but formatting options Same, perhaps? >4. Sorting out all kind of notifications Can you go into more detail? >5. showing stats within the archives view instead of the config Yep. We need to do a much better job of collecting and exposing stats. >Thanks for you help improving this work. Thank *you*! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From benedict.stein at googlemail.com Tue May 24 18:27:41 2011 From: benedict.stein at googlemail.com (Benedict Stein) Date: Tue, 24 May 2011 18:27:41 +0200 Subject: [Mailman-Developers] new updated proposed menu structure WebUI Message-ID: <1306254461.13788.16.camel@vaio-fe31m> HI, thanks for the feedback I got up to now - here version 2 of the "new" menu -- Kindest Regards Benedict Stein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From pidgeot18 at gmail.com Tue May 24 23:41:26 2011 From: pidgeot18 at gmail.com (Joshua Cranmer) Date: Tue, 24 May 2011 14:41:26 -0700 Subject: [Mailman-Developers] NNTP gateway proposal Message-ID: <4DDC2606.4080602@gmail.com> So, one of my most annoying problems with mailman is the operation of its mail-news gateway. Due to the rewriting of message-IDs, most ways of sending messages causes threading to horribly break. My proposal is this: optimize for the common case and avoid rewriting message IDs if not necessary. In other words, if the given message ID does not already exist on the server, do not rewrite the message ID. To handle most common cases of cross-posting to multiple mailing lists, find all mailing lists in the to/cc headers and use those to find all of the newsgroups. Additionally, if it turns out that the message ID needs to be rewritten, the old message ID would be additionally saved to the references header. While it won't fix the threading totally, it should preserve some sense of the structure. The biggest potential pitfall I see is if multiple mail servers inject the message into Usenet via different NNTP servers, so that some of Usenet sees it one group and some see it in some other group. What are your thoughts on this? From CNulk at scu.edu Wed May 25 00:11:48 2011 From: CNulk at scu.edu (C Nulk) Date: Tue, 24 May 2011 15:11:48 -0700 Subject: [Mailman-Developers] Proposal for a new menu grouping in MM3 webUI In-Reply-To: <20110524082348.5a58594e@neurotica.wooz.org> References: <1306237186.2736.72.camel@vaio-fe31m> <20110524082348.5a58594e@neurotica.wooz.org> Message-ID: <4DDC2D24.7080106@scu.edu> On 5/24/2011 5:23 AM, Barry Warsaw wrote: > On May 24, 2011, at 01:39 PM, Benedict Stein wrote: > >> 5. showing stats within the archives view instead of the config > Yep. We need to do a much better job of collecting and exposing stats. I don't know if this is the place to mention it but along with increased accessibility to statistics and archives, the ability to look at or review the logging information is also very important. Anywhere in the code that output's to a log file should provide enough information to follow a message coming into Mailman, through the various Mailman processes, and out of Mailman. I went through Mailman v2.1.9 to add additional logging information so I can track a message. My users call on a regular basis to check if their message "went out" to a list they can post to but not read (it gets complicated). Once I had the logging information (message-id, listname, sender, etc.), I wrote a web app that parses the vette, smtp, and post logs and combines the information so I can see what happened to the message either by list or by sender. It works well for me but additional logging information for tracking messages and problems is also need. I know I drifted a bit but additional logging is needed and an administrative interface to view the information is also needed. >> Thanks for you help improving this work. > Thank *you*! > > -Barry > Thank you for the work also. I did view your latest diagram and the volume/digest issue seems to be correct. But just to make sure, the volume number is increased for every SCHEDULED digest sent out (with the digest number reset to 1). Next, any addition digests sent out BETWEEN scheduled digests (whether due to size of digest or number of messages in the digest) increase the digest number but not the volume number. If that is true, then I am in agreement with you :) because it mimics the magazine style of volume/issue. Thanks for yours and Barry's hard work, Chris From p at state-of-mind.de Wed May 25 00:28:29 2011 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Wed, 25 May 2011 00:28:29 +0200 Subject: [Mailman-Developers] Proposal for a new menu grouping in MM3 webUI In-Reply-To: <1306237186.2736.72.camel@vaio-fe31m> References: <1306237186.2736.72.camel@vaio-fe31m> Message-ID: <20110524222829.GB16406@state-of-mind.de> Benedict, * Benedict Stein : > As introduced by terry yesterday I'm the one who will support the > development of the WebUI which should be published together with MM3 - > or even better as a standalone Django Application using the REST-Api. > > Those who already saw my Blogpost know what I'm talking about now - the > new menu grouping. > I've created a mindmap showing a possible regrouping of menu items. > Florian asked me only to use these which are already available in the > REST API. > > Just in case you didn't read my Blog yet - I've attached the image. > > Feel free to give any feedback you like, The current (MM2) structure is far too complex. I work with it often and I still get lost or spend too much time searching for an option that must have been, wait, well where did it ... In 2009 I ended up buying tickets for Pycon 2009, visiting Barry to work on the MM3 WUI. Here's what I came up with (and what I personally still would do): The navigation structure should work for the following user groups: - subscriber - moderator - admin Each group (in descending order) requires an interface that offers/exposes more options. Put the other way around: The interface should hide all options not required for a group. A user can see the same interface different any time she logs in, IF she acts out different roles (subscriber, moderator, admin). I think we need to develop a structure that works for all groups and remains consistent. No matter which role you own, menu items should always be located at the same place. I think this can be done best if menu items were rearranged following a role/task driven approach. Here's a model I've come up with at Pycon 2009: The model forsees plugins, something Barry and I discussed to open MM3 to development by third parties. A subscriber could see these items: dashboard options general topics plugins subscriptions subscribe remove modify statistics List A moderator would see more items, building upon the already established "subscriber" structure: dashboard requests statistics System List User plugins plugin 1 configuration options plugin 2 Finally, an admin would be exposed to all options available through the WUI: dashboard maintenance requests options General Subscription Rules Language Non-Digest/Digest Filter Sender Recipient Spam Message Topics Bounces Archive Gateways Auto-Responder Plugins subscriptions subscribe remove statistics System List User plugins plugin 1 configuration options plugin 2 I've laid all this and descriptions of the various items down in . p at rick -- state of mind () 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: Digital signature URL: From mark at msapiro.net Wed May 25 00:50:52 2011 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 24 May 2011 15:50:52 -0700 Subject: [Mailman-Developers] Proposal for a new menu grouping in MM3webUI In-Reply-To: <4DDC2D24.7080106@scu.edu> Message-ID: C Nulk wrote: >Thank you for the work also. I did view your latest diagram and the >volume/digest issue seems to be correct. But just to make sure, the >volume number is increased for every SCHEDULED digest sent out (with the >digest number reset to 1). Next, any addition digests sent out BETWEEN >scheduled digests (whether due to size of digest or number of messages >in the digest) increase the digest number but not the volume number. If >that is true, then I am in agreement with you :) because it mimics the >magazine style of volume/issue. This is not the way it works in MM 2.1. In MM 2.1, the volume increments and the issue resets to one for the first digest produced in a new period, where period is Year, Quarter, Month, Week or Day as set in Digest options -> digest_volume_frequency. The issue increments for each digest produced in that period whether the digest is produced 'periodically' or by size. If there are no posts/digests produced during a period, the volume doesn't increment for that period. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From CNulk at scu.edu Wed May 25 16:25:04 2011 From: CNulk at scu.edu (C Nulk) Date: Wed, 25 May 2011 07:25:04 -0700 Subject: [Mailman-Developers] Proposal for a new menu grouping in MM3webUI In-Reply-To: References: Message-ID: <4DDD1140.4010901@scu.edu> Yeah, I took a look at what I wrote and I wasn't as clear as I thought I was. By SCHEDULED digest, I mean a digest sent out on a set time period or frequency (like Years, Months, Weeks, etc.). Those digests would have the volume number incremented and the digest number reset to 1. Any digests sent within (or BETWEEN) the scheduled digests time period / freq. for whatever reason - size, number of msgs - would increment the digest number only. If there are no digests/msgs to send, then the volume number does not increment. Thanks Mark, Chris On 5/24/2011 3:50 PM, Mark Sapiro wrote: > C Nulk wrote: > >> Thank you for the work also. I did view your latest diagram and the >> volume/digest issue seems to be correct. But just to make sure, the >> volume number is increased for every SCHEDULED digest sent out (with the >> digest number reset to 1). Next, any addition digests sent out BETWEEN >> scheduled digests (whether due to size of digest or number of messages >> in the digest) increase the digest number but not the volume number. If >> that is true, then I am in agreement with you :) because it mimics the >> magazine style of volume/issue. > > This is not the way it works in MM 2.1. In MM 2.1, the volume > increments and the issue resets to one for the first digest produced > in a new period, where period is Year, Quarter, Month, Week or Day as > set in Digest options -> digest_volume_frequency. The issue increments > for each digest produced in that period whether the digest is produced > 'periodically' or by size. If there are no posts/digests produced > during a period, the volume doesn't increment for that period. > > -- > Mark Sapiro The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > From mark at msapiro.net Wed May 25 18:32:53 2011 From: mark at msapiro.net (Mark Sapiro) Date: Wed, 25 May 2011 09:32:53 -0700 Subject: [Mailman-Developers] Proposal for a new menu grouping in MM3webUI In-Reply-To: <4DDD1140.4010901@scu.edu> References: <4DDD1140.4010901@scu.edu> Message-ID: <4DDD2F35.1070804@msapiro.net> On 5/25/11 7:25 AM, C Nulk wrote: > Yeah, I took a look at what I wrote and I wasn't as clear as I thought I > was. By SCHEDULED digest, I mean a digest sent out on a set time period > or frequency (like Years, Months, Weeks, etc.). Those digests would > have the volume number incremented and the digest number reset to 1. > Any digests sent within (or BETWEEN) the scheduled digests time period / > freq. for whatever reason - size, number of msgs - would increment the > digest number only. If there are no digests/msgs to send, then the > volume number does not increment. That is essentially what I thought you meant, and as I said, that's not how it works in Mailman 2.1 (See below) digest_volume_frequency and digest_send_periodic are separate, independent settings. digest_volume_frequency controls only when the volume number changes. digest_send_periodic controls whether or not a digest is sent when cron/senddigests runs (default, daily at noon). In any case, a digest is always sent when the size of the list's accumulated digest.mbox reaches digest_size_threshhold. I.e. there are no 'scheduled' digests other than the ones sent daily by cron/senddigests and those have no relation to the volume number. Even if digest_volume_frequency is Daily, and digest_send_periodic is Yes, and digests are sent at noon, a digest triggered on size at 09:00 will be issue number one of that day's volume if it's the first digest of the day. > On 5/24/2011 3:50 PM, Mark Sapiro wrote: >> >> This is not the way it works in MM 2.1. In MM 2.1, the volume >> increments and the issue resets to one for the first digest produced >> in a new period, where period is Year, Quarter, Month, Week or Day as >> set in Digest options -> digest_volume_frequency. The issue increments >> for each digest produced in that period whether the digest is produced >> 'periodically' or by size. If there are no posts/digests produced >> during a period, the volume doesn't increment for that period. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California Better use your sense - B. Dylan From benedict.stein at googlemail.com Wed May 25 19:08:33 2011 From: benedict.stein at googlemail.com (Benedict Stein) Date: Wed, 25 May 2011 19:08:33 +0200 Subject: [Mailman-Developers] New Menu - Role Based Proposal Message-ID: <1306343313.15037.9.camel@vaio-fe31m> Hi there, I've picked up Patricks idea today and expanded the existing draft with a few other things, you can find both on http://wiki.list.org/display/DEV/New+Menu it would be brilliant if you'd compare both and see what you'd like and if there is still anything to improve. Only one little explanation: the colors in the mindmap show the ACL (at least in the role based one) - description in the upper left corner. Each item connected to the middle could be traded as a tab-like navigation e.g. http://wiki.list.org/display/DEV/benste%27s+GSoc+2011+-+page please bare in mind that these mockups don't represent any style ! - (only wackys idea of a combobox changeing the lists - thanks) the rest of the items are either heading or items, atm. I've noted only the fields which are present in the REST API, e.g. i didn't go into detail creating a new list as some values are readonly atm. -- Einen sch?nen Tag w?nscht: Benedict Stein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From benedict.stein at googlemail.com Fri May 27 17:46:18 2011 From: benedict.stein at googlemail.com (Benedict Stein) Date: Fri, 27 May 2011 17:46:18 +0200 Subject: [Mailman-Developers] ACL in Mailman - what's you opinion Message-ID: Dear List-subscribers, wacky and i discussed a few things about how to implement ACL within the Mailman3 parts. I've wrote a small Blogpost about it in http://benste.blogspot.com/2011/05/mailman-3-restapi-webui-acl.html just in case you want to contribute to Pro/Con list directly go to http://wiki.list.org/display/DEV/Pro+-+Con+ACL+in+different+Layers+%28WebUI%29 From dkg at fifthhorseman.net Fri May 27 19:49:13 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 27 May 2011 13:49:13 -0400 Subject: [Mailman-Developers] mailman breaking PGP/MIME-signed messages (was: Re: My First Signed email) In-Reply-To: <4DD00948.3030002@sixdemonbag.org> References: <4DCFD845.10708@garenick.com> <4DCFDAE9.2050908@enigmail.net> <4DCFE4FE.2020401@garenick.com> <4DCFF589.2050001@sixdemonbag.org> <4DCFF68D.8030902@sixdemonbag.org> <4DD00680.9010909@fifthhorseman.net> <4DD00948.3030002@sixdemonbag.org> Message-ID: <87tycg9gpy.fsf@fifthhorseman.net> On Sun, 15 May 2011 13:11:36 -0400, "Robert J. Hansen" wrote: > http://sixdemonbag.org/pgpmime.zip > > Contains the good message (taken from my outbox), the bad message (as > received from the list), and a diff between the two (as computed by > Cygwin's diff). Knock yourself out. This is clearly a problem with mailman; mailman is not treating the content within the multipart/signed message as an immmutable text. In particular, it's re-formatting multi-line headers within the signed part. This is apparently known upstream, reported many moons ago, when mailman used sourceforge as a bugtracker: http://sourceforge.net/tracker/?func=detail&aid=815297&group_id=103&atid=100103 And it appears to now be tracked upstream here: https://bugs.launchpad.net/mailman/+bug/558123 Below you can see the change: the additional wrapping block (with the mailing list footer) is totally fine. the error is in swapping the leading space for a tab before the boundary attribute for the Content-Type of the signed part. ------------------------------------------------------------ 0 dkg at pip:/tmp/cdtemp.4pvdgA$ wget -q http://sixdemonbag.org/pgpmime.zip 0 dkg at pip:/tmp/cdtemp.4pvdgA$ unzip -q -a pgpmime.zip 0 dkg at pip:/tmp/cdtemp.4pvdgA$ strip_headers() { > awk '{ if (X) {print $0} } /^$/{ X=1 }' > } 0 dkg at pip:/tmp/cdtemp.4pvdgA$ diff -u <(strip_headers < good_pgpmime.eml) <(strip_headers < bad_pgpmime.eml) --- /dev/fd/63 2011-05-27 13:01:37.705397276 -0400 +++ /dev/fd/62 2011-05-27 13:01:37.705397276 -0400 @@ -1,7 +1,13 @@ This is an OpenPGP/MIME signed message (RFC 2440 and 3156) +--===============1388267379== +Content-Type: multipart/signed; micalg=pgp-sha256; + protocol="application/pgp-signature"; + boundary="------------enigA22A6723C9B8F9F9E4CFB403" + +This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA22A6723C9B8F9F9E4CFB403 Content-Type: multipart/alternative; - boundary="------------020209060504060800050601" + boundary="------------020209060504060800050601" This is a multi-part message in MIME format. --------------020209060504060800050601 @@ -89,3 +95,16 @@ -----END PGP SIGNATURE----- --------------enigA22A6723C9B8F9F9E4CFB403-- + +--===============1388267379== +Content-Type: text/plain; charset="us-ascii" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Content-Disposition: inline + +_______________________________________________ +Enigmail mailing list +Enigmail at mozdev.org +https://www.mozdev.org/mailman/listinfo/enigmail + +--===============1388267379==-- 1 dkg at pip:/tmp/cdtemp.4pvdgA$ grep -i mailman-version *.eml bad_pgpmime.eml:X-Mailman-Version: 2.1.12 0 dkg at pip:/tmp/cdtemp.4pvdgA$ ------------------------------------------------------------ The right thing to do is to fix mailman to not tamper with the message body. Perhaps it has already been fixed since 2.1.12? Please follow up via mailman-developers@ (you may need to subscribe first) if you have patches to offer. If you don't want to subscribe, i'd be happy to forward patches to the list if they seem plausible. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 965 bytes Desc: not available URL: From mark at msapiro.net Fri May 27 20:39:51 2011 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 27 May 2011 11:39:51 -0700 Subject: [Mailman-Developers] mailman breaking PGP/MIME-signed messages (was: Re: My First Signed email) In-Reply-To: <87tycg9gpy.fsf@fifthhorseman.net> References: <4DCFD845.10708@garenick.com> <4DCFDAE9.2050908@enigmail.net> <4DCFE4FE.2020401@garenick.com> <4DCFF589.2050001@sixdemonbag.org> <4DCFF68D.8030902@sixdemonbag.org> <4DD00680.9010909@fifthhorseman.net> <4DD00948.3030002@sixdemonbag.org> <87tycg9gpy.fsf@fifthhorseman.net> Message-ID: <4DDFEFF7.9060504@msapiro.net> On 5/27/2011 10:49 AM, Daniel Kahn Gillmor wrote: > > This is clearly a problem with mailman; mailman is not treating the > content within the multipart/signed message as an immmutable text. In > particular, it's re-formatting multi-line headers within the signed > part. > > This is apparently known upstream, reported many moons ago, when mailman > used sourceforge as a bugtracker: > > http://sourceforge.net/tracker/?func=detail&aid=815297&group_id=103&atid=100103 > > And it appears to now be tracked upstream here: > > https://bugs.launchpad.net/mailman/+bug/558123 Bug 558123 (sf933757) is a duplicate of Bug 265967 (sf815297) and is now marked as such. The Debian patch in Bug 558123 was refactored and released in Mailman 2.1.13. See for the base bug report and for the fix. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at list.org Fri May 27 22:18:19 2011 From: barry at list.org (Barry Warsaw) Date: Fri, 27 May 2011 16:18:19 -0400 Subject: [Mailman-Developers] ACL in Mailman - what's you opinion In-Reply-To: References: Message-ID: <20110527161819.63d00ff2@neurotica.wooz.org> Hi benste, On May 27, 2011, at 05:46 PM, Benedict Stein wrote: >wacky and i discussed a few things about how to implement ACL within the >Mailman3 parts. >I've wrote a small Blogpost about it in >http://benste.blogspot.com/2011/05/mailman-3-restapi-webui-acl.html > >just in case you want to contribute to Pro/Con list directly go to >http://wiki.list.org/display/DEV/Pro+-+Con+ACL+in+different+Layers+%28WebUI%29 There's another way of implementing ACLs, which would be useful to explore, and which is what I've had in the back of my mind for a while now. First a quick review. As you mention, I've long advocated that the core's REST API be a full-permission, admin-only API. The requirement here of course is that it can really only be published over completely trusted channels, and we've said for several years now that this means only on localhost. As you point out this has several advantages: * It keeps the REST API simple * It keeps the data model simple * Clients have unlimited functional flexibility * Not locked into the core's perception of permissions and security As you rightly point out, the downside is that the core is essentially punting, and requiring all of its clients to implement security, access, and permissions. In my mind, I've always thought that you could implement some middleware to handle this, in a way that would better serve clients. For example, if I had some middleware that also exposed a REST API, but required authentication for each request, it could do the permission check, filter the request as appropriate, and forward it to the core. Of course, responses could also be filtered if necessary, but this would present exactly the API that clients required. This is appealing because it allows for pluggability and customization for various environments, without imposing extra complexity on the core. Here's another use case to illustrate. Let's say I wanted to replace Launchpad's mailing lists with Mailman 3. Now, Launchpad has a very rich user and permission model, involving accounts, people, teams, OAuth, SSO, SSL, etc. I think it would be quite difficult to integrate Launchpad's notion of permissions into the core's model, or even to design the core's model so that you could plug things in at every level. It's much more approachable to me to just hook up the user and team model to be able to do the much easier task of determining list membership for posting purposes. Launchpad's own security infrastructure would limit who can do what to the Mailman core, of course through its own web ui and API. Launchpad itself would essentially be the middleware filtering requests to the core through its permission model. Launchpad's security model would be very different from Mailman's Django web ui's model. It seems insurmountable to me that the core is the piece that resolves, integrates, and allows these divergent models. I know it's a cop-out to keep punting on security in the core, but I actually think it's a *useful* cop-out. For the great number of sites I see as integrating Mailman 3 with their own web ui, they already probably have pretty complex systems with their own permission models, and I'm leery of adding the necessary complexity to the core for Mailman to be a client of those security models. For the great number of sites that will just use Mailman's Django web ui out of the box, we can use Django's features to implement security, with perhaps some well-placed queries into the core's API or database to determine membership relationships. The core's job is to deliver email. It's existing "permission model" is just enough to decide whether and when to do that. As always, I'm interesting in hearing other people's opinions on this, and will of course keep an open mind. I'm also not against adding some minimum of required functionality to enable this security middleware I'm thinking about. But I also think it makes a lot of sense to keep the core as simple as possible (but no simpler :). Thanks for kicking off this discussion! 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 May 27 22:57:42 2011 From: barry at list.org (Barry Warsaw) Date: Fri, 27 May 2011 16:57:42 -0400 Subject: [Mailman-Developers] sievelib and Modoboa Message-ID: <20110527165742.196458df@neurotica.wooz.org> Hi folks, I wanted to point you at two very cool looking tools that Antoine Nguyen has developed, and introduced to me by Patrick Ben Koetter. I haven't had time to look into these in detail, but if you're looking for some fun hacking ideas for Mailman 3, these could fit the bill. The first is sievelib: http://pypi.python.org/pypi/sievelib/0.1 Sieve is an email filtering language specified in RFC 5228. I've always thought it might be a pretty cool way for power users to manage the email Mailman sends them. It might even form the implementational basis for a topics-on-steroids like feature in MM3. This is the first implementation of Sieve written in Python that I'm aware of. Antoine wrote sievelib as part of his Modoboa project: http://modoboa.org/en/ which looks like a pretty cool take on making the management of email systems friendlier. Of course, Antoine, Patrick and I immediately thought that it might be cool to explore some integration opportunities between Modoboa and MM3. For those of you in the USA, what better way to spend the beautiful Memorial Day weekend than sitting in front of your screen hacking on some fun projects? :) 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 May 27 23:09:18 2011 From: barry at list.org (Barry Warsaw) Date: Fri, 27 May 2011 17:09:18 -0400 Subject: [Mailman-Developers] Proposal for a new menu grouping in MM3 webUI In-Reply-To: <4DDC2D24.7080106@scu.edu> References: <1306237186.2736.72.camel@vaio-fe31m> <20110524082348.5a58594e@neurotica.wooz.org> <4DDC2D24.7080106@scu.edu> Message-ID: <20110527170918.3761c288@neurotica.wooz.org> On May 24, 2011, at 03:11 PM, C Nulk wrote: >I don't know if this is the place to mention it but along with increased >accessibility to statistics and archives, the ability to look at or >review the logging information is also very important. Anywhere in the >code that output's to a log file should provide enough information to >follow a message coming into Mailman, through the various Mailman >processes, and out of Mailman. It is, and I agree! Well, let me say that I definitely think better logging is on the table for MM3, and I've been careful to ensure that at least the Message-ID is logged for anything that pertains to the disposition of an email message. I'm not sure how or if the logging information should be available through the web ui (and thus the REST API). >I went through Mailman v2.1.9 to add additional logging information so I can >track a message. My users call on a regular basis to check if their message >"went out" to a list they can post to but not read (it gets complicated). >Once I had the logging information (message-id, listname, sender, etc.), I >wrote a web app that parses the vette, smtp, and post logs and combines the >information so I can see what happened to the message either by list or by >sender. It works well for me but additional logging information for tracking >messages and problems is also need. One other thing I've been thinking about is a kind of "debug" option where a fake message could be injected into the system, with the appropriate headers, and out would come some debugging information about which rules got hit, and exactly why a message would be held, accepted, discarded, or rejected. I haven't thought more about this other than "it would be cool to have" ;). -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 May 27 23:24:20 2011 From: barry at list.org (Barry Warsaw) Date: Fri, 27 May 2011 17:24:20 -0400 Subject: [Mailman-Developers] NNTP gateway proposal In-Reply-To: <4DDC2606.4080602@gmail.com> References: <4DDC2606.4080602@gmail.com> Message-ID: <20110527172420.16c05cb5@neurotica.wooz.org> Hi Joshua, It's been a long time since I looked at the details of the NNTP gateway, so most of my knowledge is probably pretty dated. I know this Message-ID issue is pretty annoying though. On May 24, 2011, at 02:41 PM, Joshua Cranmer wrote: >So, one of my most annoying problems with mailman is the operation of its >mail-news gateway. Due to the rewriting of message-IDs, most ways of sending >messages causes threading to horribly break. > >My proposal is this: optimize for the common case and avoid rewriting message >IDs if not necessary. In other words, if the given message ID does not >already exist on the server, do not rewrite the message ID. To handle most >common cases of cross-posting to multiple mailing lists, find all mailing >lists in the to/cc headers and use those to find all of the newsgroups. > >Additionally, if it turns out that the message ID needs to be rewritten, the >old message ID would be additionally saved to the references header. While it >won't fix the threading totally, it should preserve some sense of the >structure. > >The biggest potential pitfall I see is if multiple mail servers inject the >message into Usenet via different NNTP servers, so that some of Usenet sees >it one group and some see it in some other group. > >What are your thoughts on this? It sounds pretty reasonable to me. Perhaps you can file a bug and tag it 'mailman3' so your proposal doesn't get lost in the archives? Looking at cross-posting should be easier with Mailman 3 because we've gotten rid of the list-centric silos, or the horrible overhead of hacking around them that MM2 required. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri May 27 23:26:28 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 27 May 2011 17:26:28 -0400 Subject: [Mailman-Developers] Proposal for a new menu grouping in MM3 webUI In-Reply-To: <20110527170918.3761c288@neurotica.wooz.org> References: <1306237186.2736.72.camel@vaio-fe31m> <20110524082348.5a58594e@neurotica.wooz.org> <4DDC2D24.7080106@scu.edu> <20110527170918.3761c288@neurotica.wooz.org> Message-ID: <4DE01704.2040607@fifthhorseman.net> On 05/27/2011 05:09 PM, Barry Warsaw wrote: > One other thing I've been thinking about is a kind of "debug" option where a > fake message could be injected into the system, with the appropriate headers, > and out would come some debugging information about which rules got hit, and > exactly why a message would be held, accepted, discarded, or rejected. I > haven't thought more about this other than "it would be cool to have" ;). More than just "cool to have": it would enable people to write more tests for the test suite, which in turn makes developers more confident in undertaking aggressive re-factorings without fear of breakage. That would be a Good Thing. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From barry at list.org Fri May 27 23:32:50 2011 From: barry at list.org (Barry Warsaw) Date: Fri, 27 May 2011 17:32:50 -0400 Subject: [Mailman-Developers] Proposal for a new menu grouping in MM3 webUI In-Reply-To: <4DE01704.2040607@fifthhorseman.net> References: <1306237186.2736.72.camel@vaio-fe31m> <20110524082348.5a58594e@neurotica.wooz.org> <4DDC2D24.7080106@scu.edu> <20110527170918.3761c288@neurotica.wooz.org> <4DE01704.2040607@fifthhorseman.net> Message-ID: <20110527173250.428f86d5@neurotica.wooz.org> On May 27, 2011, at 05:26 PM, Daniel Kahn Gillmor wrote: >More than just "cool to have": it would enable people to write more >tests for the test suite, which in turn makes developers more confident >in undertaking aggressive re-factorings without fear of breakage. That >would be a Good Thing. Most definitely. In the meantime, take comfort at least that MM3 has a pretty extensive test suite that *actually runs and passes* :) -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From richard at NFSNet.org Fri May 27 23:35:18 2011 From: richard at NFSNet.org (Richard Wackerbarth) Date: Fri, 27 May 2011 16:35:18 -0500 Subject: [Mailman-Developers] ACL in Mailman - what's you opinion In-Reply-To: <20110527161819.63d00ff2@neurotica.wooz.org> References: <20110527161819.63d00ff2@neurotica.wooz.org> Message-ID: Barry, I do not understand why "published over completely trusted channels" "means only on localhost". When two machines are involved, you have to be able to trust both of them, but they don't have to be the same machine. In addition, you will need to open a secure channel. Even over public channels, signed, and possibly encrypted, messages should be sufficient as long as you don't expose the keys. Wacky On May 27, 2011, at 3:18 PM, Barry Warsaw wrote: > Hi benste, > > On May 27, 2011, at 05:46 PM, Benedict Stein wrote: > >> wacky and i discussed a few things about how to implement ACL within the >> Mailman3 parts. >> I've wrote a small Blogpost about it in >> http://benste.blogspot.com/2011/05/mailman-3-restapi-webui-acl.html >> >> just in case you want to contribute to Pro/Con list directly go to >> http://wiki.list.org/display/DEV/Pro+-+Con+ACL+in+different+Layers+%28WebUI%29 > > There's another way of implementing ACLs, which would be useful to explore, > and which is what I've had in the back of my mind for a while now. > > First a quick review. As you mention, I've long advocated that the core's > REST API be a full-permission, admin-only API. The requirement here of course > is that it can really only be published over completely trusted channels, and > we've said for several years now that this means only on localhost. As you > point out this has several advantages: > > * It keeps the REST API simple > * It keeps the data model simple > * Clients have unlimited functional flexibility > * Not locked into the core's perception of permissions and security > > As you rightly point out, the downside is that the core is essentially > punting, and requiring all of its clients to implement security, access, and > permissions. > > In my mind, I've always thought that you could implement some middleware to > handle this, in a way that would better serve clients. For example, if I had > some middleware that also exposed a REST API, but required authentication for > each request, it could do the permission check, filter the request as > appropriate, and forward it to the core. Of course, responses could also be > filtered if necessary, but this would present exactly the API that clients > required. > > This is appealing because it allows for pluggability and customization for > various environments, without imposing extra complexity on the core. Here's > another use case to illustrate. > > Let's say I wanted to replace Launchpad's mailing lists with Mailman 3. Now, > Launchpad has a very rich user and permission model, involving accounts, > people, teams, OAuth, SSO, SSL, etc. I think it would be quite difficult to > integrate Launchpad's notion of permissions into the core's model, or even to > design the core's model so that you could plug things in at every level. It's > much more approachable to me to just hook up the user and team model to be > able to do the much easier task of determining list membership for posting > purposes. Launchpad's own security infrastructure would limit who can do what > to the Mailman core, of course through its own web ui and API. Launchpad > itself would essentially be the middleware filtering requests to the core > through its permission model. > > Launchpad's security model would be very different from Mailman's Django web > ui's model. It seems insurmountable to me that the core is the piece that > resolves, integrates, and allows these divergent models. > > I know it's a cop-out to keep punting on security in the core, but I actually > think it's a *useful* cop-out. For the great number of sites I see as > integrating Mailman 3 with their own web ui, they already probably have pretty > complex systems with their own permission models, and I'm leery of adding the > necessary complexity to the core for Mailman to be a client of those security > models. For the great number of sites that will just use Mailman's Django web > ui out of the box, we can use Django's features to implement security, with > perhaps some well-placed queries into the core's API or database to determine > membership relationships. > > The core's job is to deliver email. It's existing "permission model" is just > enough to decide whether and when to do that. > > As always, I'm interesting in hearing other people's opinions on this, and > will of course keep an open mind. I'm also not against adding some minimum of > required functionality to enable this security middleware I'm thinking about. > But I also think it makes a lot of sense to keep the core as simple as > possible (but no simpler :). > > Thanks for kicking off this discussion! > > Cheers, > -Barry > _______________________________________________ > 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/richard%40nfsnet.org > > Security Policy: http://wiki.list.org/x/QIA9 From odhiambo at gmail.com Sat May 28 13:35:39 2011 From: odhiambo at gmail.com (Odhiambo Washington) Date: Sat, 28 May 2011 14:35:39 +0300 Subject: [Mailman-Developers] FreeBSD 8.2, Python2.7, Exim-4 and MM3 Message-ID: Hello everyone, This is my first post to this list so please bear with me. I am not a developer and as such I request you again to bear with me. My only endeavor is be able to get MM3 running on FreeBSD with Python2.7 and Exim 4 as the MTA. So far I have hit a deadlock, hence my coming to you. I have Python2.7 and py-sqlite3 installed from the ports. These are the latest versions on the FreeBSD ports tree. I have downloaded and installed MM-3.0 (mailman-3.0.0a7) and closely followed the instructions. So far, I've gotten stuck on one of the tests - `bin/mailman info`. Let me start with the output of bin/test -vv (I've truncated it to just the top and the bottom bits): bin/test -vv Running tests at level 1 Running mailman.testing.layers.ConfigLayer tests: Set up mailman.testing.layers.MockAndMonkeyLayer in 0.000 seconds. Set up mailman.testing.layers.ConfigLayer Traceback (most recent call last): File "/usr/local/mailman-3.0.0a7/eggs/zope.testrunner-4.0.3-py2.7.egg/zope/testrunner/runner.py", line 380, in run_layer setup_layer(options, layer, setup_layers) File "/usr/local/mailman-3.0.0a7/eggs/zope.testrunner-4.0.3-py2.7.egg/zope/testrunner/runner.py", line 672, in setup_layer layer.setUp() File "/usr/local/mailman-3.0.0a7/src/mailman/testing/layers.py", line 120, in setUp initialize.initialize_2() File "/usr/local/mailman-3.0.0a7/src/mailman/core/initialize.py", line 145, in initialize_2 database.initialize(debug) File "/usr/local/mailman-3.0.0a7/src/mailman/database/stock.py", line 61, in initialize self._create(debug) File "/usr/local/mailman-3.0.0a7/src/mailman/database/stock.py", line 96, in _create database = create_database(url) File "/usr/local/mailman-3.0.0a7/eggs/storm-0.18-py2.7-freebsd-8.2-STABLE-i386.egg/storm/database.py", line 460, in create_database return factory(uri) File "/usr/local/mailman-3.0.0a7/eggs/storm-0.18-py2.7-freebsd-8.2-STABLE-i386.egg/storm/databases/sqlite.py", line 177, in __init__ raise DatabaseModuleError("'pysqlite2' module not found") DatabaseModuleError: 'pysqlite2' module not found Running mailman.testing.layers.SMTPLayer tests: Set up mailman.testing.layers.ConfigLayer Traceback (most recent call last): File "/usr/local/mailman-3.0.0a7/eggs/zope.testrunner-4.0.3-py2.7.egg/zope/testrunner/runner.py", line 380, in run_layer setup_layer(options, layer, setup_layers) File "/usr/local/mailman-3.0.0a7/eggs/zope.testrunner-4.0.3-py2.7.egg/zope/testrunner/runner.py", line 667, in setup_layer setup_layer(options, base, setup_layers) File "/usr/local/mailman-3.0.0a7/eggs/zope.testrunner-4.0.3-py2.7.egg/zope/testrunner/runner.py", line 672, in setup_layer layer.setUp() File "/usr/local/mailman-3.0.0a7/src/mailman/testing/layers.py", line 91, in setUp initialize.initialize_1(INHIBIT_CONFIG_FILE) File "/usr/local/mailman-3.0.0a7/src/mailman/core/initialize.py", line 116, in initialize_1 mailman.config.config.load(config_path) File "/usr/local/mailman-3.0.0a7/src/mailman/config/config.py", line 105, in load self._post_process() File "/usr/local/mailman-3.0.0a7/src/mailman/config/config.py", line 125, in _post_process Switchboard.initialize() File "/usr/local/mailman-3.0.0a7/src/mailman/queue/__init__.py", line 87, in initialize 'Duplicate qrunner name: {0}'.format(name)) AssertionError: Duplicate qrunner name: retry Running mailman.testing.layers.RESTLayer tests: Set up mailman.testing.layers.ConfigLayer Traceback (most recent call last): File "/usr/local/mailman-3.0.0a7/eggs/zope.testrunner-4.0.3-py2.7.egg/zope/testrunner/runner.py", line 380, in run_layer setup_layer(options, layer, setup_layers) File "/usr/local/mailman-3.0.0a7/eggs/zope.testrunner-4.0.3-py2.7.egg/zope/testrunner/runner.py", line 667, in setup_layer setup_layer(options, base, setup_layers) File "/usr/local/mailman-3.0.0a7/eggs/zope.testrunner-4.0.3-py2.7.egg/zope/testrunner/runner.py", line 667, in setup_layer setup_layer(options, base, setup_layers) File "/usr/local/mailman-3.0.0a7/eggs/zope.testrunner-4.0.3-py2.7.egg/zope/testrunner/runner.py", line 672, in setup_layer layer.setUp() File "/usr/local/mailman-3.0.0a7/src/mailman/testing/layers.py", line 91, in setUp initialize.initialize_1(INHIBIT_CONFIG_FILE) File "/usr/local/mailman-3.0.0a7/src/mailman/core/initialize.py", line 116, in initialize_1 mailman.config.config.load(config_path) File "/usr/local/mailman-3.0.0a7/src/mailman/config/config.py", line 105, in load self._post_process() File "/usr/local/mailman-3.0.0a7/src/mailman/config/config.py", line 125, in _post_process Switchboard.initialize() File "/usr/local/mailman-3.0.0a7/src/mailman/queue/__init__.py", line 87, in initialize 'Duplicate qrunner name: {0}'.format(name)) AssertionError: Duplicate qrunner name: retry Ran 134 tests with 0 failures and 0 errors in 0.728 seconds. Tearing down left over layers: Tear down zope.testrunner.layer.UnitTests in 0.000 seconds. Tests with errors: Layer: mailman.testing.layers.ConfigLayer Layer: mailman.testing.layers.SMTPLayer Layer: mailman.testing.layers.RESTLayer Total: 134 tests, 0 failures, 3 errors in 1.142 seconds. So I can see the failures but have no clue of how to fix them. Now, when I invoke `bin/mailman info`, this is what I get: mail# bin/mailman info Traceback (most recent call last): File "bin/mailman", line 20, in mailman.bin.mailman.main() File "/usr/local/mailman-3.0.0a7/src/mailman/bin/mailman.py", line 98, in main initialize(config_file) File "/usr/local/mailman-3.0.0a7/src/mailman/core/initialize.py", line 174, in initialize initialize_2(propagate_logs=propagate_logs) File "/usr/local/mailman-3.0.0a7/src/mailman/core/initialize.py", line 145, in initialize_2 database.initialize(debug) File "/usr/local/mailman-3.0.0a7/src/mailman/database/stock.py", line 61, in initialize self._create(debug) File "/usr/local/mailman-3.0.0a7/src/mailman/database/stock.py", line 96, in _create database = create_database(url) File "/usr/local/mailman-3.0.0a7/eggs/storm-0.18-py2.7-freebsd-8.2-STABLE-i386.egg/storm/database.py", line 460, in create_database return factory(uri) File "/usr/local/mailman-3.0.0a7/eggs/storm-0.18-py2.7-freebsd-8.2-STABLE-i386.egg/storm/databases/sqlite.py", line 177, in __init__ raise DatabaseModuleError("'pysqlite2' module not found") storm.exceptions.DatabaseModuleError: 'pysqlite2' module not found There is no py-sqlite2 port on FreeBSD 8.2 at the moment. Is there something I can do to get past this deadlock? The second part of my problem is how to integrate MM3 with Exim4. I am informed that things have greatly changed from the way Exim4 was configured with MM2 (2.1.x). I am hoping that there are Exim gurus here, who have already worked on a configuration for MM3+Exim and have documented the bits required for both exim.conf and mailman.cf. Thanks. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ I can't hear you -- I'm using the scrambler. Please consider the environment before printing this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 652 bytes Desc: not available URL: From adam-mailman at amyl.org.uk Sat May 28 18:37:22 2011 From: adam-mailman at amyl.org.uk (Adam McGreggor) Date: Sat, 28 May 2011 17:37:22 +0100 Subject: [Mailman-Developers] FreeBSD 8.2, Python2.7, Exim-4 and MM3 In-Reply-To: References: Message-ID: <20110528163722.GB2223@hendricks.amyl.org.uk> On Sat, May 28, 2011 at 02:35:39PM +0300, Odhiambo Washington wrote: > The second part of my problem is how to integrate MM3 with Exim4. I am > informed that things have greatly changed from the way Exim4 was configured > with MM2 (2.1.x). I am hoping that there are Exim gurus here, who have > already worked on a configuration for MM3+Exim and have documented the bits > required for both exim.conf and mailman.cf. ISTR there was a post within the last month or so to exim-users WRT MM3. -- "Saying that road tax should be spent on transport is like saying that alcohol duty should be spent on pubs." From odhiambo at gmail.com Sun May 29 10:19:11 2011 From: odhiambo at gmail.com (Odhiambo Washington) Date: Sun, 29 May 2011 11:19:11 +0300 Subject: [Mailman-Developers] FreeBSD 8.2, Python2.7, Exim-4 and MM3 In-Reply-To: <20110528163722.GB2223@hendricks.amyl.org.uk> References: <20110528163722.GB2223@hendricks.amyl.org.uk> Message-ID: On Sat, May 28, 2011 at 19:37, Adam McGreggor wrote: > On Sat, May 28, 2011 at 02:35:39PM +0300, Odhiambo Washington wrote: > > The second part of my problem is how to integrate MM3 with Exim4. I am > > informed that things have greatly changed from the way Exim4 was > configured > > with MM2 (2.1.x). I am hoping that there are Exim gurus here, who have > > already worked on a configuration for MM3+Exim and have documented the > bits > > required for both exim.conf and mailman.cf. > > ISTR there was a post within the last month or so to exim-users WRT > MM3. > > That must have been myself trying to find out if any fellows there are using it. I did not get any workable responses. Could you please point the thread? -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ I can't hear you -- I'm using the scrambler. Please consider the environment before printing this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 652 bytes Desc: not available URL: From barry at list.org Mon May 30 03:37:47 2011 From: barry at list.org (Barry Warsaw) Date: Sun, 29 May 2011 21:37:47 -0400 Subject: [Mailman-Developers] FreeBSD 8.2, Python2.7, Exim-4 and MM3 In-Reply-To: References: Message-ID: <20110529213747.5e00f306@neurotica.wooz.org> I traded a few emails with Odhiambo before I suggested sending a query here. I have a FreeBSD VM, but don't really know much about the OS. On May 28, 2011, at 02:35 PM, Odhiambo Washington wrote: >Now, when I invoke `bin/mailman info`, this is what I get: ... > raise DatabaseModuleError("'pysqlite2' module not found") >storm.exceptions.DatabaseModuleError: 'pysqlite2' module not found > >There is no py-sqlite2 port on FreeBSD 8.2 at the moment. Is there something >I can do to get past this deadlock? Here's the weird thing I noticed. After installing Python 2.7 and py-sqlite, this would succeed: $ python2.7 -c 'import sqlite3' but, after doing a buildout, this would fail: $ bin/py -c 'import sqlite3' So, the sqlite3 module was available from the standard Python, but not the built-out Python. No clue as to why though. >The second part of my problem is how to integrate MM3 with Exim4. I am >informed that things have greatly changed from the way Exim4 was configured >with MM2 (2.1.x). I am hoping that there are Exim gurus here, who have >already worked on a configuration for MM3+Exim and have documented the bits >required for both exim.conf and mailman.cf. There are two parts to this. First, the way Exim is integrated with MM2, there's no need for alias file hacking because Exim can autodetect which mailing lists are available by looking at the config.pck files. Of course, there are no config.pck files in MM3 any more, so a new strategy is needed. Second, the preferred way to get messages into MM3 is via LMTP, so ideally, there'd be some configuration to get Exim to connect to MM3's LMTP server. It would be great to have better Exim (and Sendmail, qmail, or any other MTA) support in MM3. Let us know if you're willing and able to help! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From nigel at dotdot.it Mon May 30 10:10:59 2011 From: nigel at dotdot.it (Nigel Metheringham) Date: Mon, 30 May 2011 09:10:59 +0100 Subject: [Mailman-Developers] FreeBSD 8.2, Python2.7, Exim-4 and MM3 In-Reply-To: <20110529213747.5e00f306@neurotica.wooz.org> References: <20110529213747.5e00f306@neurotica.wooz.org> Message-ID: <36380A66-1677-4A5C-9919-B27DC14679F0@dotdot.it> On 30 May 2011, at 02:37, Barry Warsaw wrote: > There are two parts to this. First, the way Exim is integrated with MM2, > there's no need for alias file hacking because Exim can autodetect which > mailing lists are available by looking at the config.pck files. Of course, > there are no config.pck files in MM3 any more, so a new strategy is needed. So to make this more generic:- - how can an external process detect configured lists? - preferably in a relatively non-active fashion - ie looking at the filesystem - if needed by running something to say if list x exists - what addresses does a list provide (ie list-request etc) - or is there a way of getting mailman to list all the addresses that mailman handles (ideally including domain) > Second, the preferred way to get messages into MM3 is via LMTP, so ideally, > there'd be some configuration to get Exim to connect to MM3's LMTP server. That should be pretty easy. > It would be great to have better Exim (and Sendmail, qmail, or any other MTA) > support in MM3. Let us know if you're willing and able to help! Can't do a great deal on this, but willing to heckle, umm, give some advice from the sidelines. The exim.org machine is moving to a more modern platform later in the year so we may be in a position to realistically look at hosting a MM3 install then. Nigel. -- [ Nigel Metheringham ------------------------------ nigel at dotdot.it ] [ Ellipsis Intangible Technologies ]