-----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-----
-----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-----
-----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?<br>'),
> _('''None - no verification steps (<em>Not
> Recommended </em>)<br>
> @@ -67,7 +67,7 @@
> Require approval - require list
> administrator
> Approval for subscriptions <br>
> Confirm and approve - both confirm and
> approve
> -
> +
> <p>(*) 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 <br>
> Confirm and approve - both confirm and
> approve
> -
> +
> <p>(*) 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-----
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
-----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-----
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