From tkikuchi at is.kochi-u.ac.jp Sun Oct 1 03:36:22 2006 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Sun, 01 Oct 2006 10:36:22 +0900 Subject: [Mailman-Developers] pipe-to-prog/maidir/lmtp performance In-Reply-To: <4EB35FCA-CDE2-4D0F-9BD1-8879D5D2E59F@python.org> References: <4519E35A.6070906@is.kochi-u.ac.jp> <4519E971.8070202@nleaudio.com> <451A033B.7090505@Newfield.org> <9B0599C0-D151-4943-B55E-A8A7F90DE660@python.org> <1EC9A0DAC4500B094D771196@[192.168.1.160]> <91A97AAD-C7BC-48B6-B1BE-986D6B1AD7CE@python.org>

<451D2538.3020201@is.kochi-u.ac.jp> <4EB35FCA-CDE2-4D0F-9BD1-8879D5D2E59F@python.org> Message-ID: <451F1B96.9040005@is.kochi-u.ac.jp> Hi, > An smtpd.py based LTMP server could > provide an interesting proof of concept though. I've almost finished writing this primitive LMTP server. Here is a result of experiment of posting 100 messages to a list and measuring arriving/leaving times on my laptop coLinux (Debian) with Postfix-2.1.5/Python2.4. Time recording is based on the message header and mail.log, so it is a very rough experiment. MTA:In MTA:Out MM:Out sec program: first 08:56:49 08:56:51 08:56:53 4 last 08:56:54 08:57:27 08:57:38 44 sec 5 36 49 maildir: first 08:48:13 08:48:14 08:48:16 3 last 08:48:19 08:48:19 08:48:29 10 sec 6 5 16 lmtp: first 09:12:26 09:12:26 09:12:27 1 last 09:12:31 09:12:32 09:12:41 10 sec 5 6 15 With the current default method of invoking mailman post program and pipelineing takes 49 seconds for the last 100th message to reach the list member (a local user), while maildir and lmtp interface reduce this time to 15 or 16 seconds. You can also see most of the difference occured in MTA's In and Out, which means execution of mailman post program is the most heavy load. Also, maildir and lmtp passing of message from MTA to mailman is a relatively small task than the processing the list message like cooking headers and appending footers and all like those. Conclusion: Maildir or LMTP will not likely be a bottleneck. Cheers, -- Tokio Kikuchi tkikuchi at is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From brad at stop.mail-abuse.org Sun Oct 1 04:11:05 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Sat, 30 Sep 2006 21:11:05 -0500 Subject: [Mailman-Developers] pipe-to-prog/maidir/lmtp performance In-Reply-To: <451F1B96.9040005@is.kochi-u.ac.jp> References: <4519E35A.6070906@is.kochi-u.ac.jp> <4519E971.8070202@nleaudio.com> <451A033B.7090505@Newfield.org> <9B0599C0-D151-4943-B55E-A8A7F90DE660@python.org> <1EC9A0DAC4500B094D771196@[192.168.1.160]> <91A97AAD-C7BC-48B6-B1BE-986D6B1AD7CE@python.org>

<451D2538.3020201@is.kochi-u.ac.jp> <4EB35FCA-CDE2-4D0F-9BD1-8879D5D2E59F@python.org> <451F1B96.9040005@is.kochi-u.ac.jp> Message-ID: At 10:36 AM +0900 10/1/06, Tokio Kikuchi wrote: >> An smtpd.py based LTMP server could >> provide an interesting proof of concept though. > > I've almost finished writing this primitive LMTP server. I am no longer on the list. Please do not include me in any future discussions on subjects relating to the list. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See . From barry at python.org Sun Oct 1 17:27:07 2006 From: barry at python.org (Barry Warsaw) Date: Sun, 1 Oct 2006 11:27:07 -0400 Subject: [Mailman-Developers] pipe-to-prog/maidir/lmtp performance In-Reply-To: <451F1B96.9040005@is.kochi-u.ac.jp> References: <4519E35A.6070906@is.kochi-u.ac.jp> <4519E971.8070202@nleaudio.com> <451A033B.7090505@Newfield.org> <9B0599C0-D151-4943-B55E-A8A7F90DE660@python.org> <1EC9A0DAC4500B094D771196@[192.168.1.160]> <91A97AAD-C7BC-48B6-B1BE-986D6B1AD7CE@python.org>

<451D2538.3020201@is.kochi-u.ac.jp> <4EB35FCA-CDE2-4D0F-9BD1-8879D5D2E59F@python.org> <451F1B96.9040005@is.kochi-u.ac.jp> Message-ID: <41E3CC73-BB35-4671-942C-ECB9F937D366@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 30, 2006, at 9:36 PM, Tokio Kikuchi wrote: > With the current default method of invoking mailman post program > and pipelineing takes 49 seconds for the last 100th message to > reach the list member (a local user), while maildir and lmtp > interface reduce this time to 15 or 16 seconds. You can also see > most of the difference occured in MTA's In and Out, which means > execution of mailman post program is the most heavy load. Also, > maildir and lmtp passing of message from MTA to mailman is a > relatively small task than the processing the list message like > cooking headers and appending footers and all like those. > > Conclusion: Maildir or LMTP will not likely be a bottleneck. Those are very interesting number Tokio, thanks for doing the experiment and posting there results. How much work is your LMTP implementation doing when it receives the message? Is it parsing it and storing the msg pickle? Is it touching any MailList objects? Does it do the entire delivery pipeline? IIUC your results indicate total throughput from submission to MTA to final delivery to user. If that's the case, there's some common constant amount of work being done and I'm just wondering how efficient the LMTP part will be. When you feel confident about your lmtp implementation, go ahead and check it in (probably in Mailman/bin/lmtp.py with hooks for mmshell - -- or I can do the latter). I think at this early date we should make both LMTP and Maildir delivery possible, then we'll try to get real-world feedback from users as to which we should ultimately recommend. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRR/eWHEjvBPtnXfVAQJLPAP/cmQEXjI3fx3Sj4Yq8QJhT4DChuAAVWF8 y0jiCLpViWRP67QtXkEmJhKJPsoakgfQZXMnENHNUzlQ2321KO1Ed4S4H0eKRhWJ DU8KeudwfDzobA42duaWBL6412RNZlmE+b8mEWtctX5ESM3YhHbELklGCdB8GPAV oSRhMsQGJbY= =IA1i -----END PGP SIGNATURE----- From tkikuchi at is.kochi-u.ac.jp Mon Oct 2 03:12:51 2006 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Mon, 02 Oct 2006 10:12:51 +0900 Subject: [Mailman-Developers] pipe-to-prog/maidir/lmtp performance In-Reply-To: <41E3CC73-BB35-4671-942C-ECB9F937D366@python.org> References: <4519E35A.6070906@is.kochi-u.ac.jp> <4519E971.8070202@nleaudio.com> <451A033B.7090505@Newfield.org> <9B0599C0-D151-4943-B55E-A8A7F90DE660@python.org> <1EC9A0DAC4500B094D771196@[192.168.1.160]> <91A97AAD-C7BC-48B6-B1BE-986D6B1AD7CE@python.org>

<451D2538.3020201@is.kochi-u.ac.jp> <4EB35FCA-CDE2-4D0F-9BD1-8879D5D2E59F@python.org> <451F1B96.9040005@is.kochi-u.ac.jp> <41E3CC73-BB35-4671-942C-ECB9F937D366@python.org> Message-ID: <45206793.4050909@is.kochi-u.ac.jp> Hi, Barry Warsaw wrote: > > When you feel confident about your lmtp implementation, go ahead and > check it in (probably in Mailman/bin/lmtp.py with hooks for mmshell > - -- or I can do the latter). I think at this early date we should > make both LMTP and Maildir delivery possible, then we'll try to get > real-world feedback from users as to which we should ultimately > recommend. > I've commited it as LMTPRunner.py because it should be restarted by mailmanctl. > How much work is your LMTP > implementation doing when it receives the message? It does the same thing as MaildirRunner does, although it doesn't do saving the misdirected messages but only to report them in error log. > If that's the case, there's some common constant amount of work being > done and I'm just wondering how efficient the LMTP part will be. My impression is that it is almost the same as Maildir delivery. -- Tokio Kikuchi, tkikuchi at is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From msapiro at value.net Mon Oct 2 16:42:14 2006 From: msapiro at value.net (Mark Sapiro) Date: Mon, 2 Oct 2006 07:42:14 -0700 Subject: [Mailman-Developers] source code for mailman 2.1.7-1.2 In-Reply-To: Message-ID: Peter Soccar wrote: > >where, from which cvs repository can i download complete source code for mailman 2.1.7-1.2 Please do not post to mailman-coders at python.org. That list is only for use by the SourceForge Mailman tracker to report changes. There is no longer a cvs repository for Mailman. You can find the subversion repository for the 2.1.7 release at . For subversion client access, see documents E09 and F06 or F07. As far as any differences between 2.1.7 and 2.1.7-1.2 are concerned, you'll have to talk to whoever made your 2.1.7-1.2 package. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From msapiro at value.net Mon Oct 2 17:09:40 2006 From: msapiro at value.net (Mark Sapiro) Date: Mon, 2 Oct 2006 08:09:40 -0700 Subject: [Mailman-Developers] add new administration page like admin In-Reply-To: Message-ID: Peter Soccar wrote: > >how can i add a new administration page like admin or admindb to mailman Please do not post to mailman-coders at python.org. That list is only for use by the SourceForge Mailman tracker to report changes. See my reply to your mailman-users at python.org post. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at python.org Tue Oct 3 22:03:54 2006 From: barry at python.org (Barry Warsaw) Date: Tue, 3 Oct 2006 16:03:54 -0400 Subject: [Mailman-Developers] pipe-to-prog/maidir/lmtp performance In-Reply-To: <45206793.4050909@is.kochi-u.ac.jp> References: <4519E35A.6070906@is.kochi-u.ac.jp> <4519E971.8070202@nleaudio.com> <451A033B.7090505@Newfield.org> <9B0599C0-D151-4943-B55E-A8A7F90DE660@python.org> <1EC9A0DAC4500B094D771196@[192.168.1.160]> <91A97AAD-C7BC-48B6-B1BE-986D6B1AD7CE@python.org>

<451D2538.3020201@is.kochi-u.ac.jp> <4EB35FCA-CDE2-4D0F-9BD1-8879D5D2E59F@python.org> <451F1B96.9040005@is.kochi-u.ac.jp> <41E3CC73-BB35-4671-942C-ECB9F937D366@python.org> <45206793.4050909@is.kochi-u.ac.jp> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 1, 2006, at 9:12 PM, Tokio Kikuchi wrote: > I've commited it as LMTPRunner.py because it should be restarted by > mailmanctl. > >> How much work is your LMTP >> implementation doing when it receives the message? > > It does the same thing as MaildirRunner does, although it doesn't > do saving the misdirected messages but only to report them in error > log. > >> If that's the case, there's some common constant amount of work >> being done and I'm just wondering how efficient the LMTP part >> will be. > > My impression is that it is almost the same as Maildir delivery. Thanks Tokio! I saw your checkins and I'm going to play with this a bit. There are a few things about virtual_mailbox_maps that I'm not sure I like so LMTP delivery (if it can hold up efficiency-wise) might be preferable all around. Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRSLCKnEjvBPtnXfVAQLf4gP/YFstJb4RQrV2dh5It8REMfQ5bRwWG9U4 rLEQyo1rhzWbHux2LfPIYoOgkcxJWbQgFcgpdl2Z0JfKhk1W8RP3FfFKG5vH6anC rXGyiu2QHA+lzharzIdyxJKWx35pfhPTUHv/WqRpWp6PjFfGDorRU9diVCYTMNPZ /0kr9LMDr28= =wImd -----END PGP SIGNATURE----- From j.e.vanbaal at uvt.nl Wed Oct 4 10:26:24 2006 From: j.e.vanbaal at uvt.nl (Joost van Baal) Date: Wed, 4 Oct 2006 10:26:24 +0200 Subject: [Mailman-Developers] Debugging mailman (resolving inline signature attachments) In-Reply-To: <20060928085514.GA29794@buri.ifi.uio.no> References: <20060928085514.GA29794@buri.ifi.uio.no> Message-ID: <20061004082624.GQ3831@banach.uvt.nl> Hi, On Thu, Sep 28, 2006 at 10:55:14AM +0200, Sven Ingebrigt Ulland wrote: > Hello there. How would I go about debugging mailman, by -- > for example -- polluting the .py libraries with print or > assert statements? If I do that (which seems like a pretty > thoughtless idea), the output would end up .. in /dev/null? > It would probably be better to write to file in stead? > > Right now I'm having a specific problem, but it would be > nice to have some general debugging methods to use in the > future for other problems. > I'd really like to debug that code passage to verify what > variables are screwed up, and which are not. > > Any tips? Perhaps the section "DEBUGGING LIVE MAILMAN" in http://non-gnu.uvt.nl/repos/mailman-ssls/mailman-ssls/doc/secure-list-patch.pod is of any use. Bye, Joost -- Joost van Baal http://abramowitz.uvt.nl/ Tilburg University j.e.vanbaal at uvt.nl The Netherlands -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: Digital signature Url : http://mail.python.org/pipermail/mailman-developers/attachments/20061004/7a99ba2d/attachment.pgp From barry at python.org Thu Oct 5 06:31:25 2006 From: barry at python.org (Barry Warsaw) Date: Thu, 5 Oct 2006 00:31:25 -0400 Subject: [Mailman-Developers] LMTPRunner.py Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Tokio, I took a look at LMTPRunner.py today, and it looked pretty good. I don't think it was quite RFC 2033 compliant though. One thing it needed to do was return a status code for every RCPT TO recipient. Take a look at r8050. I've fixed the status codes and also done a bunch of other refactoring. Note that I haven't yet tried to hook this up to a real Postfix (or other LMTP client), but it seems to do the right thing when you telnet to localhost:8025. Give it a try and let me know what you think. I plan on testing Postfix integration, perhaps tomorrow. This definitely shows a lot of promise. I will probably hold off on updating the MaildirRunner for now, to see how far we can take LMTP delivery, and whether an smtpd.py-based server can hold up. Great work! Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRSSKnXEjvBPtnXfVAQLrUwQAg3BXbEROLAxwQ2CV64bxzQe8tR2X/K7z fdkHK5lepztbKxbYI+RkMzxeYgD8+q78ha8NIQxzmLHW6frcgOmUFyHye9ZT+EiS +/63Joj8bu5GEC0v8F7MsR1J2RqJ67MnwFU/ezge8TNRceeH2y4SuOAcX276oSIq pFpIW0TQO9M= =51Ir -----END PGP SIGNATURE----- From tkikuchi at is.kochi-u.ac.jp Fri Oct 6 03:33:27 2006 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Fri, 06 Oct 2006 10:33:27 +0900 Subject: [Mailman-Developers] LMTPRunner.py In-Reply-To: References: Message-ID: <4525B267.70109@is.kochi-u.ac.jp> Hi Barry, > > I took a look at LMTPRunner.py today, and it looked pretty good. I > don't think it was quite RFC 2033 compliant though. One thing it > needed to do was return a status code for every RCPT TO recipient. > I've looked over that part. ;-) > Take a look at r8050. I've fixed the status codes and also done a > bunch of other refactoring. Note that I haven't yet tried to hook > this up to a real Postfix (or other LMTP client), but it seems to do > the right thing when you telnet to localhost:8025. Give it a try and > let me know what you think. I plan on testing Postfix integration, > perhaps tomorrow. It's working just fine on my test environment. > > This definitely shows a lot of promise. I will probably hold off on > updating the MaildirRunner for now, to see how far we can take LMTP > delivery, and whether an smtpd.py-based server can hold up. Great work! > Now wonder if we can put a MailmanHTTPRunner(Server) in mailman-2.2. This should completely get rid of the setgid problem in the installation. I've tested putting this script in /usr/local/mailman () directory and get my browser pointing to http://server:8000/Mailman/Cgi/listinfo.py. Unfortunately, the BaseHTTPServer in the Python distribution is based on syncronous TCPServer, thus it cannot handle simultaneous connections. There are threading and forking TCPServers in the SocketServer module and we may be able to use them to compose a customized Mailman HTTP Server. --------------------------------------------------------------------- import paths # Put paths.py in /usr/local/mailman directory import BaseHTTPServer import CGIHTTPServer from Mailman.configuration import config config.load() class MailmanHTTPRequestHandler(CGIHTTPServer.CGIHTTPRequestHandler): have_fork = 0 have_popen2 = 0 have_popen3 = 0 cgi_directories = ['/Mailman/Cgi'] def test(HandlerClass=MailmanHTTPRequestHandler, ServerClass=BaseHTTPServer.HTTPServer): CGIHTTPServer.test(HandlerClass, ServerClass) if __name__ == '__main__': test() --------------------------------------------------------------------- -- Tokio Kikuchi, tkikuchi at is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From barry at python.org Fri Oct 6 14:44:43 2006 From: barry at python.org (Barry Warsaw) Date: Fri, 6 Oct 2006 08:44:43 -0400 Subject: [Mailman-Developers] LMTPRunner.py In-Reply-To: <4525B267.70109@is.kochi-u.ac.jp> References: <4525B267.70109@is.kochi-u.ac.jp> Message-ID: <0D2241B6-3610-43B5-8A09-05433A924A12@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 5, 2006, at 9:33 PM, Tokio Kikuchi wrote: >> Take a look at r8050. I've fixed the status codes and also done a >> bunch of other refactoring. Note that I haven't yet tried to hook >> this up to a real Postfix (or other LMTP client), but it seems to do >> the right thing when you telnet to localhost:8025. Give it a try and >> let me know what you think. I plan on testing Postfix integration, >> perhaps tomorrow. > > It's working just fine on my test environment. Excellent, thanks! > Now wonder if we can put a MailmanHTTPRunner(Server) in mailman-2.2. > This should completely get rid of the setgid problem in the > installation. Actually, something that emf mentioned a while ago: we should adapt the current web interface to WSGI and then perhaps use wsgiref.simple_server(): http://www.python.org/doc/current/lib/module-wsgiref.simpleserver.html Of course, this comes with Python 2.5, but I believe is available as a distutils package for Python 2.4. The advantage is not only that we can do away with the setgid stuff, but that our web interface (even if nothing else is rewritten) can be dropped into any WSGI compliant framework. In theory. I haven't actually tried any of that yet, but currently that's the directly I'm thinking 2.2 should move to. (But yes, that does probably mean we could include a wsgiref.simple_server()-based runner of sorts, although that's going to be a bit of a misnomer :) - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRSZPwHEjvBPtnXfVAQKbawQAuVCAFWFGxR6lrSLaIhjWToTvEQrxbuny V5CIMbKj+1TDKeuQUbpzVjkVZ0KAjgH1cPBq6CuQfQVui3FUm924LxfJyqi9Yd3v hNvtWDf8+1lPbXEsf1xH5iCQQIDLu9+1rCNUw8oMcndo5Ibxo5P6L2NCyATNfjXn YxObfiq+gP0= =Wfuw -----END PGP SIGNATURE----- From tkikuchi at is.kochi-u.ac.jp Mon Oct 9 04:19:54 2006 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Mon, 09 Oct 2006 11:19:54 +0900 Subject: [Mailman-Developers] HTTPRunner.py (was Re: LMTPRunner.py) In-Reply-To: <0D2241B6-3610-43B5-8A09-05433A924A12@python.org> References: <4525B267.70109@is.kochi-u.ac.jp> <0D2241B6-3610-43B5-8A09-05433A924A12@python.org> Message-ID: <4529B1CA.6090506@is.kochi-u.ac.jp> Barry Warsaw wrote: > Actually, something that emf mentioned a while ago: we should adapt > the current web interface to WSGI and then perhaps use > wsgiref.simple_server(): > > http://www.python.org/doc/current/lib/module-wsgiref.simpleserver.html Hi, I've checked in HTTPRunner.py using this simple server and wsgi_app.py for wrapping mailman cgi in wsgi environment. I fear I may be doing wrong things but it should be a proof that right things can be done. There are some glitches in admin authentication interfaces: e.g., if I want to enter password in http://server/mailman/admin/listname, then I'm redirected to http://server/admin/admin/listname. Authentication at http://server/mailman/admin/listname/general works but the redirected URL becomes http://server/mailman/admin/listname/admin/listname/general. > > Of course, this comes with Python 2.5, but I believe is available as > a distutils package for Python 2.4. The advantage is not only that > we can do away with the setgid stuff, but that our web interface > (even if nothing else is rewritten) can be dropped into any WSGI > compliant framework. In theory. I haven't actually tried any of > that yet, but currently that's the directly I'm thinking 2.2 should > move to. > > (But yes, that does probably mean we could include a > wsgiref.simple_server()-based runner of sorts, although that's going > to be a bit of a misnomer :) > > - -Barry > Cheers, -- Tokio Kikuchi, tkikuchi at is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From stephen at xemacs.org Wed Oct 11 03:49:57 2006 From: stephen at xemacs.org (stephen at xemacs.org) Date: Wed, 11 Oct 2006 10:49:57 +0900 Subject: [Mailman-Developers] [Mailman-Users] Index Listing of mail lists In-Reply-To: <98a90c220610101650v7aef92c9pe04a7f171332c17e@mail.gmail.com> References: <98a90c220610101650v7aef92c9pe04a7f171332c17e@mail.gmail.com> Message-ID: <17708.19909.978449.862563@uwakimon.sk.tsukuba.ac.jp> Reply-To set to Mailman-Users. Tom Kavanaugh writes: > If there is a way to setup a A-Z index hortizontally above the List name - > Description, it would be great. > > Any code hacks for this feature? This feature is already in the Member List page. Since Mailman is free software, reusing that code doesn't even count as stealing! Mailman Developers: Is the web code set up so that so that admins could fairly easily assemble these UI widgets into a page that suits their usage? Or would that be a major refactoring? Sorta like reimplementing Plone, I guess, but we really don't want to put "import plone" at the top! What I was thinking is that there could be a page generator pipeline, similar to the list processor. Of course the objects we want to generate pages from (member lists, moderation queues, etc) would have to grow appropriate interfaces -- sounds like work! but it would be way cool. From brad at stop.mail-abuse.org Wed Oct 11 05:30:03 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Tue, 10 Oct 2006 22:30:03 -0500 Subject: [Mailman-Developers] [Mailman-Users] Index Listing of mail lists In-Reply-To: <17708.19909.978449.862563@uwakimon.sk.tsukuba.ac.jp> References: <98a90c220610101650v7aef92c9pe04a7f171332c17e@mail.gmail.com> <17708.19909.978449.862563@uwakimon.sk.tsukuba.ac.jp> Message-ID: At 10:49 AM +0900 10/11/06, wrote: > Mailman Developers: Is the web code set up so that so that admins > could fairly easily assemble these UI widgets into a page that suits > their usage? Nope. It's all hard-coded. > Or would that be a major refactoring? Sorta like > reimplementing Plone, I guess, but we really don't want to put "import > plone" at the top! Something like that, or maybe re-implementing Zope. > What I was thinking is that there could be a page generator pipeline, > similar to the list processor. Of course the objects we want to > generate pages from (member lists, moderation queues, etc) would have > to grow appropriate interfaces -- sounds like work! but it would be > way cool. Yeah, way cool. We can't wait to see the code you're going to contribute to do this. ;) -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See . From stephen at xemacs.org Wed Oct 11 08:40:33 2006 From: stephen at xemacs.org (stephen at xemacs.org) Date: Wed, 11 Oct 2006 15:40:33 +0900 Subject: [Mailman-Developers] [Mailman-Users] Index Listing of mail lists In-Reply-To: References: <98a90c220610101650v7aef92c9pe04a7f171332c17e@mail.gmail.com> <17708.19909.978449.862563@uwakimon.sk.tsukuba.ac.jp> Message-ID: <17708.37345.384753.947297@uwakimon.sk.tsukuba.ac.jp> Mailman-Users trimmed. Brad Knowles writes: > At 10:49 AM +0900 10/11/06, wrote: > > Mailman Developers: Is the web code set up so that so that admins > > could fairly easily assemble these UI widgets into a page that suits > > their usage? > Nope. It's all hard-coded. Well, at least the hard code is already done! I love it when I get to do the easy part! > We can't wait to see the code you're going to contribute to do this. ;) I wouldn't spend effort on waiting if I were you; I'm thinking in terms of Mailman 3. But if you're in that big of a hurry, you can check out my xre.py from cvs.xemacs.org, the XEmacs/xemacs-builds/stephen module. It was somewhat inspired by this idea. The web announcement part is a little bit pipelined, and the overall structure is a pipeline. But it's a personal tool, so it's **real** crufty. It's not obvious to me that it would be all that hard to do; what I was hoping for was for some people to chip in with "that's probably going to work, you'll just have to keep finding the stuff that needs to be in the interface, which will be tedious but do-able", or inversely, "you're hosed, because we really can't get away with building these certain pages in a pipeline like that." From barry at python.org Wed Oct 11 14:23:46 2006 From: barry at python.org (Barry Warsaw) Date: Wed, 11 Oct 2006 08:23:46 -0400 Subject: [Mailman-Developers] [Mailman-Users] Index Listing of mail lists In-Reply-To: <17708.37345.384753.947297@uwakimon.sk.tsukuba.ac.jp> References: <98a90c220610101650v7aef92c9pe04a7f171332c17e@mail.gmail.com> <17708.19909.978449.862563@uwakimon.sk.tsukuba.ac.jp> <17708.37345.384753.947297@uwakimon.sk.tsukuba.ac.jp> Message-ID: <2788D46E-177B-4D9D-A86E-7CC89E8A6879@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 11, 2006, at 2:40 AM, wrote: > Brad Knowles writes: > >> At 10:49 AM +0900 10/11/06, wrote: > >>> Mailman Developers: Is the web code set up so that so that admins >>> could fairly easily assemble these UI widgets into a page that >>> suits >>> their usage? > >> Nope. It's all hard-coded. > > Well, at least the hard code is already done! I love it when I get to > do the easy part! > >> We can't wait to see the code you're going to contribute to do >> this. ;) > > I wouldn't spend effort on waiting if I were you; I'm thinking in > terms of Mailman 3. I'm definitely interested in improving things here, but I'd like to try to avoid inventing technology here. There are so many Python web frameworks and templating systems out there, that there's /got/ to be at least one that we can adopt. And I'd like to do so in Mailman 2.2 if possible. BTW, I've been working with Tokio's recent HTTPRunner and wsgiref interface. I'm making progress, but I'm realizing that there are quite a few things that have to be fixed to make that a viable deployment model. One thing I'm trying to eradicate is absolute urls for internal Mailman links. I've got the listinfo and admin pages fixed (mostly), but I probably won't check it in until I have most of the u/i working again. ;) - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRSziWHEjvBPtnXfVAQLtOAQAuPwjcxlz4rPcNQehL81Tznc5vxeSUqBh WCe2sgEksJ/51P6gadqU1DOQ16BL9ElxXNA2KT9uxgY1UhuFZhgkjIGJnYmOvwVC 4IE9begsoA5oq7qfV8ZHnZjR0QOzZN4t7vJc22oHcEn3FDZ83tblxCO5rjznL0RY 9KApK78nyyA= =RA+B -----END PGP SIGNATURE----- From stephen at xemacs.org Wed Oct 11 18:20:00 2006 From: stephen at xemacs.org (stephen at xemacs.org) Date: Thu, 12 Oct 2006 01:20:00 +0900 Subject: [Mailman-Developers] [Mailman-Users] Index Listing of mail lists In-Reply-To: <2788D46E-177B-4D9D-A86E-7CC89E8A6879@python.org> References: <98a90c220610101650v7aef92c9pe04a7f171332c17e@mail.gmail.com> <17708.19909.978449.862563@uwakimon.sk.tsukuba.ac.jp> <17708.37345.384753.947297@uwakimon.sk.tsukuba.ac.jp> <2788D46E-177B-4D9D-A86E-7CC89E8A6879@python.org> Message-ID: <17709.6576.412858.870912@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > I'm definitely interested in improving things here, but I'd like to > try to avoid inventing technology here. There are so many Python web > frameworks and templating systems out there, that there's /got/ to be > at least one that we can adopt. If you want to throw some suggestions my way, I'll take a look. I wouldn't be surprised if what's available is universally quite poorly adapted to what I'd like to do with it, though. > And I'd like to do so in Mailman 2.2 if possible. I don't think there's much chance I can help with that, unless it's gonna be a while. :-( From barry at python.org Wed Oct 11 21:34:37 2006 From: barry at python.org (Barry Warsaw) Date: Wed, 11 Oct 2006 15:34:37 -0400 Subject: [Mailman-Developers] [Mailman-Users] Index Listing of mail lists In-Reply-To: <17709.6576.412858.870912@uwakimon.sk.tsukuba.ac.jp> References: <98a90c220610101650v7aef92c9pe04a7f171332c17e@mail.gmail.com> <17708.19909.978449.862563@uwakimon.sk.tsukuba.ac.jp> <17708.37345.384753.947297@uwakimon.sk.tsukuba.ac.jp> <2788D46E-177B-4D9D-A86E-7CC89E8A6879@python.org> <17709.6576.412858.870912@uwakimon.sk.tsukuba.ac.jp> Message-ID: <4F16C7C8-1144-46E1-AEE7-AA8F4175BF63@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 11, 2006, at 12:20 PM, wrote: > Barry Warsaw writes: > >> I'm definitely interested in improving things here, but I'd like to >> try to avoid inventing technology here. There are so many Python web >> frameworks and templating systems out there, that there's /got/ to be >> at least one that we can adopt. > > If you want to throw some suggestions my way, I'll take a look. > > I wouldn't be surprised if what's available is universally quite > poorly adapted to what I'd like to do with it, though. I know that myself, emf, and others have made several attempts at adapting various existing templating systems to Mailman, but I don't think any of us have had rousing success (I certainly haven't). The ones I know about are ZPT (various implementations exist), Cheetah, Kid, PTL. I'm sure there are others. Google gives me this relatively recent comparison: http://www.simplistix.co.uk/presentations/templating_06/ templating_06.pdf Here Chris Withers gives a pretty good overview of what's available and introduces a new package he calls Twiddler (I'm not endorsing any toolkit). IWBNI whatever we choose supports i18n without forcing translators to translate entire templates. IWBNI the templating system were modular and separate from the web publisher. IWBNI the templates can be edited by mere mortals. >> And I'd like to do so in Mailman 2.2 if possible. > > I don't think there's much chance I can help with that, unless it's > gonna be a while. :-( Who knows? :) - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRS1HVnEjvBPtnXfVAQLBWwP/d5eV1u+/Zff86h3Hg01FXkHQsDYCk+Ws dohrpo6AygnhA8FvskWknvgUUuc881pGSJTcpTF1cX9u9ulzA3PLQ7KjI9jM9Sz8 XADjBTzTO1WP2g/BYuEwTTVORg2xrgVsv7vE1BzDzJ59AAG6+3bM8QUE/Xb53wha a3s3jDCERng= =22BP -----END PGP SIGNATURE----- From i at mindlace.net Thu Oct 12 00:24:36 2006 From: i at mindlace.net (emf) Date: Wed, 11 Oct 2006 18:24:36 -0400 Subject: [Mailman-Developers] Index Listing of mail lists In-Reply-To: <17708.37345.384753.947297@uwakimon.sk.tsukuba.ac.jp> References: <98a90c220610101650v7aef92c9pe04a7f171332c17e@mail.gmail.com> <17708.19909.978449.862563@uwakimon.sk.tsukuba.ac.jp> <17708.37345.384753.947297@uwakimon.sk.tsukuba.ac.jp> Message-ID: <452D6F24.5080708@mindlace.net> stephen at xemacs.org wrote: > > We can't wait to see the code you're going to contribute to do this. ;) > > I wouldn't spend effort on waiting if I were you; I'm thinking in > terms of Mailman 3. I'm trying to modularize the web code now; I'm using something vaguely like a pipeline. At the very least, all of the code that applies to sequences should work for lists of users/lists/messages. If you want to play along, check out the soc2006-webui branch :) ~ethan fremen From barry at python.org Mon Oct 16 15:05:47 2006 From: barry at python.org (Barry Warsaw) Date: Mon, 16 Oct 2006 09:05:47 -0400 Subject: [Mailman-Developers] HTTPRunner.py In-Reply-To: <4529B1CA.6090506@is.kochi-u.ac.jp> References: <4525B267.70109@is.kochi-u.ac.jp> <0D2241B6-3610-43B5-8A09-05433A924A12@python.org> <4529B1CA.6090506@is.kochi-u.ac.jp> Message-ID: <72A3B4C9-AC47-44AE-84C5-D7093A3B2E98@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 8, 2006, at 10:19 PM, Tokio Kikuchi wrote: > I've checked in HTTPRunner.py using this simple server and > wsgi_app.py for wrapping mailman cgi in wsgi environment. I fear I > may be doing wrong things but it should be a proof that right > things can be done. > > There are some glitches in admin authentication interfaces: e.g., > if I want to enter password in http://server/mailman/admin/ > listname, then I'm redirected to http://server/admin/admin/ > listname. Authentication at http://server/mailman/admin/listname/ > general works but the redirected URL becomes http://server/mailman/ > admin/listname/admin/listname/general. I checked in a bunch of updates to the web interface that should make things run better under wsgi. It's still not perfect, but most of the links (which are now relative) should work. I haven't tried it under traditional cgi yet (just wsgiref) so I may have broken things there. If you give it a try, let me know how it goes! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRTODsHEjvBPtnXfVAQIu7QP9GGCNz4jk9eojS5ZTwfVlNAtq4i5vS+Rk NuPojlND9ZfhqIBP0kM7sRFmIh8iVEf0R5Rp+wYMMKANi43IDeks29uZYZoA5V5L Y4AJJTloqWO8fbXL90EsrFEZ6NG96s+r/F2oM3movRoGCtLuugrwOhPsLqRpK4MM /Z6Q4LLSsAU= =ROAT -----END PGP SIGNATURE----- From tkikuchi at is.kochi-u.ac.jp Mon Oct 16 15:25:41 2006 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Mon, 16 Oct 2006 22:25:41 +0900 Subject: [Mailman-Developers] HTTPRunner.py In-Reply-To: <72A3B4C9-AC47-44AE-84C5-D7093A3B2E98@python.org> References: <4525B267.70109@is.kochi-u.ac.jp> <0D2241B6-3610-43B5-8A09-05433A924A12@python.org> <4529B1CA.6090506@is.kochi-u.ac.jp> <72A3B4C9-AC47-44AE-84C5-D7093A3B2E98@python.org> Message-ID: <45338855.9060401@is.kochi-u.ac.jp> Hi, > I checked in a bunch of updates to the web interface that should make > things run better under wsgi. It's still not perfect, but most of the > links (which are now relative) should work. I haven't tried it under > traditional cgi yet (just wsgiref) so I may have broken things there. > > If you give it a try, let me know how it goes! Thank you for the hard work, but now I have to enter admin password every time I click on the admin categories. I use apache ProxyPass under http://server/mailman/admin and the cookie specifies its path as /admin which is different from the current path as viewed from the browser through the reverse proxy. :-( -- Tokio Kikuchi, tkikuchi at is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From barry at python.org Mon Oct 16 17:17:03 2006 From: barry at python.org (Barry Warsaw) Date: Mon, 16 Oct 2006 11:17:03 -0400 Subject: [Mailman-Developers] HTTPRunner.py In-Reply-To: <45338855.9060401@is.kochi-u.ac.jp> References: <4525B267.70109@is.kochi-u.ac.jp> <0D2241B6-3610-43B5-8A09-05433A924A12@python.org> <4529B1CA.6090506@is.kochi-u.ac.jp> <72A3B4C9-AC47-44AE-84C5-D7093A3B2E98@python.org> <45338855.9060401@is.kochi-u.ac.jp> Message-ID: <4826C36A-8CCC-40B5-A981-6FBF4FF6AD83@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 16, 2006, at 9:25 AM, Tokio Kikuchi wrote: >> I checked in a bunch of updates to the web interface that should >> make things run better under wsgi. It's still not perfect, but >> most of the links (which are now relative) should work. I haven't >> tried it under traditional cgi yet (just wsgiref) so I may have >> broken things there. >> If you give it a try, let me know how it goes! > > Thank you for the hard work, but now I have to enter admin password > every time I click on the admin categories. I use apache ProxyPass > under http://server/mailman/admin and the cookie specifies its path > as /admin which is different from the current path as viewed from > the browser through the reverse proxy. :-( Ah darn. I struggled quite a bit with the cookie path and got it to work through wsgiref. I had some problems making that work with the CGI environment variables, but I guess I'll have to try again. :/ - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRTOidHEjvBPtnXfVAQLS0AP/Xqf02Gsc/VdtxGOxcy7l7U0e1xCELueh a1uoEU+fP5Xz/COm3x7V72EmyPvwC+A+H+O5VtXu46SdNG5MSd36BBhrSClkf+3Z WJ6ESyf56GwfihaO1t+3ZmNQnoaqbxCQwYifeZwKbihDZFxx99qCfT42lIUxoZEC wff+Z6ZIAgc= =jfMH -----END PGP SIGNATURE----- From fmouse-mailman at fmp.com Tue Oct 17 03:40:32 2006 From: fmouse-mailman at fmp.com (Lindsay Haisley) Date: Mon, 16 Oct 2006 20:40:32 -0500 Subject: [Mailman-Developers] Request for template substitution token Message-ID: <20061017014032.GC30622@fmp.com> I'm working on some utilities to integrate the Namazu search engine with Mailman, along the lines of Tom Morrison's very nice instruction posted at http://mail.python.org/pipermail/mailman-users/2004-June/037580.html. The integration on the Namazu side is pretty straightforward and I've already written a piece that customizes Namazu templates on a per-list basis with information from Mailman's MailList module. See nmzproc at . There's only one thing holding up the train on the Mailman end, and that's the fact that the only substitution token available in archtoc.html and archtocnombox.html is %(listname)s, which is replaced with the lists real_name, including any capitalization which the list admin may chose to use in the "pretty" name for the list. The Mailman templates need to be modified to generate a small search form, as per Tom Morrison's instructions, and the action attribute of the form needs to be a full path to a directory containing Namazu components, e.g. action="/mailman/%(listname)s/namazu.cgi". If Namazu is set up for a list, and the list admin decides he wants to change the real_name for the list to display all in caps, the link to Namazu will break. One line of code would do this: --- HyperArch.py.orig 2006-10-16 20:25:22.000000000 -0500 +++ HyperArch.py 2006-10-16 20:28:35.000000000 -0500 @@ -752,6 +752,7 @@ listname = mlist.internal_name() mbox = os.path.join(mlist.archive_dir()+'.mbox', listname+'.mbox') d = {"listname": mlist.real_name, + "internal": mlist.internal_name(), "listinfo": mlist.GetScriptURL('listinfo', absolute=1), "fullarch": '../%s.mbox/%s.mbox' % (listname, listname), "size": sizeof(mbox, mlist.preferred_language), This would give us a %(internal)s name for the list in the TOC index.html file which would be lower case and independent of administrative changes to the displayed list name. I can do this easily for myself (I've actually hacked PHP support into the TOC HTML files produced from these templates) but I'd like to put together and release a set of tools to integrate Namazu with Mailman. Telling people to use alternate Mailman templates, or giving them a patch for existing templates, is one thing. Telling them to patch the Mailman Archiver code is rather more radical, and if this small change could get the blessing of the Mailman developers going forward it would make my work on the Namazu integration stuff a lot easier. -- Lindsay Haisley | "Fighting against human | PGP public key FMP Computer Services | creativity is like | available at 512-259-1190 | trying to eradicate | http://www.fmp.com | dandelions" | | (Pamela Jones) | From barry at python.org Tue Oct 17 14:07:47 2006 From: barry at python.org (Barry Warsaw) Date: Tue, 17 Oct 2006 08:07:47 -0400 Subject: [Mailman-Developers] Request for template substitution token In-Reply-To: <20061017014032.GC30622@fmp.com> References: <20061017014032.GC30622@fmp.com> Message-ID: <51477F12-66BA-427B-B96A-FC8498700DA2@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 16, 2006, at 9:40 PM, Lindsay Haisley wrote: > One line of code would do this: > > --- HyperArch.py.orig 2006-10-16 20:25:22.000000000 -0500 > +++ HyperArch.py 2006-10-16 20:28:35.000000000 -0500 > @@ -752,6 +752,7 @@ > listname = mlist.internal_name() > mbox = os.path.join(mlist.archive_dir()+'.mbox', listname+'.mbox') > d = {"listname": mlist.real_name, > + "internal": mlist.internal_name(), > "listinfo": mlist.GetScriptURL('listinfo', absolute=1), > "fullarch": '../%s.mbox/%s.mbox' % (listname, listname), > "size": sizeof(mbox, mlist.preferred_language), > > This would give us a %(internal)s name for the list in the TOC > index.html file > which would be lower case and independent of administrative changes > to the > displayed list name. +1 - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRTTHk3EjvBPtnXfVAQIDZQP/etwU9L80W+LuYR1ZEc81cYUe0bcDytoO MSyTYuFBpQeF4d0bRSxvSbofE6WJC3JuprDNRTmw615CxdcTO+00TincswSwz0f8 8TaTUBkQPLrYAbvoR5DmMgqi8rTebWAzSGp4WwTBQSrUGpPnwm1uTNTV8fzT8Lz0 y7m5YaMb1rs= =FOq/ -----END PGP SIGNATURE----- From thijs at debian.org Tue Oct 17 11:28:31 2006 From: thijs at debian.org (Thijs Kinkhorst) Date: Tue, 17 Oct 2006 11:28:31 +0200 Subject: [Mailman-Developers] Patches from Debian Mailman Message-ID: <1161077311.11781.26.camel@darwin.os9.nl> Hello, I'm one of the maintainers of the Debian package "mailman", of course containing your great piece of software. The team has recently gotten more active, and while mainly concentrating on the Debian-specific parts, there's also a number of fixes we've made (or have been made in the past) to the Mailman sources. I'm trying to get the parts of our changes that are useful outside of Debian, and have submitted a couple of them now to the Patches tracker. There's also some feature patches we received in our BTS but haven't applied to the package. Here's a summary. In our package now: * Trivial change to fblast to add a shebang line http://sourceforge.net/tracker/index.php?func=detail&aid=1578740&group_id=103&atid=300103 * Make Mailman not crash on strange HTTP request types like "PROPFIND": http://sourceforge.net/tracker/index.php?func=detail&aid=1578756&group_id=103&atid=300103 * Russian newlist template has outdated variable (doesn't require comprehending the Russian language): http://sourceforge.net/tracker/index.php?func=detail&aid=1578766&group_id=103&atid=300103 * When searching for members, the selected letter is forgotten: http://sourceforge.net/tracker/index.php?func=detail&aid=1532081&group_id=103&atid=300103 Not yet in our package, but may be in the future: * Make it possible to only build the arch-dep and arch-indep parts in the Makefile. This helps us to make an architecture-specific package for only those files which are, and put everything else in a single architecture independent package. http://sourceforge.net/tracker/index.php?func=detail&aid=1564527&group_id=103&atid=300103 I believe the patches are useful to the whole Free Software community, so I hope they can be applied. Thanks. Thijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20061017/43f963f4/attachment.pgp From dev+lists at humph.com Thu Oct 19 01:37:07 2006 From: dev+lists at humph.com (Giuliano Gavazzi) Date: Thu, 19 Oct 2006 01:37:07 +0200 Subject: [Mailman-Developers] list confirm and request addresses acting as open relay Message-ID: Hello, sorry if this is a dumb observation, but recent spam to the posting address of on of our lists (fortunately a moderated distribution-only list) has prompted some test on my part. I have then noticed that the confirm address (listname-confirm +... at ...) and the request address (listname-request at ...) act as mirrors to the alleged envelope sender, sending back the whole email after the parsed commands. Until now no spammers have used this, but sooner or later they will. For the "confirm" case I suppose a solution would be to only reply to confirm strings that are in the database and only if the envelope sender IS the one associated to the particular confirm string. For the "request" case instead the situation is more complex. The reply should only be generated if the sender is a subscriber to the list, unless, of course, the subject is "subscribe". If it is a subscribe though the body of the message does not contain the original body and the damage is limited. In this "subscribe" case perhaps a throttling or maximum number or outstanding subscription requests would be a good idea. Of course this might be in the latest release but I did not find mention in the list. Thank you Giuliano From stephen at xemacs.org Thu Oct 19 03:35:37 2006 From: stephen at xemacs.org (stephen at xemacs.org) Date: Thu, 19 Oct 2006 10:35:37 +0900 Subject: [Mailman-Developers] list confirm and request addresses acting as open relay In-Reply-To: References: Message-ID: <17718.54889.198632.451859@uwakimon.sk.tsukuba.ac.jp> Giuliano Gavazzi writes: > I have then noticed that the confirm address (listname-confirm > +... at ...) and the request address (listname-request at ...) act as > mirrors to the alleged envelope sender, sending back the whole email > after the parsed commands. This kind of thing has been mentioned, I think, in respect of bounce messages. I think the real solution has to be to send only generated text when that will do. In case of a problem the original message should be stored (and queued for deletion after the usual period for expiration of a confirmation), and a reply generated containing an error message, and the URL of the original message for diagnostic purposes. From iane at sussex.ac.uk Thu Oct 19 11:47:00 2006 From: iane at sussex.ac.uk (Ian Eiloart) Date: Thu, 19 Oct 2006 10:47:00 +0100 Subject: [Mailman-Developers] list confirm and request addresses acting as open relay In-Reply-To: <17718.54889.198632.451859@uwakimon.sk.tsukuba.ac.jp> References: <17718.54889.198632.451859@uwakimon.sk.tsukuba.ac.jp> Message-ID: <23A00C67CE9C76929C4FB37C@lewes.staff.uscs.susx.ac.uk> --On 19 October 2006 10:35:37 +0900 stephen at xemacs.org wrote: > Giuliano Gavazzi writes: > > > I have then noticed that the confirm address (listname-confirm > > +... at ...) and the request address (listname-request at ...) act as > > mirrors to the alleged envelope sender, sending back the whole email > > after the parsed commands. > > This kind of thing has been mentioned, I think, in respect of bounce > messages. > > I think the real solution has to be to send only generated text when > that will do. In case of a problem the original message should be > stored (and queued for deletion after the usual period for expiration > of a confirmation), and a reply generated containing an error message, > and the URL of the original message for diagnostic purposes. > Of course, this is a kind of open relay. If you can get email through to the listname-request address, then you can get Mailman to send email to any address that you like. I hope that's not true of listname-confirm? Oh, but it is. If it sees an unrecognised request, it will respond in the belief that it's an expired request. I have no real information on how often those addresses are really used, but I suspect that most list interaction is through the web these days. Is it possible to turn off listname-request for the site? And, perhaps, to use a much longer expiry time (months rather than days), and ignore or moderated unrecognised requests. Better would be some opportunity to reject them early, so the MTA has a chance of rejecting the incoming email. -- Ian Eiloart IT Services, University of Sussex From dev+lists at humph.com Thu Oct 19 13:10:01 2006 From: dev+lists at humph.com (Giuliano Gavazzi) Date: Thu, 19 Oct 2006 13:10:01 +0200 Subject: [Mailman-Developers] list confirm and request addresses acting as open relay In-Reply-To: <23A00C67CE9C76929C4FB37C@lewes.staff.uscs.susx.ac.uk> References: <17718.54889.198632.451859@uwakimon.sk.tsukuba.ac.jp> <23A00C67CE9C76929C4FB37C@lewes.staff.uscs.susx.ac.uk> Message-ID: <52F990F6-9E85-4E73-916E-F3B24C687C00@humph.com> On 19 Oct 2006, at 11:47, Ian Eiloart wrote: > --On 19 October 2006 10:35:37 +0900 stephen at xemacs.org wrote: > >> Giuliano Gavazzi writes: >> >> > I have then noticed that the confirm address (listname-confirm >> > +... at ...) and the request address (listname-request at ...) act as >> > mirrors to the alleged envelope sender, sending back the whole >> email >> > after the parsed commands. >> >> This kind of thing has been mentioned, I think, in respect of bounce >> messages. >> >> I think the real solution has to be to send only generated text when >> that will do. In case of a problem the original message should be >> stored (and queued for deletion after the usual period for expiration >> of a confirmation), and a reply generated containing an error >> message, >> and the URL of the original message for diagnostic purposes. >> > > Of course, this is a kind of open relay. If you can get email > through to the listname-request address, then you can get Mailman > to send email to any address that you like. I hope that's not true > of listname-confirm? Oh, but it is. If it sees an unrecognised > request, it will respond in the belief that it's an expired request. > I think it is actually more general. Even a valid confirm token will reflect (relay) mail to anyone. > I have no real information on how often those addresses are really > used, but I suspect that most list interaction is through the web > these days. Is it possible to turn off listname-request for the > site? And, perhaps, to use a much longer expiry time (months rather > than days), and ignore or moderated unrecognised requests. Better > would be some opportunity to reject them early, so the MTA has a > chance of rejecting the incoming email. Turning off listname-request (and mailman-request and the confirm addresses too!) for a site is not difficult, just blacklist incoming mail to those addresses and change the text of the relevant messages and pages to reflect that. The "confirm" case is indeed a spiky problem. One could easily check the token against the pending database (one could do it from the MTA, exim could easily do it) but that would not stop a spammer getting valid tokens for new spam runs. The stricter check that would validate a token against the envelope sender would avoid this situation, but make the subscription process less tolerant, as one could subscribe an address that is an alias, and reply to the confirm token using the wrong envelope sender. Stephen proposal that only generated text is sent and only for valid tokens is a good, even if spammers could still make a mailman site blacklisted. But this is verging on the paranoid side. I think these are important (and perhaps related to security) issues. I am only happy that I chose to put our mailman installation on a different network from our domain MTA, just to be sure that it did not get blacklisted. Giuliano From Dale at Newfield.org Thu Oct 19 19:42:23 2006 From: Dale at Newfield.org (Dale Newfield) Date: Thu, 19 Oct 2006 13:42:23 -0400 Subject: [Mailman-Developers] list confirm and request addresses acting as open relay In-Reply-To: <52F990F6-9E85-4E73-916E-F3B24C687C00@humph.com> References: <17718.54889.198632.451859@uwakimon.sk.tsukuba.ac.jp> <23A00C67CE9C76929C4FB37C@lewes.staff.uscs.susx.ac.uk> <52F990F6-9E85-4E73-916E-F3B24C687C00@humph.com> Message-ID: <4537B8FF.9080302@Newfield.org> Giuliano Gavazzi wrote: > Turning off listname-request (and mailman-request and the confirm > addresses too!) for a site is not difficult, just blacklist incoming > mail to those addresses and change the text of the relevant messages > and pages to reflect that. Or more simply, just remove the relevant alias entries in the mail server configuration. -Dale From i at mindlace.net Thu Oct 19 21:45:28 2006 From: i at mindlace.net (emf) Date: Thu, 19 Oct 2006 15:45:28 -0400 Subject: [Mailman-Developers] The one-giant-object approach Message-ID: <4537D5D8.70908@mindlace.net> Gentlebeings, I'm trying to hook up the object-relational mapper I've worked out to mailman, and I'm encountering an issue I'd appreciate feedback on. Take MailList. Aside from its own namespace, it mixes in 11 other classes, leading to 255 names if you dir(list). Is this large, flat namespace a preference? It seems to me like it mixes together many bits of functionality that aren't always needed by whatever code needs a 'list'. It seems to me that if things were broken up a little bit they'd be conceptually easier to follow, and it'd be easier to make improvements. While I understand that a unified DB likely won't make it into 2.2, I would like to break out some functionality, and I just wanted to make sure that keeping a flat namespace wasn't a design goal. Thanks, ~ethan fremen From barry at python.org Fri Oct 20 04:22:08 2006 From: barry at python.org (Barry Warsaw) Date: Thu, 19 Oct 2006 22:22:08 -0400 Subject: [Mailman-Developers] The one-giant-object approach In-Reply-To: <4537D5D8.70908@mindlace.net> References: <4537D5D8.70908@mindlace.net> Message-ID: <2A2883EC-0BE4-4080-8BFC-304FABEC934C@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 19, 2006, at 3:45 PM, emf wrote: > Take MailList. Aside from its own namespace, it mixes in 11 other > classes, leading to 255 names if you dir(list). > > Is this large, flat namespace a preference? It seems to me like it > mixes > together many bits of functionality that aren't always needed by > whatever code needs a 'list'. Personally I'm not very fond of the mix-in architecture of the MailList classes. I believe it was originally intended to allow for easy addition of functionality, but it just makes things more complicated than necessary. > It seems to me that if things were broken up a little bit they'd be > conceptually easier to follow, and it'd be easier to make > improvements. I agree, but I think that will be difficult to impossible for 2.2. OTOH, you can ignore many of the MailList attributes. If you emulate what MailList.Save() does, you'll be fine. OTOH, ignore anything that starts with an underscore or that is a MethodType. > While I understand that a unified DB likely won't make it into 2.2, I > would like to break out some functionality, and I just wanted to make > sure that keeping a flat namespace wasn't a design goal. BTW, I'd love to get a database approach for mailing list data, rather than the current pickle approach. What we've always taken off the table for 2.2 is the unified user database (i.e. one record per user instead of one record per user per list). Even if all that data was stored in a database, it would still be great if you could access those values via attribute access syntax off the MailList instance. Given the ability of Python to interpose attribute access, I think that's possible. That does point to a flat namespace as a simplifying principle. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRTgy0HEjvBPtnXfVAQJmxAQAsbBwBbwbpdaLYfvFIGSdJzqRJRVOYqbW /iE51+WplcGHqjECGMitKSaoSTkRhH1bv6Wbmw++fe6ggEevFHUWpQ6eLqfx0Bup YXGaWpuUBcuRRNGmkxXu2UHygt8/TJoxUtIPZfa/GeDr0Mmr/YOSDLNVwB8W5MCL sObBU0xJhfw= =6NVN -----END PGP SIGNATURE----- From msapiro at value.net Sat Oct 21 17:46:13 2006 From: msapiro at value.net (Mark Sapiro) Date: Sat, 21 Oct 2006 08:46:13 -0700 Subject: [Mailman-Developers] Converting mm_cfg to config in mmshell scripts Message-ID: Several of the mmshell scripts in Mailman/bin in the SVN trunk have not been converted from mm_cfg to the new config scheme, given a -C/--config option, etc. I have done, but not checked in a few. If nobody claims this job, I'll do the rest and check them in. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From msapiro at value.net Sat Oct 21 17:52:57 2006 From: msapiro at value.net (Mark Sapiro) Date: Sat, 21 Oct 2006 08:52:57 -0700 Subject: [Mailman-Developers] Problem with new configuration.Configuration.load() Message-ID: If the new configuration.Configuration.load() method is given a configuration file argument which is a non-existent file, it will silently fall back to loading mm_cfg.py. I think it should remember whether a filename argument is passed and complain if the passed file doesn't exist. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From tkikuchi at is.kochi-u.ac.jp Sun Oct 22 02:16:23 2006 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Sun, 22 Oct 2006 09:16:23 +0900 Subject: [Mailman-Developers] Converting mm_cfg to config in mmshell scripts In-Reply-To: References: Message-ID: <453AB857.50408@is.kochi-u.ac.jp> Mark Sapiro wrote: > Several of the mmshell scripts in Mailman/bin in the SVN trunk have not > been converted from mm_cfg to the new config scheme, given a > -C/--config option, etc. > > I have done, but not checked in a few. If nobody claims this job, I'll > do the rest and check them in. > +1 -- Tokio Kikuchi, tkikuchi at is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From tkikuchi at is.kochi-u.ac.jp Sun Oct 22 02:29:09 2006 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Sun, 22 Oct 2006 09:29:09 +0900 Subject: [Mailman-Developers] Problem with new configuration.Configuration.load() In-Reply-To: References: Message-ID: <453ABB55.4090006@is.kochi-u.ac.jp> Mark Sapiro wrote: > If the new configuration.Configuration.load() method is given a > configuration file argument which is a non-existent file, it will > silently fall back to loading mm_cfg.py. > > I think it should remember whether a filename argument is passed and > complain if the passed file doesn't exist. > +1 BTW, should we all move to new config sheme ? Then, should we make some upgrade script in Mailman/versions.py ? -- Tokio Kikuchi, tkikuchi at is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From barry at python.org Sun Oct 22 23:39:13 2006 From: barry at python.org (Barry Warsaw) Date: Sun, 22 Oct 2006 17:39:13 -0400 Subject: [Mailman-Developers] Converting mm_cfg to config in mmshell scripts In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 21, 2006, at 11:46 AM, Mark Sapiro wrote: > Several of the mmshell scripts in Mailman/bin in the SVN trunk have > not > been converted from mm_cfg to the new config scheme, given a > -C/--config option, etc. > > I have done, but not checked in a few. If nobody claims this job, I'll > do the rest and check them in. +1 - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRTvlAXEjvBPtnXfVAQJfjgP/WXZq6Qc3M0jmhEPUwlCEwaM7RPsOYpIu 9hlVFjU6MbAI4qIfqUU44aHXQWKasDC6P2gdBulmDL4moy1e2b+f9PlBZ5ORveJz tEC5bB8FIgwpGt0W1B4WSFNa2w4/8mL9Kf6phAVkbR+8gpkU0utZ8ro6yBbaAS2X X8z9PQaehVA= =l92f -----END PGP SIGNATURE----- From barry at python.org Sun Oct 22 23:45:29 2006 From: barry at python.org (Barry Warsaw) Date: Sun, 22 Oct 2006 17:45:29 -0400 Subject: [Mailman-Developers] Problem with new configuration.Configuration.load() In-Reply-To: <453ABB55.4090006@is.kochi-u.ac.jp> References: <453ABB55.4090006@is.kochi-u.ac.jp> Message-ID: <79E3E2DB-E890-42F5-B223-1980D9EA4491@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 21, 2006, at 8:29 PM, Tokio Kikuchi wrote: > Mark Sapiro wrote: >> If the new configuration.Configuration.load() method is given a >> configuration file argument which is a non-existent file, it will >> silently fall back to loading mm_cfg.py. >> >> I think it should remember whether a filename argument is passed and >> complain if the passed file doesn't exist. >> > +1 > > BTW, should we all move to new config sheme ? Then, should we make > some > upgrade script in Mailman/versions.py ? So one question is whether we should continue to support mm_cfg.py for Mailman 2.2. Originally I thought we should for backward compatibility. Tokio, are you suggesting that we move a MM2.1 mm_cfg.py to etc/mailman.cfg during the upgrade? If we do that, then we can just eradicate mm_cfg.py altogether. Otherwise, if we decide to keep mm_cfg.py for backward compatibility, I do think we ought to complain if a file is passed in that doesn't exist. I wasn't sure we should do the complaining in .load(), but since those are only every called from bin scripts, I think that's probably fine. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRTvmenEjvBPtnXfVAQJhSgP/ZgIaDWPDCvEWecYNPgNyU3RTbqco7xp/ gycUe0kyo0MFqmuRcJd/HDYqar5JaLIPSRYhNM8b5w8OgdrL5sJGJX1eOTiuv0sb TSr2jiJHnnGIXZyNRj2Q2HDZw4yURBbrT0S8eaTtaxe2P2V0N8udmyRgfem1lynk bAREAHkUaUY= =hidD -----END PGP SIGNATURE----- From bob at nleaudio.com Mon Oct 23 06:03:11 2006 From: bob at nleaudio.com (Bob Puff) Date: Mon, 23 Oct 2006 00:03:11 -0400 Subject: [Mailman-Developers] Problem with new configuration.Configuration.load() In-Reply-To: <79E3E2DB-E890-42F5-B223-1980D9EA4491@python.org> References: <453ABB55.4090006@is.kochi-u.ac.jp> <79E3E2DB-E890-42F5-B223-1980D9EA4491@python.org> Message-ID: <20061023040218.M75447@nleaudio.com> +1 on the idea of etc/mailman.cfg. Would be nice also to have some sample file of all configurable parms, or at least a doc of it. ---------- Original Message ----------- From: Barry Warsaw To: Tokio Kikuchi Cc: Mailman Developers Sent: Sun, 22 Oct 2006 17:45:29 -0400 Subject: Re: [Mailman-Developers] Problem with new configuration.Configuration.load() > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Oct 21, 2006, at 8:29 PM, Tokio Kikuchi wrote: > > > Mark Sapiro wrote: > >> If the new configuration.Configuration.load() method is given a > >> configuration file argument which is a non-existent file, it will > >> silently fall back to loading mm_cfg.py. > >> > >> I think it should remember whether a filename argument is passed and > >> complain if the passed file doesn't exist. > >> > > +1 > > > > BTW, should we all move to new config sheme ? Then, should we make > > some > > upgrade script in Mailman/versions.py ? > > So one question is whether we should continue to support mm_cfg.py > for Mailman 2.2. Originally I thought we should for backward > compatibility. Tokio, are you suggesting that we move a MM2.1 > mm_cfg.py to etc/mailman.cfg during the upgrade? > > If we do that, then we can just eradicate mm_cfg.py altogether. > Otherwise, if we decide to keep mm_cfg.py for backward compatibility, > I do think we ought to complain if a file is passed in that > doesn't exist. I wasn't sure we should do the complaining in > .load(), but since those are only every called from bin scripts, I > think that's probably fine. > > - -Barry > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (Darwin) > > iQCVAwUBRTvmenEjvBPtnXfVAQJhSgP/ZgIaDWPDCvEWecYNPgNyU3RTbqco7xp/ > gycUe0kyo0MFqmuRcJd/HDYqar5JaLIPSRYhNM8b5w8OgdrL5sJGJX1eOTiuv0sb > TSr2jiJHnnGIXZyNRj2Q2HDZw4yURBbrT0S8eaTtaxe2P2V0N8udmyRgfem1lynk > bAREAHkUaUY= > =hidD > -----END PGP SIGNATURE----- > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com > > Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp ------- End of Original Message ------- From jigermano at gmail.com Mon Oct 23 18:03:20 2006 From: jigermano at gmail.com (Juan Ignacio Germano) Date: Mon, 23 Oct 2006 13:03:20 -0300 Subject: [Mailman-Developers] Question about fix for CVE-2006-3636 Message-ID: <60c5f2fb0610230903s7b8b9ae4v90ca3b75270f6ce4@mail.gmail.com> Hi everyone. Can anyone tell how is it that the XSS indicated by this advisory was fixed? I might be something wrong here, but can't see what is it. I was using a fairly old version (2.1.5), and upgraded to 2.1.9. To my surprise, the XSS using the URL with listinfo.html is still working, changing the content (HTML) of the list's info using the PoC URL of the said advisory. Reading the code for edithtml.py I can still see problems here: passing the values using GET still works, and the regular expression looking for <[/]?script.*> still is case sensitive. The diff between revision 7723 and 8001 for edithtml.py (Release_2_1-maint branch) gives me: Index: edithtml.py =================================================================== --- edithtml.py (revision 7723) +++ edithtml.py (working copy) @@ -143,7 +143,8 @@ doc.AddItem('

') doc.AddItem('

') form = Form(mlist.GetScriptURL('edithtml') + '/' + template_name) - text = Utils.websafe(Utils.maketext(template_name, raw=1, mlist=mlist)) + text = Utils.maketext(template_name, raw=1, mlist=mlist) + # MAS: Don't websafe twice. TextArea does it. form.AddItem(TextArea('html_code', text, rows=40, cols=75)) form.AddItem('

' + _('When you are done making changes...')) form.AddItem(SubmitButton('submit', _('Submit Changes'))) I am sure I'm doing something wrong, but can't see what is it. Where's the fix? Cheers, -- Juan