Mailman 3 July 2008 - Mailman-Developers

Re: [Mailman-Developers] [Mailman-checkins] [Branch ~mailman-administrivia/mailman-administrivia/admin] Rev 25: updates
by Mark Sapiro 06 Jul '08

06 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 | + <li>the | + <a href="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mailman/mailman/ACKNOWLEDGME…" | + >list of contributors</a>, bug hunters, big idea people, and others | + who have helped immensely with Mailman's development The above link is dead. The current link to that version is <http://mailman.cvs.sourceforge.net/mailman/mailman/ACKNOWLEDGMENTS?view=mar…>, but a somewhat more current link is <http://mailman.svn.sourceforge.net/viewvc/mailman/trunk/mailman/docs/ACKNOW…> or perhaps <http://mailman.svn.sourceforge.net/viewvc/*checkout*/mailman/trunk/mailman/…>. Better still, would be a link to the current head revision of the lp:mailman branch, but I don't know what that would be. I can browse to the file at <http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/annotate/6635?file_…> (<http://tinyurl.com/57jp73>), but that is the specific revision, not the generic latest revision. - -- Mark Sapiro <mark(a)msapiro.net> 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) iD8DBQFIcPdTVVuXXpU7hpMRAuBaAJ466jmQZ4NEswPaq8do5Y2Std1dkwCeKHYE 9FO1kfvLDpS+d/p0FYbBFkQ= =K/WD -----END PGP SIGNATURE-----

1 0

Donate to GNU Mailman!
by Barry Warsaw 06 Jul '08

06 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm very pleased to announce that you can now donate to the GNU Mailman project! https://www.fsf.org/donate/directed-donations/gnumailman/ The Free Software Foundation has established a directed donation fund for GNU Mailman. Most of your donation goes directly to GNU Mailman, with a small percentage going to help the FSF. You can now support both great organizations with one donation. As quoted on the donation page: "Your donation will be used to obtain equipment, services, development resources and other support for the GNU Mailman project. All expenditures will be approved by a committee chosen from core GNU Mailman maintainers, and will be fully disclosed on the main GNU Mailman website." Currently myself, Mark Sapiro and Terri Oda are serving as members of the informal Mailman Steering Committee. I'd like to thank Peter Brown at the FSF for help getting this set up over there. I'd also like to thank Jeff Marshall and Jeff Breidenbach from the Mail-Archive.com for their initial generous donation. As part of this kick-start, Mailman 3 will make it possible to easily archive your public mailing lists at www.mail-archive.com, including a permalink in the footer of all messages. More details on the donation program are available on the wiki: http://wiki.list.org/x/R4BJ Feel free to comment on that page with any questions, and we'll make sure to update the page with any additional information. Please consider supporting both GNU Mailman and the FSF with your donation. We thank you. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkhw6k0ACgkQ2YZpQepbvXEo8ACffJq3QNTmNIDIR8Fa6x8e+sjT 2egAnArei7fdCEsIjNjcW7utRs6KHHCc =6VAj -----END PGP SIGNATURE-----

1 0

Re: [Mailman-Developers] [Mailman-Users] Encrypted mailing lists
by Barry Warsaw 03 Jul '08

03 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm moving this discussion to mailman-developers. On Mar 30, 2008, at 2:39 PM, Alster wrote: > > I have been repeatedly tempted to sum up options of setting up > encrypted > mailing lists, with or without using GNU Mailman. > > As such, only these options listed in my previous summary remain: > > * mailman-ssls, a Mailman-Patch which has recently been updated for > Mailman 2.1.9 compatibility: > http://non-gnu.uvt.nl/mailman-ssls/ > > * firma, a standalone encrypted mailinglist server (written in bash): > http://codecoop.org/projects/firma/ > > > Additionally, there are these options which had not been part of the > last overview: > > * MMReencrypt, another Mailman patch > https://sourceforge.net/projects/mmreencrypt/ > no longer maintained > > * Schleuder, a standalone 'crypto mailinglist' > http://codecoop.org/projects/schleuder/ > still maintained (according to their versioning system), but last > release dates back to 2006 I don't have time right now to look at these, however I would really like to support some form of encrypted mailing lists for Mailman 3, if not also 2.2. It isn't possible to add this feature to Mailman 2.1. If you're interested in working on this, it would be good to capture some requirements and use cases in the wiki. If you wanted to do a survey of the approaches and implementations that have gone before, that would also help. Ideally, some folks would be motivated enough to start developing some branches in Bazaar so that we can take a look, with an eye toward supporting the feature officially in a future release. Feel free to discuss further on this mailing list. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkf+l2EACgkQ2YZpQepbvXFFBQCdFY+07fgyROIVGUVInd1+Zhph HBkAnjuh78SV2DzvEtchN0CAFLeoXkjE =iaw1 -----END PGP SIGNATURE-----

3 2

Re: [Mailman-Developers] RFC 5064 Archived-At header
by Barry Warsaw 03 Jul '08

03 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 3, 2008, at 2:11 AM, Earl Hood wrote: > On July 3, 2008 at 00:57, Barry Warsaw wrote: > >> I've just updated the current proposal on the Mailman wiki: >> >> http://wiki.list.org/x/yQAM >> >> See specifically the Open Issues section. The most straight-forward >> way to implement this leads to long, unusable (in our opinion) urls. >> Shortening the urls would require quite a bit of additional >> implementation complexity. What to do? > > Quick editorial comment: in the "Open issues" section, you write: > > "... Mail-Archive.com uses MHonArc which requires the use of the > list name in the url." > > This is misleading wrt mhonarc. Mhonarc imposes no requirement on > how an archive is structured on the file system from a pathname > perspective. The convention is something imposed by the user. Thanks Earl. Fixed. > As for "readable URLs", I still think it may be a bogus concern. > Usability testing would have to be done to verify if this concern > is real. I've clarified that this claim hasn't been tested. > Wrt this context, it seems most will "click" on the URL in the mail > message, or copy-n-paste it. > > And even then, I wonder how much the link will actually get used. > Will someone provide some real use case scenarios of how the > archived-at URL gets used by a message receipient. If I have > the message locally, do I care where it is archived? Yes. Archived messages are referenced all over the place, in forum posts and wiki pages to name a few. Another use case is referring to the message in other mailing list discussions. E.g. I'd like to point mhonarc-devs at the start of the original thread months ago on mailman- developers. Right now, if I have a message in one of my folders, it is often quite difficult to find the url that the message is archived. > One reasonable case I can think of is if a receipient wants > to tell others about the message, and instead of forwarding > the message they got, they just send a URL to it, which would > allows others to following subsequent follow-ups if they are > not subscribed to the list. One thing I've dreamed about in an archiver is a "mail this to me" link in the archived message. This would allow me for example, to jump start the thread in my mail reader. So if you were to send me the archived-at url for a message in mhonarc-dev, I'd follow that in my browser, click the "mail this to me" link and it would show up in my inbox, where I can use all my MUA goodness on it. > Or, they bookmark the link so they can always go back to the > message w/o having to archive in their local MUA. > > Either scenario implies the user can either do a couple of clicks > or just copy-n-paste the URL to their bookmark manager. > > This implies the archive-at URL is mainly for bookmarking purposes. > I.e. > I go to the archive and read some messages (or got their via a > search). > I see a message of interest, and want to bookmark it so I can go back > to it directly. You may be right that the readability argument is specious. It may be that cut-n-paste is the overwhelming use case for archived-at. Does that mean you'd argue for the slightly shorter base64 encoding of the hash? > P.S. When time permits, I will look into mhonarc to see if it can > be changed so the filenames it uses for messages can be based on > Stable URL since stable filenames has been a problem for mhonarc. That would be awesome. Stable URLs on archive regeneration are really the core impetus for all this, though the discussion has (rightly) diverged a bit since then. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkhs56YACgkQ2YZpQepbvXHv9gCgki7rMxxaddJLUQIegCtuKV0c wmQAoIzo5IKZqVC9cAc1Qq3WITcF0IHe =jAX3 -----END PGP SIGNATURE-----

1 0

Re: [Mailman-Developers] RFC 5064 Archived-At header
by Jeff Breidenbach 03 Jul '08

03 Jul '08

>Will someone provide some real use case scenarios of how the >archived-at URL gets used by a message receipient. If I have >the message locally, do I care where it is archived? It's handy if you are writing a blog. For example, Linux Weekly News reports on the Linux Kernel mailing list. They quote particular messages, and provide an archival link. This lets readers examine the (possibly active) thread. http://lwn.net/Articles/286910/ http://lwn.net/Articles/287490/

1 0

RFC 5064 Archived-At header
by Barry Warsaw 03 Jul '08

03 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello MHonArc and Mailman developers. RFC 5064 describes the Archived-At header, which is used to point directly to the archived version of a mailing list mail message. The value of this header could also be used in a message body footer, such as the type that Mailman typically adds to its list copy of the message. Supporting this would be a big improvement in usability for mailing lists and is an often requested feature of Mailman. We have been having some off-list discussions recently between Jeff Marshall and Jeff Breidenbach of the Mail-Archive.com, Earl Hood of the MHonArc project and myself on approaches that would provide for support of RFC 5064 Archived-At headers. The RFC itself is agnostic on how to calculate the value of this header, but it does provide some suggestions. On the mailman-developers mailing list a while ago we discussed several ways of calculating this header, and in our private discussions, we've refined our thoughts. We're now at something of an impasse, where the specific approach requires us to make some trade- offs between implementation choices and usability. It's now time to get your feedback. I've just updated the current proposal on the Mailman wiki: http://wiki.list.org/x/yQAM See specifically the Open Issues section. The most straight-forward way to implement this leads to long, unusable (in our opinion) urls. Shortening the urls would require quite a bit of additional implementation complexity. What to do? It's time to open this up to your ideas, but let me say that from Mailman(3)'s perspective, the exact algorithm probably doesn't matter much. I have a bzr branch that implements the interfaces and infrastructure for archiver plugins, so if MHonArc, Pipermail, and Mail-Archive.com all chose different algorithms, we can fairly easily write a different plugin for each. Still, it would be good to standardize on a usable, implementable approach. I invite you to read the wiki page, and comment either there or as a follow up to this message. I am not on the mhonarc-dev mailing list. Cheers, - -Barry P.S. mhonarc-devs: I apologize in advance for the replybot on my email address. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkhsXCIACgkQ2YZpQepbvXFvNwCgg6jS/6NgmwYMa1W+9786Qd63 d00AoLJ99UEbKmvoBRUGbVi+B+PHJZEk =Lzo8 -----END PGP SIGNATURE-----

1 0

Re: [Mailman-Developers] [Mailman-Users] Python process size grows 30x in 8 hours (memory
by Barry Warsaw 02 Jul '08

02 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 2, 2008, at 11:15 AM, Mark Sapiro wrote: > At some point in the next day or so, I'm going to make a modified > scripts/post script which will queue incoming messages in qfiles/bad > and then move them to qfiles/in only if they are under a certain size. > I'm really curious to see if that will help. This should be moved to mailman-developers, but in general it's an interesting idea. In MM3 I've split the incoming queue into two separate queues. The incoming queue now solely determines the disposition of the message, i.e. held, rejected, discarded or accepted. If accepted, the message is moved to a pipeline queue where it's munged for delivery (i.e. headers and footers added, etc.). MM3 also has an LMTP queue runner, which I'd like to make the default delivery mechanism for 3.0 and possibly 2.2 (yes, I still have a todo to back port MM3's new process architecture to 2.2). Although it's not there right now, it would be trivial to add a check on the raw size of the message before it's parsed. If it's too large then it can be rejected before the email package attempts to parse it, and that would give the upstream LTMP client (i.e. your MTA) a better diagnostic. It still makes sense to put a size limit in your MTA so it never hits the LMTP server because the string will still be in the Python process's memory. But at least you won't pay the penalty for parsing such a huge message just to reject it later. >> Trying to find a way to look at the contents of the heap or at >> least limit >> its growth. >> Or is there not a way expire & restart mailman processes analogous >> to the >> apache httpd process expiration (designed to mitigate this kind of >> resource >> growth over time)? > > > bin/mailmanctl could be modified to do this automatically, but > currently only does it on command (restart) or signal (SIGINT), but I > gather you're already running a cron that does a periodic restart. This is a good idea. It might be better to do this in Runner._doperiodic(). - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkhrpt4ACgkQ2YZpQepbvXHAtgCgj0E1IJjf4kkv4TNKkzcB+RFF VxAAn1k01dLfPeKPcOgMxDneSyEB/5Ro =qiO5 -----END PGP SIGNATURE-----

1 0

Re: [Mailman-Developers] [Mailman-Users] Mailman 2.1.11 final has been released.
by Barry Warsaw 01 Jul '08

01 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 1, 2008, at 2:40 PM, Hank van Cleef wrote: > I'm also concerned about this proposed scheme to discontinue montnly > mailings. It most definitely needs some mechanism whereby a user can > reset or re-obtain their password without moderator intervention. Our > user base is just plain not password-savvy, and I'm concerned about > the increase in moderator workload if the recovery method is similar > to password resetting by root (the Unix method). Don't worry, going forward we'll have a fairly typical password reset feature instead of the monthly reminder. The other advantage of this is that we won't have to keep user passwords in our database unencrypted. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkhqfiIACgkQ2YZpQepbvXGgOACgphaPDxMRZ1E3bSO+NVVTqHxM 8ogAoKD9V1hQ18ZkTlHsAb0X7Ky5YVEr =cYvr -----END PGP SIGNATURE-----

1 0

Mailman 2.1.11 final has been released.
by Mark Sapiro 01 Jul '08

01 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am happy to announce the final release of the Mailman 2.1.11. Mailman 2.1.11 is a cleanup of a few problems found since the release of Mailman 2.1.10. It fixes the issue of shunted email subscribe requests and a few minor issues. It updates the contrib/mmdsr script for some 2.1.10 and 2.1.11 log and error messages, and it adds a new cron to cull and optionally archive old entries in the 'bad' and 'shunt' queues. Mailman 2.1.11 has updates to several i18n translations. A few bounce log messages now have the list name prepended. There is a new Defaults.py|mm_cfg.py setting ACCEPTABLE_LISTNAME_CHARACTERS with default value '[-+_.=a-z0-9]'. This Python regular expression character class specifies the characters allowed in list names. The motivation for this is the fact that previously, a list named, e.g., xxx&yyy could be created and MTA aliases generated that would cause the MTA to execute yyy as a command. There is a possible security issue here, but it is not believed to be exploitable in any meaningful way. If anyone is concerned about the security issue and not ready to upgrade, the mailman-2.1.11-listname-patch file contains a patch that can be applied to Mailman 2.1.9 or 2.1.10 to add this feature. See the release notes at <http://sourceforge.net/project/shownotes.php?group_id=103&release_id=605074> for more details. Mailman is free software for managing email mailing lists and e-newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, including download links, please see: http://www.list.org http://mailman.sf.net http://www.gnu.org/software/mailman Files in this release are: mailman-2.1.11.tgz <- The full release tarball mailman-2.1.11.tgz.sig <- GPG signature for the tarball mailman-2.1.11-listname.patch <- Patch to add new listname ~ validation to 2.1.9 or 2.1.10. ~ This patch is only applicable to ~ the older releases. mailman-2.1.11-listname.patch.sig <- GPG signature for the patch - -- Mark Sapiro <mark(a)msapiro.net> 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) iD8DBQFIaTDdVVuXXpU7hpMRApGpAKDXM56DmmpBY28+X6pN2sDpyyZltACgr3wm ePBR1weSHPYd1ViPCTc/L8o= =bV1I -----END PGP SIGNATURE-----

1 1