Mailman 3 July 2013 - Mailman-Developers

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

07 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

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

Wiki Migration Update
by Paul Boddie 07 Aug '13

07 Aug '13

Hello, Once again, I've had some time to push the wiki migration along. As always, the results can be found here: http://mmwiki.boddie.org.uk/ I've updated the archived content to that of 16th July, so the translated content should reflect the existing wiki fairly accurately. Users ----- Big changes this time have happened around the handling of user information. I have modified the MoinMoin package installer to preserve author/editor details, a capability which for some reason had been removed from MoinMoin. I also need to preserve timestamps as well so that the history of each page makes a bit more sense, but at this point you should be able to see individual contributions: http://mmwiki.boddie.org.uk/DEV/LogoSubmissions?action=info The XML export archives do not contain user details over and above who edited which page (or who uploaded which attachment), but I have written scripts to obtain usernames from the archives, to fetch user details from the existing wiki, and to create accounts for users in MoinMoin. An alternative might involve getting a database query run on the server to provide user details: https://confluence.atlassian.com/display/CONFKB/How+to+Export+User+Data+to+… There's also some kind of export functionality in Atlassian OnDemand, whatever that is: https://confluence.atlassian.com/display/AOD/Exporting+wiki+data But the solution above may be good enough: it just creates an account for each existing user and employs the same username, full name (or alias) and e-mail address, and sets a random password. It also obtains the URL of any profile picture, with these user details obtained by scraping the home page of each user on the existing wiki. How people then log into their accounts is something we can decide: e-mailing the random password is not exactly secure, but they could reset their account in the MoinMoin interface instead (which involves a reset e-mail that isn't too secure either, but it's the slightly better choice). Redirects --------- One thing we also discussed were the redirects that occur for "tiny URLs" and where page identifiers are employed. For example: http://mmwiki.boddie.org.uk/x/AgA3 http://mmwiki.boddie.org.uk/pages/viewpage.action?pageId=3604482 A mapping of page identifiers is extracted from the exported data, and this mapping is used to support a simple redirection script that looks up the appropriate page name and redirects to that page. One thing it does not yet do is to redirect to a specific revision, however. To Do ----- I always provide a list of things that still need doing, so here are some familiar items: The way comments are presented on pages still needs improving. I may write a macro to include the comment pages in a nicer way and maybe even to allow new comments to be added. Meanwhile, the comment pages should now only be editable by their original authors (by applying ACLs). 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. 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. 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 a look at your favourite pages and let me know where improvements can be made to the conversion process. I usually apologise for pages with question marks at the end of their names, which is a lot of the FAQ, but I've implemented a mod_rewrite hack that lets you view them, so if your passion is for FAQ fidelity then please take this opportunity to have a look. I hope this is of interest! Paul

4 12

A list of discussion topics: GSoC OpenPGP Integration
by Abhilash Raj 07 Aug '13

07 Aug '13

This is a list of topics that probably needs to be discussed in detail again. I tried to mention in breif about the discussions in past personally with a someone or on mm-dev list. Please ignore the topics which you feel has already reached a inference. It is a long mail though. * How to ensure the keys belong the email it says it does? One method proposed for this was to send a confirmation email to the email address, but what if the email is intercepted in between and the attacker confirms the sign up of the person he is trying to impersonate? Or this is a problem that can be solved with SSL and is not of our concern? * Inline pgp should be supported or not? Although its not included in one the best practices but some people still use it for the purpose of signing only a part of the email. * How to handle partial multipart/signed messages? In previous discussion it was pointed out that we should strip off the parts till we actually arrive at a point where the signature verifies all the text and then send that part to the subscribers. Other options were to discard these kind of email or let the owner decide what he wants. * Should mailman keep the signature of sender before signing or strip if off? In previous discussions it was mentioned that user's signature can be kept as it is and the list re-signs the message before sending the subscribers as subscribers may want to confirm if the email was originally sent by the user in the From address. But there might be a case of anonymous list where identity of the sender should not be revealed and is only verified that any one the members sent the email. So can we introduce this as an option? About introducing options I agree to a point mentioned in the mailman-pgp-smime patch for mailman where it says that although there are lots of ways we can allow the list owner to configure a list, we should only provide minimal options to avoid unexpected scenarios where the list's security is compromised due to lots of options. * Should we make the sending of signed copies of email default? We can introduce an option to send signed email by default for those who want may verify the email, but is there a point in sending singed email when the mails received are not signed? Or this could be a good point? * Email interface to manage keys? Mailman has a set of email commands to process the requests for subscription, change password and many other things over email without a web interface, so to allow managing keys over email we could allow receiving signed emails with new keys and command to add them, the confirmation mail for the new key will then be sent to the same address but would expect a signed reply from the new key. * How are we actually using the web-of-trust model of OpenPGP? Should there be any restrictions on the key to implement the web-of-trust model which advocates for the authenticity of the key provided by the user? Something like it must be signed by 2 or 3 people or anything like that? About the implementation I decided to take up with the processing of email part first and then setting up the PKI for the users. The flow would be something like this: * the message is queued in incoming queue * the incoming runner wakes up, finds the message and calls a few functions to verify the signature of the message(assuming the function already has public key of the user from somewhere) * If the message signature is found to be valid the message is then passed on to onther runners as usual (without stripping of the signature as per my assumption till now, need discussion on this) else it is dropped or bounced depending on the state of verification( like if the signature is older we can inform the sender as the delay may have been due to smtp deliver and simply drop the message if the signature is verified to be wrong). * Now a valid signature would be a signature signed within 4 days(default and configurable by list owner) from when mailman receives the email.(Is there someway to also check if the signature was previously sent on the list? so that we can block that also?) * After that the message passes on to various other queue and runners as usual and when finally it arrives at outgoing runner it again calls a few functions to sign the message and send it to MTA. I think the function to prase message, check signature, resign message could be there in utilities as a gpg.py module. Which is where I think I should first start from. I was looking for a python wrapper for gnupg and found two options: [python-gnupg][2] and [gnupg-interface][3]. GnuPG-Interface was what was used in pgp-smime patch for mailman 2.1.5. I don't have much idea about waht should be used, will post on mailman-developers. About the outgoing messages i was thinking if we can create a signing queue and sign runner which simply signs each message with list's private-key and then the message moves on to outgoing queue where it can be delivered without any furthur changes. Any ideas about this? -- Abhilash Raj

7 23

GSOC Midterm Report
by Abhilash Raj 06 Aug '13

06 Aug '13

Hi all, This is report of my GSoC project - OpenPG integration with GNU Mailman for midterm. The code is updated at my launchpad branch[1]. Accomplishments: * A signature rule(src/mailman/rules/signature.py) to check for OpenPGP signature in a message, incase the signature is found it tries to verify the message using gpg utility. * A gpg utility(src/mailman/utilities/gpg.py) to perform all the signature related tasks using `python-gnupg`(v0.3.4). It signs and verifies the signature. * A signmessage handler(src/mailman/handlers/signmessage.py) to sign the outgoing message using the gpg utility.(Signing a message is still incomplete in the sense we do not have a way to store and use keys. For now it has a pubring.gpg and secring.gpg inside (var/gpg/). It will be replaced with actual keyrings in future.) * Tests for each of the three modules above. Testing gpg.py was a small challenge(for me). Issues and Roadblocks: * Signature verification using `python-gnupg` was a PITA to me for sometime. The way it accepts the string and signature for detached signature is not documented at all and is converse of what I could think of. It just occurred to me to try out the other possibility which turned out to be the right way. * Version control was also a issue that I encountered. Initially I started to work on git mirror of mailman. When I tried to port the code back to bazaar and push to github it took me(and others) a lot of brainstorming. Finally I did that using bzr-git. * Deciding the structure of the signed message that we were going to send out. Initially it was decided to leave sender's signature intact so that if someone wants to verify it he can do it, but there can-not be two 'pgp-signature' parts in a conventional multipart/signed message. I wrote the code to follow an internet-draft[2] i discovered one-day. But then I commented out the code and also added another format mutipart/alternative { multipart/signed { text/plain, application/pgp-signature } multipart/signed { text/plain, application/pgp-signature } } Some furthur assistance and research on which format do MUAs support the most should be implemented. * python-gnupg does not provide any way to search for keys based on key-data like email-address. I need some more work to get this working. Future Plan: The next plans for this project include testing all the above parts thoroughly and then moving on to creating a PKI for the key. Also the settings for the list-manager to adjust a few options related to signed lists - like time limit(decided from date in signature) to consider a message old, and also implementing this in code. Schedule: My work remains two to three days behind the schedule i proposed. I hope I will be able to give some extra time and get back to schedule soon. [1]: https://code.launchpad.net/~raj-abhilash1/mailman/master [2]: http://tools.ietf.org/html/draft-ietf-openpgp-multsig-02 --- Abhilash Raj

3 5

GSoC Progress Report - Authenticated REST API
by Manish Gill 25 Jul '13

25 Jul '13

Apologies about the encrypted message before. Hello, I've been documenting my progress weekly at my blog [1]. I'll give an overview of the work done. So far, me and Richard have created a new Django app mm-rest [2], which is the base of the new REST API, modified Postorius to use the app's models, which will communicate with MM-Core to get the data and expose it via Django-Rest-Framework. The approach we have been taking is to have mm-rest mirror the models exposed by the MM-Core alongside adding any of its own modifications. This makes it easy to integrate Django and any extensions/libraries for the API models. This also lets mm-rest handle the primary User model and any authentication/authorization that goes along with it. The design choices have been outlined in this [3] document. Postorius code has also been modified [4] to use these models instead of MM-client. This lets Postorius do its essential jobs even if there is no available connection to the Core. The issue that we have been working on right now is syncing. Changes b/w the Local mm-rest database and core database need to be properly synced. The data in mm-rest essentially acts like a cache for the core, so there needs to be proper integration how long that data is there for (expiration time etc), and how do we handle situations where the core database is modified without any knowledge to the local one. That's about it for now. [1] http://manishgill.blogspot.in/ [2] https://launchpad.net/mm-rest [3] http://bazaar.launchpad.net/~mgill25/mm-rest/trunk/view/head:/website/publi… [4] https://code.launchpad.net/~mgill25/postorius/m-trunk/+merge/175549

1 0

GSoC Progress Report - Authenticated REST API
by Manish Gill 25 Jul '13

25 Jul '13

-----BEGIN PGP MESSAGE----- Charset: ISO-8859-1 Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ hQEMA1FCth+r/vDlAQf+KQRfH5VjI5JZlTUVQOjlaXceS0R4jwFEQvfMZMhBSasn mAOSEeDbkJtKf4PbOqMg5TVj1UMj9PHSGO35vPVQJvC/CbK2+rV8Tyi/97rBkWbG 0PcpTTa+PhcOIfQuydl4TOEhqFvM+qQTukWZSl36liygFIB6Ji1Zuw5zFYouz63C MAZLckxwsmB6wI+y//06WjXtiLA+0i5mLkzp8fFft11v4+ZNE/F2Euvn9wZHJjzX BCFb5kwqhiAdIwY5bj3R9DSLeM4Z+aPc1ZYZ0OlL3UqP20vQBxtDadHymZ9SJcep i692zoDxaTtohkMqPqH19ifyHVZtAo9ifksZrEO0QdLqAV+piFXz/F3ILk5lFk8l 5836tQeR1cVpF1bDQvvxwfpzzpqr5BStnIDTHIWNHHYzlKTMxe7ieOksu6BEyusR WS+w87T9r29Sl9u9+tHN2XFqNN9OCAIYQbtJVow0Mk2ThxapJire93ztwvZCPwJ7 WorharPCJL2imkN2Pyf+a8fQImeatbFiWqUqJgauBcnVxF661q/v5L+W8ITUnaLz tbTJS8QBlQnEirO2ZdDYoRcnsWP1Truo8mhUKIS+RMp4xsmyURfS5D3N6uMGCBex qV0W4fQegQ6MlgHS3UNn/7gF1TL6oB0aZ735ZJMfVBnXal4uisfmofES5CJR6iSL UPiyskucp4vKemdetLl5cQDoP/6Q/uXYbNCL/alx+HDbeMJ/HlNV+8n/WeK77j/8 +drXhSMjUSzENlrKMzh3nvbp7DoLHIExMvQVYixG464z2tIR/W+ekG2vgbxj4r/1 4CFrI4/lu624MC+TKOnHCl4Q97SAFhFwTQVhH/J7taYdpdfDB0wbxJyt22p1n2xP XdkfwFxr1HDJEWT6XzKMr/TxJWcmzxsh0qFXXvXEn5jy8a85S4vXtYQotTs8xCj1 XMr5WPDowHDH0N/TEfidbCPtk9/Gl0EBkJk3ude69HyELRf65+pLgoJLqeXQQDbd zwIwC64ZtiTAFMC9uGSh899XJlNW32h3uGkWzgCzh4RSaiyMgAIVoWMLQ0ACo0Ez FJHokNMYfMH83Tom6d8wegdm1ZTFC8cSQal1Dp8uNMk7uL53OWIQlinO3CWsdBOf cOey3yZgzMKO1TVYWNZtPuNAXrI+98Ur/ZE4hfWgT15C1ga8FBHM/G56WTUNxY3r v2HY8JuwRDZiH2xO4JPjlSQN4ohtJ8D/jvTKIjY5n4plweRhRV9DLbFz6sfwqdFn k+gZAX7mn9d+l0zZ2FTkAmIdsC5CL9x8jylk/gxJkYkYl8dw2KNUkHUekUbGX2pK uj9i2NUkSkSCWuWhMoe7ZNyb/b5uUW61FzYwD3bVggEcfDlWao17D9TFJi1nTK9l pbLdui20iwO4U717/UDdw8InliWncwKKmA5yPEFL5HGXyzqp8G16DBm0LFJszEUI /1xaTIFBIUIEciSXFkoDvfPJA5lrLQdBifrab1CUuiUDVOGPZS7r8ob44XCE2bU3 HDmdT8ifvEh3+ZHtX03vguGNi1JUML6bCyNFIV+RXWO0igKq0EgFu8RmUBc6PXJD 2X5/Kd7StIVntn1EYhPzV3bIR7ZUS3jxP4OklwkLuo+xxcL5A65QjhEPOX/ojoOQ bU0QEywNr32oqB+1ZrmehsWabgbou6AnvPfeUUf2Sa26LvhEDKQ4kfGXh2YKGfAC wMBv8ahCBFfO4hzRWwtErPPsZRFkabuvxsk2SR65TSUrLH1RCK0l/sUebCa+HOuU yZ9y83VABQHB0GID/m+jVodtUWOZf125mfHg2OipKwRjRxRaNZgzWdLVGs+QW9mz R6g7/5ZEGZyDGjUMLrrc5GNORm2eBoHomlzJA8yvHSR87JpOIv252ipjcpqdSr0k Ghsp3lltAufDvWJNZwdtxK7gqWP51fHkzfC5CQYrUFAA/wskv0RVIbILMDO4YqEG Cmh99Xr/Nl9kUNvSaqSRjpH0nIw+Unc4OL5EOvKABqgm2yoRD/W4W3NIpQkMxBBI faBHdaMJhH9xRpHMXZXVXGYa+Opabml5jwvv2SRTGbiDU5OLvICrt8ETF9qoOgOR QhOyXOU4zHZmf4fiBy1ZV0S3 =gbbw -----END PGP MESSAGE-----

1 0

GSOC Progress report
by Abhilash Raj 24 Jul '13

24 Jul '13

Hi all, I am sorry for this delayed post, this is a brief report on my progress on gsoc project(OpenPGP integration with GNU Mailman). I have added a new rule called as 'signature'(src/mailman/rules/signature.py) which verifies if the signature in the email is valid. There is a strict implementation of RFC 3156 for the messages that we accept, only 'multipart/signed' with exactly two parts one of which is 'application/pgp-signature' is accepted, rest are held/discarded/bounced as per the list policy(whose implementation is still remaining). The signature rule uses 'gpg' utility(src/mailman/utilities/gpg.py) for verification of the signature. The storage and usage of keys is not implemented yet, for now only one key is used i.e. in the tests, the key is added as test data. The testing of this module was interesting work for me, the test-data gets copied from the 'var/gpg' directory to the temp var directory created on-the-fly during configLayer setup in tests. The work on 'sign' handler(src/mailman/handlers/sign.py) is under progress right now, it signs the text in the message body with the list's secret key. One the issues for this implementation is the structure of message that goes out. We decided to leave the sender's signature and add list's signature so that if someone wants to verify sender's signature he can do it easily. But there are issues with the structure of the message which would support more than one signatures simultaneously. There are options like one in this[1] document and other suggestion from Steve and Daniel. Also there has been some issues with pushing my version of code versioned in git to launchpad so the most recent code is available at my github repo here[2]. Efforts are on to push the code to lp and send a pull request soon. [1]: http://tools.ietf.org/html/draft-ietf-openpgp-multsig-02 [2]: https://github.com/maxking/mailman -- Abhilash Raj

1 0

GSOC Progress report
by Abhilash Raj 24 Jul '13

24 Jul '13

Hi all, I am sorry for this delayed post, this is a brief report on my progress on gsoc project(OpenPGP integration with GNU Mailman). I have added a new rule called as 'signature'(src/mailman/rules/signature.py) which verifies if the signature in the email is valid. There is a strict implementation of RFC 3156 for the messages that we accept, only 'multipart/signed' with exactly two parts one of which is 'application/pgp-signature' is accepted, rest are held/discarded/bounced as per the list policy(whose implementation is still remaining). The signature rule uses 'gpg' utility(src/mailman/utilities/gpg.py) for verification of the signature. The storage and usage of keys is not implemented yet, for now only one key is used i.e. in the tests, the key is added as test data. The testing of this module was interesting work for me, the test-data gets copied from the 'var/gpg' directory to the temp var directory created on-the-fly during configLayer setup in tests. The work on 'sign' handler(src/mailman/handlers/sign.py) is under progress right now, it signs the text in the message body with the list's secret key. One the issues for this implementation is the structure of message that goes out. We decided to leave the sender's signature and add list's signature so that if someone wants to verify sender's signature he can do it easily. But there are issues with the structure of the message which would support more than one signatures simultaneously. There are options like one in this[1] document and other suggestion from Steve and Daniel. Also there has been some issues with pushing my version of code versioned in git to launchpad so the most recent code is available at my github repo here[2]. Efforts are on to push the code to lp and send a pull request soon. [1]: http://tools.ietf.org/html/draft-ietf-openpgp-multsig-02 [2]: https://github.com/maxking/mailman

1 0

Mailman Hackathon this Sunday (July 21 2013)
by Florian Fuchs 18 Jul '13

18 Jul '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, We're going to do another IRC Hackathon this Sunday for all things Mailman! This time we'll start around 0700 UTC and will stay until 2300 UTC. Please join us, no matter if you need advice, want to have some code reviewed (GSoC midterms are approaching fast!) or just like to hang and see what everyone else is working on. Most of the Mailman mentors and developers are going to be there (we're distributed pretty much around the whole planet, so not everyone's gonna be there all the time...). So save the date: Sunday July 21 2013 0700 - 2300 UTC on #mailman (on freenode). Please note that while current GSoC students (both under the PSF and Systers) are especially encouraged to join, this event is for everyone interested in developing anything Mailman-related. Oh, and here's the link to that awesome timezone converter Terri dug up: http://www.timeanddate.com/worldclock/meetingtime.html?day=21&month=7&year=… Hope to see you on Sunday! Florian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR6F5fAAoJEEceGbPdavl7P1EH/0cROuMotLQbvz/yM1nkT5kn I37EtxW+1rXQXzotL1HZxSmFaI85iXR9bOhLqcKZkSswIL5HhUlXeIztx216RpSh A09K3gu6u7kFOvITkaZIA/26r0uNLbTyGsqjLZqCJbqtpSF6FHBqQdsAFQD8fNsq BiOP1VEv76Q2Cdaxyd4eDzmdH635Feb1xf3s8UvaDuILWQebZlGgxAhJmwbpe96H E4lKAzMJD4bH3NpImWa98EAi1OqmBULtzEChB6t76jt3eEp3xUpIm8zMM+CA0xsf q+AxOaMR11I+y1iPHX54xatS0UelBhQIearm0jSHsSqjATgArf8u6J7LNdkxyrY= =qBFY -----END PGP SIGNATURE-----

1 0