Mailman-Developers February 2015

mailman-developers@python.org

32 participants
70 discussions

by Daniel Kahn Gillmor

Hi Murray-- On Fri 2015-02-27 14:46:40 -0500, Murray S. Kucherawy wrote: > Sorry, by "sign" I meant "add a footer". I probably said "sign" because > this is related to some DKIM work I've been planning, and the morning's > caffeine was already wearing off. :) > Thanks for that detailed answer (and Barry for his followup). It's > precisely what I was looking for. > > How absurd would it be to propose a flag for Mailman that would take your > first case (non-MIME, or single-part text/plain) and convert it to a > multipart/mixed with a child part of the original text/plain, and then > apply the algorithm you have? I'm not one to make any decisions for mailman, but this sounds pretty reasonable to me. In fact, the only argument against ever having such a switch *not* set is that non-MIME-aware text-only MUAs will now see some crufty MIME boundaries in the message that they didn't see before. I'd bet the number of users of non-MIME-aware text-only MUAs receiving mail from mailman that are incapable of wading through a bit of extra MIME boundary info on otherwise text/plain messages is vanishingly small. Most of those folks are probably at least used to seeing it as a result of the overwhelming predominance of multipart/alternative on today's SMTP network. > The impetus here is DKIM survivability across lists. Suppose we had a DKIM > canonicalization that was MIME-aware, so that it could sign the specific > MIME parts or sets of parts. That signature would fail on the message as a > whole -- with the footer part added -- but could in theory pass if an > appended part were omitted from canonicalization. To put it in context, > suppose there were a DKIM canonicalization where the signer signed (using > your examples) the CDE message; the receiver gets FGHI which fails, but > also has enough information to know that merely verifying FGH will pass; it > then knows that FGH was "legitimate" and I was added post-signing, and may > or may not be "safe" (for some value thereof) content. > > What I'm worried about with such a design is the trivial text/plain > message. Obviously merely appending the footer destroys any hope of > validating only the original content. We'd have to entertain the idea that > Mailman would make the simple message into a multipart/mixed + text/plain, > then append the footer part and sign that; the verifier would drop the > footer and then strip off the MIME to see if it can verify the original > signature that way. That seems like its easy to get wrong, though it's > likely to be a very common case. right, the MIME boundaries provide the parsing framework to enable this kind of sub-part DKIM-verification. One issue this process brings up is that it's now necessary to treat pretty much every part of the message as though it is multipart/signed -- that is, it needs to be handled bytewise opaquely, on pain of breaking the DKIM header. We already know that there are tools that do things like re-encode messages from base64 to q-p, or change character sets, or just re-flow long lines (FSVO "long") in the mime boundary subheaders. They're not supposed to do this with multipart/signed messages, because the RFCs point out that opaque handling is required, but they sometimes break them anyway. I imagine the same risk would now apply to all DKIM-signed messages using your scheme. With that caveat in mind, it's clear that without your proposal, all DKIM-signatures of messages with footers will break anyway. So this does seem to be a strict improvement, even if there are a few corner cases that aren't fully covered. --dkg

6 years, 1 month

Announcing the new wiki.list.org

by Barry Warsaw

I am very happy to announce our new wiki! If you go to wiki.list.org you will see our shiny new Moin-based wiki. We are retiring the old Confluence-based wiki at the end of February. Until then, you can access it at old-wiki.list.org. Our very huge thanks go to Paul Boddie who did the amazing conversion work, almost single-handedly reverse engineering the Confluence dump through several iterations. Of course, our thanks also go to John Viega, owner of the list.org domain and Mailman's inventor for helping us get the DNS flipped over. Thanks too to everyone who gave feedback on the new wiki, contributed to the old wiki, and continue to help edit this important resource for the Mailman community. Our thanks also go to the Python Software Foundation and the PSF infrastructure team for providing us with the virtual machine hosting our new wiki. If you had write access to the old wiki and want it again for the new wiki, you will have to re-submit a request to mailman-cabal(a)python.org. Please be sure to register with wiki.list.org and provide us with your user name. With this conversion, I am happy to say that GNU Mailman is finally fully hosted on free software. While we appreciate the years of service donated to us by Atlassian and Contegix, it's important that we set an example by utilizing an entirely free software stack for our development and outreach. The wiki was our last remaining non-free bits. Let the gardening begin! Cheers, -Barry (On behalf of the GNU Mailman steering committee) P.S. We are working on the SSL certificate for the new wiki. Stay tuned.

6 years, 2 months

Re: [Mailman-Developers] GSoC 2015: brainstorming ideas suitable for beginners?

by Stephen J. Turnbull

Ankush Sharma B.Tech. Electronics Engg, IIT(BHU), Varanasi (U.P.), INDIA writes: > I was wondering if there is a sort of tool that generates summaries > for mailing list activity and charts like number of users, number > of active users, etc. Would something like this be a good idea or > is it already done? There are such tools but they're not integrated into the Mailman 2 web interface, and I think they're not in Postorius or Hyperkitty yet, either. They're frequently requested and I think Postorius provides some infrastructure for such things.

6 years, 2 months

Re: [Mailman-Developers] GSoC 2015: brainstorming ideas suitable for beginners?

by Barry Warsaw

On Feb 27, 2015, at 01:02 PM, Ankush Sharma B.Tech. Electronics Engg, IIT(BHU), Varanasi (U.P.), INDIA wrote: >A personalized mailing list will allow mailman users to send personalized >emails to all the list members from a common email template. Almost all the pieces are already there to support mail merging, at least as a plugin. There's quite a bit of functionality in place to allow for pluggable MTA delivery methods. Right now, there's only one. Search src/mailman/config/schema.cfg for the [mta]outgoing variable. We also already do a bit of mixin class composition to implement various aspects of the existing personalized delivery machinery. The proper class is chosen (based on the default [mta]outgoing value) from the value of mlist.personalize. To support mail merge, we'd need a little more flexibility in composing these basic bits. You'd like for individual mailing lists to be able to choose a custom delivery mechanism from a set of site-defined choices, for example. Then a plugin could define a new delivery class which does the database lookups and the mail merge into the template at the point where the VERP'd message is handed off to the upstream MTA. You'd register this new delivery class with the system and them mailing lists could opt into it. Cheers, -Barry

6 years, 2 months

Query regarding plugin integration with mailman3

by Aanand Shekhar Roy

Can someone tell me if the following way is suitable for implementing a plug in on mailman3 : A folder contains all the .py codes needed to implement the plugin feature aimed. In that folder we make an executable file i.e. .sh file, which runs the script that adds the code mentioned above in the right places of mailman3 src code. Regards, Aanand

6 years, 2 months

Re: [Mailman-Developers] MIME footers

by Barry Warsaw

On Feb 27, 2015, at 11:46 AM, Murray S. Kucherawy wrote: >How absurd would it be to propose a flag for Mailman that would take your >first case (non-MIME, or single-part text/plain) and convert it to a >multipart/mixed with a child part of the original text/plain, and then >apply the algorithm you have? [...] > >What I'm worried about with such a design is the trivial text/plain >message. Obviously merely appending the footer destroys any hope of >validating only the original content. We'd have to entertain the idea that >Mailman would make the simple message into a multipart/mixed + text/plain, >then append the footer part and sign that; the verifier would drop the >footer and then strip off the MIME to see if it can verify the original >signature that way. That seems like its easy to get wrong, though it's >likely to be a very common case. The biggest downside, and probably the main reason we append the footer text in the text/plain-compatible-charset case is because of crappy MUAs. I think we *still* get complaints about the MIME composition not being rendered very well. Their MUAs will show them attachments without the message content they actually care about. I wish I could say "fix the MUAs" but that's probably been futile since the day email was invented. ;) That said, it's not a totally unreasonable suggestion. I wonder if it makes sense to have that be a user option (then, what's the default, what a standard says, or whatever minimizes user complaints). Cheers, -Barry

6 years, 2 months

GSoC 2015: brainstorming ideas suitable for beginners?

by Terri Oda

Hi all, In my role as org admin for Python, I'm trying to make sure we have more beginner-friendly ideas on the GSoC pages, and Mailman's among the groups that doesn't have any. How embarrassing for me as a Mailman developer. ;) It's also a problem for Mailman if we're applying as a separate organization, as Google seldom allows orgs unless they have a reasonable number of ideas suitable for open source newbies. (The idea behind this is that many students are very new to Open Source and we want them to at least get something out of the application process, learn how to set up their environments and learn about what it takes to get hired as a GSoC student. Even if they don't make it in their first year, they'll be much more ready for later years!) I'd love some help brainstorming some actual beginner-friendly ideas, though, because I'm currently all idea'd out. Anyone want to suggest some simpler things they'd like to see in Mailman that we could maybe put on the list? Suggesting and idea does not mean you have to volunteer to mentor them, although I'm always looking for new mentors too! Terri

6 years, 2 months

Re: [Mailman-Developers] GSoC 2015 aspirant: Github/development tools integration

by Aanand Shekhar Roy

Hi Karan, I would suggest setting up mailman would be a good start and from there your can to jump beginner friendly bugs on launchpad. To get a better insight into mailman system, you can also go through their documentation http://wiki.list.org/DEV/A%205%20minute%20guide%20to%20get%20the%20Mailman%… https://pythonhosted.org/mailman/src/mailman/docs/START.html If you get stuck you can contact someone at IRC also, at #mailman on freenode. > Hi Developers, > > I am final year computer science engineering student from UPTU. I want to > contribute to the organization by becoming a part of GSoC 2015. I know > C/C++, Python, Javascript. > I went through project ideas of Mailman and found "Github/development > tools > integration" interesting. Please guide me for the next step. I want to > start exploring asap to get good grasp of the platform required. > > Thank You, > > Karan Dev > Github: https://github.com/karan10 > Blog: https://karandevjre.wordpress.com > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers(a)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/2013001%40iiitdm… > > Security Policy: http://wiki.list.org/x/QIA9 >

6 years, 2 months

GSoC 2015 aspirant: Github/development tools integration

by Karan Dev

Hi Developers, I am final year computer science engineering student from UPTU. I want to contribute to the organization by becoming a part of GSoC 2015. I know C/C++, Python, Javascript. I went through project ideas of Mailman and found "Github/development tools integration" interesting. Please guide me for the next step. I want to start exploring asap to get good grasp of the platform required. Thank You, Karan Dev Github: https://github.com/karan10 Blog: https://karandevjre.wordpress.com

6 years, 2 months

GSOC 15 Interested in project Mailman client written in Javascript

by kiran ps

Hi, I'm an Engineering student(computer science) pursuing my degree from Government Engineering College(Calicut University), Thrissur, India. I went through Mailman gsoc idea list.I'm interested in the project Mailman client written in Javascript. I have good skills in JavaScript, nodejs, angular, python. I am looking forward for a good response from your side regarding details about the projects so that I could start contributing towards it. Skills: Languages: JavaScript, nodejs, python, HTML5, CSS3, C, C++ Libraries: jQuery, underscorejs, zeptojs, KineticJS Frameworks: Angularjs, Express, Django, Tools: Vim, Git, Grunt, bower, Yeoman Thank you, { name: "Kiran P S", email: "pskirann(a)gmail.com", github: "github.com/kiranps", google+: "plus.google.com/+kiranps1", twitter: "@pskirann" }

6 years, 2 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers February 2015