Mailman 3 October 2013 - Mailman-Developers

before next release: disable backscatter in default installation
by Jo Rhett 08 Nov '22

08 Nov '22

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] Mailman 3 vs Groupserver vs Sympa
by Ian Eiloart 15 Mar '14

15 Mar '14

Hi Kẏra, Some additional answers, inline below. Most of your questions relate to the web archiver, and Nico has answered some of those. In order to get all the questions and answers in the same place (so people can see which questions aren’t yet answered here), I’ve rolled Nico’s comments into this reply. On 7 Oct 2013, at 03:38, Kẏra <kxra(a)riseup.net> wrote: > Hello, > > My name is Kẏra and I am the technology director of the Free Culture > Foundation as well as a campaigns organizer for the Free Software > Foundation and we're in need up upgrading our mailing lists to a more > web-friendly system. I'm doing research on newer list severs to see how > they compare. So far Groupserver seems to provide everything, but if > Mailman 3 is going to be released soon, we'd like to consider that as well. > > I'm making a comparison chart and wanted to ask about Mailman 3 (and > Postorius) features. Answers to any and all of the following with regards > to Mailman 3 + Postorius would be super helpful: > > Can you post from the web interface? yes > Is there file upload support? yes > Is there now a search feature? Can it search multiple lists? yes, yes > Are there web feeds (atom or rss)? Generated from lists? searches? threads? > files? Nico’s plugin API seems to be offering support for this. > Are posts and administration integrated into the web interface? I think that site and list administration are not part of the hyperkitty > Can you specify a posting rate restriction? I don’t know. > Is full css customization for the web interface supported? > Is css customization for the email interface supported? Hyperkitty supports "themes". I’m guessing you’ll be able to roll your own. > Is there site-side logging? (as opposed to server side) Logging (apart from web accesses) would be a Mailman responsibility. I’m not sure what you mean by "site-side", but perhaps you’re after remote reporting on a domain of yours hosted a third party at a remote site. Again, that’s possible. It could be provided through a web interface, or some other means. > Is there a link to the post in the web interface in the footer of messages? That’ll require co-operation between Mailman and the web archive. But, if the web archive URL is predictable, then I think Mailman will be able to do this. > Now that users are more than just email addresses, can you request to > contact a list member? Do you mean from their profile page, or from a list of members? > Can users have multiple email addresses? Yes, that’s a part of users being more than just email addresses. > Are there profile pages where you can see a summary of their latest posts? yes > Can the web interface hide quoted text? yes > Are usage statistics provided? The Hyperkitty change log for 0.1 alpha says "show basic list info and metrics". Certainly the Mailman 2 logs provide enough information from which useful usage stats could be derived. If Hyperkitty doesn’t provide the stats that you want, you’ll likely be able to get them from the log files. > Thanks! > > Also, did Mailman 2 already support LMTP and virtual domains or are those > new? They’re new. Mailman 2 did have partial support of virtual domains, but there was a restriction whereby no two domains could have a list with the same name: so I can’t imagine that this would be useful. > > Best, > Kẏra > > -- > Board of Directors, Free Culture Foundation: www.freeculture.org > Campaigns Organizer, Free Software Foundation: www.fsf.org > > Blog: http://kxra.info - StatusNet Microblog: http://identi.ca/kxra > Email: kxra(a)freeculture.org - SMS: +1.617.340.3661 > Jabber/XMPP: kxra(a)riseup.net - IRC: kxra @freenode @oftc @indymedia > _______________________________________________ > 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/iane%40sussex.ac… > > Security Policy: http://wiki.list.org/x/QIA9 -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148

2 1

Re: [Mailman-Developers] Migration script from MM2 to MM3
by Barry Warsaw 15 Jan '14

15 Jan '14

On Sep 20, 2013, at 12:46 PM, Aurelien Bompard wrote: >What do you think? Bad timing? Any existing work I'm missing? I think it's a *great* idea. No, perfect timing. Not that I know of! :) What we've said in the past is that we weren't going to promise conversion scripts from 2.1 to 3.0, partly because that work was incomplete, but also because we wanted to caution users not to just blindly upgrade as soon as 3.0 is released. But I think having a reliable, well-tested, non-destructive option to upgrade would be wonderful, especially because I fully hope that a site could run 2.1 and 3.0 together for a while. Any help you need, let me know. (I've been ridiculously swamped at work these past few weeks. Apologies for being rather quiet lately. I hope that'll improve in the next couple of weeks.) Cheers, -Barry

3 3

Mailman 2.1.16 release.
by Mark Sapiro 23 Nov '13

23 Nov '13

FYI, I will be releasing 2.1.16rc1 in a few days with a target of a final release in early September. I believe the release will be very solid and stable. The main purpose of the candidate release is to expose any i18n changes so that translators can submit any updates and get them in the final release. There are a few new features, contributed programs, i18n changes and bug fixes, all of which will be announced when the candidate is released. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 10

Mailman Suite beta: what's left?
by Terri Oda 15 Nov '13

15 Nov '13

Stephen, Florian and I had a nice discussion at the GSoC Mentor Summit about what's left before we can release a beta of the entire Mailman Suite (i.e. Mailman core, Postorius and Hyperkitty packaged together). We're getting close! In fact, close enough that I'm going to suggest that we set a beta release target date of Dec 1st. I know we had a list of 5 things... but for some reason I can't remember all of them. Florian, Stephen, can you chime in? 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. 2. Postorius & Hyperkitty need a bit more work on the authentication management. Florian indicated that he's looking for some code review for the persona integration and that we'd really like a single sign on solution for postorius/hyperkitty to work together seamlessly. 3. We need some nice install scripts or packaging work so that installing Mailman Suite is easy. Probably for beta purposes this can just be a shell script, but we also talked about doing a meta "Mailman Suite" PyPI package and maybe doing a .deb or .rpm as proof of concept. 4. ?? 5. ?? Hopefully Florian and Stephen have better memories than I and can fill those in. Everyone else: anything you know that needs to happen before we can get a Mailman Suite beta out? Terri

9 29

Mailman DMARC Support (it's not what you think!)
by Jim Popovitch 21 Oct '13

21 Oct '13

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?reme… 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.

1 0

Mailman3: decorating non-ascii message templates
by Aurélien Bompard 19 Oct '13

19 Oct '13

Hey all, I first thought about opening a bug for this, but I think it needs a small discussion first. In Mailman3 the message templates are stored on disk (welcome.txt, footer-generic.txt, ...) However, unless I missed something, there is no hint about the encoding of those files. As a result, when I try the decorate() function (from mailman.handlers.decorate) on a non-ascii file, it crashes with a classic UnicodeDecodeError: 'ascii' codec can't decode byte [...]. Note: if the file contains no string to replace (like $fqdn_listname), it is passed through unchanged and it works. So how should we deal with this? I think that the TemplateLoader in mailman.app.templates should return unicode strings, because that's the closest to the moment when files are read, and unicode conversion should happen on the "external borders" of the application. Thus the TemplateLoader's get() method seems to be the right place. I see two options: - We require that all template files are stored in either ascii or utf-8. That's the easiest way to go, and we just decode the text after getting the file. - We use the fact that our Language entities contain encoding values. When the template is loaded from an internal URL containing the language, we add the corresponding encoding to the result metadata (to be retrieved with the info() method) and use that to decode the contents. This means that templates in non-localized directories still have to be ascii-only, and the same goes for templates retrieved from non-internal URLs (not starting with mailman://). It's more complex but it may seem more natural to the administrator, since he won't have to force UTF-8 encoding when editing a file. We must also think of not making it too hard for Postorius, which will probably only get UTF-8 posted from the webpage (since it's always displayed in UTF-8 IIRC). I would vote for the easy way for just requiring UTF-8 encoding, but I'd like to hear your thoughts on this. Thanks, Aurélien -- http://aurelien.bompard.org ~~~~~~ xmpp:aurelien@bompard.org Tell me and I will forget. Show me and I will remember. Involve me and I will understand. -- Chinese proverb

3 2

Re: [Mailman-Developers] Mailman 2.1.16 release.
by Mark Sapiro 17 Oct '13

17 Oct '13

On 10/16/2013 10:44 AM, Andrew Hodgson wrote: > > Thanks for this. All working fine this end. Only thing I can see is the version text still says that it is running RC3. and On 10/16/2013 07:21 PM, Christopher Schulte wrote: > Hi Mark, I pulled down > > http://ftp.gnu.org/gnu/mailman/mailman-2.1.16.tgz > > and my list web interface shows version 2.1.16rc3. Maybe someone > forgot to bump Version.py ? Actually, it's a bit more tangled than that. For those keeping score at home, I have a script that I use to 1) bump the version 2) tag the release and 3) package the tarball. The issue is step 1) bumps the version, but doesn't commit, then step 2) tags the latest (prior) commit and then commits, and step 3) packages the tagged version which doesn't have the bump. Sometimes I remember to commit between steps 1) and 2), and sometimes I don't. I have updated the script to commit after the bump in step 1) which will avoid this in the future I hope. I have replaced the tarballs at the download sites: https://launchpad.net/mailman/2.1/ http://ftp.gnu.org/gnu/mailman/ https://sourceforge.net/projects/mailman/ with ones that have the correct version. This is the only difference between the new tarballs and the prior ones. If you downloaded one earlier and care about the displayed version, you can either download a new one or apply the attached Version.py.patch. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 0

Re: [Mailman-Developers] Mailman 2.1.16 release.
by Mark Sapiro 16 Oct '13

16 Oct '13

On 10/16/2013 08:31 AM, Andrew Hodgson wrote: > > Thanks for the good release as always. Sorry to ask this, but will your Htdig integration patch for 2.1.15 also work on 2.1.16, or are the differences too great for the patch to apply successfully? The patch for 2.1.16 is now there at <http://www.msapiro.net/mm/index_htdig.patch.2.1.16>. There were only a few minor line number changes between that and the 2.1.15 patch. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 0

Mailman 3 vs Groupserver vs Sympa
by Stephen J. Turnbull 07 Oct '13

07 Oct '13

Hi, Kẏra! Thank you for your interest in Mailman 3! I'm sure I speak for all the developers in saying that we are honored! That said, what follows is the well-informed (I believe ;-) but individual opinion of one developer, complicated by the fact that Mailman development is quite decentralized because the web admin and archive management interfaces have been hived off into separate projects, as Nico points out. I'm not sure everybody will be pleased by my next few remarks, either. If Groupserver meets all your requirements and is stable, I'd have to say that's the odds-on favorite. Mailman 3 core (the user and list database manager, and mail delivery server) is in late beta at this point, and very usable. A few sites are using it in production, though I have no idea how mission-critical those lists are. However, the web interfaces (Postorius for admin and HyperKitty for archives) are still in flux, and recent development activity in Mailman core has been more focused on security issues (verification and re-signing of digitally-signed posts, refactored REST interface to improve authentication). Finally, Mailman 3 is still really about *mail*. It's not web-centric, although web access is dramatically improved where the features have been implemented. All that said, Barry still openly admits he wants Mailman 3 to "kill web fora" and secretly hankers after Linux-style World Domination. It might be worth waiting for. :-) Also, regarding the state of Postorius and HyperKitty you should definitely contact their developers. Most of them do hang out here on mailman-developers, but there hasn't been a lot of traffic about progress recently. I suppose they have their own channels of communication. You wrote: > Are posts and administration integrated into the web interface? There is a Messaging Interface (aka MI) being developed by the Systers (as an alternative to Postorius/Hyperkitty) which provides some administration features, access to the archives, and reading and posting support. It is clearly intended to be used internally to an organization rather than as a way to support Mailman's traditional constituency of open subscription, (nearly) open post public lists. (Of course Mailman has been adapted to other kinds of lists such as anonymized lists, fully personalized lists, and announce lists, but it typically needs a lot of external support for applications like CRM.) > Can you specify a posting rate restriction? What do you mean? (Presently the answer is "no", but if you mean preventing users from posting more than N times in a day or something like that it would be easy to add.) > Is full css customization for the web interface supported? > Is css customization for the email interface supported? Again, what do you mean by this? Of course you can substitute your own CSS for that distributed by Postorius or HyperKitty in the web interfaces. There is no CSS in the email interface AIUI -- the email interface is whatever email program the user has chosen. I'm pretty sure that's not the question you're asking, though. ?? > Is there site-side logging? (as opposed to server side) What do you mean by "site" and "server"? Sites have to be served. > Is there a link to the post in the web interface in the footer of > messages? If you want one and are using an archive manager that supports it, it's customizable. (I believe HyperKitty does support that.) The Systers' MI assumes a web-based interface, so no link needed. > Now that users are more than just email addresses, can you request to > contact a list member? Not implemented as far as I know. It would be easy to implement. > Can users have multiple email addresses? Yes. > Are there profile pages where you can see a summary of their latest > posts? Not as far as I know, although HyperKitty could easily provide something like it, if not already implemented. Note that unlike LinkedIn (for one example) where there's a single profile page and the owner get an edit interface while 3rd parties get a read-only view, HyperKitty and Postorius will have different viewpoints about the user profiles (although HyperKitty can probably access the same information that Postorius does via Mailman core's REST interface). The Systers MI probably provides a more unified view, but it's pretty alpha at the moment, and Systers-specific. > Are usage statistics provided? Not by Mailman itself. They are easy to provide by trawling the logs (the Mailman 2 approach). In Mailman 3 they could be kept internally and made available by the admin interface to HyperKitty or Postorius if we knew what statistics are desired. What do you want to see? > Also, did Mailman 2 already support LMTP and virtual domains or are those > new? LMTP, no, although I believe it was possible to fake it by talking LMTP to Mailman 2's incoming SMTP interface (they're nearly the same protocol). Mailman 3 *only* supports LMTP for incoming posts, delegating the hairy interaction with the Internet to its upstream MTA. Virtual domains, yes, with the usually mild restriction that the same list address can't be used multiple times in different domains. Third-party patches to remove that restriction were available. In Mailman 3, that restriction has been removed.

1 0