[Mailman-Developers] Signaling One-Click Functionality for List Email Headers
Greetings, I'm not sure if anyone has followed development of RFC 8058 "Signaling One-Click Functionality for List Email Headers" located at <https://tools.ietf.org/rfc/rfc8058.txt> and brought this topic up on this list. Is that something mailman(2|3) should support? To me it looks useful. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Building plug-ins for mailman.
Hi Aanand, * Aanand Shekhar Roy 2013...@iiitdmj.ac.in: Hi all, I am currently finding good plugin ideas that might make there way into mailman 3 system.I had discussed the same with @terri on irc.Some ideas i have already found good are: 1. DNS BlockList where would you put DNSBL support? On SMTP level? I'd let the MTA take care of it. On HTTP level? I'd let the HTTP take care of it. Sorry, if I sound harsh. I don't mean it. I just can't imagine where DNSBL would make sense without reinventing something that has been done yet. 2. Confirmation from user before posting phone nos in emails 3. SpamAsassin as it is I'd leave that to an MTA too, unless there's a non-SMTP way how mail enters mailman. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
* Stephen J. Turnbull step...@xemacs.org: Rajeev S writes: Also maybe you can try making your tool a little more smart? Like lets say I try to create a list abhil...@raj.com and there is no domain raj.com in the database, so instead of just showing error maybe you can ask the user: The domain raj.com does not exist, Do you want to create one? [y/n] I'm not sure I like this approach. Creating a domain should be a heavyweight operation, and eventually should include a bunch of sanity checks, like existence of domains and MX records. I have visions (nightmares) of users coming to us saying User: I said yes, but mail never arrives. Dev: Oh, is there a proper entry in the DNS? User: Doesn't Mailman create the domain? I doubt anyone that igorant of e-mail and how it works will ever make it to the MM3 command line client, but yes, such cases do exist. We should have public pillory that receives name, mail and date, whenever someone confirms the above question. ;) However I think the use case prepare Mailman to handle mail for a domain it doesn't handle mail for yet exists and we should find a way to deal with it. Perhaps we could improve this, if we used better wording that doesn't lead the operator to believe Mailman will connect a domain, setup DNS, do all the other foo and finally configure it self to handle mailing lists for that domain? Or maybe it could schedule a deletion after a pre-defined time with a reasonable default lets say 1 Day? And for an urgency(to delete) there Deleting a list/domain requires an (internal) scheduler. Does Mailman have one? A broom job that can be called via cron? could be --force argument? Deleting a list should be immediate, but I agree it should be confirmed. ... and it should be possible to pass the confirmation in the command to make it useful in scripts. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
* Stephen J. Turnbull step...@xemacs.org: Patrick Ben Koetter writes: I doubt anyone that igorant of e-mail and how it works will ever make it to the MM3 command line client, but yes, such cases do exist. I think they're actually likely to be reasonably common. However I think the use case prepare Mailman to handle mail for a domain it doesn't handle mail for yet exists and we should find a way to deal with it. Indeed. I'm suggesting that the routine could check the DNS and a few other things, and present the list operator with a TODO list. Sortof like check_perms. Where would you start with the TODO list? Where would you end? Deleting a list should be immediate, but I agree it should be confirmed. ... and it should be possible to pass the confirmation in the command to make it useful in scripts. Ooh, that is a very good point. Bessides possible, the syntax for doing that should be regular. I'm hopping in on this and I certainly missed most of the discussion on the command line client: Do we have interface guidelines for commands? Shortopts, longopts, interaction, non-interactive behaviour/requirements? I wonder about distinguishing yes to this prompt and yes to all? Me too. Probably scripts should not be using commands that need multiple confirmations, though. Hmmm, Unix: Do one thing. Do it well. ? -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] DMARC and Mail Lists open space at Pycon
* Mark Sapiro m...@msapiro.net: On April 11, 2014 3:18:13 PM EDT, Mark Sapiro m...@msapiro.net wrote: On 04/11/2014 05:25 AM, Mark Sapiro wrote: Tentatively rescheduled to 17:00 EDT (21:00 GMT) on Friday, 11 Apr in room 525. I will attempt to post realtime summaries on #mailman. Due to various scheduling issues, this will be rescheduled for Saturday evening (Montreal time). Details to follow. Please email me if you're thinking of attending. So far I know it's me, Florian Fuchs, and Barry Warsaw, but we need DMARC folks too. We are currently scheduled for 19:00 EDT (23:00 GMT), today, 12 Apr in room 525. It looks like it may just be Barry, Florian and me making dinner plans, but if you're interested and here please come. Yikes! That's 1:00 a.m. my time. Can't guarantee I will still be up then. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [Dmarclist] DMARC and Mail Lists open space at Pycon
* Mark Sapiro via Dmarclist m...@msapiro.net: On 04/11/2014 05:25 AM, Mark Sapiro wrote: Tentatively rescheduled to 17:00 EDT (21:00 GMT) on Friday, 11 Apr in room 525. I will attempt to post realtime summaries on #mailman. Due to various scheduling issues, this will be rescheduled for Saturday evening (Montreal time). Details to follow. Please email me if you're thinking of attending. So far I know it's me, Florian Fuchs, and Barry Warsaw, but we need DMARC folks too. Florian has Skype on his Laptop. I've asked him and we could have remote audio - sort of. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Git mirror for mailman
* Abhilash Raj raj.abhila...@gmail.com: Hi Patrick, I see you haven't updated the git mirror that you put up for mailman. I also did send you my public key off the list. Thanks a lot for your help. Terri sent a mail that discourages use of a GIT repo during GSoC. Barry wants a proxy. What I provided is a GIT repo that is not a read-only proxy. It does not fit either of the requirements. I'll see to provide a read-only proxy as soon as my time permits. Thanks a lot for your help. p@rick On Sun, Mar 9, 2014 at 1:30 AM, Patrick Ben Koetter p...@sys4.de wrote: * Abhilash Raj raj.abhila...@gmail.com: I was in a conversation with Barry yesterday to setup a unofficial git mirror for mailman since there are large number of people who use git as their primary vcs. I think it would encourage more people to contribute to mailman, if not through merge requests on lp, through small patches making of which is quite trivial in git I suppose. Seems we have an inofficial git repo now. Are there any opinions on who should be in control of the code, e.g. handle merge requests, etc.? AFAIK Barry has the last word on what gets to become Mailman 3 at the moment. I'd like to move on with the repo setup and clarify that. Thx p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/raj.abhilash1%40gmail.com Security Policy: http://wiki.list.org/x/QIA9 -- Abhilash Raj ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/p%40sys4.de Security Policy: http://wiki.list.org/x/QIA9 -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Git mirror for mailman
Hi, * Abhilash Raj raj.abhila...@gmail.com: Hi Patrick, excuse my ignorance: Is Raj your first name or Abhilash? On Saturday 08 March 2014 12:37 PM, Patrick Ben Koetter wrote: * Abhilash Raj raj.abhila...@gmail.com: Hi all, I was in a conversation with Barry yesterday to setup a unofficial git mirror for mailman since there are large number of people who use git as their primary vcs. I think it would encourage more people to contribute to mailman, if not through merge requests on lp, through small patches making of which is quite trivial in git I suppose. I am willing to maintain the mirror but I need I don't have a private server to host it. Anyone has ideas about how to setup? or already has a mirror running? How about this: https://project.sys4.de/public/projects/python/mailman Pulling should be easy: git clone https://src.sys4.de/python/mailman.git Thanks for this. Who will be the maintainer? That/these persons need an account and should contact me so I can give them access. I am willing to be a maintainer. Also can you tell me how to maintain I haven't maintained a project like this before? Does a cron job needs to setup to pull periodically? I will create an account for you and I will send the login data to you offlist. Do you PGP or anything alike? As for the workflow: Wars have been waged to etablish the right way [tm] to do this. I suggest whatever we do, make it easy to adopt or people will turn away because they need to spend too much work on project administration. The mailman repo is public. Anyone can pull a copy from it. If they want to contribute code/docs/..., they have to submit a merge request at https://project.sys4.de/python/mailman/merge_requests. Then its up to one of the developers to look at the new code and then to decide whether it should be merged or not. It's up to a developer or any more privileged role to conduct the actual merge. As for pulling: To my knowledge it is best practise to pull before you begin your work. Of course one should create a branch and work in that, so the code won't interfere with other changes, while you work on it. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Git mirror for mailman
* Abhilash Raj raj.abhila...@gmail.com: I was in a conversation with Barry yesterday to setup a unofficial git mirror for mailman since there are large number of people who use git as their primary vcs. I think it would encourage more people to contribute to mailman, if not through merge requests on lp, through small patches making of which is quite trivial in git I suppose. Seems we have an inofficial git repo now. Are there any opinions on who should be in control of the code, e.g. handle merge requests, etc.? AFAIK Barry has the last word on what gets to become Mailman 3 at the moment. I'd like to move on with the repo setup and clarify that. Thx p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Git mirror for mailman
* Abhilash Raj raj.abhila...@gmail.com: Hi all, I was in a conversation with Barry yesterday to setup a unofficial git mirror for mailman since there are large number of people who use git as their primary vcs. I think it would encourage more people to contribute to mailman, if not through merge requests on lp, through small patches making of which is quite trivial in git I suppose. I am willing to maintain the mirror but I need I don't have a private server to host it. Anyone has ideas about how to setup? or already has a mirror running? How about this: https://project.sys4.de/public/projects/python/mailman Pulling should be easy: git clone https://src.sys4.de/python/mailman.git Who will be the maintainer? That/these persons need an account and should contact me so I can give them access. p@rick P.S. If you like something else let me know. I can destroy the project space easily. -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] MM 3 and Postfix + Apache
* Tom Browder tom.brow...@gmail.com: Can I use essentially the same settings I used for Postfix and Apache for my MM 2 installation with MM 3? No, you can't. MM3 provides an LMTP Server. Configure a transport that routes messages for a mailing list to MM3's LMTP server. p@rick Thanks, -Tom ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/p%40sys4.de Security Policy: http://wiki.list.org/x/QIA9 -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2014 ideas list
* Florian Fuchs flo.fu...@gmail.com: On 02/07/2014 10:22 PM, Patrick Ben Koetter wrote: Dunno, if this is there yet, but a command line client for admins that allows to create lists, configure them via list templates, backup configs etc. would be a nice thing to have. +1! Maybe starting with a local version first (meaning: running on the same host as Mailman, with unrestricted REST API access -- I guess it might be enough work for one GSoC project to build a nice CL interface for the most important functionality). But with an option to add remote access with more advanced authentication/authorization at a later time. ACK Personally I would also like to see SNMP support to monitor mailman in larger installations. I'm adding it to the ideas page. Would you like to provide a short description of what you have in mind, so I can add that too? Unfortunately I am short on time. Here's a brief description: The idea is to add SNMP capabilities to MM. The SNMP interface should follow the FCAPS model http://en.wikipedia.org/wiki/FCAPS. What exactly that means for an MLM and MM in specific is something I'd expect the project to layout and implement (in parts). I would, for example, like to know how many mailing lists there are, how many people subscribed to each mailinglist, how many non-subscribed senders send to the mailinglist etc. pp. I can come up with a list of items to examine and count if this becomes a project. p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2014 ideas list
* Florian Fuchs flo.fu...@gmail.com: On 02/06/2014 08:21 PM, Barry Warsaw wrote: 2. A responsive ui for Postorius Very much +1. Another thought would be to support an app that you could install on Android or iOS (or Ubuntu Touch? :) to more directly control a Postorius server. Also a great idea! I think using Apache Cordova for that would be an interesting option. It's a native app container around a HTML/JS engine, so one can build native apps with HTML/CSS/JS. Supports Android, iOS and, yes, Ubuntu, plus a few others. I heard a lot of good things about it from a friend who has used it recently. Dunno, if this is there yet, but a command line client for admins that allows to create lists, configure them via list templates, backup configs etc. would be a nice thing to have. Personally I would also like to see SNMP support to monitor mailman in larger installations. p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman Suite beta: what's left?
* Terri Oda te...@zone12.com: -- SNIP -- Hopefully Florian and Stephen have better memories than I and can fill those in. Everyone else: anything you know that needs to happen before we can get a Mailman Suite beta out? Maybe documentation that tells interested people how they can start using the beta? p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Test: Please ignore
Are the mailman footer links HTTPS-Links? p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Adding DMARC support for Mailman 3
Greetings, I am writing on behalf of a group of companies and single persons, who would like to see a limited feature set of the DMARC¹ standard supported by Mailman 3. Since I know we're all eager to get MM3 out as soon as possible and any additional new feature request stands against that I've contacted Barry offlist and asked if he'd agree that the companies involved pay us, sys4², to implement the feature. He did and we also agreed to dedicate a significant part of the payment to mailman's FSF donation account. Before we take out to write code, I would like to ask mailman-developers how it should be done to fit best into Mailman's architecture. Here are the DMARC features that should go into Mailman 3: - don't allow email that comes from a domain with a DMRAC record of p=reject - take ownership of the email and send it with a From: using the domain of the mailing list. (There's a patch for this for Mailman 2.1, which might might be helpful for Mailman 3.) - find the authentication-results header and rewrite it as an Original-Authentication-header: http://tools.ietf.org/html/draft-kucherawy-original-authres-00.html Speaking of an RFC written by Murray Kucherawy. I've contacted Murray in advance and asked him to assist in case we had any questions regarding his RFC(s). He subscribed and ready to help. I hope I was able to bring all parties required together to make a Mailman DMARC implementation come true and I am curious to hear what you have to say. p@rick ¹) DMARC http://www.dmarc.org/ adds policies and more to DKIM, which gives digitally signed identity to sender domains and has become a cornerstone to reputation based mail management. Having DMARC support in Mailman 3 is - in my eyes - a reason for postmasters (not end-users) to upgrade their MM 2.x installation as soon as possible. ²) In case you ask yourself, who sys4 is: We've accompanied Mailman 3 development since Pycon in Chicago (in 2008 ?). Florian Fuchs, whom I don't have to introduce, works with us as well Ralf Hildebrandt and I. We, Ralf and I, are on the python.org postmaster team. Also with sys4 are Antoine Nguyen and Christian Roesser - both are exerienced Python programmers and both have spent significant time developing email applications. -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] About authentication (was Re: Architecture for extra profile info)
Richard, * Richard Wackerbarth r...@dataplex.net: Again, we agree. (Something must be wrong :) ) I think that it is important that we (the senior developers and mentors) assure that we maintain a structure whereby each of the student proposals can proceed at the same time. I believe you have been asked very politely not to continue this thread yesterday and give way for more pressing topics such as GSoC. Can you please do so? p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] anti-spam filter
* Ian Eiloart i...@sussex.ac.uk: On 15 Apr 2013, at 11:22, Stephen J. Turnbull step...@xemacs.org wrote: OTOH, a generic interface to the Mailman REST API, which could be used by Sendmail milters or whatever else is out there and somewhat standard (is it Postfix or Exim that can handle milters? I forget), with example implementation of a milter that checks whether the poster is subscribed by asking Mailman, would be useful as an extension to any MTA used with Mailman. I think Mailman supports SMTP/LMTP calls to discover whether a sender is permitted to post to a list, doesn't it? Exim doesn't handle Milters, but can do the calls forward. Provided Mailman is making the judgement, and issuing L/SMTP rejects at L/SMTP time before accepting the message, Exim is fine. It would be great if Exim as third MTA in the OSS troika of MTAs would. Content filtering *could* also be done at L/SMTP time. I think that where the Mailman and the MTA installations are managed by the same person or organisation, then the better place to have content filtering performed is at the MTA, but there might be exceptions to this. For example, a medical mailing list might want to be more liberal with regard to drugs that are commonly marketed in spam. Conversely, a list might have a particular subscriber demographic that makes it more sensitive to bad language. Or perhaps different lists might have different primary languages, and therefore different views on the value of messages in that language. ACK So, I can see that different lists on the same system might have different requirements for spam filtering. However, the solution is probably to provide hooks into Spamassassin, or another existing spam solution, and to provide ways that list owners can manage a configuration file on a per list basis. ACK. SpamAssassin knows how to apply different policies per recipient(domain). It is possible to provide policies via file config, SQL or LDAP. p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2013 - GNU Mailman - Introduction and Project Discussion
* Barry Warsaw ba...@list.org: On Apr 12, 2013, at 08:28 AM, Patrick Ben Koetter wrote: I think it would be real nice to have a MILTER interface at LMTP server level to allow mail modification as required. Mailman runs in large environments and all the 'large organizations' I have worked asked my team and me to customize how mail is processed. MILTER is a great interface to modify mail. Do you mean a hook in Mailman's LMTP server process? I thought about that in my previous message but decided not to mention it because it's not clear to me how performant Mailman's current smtpd-based (read: async) LMTP server is. What I mean is, I'm not sure how much additional work we want the LMTP server to do. It would be cool if someone did some performance testing of the LMTP implementation, and it would be cool if someone tried to add some hooks into that server. It might also be interesting to look into alternative implementations. Another reason to push for getting Mailman 3 onto Python 3 would be the ability to leverage Guido's Tulip work for better async IO performance. We did a quick test and blew 10.000 messages into Mailman 3's LMTP server. The hardware was/is a Pentium 2, 2 GB RAM machine with desktop discs - way below current server hardware. It took the test 25 min. to submit all messages: real25m10.041s user0m4.872s sys 0m7.700s That makes an average of 400 msg/min or 6,6 msg/sec Robert, who did the tests, Ralf and I agree that this is way enough for LMTP server performance. If we add a MILTER interface, the milter applications hooked into the LMTP servers receiving process will slow down the income rate. The impact depends on what the specific application tests or what kind of modification it applies to the message. In general MILTERs are designed to work in memory only. No message will need to be written to a disc, which usually is the most expensive operation during mail processing. At the moment we (at sys4.de) don't think it needs further testing, but we offer to do so if you have reason to do so. p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] anti-spam filter
* Pratik Sarkar iampratiksar...@gmail.com: Hi guys, Is the anti-spam/abuse filter still being seriously considered as a gsoc project this year? I - personal opinion - think adding a anti-spam/abuse filter is a good idea. I do however stronly oppose against a hardcoded implemenation that e.g. integrates SpamAssassin only or a new Bayesian filter. Why? (Please don't take this personal...) Reinvention I think it is a waste of time to reinvent (Bayes) something that has been there for many years. Proprietary implementation I also think it is no good service to those who will also want to expand Mailmans capabilities to do a product specific implementation instead of building a generic interface. I think, if Mailman should become able to filter spam and viruses, we should use a standardized interface (e.g. MILTER, SMTP/LMTP transport) that allows _any_ kind of mail filter to be hooked into the receiving process. Then anyone would be able to add their secret sauce when it comes to process email. This way the (new) Bayesian filter, which has been suggested on the list, could interface with Mailman too. p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] anti-spam filter
* Terri Oda te...@zone12.com: On 13-04-18 1:40 PM, Patrick Ben Koetter wrote: I - personal opinion - think adding a anti-spam/abuse filter is a good idea. I do however stronly oppose against a hardcoded implemenation that e.g. integrates SpamAssassin only or a new Bayesian filter. I hope that no one was seriously considering that level of hardcoding. What we are almost certainly talking about is setting up a handler (I think Stephen estimated this to be around 10 lines of code). And that handler would be - excuse my ignorance I don't program - a Python function to handle a Python program? Could the handler pass a message over to e.g. SpamAssassin (Perl) or openDKIM (c code) or any other non Python program without the need to add any additional (Python) code? p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] anti-spam filter
* Mark Sapiro m...@msapiro.net: On 4/18/2013 1:32 PM, Patrick Ben Koetter wrote: * Terri Oda te...@zone12.com: I hope that no one was seriously considering that level of hardcoding. What we are almost certainly talking about is setting up a handler (I think Stephen estimated this to be around 10 lines of code). And that handler would be - excuse my ignorance I don't program - a Python function to handle a Python program? Could the handler pass a message over to e.g. SpamAssassin (Perl) or openDKIM (c code) or any other non Python program without the need to add any additional (Python) code? In 10 lines? Maybe. If SpamAssassin is spamd, the Python socket module is part of the standard library. OpenDKIM includes a milter interface. There are Python milter shims available Perhaps your point is that this is more than 10 lines of code which is probably true, but interfacing to some specific spam filter plugin architecture from a Mailman chain rule module does not seem to me to be a big project. My original point was that we should use MILTERs because we shouldn't reinvent what already has been implemented very well and we shouldn't come up with a proprietary solution, because that will make it harder to expand Mailman and also less versatile as a tool. Let me add this too: I think we miss out some important customers if we stop at but you only need to add code to get what you want. Mail systems are created and run by postmasters in most cases. Even though there's a strong movement at the moment towards 'devops', the majority of sysops/postmasters can't program. If we stop at a programmable interface - which I understand is what you and Terri suggest - they will not be able to use Mailman in more complex setups, because integrating additional mail processing components would require them to program. I suggest to go further and add a MILTER because this way all customers involved - admins and developers - will get what they want/need: - Admins can check if there's a MILTER https://www.milter.org/ out there that already does what the mail processing chain needs. If there is, they connect Mailman and the MILTER via a well know interface (UNIX domain socket/TCP socket) and be done. No need to program. Configuration only. Most of the tools used in everyday postmastering provide a MILTER interface to interact with other mail processing components. - Developers will have full access (LMTP session data, mail header, mail body) to a message via the MILTER protocol. They can create their specialized application in any programing language that suits the job. As you said, Python brings (about 16) tons of code to get you started easily. p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] A feature I'd like to emphasize for GSoC ...
* Stephen J. Turnbull step...@xemacs.org: Paul Wise writes: On Tue, Apr 16, 2013 at 4:08 AM, Florian Fuchs wrote: This could be something for a HTML(5)/JS/CSS savvy person (to make it *really* convenient). I'm thinking scrollable log views, that interactively append/prepend entries to the view, depending on your position in the log file. Or commenting on log snippets and saving them for further review. As long these are based on progressive enhancement, sounds good. I think no thanks to interactive convenience, unless the candidate is *really* good at Zen Garden stuff (ie, won't need to spend any time thinking about progressive enhancement, let alone learning any CSS or JS). Convenience can only be realized if logs can be read and effective queries are easy for users to generate, and the replies are easy to understand, too. Let's leave Web2.0 stuff for next summer, please. Let me add some inconvenience: Log contains privacy related information. I'd expect a log view/research interface to limit output to what the person/role may look at and no more. p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Boilerplate and content filtering [was: Introduction and Project Discussion]
* Stephen J. Turnbull step...@xemacs.org: Sreyanth writes: Also, I would like to hear more about : Boilerplate stripper AND Better content-filtering / handling error messages. Boilerplate stripping is trivial to understand. But, can anyone elaborate on Better content-filtering / handling error messages? But boilerplate stripping is not necessarily trivial to implement, because it's not always clear what boilerplate is. I think it might be a good idea to save it off and provide a link rather than discard it, which leads to interesting questions of storage, shared links for true boilerplate (storage compression of repeatedly encountered text, yes, but more important the link will turn purple so you don't need to click on it in the next message from that user!), and user interface in general. Content filtering is mostly going to be about MIME handling: choice of the appropriate text/* part and things like that, removing images/video/etc where the list prohibits them, converting HTML/ wordprocessor attachments to plain text, removing MIME parts whose Content-Type doesn't match filename or perhaps file(1) magic in the content, etc. Just to mention it: IF we are going to add MILTER functionality, a MILTER would be perfect to do MIME handling. p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] anti-spam filter
* Stephen J. Turnbull step...@xemacs.org: Pratik Sarkar writes: Is the anti-spam/abuse filter still being seriously considered as a gsoc project this year? I would say so, yes. Personally, I am fundamentally opposed to it; I think it's wrong in principle (filtering of this kind should be done by the incoming MTA) and inappropriate for the 3.0 release. *But* there is clearly user demand for it, and among the actually signed-up mentors[1] there are at least two who have shown some support for it. OTOH, you should be aware that while nobody has a veto except Barry (Terri has one ex oficio but I doubt she'd exercise it if Barry was in favor), it's likely that projects that all the mentors favor will be ranked higher, and looking at the quality of posts from students so far there is going to be competition for Mailman slots. If you have a solid proposal for anti-spam already worked out (the idea the guy proposed with a Bayesian filter based on word triads comes close to what I'd call solid, see also Terri's post where she proposed a schedule for the kind of additional detail needed), then that's probably your best bet. But if you're looking for a project and you think that anti-spam is cool but that's all the thinking you've done so far, I'd say it's very risky proposal. There are a lot of things we need in UI (both subscriber-oriented and admin-oriented) that are interesting and higher-priority. Perhaps the integration could create an interface itself that makes it easy to add other filters in the future. I am thinking Postfix 'content filter', which uses SMTP/LMTP to send messages to an external filter and they send it back then using SMTP. The first Mailman content filter could be the one you proposed. Others could add their filter later. p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2013 - GNU Mailman - Introduction and Project Discussion
* Stephen J. Turnbull step...@xemacs.org: Sreyanth writes: 3. Anti-spam / anti-abuse in Mailman. A couple of people have mentioned anti-spam, and it's a frequently requested feature. Nevertheless, I don't think we should spend Google money and mentor time on it. I concur. 1. Mailman is the wrong place to do filtering. It's equally effective, normally covers more messages, and is somewhat more efficient in resource usage to do it at the MTA. Spam-filtering is expensive. It should be done only once - at sender level and not for each recipient of a mailing list. We could let Mailman do it when the mail enters, but what would be the gain? There's plenty of software out there that already knows how to battle spam. Even worse! In some countries - take Germany for example - you either reject spam at SMTP session level while the sending client is still there and will take notice or you MUST deliver it - else you break the law because you took reponsibility for transport, but supressed the message. Mailman is part of a mail system, but it I don't expect it will ever become the component that will communicate directly with a remote (spam sending) client. All the work to add an anti-spam feature in Mailman would be 'useless' to countries with laws as I described above. BUT ... I think it would be real nice to have a MILTER interface at LMTP server level to allow mail modification as required. Mailman runs in large environments and all the 'large organizations' I have worked asked my team and me to customize how mail is processed. MILTER is a great interface to modify mail. 2. Any new algorithms *should* be made available at the MTA level where they can be best put to use by more people. This implies something that either plugs into existing filters (such as spamassassin) or MTAs (ie, milters) rather than a Handler. 3. Adapting existing filters is generally pretty trivial: you write a 10-line custom Handler that pipes it to an external process. This isn't big enough for a GSoC project. 4. To the extent that new algorithms are involved, I have doubts that Mailman mentors have the kind of expertise needed to really help with such a project (I could be wrong, but I certainly don't know much about that kind of text processing, and I don't know that anybody else in Mailman has expertise in it). On the other hand, I don't know which project in GSoC would be a better place for it. It's possible to argue that Mailman is a reasonable place for it, but IMHO we probably shouldn't. I hate to stand in the way of someone, who wants to contribute to OSS, but IMHO we shouldn't either. Regarding anti-abuse, we would like to do something about problems like backscatter. However, I have to wonder how much *code* (vs *specification* and *design*) is needed for those problems. If the project is really spec-heavy, it's probably not really what Google has in mind (based on comments on the mentors' list, not on any official Google pronouncements, though). Has anyone ever mentioned SNMP as a feature for Mailman? p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2013 - GNU Mailman - Introduction and Project Discussion
* Barry Warsaw ba...@list.org: On Apr 12, 2013, at 08:28 AM, Patrick Ben Koetter wrote: I think it would be real nice to have a MILTER interface at LMTP server level to allow mail modification as required. Mailman runs in large environments and all the 'large organizations' I have worked asked my team and me to customize how mail is processed. MILTER is a great interface to modify mail. Do you mean a hook in Mailman's LMTP server process? I thought about that in Yes, I mean to hook MILTER capability into Mailman's LMTP server process. my previous message but decided not to mention it because it's not clear to me how performant Mailman's current smtpd-based (read: async) LMTP server is. It's not clear to me either, but now that you made me think about it I begin to ask myself how fast is fast enough and I also ask myself are we dealing with a bogey (had to look this up. hope it fits) or are trying to address a reasonable bottleneck. (I've experienced quite a few problematic situations in mail transport which turned out to be more driven by myth and oral history than by vested knowledge). I agree we should measure, just in order not to speculate, but let me send some thoughts ahead before we take out to test performance: - Input/output ratio on a mailing list system is 1:n. Performance requirements on the receiving side should be the least to worry about. - In most usage scenarios that come to my mind companies run an MLM as a supplement to their 'regular' mail system. Only a minor ratio of mail that enters the mail system is routed forward to the MLM (here: MM3 LMTP server). - At the moment (MM2) mail enters Mailman via a script that is called. Scripts are _a lot_ slower than a server process. My understanding is MM3 will have an LMTP server process. Any site that switches to MM3 should experience a performance boost on the receiving side. It seems to me most people will be off fine. Unfortunately I think most people will not need to use a MILTER, too. What characterizes the remaining group: - They run sites dedicated solely to mailing lists. - They need special filtering (read: MILTER and other methods). - They split load via clusters. - They have their own development teams to customize and optimize software as required What I mean is, I'm not sure how much additional work we want the LMTP server to do. How much should it be able to do at all? Do you collect and log statistics at the moment? Personally I like the delays=0.04/0.01/0.05/0.1 entry in Postfix's log. Quote from postconf(5): The format of the delays=a/b/c/d logging is as follows: · a = time from message arrival to last active queue entry · b = time from last active queue entry to connection setup · c = time in connection setup, including DNS, EHLO and STARTTLS · d = time in message transmission -- $ man 5 postconf | less +/delay_logging_resolution_limit It would be cool if someone did some performance testing of the LMTP implementation, and it would be cool if someone tried to add some hooks into that server. It might also be interesting to look into alternative implementations. Another reason to push for getting Mailman 3 onto Python 3 would be the ability to leverage Guido's Tulip work for better async IO performance. I'm short on time to do performance testing myself, but I'll forward the request to my team members since we are doing tests at the moment anyway. Maybe someone finds time to squeeze LMTP server testing in. My first idea would be to use either Postfix smtp-source (multi-threaded SMTP/LMTP test generator) or swaks (Swiss Army Knife for SMTP) http://www.jetmore.org/john/code/swaks/ and create a wrapper around it that produces the load. Has anyone ever mentioned SNMP as a feature for Mailman? Nope, but that would be interesting too. We (sys4) will contribute the MIB and monitoring server during development, if someone takes onto the programming. p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Mailing Lists and Non-ASCII Addresses
Just published a few minutes ago: http://www.rfc-editor.org/rfc/rfc6783.txt Probably worth to read before pushing MM3 out. p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Listadmin and other alternate interfaces for Mailman
Terri, Am 24.10.2012 08:27, schrieb Terri Oda: Since I now treat every gathering of hackers as an excuse to get people to tell me things about Mailman, I was chatting with folk at the GSoC mentor summit and my friend V was telling me that she really likes Listadmin as a nicer interface to Mailman: http://freecode.com/projects/listadmin Seems like something I might have to look at and learn some lessons from before we're done with postorius dev. first of all: I don't consider listadmin a contradiction to postorious. To me listadmin is simply another user interface to mailman for another user group - those that like to run (automated) commands from command line or prefer to work on command line (like I do). One of the great improvements of MM3 over previous versions is its REST interface. IIRC it was Pycon in Chicago when Barry, Florian and I discussed about the possibilities that come along with the REST interface. We came up with ideas like use a template to create and setup a mailinglist from command line, do a remote backup of list settings and subscriptions, include MM3 management in some sort of account provisioning. It's been a while since Pycon in Chicago and we might add smartphone app to deal with post requests or similar things one might want to do from an app. My favourite still is a command line interface to MM3 which I can run as a local REST client from wherever I am at the moment. p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich attachment: p.vcf___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Getting to Mailman 3.0 final
* Barry Warsaw ba...@list.org: On Sep 16, 2012, at 01:41 PM, Adam McGreggor wrote: Part of the attraction in using Mailman 2, was that, for the majority of tasks end-users want to do, they can do it via the web interface; certainly an advantage over those you have to do everything by email, in the proscribed manner, to the right address 'alternatives' (I say 'alternatives' as I don't think they're fit for non-geeks (and even some struggle with those). I would not roll-out Mailman 3 if there were not an end-users' web interface, at the very least for subscription management/alterations. Maybe now that the core is pretty close to what it will be like when released, we can get more volunteers to help test Postorius, and perhaps contribute to it? It would be cool if we could do a simultaneous release, but OTOH, the architecture of MM3 expressly encourages separation of the web ui from the engine. I think if we release MM3 without 'a frontend' we will miss people's expectation to get a feature complete MLM - which includes a frontend in most peoples opinion I guess. I do think that if we release them separately, we'll have to be very clear about setting expectations. I wouldn't do it. p@rick -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] translation of mail templates
* Mark Sapiro m...@msapiro.net: Peter Holzer wrote: Hi Aside of the actual translations being done... Can someone confirm that german umlauts and more or less exotic characters should work within the mail templates? Templates for web pages or pieces of web pages should have all non-ascii characters encoded as HTML entities, e.g. 'auml;', 'ouml;', etc. Seriously? Is there a particular reason we can't go UTF-8 and use 'ä', 'ö' the way they are written natively? Don't take it personal, Mark, but eversince I've been on the Internet I had to use a charset from a foreign language to create a crippled representation of my native language. If there's a chance to improve that I'd like to take it. Text templates for email messages, etc. can have non-ascii (exotic) characters as long as they are encoded in the character set that Mailman uses for that language. For Mailman 2.1 and German, this is iso-8859-1. Unfortunately, I'm not sure how this is working in MM3 in terms of how the various languages are registered and what the character set for German is (although most should probably be utf-8). For German most people nowadays use UTF-8. p@rick -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] translation of mail templates
Peter, there should be German translations that come with Mailman 2. Which ones are you trying to translate? p@rick Am 20.08.2012 09:18, schrieb Peter Holzer: Hi I started to translate the templates into german, resulting in some nasty unicode errors. Is there a howto on how the translation for other languages has to be done? Peter ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/p%40state-of-mind.de Security Policy: http://wiki.list.org/x/QIA9 -- state of mind () Digitale Kommunikation www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht München Partnerschaftsregister PR 563 smime.p7s Description: S/MIME Kryptografische Unterschrift ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] translation of mail templates
* Barry Warsaw ba...@list.org: On Aug 20, 2012, at 06:22 PM, Peter Holzer wrote: I just took the english templates from MM3 and started to change them. Are the templates the same as in MM2? Anyhow do i have to configure something in MM3 to make these templates work? The i18n infrastructure is probably not complete in mm3, although the basic should work. We don't really have good extraction of the messages, and we're still undecided on what service, or how, to manage translations. There are lots of options, but what I think really needs to happen is for someone to really take ownership of i18n for mm3. I'm happy to help with the technical side of the core, and the Postorius folks will help with the Django side, but I think we need someone who is really involved in translations to evaluate our options and drive the technical discussion forward. I am not the one to tell about the technical issues, but I can tell https://www.transifex.com works well for Modoboa http://modoboa.org/en/. They have free accounts for open source projects. It might be a nice way to organize a translation community. p@rick -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] mailing list to work with ADSP and DMARC
Frank, * Franck Martin fra...@peachymango.org: As I have not received feedback.. then no feedback is good feedback right? I submitted the code to be merged into main branch (using launchpad interface). It is 2.1.x branch and I know the development happens on 3.x, but let me know the status and if I should try to do a branch in 3.x code base in a view to submit a similar patch. ADSP is considered to be broken and marked deprecated. DMARC is its successor and on the rise. Currently DMARC is undergoing interop testing. It is said to advance towards IETF standard sometime in autumn. You might just be a little too early and you might work on the wrong code. On Mailman-Developers currently most discussions deal with/most efforts are put into MM3 development. My bet is you will receive more feedback if you start implementing DMARC relevant features into MM3 code. If you get Murray Kucherawy, I don't know if he's still on the list, to contribute/share ideas on DMARC you will very likely get a bulletproof implementation - he's one of the driving forces behind DMARC. p@rick - Original Message - From: Franck Martin fra...@peachymango.org To: mailman-developers mailman-developers@python.org Sent: Tuesday, July 10, 2012 9:45:28 PM Subject: [Mailman-Developers] mailing list to work with ADSP and DMARC I did a branch on the 2.1 series to test rewriting the From: header to be able to make emails to comply with DMARC and ADSP You can find the branch here: https://code.launchpad.net/~mlm-author/mailman/2.1-author and the diff with mailman main branch here: http://bazaar.launchpad.net/~mlm-author/mailman/2.1-author/revision/1340?start_revid=1340remember=1338compare_revid=1338 I have also a test mailing list running at: http://lists.peachymango.org/mailman/listinfo/mlm-auth The best to see how it works is to subscribe, send an email, and see how the email is distributed. I guess you need to receive an email to see that... I'll reply... Several ways to solve this problem were explored with mailman: http://wiki.list.org/display/DEV/DKIM I took a 7th option which is to rewrite the From: without using the + and put the information about the sender in the Reply-To: This may not be optimum but it works. Overall this solution is one out of 3 ways to get mailing lists running with DMARC (see DMARC FAQ) 1) don't break DKIM 2) use AOR 3) rewrite the from There is another one which is to whitelist emails coming from mailing lists Also note that while I'm involved in the DMARC group, I do this code as a personal project. Now send comments, and be nice with me :P ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/franck%40peachymango.org Security Policy: http://wiki.list.org/x/QIA9 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/p%40state-of-mind.de Security Policy: http://wiki.list.org/x/QIA9 -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] mailman3 instance for preview + exploration
* Jeff Breidenbach j...@jab.org: Hello mailman-developers, I suspect that there are folks who would like to see what Mailman 3 and particularly Postorius without going through the effort of software installation. Jeff Marshall was kind enough to set up a test instance that people can look at and play with. This is a temporary setup so don't use for anything real. Also try not to spam anyone as we'll take it down at the first sign of trouble. I hope this helps with the development process. Cheers, Jeff === http://mailman3.jab.org:8000/ [Errno 111] Connection refused -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2012] Metrics
* Patrick Ben Koetter p...@state-of-mind.de: let me throw in some thoughts just to annoy you ;) Like with most statistical data I mostly see the figures being used to give statements on quantity - top poster, number of threads etc. Do you think it would be possible to also make some statements on quality? Let me give an example: Mailing lists are often places where people go to ask for advice. Someone asking usually starts a thread and continually keeps replying. That easily makes a person top poster and might make the same person a thread starter, but number of posts and threads started gives no indication of that persons knowledge (concerning the mailing lists topic). OTOH someone who has been on the list for ages, who replies more often than starting threads and who ends threads often after she has replied might very well be a very knowledgeable person, because she gives the one answer that solves the problem. Do you think it would be possible to deduct such quality oriented statements? As a follow-up: I just stumbled across http://www.mentby.com/patrick-ben-koetter/, which is nice because it also gives an overview over all (here: some) mailing lists an identity posts to. The second pie chart seems to try to say something about quality. It splits posts in 'relevant' and 'passive', which are not exactly opposites, but well … Actually I'd say they still need to work on their rating: http://www.mentby.com/barry-warsaw/ ;) p@rick -- state of mind () Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Speaking about kitties (or archivers)
* Barry Warsaw ba...@list.org: On Jun 02, 2012, at 07:19 AM, Patrick Ben Koetter wrote: Maildir is robust but it doesn't scale under high load. You can add indexes, but they are limited sooner or later too. Concerning mailbox formats Timo Sirainens current approach to collect a limited number of messages in one file and then start a new one combines the best of both worlds - mbox and maildir - in mdbox http://wiki2.dovecot.org/MailboxFormat/dbox. Con It takes an index to know in which files a message is located. Pro A magnitude faster to backup, which I would keep an eye on because mailing list archives tend to be large and backing up a directory of small files is a well known performance killer. I can get you in contact with Timo if you like to. I've chatted with him a few times (I'm a Dovecot user and fan). +1 Would someone like to take a crack at implementing this format either in, or on top of, the Python stdlib mailbox module: http://docs.python.org/library/mailbox.html I'd much rather use something standard (and maintained by someone else!) than a bunch of custom code specific to Mailman. Speaking of standards. I discussed this with Timo in private mail and he suggests not to use mdbox directly. It is still under development and he thinks it should not become a standard format like mbox or maildir. To quote Timo from our conversation: I'd prefer using mdbox via Dovecot itself, either via LMTP or dovecot-lda or maybe by adding some doveadm save command. Anything else I think would be problematic. Even using Dovecot's library for accessing mdbox would be problematic in some installations if you didn't also read several settings from dovecot.conf (e.g. lock_method). Note: The 'doveadm save' command above refers to an idea where dovecot would import to be archived messages from a MM3 mailing list into Dovecot (and whatever format has been definded for the mailbox). Maybe - and to pick up an idea Barry had mentioned to me a long time ago about mailing list management directly from a mail client - we would gain the most if we implemented an LMTP client as archiver (better: archive transport). This would introduce the chance to choose among many LMTP servers and their specific, optimized storage format (Dovecot - mdbox, Cyrus IMAP - ?) including their servers various IMAP SEARCH capabilities for searches in archives. p@rick -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Speaking about kitties (or archivers)
* Barry Warsaw ba...@list.org: On Apr 24, 2012, at 01:41 PM, Stephen J. Turnbull wrote: IMHO, premature optimization. Among other things, there isn't going to be a the archiver-core. Mailman should provide a archiver-core, and I think it should be based on maildir (which is apparently Barry's intuition, too). Theory and implementation of maildir are simple and robust, and that allows us to concentrate on the archiver interface. In fact, the prototype archiver already implements maildir storage. This storage isn't exposed via REST yet though. Maildir is robust but it doesn't scale under high load. You can add indexes, but they are limited sooner or later too. Concerning mailbox formats Timo Sirainens current approach to collect a limited number of messages in one file and then start a new one combines the best of both worlds - mbox and maildir - in mdbox http://wiki2.dovecot.org/MailboxFormat/dbox. Con It takes an index to know in which files a message is located. Pro A magnitude faster to backup, which I would keep an eye on because mailing list archives tend to be large and backing up a directory of small files is a well known performance killer. I can get you in contact with Timo if you like to. p@rick -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] need tutorial for setting up python development environment on Ubuntu please
* David d...@fiteyes.com: On Fri, May 4, 2012 at 4:22 PM, Barry Warsaw ba...@list.org wrote: On May 04, 2012, at 02:10 PM, David wrote: Now start up Mailman, your MTA Good up to that point. What is the method for generating aliases for Postfix in Mailman 3? This has changed im MM3. Postfix now delivers ML mails to MM3 via LMTP. - http://wiki.list.org/display/DEV/LMTP+process -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Pycon 2012 sprint start time
* Barry Warsaw ba...@list.org: Pycon 2012 sprinters, I will probably be in the sprint room by 9:30am tomorrow, but we won't officially start until 10am. Looking forward to seeing everyone there! Wish I was there! Greetings from Cologne, Germany. :) p@rick -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Header cleanup/unnoticed header
Given our recent discussions on header cleanup for MM3 I noted another x-header that went unnoticed: x-mas: Sat, 24 Dec 2011 07:43:57 +0100 Should we standardize that too? ;) p@rick -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] [internet-dra...@ietf.org: [EAI] I-D Action: draft-ietf-eai-mailinglistbis-01.txt]
FYI - Forwarded message from internet-dra...@ietf.org - Date: Thu, 15 Dec 2011 15:33:54 -0800 From: internet-dra...@ietf.org To: i-d-annou...@ietf.org Cc: i...@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-mailinglistbis-01.txt Authentication-Results: mail.state-of-mind.de (amavisd-new); dkim=pass header.i=@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Mailing Lists and UTF-8 Addresses Author(s) : John Levine Randall Gellens Filename: draft-ietf-eai-mailinglistbis-01.txt Pages : 8 Date: 2011-12-15 This document describes considerations for mailing lists with the introduction of internationalized email addresses. It outlines some possible scenarios for handling lists with mixtures of internationalized and traditional addresses, but does not offer implementation or deployment advice. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-mailinglistbis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-eai-mailinglistbis-01.txt ___ IMA mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/ima - End forwarded message - -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman headers roundup
* Barry Warsaw ba...@list.org: X-Mailman-Version The version of Mailman that sent the message. It can lose the X- prefix. Modify to: List-Agent, Mediator Next Step: Discuss I like List-Agent much more than User-Agent, since Mailman is only tenuously under any control of the user. I like having this header under the List- prefix, so I Mediator doesn't appeal to me. Here's why I would prefer Mediator: What we want is a header field name that indicates the message has been accepted, modified and forwared by a program. The header field name 'List-Agent' does that, but it is specific to mailing lists. The term 'Mediator' describes the same, but it is general in meaning. Any instance modifying and forwarding a message can use it. If we use List-Agent others will have to register another header field name - 'Mediator' would fit for all. p@rick -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman headers roundup
* Barry Warsaw ba...@list.org: Thanks for coordinating this Patrick. On Oct 30, 2011, at 08:04 PM, Patrick Ben Koetter wrote: X-List-Received-Date This only gets added when the message is sent to the archive. Modify to: List-Archive-Sent Next Step: Discuss List-Archive-Sent (maybe with -Date) makes sense to me. This really is different than Received headers IMO since it's not recording any receiving event in Mailman. To the extent that it's useful to know when an MLM sends the message to its archivers, getting the direction right seems important. The question in my mind is what to do about the case where, as in MM3, we have multiple archivers. Multiple L-A-S headers should be allowed, but then I wonder whether the headers need to record which archiver the header applies to. TBH, in MM3 when we send to one archiver, we send to them all so I'm not sure the extra complexity is worth it. I also don't know whether any other MLM supports multiple archivers. X-Message-ID-Hash propose an RFC as an extension of RFC 5064 Modify to: unclear Next Step: Discuss As an RFC, obviously we'd drop the X- prefix, but also Hash might be too vague. Personally I think Message-ID-Hash is fine and the theoretical RFC shouldn't allow much leeway in implementations (i.e. only one hash algorithm is allowed). This will probably be bikeshedded to death. Still, since Message-ID must be unique (and generally is, as backed up by The Mail Archive's data), I think base-32 of SHA-1 will in practice be just fine. As a sidenote: Postfix 2.9 will introduce longer Message-IDs because a Message-ID is only stable while the message is in the server (queue), but it may be reused immediately after the first message had been delivered - that's RFC compliant. This has caused problems with long time log analysis software and archival and that's why Postfix 2.9 will offer longer Message-IDs (read also: Queue-IDs). X-Mailman-Version The version of Mailman that sent the message. It can lose the X- prefix. Modify to: List-Agent, Mediator Next Step: Discuss I like List-Agent much more than User-Agent, since Mailman is only tenuously under any control of the user. I like having this header under the List- prefix, so I Mediator doesn't appeal to me. One last attempt: Using List-Agent only creates an agent instance that can be used by MLM software. Using Mediator will creat an Agent that can be used by any software that processes mail. X-Mailman-Approved-At lose the X-prefix Modify to: List-Approved-Date Next Step: Create RFC or Extend RFC 2369? To generalize, it might be useful to have List-Moderation-Action and List-Moderation-Date headers. The former would have values like Approved, +1 Held, Rejected, or Discarded, while the latter would have the date of the disposition. Seemingly useless actions like Discarded and Held would still be useful because even a discarded message may end up in some email graveyard for future data mining. II. MODIFY X-Mailer Only used when Mailman originates messages such as autoresponses. Modify to: User-Agent Next Step: Change code Similar to the above, I don't like User-Agent much here. I think this could be simply folded into List-Agent since there are probably plenty of other header clues to know that a message was originated by Mailman. X-Topics This contains a list of all the topic names that matched the message. Are there any other MLMs that support topics in a way that would make that header generally useful? Modify to: Tag Next Step: Create RFC I think someone suggested Keywords, and as much as I'd like to use that one, I don't think it's feasible. Existing Keywords headers are used as input to the topic tagger so it can't be re-used. List-Topics seems fine to me, but other possibilities include List-Tags, List-HashTags, or List-Keywords. Lets settle for List-Topics. If someone wants to compare e.g. with their social network, forum ... they will have to create a mapping. This will work too. X-Mailman-Rule-Hits They could certainly lose the X- prefix. Modify to: Mailman-Rule-Hits Next Step: Create RFC X-Mailman-Rule-Misses They could certainly lose the X- prefix. Modify to: Mailman-Rule-Misses Next Step: Create RFC These are all pretty specific to the Mailman implementation so dropping the X- should be enough. No RFC needed. Okay. X-Content-Filtered-By I think this should be renamed to (X-)Mailman-Content-Filter. Modify to: Mailman-Content-Filter Next Step: Create RFC The only utility of this header is to notify the recipients that the original message has been altered by removing MIME parts. OTOH, I think it's pretty much understood that messages flowing to mailing lists are subject to considerable modification. Certainly
[Mailman-Developers] Mailman headers roundup
I've created a list to sum up the current discussion/threads on the mailman header work. The list is separated in four sections: I. CLARIFY Needs discussion. II. MODIFY Needs to be registered with IETF or changes X- name. III. KEEP Do not change VI. DELETE Remove from MM3 code Please cross-check and pickup discussion on the CLARIFY items. Once we are done I will approach IETF for the headers that need standardizing. I. CLARIFY X-List-Received-Date This only gets added when the message is sent to the archive. Modify to: List-Archive-Sent Next Step: Discuss X-Message-ID-Hash propose an RFC as an extension of RFC 5064 Modify to: unclear Next Step: Discuss X-Mailman-Version The version of Mailman that sent the message. It can lose the X- prefix. Modify to: List-Agent, Mediator Next Step: Discuss X-Mailman-Approved-At lose the X-prefix Modify to: List-Approved-Date Next Step: Create RFC or Extend RFC 2369? II. MODIFY X-Mailer Only used when Mailman originates messages such as autoresponses. Modify to: User-Agent Next Step: Change code X-Topics This contains a list of all the topic names that matched the message. Are there any other MLMs that support topics in a way that would make that header generally useful? Modify to: Tag Next Step: Create RFC X-Mailman-Rule-Hits They could certainly lose the X- prefix. Modify to: Mailman-Rule-Hits Next Step: Create RFC X-Mailman-Rule-Misses They could certainly lose the X- prefix. Modify to: Mailman-Rule-Misses Next Step: Create RFC X-Content-Filtered-By I think this should be renamed to (X-)Mailman-Content-Filter. Modify to: Mailman-Content-Filter Next Step: Create RFC III. KEEP X-Peer X-MailFrom X-RcptTo Ignore this, it's used in the test suite only. Next Step: Ignore X-Originally-To Probably not worth changing. Next Step: Ignore X-Original-CC X-Original-Content-Transfer-Encoding X-MIME-Version Ignore these. Next Step: Ignore X-Ack X-No-Ack These should keep the X- prefix. Next Step: Ignore X-Approve X-Approved need to keep the above two for backward compatibility Next Step: Ignore VI. DELETE X-Mailman-Copy It can either be removed or lose the X- prefix. Next Step: Remove from code X-BeenThere legacy Next Step: Remove from code X-Archive X-No-Archive deprecated Next Step: Remove from code X-List-Administrivia X-List-Administrivia is just useless and should be removed. Next Step: Remove from code p@rick -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman headers roundup
* Murray S. Kucherawy m...@cloudmark.com: -Original Message- From: mailman-developers-bounces+msk=cloudmark@python.org [mailto:mailman-developers-bounces+msk=cloudmark@python.org] On Behalf Of Patrick Ben Koetter Sent: Sunday, October 30, 2011 12:04 PM To: Mailman Developers Subject: [Mailman-Developers] Mailman headers roundup I've created a list to sum up the current discussion/threads on the mailman header work. [...] Nice! Thanks. For the ones that are at Create RFC, does someone have a specific syntax they should follow, especially something like ABNF? That plus a description makes crafting the RFC easy. My impression is we need to settle User-Agent, List-Agent and/or Mediator first. Then, at least that's my plan, I would start to collect/write descriptions, syntax, ABNF etc. p@rick -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] New RFC on using DKIM with MLMs
I've begun to sort the various comments into a list that sorts all changes in categories like 'decide', 'delete', 'modify', 'keep'. I will send it to mailman-developers@python.org once I've clarified a few header fields. As a reference I looked for existing list-relevant header fields in RFC 2369 http://www.rfc-editor.org/rfc/rfc2369.txt, which doesn't seem to have seen an update in a while. All my comments to List-* headers refer to RFC 2369. Please find them below including some minor nitpicking at the end. * Barry Warsaw ba...@list.org: On Oct 27, 2011, at 02:29 PM, Ian Eiloart wrote: Note that I responded in the context of Mailman 3. We have an opportunity there to clean that all up, but it probably isn't a good idea to radically change these for MM2. ACK. I'd keep MM2 as it is and introduce changes for MM3 only. From Mailman/Handlers/CookHeaders.py: msg['X-Mailman-Version'] = mm_cfg.VERSION Seems to add the product version and not the User-Agent. Yes, but a User-Agent, header would have the product and the product version. A List-Agent header should do the same. List-Agent is not a bad idea. It's not available in RFC 2369. We will have to propose 'List-Agent' as a new standard. Should we? X-Mailman-Approved-At From Mailman/ListAdmin.py: # Queue the file for delivery by qrunner. Trying to deliver the # message directly here can lead to a huge delay in web # turnaround. Log the moderation and add a header. msg['X-Mailman-Approved-At'] = email.Utils.formatdate(localtime=1 So, I guess that the web moderation works by adding this header, so that the message can be delivered when the queue runner sees it. It looks like useful trace information, so it should stay. This also looks like a candidate for, say, a List-Approved-Date header. It's not available in RFC 2369. We will have to propose 'List-Approved-Date' as a new standard. Should we? From Mailman/Handlers/Tagger.py: # For each regular expression in the topics list, see if any of the lines # of interest from the message match the regexp. If so, the message gets # added to the specific topics bucket. So, is this used by Mailman to decide who to send the message to? Or is it supposed to help recipients to build filters. Either way, it might be useful for the latter purpose. Perhaps it's a candidate for List-Topics? Are there any other MLMs that support topics in a way that would make that header generally useful? Not that I am aware of. But maybe we could give it a more generic view. I could imagine calling them 'Tags', which would make them usable in any protocol that sends headers. From the changelog: The archived copy of messages grows an X-List-Received-Date: header indicating the time the message was received by Mailman. # Always put an indication of when we received the message. Seems to decide where messages should be archived I think that's a candidate for a List-Archived-Date header. Because that's potentially helpful for people looking to find the message in an archive. Possibly so, if it's a header added by the MLM. E.g. an archiver might have its own archive date value so it would either have to chose a different header, or use multiple instances (with the loss of fidelity). When I read 'List-Archived-Date' I understand it specifies the date the message had been archived by some archival software and not the date is was sent to the archive by an MLM. That makes a difference to me because copying the message to an archive might not be the only way to transport it there. The MLM might as well use an LMTP transport and queue it up for delivery. The queued message might get stuck in a delivery queue for hours. Being able to tell the difference between 'sent off to' and 'stored at' might be very useful to a postmaster when debugging archival problems. Choosing a more specific header field would probably also avoid getting into an archivers way when it creats an archive date value as Barry mentioned above. Not sure. Am I overly pedantic on this? p@rick -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] New RFC on using DKIM with MLMs
* Barry Warsaw ba...@list.org: On Oct 28, 2011, at 10:36 PM, Patrick Ben Koetter wrote: From Mailman/Handlers/CookHeaders.py: msg['X-Mailman-Version'] = mm_cfg.VERSION Seems to add the product version and not the User-Agent. Yes, but a User-Agent, header would have the product and the product version. A List-Agent header should do the same. List-Agent is not a bad idea. It's not available in RFC 2369. We will have to propose 'List-Agent' as a new standard. Should we? I think it makes sense to have a header identifying the MLM that the message flowed through, and List-Agent seems like a good choice. Let me merge Stephen's comment from 87obx04ocb@uwakimon.sk.tsukuba.ac.jp to stick with a more generic term such as 'User-Agent'. While I disagree with having Mailman be a User-Agent, I can't actually say there are useful semantics to having a separate List-Agent. Nor do I see a real problem with having multiple User-Agent headers, if multiple agents have handled the message. I agree with Stephen that List-Agent is too specific leaving no semantic room for other types of message processing software. At the same time I think User-Agent is not apt, because RFC 1945 defines a User-Agent as originator, which is not the case with any MLM - it distributes a message which originated somewhere else: The User-Agent request-header field contains information about the user agent originating the request. -- http://www.ietf.org/rfc/rfc1945.txt I suggest we use the term 'Mediator' as introduced by D. Crocker in RFC 5598 http://www.rfc-editor.org/in-notes/rfc5598.txt instead: A Mediator attempts to preserve the original Author's information in the message it reformulates but is permitted to make meaningful changes to the message content or envelope. A Mediator's role is complex and contingent, for example, modifying and adding content or regulating which Users are allowed to participate and when. The common example of this role is a group Mailing List. (see section 2.1.4. Mediator and also section 5. Mediators) A 'Mediator' would leave the original User-Agent intact AND tell the message had been processed by another mail handling service AND it would allow for other Mediators to be added in case more mail processing was done after an MLM's (here: Mailman) job. X-Mailman-Approved-At From Mailman/ListAdmin.py: # Queue the file for delivery by qrunner. Trying to deliver the # message directly here can lead to a huge delay in web # turnaround. Log the moderation and add a header. msg['X-Mailman-Approved-At'] = email.Utils.formatdate(localtime=1 So, I guess that the web moderation works by adding this header, so that the message can be delivered when the queue runner sees it. It looks like useful trace information, so it should stay. This also looks like a candidate for, say, a List-Approved-Date header. It's not available in RFC 2369. We will have to propose 'List-Approved-Date' as a new standard. Should we? I also think it makes sense to have a date header marking the time when the message was approved. This implies of course that the message was held for moderation. Would there be a L-A-D header if the posting was automatically accepted? Maybe the header should be List-Posted-Date, although there some subtly different semantics implied by that. E.g. if the date the message was approved isn't quite the date the message was posted (idk, some delay from moderator acceptance to actually posting through the MLM). Hmm, if there are no intermediate processes between receiving a message and approving it a List-Approved-Date seems fine. But if there are we run into the same problem as described below with List-Archived-Date - you can't tell when it was queued and when processing took place. Adding a second header might make the useful distinction: List-Received-Date RFC 2822 date timestamp when message was received by MLM List-Approved-Date RFC 2822 date timestamp when message was approved by moderator Another header that might be useful here would be List-Approved-By which could be the name or email address of the moderator who approved it. Right now, MM3 doesn't fill that in, and it could of course be filled in by say list-ow...@example.com, but in MM3 it could be potentially filled in with the preferred address for the moderator that approved it. I see the benefit because it helps if you moderate in a team. But I fear the anger of people whose postings we decline. They search for moderator identities and then start molesting them e.g. by subscribing them to mailing lists that don't require opt-in. (Happend to me python.org postmaster. The angry person subscribed my address to various pr0n mailing lists and it took me weeks to get unsubscribed.) All
Re: [Mailman-Developers] New RFC on using DKIM with MLMs
I searched mailman 2.1.14 sources and changelog to find out what they stand
for. Read below. Which could/should we replace with already existing
standardized headers?
* Ian Eiloart i...@sussex.ac.uk:
On 25 Oct 2011, at 02:04, Barry Warsaw wrote:
On Oct 13, 2011, at 11:41 PM, Murray S. Kucherawy wrote:
There's movement afoot to deprecate use of X- in header field names.
Just
call it Mailman-Topic. And if it's worthwhile, consider registering it
with IANA.
I wonder if we should remove the X- prefixes for Mailman 3. Here's a list
of
ones we still add or recognize (some might be used only in the test suite):
X-Message-ID-Hash
This could be replaced with DKIM sigs, I guess.
X-Mailman-Rule-Hits
X-Mailman-Rule-Misses
This might be useful for diagnostics, but probably wants to be off in
general. My view is that Mailman should not be doing message filtering.
Are they related to SpamAssassin filtering that can take place in MM?
X-BeenThere
I guess that's useful for avoiding list loops, perhaps?
From Mailman/Handlers/CookHeaders.py:
# Mark message so we know we've been here, but leave any existing
# X-BeenThere's intact.
X-Mailman-Version
I think this should be replaced with X-Mailer, or even User-Agent. That's
not currently an SMTP header, but I think it should be. And it is in quite
widespread use.
From Mailman/Handlers/CookHeaders.py:
msg['X-Mailman-Version'] = mm_cfg.VERSION
Seems to add the product version and not the User-Agent.
X-Mailman-Approved-At
From Mailman/ListAdmin.py:
# Queue the file for delivery by qrunner. Trying to deliver the
# message directly here can lead to a huge delay in web
# turnaround. Log the moderation and add a header.
msg['X-Mailman-Approved-At'] = email.Utils.formatdate(localtime=1)
X-Archive
Does this do the same as List-Archive?
Looks like a control feature for senders:
From doc/mailman-admin.txt:
Note that senders can control whether their own posts are
archived, on an individual per-message basis. If the posted
message has a X-No-Archive: header (regardless of value), or a
X-Archive: header with a value of No (case insensitive), then
the message will not be archived, although it will be treated
as normal in all other ways.
From the changelog:
o When a moderated message is approved for the list, add an
X-Mailman-Approved-At: header which contains the timestamp
of the approval action (changed from X-Moderated: with a
different format).
- Honor X-Archive: No header by not putting this message in the
archive.
X-No-Archive
What does this mean?
Seems like a dupe from X-Archive:
From the changelog:
o Just the mere presence of an X-No-Archive: is enough to
inhibit archiving for this message; the value of the header
is now ignored.
X-Ack
From the changelog:
- Autoresponses, -request command responses, and posting hold
notifications are inhibited for any message that has a
Precedence: {bulk|list|junk} header. This is to avoid mail
loops between email 'bots. If the original message has an
X-Ack: yes header, the response is sent.
X-No-Ack
Is this still being used?
Nothing in the changelog
Nothing in the mailman-2.1.14 sources.
X-Peer
Is this still being used?
Nothing in the changelog
Nothing in the mailman-2.1.14 sources.
X-MailFrom
Is this still being used?
Nothing in the changelog
Nothing in the mailman-2.1.14 sources.
X-RcptTo
Is this still being used?
Nothing in the changelog
Nothing in the mailman-2.1.14 sources.
Isn't that usually in the Received header?
X-Originally-To
Doesn't that do the same thing as List-post?
Seems like a copy of Postfix' X-Original-To-header. Is it?
From cron/gate_news:
del msg['X-Originally-To']
msg['X-Originally-To'] = msg['To']
X-Original-CC
What's the purpose of including this?
From Mailman/Defaults.py.in:
# Next, these headers are left alone, unless there are duplicates in the
# original message. Any second and subsequent headers are rewritten to
the
# second named header (case preserved).
NNTP_REWRITE_DUPLICATE_HEADERS = [
('to', 'X-Original-To'),
('cc', 'X-Original-Cc'),
('content-transfer-encoding',
'X-Original-Content-Transfer-Encoding'),
('mime-version', 'X-MIME-Version'),
]
X-Original-Content-Transfer-Encoding
From Mailman/Defaults.py.in:
# Next, these headers are left alone, unless there are duplicates in the
# original message. Any second and subsequent headers are rewritten to
the
# second named header (case preserved).
NNTP_REWRITE_DUPLICATE_HEADERS = [
('to', 'X-Original-To'),
('cc',
Re: [Mailman-Developers] New RFC on using DKIM with MLMs
* Stephen J. Turnbull step...@xemacs.org: Joshua Cranmer writes: On 10/24/2011 8:04 PM, Barry Warsaw wrote: On Oct 13, 2011, at 11:41 PM, Murray S. Kucherawy wrote: There's movement afoot to deprecate use of X- in header field names. Just call it Mailman-Topic. And if it's worthwhile, consider registering it with IANA. I wonder if we should remove the X- prefixes for Mailman 3. Here's a list of ones we still add or recognize (some might be used only in the test suite): I would say that anything that is used only in the test suite should still get an X-, although I suppose you could use Mailman-Test- too. Is it possible to register a prefix (namespace) such as mailman-. Anything below would be mailman related. Stupid idea? p@rick -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] MM3: list disabling/enabling?
* Barry Warsaw ba...@list.org: OTOH, I can imagine that for some purposes you might want a different status code, and I don't see any good reason for making that configurable and then restricting it to 5xx. Rather, document it as this SHOULD be a 5xx code (in the RFC 2119 sense, ie, with sufficient reason it could be a 4xx code, but we don't know of any examples offhand :-). Do you really think it needs to be configurable? I mean, if we can't think of a reason to not make it 5xx, why not just wait for the first wishlist bug report? :) A configurable reply could provide a hint along the 550 like this: 550 See: http://list.example.com/550/listname The listname ressource could inform why the list was retired e.g. because it was relocated or closed or where to find the retired lists archives ... p@rick -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] MM3: list disabling/enabling?
* Barry Warsaw ba...@list.org: On Jul 12, 2011, at 01:06 PM, Ian Eiloart wrote: Bouncing certainly is suboptimal, since it may create collateral spam. Better to reject the message at SMTP time with a 5xx response than to bounce. That's an interesting take on it. The LMTP server in Mailman could reject messages addressed to disabled lists, and that 5xx error should propagate through the MTA. Is disabling a list a temporary measure? If it is, should the server reply a temporary error? 421 domain Service not available, closing transmission channel (This may be a reply to any command if the service knows it must shut down) 450 Requested mail action not taken: mailbox unavailable (e.g., mailbox busy) Or is it permanent? 550 Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons) p@rick -- state of mind () Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] MM3: list disabling/enabling?
* Lindsay Haisley fmo...@fmp.com: On Tue, 2011-07-12 at 17:23 +0200, Patrick Ben Koetter wrote: Is disabling a list a temporary measure? If it is, should the server reply a temporary error? In my humble opinion, an intentionally disabled list should cause the mail system to generate a 500 class error (permanent error). 400 class errors (temporary errors) are generally reserved for situations where the _intention_ is that the mail should go through but is prevented from doing so by problems for which a solution is in progress. A 400 class error causes the originating system to cache and re-try delivery, so if a list returns a 400 class error, it's just delayed, not truly disabled. This may be a fine distinction, and if a list is disabled ACK. Looking at the available codes I guess the best return code would probably be 550: 550 Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons) http://www.rfc-editor.org/rfc/rfc5321.txt, section 4.2.3. Reply Codes in Numeric Order p@rick -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] MailMan Usage
* Mark Sapiro m...@msapiro.net: On 6/26/2011 4:55 AM, Aamir Khan wrote: I would like to dedicate a email lets say h...@example.com where you can send emails and depending upon the Text written inside the Mail..(doing some Regexp matching)...I have to call different actions like retrieving data from DB and then answering the query etc... So i would like to know whether Mailman is suitable for my problem to be solved...if not, can you suggest me the open source solution that can fulfill my need. I don't think Mailman is suitable for this. I'm not aware offhand of any off-the-shelf open source solution. Check OTRS http://otrs.org for automated trouble ticket replies and Postmaster filters (pcre, regexp). p@rick -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Proposal for a new menu grouping in MM3 webUI
Benedict, * Benedict Stein benedict.st...@googlemail.com: As introduced by terry yesterday I'm the one who will support the development of the WebUI which should be published together with MM3 - or even better as a standalone Django Application using the REST-Api. Those who already saw my Blogpost know what I'm talking about now - the new menu grouping. I've created a mindmap showing a possible regrouping of menu items. Florian asked me only to use these which are already available in the REST API. Just in case you didn't read my Blog yet - I've attached the image. Feel free to give any feedback you like, The current (MM2) structure is far too complex. I work with it often and I still get lost or spend too much time searching for an option that must have been, wait, well where did it ... In 2009 I ended up buying tickets for Pycon 2009, visiting Barry to work on the MM3 WUI. Here's what I came up with (and what I personally still would do): The navigation structure should work for the following user groups: - subscriber - moderator - admin Each group (in descending order) requires an interface that offers/exposes more options. Put the other way around: The interface should hide all options not required for a group. A user can see the same interface different any time she logs in, IF she acts out different roles (subscriber, moderator, admin). I think we need to develop a structure that works for all groups and remains consistent. No matter which role you own, menu items should always be located at the same place. I think this can be done best if menu items were rearranged following a role/task driven approach. Here's a model I've come up with at Pycon 2009: The model forsees plugins, something Barry and I discussed to open MM3 to development by third parties. A subscriber could see these items: dashboard options general topics plugins subscriptions subscribe remove modify statistics List A moderator would see more items, building upon the already established subscriber structure: dashboard requests statistics System List User plugins plugin 1 configuration options plugin 2 Finally, an admin would be exposed to all options available through the WUI: dashboard maintenance requests options General Subscription Rules Language Non-Digest/Digest Filter Sender Recipient Spam Message Topics Bounces Archive Gateways Auto-Responder Plugins subscriptions subscribe remove statistics System List User plugins plugin 1 configuration options plugin 2 I've laid all this and descriptions of the various items down in http://wiki.list.org/display/DEV/global+requirements. p@rick -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Bounce processing in MM3
* Barry Warsaw ba...@list.org: One of the last major subsystems that I need to get working in Mailman 3 is bounce processing. This is different than bounce detection, which has been successfully ported from Mailman 2, but doesn't differ in any significant way. The question I am thinking about now is what to do with a bounce once we detect one. There are a couple of interesting things in MM3 that makes it different from MM2. In MM3, users and addresses are global to the system, while membership is specific to a mailing list. This means if we register a bounce on an address, we can have that score affect the address's subscription to all relevant mailing list. We can also do things like automatically roll over to another registered and validated email address for that user, if there is one, or at least send notifications to the other address. Here's an I think while I type section... ;) Should we apply a global action to a local problem i.e. if an address in one list bounces, suspend that address in all lists? Sounds like a good feature to keep the mail system from wasting ressources, but is this a good service for the recipient? If a message cannot be delivered to a specific address is undeliverable it usually is because - the receiving mail system is down - global action, because no list will be able to deliver a message - the recipient does not exist anymore - global action, because no list will be able to deliver a message - the recipient never existed - paradox: User never was able to verify list membership. Maybe she was, with another list and we just took the address for granted. We should always confirm an address for deliverablity reasons! - the recipients mailbox is over quota - global action, because no list will be able to deliver a message - the envelope sender is being rejected - problem! We can't tell if the specific envelope sender or the whole envelope sender domain was rejected. Action: Local. In dubio pro reo. In this case I'd leave it to all lists to learn that the particular recipient is undeliverable. There's also the question about how all the bounce scores are managed, and the knobs you as a list administrator can tweak to control how and when things happen based on the score. Reporting and logging are also part of the plan. We could apply a score and disable sending in all lists if e.g. three lists detected the recipient address bounces. But what's the consequence? Once we disable one recipient, should we apply that to all recipients in that recipients domain? Looks like a great admin service, but also like a great opportunity to shoot oneself into the foot automatically. It should be a feature that must be called manually. Because MM3 uses a relational database underneath the hood, my plan is to have a single table that only appends new bounce events. That way, Mailman will have a permanent record of every bounce that occurred. Exactly what information we can or should put in that table is up for discussion. I do plan also to keep all bounce messages in MM3's message store so that postmortem debugging is easier. Send priority by reputation. Reputation deducted from deliverabilty or should I better say receivability? We could create a domains or even a hosts receivabilty record. Those with the worst record are the once we send to last, because they likely will clutter our MSAs outgoing mailqueue. On a sidenote: I'd welcome an abuse database to blacklist addresses in a global range. And I like the idea that each MM instance should offer these data as service to other installations. Site-wide. Cross-Site. Because I'm just starting to think about all this, I wanted to throw this out to the list to get your feedback on things you'd like to see. What is it about MM2's bounce processing that you like? What don't you like? What MM2 bounce features can you do without? What would you like to see added? I am not acquainted with MM2 bounce features. p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] MM3 testserver downtime
Due to maintenance - we replace our VM host and migrate from XEN to KVM - mailman.state-of-mind.de will not be available until Friday, July 16th EBD. p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] mock-ups for user settings page, MM3
Anna, * Anna Granudd anna.gran...@gmail.com: I'm currently working on the (Django) views for the Mailman 3.0 UI. I looked at what mock-ups were made in the wiki, [1], and realized that so far there are no mock-ups for the user settings page. Therefore, I was wondering if there are non on purpose at the moment. The proposed way to get a design was a) adopt a new logo b) develop new color set c) create a new grid d) create a new design. anybody has any thoughts on what to think of when designing this page and how you would like it to look like. We could start with using the old user For the moment - this is my personal opinion - we should use logical, structured markup. Plain HTML. Design is important, but nothing without groundwork based on proper organisation of options and good HTML. settings page design from older versions of Mailman and just freshing it up a bit or we could make a complete redesign but it would be nice to get some peoples' opinions on what you want before starting (although just writing your thoughts down and emailing them works as well, if you don't feel like creating mock-ups). I think we need to decide on UI standards (do we need a 'save' button or not etc.) and a new organisation of options first and then aim for design. p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman user interface: draft of a mega drop-down navigation
* Geoff Shang ge...@quitelikely.com: On Thu, 24 Jun 2010, Claudia Fleiner wrote: Here I will present you our idea of a mega drop-down navigation panel for the new Mailman user interface: http://wiki.list.org/display/DEV/Web+UI+Mockups Can anyone explain this a bit for those of us who can't see this image? Or better still, point us at a coded example? The overall style is light. Lot's of whitespace creates room to distinguish object from each other. The compositional focus is on the content area. Logo and navigation stand back to let users concentrate on the task they need to accomplish. The page is white. The navigation color scheme used is dark blue for typo and light blue as background color. There's a broad border around the navigation pane. It is semi-transparent. When opened, i.e. when level 2 and 3 are visible, the navigation layers over the content drawing users attention to the navigation only. The navigation is horizontal to make way for applications that take place beneath; applications usually require more place than text/images pages. You can see navigation level 1. The navigation differs from traditional navigations in a few ways: - When you hover the mouse or focus a menu entry using keyboard navigation you get to see both, level 2 and 3, at once. A large rectangle (wider than higher) creates the canvas for for both levels. - A topic specific icon prepends evey level 2 item. - Level 2 items are aligned to the left and in bold text. - Level 3 items, if there are any, follow right hand to their correspondent level 2 entry on the same line. They are displayed in regular font weight. - If there were so many level 3 items that they needed to wrap to the next line, they would indent starting at the same left margin where the first level 3 item started. -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman 3.0 UI Test Server
* Ian Eiloart i...@sussex.ac.uk: --On 14 June 2010 19:21:04 +0200 Florian Fuchs f...@state-of-mind.de wrote: Hi all, we have set up a test server for the development of the Mailman 3.0 UI. As coding on the UI progresses we will update it regularly so everybody can see what's being done. For now it contains a simple, experimental Django app I've written to test list creation and subscription through Mailman's new REST API. You can add mailing lists and subscribe to them. Mails sent to those lists will not be delivered to subscribers but be kept in a separate IMAP folder so nobody gets spammed (thanks Patrick!). This app will be replaced as soon as there's a working code base for the real UI. The server's address is http://mailman.state-of-mind.de That's so much nicer than Mailman2! That was hard... ;) A couple of small issues with list creation: 1. The checkboxes should be closer to the text in the languages list. It's hard to see which box applies to which text. Agreed. 2. Mailman 3 supports multiple domains, right? So the list creation page should, perhaps, let me pick a domain from a drop down list. There will be a way to choose among the domains a user (role) has access to, when MM3 and the REST server will provide such functionality. What you see at the moment is about all the REST server can provide at the moment. 3. Given that the list of lists is created from the list creation page, perhaps there should be an opportunity to fill in the List information field on the list creation page. Yep. Do you have a wiki account? If not, you should get one and write down the constraints here: http://wiki.list.org/display/DEV/Suggestions+for+new+Mailman+3.0+UI p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman 3.0 UI Test Server
* Barry Warsaw ba...@list.org: On Jun 14, 2010, at 07:21 PM, Florian Fuchs wrote: we have set up a test server for the development of the Mailman 3.0 UI. As coding on the UI progresses we will update it regularly so everybody can see what's being done. For now it contains a simple, experimental Django app I've written to test list creation and subscription through Mailman's new REST API. You can add mailing lists and subscribe to them. Mails sent to those lists will not be delivered to subscribers but be kept in a separate IMAP folder so nobody gets spammed (thanks Patrick!). This app will be replaced as soon as there's a working code base for the real UI. The server's address is http://mailman.state-of-mind.de Yay! Thanks Florian and Patrick. Can we get access to the IMAP folder? host: mailman.state-of-mind.de user: mail...@mailman.state-of-mind.de pass: hemispheres And, please (!), don't use it to trade files... p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
* Christian Schoepplein ch...@schoeppi.net: * Geoff Shang ge...@quitelikely.com: Note that people who use magnification (i.e. who have low vision) are going to have differing requirements from those who use speech or Braille output via screen readers. Ideally the UI would work well for both groups but I'm not qualified to talk about the former, only the latter. Yes, thank you. I was aware of that and I have to admit I don't know yet what qualities exactly will be required to create an interface that works equally well for both groups. Unless someone has a better idea I guess we will just have to do 'a best guess', then measure and improve in an iterative manner. I know some people that use magnification. I can ask them to test also the new MM WUI or ask them for their needs regarding a new user interface. Great. Disclaimer: I am not deaf. A deaf person should be consulted about the requirements that deaf people may have. Yes, good idea. Are there any deaf people on this list who might be able to shed some light on this? I also can help out on this point maybe, because I also have friends that are deaf or work for a big German organization for deaf people. Even better. @p...@trick: Maybe I can also arrange a meeting with these people, they also live in Munich. That would be perfect. Should we all meet before we start working on the new WUI so we can take the input into consideration right from the start? p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
* Geoff Shang ge...@quitelikely.com: I was mainly wanting to highlight my accessibility concerns, particularly since I couldn't see the mock-ups, but I agree with all your points. Great. I can see and I need to use my imagination to figure what a _real good_ interface for visually imapaired people looks like. Better to have people who really know from first hand experience what to look out for. This said I think the interface should also be better accessible for deaf people. I've learned deaf people experience problems with complex sentences. We should consider that too and other aspects. You mentioned some other feature requests based on 2.1.x functionality. I'd be curious to learn what they are and even more than that I would like to invite you to help us create a user interface that works for as many as possible. Most of my other feature requests are functionality-related, rather than UI as such. Some may already be in the wishlist(s) on the Wiki (or wherever I saw it). I'm happy to post them here in a separate thread if people think it's relevant. They're just things I've jotted down when using Mm that I've thought should be changed/fixed. Please post your feature requests even if we find out they are duplicates. As for UI development, I'm fairly rusty at Python and I've never actually used Django (though I like the look of it), but I'd be happy to get my hands dirty if it's a matter of tweeking what someone else has started. You are more than welcome to help. As far as I know MM3 development has taken place mostly in sprints at Pycons in 2009 and 2010 (I don't recall everybodys name right now) and after these events almost solely by Barry and Florian. For this summer (of code) Anna has joined the team and I believe if Barry manages to do more work on the REST server and IMAP backend - *HINT* *HINT* - we will soon be able to present an early version of MM3 to test and play with while we bring it to a stable state. p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
* Christian Schoepplein ch...@schoeppi.net: I am really happy to find out you, as a blind person, are on this list and that you want to get involved into MM3 development, because creating a user interface that works well for most visually impaired people is one of our/my major goals in the MM3 WUI (web user interface) overhaul. That sounds very good. I also got in contact with Anna and asked about the accessibility in the new WUI, that should be an important point IMHO and should be not forgotten. Very nice that other people, who are more involved in the development of mailman, are keeping this point in mind too :). As allready said to Anna, just let me / us know, if there is anything to test. I'd be happy to support the development of the new WUI as good as possible regarding the accessibility for blind or visual impared users. Great. I live near Munich. Maybe we can meet and you can give me some first some Sendmail bashing... ;) p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
* Patrick Ben Koetter p...@state-of-mind.de: * Christian Schoepplein ch...@schoeppi.net: I am really happy to find out you, as a blind person, are on this list and that you want to get involved into MM3 development, because creating a user interface that works well for most visually impaired people is one of our/my major goals in the MM3 WUI (web user interface) overhaul. That sounds very good. I also got in contact with Anna and asked about the accessibility in the new WUI, that should be an important point IMHO and should be not forgotten. Very nice that other people, who are more involved in the development of mailman, are keeping this point in mind too :). As allready said to Anna, just let me / us know, if there is anything to test. I'd be happy to support the development of the new WUI as good as possible regarding the accessibility for blind or visual impared users. Great. I live near Munich. Maybe we can meet and you can give me some first some Sendmail bashing... ;) That's what you get when you delete the wrong lines... :-D I wanted to say: Great. I live near Munich. Maybe we can meet and you can give me some first hand experience using MM3 as a blind person. And I was going to say something about the two of us using Postfix and we could do some Sendmail bashing... ;) p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
* Geoff Shang ge...@quitelikely.com: Note that people who use magnification (i.e. who have low vision) are going to have differing requirements from those who use speech or Braille output via screen readers. Ideally the UI would work well for both groups but I'm not qualified to talk about the former, only the latter. Yes, thank you. I was aware of that and I have to admit I don't know yet what qualities exactly will be required to create an interface that works equally well for both groups. Unless someone has a better idea I guess we will just have to do 'a best guess', then measure and improve in an iterative manner. This said I think the interface should also be better accessible for deaf people. I've learned deaf people experience problems with complex sentences. We should consider that too and other aspects. Huh? This makes no sense to me. People who only have hearing impairments shouldn't have any more problems with comprehention or It didn't make sense to me either until I listened to a Chaos Computer Club (CCC) Podcast about accessibility with the two guys who started/participated in the Web Standards Project http://www.webstandards.org/. Too bad the Podcasts are German only. I recommend them to anybody interested in technics, society and culture. Anyway, their story went like this: If you are deaf you learn sign language to communicate with others. Sign language is the first (mother) language for deaf people. Any other (written) language is foreign and that introduces all the problems people usually have with foreign languages. reading than people with only vision impairments. By all means make allowances for people with reading/learning/cognitive disabilities, but please don't atribute the need for this to something unrelated. Do I seem overeager? Don't worry I am not a do-gooder trying to create an interface that attempts to work for _everybody_ on this planet. I simply want to create an interface that accounts for accessibility and that includes deaf people too. If the relation deaf - reading problems stands then I'd like to find a way that works for deaf people too. Maybe (!) that's not a problem at all with an application interface as we are going to create, but only with websites that contain lots of text. Disclaimer: I am not deaf. A deaf person should be consulted about the requirements that deaf people may have. Yes, good idea. Are there any deaf people on this list who might be able to shed some light on this? p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
Geoff, I am really happy to find out you, as a blind person, are on this list and that you want to get involved into MM3 development, because creating a user interface that works well for most visually impaired people is one of our/my major goals in the MM3 WUI (web user interface) overhaul. This said: I believe the current interface is too complicated even for those who don't need to meet any perceptional or motional challenges: - It doesn't enforce reasonable grouping of related functions - It exposes an immense number of configuration options to the user but doesn't seem to prioritize how often they are required - It has a high signal noise ratio i.e. it's crowed with text (help messages) which makes it hard to focus on the configuration options themselves. - HTML is not used in a semantic way. You already mentioned there's no association between option names and their fields aka 'labels'. If I remember correctly structure i.e. headings and reasonable use of list are also missing. The list is totally uncomplete, but I guess you get the idea. This and more should go and be replaced by better solutions AND the interface should be modern, nice to look at and provide a set of comfortable JavaScript functions. But JavaScript et al. must not be a basic requirement. We want progressive enhancement http://en.wikipedia.org/wiki/Progressive_Enhancement and, to answer one of your questions in your message, our goal is to ship a default user interface that provides the needed accessibility. You mentioned some other feature requests based on 2.1.x functionality. I'd be curious to learn what they are and even more than that I would like to invite you to help us create a user interface that works for as many as possible. p...@rick * Geoff Shang ge...@quitelikely.com: On Fri, 4 Jun 2010, Anna Granudd wrote: there are some mock-ups on the wiki (see http://wiki.list.org/display/DEV/Web+UI+Mockups) but it'd be great if you could help with ideas for a nice design and layout! As a blind person, I'm not able to comment on these as these are images. I can understand the desire for an overhall of the Mailman UI, but I think it's worth saying that for the most part, the 2.x UI works well for people using screen reader technology. The only area which provides some challenges is the membership management screen, as it can be difficult to associate each checkbox with the function it performs. But even this can be managed using screen reader commands for reading tables. I realise that Mailman 3.x will make it possible to create multiple UIs, as the functionality will be separated from the UI. However, it is also my experience that alternate/specialised UIs can and do go unmaintained, and as such it is my hope that the (or at least a) standard UI shipped by default with Mailman will provide the needed accessibility. So this is one of the reasons why I'm on this list, to keep an eye on developments and hopefully provide some feedback when a test server becomes available. Right now, my UI wishlist is as follows: 1. At least one UI with no *necessary* javascript. Maybe this won't be the main UI, but as a person who uses the Linux console with a text-mode browser, I like the fact that I can quickly fire up my browser to deal with a moderator request with no fuss. Given that a package like Squirrelmail can operate completely without Javascript if the user chooses, this should surely be possible. 2. Proper use of the label tag in association with form elements. This was (or seemed to be done) fairly well for the most part, with the exception of those checkboxes I mentioned, but I'd hate to see this lost. What this means in practice is that screen readers will read the appropriate label text when focusing upon a form element. There's probably other important stuff, but this is all that comes to mind right now. Other non-accessibility-related things which I think are worth considering are: 1. More useful archives with search capability. I'm sure this is on a dozen wishlists. 2. A friendlier front page per list. Surely having 3 forms on the front page (or is it 4?) is a bit intimidating to some. I've got some other feature requests based on 2.1.x functionality but I'll post that somewhere else more appropriate. Geoff. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/p%40state-of-mind.de Security Policy: http://wiki.list.org/x/QIA9 -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht
Re: [Mailman-Developers] Feature request for Mailman 3: Ability to perform all admin functions from gmail
* Barry Warsaw ba...@list.org: On Mar 29, 2010, at 10:18 AM, Brian J Mingus wrote: I realize many of you will say that gmail is not a proper MUA but that doesn't weigh on me very heavily since I am otherwise very productive with it. I am also skilled in Python, although as you can imagine I have a long todo list. But, if someone could define a clear path to making this work perhaps I could meet the Mailman 3 deadline, whenever that is. Or perhaps I could work with someone on it, or convince someone else that an alternate, more general and widely supported (e.g., supported in all very popular web e-mail clients) e-mail interface to mailman administration is worth their time. Another thing to think about besides Skip's script is that MM3 will provide a REST API for scriptable control. Now, the primary admin REST API probably will not be available, but a protected, authenticated API is worth pursuing. Another option is to expose more of the command interface through the email API, but I would like to explore GPG verification for that interface. Add S/MIME just in case you feel bored... ;) p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman 3.0 UI Status?
* Barry Warsaw ba...@list.org: On Mar 17, 2010, at 03:41 PM, Jennifer Redman wrote: I believe that there was a Code Sprint at Pycon to work on the MM 3.0 UI (and other items). Is there any place I can go to read about what has been implemented thus far in MM 3.0 and what features are still outstanding with regards to MM 3.0 and in particular the UI? Hi Jen, We did sprint on the MM3 web ui at Pycon, and I've been meaning to review the work and publicize it more. Florian, Jon, and Craig did some good work on that side while I was reworking the REST infrastructure. Their branches are here: https://code.edge.launchpad.net/mailmanweb We decided to use Django and see how far we could get. I think the experiment worked well and I'm inclined to go with Django moving forward. Perhaps Florian can speak more about this, where he plans to go and how we can get more people involved in this effort. I think he and Patrick were even considering putting up an experimental server so that we can being to play with it. The server is up and almost ready to play with. Florian wanted to check a few things the other day and ping you offlist on this and that. p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Anybody looking for an insane project?
* Barry Warsaw ba...@python.org: On Dec 9, 2009, at 3:35 PM, David Brown wrote: RFC 5228 seems to obsolete RFC 3028. Okay, I think I found the project here: http://sieve.info/ Hi Dave, thanks for the update and link. The most python-y thing I could find is on their servers page; they list pysieved (Python Managesieve Server) but the link 404s. Looks like the programmer's site is still running, though... looks like you could get the files here: http://woozle.org/~neale/gitweb.cgi?p=pysieved;a=tree This doesn't appear to be an implementation of the sieve *language*, though... it's a script management tool. Would it be necessary to implement the sieve language in Python or would it be possible to just use one of the existing C libraries? (libSieve is under LGPL) I think either would be fine. If there were a pure-Python implementation of the language, we could possibly consider enabling it by default. With a Python extension module talking to libSieve, we might want to make it optional. But it's probably way too early to make that decision. Are we talking Cyrus' libSieve? If we are, I might throw in that the Dovecot project used the library for a while and turned to a complete new selfmade implementation. I don't recall the reasons, but I think it would be worth asking Timo, the man behind Dovecot. p...@rick Mostly I'm trying to see if anybody would be interested in doing a little exploration hacking along these lines. If so, I will of course help you get started; ideally, you'd hack together a Bazaar branch that pulled in the appropriate libraries and did Something Cool with them just as a proof-of-concept. -Barry ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/p%40state-of-mind.de Security Policy: http://wiki.list.org/x/QIA9 -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman 3 and LMTP
Hi! * Barry Warsaw ba...@python.org: I'm getting very near ready to release another alpha of Mailman 3, and on the prompting of a private message from Robert Niederreiter I took some time to fire up a VM and actually try Postfix+LMTP delivery in an experimental production system. I'd like to get some feedback from the Postfix experts in the crowd so that we can update the wiki page here: http://wiki.list.org/display/DEV/LMTP+process FTR: the VM is running Ubuntu Karmic Koala 9.10 server with Postfix 2.6.5 and Mailman 3.0 from the lp:mailman bzr trunk. To start with, I mostly followed the instructions in the wiki. I tried using the standard lmtp transport in master.cf, creating /etc/postfix/mailman_lists as described in the wiki (not the dedicated list server example, but the earlier one on the page). I actually used: # Key # Value t...@xxx.example.comlmtp:xxx.example.com where 'xxx.example.com' is replaced by my VM's host name. Additionally you probably want to add square brackets around the hostname. Quoting man 5 transport: ...the [] suppress MX lookups. This prevents mail routing loops when your machine is primary MX host for example.com. The first gotcha is that unless you start Mailman as root, you can't bind its LMTP server to port 24, which is Postfix's default. By default Mailman's LMTP server listens on localhost:8024, so you either need to append ':8024' on the Value above, or set lmtp_tcp_port = 8024 in Postfix's main.cf. I ended up doing the latter, but both work. I think an option in MM3 should make this configurable. I set up transport_maps and local_recipient_maps just as outlined in the wiki page, fired everything up, and then sent a message to the VM's Postfix while tailing the logs. I kept seeing Connection refused messages from Postfix and it never hit Mailman's LMTP server. This was highly confusing because I could see in the Postfix logs that it was finding the right IP address for its own hostname and it was trying the right port number. Mailman's lmtp.log file claimed it was listening on the right IP and port, and I could even telnet to it just fine. So what was Postfix doing? It seems that Karmic is playing tricks with /etc/hosts. I've got DNS set up to correctly resolve the VM's hostname, but there was actually an entry in /etc/hosts that set xxx.example.com to 127.0.1.1. I'm not entirely sure which process looks at what, when, but clearly this inconsistency was a key part of the problem. The other thing that surprised me was that Postfix was also On a sidenote: It also confuses a dhcpd server running on a machine that promotes 127.0.1.1 to be xxx.example.com. I've opened a bug ticket for that two Ubuntu releases ago, but it seems they only keep carrying it further from release to release instead of addressing it. At least that's the impression I get without knowing the real cause. consulting /var/spool/postfix/etc/hosts, and I had to change both /etc/hosts That's because LaMont Jones delivers the Debian/Ubuntu Postfix package chrooted. If Postfix runs chrooted it uses /var/spool/postfix/etc/hosts instead of /etc/hosts. and that file as well, so that the IP addresses jived with DNS. This is unsatisfactory, but it seemed critical to getting things working. The last piece of the puzzle was to not use Postfix's standard lmtp server in lmtp client... SCNR master.cf, but to define a new one like so: mailman3 unix - - - - - lmtp -o disable_dns_lookups=yes and then change the mailman_lists transport map to # Key # Value t...@xxx.example.commailman3:xxx.example.com After a restart, everything suddenly worked exactly as expected. suddenly... :) Robert was having a different problem, but hopefully he will follow up here with his experience and let us know if any of the above helps. If any Postfix experts have words of wisdom to make this better, please let me know. If MM relies on Postfix defaults and the postmaster changes them in Postfix the MM part might end up being unusable. I recommend to take full control of the settings in the Postfix transport map. Let MM create its own Postfix style transport map. Set the Postfix service name (in your example its mailman3), put the hostname in square brackets and set the port. I probably need to work on better dropping of privileges for qrunners so that you can 'bin/mailman start' as root, and once the LMTP runner binds to port 24, it can drop privs to 'mailman'. I'll put that on the list for something to do after the next alpha. I like that idea. I'd also like to try to resurrect William Mead's LMTP branch. Sadly, it won't merge cleanly into trunk any more (not the least of which because it's in the wrong bzr format). If anybody would like to contribute that before I get to it, I'd be grateful. The good news is that I think Mailman 3 is getting more real every day.
[Mailman-Developers] Mailman and Submission port
MM developers, I'd like to propose a change in MM3s default SMTP client port from port 25 (transport) to port 587 (submission). Why? From my point of view mailman rather is a mail component that introduces messages into a mail system than one that sits between MTAs and assists in transporting messages that pass by. RFC 4409 http://www.rfc-editor.org/rfc/rfc4409.txt explicitly defines a submission port (587) for mail systems whose purpose is to accept message from MUAs: However, SMTP is now also widely used as a message *submission* protocol, that is, a means for Message User Agents (MUAs) to introduce new messages into the MTA routing network. The process that accepts message submissions from MUAs is termed a Message Submission Agent (MSA). Apart from doing 'the right thing' what would be the benefit? The RFC gives some ideas in a later section: (...) Even when submitted messages are complete, local site policy may dictate that the message text be examined or modified in some way, e.g., to conceal local name or address spaces. Such completions or modifications have been shown to cause harm when performed by downstream MTAs -- that is, MTAs after the first-hop submission MTA -- and are in general considered to be outside the province of standardized MTA functionality. From my daily work with mailman the following modified in some way-tasks come to my mind immediately: - apply client and content policy that differs from the port 25 anti-spam policy - add DKIM signatures because it is clear mailman messages are ORIGINATING from our network What would we have to do, to make port 587 the default port? In section 4 the RFC says, a MSA MUST do all of the following: 1. General Submission Rejection Code 2. Ensure All Domains Are Fully-Qualified 3. Require Authentication To cut it short: 1. and 2. are trivial (at least in Postfix and I don't know the others MTAs well enough to tell for them too). 3. requires to add SMTP AUTH functionality to Mailman's SMTP client. How should we implement SMTP AUTH in the MM SMTP client? I propose for a start plaintext (PLAIN, LOGIN) and shared-secret mechanisms (CRAM-MD5, DIGEST-MD5) should be added to the SMTP client. Those are the ones used most widely in every day SMTP AUTH. Later implementations could add GSSAPI and EXTERNAL. If plaintext mechanisms are added we should also consider to add STARTTLS functionality to MM's SMTP client to shield credentials while they are sent in a plaintext authentication session. p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman and Submission port
* Stephen J. Turnbull step...@xemacs.org: Patrick Ben Koetter writes: I'd like to propose a change in MM3s default SMTP client port from port 25 (transport) to port 587 (submission). I don't see a real justification for such a change, given the authentication requirement. While Mailman can be used in relatively closed setups, its central mission remains the more-or-less open discussion list as far as I can see. Closed lists, announcement lists, and the like are very common, but I don't think they are the overwhelming majority of uses yet. Until they are, changing the default is an annoyance to many. The change I propose is not driven by considerations concerning pro or con open/closed setups. Maybe you misunderstood me or I am misunderstanding your reply. To clarify: I don't want to require users to authenticate in order to allow them to send. I want mailman to use a stanardized port for message submission (and that brings in the authentication requirement). Everybody seems to use a dedicated port to inject messages coming from mailman. People do that either to completely avoid applying expensive content filter rules to all messages coming from mailman or they do it to only run a minimal subset of content filter rules. I want to standardize that dedicated port and I propose to use the submission port as recommended by RFC for scenarios like that. The authentication requirement applies to the mailman server (read: SMTP client) only. It can be set once in the global mailman configuration file. Users don't need to do anything. It's completely transparent to them. p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] monthly password reminder bounce reaction
* s...@pobox.com s...@pobox.com: Barry Remember that monthly reminders are a thing of the past. They Barry won't be in MM3 and IIRC, they've already been removed from the Barry MM2.2 tree also. Thank you. As the person who maintains the mail.python.org spam filters the volume of held messages I have to wade through is huge around the first of the month because of bouncing reminders. I will definitely miss Mailman Day. ;) p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] monthly password reminder bounce reaction
We, the Python.org postmasters, received about 2.200 bounces at Mailman day from monthly password reminders that did not reach the recipient. Ralf said such bounces do not increase a mailing list members bounce score. Is this correct? If it is, can we add such behaviour to the MM3 feature list? Any objections? p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] monthly password reminder bounce reaction
* Mark Sapiro m...@msapiro.net: Patrick Ben Koetter wrote: We, the Python.org postmasters, received about 2.200 bounces at Mailman day from monthly password reminders that did not reach the recipient. Ralf said such bounces do not increase a mailing list members bounce score. Is this correct? If it is, can we add such behaviour to the MM3 feature list? The reminders go away in Mailman 3.0 as does the site list, so the problem goes away. Fine. See the FAQ at http://wiki.list.org/x/aICB for a description of the issues and why this is happening. I agree that 2200 bounces is a huge number to deal with manually. I'm willing to work with you to find a way to deal with these programmatically if you wish. Thanks for the offer. Ralf already took care of it and he's not the kind of guy to use his hands if a script can do it. I haven't asked, but I guess he used some awk magic... Just incrementing the bounce score for such a user on all lists of which she is a member will not work, because as the FAQ notes, her list delivery is probably disabled so the only bounces are the password reminder, and likely, last month's bounce is stale when this one arrives. Removing the member from all lists is often the right thing, but consider a member who is actually active on lists, but bounces un-whitelisted mail and forgets to whitelist the site list. Then the password reminder bounces and he is removed from all lists. Yes, I understand that very well. My mail was more about doing the right thing than about what exactly should be done. Since the cause will be removed the problem should be gone in MM3. p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] mailman 3: webinterface: prototype (PDF)
* Terri Oda te...@zone12.com: Patrick Ben Koetter wrote: Can we add a search box for options? It might not be necessary on the smaller pages, but the full admin/owner interface looks like it's still going to be sufficiently busy that it could help. We can. But I, personally, would want to wait for usability test and see if we can do without it simply because it makes the interface more complex. Well, here's some user data from a recent mailman-users post http://www.mail-archive.com/mailman-users%40python.org/msg53494.html This is a *common* way for people to find things in the current mailman admin interface, sadly. I've watched people do it and had people tell me in person that's how they find things too. Most people who maintain mailing lists do settings changes infrequently, and often under some time pressure. And they never have time to learn the menu hierarchy unless they maintain a lot of different types of lists. And often not even then. There's a lot of options there, and most people nowadays are used to the google method of finding things. ;) I totally understand not wanting to add too much extra, but... my user observations thus far imply that this is a feature that would be used heavily. Agreed. If it helps we will find a place for it. The test scenario affects the outcome of the test. We need to standardize the test before we run it. I might be able to get some people from a usability lab we work with help us. Let me check that. I'm an academic researcher professionally, so I'm well aware of issues in testing methodologies. But honestly? Don't get caught up in doing Perfect Science here. Even a quick, dirty, messy user study would give Believe me. I won't. ;) us a lot of information that could be useful. The current interface suffers badly from lack of user testing, and I'd hate for the same to be true of the new one. Yes. If you need more help with user studies, I should be able get some help from the usability research lab here. I know one of the profs here expressed interest in mailman usability in the past, and we may be able to find people willing to work on the problem. That would be the perfect opportunity. Please ask him if he's still interested. The question is: How do I get there. I life in Munich, Germany. p...@rick -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] mailman 3: webinterface: prototype (PDF)
* Barry Warsaw ba...@list.org: What do you think? Should I comment the navigation structures? I've put a lot of thinking into it and that is, of course, not visible. I could comment and we'd have it easier to see where I think things should be put to. That does sound good. Comments, or some other way to capture your thinking behind it, would be good. I created a separate page for each role (admin, moderator, subscriber) and added notes to each menu item. If you want to start with a top view, start here: http://wiki.list.org/display/DEV/global+requirements Then, in each subsection of Navigation Structure choose See a commented role navigation structure. To jump right at it: administrator navigation structure http://wiki.list.org/display/DEV/administrator+navigation+structure moderator navigation structure http://wiki.list.org/display/DEV/moderator+navigation+structure subscriber navigation structure http://wiki.list.org/display/DEV/subscriber+navigation+structure p...@rick -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] mailman 3: webinterface: prototype (PDF)
* Barry Warsaw ba...@list.org: On Apr 23, 2009, at 11:16 AM, Patrick Ben Koetter wrote: following our discussions at the Pycon 2009 Mailman sprint I've come up with first draft of a/the future mailman 3 web interface. Patrick, thanks very much for doing this. I think it's a good way to begin the discussions. One thing that it would be good to think about is how MM3's improved model can make navigation and configuration easier. For example, when a user is thinking about her subscriptions, she needn't be constrained to a list-centric view. In MM2, certain global operations were pure hacks, and a user always had to see a list-centric view. For sites that run many inter-related mailing lists, the user will probably want to get a more general view of their subscriptions and options. On Launchpad for example, they can go to one page that shows all their subscriptions. Each mailing list that they are (or may) subscribe to is listed on one page, and each has a pull down menu that lets the user unsubscribe (i.e. not subscribed), subscribe with their preferred email address (a concept not yet exposed in Mailman, but which could be), or subscribed with a specific address. Agreed. We discussed that at the sprint and I think the navigation structure I have come up with allows for that: http://wiki.list.org/display/DEV/global+requirements#globalrequirements-NavigationStructure Here's the excerpt of a users navigation structure: options general topics plugins subscriptions subscribe remove modify statistics List A (regular) user, for example, would do this to see a list of all current subscriptions: Go to top level menu item: subscriptions This will show a list of all current subscriptions that could be individually choosen for unsubscription or modification. Also all subscriptions could inherit applicable settings from the currently choosen account. If user wanted to subscribe another list a subpage would have to be choosen. This page would list all available subscriptions. It's a separate page on purpose to prevent information overflow if we'd put it all in one page. What do you think? Should I comment the navigation structures? I've put a lot of thinking into it and that is, of course, not visible. I could comment and we'd have it easier to see where I think things should be put to. This is nice because they can pretty easily manage all their subscriptions from one page. You could imagine other global-ish things on this page, like vacation settings, or default site-wide user options. Yep. This page might also contain widgets for registering and confirming additional email addresses linked to the user account. Agreed, but having the concept of a task-oriented navigation in mind I'd probably put this on the users personal homepage. On the list-admin side, another thing to think about is the application of styles. A style needn't be just something that can be applied when Style as in profile? Just to think of two prototypes: Techi-Profile No HTML Mail No Attachments Party-Profile HTML Mail Attachments the list is created. Say for example, there is a micro-style that lets them disable digests and select a standard personalized footer. That might be a style available to the list owner on their list page. I do like the idea of a notifications area with a list of things a user can do (i.e. the 3 pending). This of course would be linked to task-oriented pages for addressing those things. A user might also see a list of registered emails that need confirming (with a link to send another confirmation message). Yes. They have to functions: 1. Notify user if (!) attention is required (hide otherways...) 2. Provide quick-/deeplink into the lower navigation levels without having the user click through tons of navigation levels (or even worse clicking through the whole site because they don't remember where it was). That's all for now. We will start working on design May, 1st. Minor changes to pages and elements are possible. I'd like to avoid major changes after that - the effort of redoing design is immense. Think we can get the discussion to a point of let's start design 'til then? p...@rick -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Re: [Mailman-Developers] mailman 3: webinterface: prototype (PDF)
Terri, thanks for taking the time to read my proposal and writing this email. * Terri Oda te...@zone12.com: What do you think? Should I comment the navigation structures? I've put a lot of thinking into it and that is, of course, not visible. I could comment and we'd have it easier to see where I think things should be put to. I love how you've put all this thought into a better structure here. But no matter how much thought goes into it, someone's gonna have trouble finding stuff in a tree that big... Yes. For a list owner this seems acceptable to me. Those are the ones who are willing to spend some time - they expect a certain level of complexity because they know the software is complex. For a regular subscriber the interface should be as simple as possible (but not simplier or they will think we believe they are stupid ;). Can we add a search box for options? It might not be necessary on the smaller pages, but the full admin/owner interface looks like it's still going to be sufficiently busy that it could help. We can. But I, personally, would want to wait for usability test and see if we can do without it simply because it makes the interface more complex. Reason is, I have planned search boxes for several other use cases e.g. finding a subscriber, a mail address etc. I would rather not have two search boxes fanning out ambiguity and competing for user attention - unless we need to. I do believe complexity is a deliberate decision. We will start working on design May, 1st. Minor changes to pages and elements are possible. I'd like to avoid major changes after that - the effort of redoing design is immense. Can we please please please do some user testing on the initial designs before they get set in stone? Ideally, I think we'd want to do this at Yes, very welcome. the point where there's a clickthrough prototype. Then we could sit some people down and ask them to do some tasks, and see how long it The test scenario affects the outcome of the test. We need to standardize the test before we run it. I might be able to get some people from a usability lab we work with help us. Let me check that. takes/where they go wrong. Plus we could get general impressions on usability from the mailman-users list. We should also manage the change actively e.g. provide a little website that explains why things have changed, where they have gone etc. The goal would be to re-empower the people and give them the security back they have accquired using the old interface over the years. p...@rick -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] mailman 3: webinterface: prototype (PDF)
Greetings, following our discussions at the Pycon 2009 Mailman sprint I've come up with first draft of a/the future mailman 3 web interface. The interface has changed a lot. Changes follow these principles: * Simplify interface * Focus on tasks * Order and sort by task recurrance * Reduce information overflow e.g. by hiding help messages * Show help messages as bubbles when selected by user * Remove instructions on using a web from * Use default button texts e.g. Save instead of Submit your changes See also: http://wiki.list.org/display/DEV/Rest+client I've come up with a paper prototype, which you can download in an annotated PDF by clicking at Mailman webinterface draft at the following location: http://wiki.list.org/display/DEV/Information+Architecture Important The version you can download is _not a design_. It's a grid that creates a structure, puts elements we need on a (HTML) page, orders and groups them following the principles I've outlined above. Please feel free to comment on it and ask questions. I've spent the last 5 days clicking the old interface, thinking and sitting before my current proposal - I just might be blind to my own stupidity or brain dead by now. ;) My goal is to agree on an information architecture, so we can go on and create a design that combines functional requirements and aesthetics. Once we've agreed on a design, we will create HTML templates and then we will put them together with the upcoming REST client. p...@rick -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] PyCon 2009 sprint: Webinterface
* Barry Warsaw ba...@list.org: How do we do it? Do I get write access to Mailman wiki? You should have write access just by virtue of having an account on the wiki. There are only a few pages that aren't generally writable by every logged in user. If you're having a problem with a specific page, let me know. I'll give it a try later. We've thought about different client technologies too. That's the client technology part I wrote about in the wiki. Which we didn't discuss was fully authenticated access for the REST server by design. If I understand this correctly than any party that is able to communicate with the REST server will have full admin access to Mailman's data model. In other words: It's upon any REST client to protect the REST server from abuse. That's basically correct. I feel a little uneasy not having the server control that itself unless we find a good way to control who may connect to the server or the server is able to identify valid clients by some client identity (ACL). It depends on whether we view the REST API as a user feature or an admin interface. I've always thought about it as the latter, but I'm open to It's probably both, depending on the users role. other opinions. OTOH, I think there's a lot of functionality that a privileged process could need, that the general public won't need at all. That's what I think, too. Another way to think about it is that there doesn't need to be just one REST API. Yes and I think this would make maintaining code, setting the whole system up and configuring it more complicated. Currently one REST server that uses a role model to determine access level to MM's data model seems the best approach to me. I am open to suggestions. What this means though is that when you deploy Mailman's REST interface, you must take care to protect it. You wouldn't want to expose it to the internet for example. You'd want to make sure that its interface is Exposing it to the internet is a typical use case in my eyes e.g. run the server on the internet, but control it from a different host. I can see mailman providers offering access to their MM server to customers who integrate their client on their servers - on the internet. accessibly on via your data center, or via localhost if you were running a turnkey standalone system. I was thinking of TLS client/server authentication for open networks. Not that I have spent time yet to find out if Python (REST) tools provide such functionality - I am sure it does, but given my low Python experience, I'd rather verify... I'm not sure about this either. We should check. Client/server communication will send/receive personal data that IMHO should always be protected during transport regardless of the REST data access control model we choose. p...@rick -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 45227227 81669 München Telefax +49 89 45227226 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] PyCon 2009 sprint: Webinterface
* Patrick Ben Koetter p...@state-of-mind.de: * Barry Warsaw ba...@list.org: How do we do it? Do I get write access to Mailman wiki? You should have write access just by virtue of having an account on the wiki. There are only a few pages that aren't generally writable by every logged in user. If you're having a problem with a specific page, let me know. I'll give it a try later. Any special place I should migrate our wiki to? These locations already exist, but I wouldn't want to modify their content: http://wiki.list.org/display/DEV/REST+Interface http://wiki.list.org/display/DEV/Web+Interface I could create sub-pages. Any preferences, ideas? p...@rick -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] PyCon 2009 sprint: Webinterface
* Barry Warsaw ba...@list.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 24, 2009, at 5:16 AM, Patrick Ben Koetter wrote: * Patrick Ben Koetter p...@state-of-mind.de: * Barry Warsaw ba...@list.org: How do we do it? Do I get write access to Mailman wiki? You should have write access just by virtue of having an account on the wiki. There are only a few pages that aren't generally writable by every logged in user. If you're having a problem with a specific page, let me know. I'll give it a try later. Any special place I should migrate our wiki to? These locations already exist, but I wouldn't want to modify their content: http://wiki.list.org/display/DEV/REST+Interface http://wiki.list.org/display/DEV/Web+Interface I could create sub-pages. Any preferences, ideas? You could either add to the bottom of those pages (which will make them easier to garden later), or you could make them subpages of http://wiki.list.org/display/DEV/PyCon+Sprint+2009 I'll make them subpages of Sprint+2009. BTW, has the wiki been slow for anybody else? Yep. p...@rick Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAknIvE4ACgkQ2YZpQepbvXHa+ACfcSFh4QtSx/TCE/v/MWw321ed GVAAoKEEQ4NB29BVNr1L9AjPM9v9R2VC =3CN4 -END PGP SIGNATURE- -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] PyCon 2009 sprint: Webinterface
* Barry Warsaw ba...@list.org: http://wiki.list.org/display/DEV/PyCon+Sprint+2009 BTW, has the wiki been slow for anybody else? It's so slow at the moment it's a pain to work with. Any chance to bring this back to normal? thanks, p...@rick -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Web Interface: Login
Is there any reason why there need to be two login screens? One for regular users and another one for moderatores/admin? p...@rick -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Web Interface: Login
* Barry Warsaw ba...@list.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 23, 2009, at 9:25 AM, Patrick Ben Koetter wrote: Is there any reason why there need to be two login screens? One for regular users and another one for moderatores/admin? I think it makes sense to simplify the interface and have only one login page, but ... Subscribers need to provide their mail address (authentication identity) and their password. Admin and moderators currently don't have to. If we had only one login page, would that require admin and moderators to provide an authentication identity too and not only their password? (At the moment I believe this would be a benefit. One could have more than one admin without having them share one password.) Would that break any upgrade compatibility for none MM3 lists? p...@rick -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Web Interface: Login
* Barry Warsaw ba...@list.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 23, 2009, at 9:47 AM, Patrick Ben Koetter wrote: I think it makes sense to simplify the interface and have only one login page, but ... Subscribers need to provide their mail address (authentication identity) and their password. Admin and moderators currently don't have to. This is broken, for many reasons. It's this way because MM2 doesn't have a notion of roles, so admin and moderator is defined solely because you know a password. This password is shared among all people sharing that role, which is another reason why this is broken. Agreed. Ideally, (in MM3) Mailman would have accounts, which would be separate from but linked with the email addresses it manages for lists and such. It should be separate in the sense that authentication information may come from external systems, e.g. your content management user accounts, or Launchpad, or OpenID, etc. Yes, I think a role model is a good idea and using external services is IMO a good idea too. If we had only one login page, would that require admin and moderators to provide an authentication identity too and not only their password? (At the moment I believe this would be a benefit. One could have more than one admin without having them share one password.) Would that break any upgrade compatibility for none MM3 lists? Let's worry only about MM3 lists here. We'll have to deal with upgrading/importing from MM2 at some point, but if possibly I'd like to not compromise the MM3 design with worrying about importing from MM2. Fine. I will work with a unified login model then. p...@rick -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] PyCon 2009 sprint: Webinterface
* Barry Warsaw ba...@list.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 20, 2009, at 6:22 PM, Patrick Ben Koetter wrote: Here's the link to a wiki I've put up to get started: http://mailman.state-of-mind.de/wiki/doku.php Hi Patrick, Do you think the Mailman wiki would be a better place for this? Yes. It keeps everything in one place. I would have to work around the freemind mindmap flash fancy stuff though, which I've just fallen in love with. But let's not let this get in the way. How do we do it? Do I get write access to Mailman wiki? I will add more as I get to it. Comments, ideas, improvements are welcome. The server part, for example, is completely empty at the moment... One thing we discussed at last year's sprint, is the model that the REST interface will have full admin access to Mailman's data model. I.e. it will by design be fully authenticated. The reason for this is that we'd like it to act as an API that other systems can use to integrate mailing list services into their systems. For example, if you had a web site running PHP that you wanted to use Mailman for your mailing lists, it could use this REST API to control and query Mailman. We've thought about different client technologies too. That's the client technology part I wrote about in the wiki. Which we didn't discuss was fully authenticated access for the REST server by design. If I understand this correctly than any party that is able to communicate with the REST server will have full admin access to Mailman's data model. In other words: It's upon any REST client to protect the REST server from abuse. I feel a little uneasy not having the server control that itself unless we find a good way to control who may connect to the server or the server is able to identify valid clients by some client identity (ACL). What this means though is that when you deploy Mailman's REST interface, you must take care to protect it. You wouldn't want to expose it to the internet for example. You'd want to make sure that its interface is accessibly on via your data center, or via localhost if you were running a turnkey standalone system. I was thinking of TLS client/server authentication for open networks. Not that I have spent time yet to find out if Python (REST) tools provide such functionality - I am sure it does, but given my low Python experience, I'd rather verify... Still, this provides great advantages, such as the ability for us to ship a web interface as an add on, and for sites to easily swap out the web interface, or create their own ways of accessing and controlling Mailman without having to write Python code (which they can do in MM2 and will be able to do in MM3, though few sites apparently do this). Same idea here. p...@rick So while an account/login model is necessary (e.g. for the email interface), it needn't be required for accessing the REST API. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAknHnJYACgkQ2YZpQepbvXG61QCaAyejP3BWk8XuTVoPWUfgxwy1 0f8An1uI13rnc97QoLJg/gQTBvmU/WW7 =lnPY -END PGP SIGNATURE- -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] PyCon 2009 sprint: Webinterface
* Patrick Ben Koetter p...@state-of-mind.de: Aesthetic design is something we can turn to later. I for myself want to use our sprint time to work on information architecture, client features etc. I am currently working on a proposal to rearrange the information structure and I am writing down some basic requirements we should want from the interface (W3A, etc.). Here's the link to a wiki I've put up to get started: http://mailman.state-of-mind.de/wiki/doku.php I will add more as I get to it. Comments, ideas, improvements are welcome. The server part, for example, is completely empty at the moment... p...@rick -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 45227227 81669 München Telefax +49 89 45227226 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] PyCon 2009 sprint: Webinterface
* Barry Warsaw ba...@list.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 23, 2009, at 10:20 AM, Patrick Ben Koetter wrote: I am collecting information for my work on the MM3 Webinterface while we meet at PyCon 2009 sprint. Which I'm really looking forward to! Apologies for not responding sooner. I guess you have work to do, too. ;) So far I have found the Summer of Code summary http://wiki.list.org/display/DEV/2006/08/20/Summer+of+Code+summary. Any other information/writing I should collect and read before we meet? The only other thing to look at is this branch: https://code.edge.launchpad.net/~mk2s/mailman/restserver It's the work that Maki and Andrew did at last year's sprint. This is for the Mailman 2.2 branch, but there's some interesting work there regarding the REST server. I don't know if we should use this branch in the 3.0 version, but it's worth discussing as a starting point. Agreed. Same idea here. I also believe I had seen a page where you (?) had noted a link for a design you favoured, but I can't find it. Can you post the link or come up with a list of sites you like? (Not that we weren't able to develop design. I just want to get an idea.). Oh man, it either wasn't me or I don't remember. ;) Aesthetic design is something we can turn to later. I for myself want to use our sprint time to work on information architecture, client features etc. I am currently working on a proposal to rearrange the information structure and I am writing down some basic requirements we should want from the interface (W3A, etc.). I'll put it up on a wiki and send the link to the list as soon as I am done. This should put us in the middle of work and not at its beginning when we meet. p...@rick -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 45227227 81669 München Telefax +49 89 45227226 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Short introduction request for input
Mailman Developers, I've recently sent the one or the other mail to this mailing list concerning Mailman and Postfix as well as development of a new web interface for MM3. You might have wondered who I am and why I started posting to the MM developer list without any introduction. Please let me make up for this now. My name is Patrick Ben Koetter. People who use Postfix may now my name from my involvement in the Postfix community. At LISA'07 I was asked by Brad Knowles to join the Python postmaster team, which I did a few months ago. This involved introducing myself to Barry and we started talking about MM3 development, the webinterface, the plan for a REST client/server architecture etc. To cut things short we - my business partner Andreas and Florian, who's been working with us for years - will attend the Mailman sprint at Pycon 2009. The plan is to introduce us to MM3 code and architecture and start to develop a new web interface based on a REST client/server architecture. Andreas and Florian will focus on programming and I will work on the web interface, documentation etc. I hope this gives an idea what our motivation is about and why you (hopefully) are going to see more posts from us to this list in the next time. To start let me ask you for your input on MM3 web interface plans. Barry told me several plans/feature/wish lists have been written and that he would like them to be the base for further development. So far I have found the following links: http://wiki.list.org/display/DEV/Web+Interface http://wiki.list.org/display/DEV/REST+Interface Do you know of more? Thanks, p...@rick P.S. We hope to meet all of you at Pycon 2009! -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 45227227 81669 München Telefax +49 89 45227226 Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] PyCon 2009 sprint: Webinterface
Barry, I am collecting information for my work on the MM3 Webinterface while we meet at PyCon 2009 sprint. So far I have found the Summer of Code summary http://wiki.list.org/display/DEV/2006/08/20/Summer+of+Code+summary. Any other information/writing I should collect and read before we meet? I also believe I had seen a page where you (?) had noted a link for a design you favoured, but I can't find it. Can you post the link or come up with a list of sites you like? (Not that we weren't able to develop design. I just want to get an idea.). Thanks, p...@rick -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung Patrick KoetterTel: 089 45227227 Echinger Strasse 3 Fax: 089 45227226 85386 Eching Web: http://www.state-of-mind.de Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] buildout problems solved
* Barry Warsaw ba...@list.org: Nope, I did. It's a bug, but I only have 32 bit machines available to me. Still, I'll try to work up a fix. Stay tuned. In the meantime, this should not be a show stopper bug for you. Just ignore these failures and have at it! A small fix now you've moved the sources to src/: # diff docs/ALPHA.txt.orig docs/ALPHA.txt 68c68 For now though, start by looking through mailman/config/schema.cfg. --- For now though, start by looking through src/mailman/config/schema.cfg. p...@rick -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung Patrick KoetterTel: 089 45227227 Echinger Strasse 3 Fax: 089 45227226 85386 Eching Web: http://www.state-of-mind.de Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Fail to create a list with MM3 ALPHA
I am having problems creating a mailing list with MM3 ALPHA.
Here's what I have done so far:
I created a config that overrides src/mailman/config/schema.cfg.
Then I started mailmanctl:
# /var/lib/mailman/bin/mailmanctl -C /etc/mailman/mailman.cfg start
Warning! You may encounter permission problems.
Starting Mailman's master qrunner.
mailmanctl is created the necessacry directory structure in /var/lib/mailman/:
# ls -1 /var/lib/mailman/
archives
bin
data
etc
ext
lists
locks
logs
messages
qfiles
spam
It seems to run well:
# ps axf | grep mailman
16215 pts/0S+ 0:00 \_ grep mailman
16164 ?Ss 0:00 /usr/local/bin/python /var/lib/mailman/bin/master -C
/etc/mailman/mailman.cfg
16167 ?S 0:00 \_ /usr/local/bin/python
/var/lib/mailman/bin/qrunner --runner=retry:0:1 -s -C /etc/mailman/mailman.cfg
16168 ?S 0:00 \_ /usr/local/bin/python
/var/lib/mailman/bin/qrunner --runner=out:0:1 -s -C /etc/mailman/mailman.cfg
16169 ?S 0:00 \_ /usr/local/bin/python
/var/lib/mailman/bin/qrunner --runner=bounces:0:1 -s -C /etc/mailman/mailman.cfg
16170 ?S 0:00 \_ /usr/local/bin/python
/var/lib/mailman/bin/qrunner --runner=command:0:1 -s -C /etc/mailman/mailman.cfg
16171 ?S 0:00 \_ /usr/local/bin/python
/var/lib/mailman/bin/qrunner --runner=pipeline:0:1 -s -C
/etc/mailman/mailman.cfg
16172 ?S 0:00 \_ /usr/local/bin/python
/var/lib/mailman/bin/qrunner --runner=lmtp:0:1 -s -C /etc/mailman/mailman.cfg
16173 ?S 0:00 \_ /usr/local/bin/python
/var/lib/mailman/bin/qrunner --runner=in:0:1 -s -C /etc/mailman/mailman.cfg
16174 ?S 0:00 \_ /usr/local/bin/python
/var/lib/mailman/bin/qrunner --runner=virgin:0:1 -s -C /etc/mailman/mailman.cfg
16175 ?S 0:00 \_ /usr/local/bin/python
/var/lib/mailman/bin/qrunner --runner=news:0:1 -s -C /etc/mailman/mailman.cfg
16176 ?S 0:00 \_ /usr/local/bin/python
/var/lib/mailman/bin/qrunner --runner=archive:0:1 -s -C /etc/mailman/mailman.cfg
Then I try to create a list:
# /var/lib/mailman/bin/create_list -C /etc/mailman/mailman.cfg
mail...@mailman.state-of-mind.de
Traceback (most recent call last):
File /var/lib/mailman/bin/create_list, line 18, in module
mailman.bin.create_list.main()
File /root/mailman/src/mailman/bin/create_list.py, line 93, in main
options = ScriptOptions()
File /root/mailman/src/mailman/options.py, line 80, in __init__
self.add_options()
File /root/mailman/src/mailman/bin/create_list.py, line 47, in add_options
super(ScriptOptions, self).add_options()
File /root/mailman/src/mailman/options.py, line 131, in add_options
type='unicode', help=_('The mailing list name'))
File /usr/local/lib/python2.6/optparse.py, line 1004, in add_option
raise TypeError, invalid arguments
TypeError: invalid arguments
What should I do?
Thanks,
p...@rick
--
state of mind
Agentur für Kommunikation, Design und Softwareentwicklung
Patrick KoetterTel: 089 45227227
Echinger Strasse 3 Fax: 089 45227226
85386 Eching Web: http://www.state-of-mind.de
Amtsgericht MünchenPartnerschaftsregister PR 563
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] buildout problems solved
* Barry Warsaw ba...@list.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks to help from the distutils sig, I believe I've solved the buildout problems that were discussed here a while back. By moving the mailman source tree into an 'src' subdirectory, buildout now works regardless of whether you're sharing eggs via ~/.buildout/default.cfg or not. Please give the current 3.0 bzr tree a try. If you want me to cut a new release with the fixes I can do that too. Downloaded branch via bzr, built and ran test. I am not sure what I should look for. Is that what you expect? r...@mailman:mailman# bin/test Running mailman.testing.layers.SMTPLayer tests: Set up mailman.testing.layers.ConfigLayer in 0.942 seconds. Set up mailman.testing.layers.SMTPLayer in 0.003 seconds. Ran 65 tests with 0 failures and 0 errors in 9.587 seconds. Running zope.testing.testrunner.layer.UnitTests tests: Tear down mailman.testing.layers.SMTPLayer in 0.002 seconds. Tear down mailman.testing.layers.ConfigLayer in 0.011 seconds. Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds. Error in test test_passwords (mailman.tests.test_passwords.TestPBKDF2Passwords) Traceback (most recent call last): File /usr/local/lib/python2.6/unittest.py, line 279, in run testMethod() File /root/mailman/src/mailman/tests/test_passwords.py, line 51, in test_passwords secret = passwords.make_secret(self.pw8a, self.scheme) File /root/mailman/src/mailman/passwords.py, line 229, in make_secret secret = scheme_class.make_secret(password) File /root/mailman/src/mailman/passwords.py, line 166, in make_secret digest = PBKDF2PasswordScheme._pbkdf2(password, salt, ITERATIONS) File /root/mailman/src/mailman/passwords.py, line 149, in _pbkdf2 T = U = array(b'l', prf.digest()) ValueError: string length not a multiple of item size Error in test test_passwords_with_funky_chars (mailman.tests.test_passwords.TestPBKDF2Passwords) Traceback (most recent call last): File /usr/local/lib/python2.6/unittest.py, line 279, in run testMethod() File /root/mailman/src/mailman/tests/test_passwords.py, line 58, in test_passwords_with_funky_chars secret = passwords.make_secret(self.pw8b, self.scheme) File /root/mailman/src/mailman/passwords.py, line 229, in make_secret secret = scheme_class.make_secret(password) File /root/mailman/src/mailman/passwords.py, line 166, in make_secret digest = PBKDF2PasswordScheme._pbkdf2(password, salt, ITERATIONS) File /root/mailman/src/mailman/passwords.py, line 149, in _pbkdf2 T = U = array(b'l', prf.digest()) ValueError: string length not a multiple of item size Error in test test_unicode_passwords_with_funky_chars (mailman.tests.test_passwords.TestPBKDF2Passwords) Traceback (most recent call last): File /usr/local/lib/python2.6/unittest.py, line 279, in run testMethod() File /root/mailman/src/mailman/tests/test_passwords.py, line 65, in test_unicode_passwords_with_funky_chars secret = passwords.make_secret(self.pwub, self.scheme) File /root/mailman/src/mailman/passwords.py, line 229, in make_secret secret = scheme_class.make_secret(password) File /root/mailman/src/mailman/passwords.py, line 166, in make_secret digest = PBKDF2PasswordScheme._pbkdf2(password, salt, ITERATIONS) File /root/mailman/src/mailman/passwords.py, line 149, in _pbkdf2 T = U = array(b'l', prf.digest()) ValueError: string length not a multiple of item size Ran 23 tests with 0 failures and 3 errors in 0.367 seconds. Tearing down left over layers: Tear down zope.testing.testrunner.layer.UnitTests in 0.000 seconds. Total: 88 tests, 0 failures, 3 errors in 11.057 seconds. p...@rick -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung Patrick KoetterTel: 089 45227227 Echinger Strasse 3 Fax: 089 45227226 85386 Eching Web: http://www.state-of-mind.de Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] buildout problems solved
* Barry Warsaw ba...@list.org: Downloaded branch via bzr, built and ran test. I am not sure what I should look for. Is that what you expect? r...@mailman:mailman# bin/test Running mailman.testing.layers.SMTPLayer tests: Set up mailman.testing.layers.ConfigLayer in 0.942 seconds. Set up mailman.testing.layers.SMTPLayer in 0.003 seconds. Ran 65 tests with 0 failures and 0 errors in 9.587 seconds. Running zope.testing.testrunner.layer.UnitTests tests: Tear down mailman.testing.layers.SMTPLayer in 0.002 seconds. Tear down mailman.testing.layers.ConfigLayer in 0.011 seconds. Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds. Error in test test_passwords (mailman.tests.test_passwords.TestPBKDF2Passwords) Traceback (most recent call last): File /usr/local/lib/python2.6/unittest.py, line 279, in run testMethod() File /root/mailman/src/mailman/tests/test_passwords.py, line 51, in test_passwords secret = passwords.make_secret(self.pw8a, self.scheme) File /root/mailman/src/mailman/passwords.py, line 229, in make_secret secret = scheme_class.make_secret(password) File /root/mailman/src/mailman/passwords.py, line 166, in make_secret digest = PBKDF2PasswordScheme._pbkdf2(password, salt, ITERATIONS) File /root/mailman/src/mailman/passwords.py, line 149, in _pbkdf2 T = U = array(b'l', prf.digest()) ValueError: string length not a multiple of item size Error in test test_passwords_with_funky_chars (mailman.tests.test_passwords.TestPBKDF2Passwords) Traceback (most recent call last): File /usr/local/lib/python2.6/unittest.py, line 279, in run testMethod() File /root/mailman/src/mailman/tests/test_passwords.py, line 58, in test_passwords_with_funky_chars secret = passwords.make_secret(self.pw8b, self.scheme) File /root/mailman/src/mailman/passwords.py, line 229, in make_secret secret = scheme_class.make_secret(password) File /root/mailman/src/mailman/passwords.py, line 166, in make_secret digest = PBKDF2PasswordScheme._pbkdf2(password, salt, ITERATIONS) File /root/mailman/src/mailman/passwords.py, line 149, in _pbkdf2 T = U = array(b'l', prf.digest()) ValueError: string length not a multiple of item size Error in test test_unicode_passwords_with_funky_chars (mailman.tests.test_passwords.TestPBKDF2Passwords) Traceback (most recent call last): File /usr/local/lib/python2.6/unittest.py, line 279, in run testMethod() File /root/mailman/src/mailman/tests/test_passwords.py, line 65, in test_unicode_passwords_with_funky_chars secret = passwords.make_secret(self.pwub, self.scheme) File /root/mailman/src/mailman/passwords.py, line 229, in make_secret secret = scheme_class.make_secret(password) File /root/mailman/src/mailman/passwords.py, line 166, in make_secret digest = PBKDF2PasswordScheme._pbkdf2(password, salt, ITERATIONS) File /root/mailman/src/mailman/passwords.py, line 149, in _pbkdf2 T = U = array(b'l', prf.digest()) ValueError: string length not a multiple of item size Ran 23 tests with 0 failures and 3 errors in 0.367 seconds. Tearing down left over layers: Tear down zope.testing.testrunner.layer.UnitTests in 0.000 seconds. Total: 88 tests, 0 failures, 3 errors in 11.057 seconds. Nope. I expect no failures! Can you tell me something about the system you're running these tests on? It's a XEN guest on an Intel machine. $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=8.04 DISTRIB_CODENAME=hardy DISTRIB_DESCRIPTION=Ubuntu 8.04.2 Python 2.6 has been built like this: # apt-get build-dep python2.5 # download and unpack, cd ... # ./configure # make # make test ... 325 tests OK. 1 test failed: test_httpservers 35 tests skipped: test_aepack test_al test_applesingle test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dl test_gl test_imageop test_imgfile test_kqueue test_linuxaudiodev test_macos test_macostools test_normalization test_ossaudiodev test_pep277 test_py3kwarn test_scriptpackages test_socketserver test_startfile test_sunaudiodev test_timeout test_urllib2net test_urllibnet test_winreg test_winsound test_zipfile64 Those skips are all expected on linux2. # make install # python Python 2.6.1 (r261:67515, Jan 17 2009, 23:49:39) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2 Type help, copyright, credits or license for more information. Then I did: # bzr branch lp:mailman # cd mailman # python bootstrap.py # bin/buildout # bin/test That's it. p...@rick -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung Patrick KoetterTel: 089 45227227 Echinger Strasse 3 Fax: 089 45227226 85386 Eching Web: http://www.state-of-mind.de Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature
Re: [Mailman-Developers] buildout problems solved
* Barry Warsaw ba...@list.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 28, 2009, at 2:43 PM, Patrick Ben Koetter wrote: It's a XEN guest on an Intel machine. $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=8.04 DISTRIB_CODENAME=hardy DISTRIB_DESCRIPTION=Ubuntu 8.04.2 Let me guess, is it a 64-bit machine? Correct. Did I miss something? Please run this: % python2.6 -c 'import array; print array.array(l).itemsize' p...@mailman:~$ python2.6 -c 'import array; print array.array(l).itemsize' 8 What does this print? How about this: python2.6 -c 'import array; print array.array(L).itemsize' p...@mailman:~$ python2.6 -c 'import array; print array.array(L).itemsize' 8 p...@rick -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung Patrick KoetterTel: 089 45227227 Echinger Strasse 3 Fax: 089 45227226 85386 Eching Web: http://www.state-of-mind.de Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] ANNOUNCE: GNU Mailman 3.0a2 (Grand Designs)
* Barry Warsaw ba...@list.org: The megamerge branch was merged into lazr.config proper and release as lazr.config 1.1. So you don't need this branch. The bzr branch of mm3.0 is up-to-date now, but from the tarball, you should just skip this step and edit buildout.cfg so that the develop line only contains a single dot. Note that bin/test may break for you. If it does, I have a workaround, but I don't yet know if the problem is in buildout or mailman. It worked, more or less: Ran 29 tests with 0 failures and 4 errors in 0.407 seconds. Tearing down left over layers: Tear down zope.testing.testrunner.layer.UnitTests in 0.000 seconds. Test-modules with import problems: eggs.lazr.config-1.1-py2.6.egg.lazr.config.tests eggs.lazr.delegates-1.0-py2.6.egg.lazr.delegates.tests eggs.zc.buildout-1.1.1-py2.6.egg.zc.buildout.tests eggs.zc.buildout-1.1.1-py2.6.egg.zc.buildout.testselectingpython eggs.zc.recipe.egg-1.1.0-py2.6.egg.zc.recipe.egg.tests eggs.zc.recipe.testrunner-1.1.0-py2.6.egg.zc.recipe.testrunner.tests eggs.zope.interface-3.5.0-py2.6-linux-x86_64.egg.zope.interface.common.tests.test_idatetime eggs.zope.interface-3.5.0-py2.6-linux-x86_64.egg.zope.interface.common.tests.test_import_interfaces eggs.zope.interface-3.5.0-py2.6-linux-x86_64.egg.zope.interface.tests.test_adapter eggs.zope.interface-3.5.0-py2.6-linux-x86_64.egg.zope.interface.tests.test_advice eggs.zope.interface-3.5.0-py2.6-linux-x86_64.egg.zope.interface.tests.test_declarations eggs.zope.interface-3.5.0-py2.6-linux-x86_64.egg.zope.interface.tests.test_document eggs.zope.interface-3.5.0-py2.6-linux-x86_64.egg.zope.interface.tests.test_element eggs.zope.interface-3.5.0-py2.6-linux-x86_64.egg.zope.interface.tests.test_interface eggs.zope.interface-3.5.0-py2.6-linux-x86_64.egg.zope.interface.tests.test_odd_declarations eggs.zope.interface-3.5.0-py2.6-linux-x86_64.egg.zope.interface.tests.test_sorting eggs.zope.interface-3.5.0-py2.6-linux-x86_64.egg.zope.interface.tests.test_verify eggs.zope.testing-3.7.1-py2.6.egg.zope.testing.tests eggs.zope.testing-3.7.1-py2.6.egg.zope.testing.testrunner.tests Total: 94 tests, 0 failures, 4 errors in 11.174 seconds. Proceed to create mailman.cfg or wait for workaround? p...@rick -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung Patrick KoetterTel: 089 45227227 Echinger Strasse 3 Fax: 089 45227226 85386 Eching Web: http://www.state-of-mind.de Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] ANNOUNCE: GNU Mailman 3.0a2 (Grand Designs)
* Barry Warsaw ba...@list.org: For detailed information on 3.0a2, please read docs/ALPHA.txt. This file explains how to build Mailman and run the test suite. The docs/ NEWS.txt file contains high level descriptions of what's changed since 3.0a1. Most notably are the new configuration system, the better test suite and installation process, and the new LMTP support. Mailman 3 also contains extensive doctests which explain how certain subsystems work. I'm having problems to build MM3 and I am unexperienced enough with Python (including bzr) to tell if its me or any program standing in the way. So far I have successfully built Python 2.6 on a vanilla Ubuntu/Hardy virtual machine. Then I followed docs/ALPHA.txt from mailman-3.0.0a2 and tried to checkout megamerge. I get this and believe I shouldn't: # bzr branch lp:~barry/lazr.config/megamerge bzr: ERROR: Not a branch: https://code.launchpad.net/;. I can't tell if its a configuration error on my side or a real error. Any help greatly appreciated. p...@rick -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung Patrick KoetterTel: 089 45227227 Echinger Strasse 3 Fax: 089 45227226 85386 Eching Web: http://www.state-of-mind.de Amtsgericht MünchenPartnerschaftsregister PR 563 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
