Mailman 3 August 2013 - 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

Mailman 2.1.16 release.
by Mark Sapiro Nov. 23, 2013

Nov. 23, 2013

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

Can we send message with attachment using UserNotification?
by Nghia Vu Truong Sept. 1, 2013

Sept. 1, 2013

Hi there, Could you please help me with this question! Is there anyway we can attach a document to message, sending by UserNotification method? Thanks Nghia

3 2

GSoC Updates
by Abhilash Raj Aug. 29, 2013

Aug. 29, 2013

Hi all, So I think my work inside mailman for signing and verification is almost complete, here are a few things that I have now working and it would be very nice if some of you can have a look at the code and let me know if the implementation is correct(the logical and the pythonic way). 1) There is a 'signature rule'[1] that can verify signature from the users whose public key is stored in 'var/gpg' directory insider 'pubring.gpg'. This rule also verifies that the email has only two parts one of which must be 'application/pgp-signature'. 2) The 'signmessage handler'[2] signs the message while preserving the sender's signature. The structure of the message for now is a multipart/alternative with each alternative part having one signature(one from list and another from sender). (I have into my todo what Daniel suggested previously[3] to have two signatures in one pgp-signature part) 3) A 'gpg'[4] utility which does all the crypto part from signing to verification, generation of list's key, importing key from data(will be used if we allow user's to copy paste their public key data insider postorius), importing key from a public keyserver(default is set as 'pgp.mit.edu' on random basis, please suggest something which you think can be a better default). In line 81 I am passing an empty string to the comment for the key but still the key generated is still having the default comment 'Generated by gpg.py'. Any idea why? Is it because the string I am passing is a null string and it should have a non-null string to set as comment? 4) There are few other changes like adding the signature rule in default-posting-chain chain and signmessage handler in default-posing-pipeline. Also I have added a new config variable as 'gpg_dir' whose default value is set to '$VAR_DIR/gpg'. There are tests written for almost all the modules above, some more tests maybe required to be added to then though) I am thinking to setup a working installation of this code once I find a place to do that, so that we can find bugs more easily. Moving on my plan includes adding the APIs for management of keys and options for list-admin and users in postorius and mm-client. If anyone has ever given a thought before about what all things should be there please help me with it. [1]: http://bazaar.launchpad.net/~raj-abhilash1/mailman/master/view/head:/src/ma… [2]: http://bazaar.launchpad.net/~raj-abhilash1/mailman/master/view/head:/src/ma… [3]: http://www.mail-archive.com/mailman-developers%40python.org/msg13961.html [4]: http://bazaar.launchpad.net/~raj-abhilash1/mailman/master/view/head:/src/ma… --- Abhilash Raj

3 4

virtualenv and nose2 replace zc.buildout and zope.testing
by Barry Warsaw Aug. 27, 2013

Aug. 27, 2013

Hey everyone, A while ago I mentioned that I was trying to get rid of zc.buildout to build Mailman 3 and zope.testing to test it. This work is now complete and pushed to trunk. My thanks to the awesome nose2 project and Jason Pellerin for his help in answering my questions along the way. Updated instructions are available in src/mailman/docs/START.rst and it would be great if you could test this out. Here's a summary. * Create a virtual environment using Python 2.7 % virtualenv --system-site-packages /tmp/py27 * Activate the virtualenv and set it up for development % source /tmp/py27/bin/activate % python setup.py develop * Run the tests % nose2 -v This makes building for development consistent with building for (test) deployment, and simplifies Mailman 3's dependencies, and some implementation details are nicer now. Enjoy, and please let me know if you have any problems. -Barry

2 1

ANN: wiki.list.org migrations
by Barry Warsaw Aug. 23, 2013

Aug. 23, 2013

Hello everyone, I want to mention a few things related to wiki.list.org. First and most immediately, our currently wiki hosting provider Contegix, is in the process of a major infrastructure update which will cause some downtime for wiki.list.org. Contegix has been hosting our wiki gratis for several years, for which we are very grateful. Their support over the years has been superb. Unfortunately, the infrastructure our wiki is hosted on is quite legacy, and in fact, we are the last organization to be hosted on it. The time has come to for them to retire it, but they have again graciously offered to continue hosting our wiki gratis on their new infrastructure. The migration process is tricky, since we have to coordinate with Contegix's timing and our DNS changes with John Viega (Mailman's original author and owner of the list.org domain). Please be aware that the wiki may experience some downtime as both DNS and the instance get shuffled around. As some of you know, Paul Boddie has been working diligently on migrating our current Atlassian Confluence wiki to Moin. While Confluence has served us well over the years, we recognize that it is inappropriate for a GNU project such as Mailman to utilize a non-free wiki. Moin is our current choice for a free software wiki hosting platform, and Paul has done an amazing job on the migration, as anyone who reads mailman-developers can see. That work is close, but not quite ready for production. Stay tuned for more announcements on that front, or join mailman-developers for more information, or if you'd like to pitch in to help. We will send another announcement when the Contegix transfer is complete. In the meantime, if you see outages for wiki.list.org, please be patient. I hope there won't be too much of a disruption of service. Cheers, -Barry

1 0

Fwd: Re: GSoC Updates
by Abhilash Raj Aug. 22, 2013

Aug. 22, 2013

-------- Original Message -------- Subject: Re: [Mailman-Developers] GSoC Updates Date: Thu, 15 Aug 2013 19:44:43 +0530 From: Abhilash Raj <raj.abhilash1(a)gmail.com> To: Stephen J. Turnbull <stephen(a)xemacs.org> Thanks for the replies, I tried working on it and it was good enough to be used for now. Thanks Steve for trying it yourself. I have another few set of question now as I move towards signing and a few answers to it also(which may be wrong please correct me). 1) How do list owner create keys? What parameters? Which address? I think I will write a small doc on how to create key via command line in linux using gnupg and copy paste the ascii armoured text to postorious ui(which will be created soon). About the address I think owner can create a key using posting address with a min key length of 1024? or else mailman rejects the key? MD5 hash should be discouraged and at least SHA1 should be used?(although I found this[1] that even sha1 should not be used) 2) RSA or DSA keys? DSA can only be used for signing but is faster than RSA, although for now our scope is limited to signing later on we "will" add encryption so I think we should stick to RSA? 3) How to manage paraphrase(or passwords) for keys? In previous discussions we decided to use gnupg-agent and I although I haven't tried it. Any other suggestions to it? Also one more thing while running tests i noticed many other tests are breaking as initially a simple message could pass though "default-posting-chain" but now we need a multipart/signed message. So should I worry about changing all other tests? --- Abhilash Raj [1]: http://lwn.net/Articles/337745/ On Wednesday 14 August 2013 02:05 PM, Stephen J. Turnbull wrote: > Abhilash Raj writes: > > > After midterm evaluations I have been working on signing the message > > using one the keys associated with the list, now since `python-gnupg` > > does not allow selecting keys with key credentials( like address or > > list-name name) > > Have you tried this? In the GPG documentation, "key ID" often > actually means any of the above.[1] If python-gnupg simply passes its > argument to the gpg process, it should Just Work. Anyway, it seems to > work for me (some output edited for clarity): > > venv27 abhilash 15:39$ python2.7 > Python 2.7.5 (default, Aug 1 2013, 23:58:20) > [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > No entry for terminal type "emacs"; > using dumb terminal settings. >>>> from gnupg import GPG >>>> gpg = GPG(gnupghome='/Users/steve/.gnupg',keyring='test-pub',secret_keyring='test-sec') >>>> gpg.list_keys() > [{'dummy': u'', 'keyid': u'17A810C33BDFEFA8', 'expires': u'', > 'subkeys': [[u'2C376F1897FD6C1C', u'e']], 'length': u'2048', > 'ownertrust': u'u', 'algo': u'1', > 'fingerprint': u'A36D6B345C18B02E695B8B7917A810C33BDFEFA8', > 'date': u'1376462161', 'trust': u'-', 'type': u'pub', > 'uids': [u'GPG Test User <gpg-tester(a)turnbull.sk.tsukuba.ac.jp>']}, > {'dummy': u'', 'keyid': u'87EBCC0B6DF8B373', 'expires': u'', > 'subkeys': [[u'18E03AE36F3B6DAD', u'e']], 'length': u'1024', > 'ownertrust': u'-', 'algo': u'17', > 'fingerprint': u'A9FC56DBD48F5E5B61B7137487EBCC0B6DF8B373', > 'date': u'1183228371', 'trust': u'-', 'type': u'pub', > 'uids': [u'Stephen J. Turnbull (XEmacs Reviewer) <stephen(a)xemacs.org>']}] >>>> crypted = gpg.encrypt(u'A bit of random text.', u'stephen(a)xemacs.org', always_trust=True) >>>> str(crypted) > '-----BEGIN PGP MESSAGE----- > Version: GnuPG v1.4.14 > (Darwin) > > hQIOAxjgOuNvO22tEAgAgPUFFCFDKe8zSWt42IG7LkLWWbbTCiAsO7aM2pEgtFrI > KxRklwvEOX7bj5cYbmGr1PeM2IH58T4gMMHsYuOUyNzxS1mbsXZ9C4rpE0QJSkPY > +5Z10dpHEyAZ030g6uBeubFHC+78as1s10UP16zlVgs2AeZwfM88OBocs7FmUdZr > X5uAUxpB5RGET/zc2uHvBzIigXTzUrS8LrTtPfhyP8jCia6klX/2+2Q3gPlENoaP > PkIx/vZ7aKCIKyoP+pbLlwGAb/CX1WoQgyrsNFApg/HJhZ3ZLYKcvIqO3PNejOcN > 8ZYLRV4Uz0tLCuALCccw+XEZSQTKBoemXqVUwSKCAAf+OiHpMqDMoO7ReVVZg841 > MnRcZzfUnL8mj1FZwnr3iTcQ7BdUbu5vMAjn0SIlBISquu0rZi+wynGwgSpWnJeF > Llh+gjizNuHUxtO96phbwMeyVrD1yKSxkxC9cY0r8NBo/MTwUmyMCHNKpj0qrome > GZI2ekhYjLWfAbX3c6dwBx7pQhwkHkgMmoY6yN0OpLf1urnHGpv+AsEwDmWZ8mz3 > CLtD/l9eMl4LGIHNSV7yQ4lAzhYMenNdxkYJyKtxEvM1BFdqOblRb/h+B3X/xtT/ > 6ATAK1mZz1nU4H2EB1EvS4rbbQJ6oIevQSz3r/G6jSI7PqPDJvhnzQBrN7wh1pep > ldJQASeq3bCushTnFolWVxOgswXm2VFMPnhqEVxBJrZ12nZO2LGN7Y2/W+qQ/Qqb > DdYqbYOXNFW9r9p7ugJKKD1kK3XUkTC0Y+t1I/a7dLJBvpA= > =olXg > -----END PGP MESSAGE----- > ' >>>> of = open ('/tmp/cryptfile', 'w') >>>> of.write(str(crypted)) >>>> of.close() >>>> signed = gpg.sign('A bit of random text.', passphrase=u'Not useful without my keyring.', keyid=u'gpg-tester(a)turnbull.sk.tsukuba.ac.jp') >>>> str(signed) > '-----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > A bit of random text. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.14 > (Darwin) > > iQEcBAEBAgAGBQJSCz30AAoJEBeoEMM73++oWGcH/jS3AJ6OZLm8JHiLAI0AzCXe > muRVhPPfGrqL/Jr+l9WA8Zj3pClHa04H0ha3nvYFHPhN30lFDDw56iCPMA+DbJbr > 2BeqUSfJj36EGHOi8yV5iljZA4NhAw9qqhwQz7kas+KTeY8+98DQDS10ixVZ92Gv > NDxQCKcyTj+6leqy3ePRAgXP5DouTGXntupzPQzcbQW6L8X6h6STOiLAAGKXpGJm > t4Fruvbb3kAcqDGCp5Y9kLrxd1unlCp9leoeJeG5NZ5IcI2B4qUwqKdydu9ZMJxS > kJYJR1ZNVMtQh/kMNA87GMNv4nd8d5QPD+bm5b4L5BDlibzMGb5Q80mJAKD5xqo= > =qHjE > -----END > PGP SIGNATURE----- > ' >>>> > > Decryption of the encrypted file works. I didn't verify the > signature, but it looks like it's working. > > > Also I understand that keeping key safe is one of the important > > tasks but for the time-being I am simply adding the public and > > secret keyrings in "VAR_DIR/gpg/", all the list's private keys are > > in `secring.gpg` and all the list's public keys are in > > `pubring.gpg` and all the user's public keys are in > > `userring.gpg`. It will be changed to keep the secret keys at a > > more safer location. > > I agree with Richard that there's no particular reason to do anything > but put the public keys on one ring. > > I don't see any point in putting the private keys somewhere else. As I > wrote elsewhere, the weak point in the private keys is the need to > supply a password, not the location of the file containing the key. I > wonder if there may not be a way to do this using agent forwarding so > that the private keys are kept on a different host. > > The only issue I can see is that *if* at some point it becomes > feasible to use agent forwarding, I suspect only one agent can be used > per GPG subprocess. > > > Footnotes: > [1] Has anybody else noticed that both gpg's UI and its documentation > seem designed to make it as hard to use as possible? >

3 2

Some Doubts for GSoC Project
by Abhilash Raj Aug. 22, 2013

Aug. 22, 2013

Hi, I had a few doubts regarding the project, I din't see any reply on mm-dev so I mailed separately. Firstly what address should be used to create the keys for the lists? I was of the opinion that list' posting address should be used like 'mailman-developers(a)python.org' for mm-dev list. Steve had opinion that keys should be associated with people rather than bots so the address should be '$LIST-owner@fooo' type. Any thoughts?? Also Barry while running tests I see a few tests are failing because now simple message will not be able to pass the 'default-posting-chain' and 'multipart/signed' is requred. So should I change all the tests? ---- Abhilash Raj

6 7

Fwd: Re: GSoC Updates
by Abhilash Raj Aug. 22, 2013

Aug. 22, 2013

-------- Original Message -------- Subject: Re: [Mailman-Developers] GSoC Updates Date: Fri, 16 Aug 2013 11:48:56 +0530 From: Abhilash Raj <raj.abhilash1(a)gmail.com> To: Stephen J. Turnbull <stephen(a)xemacs.org> On Friday 16 August 2013 10:35 AM, Stephen J. Turnbull wrote: > Abhilash Raj writes: > > > 1) How do list owner create keys? What parameters? Which address? > > python-gnupg provides a key-generation API, GPG.gen_key(). > Alternatively, this could be done manually by the trusted > site-manager. The web UI would have to run over SSL, presumably > HTTPS. But can we achieve required randomization to create keys on virtualized systems? This was the reason it was suggested before that keys are uploaded by the site owners when they create new lists. > I think the address should be $LIST-owner@fqdn. For other parameters, > defaults are OK I think (size=2048, type=RSA IIRC). > > > About the address I think owner can create a key using posting > > address with a min key length of 1024? or else mailman rejects the > > key? MD5 hash should be discouraged and at least SHA1 should be > > used? (although I found this[1] that even sha1 should not be used) > > Nobody short of a major government can afford to break private keys or > crypto hashes on a regular basis. Otherwise, before they try to break > SHA1, they'll kidnap and torture you (I'm serious about the > calculation they'll make, not that I think it will happen to anybody > we know for several thousand years). Okay then we can just suggest not to use md5. > > 3) How to manage paraphrase(or passwords) for keys? > > > > In previous discussions we decided to use gnupg-agent and I > > although I haven't tried it. Any other suggestions to it? > > I really don't know. As you probably know, files containing host keys > for SSH and other SSL applications don't have passwords, but are > simply made readable only by root. That might be the appropriate > solution here. Otherwise, any reboot takes all lists down until the > owner can be tracked down. > > > Also one more thing while running tests i noticed many other tests are > > breaking as initially a simple message could pass though > > "default-posting-chain" but now we need a multipart/signed message. So > > should I worry about changing all other tests? > > Yes. Conventionally that is the responsibility of the person who adds > a feature. However, there's nothing that says you can't ask Barry for > help. He may know a way to do it quickly. Barry anything here?

2 4

GSoC Updates
by Abhilash Raj Aug. 21, 2013

Aug. 21, 2013

Hi all, After midterm evaluations I have been working on signing the message using one the keys associated with the list, now since `python-gnupg` does not allow selecting keys with key credentials( like address or list-name name) so we need key_id. As barry suggested we can create a mapping of address to key_ids and store in a seperate table. I was of the opinion that we need key_ids only for signing the content and hence need to select only list's keys and not user, so can we add a new column `key_id` to the existing list table? So that the key_id is easily accessible as a list parameter and can be easily updated. One point in this would be should we allow more than one key associated with a user( or address? ). Any comments on this? (barry?) Also I understand that keeping key safe is one of the important tasks but for the time-being I am simply adding the public and secret keyrings in "VAR_DIR/gpg/", all the list's private keys are in `secring.gpg` and all the list's public keys are in `pubring.gpg` and all the user's public keys are in `userring.gpg`. It will be changed to keep the secret keys at a more safer location. --- Abhilash Raj

6 7