Mailman 3 February 2015 - Mailman-Developers

before next release: disable backscatter in default installation
by Jo Rhett Nov. 7, 2022

Nov. 7, 2022

Hi. There's a fairly simple problem here that needs to be addressed. And it's mostly a documentation/install problem. I'm hoping we can get this resolved before the next release. PROBLEM: Mailman comes out of the box ready to backscatter spam people. Yes, it's easy enough to fix. But because it comes stock this way, and is documented to install this way, most people install it to do this. Those of us who work in abuse departments are tired of hearing "well that's how Mailman works". We also object to having to teach people how to fix their mailman installations because it's not documented in the current manual. This is *exactly* like Sendmail 14 years ago. We didn't accept it then, and Sendmail fixed the problem. RESOLUTION: Mailman default installation should not backscatter in a default configuration. 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by default. Nearly everyone uses web based signup. 2. Discard or hold messages from non-subscribers by default. I would think that it would be perfectly reasonable to have documentation on how to enable the 1980s-style -request / -subscribe etc aliases. However this documentation should have a note that this is against the AUP of nearly every network provider, and enabling it will likely cause them to get listed in various blacklists as a backscatter source. FYI: I know that this goes against the instincts of many old-time mailing list advocates here. But after dealing with a 10k/hour backscatter DoS my tolerance for this problem is understandably limited. Yes, it was a sweet day back in the 1980s. I was running a mailing list server and several UUCP gateways at the time, so I remember them well. But those days are past, and we need to deal with the reality of today. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

21 168

Re: [Mailman-Developers] MIME footers
by Daniel Kahn Gillmor March 10, 2015

March 10, 2015

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

3 2

Announcing the new wiki.list.org
by Barry Warsaw March 3, 2015

March 3, 2015

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 21

Re: [Mailman-Developers] GSoC 2015: brainstorming ideas suitable for beginners?
by Stephen J. Turnbull March 3, 2015

March 3, 2015

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.

3 2

Re: [Mailman-Developers] GSoC 2015: brainstorming ideas suitable for beginners?
by Barry Warsaw March 3, 2015

March 3, 2015

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

2 1

Query regarding plugin integration with mailman3
by Aanand Shekhar Roy March 1, 2015

March 1, 2015

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

2 1

Re: [Mailman-Developers] MIME footers
by Barry Warsaw March 1, 2015

March 1, 2015

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

4 4

GSoC 2015: brainstorming ideas suitable for beginners?
by Terri Oda March 1, 2015

March 1, 2015

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

10 25

Re: [Mailman-Developers] GSoC 2015 aspirant: Github/development tools integration
by Aanand Shekhar Roy Feb. 28, 2015

Feb. 28, 2015

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 >

1 0

GSoC 2015 aspirant: Github/development tools integration
by Karan Dev Feb. 28, 2015

Feb. 28, 2015

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

1 0