Mailman 3 January 2015 - Mailman-Developers

Re: [Mailman-Developers] X-Message-ID-Hash header (was Re: Python 3)
by Jeff Breidenbach 04 Jan '15

04 Jan '15

I should probably report the experience of mail-archive.com, which has supported a homebrew message-id hash algorithm for over 6 years. Only one organization has ever used it (LibreOffice). They put it in the Archived-At headers, not message footers. However, links did end up getting manually referenced in message bodies 575 times. Folks here might want to take a look at how people used it. Christian Lohmaier from LibreOffice is a good contact if anyone wants to talk to him directly. The homebrew has algorithm turned out to be a pretty bad design. Base-64 got us in trouble. One memorable bug involved hashes prepended with a minus sign. This caused havoc with the search engine resolving the links, who interpreted the minus sign as a negation operator. Blending the List-Post address into the hash was supposed to resolve crossposts. In practice it complicated things enough that LibreOffice incorrectly computed some of the hashes. There were also times when mail-archive.com wasn't doing that great a job either of running everything smoothly. Finally, we really get in trouble when asked to merge multiple archives, due to a mailing list migrating from server to server. It happens, and those migrations often change both List-Post and List-Id. Blending either into the hash is a headache. So the homebrew hash was dumb idea, and will gracefully retire in favor of the standard mailman hash algorithm. It was pretty neat to see some usage, though. And Archived-At still looks like a winner. Cheers, Jeff Alogithm: https://www.mail-archive.com/faq.html#listserver Usage: https://www.mail-archive.com/search?l=all&q=go.mail-archive.com

1 0

Re: [Mailman-Developers] Python 3
by Stephen J. Turnbull 03 Jan '15

03 Jan '15

Aurelien Bompard writes: > Barry writes: > > One of the advantages of accessing the core through the REST API > > is that it doesn't matter what clients like HyperKitty and > > Postorious are written in. > I'm not exclusively using the REST API though. I'm importing a > couple interfaces, mostly the archiver interface. This was a design mistake, I think. An IArchiver really needs to be in core for two reasons: first, it needs to generate a permalink and attach it to the message as distributed. Second, it needs to associate that permalink with the message so the "real" archiver process will do set that link correctly. For a production-quality archiver, that's *all* it should do. The archiver itself should be a separate process, receiving the message and permalink data by IPC. @Barry: maybe rename IArchiver to IPermalinker? ;-) Remember, Mailman core is going to be distributing Internet mail. Except in the case where 100.00% of the users are on one host, that's going to be the bottleneck on message processing. Archiving simply does not need to be fast. The archiver can implement LMTP even, although that would be overkill if we didn't already have an LMTP server. The simplest approach would be to simply put the Archive-Permalink header in the message and stream it to the archiver which would parse it out. > I'm also using the custom Message class a lot in the tests. Can't avoid that with Python 2, I guess, but using Message will be *so* much less painful with Python 3. > But I think the main problem is the import of mailman's config > object in the class that implements the IArchiver interface. I > don't believe there's another way to get the configuration. If you need that configuration (which, come to think of it, you probably do, at least parts of it), you could have a private protocol for communicating it as metadata (a message header or as metadata in the stream). > And now that I think of it, the archiver interface will be imported > by Mailman core, and will thus run with a Python3 interpreter. As a > result, all of KittyStore must at least be Python3 compatible. In the long run (ie, when nobody who's anybody uses Python 2 at all) I think everybody would be happier if you refactor to keep KittyStore at arm's length from Mailman core.

6 11

new wiki, get-togethers, and 3.0 blockers
by Sumana Harihareswara 03 Jan '15

03 Jan '15

Hi Mailman developers! I am becoming one of you :) and have gotten as far as a first patch.[0] Congrats on the new 3.0b5 release! A few questions: * I saw on http://wiki.list.org that we're in the process of moving to a new wiki, and I saw https://mail.python.org/pipermail/mailman-developers/2014-October/024001.ht… in which I heard that we're still in the process of finishing up the conversion. Is there anything you need to help make this happen? Money for SSL certs, wiki gardening time, or anything else I can help with? * I'd love to get to hack with some of you in person. Are any of you planning on going to the PyCon sprints in Montreal April 13-16? https://us.pycon.org/2015/community/sprints/ I live in New York City and can get to DC and Boston pretty easily in case anyone would like to have a little hacking weekend. * I saw in the https://mail.python.org/pipermail/mailman-developers/2014-November/024056.h… conversation that I should be looking at https://bugs.launchpad.net/postorius/+bugs?field.tag=mailman3-suite-blocker for Mailman 3 blockers. It looks like there are 13 blocker bugs left; is that still right? Thanks all! [0] https://code.launchpad.net/~sumanah/mailman/mailman/+merge/244077 -- Sumana Harihareswara http://brainwane.net

4 3