Mailman-Developers November 2007

mailman-developers@python.org

6 participants
7 discussions

Re: [Mailman-Developers] [Mailman-checkins] [Branch ~mailman-coders/mailman/2.1]

by Barry Warsaw

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 4, 2007, at 9:46 PM, noreply(a)launchpad.net wrote: > ------------------------------------------------------------ > revno: 992 > committer: Mark Sapiro <msapiro(a)value.net> > branch nick: 2.1 > timestamp: Thu 2007-10-04 18:35:10 -0700 > message: > /cygdrive/c/MM_bzr/log.txt > modified: > Mailman/versions.py > > === modified file 'Mailman/versions.py' > --- a/Mailman/versions.py 2005-12-30 18:50:08 +0000 > +++ b/Mailman/versions.py 2007-10-05 01:35:10 +0000 > @@ -483,10 +483,11 @@ > # blow away the original timestamp and request id. > This means the > # request will live a little longer than it possibly > should have, > # but that's no big deal. > + import email > for p in v: > author, text = p[2] > reason = p[3] > - msg = Message.OutgoingMessage(text) > + msg = email.message_from_string(text, > Message.Message) > l.HoldMessage(msg, reason) > del r[k] > elif k == 'add_member': Should the import happen at the module global level? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHQIRK2YZpQepbvXERAjRQAJ9/yhfNVNoxMY+V3jS9p7rZka5QmQCgrNpS ZXyQ0KC915TCjkwM7ECdeOc= =M8JK -----END PGP SIGNATURE-----

13 years, 10 months

lost email

by Barry Warsaw

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks, I lost my entire raid array over the weekend. Fortunately, I was able to make a backup of most stuff on November 20th, and managed to save a few emails out of my local cache up to November 23rd (thank you, thank you, thank you Mail.app!). Depending on what upstream servers bounced or delayed, I may not have gotten anything from the 23rd until today. Everything's back up again now, but if you sent me an important email over the Thanksgiving holiday, assume I lost it and please resend! Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHSteD2YZpQepbvXERAqtoAJ9aJPGRcQ/An5YS66sydkJp5vSj0ACfRXYE 8KPXA/n5BIyj8BcaArBuYv8= =G0GI -----END PGP SIGNATURE-----

13 years, 10 months

Shameless plug

by Barry Warsaw

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks, I apologize in advance for the shameless plug. GNU Mailman is up for the 2007 Antonio Pizzigati Prize for software in the public interest. I sure would appreciate it if you take the time to vote for GNU Mailman: http://forums.pizzigatiprize.org/index.php Vote in the 'Vote' forum. Leave comments in the 'GNU Mailman' forum. Yes, you need to register with the site in order to vote. Thanks for your support! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHQf9t2YZpQepbvXERAorYAKCXoVhrBI8eZu+uRxaYlIdyCjAj/ACglrYh RQstgR9SujgyTqsMVSh2q/s= =oIKy -----END PGP SIGNATURE-----

13 years, 11 months

Re: [Mailman-Developers] [Mailman-checkins] [Branch ~mailman-coders/mailman/2.1]

by Barry Warsaw

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mark, On Nov 18, 2007, at 4:40 PM, noreply(a)launchpad.net wrote: > === modified file 'Mailman/Gui/Privacy.py' > --- a/Mailman/Gui/Privacy.py 2005-12-30 18:50:08 +0000 > +++ b/Mailman/Gui/Privacy.py 2007-11-18 20:01:26 +0000 > @@ -1,17 +1,17 @@ > -# Copyright (C) 2001-2005 by the Free Software Foundation, Inc. > +# Copyright (C) 2001-2007 by the Free Software Foundation, Inc. > # > # This program is free software; you can redistribute it and/or > # modify it under the terms of the GNU General Public License > # as published by the Free Software Foundation; either version 2 > # of the License, or (at your option) any later version. > -# > +# > # This program is distributed in the hope that it will be useful, > # but WITHOUT ANY WARRANTY; without even the implied warranty of > # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > # GNU General Public License for more details. > -# > +# > # You should have received a copy of the GNU General Public License > -# along with this program; if not, write to the Free Software > +# along with this program; if not, write to the Free Software > # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA > 02110-1301, > # USA. > > @@ -59,7 +59,7 @@ > _('Confirm'), > _('Require approval'), > _('Confirm and approve')), > - 0, > + 0, > _('What steps are required for > subscription? '), > _('''None - no verification steps (Not > Recommended ) > @@ -67,7 +67,7 @@ > Require approval - require list > administrator > Approval for subscriptions > Confirm and approve - both confirm and > approve > - > + > (*) when someone requests a > subscription, > Mailman sends them a notice with a unique > subscription request number that they > must reply to > @@ -88,7 +88,7 @@ > Require approval - require list > administrator > approval for subscriptions > Confirm and approve - both confirm and > approve > - > + > (*) when someone requests a > subscription, > Mailman sends them a notice with a unique > subscription request number that they > must reply to These changes affect all translations because they change the source string. Since translators will get the new pot file soon, this might be okay, but I just wanted to point that out. Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHQLI32YZpQepbvXERAlbIAJ9285htmRgaa/bEhdECBJGidBXUfQCglMI5 As32OIHFWg9UvNkk/jhkKTQ= =mIJw -----END PGP SIGNATURE-----

13 years, 11 months

Problem with Proxying and Utils.GetRequestURI

by Mathias Andre

Dear all, In my company we're currently running Mailman 2.1.9. The setup is as follow: We have a dedicated Mailman server list.example.com For several reason we have been asked to make use of our main web server to proxy the request to the Mailman server (this allow us to use one single certificate SSL) so on our main web server www.example.com we have the following Apache configuration: ProxyPass /lists http://list.example.com/cgi-bin/mailman/ ProxyPassReverse /lists http://list.example.com/cgi-bin/mailman/ So we can acess the Mailman web interfaces via for example: http://www.example.com/lists/listinfo/mailman This works just fine, we 'renamed' all the lists using fix_url and everything went ok, all the links are fine. Well, except for one: the ACTION= entry in all the login forms (admin, admindb...) After a bit of investigation I identified the source of the 'problem', in Mailman/Cgi/Auth.py in def loginpage(): As it's a frontpage the actionurl comes from Utils.GetRequestURI(url), which in turns uses the REQUEST_URI environment variable. In our case this variable is set to the *local* Apache path, ie the path on list.example.com instead of the path on www.example.com, so we have /cgi-bin/mailman//admin/mailman instead of: /lists/admin/mailman So the web browser then tries to send the form's data to www.example.com/cgi-bin/mailman//admin/mailman which obviously doesn't exist. We temporarily fixed our problem by forcing loginpage() to always return actionurl = url whether or not frontpage is True or not. This doesn't seem to have broken anything else but obviously I would like to find a cleaner solution. So I have a couple of questions: Are we doing something wrong in our setup? Why does Mailman GetRequestURI if frontpage is True? I hope that someone will be able to enlighten us :) Many thanks in advance for this, and for the great piece of software! Mathias Andre -- * Mathias Andre Phone : +49 (0)89 3200 6760 *E S* European Southern Observatory Fax : +49 (0)89 3200 6380 O Karl Schwarzschildstr. 2 Office 213/6 * D-85748 Garching Germany "For every problem, there is a solution that is simple, neat, and wrong." H. L. Mencken

13 years, 11 months

Re: [Mailman-Developers] [Mailman-checkins] [Branch ~mailman-coders/mailman/3.0]

by Barry Warsaw

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 6, 2007, at 9:07 PM, noreply(a)launchpad.net wrote: > ------------------------------------------------------------ > revno: 6573 > committer: Mark Sapiro <msapiro(a)value.net> > branch nick: 3.0 > timestamp: Tue 2007-11-06 18:03:28 -0800 > message: > - Scrubber.py > Fixed an issue where an implicit text/plain part without any > headers gets > lost. > > Moved the cleansing of the filename extension to a place where > it is > guaranteed to be a string as opposed to an empty list. > modified: > Mailman/Handlers/Scrubber.py > > === modified file 'Mailman/Handlers/Scrubber.py' > --- a/Mailman/Handlers/Scrubber.py 2007-10-31 21:38:51 +0000 > +++ b/Mailman/Handlers/Scrubber.py 2007-11-07 02:03:28 +0000 > @@ -46,7 +46,7 @@ > # Path characters for common platforms > pre = re.compile(r'[/\\:]') > # All other characters to strip out of Content-Disposition: filenames > -# (essentially anything that isn't an alphanum, dot, slash, or > underscore. > +# (essentially anything that isn't an alphanum, dot, dash, or > underscore). > sre = re.compile(r'[^-\w.]') > # Regexp to strip out leading dots > dre = re.compile(r'^\.*') > @@ -265,7 +265,7 @@ > # If the message isn't a multipart, then we'll strip it > out as an > # attachment that would have to be separately downloaded. > Pipermail > # will transform the url into a hyperlink. > - elif part and not part.is_multipart(): > + elif part._payload and not part.is_multipart(): I'm not sure it's a good idea to use this non-public attribute. 'part.get_payload()' would probably be a better test. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHQH3Q2YZpQepbvXERAh5kAJ9vkjyCoAV10aYaNEDE34i9KNKQxgCgjF3p c7yN8r7OSuvkTjVUXa75zKA= =V12k -----END PGP SIGNATURE-----

13 years, 11 months

Re: [Mailman-Developers] Improving the archives

by Craig Loomis

Or Re: [Mailman-Developers 10417] Improving the archives I would like to interject and highlight some use cases for stable and predictable IDs. For us, "message IDs" are directly used both by people and ignorant programs. Our mailing lists serve as a permanent and concise record of our discussions, decisions, and operations, and we find it invaluable to be able to refer to individual messages in a simple and memorable way: "message 1210 in the calibration list", say. Other people can then easily jot that info down or directly find the message. Some message IDs even become shorthands for a particular topic or decision. We have also added trac InterWiki templates pointing into our mail archives (as listname:number), which encourages desirable cross-referencing (PRs, wiki pages, and SVN change logs can refer to mail messages, just as wiki pages could always refer to changesets and PRs, etc, etc.) But trac InterWiki templates can only interpolate $1,$2,... arguments into strings, and could not possibly calculate anything based on the _content_ of the messages. Globally unique IDs, hashed IDs, etc., are very appealing from various CS-y and techie points of view, but are simply not memorable to humans or knowable by dumb external programs. I think as much, or more, effort should be put into delivering a straightforwardly useable naming scheme as goes into making an arbitrary message recoverable from anywhere. Basically, "friendly URLs" should be a primary requirement, not an optional afterthought for careless geeks like me to get wrong later.... We long ago added an extremely simple ID handoff between MM 2.1.8 and pipermail, and though imperfect it has served us well. Basically, we hijacked the .post_id member in mailman (otherwise basically unused, and mysteriously a floating point number); CookHeaders stuffed it into a X-Mailman-Sequence-ID header line, and AfterDelivery incremented it. In turn, pipermail uses the header to feed a sequence ID into make_article, and the message is squirreled away as $mailinglist/all/%d.html. There are a few other minor matters (e.g. post_id was added to Decorators, a couple of templates were changed, we lost having 'ls' sort chronologically [did we have to add .last and .prev to the HyperDatabase classes?]), but it really was a minor bit of work. And for stability, as long as the archive files aren't lost, pipermail rebuilds should yield the same URLs even if junk messages have been deleted. [Oh, we did also add a "never rotate" policy to our archives, but that is finesseable. ] As an aside on other discussions, can you get away without using Message-ID or Date? I.e., aren't those just more of those tokens which were standardized back before the Internet got tricky enough to invalidate the standards? Mailing lists serialize incoming messages, and so can generate their own unique and trustworthy IDs. "UUIDs" would work, but if you can trust yourself to generate them, consecutive integers provide minimal, order-preserving, perfect hashing, too! Anyhow, we have found that people will enthusiastically refer by name to individual messages within mail archives if they can. - craig

13 years, 11 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers November 2007