Mailman 3 October 2006 - Mailman-Developers

Question about fix for CVE-2006-3636
by Juan Ignacio Germano 23 Oct '06

23 Oct '06

Hi everyone. Can anyone tell how is it that the XSS indicated by this advisory was fixed? I might be something wrong here, but can't see what is it. I was using a fairly old version (2.1.5), and upgraded to 2.1.9. To my surprise, the XSS using the URL with listinfo.html is still working, changing the content (HTML) of the list's info using the PoC URL of the said advisory. Reading the code for edithtml.py I can still see problems here: passing the values using GET still works, and the regular expression looking for <[/]?script.*> still is case sensitive. The diff between revision 7723 and 8001 for edithtml.py (Release_2_1-maint branch) gives me: Index: edithtml.py =================================================================== --- edithtml.py (revision 7723) +++ edithtml.py (working copy) @@ -143,7 +143,8 @@ doc.AddItem('<p>') doc.AddItem('<hr>') form = Form(mlist.GetScriptURL('edithtml') + '/' + template_name) - text = Utils.websafe(Utils.maketext(template_name, raw=1, mlist=mlist)) + text = Utils.maketext(template_name, raw=1, mlist=mlist) + # MAS: Don't websafe twice. TextArea does it. form.AddItem(TextArea('html_code', text, rows=40, cols=75)) form.AddItem('<p>' + _('When you are done making changes...')) form.AddItem(SubmitButton('submit', _('Submit Changes'))) I am sure I'm doing something wrong, but can't see what is it. Where's the fix? Cheers, -- Juan

1 0

Problem with new configuration.Configuration.load()
by Mark Sapiro 22 Oct '06

22 Oct '06

If the new configuration.Configuration.load() method is given a configuration file argument which is a non-existent file, it will silently fall back to loading mm_cfg.py. I think it should remember whether a filename argument is passed and complain if the passed file doesn't exist. -- Mark Sapiro <msapiro(a)value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 3

Converting mm_cfg to config in mmshell scripts
by Mark Sapiro 22 Oct '06

22 Oct '06

Several of the mmshell scripts in Mailman/bin in the SVN trunk have not been converted from mm_cfg to the new config scheme, given a -C/--config option, etc. I have done, but not checked in a few. If nobody claims this job, I'll do the rest and check them in. -- Mark Sapiro <msapiro(a)value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 2

The one-giant-object approach
by emf 19 Oct '06

19 Oct '06

Gentlebeings, I'm trying to hook up the object-relational mapper I've worked out to mailman, and I'm encountering an issue I'd appreciate feedback on. Take MailList. Aside from its own namespace, it mixes in 11 other classes, leading to 255 names if you dir(list). Is this large, flat namespace a preference? It seems to me like it mixes together many bits of functionality that aren't always needed by whatever code needs a 'list'. It seems to me that if things were broken up a little bit they'd be conceptually easier to follow, and it'd be easier to make improvements. While I understand that a unified DB likely won't make it into 2.2, I would like to break out some functionality, and I just wanted to make sure that keeping a flat namespace wasn't a design goal. Thanks, ~ethan fremen

2 1

list confirm and request addresses acting as open relay
by Giuliano Gavazzi 19 Oct '06

19 Oct '06

Hello, sorry if this is a dumb observation, but recent spam to the posting address of on of our lists (fortunately a moderated distribution-only list) has prompted some test on my part. I have then noticed that the confirm address (listname-confirm +...@...) and the request address (listname-request@...) act as mirrors to the alleged envelope sender, sending back the whole email after the parsed commands. Until now no spammers have used this, but sooner or later they will. For the "confirm" case I suppose a solution would be to only reply to confirm strings that are in the database and only if the envelope sender IS the one associated to the particular confirm string. For the "request" case instead the situation is more complex. The reply should only be generated if the sender is a subscriber to the list, unless, of course, the subject is "subscribe". If it is a subscribe though the body of the message does not contain the original body and the damage is limited. In this "subscribe" case perhaps a throttling or maximum number or outstanding subscription requests would be a good idea. Of course this might be in the latest release but I did not find mention in the list. Thank you Giuliano

4 4

Request for template substitution token
by Lindsay Haisley 17 Oct '06

17 Oct '06

I'm working on some utilities to integrate the Namazu search engine with Mailman, along the lines of Tom Morrison's very nice instruction posted at http://mail.python.org/pipermail/mailman-users/2004-June/037580.html. The integration on the Namazu side is pretty straightforward and I've already written a piece that customizes Namazu templates on a per-list basis with information from Mailman's MailList module. See nmzproc at <http://www.fmp.com/namazu>. There's only one thing holding up the train on the Mailman end, and that's the fact that the only substitution token available in archtoc.html and archtocnombox.html is %(listname)s, which is replaced with the lists real_name, including any capitalization which the list admin may chose to use in the "pretty" name for the list. The Mailman templates need to be modified to generate a small search form, as per Tom Morrison's instructions, and the action attribute of the form needs to be a full path to a directory containing Namazu components, e.g. action="/mailman/%(listname)s/namazu.cgi". If Namazu is set up for a list, and the list admin decides he wants to change the real_name for the list to display all in caps, the link to Namazu will break. One line of code would do this: --- HyperArch.py.orig 2006-10-16 20:25:22.000000000 -0500 +++ HyperArch.py 2006-10-16 20:28:35.000000000 -0500 @@ -752,6 +752,7 @@ listname = mlist.internal_name() mbox = os.path.join(mlist.archive_dir()+'.mbox', listname+'.mbox') d = {"listname": mlist.real_name, + "internal": mlist.internal_name(), "listinfo": mlist.GetScriptURL('listinfo', absolute=1), "fullarch": '../%s.mbox/%s.mbox' % (listname, listname), "size": sizeof(mbox, mlist.preferred_language), This would give us a %(internal)s name for the list in the TOC index.html file which would be lower case and independent of administrative changes to the displayed list name. I can do this easily for myself (I've actually hacked PHP support into the TOC HTML files produced from these templates) but I'd like to put together and release a set of tools to integrate Namazu with Mailman. Telling people to use alternate Mailman templates, or giving them a patch for existing templates, is one thing. Telling them to patch the Mailman Archiver code is rather more radical, and if this small change could get the blessing of the Mailman developers going forward it would make my work on the Namazu integration stuff a lot easier. -- Lindsay Haisley | "Fighting against human | PGP public key FMP Computer Services | creativity is like | available at 512-259-1190 | trying to eradicate | <http://pubkeys.fmp.com> http://www.fmp.com | dandelions" | | (Pamela Jones) |

2 1

Patches from Debian Mailman
by Thijs Kinkhorst 17 Oct '06

17 Oct '06

Hello, I'm one of the maintainers of the Debian package "mailman", of course containing your great piece of software. The team has recently gotten more active, and while mainly concentrating on the Debian-specific parts, there's also a number of fixes we've made (or have been made in the past) to the Mailman sources. I'm trying to get the parts of our changes that are useful outside of Debian, and have submitted a couple of them now to the Patches tracker. There's also some feature patches we received in our BTS but haven't applied to the package. Here's a summary. In our package now: * Trivial change to fblast to add a shebang line http://sourceforge.net/tracker/index.php?func=detail&aid=1578740&group_id=1… * Make Mailman not crash on strange HTTP request types like "PROPFIND": http://sourceforge.net/tracker/index.php?func=detail&aid=1578756&group_id=1… * Russian newlist template has outdated variable (doesn't require comprehending the Russian language): http://sourceforge.net/tracker/index.php?func=detail&aid=1578766&group_id=1… * When searching for members, the selected letter is forgotten: http://sourceforge.net/tracker/index.php?func=detail&aid=1532081&group_id=1… Not yet in our package, but may be in the future: * Make it possible to only build the arch-dep and arch-indep parts in the Makefile. This helps us to make an architecture-specific package for only those files which are, and put everything else in a single architecture independent package. http://sourceforge.net/tracker/index.php?func=detail&aid=1564527&group_id=1… I believe the patches are useful to the whole Free Software community, so I hope they can be applied. Thanks. Thijs

1 0

LMTPRunner.py
by Barry Warsaw 16 Oct '06

16 Oct '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Tokio, I took a look at LMTPRunner.py today, and it looked pretty good. I don't think it was quite RFC 2033 compliant though. One thing it needed to do was return a status code for every RCPT TO recipient. Take a look at r8050. I've fixed the status codes and also done a bunch of other refactoring. Note that I haven't yet tried to hook this up to a real Postfix (or other LMTP client), but it seems to do the right thing when you telnet to localhost:8025. Give it a try and let me know what you think. I plan on testing Postfix integration, perhaps tomorrow. This definitely shows a lot of promise. I will probably hold off on updating the MaildirRunner for now, to see how far we can take LMTP delivery, and whether an smtpd.py-based server can hold up. Great work! Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRSSKnXEjvBPtnXfVAQLrUwQAg3BXbEROLAxwQ2CV64bxzQe8tR2X/K7z fdkHK5lepztbKxbYI+RkMzxeYgD8+q78ha8NIQxzmLHW6frcgOmUFyHye9ZT+EiS +/63Joj8bu5GEC0v8F7MsR1J2RqJ67MnwFU/ezge8TNRceeH2y4SuOAcX276oSIq pFpIW0TQO9M= =51Ir -----END PGP SIGNATURE-----

2 6

[Mailman-Users] Index Listing of mail lists
by stephen＠xemacs.org 11 Oct '06

11 Oct '06

Reply-To set to Mailman-Users. Tom Kavanaugh writes: > If there is a way to setup a A-Z index hortizontally above the List name - > Description, it would be great. > > Any code hacks for this feature? This feature is already in the Member List page. Since Mailman is free software, reusing that code doesn't even count as stealing!<wink> Mailman Developers: Is the web code set up so that so that admins could fairly easily assemble these UI widgets into a page that suits their usage? Or would that be a major refactoring? Sorta like reimplementing Plone, I guess, but we really don't want to put "import plone" at the top! What I was thinking is that there could be a page generator pipeline, similar to the list processor. Of course the objects we want to generate pages from (member lists, moderation queues, etc) would have to grow appropriate interfaces -- sounds like work! but it would be way cool.

4 6

Debugging mailman (resolving inline signature attachments)
by Sven Ingebrigt Ulland 04 Oct '06

04 Oct '06

Hello there. How would I go about debugging mailman, by -- for example -- polluting the .py libraries with print or assert statements? If I do that (which seems like a pretty thoughtless idea), the output would end up .. in /dev/null? It would probably be better to write to file in stead? Right now I'm having a specific problem, but it would be nice to have some general debugging methods to use in the future for other problems. I'm using version 2.1.5-8sarge2 (yes, Debian sarge). The current problem is that list msg_footer, that is list signatures, are inline attached as base64- encoded UTF-8 mime parts, but only in some cases: Original message: iso8859-15 text/plain. Result: Mailman distributes the message to the list members as mime multipart, first part is the original iso8859-15 message, and the list footer is appended like this: --===============0410419818== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline WWVzLCB0aGlzIGlzIG5vdCB0aGUgcmVhbCBsaXN0IHNpZ25hdHVyZSwgeW91IGhheG9yIG NyYXhvcg== --===============0410419818==-- The same happens for charset 'us-ascii' and 'iso8859-1', which were some examples I could find now after a quick look. When the original message is UTF-8 text/plain, however, the body and signature are merged together as they should be. The footer contains *only* standard 7-bit ascii values.. no 8-bit stuff or strangeness. Now, mailman determines this footer business in Handlers/Decorate.py on lines 80 to 110 (roughly). It calls the following to determine list charset: lcset = Utils.GetCharSet(mlist.preferred_language) GetCharSet calls mm_cfg.LC_DESCRIPTIONS, which imports Defaults.py, where -- since my lists have lang set to 'en' -- 'us-ascii' is returned. I also tried mapping 'en' to 'utf-8', without success. This is the snippet that determines if the message should be multipart or not (linenums included): 86 if not msg.is_multipart() and msgtype == 'text/plain' and \ 87 msg.get('content-transfer-encoding', '').lower() <> 'base64' and \ 88 (lcset == 'us-ascii' or mcset == lcset): The incoming messages from users are: - not multipart - charset is text/plain - content-transfer-encoding is mostly '7bit' (not base64) - lcset *should* be 'us-ascii', but it appears it might not be - mcset (message charset) is what the user used, normally iso8859-1, iso8859-15 or utf-8. I'd really like to debug that code passage to verify what variables are screwed up, and which are not. Any tips? best regards, sven

4 3