Mailman 3 January 2014 - 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] Mailman 3 vs Groupserver vs Sympa
by Ian Eiloart March 14, 2014

March 14, 2014

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

GSoC 2014 ideas list
by Terri Oda Feb. 9, 2014

Feb. 9, 2014

I've had prospective Google Summer of Code students emailing me since, uh, September or so... so I guess it's time to talk ideas! I've set up a wiki page, as usual: http://wiki.list.org/display/DEV/Google+Summer+of+Code+2014 But let's start with here: what small projects would you like to see us sponsor this year? I think we'll need to be more selective about the final list, but let's start with some brainstorming!

7 13

Re: [Mailman-Developers] Mailman web UI Error
by Florian Fuchs Jan. 30, 2014

Jan. 30, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/30/2014 12:40 PM, Kevin Ratnasekera wrote: > Hi, I am Kevin Ratnasekera, Undergraduate from University of > Moratuwa Sri Hi! > Lanka. I am currently developing a Cloud connector for mailman 3 > as part of my internship project. For this I am using the REST api > for mailman-3.0.0b3. I am currently following this tutorial > http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI… > > and I am getting this error while creating a new domain, user , list etc. > > NameError at /postorius/users/new/ global name 'utils' is not > defined Unfortunately you ran into an error that just got fixed yesterday. Updating your postorius branch should fix that (bzr pull). If you're especially interested in using Mailman3's REST API, I'd also recommend taking a closer look at the Python bindings (mailman.client on launchpad - docs are in the repo's src/mailmanclient/docs directory). It's a Python wrapper which makes accessing the REST API pretty easy. Cheers Florian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS6r6nAAoJEEceGbPdavl7ObsH+QHD48xlDqEVCw/qk88OCvNM oMeJJeuJM7qournaRofCjNp8Z3JWUlltXGIBMd4iKPsIjmUdNQPTwXaxUeRJb3vD XeVw26ThLzNbjocxcM2HtgOKFwJrPcX6Ov/H0JLsNIwA83V9fClxbEuJ60LNNQ7r DFJLiqwsozJbOz1khBqjyyg/xbIhcTIko9Yo+jJyqzgEdNhv0gUBYtsJN/xOJZVB YD2MwqlFt7UVKrQIpjyZ1ceZz6PZaZnYgAxgKY2DjApChqbbA5lFnhgtcKtYwAZN CqEWJ2juB71dGmBSsG8f7ThrLmERKYCICft8iOPnRLhV/xjtWgoP8j7E+SiR6E0= =yTb3 -----END PGP SIGNATURE-----

1 0

Mailman web UI Error
by Kevin Ratnasekera Jan. 30, 2014

Jan. 30, 2014

Hi, I am Kevin Ratnasekera, Undergraduate from University of Moratuwa Sri Lanka. I am currently developing a Cloud connector for mailman 3 as part of my internship project. For this I am using the REST api for mailman-3.0.0b3. I am currently following this tutorial http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI… and I am getting this error while creating a new domain, user , list etc. NameError at /postorius/users/new/ global name 'utils' is not defined Request Method: POST Request URL: http://127.0.0.1:8000/postorius/users/new/ Django Version: 1.4 Exception Type: NameError Exception Value: global name 'utils' is not defined Exception Location: /home/kevin/postorius/src/postorius/models.py in create, line 88 Python Executable: /usr/bin/python Python Version: 2.7.3 Traceback: File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py" in get_response 111. response = callback(request, *callback_args, **callback_kwargs) File "/usr/local/lib/python2.7/dist-packages/django/contrib/auth/decorators.py" in _wrapped_view 20. return view_func(request, *args, **kwargs) File "/home/kevin/postorius/src/postorius/views/user.py" in user_new 261. user.save() File "/home/kevin/postorius/src/postorius/models.py" in save 151. self.objects.create(**self.kwargs) File "/home/kevin/postorius/src/postorius/models.py" in create 88. method = getattr(utils.get_client(), 'create_' + self.resource_name) Exception Type: NameError at /postorius/users/new/ Exception Value: global name 'utils' is not defined Any comments?? Regards Kevin

1 0

Re: [Mailman-Developers] Migration script from MM2 to MM3
by Barry Warsaw Jan. 15, 2014

Jan. 15, 2014

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

PGP-signed message verification using the email module (and in Mailman)
by Paul Boddie Jan. 11, 2014

Jan. 11, 2014

Hello, Sorry if this is too off-topic for the Mailman list and should really be directed to the email-sig list, but as I noticed that one of the GSOC projects touched upon message signing and verification, I thought that there might be more expertise on hand amongst this list's members, and there is a remote possibility that some of my difficulties can inform that work, too. I've been looking into using the Python email module for signing and verifying messages according to RFC 3156, but one difficulty I encountered was where a message with the following form is received and parsed: Content-Type: multipart/signed ... -> Content-Type: ... ... This is the content being signed (together with the part's headers). -> Content-Type: application/pgp-signature ... -----BEGIN PGP SIGNATURE----- ... -----END PGP SIGNATURE----- Obviously, the email module permits the inspection of the message, and the apparent solution in verifying the message is to obtain the signed content along with the signature (using the get_payload method on the top-level multipart container) and then to pass them both to gpg for verification. Something like this... content, signature = message.get_payload()[:2] We might also choose to decode the signature, I imagine, since it may employ a transfer encoding: signature = signature.get_payload(decode=True) However, in an almost accidental discovery involving Python 2.5 and 2.7 being used for the respective signing and verification operations (and in reverse), what I found was that the email module would parse the signed content part but then, upon being asked to provide the string representation of the part, it would reformat the headers and thus cause the verification to fail. So, where the email module in Python 2.5 likes to wrap headers using tab character indents, the module in Python 2.7 prefers to use a space for indentation instead. This means that the module reformats data upon being asked to provide a string representation of it rather than reporting exactly what it received. The behaviour of the module is fairly understandable - no-one wants to keep the original data around in addition to having a more manageable parsed form of it - but is there a convenient way of preserving the form of the original message for future use? It seems that asking for the individual headers will yield the original formatting, and that the _headers attribute on Message instances provides the original headers in order, but I wonder if I'm missing a simple method to get things as they were received and not as the particular version of the module wants to format them. Of course, RFC 3156 warns about the pitfalls of encoding the part that is to be signed, and I have been tempted to use a conservative approach where signed content is wrapped up inside an opaque message part with headers that are unlikely to be rewritten, but if I can manage to work with the email module rather than around it, I can hopefully steer clear of such inelegant measures. Does anyone have any opinions or experience that they would like to share on the matter? Paul

3 4