From barry at list.org Fri Nov 1 19:18:42 2013 From: barry at list.org (Barry Warsaw) Date: Fri, 1 Nov 2013 14:18:42 -0400 Subject: [Mailman-Developers] Mailman Suite beta: what's left? In-Reply-To: <421c057a11001f7ae9b763de6ad807f4@toybox.ca> References: <421c057a11001f7ae9b763de6ad807f4@toybox.ca> Message-ID: <20131101141842.534b3737@anarchist> On Oct 29, 2013, at 05:35 PM, Terri Oda wrote: >1. Need a Postorius interface for associating multiple email addresses with a >single account. This is probably going to require either an email >verification, so we might want to have that as part Mailman Core rather than >doing it directly in Postorius. Short term, I don't care how it's done as >long as it verifies that the user actually has access to the addresses they >link together. If it's easy(-ish) to do in Postorius, then I think that might be best for now. Among the half finished branches I have sitting around is one to improve the integration between the core and the web u/i, and right now it has too much legacy crap to be generally useful. What I mean is, if the core is going to send an email that contains a url, it has to be configured to properly calculate the url. In MM2.1, this was all nicely hardcoded because the only ui was the built-in one. Now, even with Postorius, the core can't a priori *know* what proper urls would look like, so sending confirmations with urls in them could be wrong. So this feature in particular, if Postorius can do all the necessary confirmations, I can much more easily provide an API that Postorius can call to associate an email address with a given user. Cheers, -Barry From barry at list.org Fri Nov 1 19:20:08 2013 From: barry at list.org (Barry Warsaw) Date: Fri, 1 Nov 2013 14:20:08 -0400 Subject: [Mailman-Developers] Mailman Suite beta: what's left? In-Reply-To: <52710E5E.6070805@bompard.org> References: <421c057a11001f7ae9b763de6ad807f4@toybox.ca> <87bo27tkh7.fsf@uwakimon.sk.tsukuba.ac.jp> <52710E5E.6070805@bompard.org> Message-ID: <20131101142008.772a7dbc@anarchist> On Oct 30, 2013, at 02:49 PM, Aur?lien Bompard wrote: >I've also created a branch and a pull request in Launchpad with lots of >modifications to the import script. I'm slowly working my way through this branch. I'll have some time this weekend to hopefully finish it up. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Fri Nov 1 19:24:14 2013 From: barry at list.org (Barry Warsaw) Date: Fri, 1 Nov 2013 14:24:14 -0400 Subject: [Mailman-Developers] Mailman Suite beta: what's left? In-Reply-To: <8738njta1o.fsf@uwakimon.sk.tsukuba.ac.jp> References: <421c057a11001f7ae9b763de6ad807f4@toybox.ca> <20131029220650.GB1988@sys4.de> <20131030082117.GE6777@charite.de> <8738njta1o.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20131101142414.06bf8c76@anarchist> On Oct 30, 2013, at 05:52 PM, Stephen J. Turnbull wrote: >Of course it will be MTA-specific. I haven't done it on Postfix, but >for Exim you just add a Mailman3 router and transport ahead of the >Mailman2 router (I've already submitted the docs for that -- they're >very generic -- don't know if Barry's merged them yet), and start >adding Mailman3 lists. This branch? https://code.launchpad.net/~stephen-xemacs/mailman/exim4/+merge/187302j If so, not yet, but it's in my todo list (a.k.a. browser tabs :). -Barry From stephen at xemacs.org Sat Nov 2 08:06:45 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 02 Nov 2013 16:06:45 +0900 Subject: [Mailman-Developers] Mailman Suite beta: what's left? In-Reply-To: <20131101141842.534b3737@anarchist> References: <421c057a11001f7ae9b763de6ad807f4@toybox.ca> <20131101141842.534b3737@anarchist> Message-ID: <87habvs2nu.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > So this feature in particular, if Postorius can do all the > necessary confirmations, I can much more easily provide an API that > Postorius can call to associate an email address with a given user. I'm getting that ol' sinking feeling. Either Postorius is *the* Mailman 3 user/admin UI, or it isn't. If it is, shouldn't we merge the projects sooner rather than later? If it isn't, Mailman should be able to do this kind of thing itself. It should be reasonably low-cost to build a simple django app (or lower-level, SimpleHTTPServera app) that handles confirmation. Or we can do without web confirmation URLs if there's no admin UI available. From stephen at xemacs.org Sat Nov 2 08:09:27 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 02 Nov 2013 16:09:27 +0900 Subject: [Mailman-Developers] Mailman Suite beta: what's left? In-Reply-To: <20131101142414.06bf8c76@anarchist> References: <421c057a11001f7ae9b763de6ad807f4@toybox.ca> <20131029220650.GB1988@sys4.de> <20131030082117.GE6777@charite.de> <8738njta1o.fsf@uwakimon.sk.tsukuba.ac.jp> <20131101142414.06bf8c76@anarchist> Message-ID: <87fvrfs2jc.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > >Mailman2 router (I've already submitted the docs for that -- they're > >very generic -- don't know if Barry's merged them yet), and start > >adding Mailman3 lists. > > This branch? > > https://code.launchpad.net/~stephen-xemacs/mailman/exim4/+merge/187302j Yes, but don't worry about it. It's straightforward and I'm happy to support Exim users who want to try Mailman 3 (don't post all at once, now...). Steve From paul at boddie.org.uk Sun Nov 3 22:37:52 2013 From: paul at boddie.org.uk (Paul Boddie) Date: Sun, 3 Nov 2013 22:37:52 +0100 Subject: [Mailman-Developers] Wiki Migration Update Message-ID: <201311032237.52755.paul@boddie.org.uk> Hello, Time has passed and some more time has been spent on the wiki migration. As always, the results can be found here: http://mmwiki.boddie.org.uk/ The archived content now reflects the real wiki from yesterday - 2nd November - so the translated content should reflect the existing wiki fairly accurately and include recent edits. Dates and History ----------------- One matter that was not addressed at all before now was that of accurate date information in the page histories. I needed to patch the MoinMoin package installer for this, and there turns out to be a good reason why it doesn't support preserving the editing dates: the edit log would need sorting afterwards, and that would probably need to be done offline. Moreover, taking different packages of pages and combining them requires the histories from the different packages to be merged, so I had to write a script to do this. The result is that, subject to time zone ambiguity, the edit dates should be accurate in the converted content and the RecentChanges should reflect what you see on the current Confluence wiki. Users ----- Last time, I reintroduced user details to the migrated wiki, but one item that remains is that of actually importing users. To illustrate user import, I imported four recent users of the wiki that happened to be useful for testing various aspects of the conversion. For example: http://mmwiki.boddie.org.uk/DEV/A_5_minute_guide_to_get_the_Mailman_web_UI_running Here, you'll see that the comments at the bottom of the page bear the name of the commenter, who helpfully supplied some non-ASCII characters in her name so that I could encounter some problems with MoinMoin's command option handling. :-) As I mentioned last time, the method of acquiring user profile information is not as satisfactory as that of getting the page data out of Confluence, but I imagine that people will want to review the user list, exclude obvious spammers, and then send out account reset e-mails - there must be some e-mail experts here willing to do that nicely ;-) - and so the process will necessarily involve some manual work. Redirects --------- Also done last time were redirects: http://mmwiki.boddie.org.uk/x/AgA3 http://mmwiki.boddie.org.uk/pages/viewpage.action?pageId=3604482 This time, I've added support for various other Confluence URL paths, such as searching: http://mmwiki.boddie.org.uk/dosearchsite.action?searchQuery.queryString=exim&searchQuery.spaceKey=DOC The special PDF export action is supported, although this really requires Java, fop, xsltproc and DocBook XSL resources: http://mmwiki.boddie.org.uk/pages/doexportpage.action?pageId=3604482&type=TYPE_PDF Confluence seems to use this kind of URL as well: http://mmwiki.boddie.org.uk/spaces/flyingpdf/pdfpageexport.action?pageId=3604482 And there's also the highly sophisticated dashboard action (which just redirects to the front page): http://mmwiki.boddie.org.uk/dashboard.action Comments -------- I have reviewed the import of comments and improved the functionality of the MoinMoin extensions supporting new comments. I gave an example of comments above in the "Users" section. New comments assign complete ownership of a comment to the author, but that author must have write access to the page on which the comment will appear (even though they are actually making a subpage). Existing comments from Confluence already assign ownership to the author of the comment when converted. To Do ----- I always provide a list of things that still need doing, so here are some familiar items: It might also be nice to have a list of attachments on pages that have them, and I will take a look to see how Confluence tends to present such things. (I'm not sure if this is a great priority, though. You can always follow the "Attachments" link to see what's there.) User home pages should probably be populated and have things like profile images (if provided), activity indicators, and maybe the dashboard functionality should be emulated, too. (People agreed that this wasn't a priority.) In Conclusion ------------- As I have mentioned previously, the source code for the converter can be found here: http://hgweb.boddie.org.uk/ConfluenceConverter/ Please take another look at your favourite pages and let me know if anything has gone badly wrong in the conversion process. With this I hope we are nearing the point of final migration. Paul From mark at msapiro.net Mon Nov 4 01:20:06 2013 From: mark at msapiro.net (Mark Sapiro) Date: Sun, 03 Nov 2013 16:20:06 -0800 Subject: [Mailman-Developers] Wiki Migration Update In-Reply-To: <201311032237.52755.paul@boddie.org.uk> References: <201311032237.52755.paul@boddie.org.uk> Message-ID: <5276E836.3030301@msapiro.net> On 11/03/2013 01:37 PM, Paul Boddie wrote: > > Please take another look at your favourite pages and let me know if anything > has gone badly wrong in the conversion process. > > With this I hope we are nearing the point of final migration. I've looked and it seems really good. I agree that we are very close if not there on everything that matters to me. Thank you Paul for this work. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at list.org Mon Nov 4 22:16:38 2013 From: barry at list.org (Barry Warsaw) Date: Mon, 4 Nov 2013 16:16:38 -0500 Subject: [Mailman-Developers] Mailman Suite beta: what's left? In-Reply-To: <87habvs2nu.fsf@uwakimon.sk.tsukuba.ac.jp> References: <421c057a11001f7ae9b763de6ad807f4@toybox.ca> <20131101141842.534b3737@anarchist> <87habvs2nu.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20131104161638.5f62eb22@anarchist> On Nov 02, 2013, at 04:06 PM, Stephen J. Turnbull wrote: > > So this feature in particular, if Postorius can do all the > > necessary confirmations, I can much more easily provide an API that > > Postorius can call to associate an email address with a given user. > >I'm getting that ol' sinking feeling. Either Postorius is *the* >Mailman 3 user/admin UI, or it isn't. If it is, shouldn't we merge >the projects sooner rather than later? > >If it isn't, Mailman should be able to do this kind of thing itself. > >It should be reasonably low-cost to build a simple django app (or >lower-level, SimpleHTTPServera app) that handles confirmation. > >Or we can do without web confirmation URLs if there's no admin UI >available. I think it definitely makes sense for there to be a REST API to explicitly add an email address to a user, or to link an existing address to a user. There's already an API for verifying (and unverifying) an email address. This API would not do any confirmations - it would trust the client to have done whatever it takes to ensure that the user owning the first (existing) address also owns the second address. If we want to combine linking and verifying in one step, then the client would be trusted to ensure that the user owns both addresses *and* that the second address is actually valid. I'm guessing this would be the most common use case. If the client wants to leave it to the core to do the confirmations, I think that would be a separate API. What would be the protocol, given that we want to make sure that both addresses are owned by the same user *and* we want to be sure that the confirmation process can't be used to mine information such as potential addresses subscribed to the system? Strawman: Generate a unique token for the dual-confirmation event. Send a confirmation message to the user's preferred address. It would say something like "Someone has requested linking foo at example.com to your Mailman account. If this was you, please reply (and/or click) to confirm this request. The request will not be completed until you complete a similar confirmation in your foo at example.com account. If you did not make this request, ignore this message." The Reply-To address would contain the token. (With sufficient hand-waving, the URL would contain the token.) Send a message to the new address saying "You have requested a registration of your foo at example.com address to the Mailman server at example.net. Reply (and/or click) to confirm." Maybe they get different tokens. In any case, nothing would happen until both requests are confirmed. The confirmation to the new address is specifically crafted not to reveal whether the original address is registered or not. E.g. if the core had to do a new user registration, it would send a similar message, and nothing about the original account would be leaked in this second email. To a new user, it would just look like an original registration confirmation message. The "click" part is where we get hand-wavy. I need to finish up my template branch so that these types of "core knows something about the web ui" assumptions don't have to be hard-coded. Even if Postorius is the default ui, we may not know exactly how to contact it, or whether the site has customized various texts. I'm thinking something similar to the way the welcome message is now retrieved via url. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From aurelien at bompard.org Tue Nov 5 10:11:21 2013 From: aurelien at bompard.org (=?ISO-8859-1?Q?Aur=E9lien_Bompard?=) Date: Tue, 05 Nov 2013 10:11:21 +0100 Subject: [Mailman-Developers] Mailman Suite beta: what's left? In-Reply-To: <5272CF5F.2010408@gmail.com> References: <421c057a11001f7ae9b763de6ad807f4@toybox.ca> <5272CF5F.2010408@gmail.com> Message-ID: <5278B639.5030403@bompard.org> > Re: Hyperkitty: Last time I checked it didn't seem to implement any > access control for non-public lists. This isn't really a bug, but it > restricts HK to be used with public lists only. > @Aurelien: Is that correct? If so: Would you mind me suggesting some > ideas to add member checking for private lists? This has landed in HyperKitty a couple of weeks ago, but it's not in the released tarballs yet. Will update soon. Aur?lien -- http://aurelien.bompard.org ~~~~~~ xmpp:aurelien at bompard.org "Pessimism is a luxury of good times. In difficult times, pessimism is a self-fulfilling, self-inflicted death sentence" -- Evelin Linder From colin.mailinglist at gmail.com Thu Nov 7 02:50:33 2013 From: colin.mailinglist at gmail.com (Colin Fleming) Date: Thu, 7 Nov 2013 14:50:33 +1300 Subject: [Mailman-Developers] REST API call for creating archive view? Message-ID: Hi all, I'm interested in using Mailman to set up a mailing list for my product. I'd like to have it be fully integrated into my website, so I'm planning to use Mailman 3 and the REST API. I've checked out mailman.client and poked around, and also looked at http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/files/head:/src/mailman/rest/docs/, but the one thing I couldn't see was any way to access mail messages themselves. Is there a way to create an archive view (i.e. present a view of all messages in a list and allow reading particular mails) using the current API? Thanks, Colin From barry at list.org Thu Nov 7 16:15:51 2013 From: barry at list.org (Barry Warsaw) Date: Thu, 7 Nov 2013 10:15:51 -0500 Subject: [Mailman-Developers] REST API call for creating archive view? In-Reply-To: References: Message-ID: <20131107101551.3a8cb624@anarchist> On Nov 07, 2013, at 02:50 PM, Colin Fleming wrote: >I'm interested in using Mailman to set up a mailing list for my product. >I'd like to have it be fully integrated into my website, so I'm planning to >use Mailman 3 and the REST API. I've checked out mailman.client and poked >around, and also looked at >http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/files/head:/src/mailman/rest/docs/, >but the one thing I couldn't see was any way to access mail messages >themselves. Is there a way to create an archive view (i.e. present a view >of all messages in a list and allow reading particular mails) using the >current API? While we could (and should) add a REST API for accessing the IMessageStore, I think this will not be very useful for you. That API would just return the message text based on the Message-ID (or hash) that you want to look up. It wouldn't have any support for common archiving structure like threading, etc. It would be better for you to implement an IArchiver plugin to get the messages fed to you as they come in. Of course, then you'd have to implement the archiver yourself, or you can use one of the standard archiver plugins such as for HyperKitty or MHonArc. And actually, having a REST API to HyperKitty is probably the best long-term approach. Perhaps Aur?lien can speak to that. -Barry From sca at andreasschulze.de Thu Nov 7 08:28:42 2013 From: sca at andreasschulze.de (Andreas Schulze) Date: Thu, 07 Nov 2013 08:28:42 +0100 Subject: [Mailman-Developers] Mailman DMARC Support (it's not what you think!) In-Reply-To: References: Message-ID: <20131107082842.Horde.shqWasqTzTgr_8ncOBAg4Q1@horde.andreasschulze.de> Zitat von Jim Popovitch : > ... that mailing lists, like MTAs, have no business modifying the > From header; I fully agree with these opinions an like to add "should not modify the messagebody" > nor should mailing lists accept mail that they knowingly can't reflect. "reflect" is a really good word for the listmanagers job. Andreas From franck at peachymango.org Thu Nov 7 19:29:51 2013 From: franck at peachymango.org (Franck Martin) Date: Thu, 7 Nov 2013 12:29:51 -0600 (CST) Subject: [Mailman-Developers] Mailman DMARC Support (it's not what you think!) In-Reply-To: References: <20131107082842.Horde.shqWasqTzTgr_8ncOBAg4Q1@horde.andreasschulze.de> Message-ID: <2139657187.144285.1383848991796.JavaMail.zimbra@peachymango.org> ----- Original Message ----- > From: "Andreas Schulze" > To: mailman-developers at python.org > Sent: Wednesday, November 6, 2013 11:28:42 PM > Subject: Re: [Mailman-Developers] Mailman DMARC Support (it's not what you think!) > > > Zitat von Jim Popovitch : > > > ... that mailing lists, like MTAs, have no business modifying the > > From header; > I fully agree with these opinions an like to add "should not modify > the messagebody" > The lists at apache.org do not modify the body and works well with DKIM/DMARC. However there are lists that do modify the message body... From franck at peachymango.org Thu Nov 7 19:27:06 2013 From: franck at peachymango.org (Franck Martin) Date: Thu, 7 Nov 2013 12:27:06 -0600 (CST) Subject: [Mailman-Developers] Mailman DMARC Support (it's not what you think!) In-Reply-To: References: Message-ID: <1656285249.144207.1383848826424.JavaMail.zimbra@peachymango.org> Yes this is one of the other options to do. The last one is to do Original Authentication Header, but transitive trust on email is complicated. To be noted, the procedure, in this patch, to find the policy record in the DNS, is not in line with the best current practice specified in the DMARC spec, far from it. Also, what about p=quarantine? ----- Original Message ----- From: "Jim Popovitch" To: Mailman-Developers at python.org Sent: Sunday, October 20, 2013 3:17:17 PM Subject: [Mailman-Developers] Mailman DMARC Support (it's not what you think!) Hello, Having read the archives, I see that (at least 6 of) you are aware of DMARC, or as I like to call it YAPFS. (Yet Another Panacea For Spam) :-) Earlier this year Mark asked me to run by MM-Dev a patch that Phil Pennock and I collaborated on. Mark, thank you for your valuable feedback, I have addressed all but 1 of those issues. Phil's and my take is that mailing lists, like MTAs, have no business modifying the From header; nor should mailing lists accept mail that they knowingly can't reflect. To that end, we have added support for testing the From domain for a DMARC p=reject policy, and if it exists, allowing lists to Accept/Hold/Reject/Discard the message. Here is the LP diff for your perusal: http://bazaar.launchpad.net/~jimpop/mailman/dmarc-reject/revision/1379?remember=1379&compare_revid=1374 I will soon be porting this to 3.0, and I will return here for input on that as well. Thank you everyone for your valued opinions, -Jim P. _______________________________________________ Mailman-Developers mailing list Mailman-Developers at 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/franck%40peachymango.org Security Policy: http://wiki.list.org/x/QIA9 From jtrentadams at gmail.com Thu Nov 7 19:23:35 2013 From: jtrentadams at gmail.com (J. Trent Adams) Date: Thu, 07 Nov 2013 11:23:35 -0700 Subject: [Mailman-Developers] Mailman DMARC Support (it's not what you think!) In-Reply-To: References: Message-ID: <527BDAA7.3000309@gmail.com> Jim - On 10/20/13 4:17 PM, Jim Popovitch wrote: > Hello, > > Having read the archives, I see that (at least 6 of) you are aware of > DMARC, or as I like to call it YAPFS. (Yet Another Panacea For Spam) > :-) Heh - If only DMARC was as successful at stopping spam as it is in shutting down spoofed domain mail! Wow, that'd be fantastic. . . I'd love to stop receiving unwanted solicitations. But that's not what it does. As it turns out, DMARC has proven so remarkably successful at eliminating spoofed domain phishing attacks. So much so that it's already saving us a huge, non-trivial, amount of money per year (with a trend line of savings that's continuing to increase). I wish we could share the actual dollar value we're saving by protecting our customers, but that information isn't public. Suffice it to say that it works (and works tremendously well). > > Earlier this year Mark asked me to run by MM-Dev a patch that Phil > Pennock and I collaborated on. Mark, thank you for your valuable > feedback, I have addressed all but 1 of those issues. > > Phil's and my take is that mailing lists, like MTAs, have no business > modifying the From header; nor should mailing lists accept mail that > they knowingly can't reflect. To that end, we have added support for > testing the From domain for a DMARC p=reject policy, and if it exists, > allowing lists to Accept/Hold/Reject/Discard the message. Here's my problem with this solution: it forces participants of mailing lists to send from domains that do not have adequate protection against spoofed domain attacks. Doing so then opens a hole in the defenses which can then be abused. I can speak to this from experience on email security for one of the most phished brands (the most phished, if you trust APWG's reporting). We set up an unprotected domain specifically for mailing lists, and we watched that as our DMARC protection across our other domains came online, the abuse on our unprotected domains increased. Finally, we'd locked everything down other than the mailing list domain, and then it became a primary target of abuse. . . which resulted in us having to shut it down. Now we're left participating on mailing lists using personal mail accounts. As you can imagine, that makes many departments in the organization really nervous for a variety of obvious reasons. Sure, we're slightly unique in that we're highly susceptable to phishing attacks, and a common abuse vector is domain spoofing. . . but as we lock down our doors, we're seeing shifts by the attackers to other, less protected targets. So, the problems that vex us today are beginning to nip at the heels of the victims of tomorrow. . . . and given the rampant problem of password reuse, any credentials phished from an unprotected domain can easily be used to attack a domain that is protected. Again, I wish I could share the numbers of these types of attacks, but they're staggeringly large. And it's incredibly annoying that our hands are tied since humans will do what humans do (e.g. reuse passwords everywhere). Not good, that. It's unfortunate that the real world infringes on the perfection of a pure "reflector" architecture. I wish that solutions were beautiful and unblemished. Sadly, reality is messy, and some consideration for compromise is necessary for solutions to be effective. Besides, mailing lists modify messages they "reflect" all the time. They pre-pend list identifiers to the subject line (which makes my life much easier), and also post-pend list management options (which is a regulatory requirement in some jurisdictions). So, if we want to be purists, no modifications should be allowed. But that's taking the argument to an extreme. Instead, we should consider a benefit analysis for each proposed change. And in this particular case, as more senders are adopting DMARC each and every day for entirely valid security and economic reasons, I believe that modifying the RFC5322.From field is a perfectly reasonable option. . . . unless someone can think of another clever way to maintain effective end-to-end email authentication in a novel way? Perhaps through the broader adoption of transitive trust (e.g. the Original Authentication Results header)? Anyway, thanks for your careful consideration, and I do look forward to continuing to discuss viable options for keeping email as trusted and secure as possible. Yours, Trent > > Here is the LP diff for your perusal: > http://bazaar.launchpad.net/~jimpop/mailman/dmarc-reject/revision/1379?remember=1379&compare_revid=1374 > > I will soon be porting this to 3.0, and I will return here for input > on that as well. > > Thank you everyone for your valued opinions, > > -Jim P. > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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/jtrentadams%40gmail.com > > Security Policy: http://wiki.list.org/x/QIA9 From jimpop at gmail.com Thu Nov 7 20:49:30 2013 From: jimpop at gmail.com (Jim Popovitch) Date: Thu, 7 Nov 2013 14:49:30 -0500 Subject: [Mailman-Developers] Mailman DMARC Support (it's not what you think!) In-Reply-To: <1656285249.144207.1383848826424.JavaMail.zimbra@peachymango.org> References: <1656285249.144207.1383848826424.JavaMail.zimbra@peachymango.org> Message-ID: On Thu, Nov 7, 2013 at 1:27 PM, Franck Martin wrote: > To be noted, the procedure, in this patch, to find the policy record in the > DNS, is not in line with the best current practice specified in the DMARC > spec, far from it. Care to offer some insight? > Also, what about p=quarantine? I think that should be treated the same as p=reject. Don't send me your junk for storage! :-) Thanks! -Jim P. From jimpop at gmail.com Thu Nov 7 20:58:45 2013 From: jimpop at gmail.com (Jim Popovitch) Date: Thu, 7 Nov 2013 14:58:45 -0500 Subject: [Mailman-Developers] Mailman DMARC Support (it's not what you think!) In-Reply-To: <527BDAA7.3000309@gmail.com> References: <527BDAA7.3000309@gmail.com> Message-ID: On Thu, Nov 7, 2013 at 1:23 PM, J. Trent Adams wrote: > > Jim - > > On 10/20/13 4:17 PM, Jim Popovitch wrote: >> Hello, >> >> Having read the archives, I see that (at least 6 of) you are aware of >> DMARC, or as I like to call it YAPFS. (Yet Another Panacea For Spam) >> :-) > > Heh - If only DMARC was as successful at stopping spam as it is in > shutting down spoofed domain mail! Wow, that'd be fantastic. . . I'd > love to stop receiving unwanted solicitations. But that's not what it does. > > As it turns out, DMARC has proven so remarkably successful at > eliminating spoofed domain phishing attacks. So much so that it's > already saving us a huge, non-trivial, amount of money per year (with a > trend line of savings that's continuing to increase). I wish we could > share the actual dollar value we're saving by protecting our customers, > but that information isn't public. Suffice it to say that it works (and > works tremendously well). That's good. DMARC does have a purpose in transactional emails. >> Earlier this year Mark asked me to run by MM-Dev a patch that Phil >> Pennock and I collaborated on. Mark, thank you for your valuable >> feedback, I have addressed all but 1 of those issues. >> >> Phil's and my take is that mailing lists, like MTAs, have no business >> modifying the From header; nor should mailing lists accept mail that >> they knowingly can't reflect. To that end, we have added support for >> testing the From domain for a DMARC p=reject policy, and if it exists, >> allowing lists to Accept/Hold/Reject/Discard the message. > > Here's my problem with this solution: it forces participants of mailing > lists to send from domains that do not have adequate protection against > spoofed domain attacks. Doing so then opens a hole in the defenses which > can then be abused. > > I can speak to this from experience on email security for one of the > most phished brands (the most phished, if you trust APWG's reporting). > We set up an unprotected domain specifically for mailing lists, and we > watched that as our DMARC protection across our other domains came > online, the abuse on our unprotected domains increased. Finally, we'd > locked everything down other than the mailing list domain, and then it > became a primary target of abuse. . . which resulted in us having to > shut it down. > > Now we're left participating on mailing lists using personal mail > accounts. As you can imagine, that makes many departments in the > organization really nervous for a variety of obvious reasons. Which .... appears to be working well for you, mr jtrentadams@ ;-) > Sure, we're slightly unique in that we're highly susceptable to phishing > attacks, and a common abuse vector is domain spoofing. . . but as we > lock down our doors, we're seeing shifts by the attackers to other, less > protected targets. So, the problems that vex us today are beginning to > nip at the heels of the victims of tomorrow. > > . . . and given the rampant problem of password reuse, any credentials > phished from an unprotected domain can easily be used to attack a domain > that is protected. Again, I wish I could share the numbers of these > types of attacks, but they're staggeringly large. And it's incredibly > annoying that our hands are tied since humans will do what humans do > (e.g. reuse passwords everywhere). Not good, that. > > It's unfortunate that the real world infringes on the perfection of a > pure "reflector" architecture. I wish that solutions were beautiful and > unblemished. Sadly, reality is messy, and some consideration for > compromise is necessary for solutions to be effective. > > Besides, mailing lists modify messages they "reflect" all the time. They > pre-pend list identifiers to the subject line (which makes my life much > easier), and also post-pend list management options (which is a > regulatory requirement in some jurisdictions). > > So, if we want to be purists, no modifications should be allowed. But > that's taking the argument to an extreme. Instead, we should consider a > benefit analysis for each proposed change. And in this particular case, > as more senders are adopting DMARC each and every day for entirely valid > security and economic reasons, I believe that modifying the RFC5322.From > field is a perfectly reasonable option. To be fair, Mailman doesn't modify the body, it does add footer attachments and follows existing RFC requirements for appending headers. I wouldn't necessarily classify that in the same way as RFC5322 From spoofing. > . . . unless someone can think of another clever way to maintain > effective end-to-end email authentication in a novel way? Perhaps > through the broader adoption of transitive trust (e.g. the Original > Authentication Results header)? > > Anyway, thanks for your careful consideration, and I do look forward to > continuing to discuss viable options for keeping email as trusted and > secure as possible. I'm not convince that email trust and security have any impact whatsoever on Mailman or MLMs in general. I believe you can have secure and trusted email (i.e. ibm.com) yet not break MLMs. -Jim P. From jtrentadams at gmail.com Thu Nov 7 23:12:17 2013 From: jtrentadams at gmail.com (J. Trent Adams) Date: Thu, 07 Nov 2013 15:12:17 -0700 Subject: [Mailman-Developers] Mailman DMARC Support (it's not what you think!) In-Reply-To: References: <527BDAA7.3000309@gmail.com> Message-ID: <527C1041.5050205@gmail.com> Jim - On 11/7/13 12:58 PM, Jim Popovitch wrote: > On Thu, Nov 7, 2013 at 1:23 PM, J. Trent Adams wrote: [snip] > Now we're left participating on mailing lists using personal mail > accounts. As you can imagine, that makes many departments in the > organization really nervous for a variety of obvious reasons. > Which .... appears to be working well for you, mr > jtrentadams@ ;-) Indeed! . . . though let's keep that on the down-low given the concern about the apparent ease with which some entities seem to have access to these accounts. ;) [ snip ] > To be fair, Mailman doesn't modify the body, it does add footer > attachments and follows existing RFC requirements for appending > headers. I wouldn't necessarily classify that in the same way as > RFC5322 From spoofing. Yeah, that's a fair point about Mailman using appropriate mechanisms to append the footers. . . But if a sender signs the subject header, does the signature break if Mailman pre-pends (useful) info? At the end of the day, though, assuming SPF and DKIM are the most effective means of email authentication, DMARC is the only (current) way to effectively close the loop. And Mailman (my preferred MLM by far) has an excellent opportunity to leap ahead of the pack and keep that loop from being severed. > >> . . . unless someone can think of another clever way to maintain >> effective end-to-end email authentication in a novel way? Perhaps >> through the broader adoption of transitive trust (e.g. the Original >> Authentication Results header)? >> >> Anyway, thanks for your careful consideration, and I do look forward to >> continuing to discuss viable options for keeping email as trusted and >> secure as possible. > I'm not convince that email trust and security have any impact > whatsoever on Mailman or MLMs in general. I believe you can have > secure and trusted email (i.e. ibm.com) yet not break MLMs. > > -Jim P. Hmmm. . . that's an interesting take. A quick glance at ibm.com shows that they SPF -all, so at least their top level domain shouldn't be sending mail at all. Is that what you meant? Glancing at their subdomains (e.g. us.ibm.com), though, shows that they're protected by SPF ~all and not DMARC. Given that many major mailbox providers only soft fail ~all, it's still likely to see spoofed domain mail reach the recipient. . . Or am I missing something clever that they're doing (which I should probably know about)? Other than that, I believe that MLMs in general play a huge part in trusted and secure mail. Sure, they're not on the front line, but if they require a hobbling of security of their subscribers to participate, I see that as not so great. Now, it's not a perfect analogy, but what if in order to ride the city bus you were required to lick the handrails? OK, it's not pretty, but that'd be requiring you to do something inherently dangerous simply to take advantage of public transportation. I don't know about you, but I'd prefer another mode of transport. Anyway, I'd like to think that MLMs in general, and Mailman in specific as the Cadillac (or should we say Tesla now?) of MLMs, should provide an option to participate in as secure communication as possible. Someone's going to do it eventually, and I'm hoping that we can build on the momentum here given that there are a few reasonably visible lists willing to cut over to Mailman once their subscribers have a better experience. Thanks, by the way, for the discussion and consideration. - Trent From jimpop at gmail.com Thu Nov 7 23:27:39 2013 From: jimpop at gmail.com (Jim Popovitch) Date: Thu, 7 Nov 2013 17:27:39 -0500 Subject: [Mailman-Developers] Mailman DMARC Support (it's not what you think!) In-Reply-To: <527C1041.5050205@gmail.com> References: <527BDAA7.3000309@gmail.com> <527C1041.5050205@gmail.com> Message-ID: On Thu, Nov 7, 2013 at 5:12 PM, J. Trent Adams wrote: > should provide an option to participate in as secure communication as possible. Randomly applying security distinctions, to RFC de'jour, is not really helping. If you want true message security, then PGP/GPG is the only universal way. If you are just looking to protect the integrity of the pathway, might I suggest that a wrapper around 2 different technologies (one being header reliability and the other being source reliability) is just that... a wrapper (or as I say, a panacea). If you truly wanted secure comms, DMARC would be mandating PGP and going after MUAs.... but I digress. -Jim P. From jtrentadams at gmail.com Fri Nov 8 01:00:56 2013 From: jtrentadams at gmail.com (J. Trent Adams) Date: Thu, 07 Nov 2013 17:00:56 -0700 Subject: [Mailman-Developers] Mailman DMARC Support (it's not what you think!) In-Reply-To: References: <527BDAA7.3000309@gmail.com> <527C1041.5050205@gmail.com> Message-ID: <527C29B8.7060202@gmail.com> Jim - On 11/7/13 3:27 PM, Jim Popovitch wrote: > On Thu, Nov 7, 2013 at 5:12 PM, J. Trent Adams wrote: >> should provide an option to participate in as secure communication as possible. > Randomly applying security distinctions, to RFC de'jour, is not really > helping. Well, here we disagree. DMARC is far from random (in development since 2007), and it's actually helping. And not just on the margins. We're seeing significant improvement in the real world at Internet scale for millions of our customers. It'd be fantastic to see Mailman trumpet an option that allows those who want to take advantage of it to drop their old, beat-up MLM and join the party. > If you want true message security, then PGP/GPG is the only > universal way. If you are just looking to protect the integrity of > the pathway, might I suggest that a wrapper around 2 different > technologies (one being header reliability and the other being source > reliability) is just that... a wrapper (or as I say, a panacea). If > you truly wanted secure comms, DMARC would be mandating PGP and going > after MUAs.... Here, though, I totally agree with you! After all, I earned my degree in astrophysics, and we modeled everything using perfect theoretical spheres. Sadly, our models always fell short under close scrutiny. . . fortunately, as opposed to physics, the astro variety of the science didn't often come under close scrutiny. Talk about being left off the hook! That being said, in a more nuanced, complex, messy world, theoretical solutions don't always live up to the promise. So, yeah, it'd be super kewl to ask all our customers (and all the communication channels) to get on the bandwagon with encryption. I've got stacks and stacks of real world data and research that explains why that's simply not viable (today). DMARC, on the other hand, emerged as an empirical experiment on what works today, in the real world. It was a lot of trial and error until we happened to get the mix right. It's no panacea (it only stops one type of particularly nasty attack), but you're right, it's just a wrapper. Fortunately, it works, so the Lords of Kobol be praised! Finally, some defense against the maurauding Cylons (even though it's a mish-mash of low-tech bits and bobs). . . . amusingly, this reminds me of the LAN parties we used to have. It wasn't pretty, but the goal was to get the Sinclair to talk to the Commodore using whatever means necessary (air nets were particularly hilarious, albeit incredibly hard on the ears). > but I digress. Yeah, but aren't digressions fun? Happy to continue the conversation off-list so that we don't bore the rest of the crew. Cheers, Trent > > -Jim P. From franck at peachymango.org Fri Nov 8 01:44:06 2013 From: franck at peachymango.org (Franck Martin) Date: Thu, 7 Nov 2013 18:44:06 -0600 (CST) Subject: [Mailman-Developers] Mailman DMARC Support (it's not what you think!) In-Reply-To: References: <1656285249.144207.1383848826424.JavaMail.zimbra@peachymango.org> Message-ID: <2022161507.159429.1383871446211.JavaMail.zimbra@peachymango.org> ----- Original Message ----- > From: "Jim Popovitch" > To: Mailman-Developers at python.org > Sent: Thursday, November 7, 2013 11:49:30 AM > Subject: Re: [Mailman-Developers] Mailman DMARC Support (it's not what you think!) > > On Thu, Nov 7, 2013 at 1:27 PM, Franck Martin wrote: > > To be noted, the procedure, in this patch, to find the policy record in the > > DNS, is not in line with the best current practice specified in the DMARC > > spec, far from it. > > Care to offer some insight? As they say at IETF: Read the spec! :P > > > Also, what about p=quarantine? > > I think that should be treated the same as p=reject. Don't send me > your junk for storage! :-) > Please amend the patch to reflect it. From jimpop at gmail.com Fri Nov 8 01:59:38 2013 From: jimpop at gmail.com (Jim Popovitch) Date: Thu, 7 Nov 2013 19:59:38 -0500 Subject: [Mailman-Developers] Mailman DMARC Support (it's not what you think!) In-Reply-To: <2022161507.159429.1383871446211.JavaMail.zimbra@peachymango.org> References: <1656285249.144207.1383848826424.JavaMail.zimbra@peachymango.org> <2022161507.159429.1383871446211.JavaMail.zimbra@peachymango.org> Message-ID: On Thu, Nov 7, 2013 at 7:44 PM, Franck Martin wrote: > > ----- Original Message ----- >> From: "Jim Popovitch" >> To: Mailman-Developers at python.org >> Sent: Thursday, November 7, 2013 11:49:30 AM >> Subject: Re: [Mailman-Developers] Mailman DMARC Support (it's not what you think!) >> >> On Thu, Nov 7, 2013 at 1:27 PM, Franck Martin wrote: >> > To be noted, the procedure, in this patch, to find the policy record in the >> > DNS, is not in line with the best current practice specified in the DMARC >> > spec, far from it. >> >> Care to offer some insight? > > As they say at IETF: Read the spec! :P Well, as they say in production environments, I'll wait for the final cut. ;-) >> >> > Also, what about p=quarantine? >> >> I think that should be treated the same as p=reject. Don't send me >> your junk for storage! :-) >> > > Please amend the patch to reflect it. Done. Rev 1380. -Jim P. From franck at peachymango.org Fri Nov 8 02:11:18 2013 From: franck at peachymango.org (Franck Martin) Date: Thu, 7 Nov 2013 19:11:18 -0600 (CST) Subject: [Mailman-Developers] Mailman DMARC Support (it's not what you think!) In-Reply-To: References: <1656285249.144207.1383848826424.JavaMail.zimbra@peachymango.org> <2022161507.159429.1383871446211.JavaMail.zimbra@peachymango.org> Message-ID: <1691624571.159852.1383873078963.JavaMail.zimbra@peachymango.org> ----- Original Message ----- > From: "Jim Popovitch" > To: "Franck Martin" > Cc: Mailman-Developers at python.org > Sent: Thursday, November 7, 2013 4:59:38 PM > Subject: Re: [Mailman-Developers] Mailman DMARC Support (it's not what you think!) > > On Thu, Nov 7, 2013 at 7:44 PM, Franck Martin wrote: > > > > ----- Original Message ----- > >> From: "Jim Popovitch" > >> To: Mailman-Developers at python.org > >> Sent: Thursday, November 7, 2013 11:49:30 AM > >> Subject: Re: [Mailman-Developers] Mailman DMARC Support (it's not what you > >> think!) > >> > >> On Thu, Nov 7, 2013 at 1:27 PM, Franck Martin > >> wrote: > >> > To be noted, the procedure, in this patch, to find the policy record in > >> > the > >> > DNS, is not in line with the best current practice specified in the > >> > DMARC > >> > spec, far from it. > >> > >> Care to offer some insight? > > > > As they say at IETF: Read the spec! :P > > Well, as they say in production environments, I'll wait for the final cut. > ;-) Then wait for the final cut before submitting patches... From jimpop at gmail.com Fri Nov 8 02:17:08 2013 From: jimpop at gmail.com (Jim Popovitch) Date: Thu, 7 Nov 2013 20:17:08 -0500 Subject: [Mailman-Developers] Mailman DMARC Support (it's not what you think!) In-Reply-To: <1691624571.159852.1383873078963.JavaMail.zimbra@peachymango.org> References: <1656285249.144207.1383848826424.JavaMail.zimbra@peachymango.org> <2022161507.159429.1383871446211.JavaMail.zimbra@peachymango.org> <1691624571.159852.1383873078963.JavaMail.zimbra@peachymango.org> Message-ID: On Thu, Nov 7, 2013 at 8:11 PM, Franck Martin wrote: > > Then wait for the final cut before submitting patches... The only reason there is a patch is because someone (ahem, cough cough) implemented a trial spec into a production email address used to send email to a spam fighting mailinglist which caused reflected emails to be rejected back to the mailinglist provider (me!). tl;dr: I had to do this because of you. -Jim P. From colin.mailinglist at gmail.com Fri Nov 8 06:36:45 2013 From: colin.mailinglist at gmail.com (Colin Fleming) Date: Fri, 8 Nov 2013 18:36:45 +1300 Subject: [Mailman-Developers] REST API call for creating archive view? In-Reply-To: <20131107101551.3a8cb624@anarchist> References: <20131107101551.3a8cb624@anarchist> Message-ID: Ok, thanks Barry, I'll take a closer look at IArchiver then. I've seen a little info about it but I'm not on a development machine at the moment (moving cities) so I'll look when I get a chance. Thanks, Colin On 8 November 2013 04:15, Barry Warsaw wrote: > On Nov 07, 2013, at 02:50 PM, Colin Fleming wrote: > > >I'm interested in using Mailman to set up a mailing list for my product. > >I'd like to have it be fully integrated into my website, so I'm planning > to > >use Mailman 3 and the REST API. I've checked out mailman.client and poked > >around, and also looked at > > > http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/files/head:/src/mailman/rest/docs/ > , > >but the one thing I couldn't see was any way to access mail messages > >themselves. Is there a way to create an archive view (i.e. present a view > >of all messages in a list and allow reading particular mails) using the > >current API? > > While we could (and should) add a REST API for accessing the > IMessageStore, I > think this will not be very useful for you. That API would just return the > message text based on the Message-ID (or hash) that you want to look up. > It > wouldn't have any support for common archiving structure like threading, > etc. > > It would be better for you to implement an IArchiver plugin to get the > messages fed to you as they come in. Of course, then you'd have to > implement > the archiver yourself, or you can use one of the standard archiver plugins > such as for HyperKitty or MHonArc. > > And actually, having a REST API to HyperKitty is probably the best > long-term > approach. Perhaps Aur?lien can speak to that. > > -Barry > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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/colin.mailinglist%40gmail.com > > Security Policy: http://wiki.list.org/x/QIA9 From stephen at xemacs.org Fri Nov 8 11:20:48 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 08 Nov 2013 19:20:48 +0900 Subject: [Mailman-Developers] REST API call for creating archive view? In-Reply-To: References: Message-ID: <87fvr7jitb.fsf@uwakimon.sk.tsukuba.ac.jp> Colin Fleming writes: > Is there a way to create an archive view (i.e. present a view of > all messages in a list and allow reading particular mails) using > the current API? No, and (sorry Barry, but I think you just added to the confusion -- IArchiver is really a write-only API) there won't be unless the architecture of Mailman 3 changes dramatically. Archiving (storage and retrieval of posted messages) is the responsibility of a separate module. What Mailman itself can tell you is the suggested permalink for individual archived messages. We do plan to provide such a module (the current implementation and leading candidate is called HyperKitty). I do not know if the current architecture of HyperKitty is sufficiently modular as to allow you to just grab messages and then format them yourself. I'm not sure why you'd want to grab raw messages, actually; I think the best idea would for HyperKitty core (or any other implementation of an archiver) to spit out a DIV element containing the (semantically) formatted email message, and provide a default CSS, plus a fairly trivial full webapp that wraps the DIV in a full page. I'm not sure if it does that yet, though, you need to talk to the HyperKitty devs about it. (Heck, if it doesn't, maybe I'll go into the archiver business myself. Look for CSSZenKitty at a DVCS host near you!) Steve From stephen at xemacs.org Fri Nov 8 11:33:36 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 08 Nov 2013 19:33:36 +0900 Subject: [Mailman-Developers] Mailman DMARC Support (it's not what you think!) In-Reply-To: <2022161507.159429.1383871446211.JavaMail.zimbra@peachymango.org> References: <1656285249.144207.1383848826424.JavaMail.zimbra@peachymango.org> <2022161507.159429.1383871446211.JavaMail.zimbra@peachymango.org> Message-ID: <87eh6rji7z.fsf@uwakimon.sk.tsukuba.ac.jp> Franck Martin writes: > As they say at IETF: Read the spec! :P I have (probably three times carefully by now), and I still can't understand why you think DMARC makes any sense at all for mailing lists. (I have no trouble at all understanding why Citibank thinks it's great. But that's a completely different use-case.) It might help if you gave us the annotated version of what you do like about it, instead of telling us that everything we've been doing for 20 years is wrong, and that we're crazy to object to the violation of the most fundamental and ancient email RFC (not to mention violating copyright law in every Berne Convention signatory) by corrupting the authorship information of each post we process. As Jim says, the only real hope mailing lists have is some kind of digital signature protocol that allows the list to testify to having performed its own authenticity checks before forwarding the post. Steve From colin.mailinglist at gmail.com Sat Nov 9 06:10:10 2013 From: colin.mailinglist at gmail.com (Colin Fleming) Date: Sat, 9 Nov 2013 18:10:10 +1300 Subject: [Mailman-Developers] REST API call for creating archive view? In-Reply-To: <87fvr7jitb.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87fvr7jitb.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: Thanks for the comments, Steve - can you clarify what you mean by a "write-only API"? As far as I can tell I could use that to insert messages that Mailman now considers "posted to the list" into my own DBMS and then present them however I like. I'll have a bunch of questions around robustness and error handling, but is that not basically the case? I like the idea of Hyperkitty returning fairly plain HTML that I could later style, although having a REST API that would allow me to get at thread objects which contained a tree of message objects would probably be ideal. I suspect that's fairly trivial for me to implement assuming my assumptions about IArchiver are correct. Cheers, Colin On 8 November 2013 23:20, Stephen J. Turnbull wrote: > Colin Fleming writes: > > > Is there a way to create an archive view (i.e. present a view of > > all messages in a list and allow reading particular mails) using > > the current API? > > No, and (sorry Barry, but I think you just added to the confusion -- > IArchiver is really a write-only API) there won't be unless the > architecture of Mailman 3 changes dramatically. Archiving (storage > and retrieval of posted messages) is the responsibility of a separate > module. What Mailman itself can tell you is the suggested permalink > for individual archived messages. > > We do plan to provide such a module (the current implementation and > leading candidate is called HyperKitty). > > I do not know if the current architecture of HyperKitty is > sufficiently modular as to allow you to just grab messages and then > format them yourself. > > I'm not sure why you'd want to grab raw messages, actually; I think > the best idea would for HyperKitty core (or any other implementation > of an archiver) to spit out a DIV element containing the > (semantically) formatted email message, and provide a default CSS, > plus a fairly trivial full webapp that wraps the DIV in a full page. > I'm not sure if it does that yet, though, you need to talk to the > HyperKitty devs about it. > > (Heck, if it doesn't, maybe I'll go into the archiver business > myself. Look for CSSZenKitty at a DVCS host near you!) > > Steve > > From barry at list.org Sat Nov 9 15:53:50 2013 From: barry at list.org (Barry Warsaw) Date: Sat, 9 Nov 2013 09:53:50 -0500 Subject: [Mailman-Developers] REST API call for creating archive view? In-Reply-To: References: <87fvr7jitb.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20131109095350.34fc5afd@limelight.wooz.org> On Nov 09, 2013, at 06:10 PM, Colin Fleming wrote: >Thanks for the comments, Steve - can you clarify what you mean by a >"write-only API"? As far as I can tell I could use that to insert messages >that Mailman now considers "posted to the list" into my own DBMS and then >present them however I like. I'll have a bunch of questions around >robustness and error handling, but is that not basically the case? It is. The IArchiver API is not part of the REST API; it's not an external API that clients can talk to. It's an internal API that Mailman uses exactly as you say - it's a generic way to get messages posted to the list into other services, structured around the needs of archivers. >I like the idea of Hyperkitty returning fairly plain HTML that I could >later style, although having a REST API that would allow me to get at >thread objects which contained a tree of message objects would probably be >ideal. I suspect that's fairly trivial for me to implement assuming my >assumptions about IArchiver are correct. IArchiver is part of Mailman core, not Hyperkitty. In fact, it's the way messages posted to mailing lists get *into* Hyperkitty. :) -Barry From adam-mailman at amyl.org.uk Sat Nov 9 19:14:55 2013 From: adam-mailman at amyl.org.uk (Adam McGreggor) Date: Sat, 9 Nov 2013 18:14:55 +0000 Subject: [Mailman-Developers] Mailman Suite beta: what's left? In-Reply-To: <87fvrfs2jc.fsf@uwakimon.sk.tsukuba.ac.jp> References: <421c057a11001f7ae9b763de6ad807f4@toybox.ca> <20131029220650.GB1988@sys4.de> <20131030082117.GE6777@charite.de> <8738njta1o.fsf@uwakimon.sk.tsukuba.ac.jp> <20131101142414.06bf8c76@anarchist> <87fvrfs2jc.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20131109181454.GZ10820@hendricks.amyl.org.uk> On Sat, Nov 02, 2013 at 04:09:27PM +0900, Stephen J. Turnbull wrote: > Barry Warsaw writes: > > > >Mailman2 router (I've already submitted the docs for that -- they're > > >very generic -- don't know if Barry's merged them yet), and start > > >adding Mailman3 lists. > > > > This branch? > > > > https://code.launchpad.net/~stephen-xemacs/mailman/exim4/+merge/187302j > > Yes, but don't worry about it. It's straightforward and I'm happy to > support Exim users who want to try Mailman 3 (don't post all at once, > now...). That'll be me :o) (I can't get my head around Postfix, and it seems to be more trouble than Exim (or Postfix users don't RTFM as much as Exim ones)). https://code.launchpad.net/~stephen-xemacs/mailman/exim4/+merge/187302j 404s for me; is http://bazaar.launchpad.net/~stephen-xemacs/mailman/exim4/revision/7219 the same? The only thing I would say (and were this on Github, I'd have just added a comment) is for -- 252 # /etc/exim4/conf.d/main/455_mm3_router 253 mailman3_router: 254 driver = accept 255 domains = +mm_domains 256 require_files = MM3_LISTCHK 257 local_part_suffix_optional 258 local_part_suffix = -admin : \ 259 -bounces : -bounces+* : \ 260 -confirm : -confirm+* : \ 261 -join : -leave : \ 262 -owner : -request : \ 263 -subscribe : -unsubscribe 264 transport = mailman3_transport it might be worth adding a reminder that order of routers matters in Exim (or perhaps add that to the note: 227 Debian-specific script. If your Exim v4 installation is structured 228 differently, ignore the comments indicating location in the Debian 229 installation. I've been holding off deploying MM3 until it has a usable web-interface, but as it looks as though that might be there, and now you've added the Exim stanzas, I suppose I really should give it a whirl? -- "all the succession and repetition of massed humanity ... Those vile bodies" From stephen at xemacs.org Sun Nov 10 16:34:44 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Mon, 11 Nov 2013 00:34:44 +0900 Subject: [Mailman-Developers] Mailman Suite beta: what's left? In-Reply-To: <20131109181454.GZ10820@hendricks.amyl.org.uk> References: <421c057a11001f7ae9b763de6ad807f4@toybox.ca> <20131029220650.GB1988@sys4.de> <20131030082117.GE6777@charite.de> <8738njta1o.fsf@uwakimon.sk.tsukuba.ac.jp> <20131101142414.06bf8c76@anarchist> <87fvrfs2jc.fsf@uwakimon.sk.tsukuba.ac.jp> <20131109181454.GZ10820@hendricks.amyl.org.uk> Message-ID: <878uwwjmnf.fsf@uwakimon.sk.tsukuba.ac.jp> Adam McGreggor writes: > https://code.launchpad.net/~stephen-xemacs/mailman/exim4/+merge/187302j > 404s for me; is > http://bazaar.launchpad.net/~stephen-xemacs/mailman/exim4/revision/7219 > the same? Yes, that's the one. > it might be worth adding a reminder that order of routers matters in Exim (or > perhaps add that to the note: I mention that in "Troubleshooting". Maybe I should change the section name to attract the eye of those not yet in trouble? I dislike writing the same thing multiple times, and especially duplicating manuals in code. It's a maintenance burden (slight, but it adds up if done a lot), and it also sometime makes me wonder if I actually saw something when I find a section of text where it should be included but it's not there. Then it turns out a more accurate discription was somewhere else -- aaaargh! From stephen at xemacs.org Sun Nov 10 16:36:23 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Mon, 11 Nov 2013 00:36:23 +0900 Subject: [Mailman-Developers] REST API call for creating archive view? In-Reply-To: References: <87fvr7jitb.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <877gcgjmko.fsf@uwakimon.sk.tsukuba.ac.jp> Colin Fleming writes: > Thanks for the comments, Steve - can you clarify what you mean by a > "write-only API"? "Mailman core has no way to retrieve those messages." For the rest, I think Barry's answer is clear and definitive. From colin.mailinglist at gmail.com Sun Nov 10 21:38:37 2013 From: colin.mailinglist at gmail.com (Colin Fleming) Date: Mon, 11 Nov 2013 09:38:37 +1300 Subject: [Mailman-Developers] REST API call for creating archive view? In-Reply-To: <877gcgjmko.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87fvr7jitb.fsf@uwakimon.sk.tsukuba.ac.jp> <877gcgjmko.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: Ah, I see - great, thanks for the clarification. On 11 November 2013 04:36, Stephen J. Turnbull wrote: > Colin Fleming writes: > > > Thanks for the comments, Steve - can you clarify what you mean by a > > "write-only API"? > > "Mailman core has no way to retrieve those messages." > > For the rest, I think Barry's answer is clear and definitive. > From iane at sussex.ac.uk Wed Nov 13 13:29:40 2013 From: iane at sussex.ac.uk (Ian Eiloart) Date: Wed, 13 Nov 2013 12:29:40 +0000 Subject: [Mailman-Developers] Mailman Suite beta: what's left? In-Reply-To: <87zjpqsx1x.fsf@uwakimon.sk.tsukuba.ac.jp> References: <421c057a11001f7ae9b763de6ad807f4@toybox.ca> <20131029220650.GB1988@sys4.de> <20131030082117.GE6777@charite.de> <8738njta1o.fsf@uwakimon.sk.tsukuba.ac.jp> <20131030093537.GN6777@charite.de> <87zjpqsx1x.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: On 30 Oct 2013, at 13:33, Stephen J. Turnbull wrote: > Ralf Hildebrandt writes: > >>> Where else do you expect to find this information, so we can put it >>> there? >> >> I must admin I haven't tried installing yet, mainly because I didn't >> know how to "go back" in case of problems. > > Repeating what I already wrote for completeness here: Migrating and > then going back all at once is not necessary. You can migrate bit by > bit, although it may require a little bit of manual fiddling if you > get to the point of installing both on a production server. The tricky bit here is the continuity of the web interfaces. If a list manager is used to going to lists.example.com/Mailman/listname, and they have that bookmarked, then they?ll want to keep going to that same place. Likewise, with the list archives, and all the list users. We have 1312 lists, perhaps two or three thousand list admins, and tens of thousands of users. I?m currently struggling with how to migrate those lists to new hardware, and I think I?m going to have to do it all at once in order to avoid having to educate everyone to find a new web address, and then to revert to the old one. Perhaps I could alternatively tell them that web access is unavailable during a migration week. I?m also nervous about breaking migration through the archives. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 From flo.fuchs at gmail.com Wed Nov 13 14:39:41 2013 From: flo.fuchs at gmail.com (Florian Fuchs) Date: Wed, 13 Nov 2013 14:39:41 +0100 Subject: [Mailman-Developers] Mailman Suite beta: what's left? In-Reply-To: References: <421c057a11001f7ae9b763de6ad807f4@toybox.ca> <20131029220650.GB1988@sys4.de> <20131030082117.GE6777@charite.de> <8738njta1o.fsf@uwakimon.sk.tsukuba.ac.jp> <20131030093537.GN6777@charite.de> <87zjpqsx1x.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <5283811D.40401@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/13/2013 01:29 PM, Ian Eiloart wrote: >> Repeating what I already wrote for completeness here: Migrating >> and then going back all at once is not necessary. You can >> migrate bit by bit, although it may require a little bit of >> manual fiddling if you get to the point of installing both on a >> production server. >> > > The tricky bit here is the continuity of the web interfaces. If a > list manager is used to going to > lists.example.com/Mailman/listname, and they have that bookmarked, > then they?ll want to keep going to that same place. > > Likewise, with the list archives, and all the list users. We have > 1312 lists, perhaps two or three thousand list admins, and tens of > thousands of users. Postorius' URL config does allow for some customization, but I doubt it will be easily possible to style list summary URLs to match the MM2-style "mailman/listinfo/{list name}" URLs. The reason is that Postorius uses the "list-id" property as unique identifier in URLs which is generally different to the list names used in MM2-URLs. What we could do though (possibly as part of the migration routine) is to auto-generate rewrite rules for major web servers like Apache/nginx/... redirecting MM2-style URL requests to the new ones (using HTTP status code 301, which would also tell search engines that the change is permanent). Florian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSg4EdAAoJEEceGbPdavl7Yr0IAJn5zGRIpu0T9JqVqfZA9S92 eL5b4NI7J8XqxC/0zQpqTUfAV8NOoxCORfY8YTx7ClDbitFJzEVPAa+/95x8w7w/ 2jqBtpktnBRa5TlLWubK+odXdPi/z01cj2VxkbOZq42VJu2kG97usHux7nGhR9K4 2SOGA3J735kjoKA60FNKVVSCjX4/TXSy42WINe0mlWQ0OVmD0Nza2xwoHWQLlaN7 Pe+/32FJlWr+x0QX+Tdp3qh9R6v9MHdsY7LluddTnpNx4Lss/KR+pS7390wzuWxx eIhaTAlWE6Ix2fCHGrVB67wxyH6MktNwbBqeUj4nXccfga7yVNRJfEncMdoOGDg= =ZeDC -----END PGP SIGNATURE----- From aurelien at bompard.org Wed Nov 13 15:38:23 2013 From: aurelien at bompard.org (=?ISO-8859-1?Q?Aur=E9lien_Bompard?=) Date: Wed, 13 Nov 2013 15:38:23 +0100 Subject: [Mailman-Developers] REST API call for creating archive view? In-Reply-To: References: <87fvr7jitb.fsf@uwakimon.sk.tsukuba.ac.jp> <877gcgjmko.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <52838EDF.5070605@bompard.org> Hey Colin, sorry for not replying earlier There is a REST interface in HyperKitty, that will give you access to the archives if you want to implement another web interface on top of it. The good thing is that I know someone who already did that, with about the same needs as you, so it must be doable :-) The bad thing is that it was some months ago, and HyperKitty keeps evolving, while this part is not covered by unit tests yet. So it may be broken at the moment. But it may also be very easily fixable if needed. Aur?lien -- http://aurelien.bompard.org ~~~~~~ xmpp:aurelien at bompard.org Recursion: (n.) See "Recursion". From stephen at xemacs.org Wed Nov 13 16:00:16 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 14 Nov 2013 00:00:16 +0900 Subject: [Mailman-Developers] Mailman Suite beta: what's left? In-Reply-To: References: <421c057a11001f7ae9b763de6ad807f4@toybox.ca> <20131029220650.GB1988@sys4.de> <20131030082117.GE6777@charite.de> <8738njta1o.fsf@uwakimon.sk.tsukuba.ac.jp> <20131030093537.GN6777@charite.de> <87zjpqsx1x.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <87txfggxdr.fsf@uwakimon.sk.tsukuba.ac.jp> Ian Eiloart writes: > On 30 Oct 2013, at 13:33, Stephen J. Turnbull wrote: > > Repeating what I already wrote for completeness here: Migrating and > > then going back all at once is not necessary. You can migrate bit by > > bit, although it may require a little bit of manual fiddling if you > > get to the point of installing both on a production server. > > The tricky bit here is the continuity of the web interfaces. If a > list manager is used to going to lists.example.com/Mailman/listname, > and they have that bookmarked, then they?ll want to keep going to > that same place. Sure, and I don't blame them. I could have been more careful in expressing myself. I didn't really mean that you could do it in dribs and drabs, rather that you could start with a test list that the kind of beta tester who uses git to get betas wouldn't mind being on, move on up to a few hard-core techie lists whose members understand "beta", and only when people are satisfied that those are working, then do the rest. And at each stage it's reversible without losing data -- but not necessarily at zero cost to users, or to you. Whether that's good enough for you is something you'll have to decide. I just wanted to make it clear that if you *had* a working Mailman 2 installation you can revert to it. > I?m also nervous about breaking migration through the archives. Unfortunately I don't know enough about HyperKitty to help you there. I suspect that the HyperKitty guys have paid about the same amount of attention to consistency across migration as the Postorius folks have, and it matters more there because who knows what people might have bookmarked? From barry at list.org Wed Nov 13 16:30:23 2013 From: barry at list.org (Barry Warsaw) Date: Wed, 13 Nov 2013 10:30:23 -0500 Subject: [Mailman-Developers] Mailman Suite beta: what's left? In-Reply-To: <5283811D.40401@gmail.com> References: <421c057a11001f7ae9b763de6ad807f4@toybox.ca> <20131029220650.GB1988@sys4.de> <20131030082117.GE6777@charite.de> <8738njta1o.fsf@uwakimon.sk.tsukuba.ac.jp> <20131030093537.GN6777@charite.de> <87zjpqsx1x.fsf@uwakimon.sk.tsukuba.ac.jp> <5283811D.40401@gmail.com> Message-ID: <20131113103023.6f2d57a4@anarchist> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Nov 13, 2013, at 02:39 PM, Florian Fuchs wrote: >What we could do though (possibly as part of the migration routine) is >to auto-generate rewrite rules for major web servers like >Apache/nginx/... redirecting MM2-style URL requests to the new ones >(using HTTP status code 301, which would also tell search engines that >the change is permanent). That seems like a more useful approach than trying to twist Postorius's natural urls to fit MM2 style urls. TBH, I was never really in love with MM2 urls, but it was the best we could do way back when. Let's embrace the 21st century and let Postorius do the best it can do, and leave the rest (with some help) to the web server. :) - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCAAGBQJSg5sPAAoJEBJutWOnSwa/KusP/1toDvXheLLNyTNhbowiaMXD RKyFu/NRcw/LDPPMiAFp8ci60kICmOOUAdopK82BVzl1YodkWJuBu02aZntGJWy5 kbHXIt309KXskt7g1ZK8B1PF43MDpVzJwKIIjRKJqICBKA46YAW+gEAWeMhNi1EK 6GrpAaobddOGJSKUwbQ3bfDBHiSDZ9DflFhdhx7z9yjUyysr8Ul3PV3pfgaFtqyR QllJz4UrEUahfb+rpw9f+GjqJAtz6IF9HzUICQJ+1ecxeyaOM0bKB5ZQnNSz6Wwb zfLIXjDvEyD7w9SJ7d0CPlhRHWSlM9f2WJC+bMC0mALQ63HYxUEebjQYl5y307Hl +tEuO9090i022Je6OpdAFdvd454Vwu61sPzvuh8Y/NrAawZGDJDcBNp+6kFAYefW qKKShf0ebzPHqeYHDAjK7mhr33K4tpf1siVZrKj//sXxE7aKgtKSDykDQpqq9s8u xfkxCWkkqD/NFOXENBBYOZ7EnUDINFFLIqnAugnYMAGD6Rkie3dt869XNueAFf2l rGubrnVobvKPhJXi2Cpz479TSyYSVaRqWkYTUo9D1+4jm7YLK+S8LpVYondvjUPD HJfo8CmanLVXwZ8Zgr7H7hN6mJd2bOYtU2M4syinppyzoZbmuWOyr3KNWfKfI8ht s8V0SmIVthwBk7n9liWV =Dv3n -----END PGP SIGNATURE----- From colin.mailinglist at gmail.com Wed Nov 13 21:51:24 2013 From: colin.mailinglist at gmail.com (Colin Fleming) Date: Thu, 14 Nov 2013 09:51:24 +1300 Subject: [Mailman-Developers] REST API call for creating archive view? In-Reply-To: <52838EDF.5070605@bompard.org> References: <87fvr7jitb.fsf@uwakimon.sk.tsukuba.ac.jp> <877gcgjmko.fsf@uwakimon.sk.tsukuba.ac.jp> <52838EDF.5070605@bompard.org> Message-ID: Thanks Aur?lien! Is there some documentation (or code) somewhere I can look at for that? On 14 November 2013 03:38, Aur?lien Bompard wrote: > Hey Colin, sorry for not replying earlier > > There is a REST interface in HyperKitty, that will give you access to > the archives if you want to implement another web interface on top of > it. The good thing is that I know someone who already did that, with > about the same needs as you, so it must be doable :-) > The bad thing is that it was some months ago, and HyperKitty keeps > evolving, while this part is not covered by unit tests yet. So it may be > broken at the moment. But it may also be very easily fixable if needed. > > Aur?lien > > -- > http://aurelien.bompard.org ~~~~~~ xmpp:aurelien at bompard.org > Recursion: (n.) See "Recursion". > > From fil at rezo.net Thu Nov 14 11:22:20 2013 From: fil at rezo.net (Fil) Date: Thu, 14 Nov 2013 11:22:20 +0100 Subject: [Mailman-Developers] small patch Message-ID: Hello, I just upgraded to Mailman 2.1.16 and python 2.7 (I was still on MM 2.1.11 with python 2.3) => with a topics-enabled list, I had a few shunted files with this message : Nov 14 11:04:29 2013 (21875) Uncaught runner exception: change_header() got an unexpected keyword argument 'Delete' File "/var/local/mailman/Mailman/Handlers/Tagger.py", line 74, in process mlist, msg, msgdata, Delete=False) so I modified this: http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/view/head:/Mailman/Handlers/Tagger.py#L73 on line 74, use delete=False, instead of Delete=False -- Fil From mark at msapiro.net Fri Nov 15 03:27:43 2013 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 14 Nov 2013 18:27:43 -0800 Subject: [Mailman-Developers] small patch In-Reply-To: References: Message-ID: <5285869F.4020703@msapiro.net> On 11/14/2013 02:22 AM, Fil wrote: > Hello, > > I just upgraded to Mailman 2.1.16 and python 2.7 (I was still on MM 2.1.11 > with python 2.3) > > => with a topics-enabled list, I had a few shunted files with this message : > > Nov 14 11:04:29 2013 (21875) Uncaught runner exception: change_header() got > an unexpected keyword argument 'Delete' > > File "/var/local/mailman/Mailman/Handlers/Tagger.py", line 74, in process > > mlist, msg, msgdata, Delete=False) Thanks for the report. The fix is committed for the next release. See . -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From aurelien at bompard.org Fri Nov 15 10:16:03 2013 From: aurelien at bompard.org (=?UTF-8?B?QXVyw6lsaWVuIEJvbXBhcmQ=?=) Date: Fri, 15 Nov 2013 10:16:03 +0100 Subject: [Mailman-Developers] Mailman Suite beta: what's left? In-Reply-To: <87txfggxdr.fsf@uwakimon.sk.tsukuba.ac.jp> References: <421c057a11001f7ae9b763de6ad807f4@toybox.ca> <20131029220650.GB1988@sys4.de> <20131030082117.GE6777@charite.de> <8738njta1o.fsf@uwakimon.sk.tsukuba.ac.jp> <20131030093537.GN6777@charite.de> <87zjpqsx1x.fsf@uwakimon.sk.tsukuba.ac.jp> <87txfggxdr.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <5285E653.3070600@bompard.org> >> I?m also nervous about breaking migration through the archives. > > Unfortunately I don't know enough about HyperKitty to help you > there. I suspect that the HyperKitty guys have paid about the same > amount of attention to consistency across migration as the Postorius > folks have, and it matters more there because who knows what people > might have bookmarked? We have a way to redirect the old archives URL format to the new one, but it's not very solid because it depends on the order the emails were archived (that's how it was done in pipermail), and a duplicate email can put the numbers off. If anyone has a better idea, I'm interested, I'd sure like to preserve all the links to individual emails that are laying around on the interwebs. Aur?lien -- http://aurelien.bompard.org ~~~~~~ xmpp:aurelien at bompard.org Better to light a candle than to curse the darkness. -- Chinese proverb From aurelien at bompard.org Fri Nov 15 16:22:58 2013 From: aurelien at bompard.org (=?ISO-8859-1?Q?Aur=E9lien_Bompard?=) Date: Fri, 15 Nov 2013 16:22:58 +0100 Subject: [Mailman-Developers] REST API call for creating archive view? In-Reply-To: References: <87fvr7jitb.fsf@uwakimon.sk.tsukuba.ac.jp> <877gcgjmko.fsf@uwakimon.sk.tsukuba.ac.jp> <52838EDF.5070605@bompard.org> Message-ID: <52863C52.6010502@bompard.org> > Thanks Aur?lien! Is there some documentation (or code) somewhere I can > look at for that? Unfortunately there is no separate documentation for the REST API, but if you install HyperKitty and browse the /api URL, there is an HTML rendering that explains endpoints and their use. Aur?lien -- http://aurelien.bompard.org ~~~~~~ xmpp:aurelien at bompard.org "Experience is that marvelous thing that enables you to recognize a mistake when you make it again." -- Franklin P. Jones From colin.mailinglist at gmail.com Fri Nov 15 21:51:11 2013 From: colin.mailinglist at gmail.com (Colin Fleming) Date: Sat, 16 Nov 2013 09:51:11 +1300 Subject: [Mailman-Developers] REST API call for creating archive view? In-Reply-To: <52863C52.6010502@bompard.org> References: <87fvr7jitb.fsf@uwakimon.sk.tsukuba.ac.jp> <877gcgjmko.fsf@uwakimon.sk.tsukuba.ac.jp> <52838EDF.5070605@bompard.org> <52863C52.6010502@bompard.org> Message-ID: Ok, thanks - I'll see if I can get that set up when I get a moment and give it a try. Cheers, Colin On 16 November 2013 04:22, Aur?lien Bompard wrote: > > > Thanks Aur?lien! Is there some documentation (or code) somewhere I can > > look at for that? > > Unfortunately there is no separate documentation for the REST API, but > if you install HyperKitty and browse the /api URL, there is an HTML > rendering that explains endpoints and their use. > > Aur?lien > > -- > http://aurelien.bompard.org ~~~~~~ xmpp:aurelien at bompard.org > "Experience is that marvelous thing that enables you to recognize > a mistake when you make it again." -- Franklin P. Jones > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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/colin.mailinglist%40gmail.com > > Security Policy: http://wiki.list.org/x/QIA9 > From mark at msapiro.net Mon Nov 18 02:08:26 2013 From: mark at msapiro.net (Mark Sapiro) Date: Sun, 17 Nov 2013 17:08:26 -0800 Subject: [Mailman-Developers] Mailman 2.1.17 Message-ID: <5289688A.7000409@msapiro.net> Since the release of Mailman 2.1.16 last month, there have been some i18n updates, a new feature affecting which headers are kept in posts to anonymous lists and a few bug fixes. One of these bugs was introduced in 2.1.16 and is fairly serious although it only affects lists with defined topics. See . For this reason, I plan to release Mailman 2.1.17 in about a week. If there are any i18n changes or other things that should go in 2.1.17, please get them to me before next weekend. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From terri at zone12.com Wed Nov 20 04:28:47 2013 From: terri at zone12.com (Terri Oda) Date: Tue, 19 Nov 2013 19:28:47 -0800 Subject: [Mailman-Developers] Mailman Suite Beta task list take 2 Message-ID: <528C2C6F.6060102@zone12.com> Trying to keep track of what's still on the table: 1. Multiple email address association with a single account. We're going to implement the verification emails from postorius for now, I guess. Florian, you seemed to know how to do this; do you mind getting it done? 2. Authentication issues for Postorius/Hyperkitty Have these been resolved? Florian, do you need code reviews yet? 3. Install scripts/PyPI packaging Anyone want to take this? Even just a start on it would be very helpful. Aurelian, you may be the person who's had the most success with this thus far -- would you be interested in doing it or helping out someone else who takes on the task? 4. Owner/moderator removal in Postorius Unless someone is desperate to handle this one, I may do it this week, either tonight or Thursday. 5. Anything else? Terri From raj.abhilash1 at gmail.com Wed Nov 20 05:23:10 2013 From: raj.abhilash1 at gmail.com (Abhilash) Date: Wed, 20 Nov 2013 09:53:10 +0530 Subject: [Mailman-Developers] Mailman Suite Beta task list take 2 In-Reply-To: <528C2C6F.6060102@zone12.com> References: <528C2C6F.6060102@zone12.com> Message-ID: <528C392E.8070002@gmail.com> Hi all, On Wednesday 20 November 2013 08:58 AM, Terri Oda wrote: > Trying to keep track of what's still on the table: > > 1. Multiple email address association with a single account. > > We're going to implement the verification emails from postorius for now, > I guess. Florian, you seemed to know how to do this; do you mind > getting it done? > > 2. Authentication issues for Postorius/Hyperkitty > > Have these been resolved? Florian, do you need code reviews yet? > > 3. Install scripts/PyPI packaging > > Anyone want to take this? Even just a start on it would be very > helpful. Aurelian, you may be the person who's had the most success > with this thus far -- would you be interested in doing it or helping out > someone else who takes on the task? I want to take this, but I have no experience for this. If someone could help me a little I can give it a try. Any thoughts? -- Abhilash -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From aurelien at bompard.org Wed Nov 20 10:47:57 2013 From: aurelien at bompard.org (=?ISO-8859-1?Q?Aur=E9lien_Bompard?=) Date: Wed, 20 Nov 2013 10:47:57 +0100 Subject: [Mailman-Developers] Mailman Suite Beta task list take 2 In-Reply-To: <528C392E.8070002@gmail.com> References: <528C2C6F.6060102@zone12.com> <528C392E.8070002@gmail.com> Message-ID: <528C854D.9050408@bompard.org> >> 3. Install scripts/PyPI packaging >> Anyone want to take this? Even just a start on it would be very >> helpful. Aurelian, you may be the person who's had the most >> success with this thus far -- would you be interested in doing it >> or helping out someone else who takes on the task? Sure, either doing it or helping out is fine. What are you guys thinking about for install scripts? A Makefile? A shell script? Makefiles seems better and more standard to me, and it's mainly about copying some files around, so it shouldn't get too hairy. > I want to take this, but I have no experience for this. If someone > could help me a little I can give it a try. Any thoughts? I can help you. For example, I can send you my spec files, they are mostly shell scripts divided into sections, the "install" section should help you get started. Aur?lien -- http://aurelien.bompard.org ~~~~~~ xmpp:aurelien at bompard.org "Life is what happens to you while you're busy making other plans." -- John Lennon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From flo.fuchs at gmail.com Wed Nov 20 11:47:41 2013 From: flo.fuchs at gmail.com (Florian Fuchs) Date: Wed, 20 Nov 2013 11:47:41 +0100 Subject: [Mailman-Developers] Mailman Suite Beta task list take 2 In-Reply-To: <528C2C6F.6060102@zone12.com> References: <528C2C6F.6060102@zone12.com> Message-ID: <528C934D.3070807@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/20/2013 04:28 AM, Terri Oda wrote: > Trying to keep track of what's still on the table: > > 1. Multiple email address association with a single account. > > We're going to implement the verification emails from postorius for > now, I guess. Florian, you seemed to know how to do this; do you > mind getting it done? Yep. I'm on it. > 2. Authentication issues for Postorius/Hyperkitty > > Have these been resolved? Florian, do you need code reviews yet? The code itself is working and tested (lp:~flo-fuchs/postorius/postorius_persona). I wanted to add some more documentation before requesting reviews though. Will probably get that done until the end of the week I think. > 4. Owner/moderator removal in Postorius > > Unless someone is desperate to handle this one, I may do it this > week, either tonight or Thursday. Great! Florian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSjJNNAAoJEEceGbPdavl7FxkH/3rKV5vTVwWbnkcHsFvvw7gV EHTYgho20cEW2mvYpikc1efUEKsmAqayFBe0Vj/MdS64k352snR9stwN+GKGq/VT Fb7Mk5frEgpKPgj0iIz4pF2BMYo/LV6Ao9sR80R5ssrrk+H0V2syF/4Nx0S7Mfc/ sGC8Bc5v7bXEiCkFZ++U1sySu/0L8z78B+QwVJNbtT95wwbFIOEoJGE6lDA19Uq0 WF9iGhfSaR5UBOTeK797lNRN0pCUtv9X8mZgU+MMOOG9Y965Jl+nCEltnq90ut1k cELJK2v08WWr39PHuzfj+D1wSG3rym7L5Y9ZIORz/DwLm2jqnyqM185WJUBC2vU= =xkiA -----END PGP SIGNATURE----- From raj.abhilash1 at gmail.com Wed Nov 20 12:07:06 2013 From: raj.abhilash1 at gmail.com (Abhilash) Date: Wed, 20 Nov 2013 16:37:06 +0530 Subject: [Mailman-Developers] Mailman Suite Beta task list take 2 In-Reply-To: <528C854D.9050408@bompard.org> References: <528C2C6F.6060102@zone12.com> <528C392E.8070002@gmail.com> <528C854D.9050408@bompard.org> Message-ID: <528C97DA.5060005@gmail.com> On Wednesday 20 November 2013 03:17 PM, Aur?lien Bompard wrote: >>> 3. Install scripts/PyPI packaging >>> Anyone want to take this? Even just a start on it would be very >>> helpful. Aurelian, you may be the person who's had the most >>> success with this thus far -- would you be interested in doing it >>> or helping out someone else who takes on the task? > > Sure, either doing it or helping out is fine. What are you guys thinking > about for install scripts? A Makefile? A shell script? > Makefiles seems better and more standard to me, and it's mainly about > copying some files around, so it shouldn't get too hairy. > >> I want to take this, but I have no experience for this. If someone >> could help me a little I can give it a try. Any thoughts? > > I can help you. For example, I can send you my spec files, they are > mostly shell scripts divided into sections, the "install" section should > help you get started. Great! Can you send those to my id: raj.abhilash1 at gmail.com. > > Aur?lien > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From mark at msapiro.net Sat Nov 23 20:40:44 2013 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 23 Nov 2013 11:40:44 -0800 Subject: [Mailman-Developers] Mailman 2.1.17 release. In-Reply-To: <51E30DF7.8020306@msapiro.net> References: <51DF5301.7070802@msapiro.net> <51E30DF7.8020306@msapiro.net> Message-ID: <529104BC.60808@msapiro.net> I am pleased to announce the final release of Mailman 2.1.17. Python 2.4 is the minimum supported, but Python 2.7 is recommended. This release has two new features and a few bug fixes as detailed in the attached README. Mailman is free software for managing email mailing lists and e-newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, please see: http://www.list.org http://www.gnu.org/software/mailman http://mailman.sourceforge.net/ Mailman 2.1.17 can be downloaded from https://launchpad.net/mailman/2.1/ http://ftp.gnu.org/gnu/mailman/ https://sourceforge.net/projects/mailman/ -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -------------- next part -------------- 2.1.17 (23-Nov-2013) New Features - Handling of posts gated from usenet to a list via the Mail <-> News gateway is changed. Formerly, no list membership, moderation or *_these_nonmembers checks were done. Now, if the sender of the usenet post is a moderated member or a nonmember matching a *_these_nonmembers filter, those checks will be done and actions applied. Nonmember posts from senders not matching a *_these_nonmembers filter are still accepted as before. (LP: #1252575) - There is a new mm_cfg.py setting ANONYMOUS_LIST_KEEP_HEADERS. Since it is not possible to know which non-standard headers in a message might reveal sender information, we now remove all headers from incoming posts to anonymous lists except those which match regular expressions in this list. The default setting keeps non X- headers except those known to reveal sender information, Mailman added X- headers and x-Spam- headers. See the description in Defaults.py for more information. (LP: #1246039) i18n - The Japanese message catalog has been updated by SATOH Fumiyasu. (LP: #1248855) Bug Fixes and other patches - Added a reopen command to the sample init.d script in misc/mailman.in. (LP: #1251917) - Fixed a misspelling in Tagger.py causing an "unexpected keyword argument 'Delete'" exception. (LP: #1251495) - Fixed contrib/qmail-to-mailman.py to work with a user other than 'mailman' and to recognize more listname-* addresses. (LP: #412293) - Fixed a possible UnicodeDecodeError in bin/sync_members. (LP: #1243343) - Fixed Makefile to not include $DESTDIR in paths compiled into .pyc files for traceback purposes. (LP: #1241770) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: