Mailman 3 November 2005 - Mailman-Developers

Handlers/SpamDetect.py 'Accept' action does not interact well with other access-control handlers
by Max Bowsher Nov. 25, 2005

Nov. 25, 2005

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If I set up an Accept rule in header_filter_rules, it does not truly accept the message. Instead, it only causes the individual handler, SpamDetect.py, to accept the message. Any further handler in the pipeline may cause a hold/reject/discard in spute of the accept header_filter_rule. In particular, messages accepted by header_filter_rules will still be subjected to *_these_nonmembers and generic_nonmember_action. This makes it impossible to use header_filter_rules to accept only real automated commit/bugtracker notification emails, whilst not accepting spam that forges the automated notifier address. Max. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Cygwin) iD8DBQFDhuYafFNSmcDyxYARAiy8AJ999p8RE8jNBmMEE2jg+FpJ4le+YACghJhA 6DZrKR/jRl1XzuqC59s4/SM= =FLNz -----END PGP SIGNATURE-----

1 0

Re: [Mailman-Developers] [Mailman-i18n] Ubuntu/Launchpad Rosetta for i18n translations?
by Barry Warsaw Nov. 22, 2005

Nov. 22, 2005

On Mon, 2005-11-21 at 22:34 +0100, "Martin v. Löwis" wrote: > The thing that worries me (as a TP coordinator) about Rosetta and open > translation processes is the legal copyright issues. In principle, each > translator has the copyright to the translation, so the translator would > need to do license the translations somehow. I'm actually unsure what > the procedures at Rosetta are, so this might be FUD - but it should be > clarified before making such a change. Excellent point Martin, thanks. I'll ask the Rosetta folks if/how they handle these questions. > I don't know how much mailman has to implement FSF policies (it still > is part of the GNU project, right?): the FSF would require assignments > from each contributor, or, in the specific case of translators, a > signed copyright disclaimer. I think at the least, a disclaimer is necessary, and I'm not sure how this would be handled if translations were coordinated through Rosetta. I'll follow up here with whatever I learn. Thanks, -Barry

1 0

Ubuntu/Launchpad Rosetta for i18n translations?
by Barry Warsaw Nov. 21, 2005

Nov. 21, 2005

Hello translators, In what will hopefully be just the first of several improvements to the Mailman development process, I would like to get some feedback from the i18n developers on moving translation coordination to Rosetta. Rosetta is part of Ubuntu's Launchpad and while I haven't played around with it too much (problems with my ancient gpg keys I suspect ;) it looks a lot like what a few of us dreamed of writing several years ago (but of course, never did). Rosetta is essentially a web based interface for translating open source applications. The site has the potential to be a much better collaboration platform for translations than the mailing list or my inbox. It also looks like it would open us to collaborating with a much larger i18n community. The ultimate goal of course is to continually improve the quality and breadth of Mailman's translation. The current set of champions have done a great job getting Mailman i18n to where it is now, but I think that something like Rosetta can make all our lives easier. Specifically, I think Rosetta could help eliminate me as a bottleneck, or require translators to deal with all the nastiness of committing updates to the CVS trees themselves. I would like to get feedback from the current i18n champions on this plan. If you have experience with Rosetta, both positive and negative, as a translator or developer, I would be very interested in hearing your opinion. For more information see: http://launchpad.com/rosetta Cheers, -Barry

2 1

respond_to_post_requests
by Hatuka*nezumi Nov. 20, 2005

Nov. 20, 2005

Hi list. I found that list default for respond_to_post_requests is hardcoded as 1. I guess it may not be suitable for some kind of unadvertised lists. A short patch is attached. --- nezmi

1 0

Re: [Mailman-Developers] PHP Wrappers?
by Joshua Ginsberg Nov. 17, 2005

Nov. 17, 2005

Well, it's pretty much about as vanilla of an XMLRPC interface as we could generate... I'm not a PHP programmer, so I don't know exactly how the XMLRPC bindings work on PHP, but the Readers' Digest version of XMLRPC goes like this... XMLRPC is a request-response based remote procedure call mechanism over HTTP. The client initiates a request to the XMLRPC "listener" and posts an XML document that represents a request. For example, let's say I wrap the function multiply(x, y) which multiplies two numbers together. First, I need to give the function an XMLRPC methodname, so we'll call it "foo.multiply". A request might look like: <?xml version="1.0"?> <methodCall> <methodName>foo.multiply</methodName> <params> <param><i4><value>2</value></i4></param> <param><i4><value>5</value></i4></param> </params. </methodCall> which the "listener" would parse and dispatch to multiply(x, y) and get back 10. Which it would then send as a response to the client. <?xml version="1.0"?> <methodResponse> <params> <param><i4><value>10</value></i4></param> </params> </methodResponse> and so your XMLRPC client would return 10. There are a handful of standard "system" methods, so for example you can execute system.listMethods() to see what methods are implemented; or system.methodHelp(methodName) to see documentation on a method. Also, if errors occur, they are raised as "faults" with a fault code and a fault string. Fortunately most programming languages wrap the details of all of this up for you to make it easy. In Python, you instantiate an object that represents a connection to an XMLRPC listener. Then all methods implemented by that listener become attributes of that object. So in Python: >>> import xmlrpclib >>> sp = xmlrpclib.ServerProxy('http://lists.mysite.com/mailman/RPC2') >>> sp.system.listMethods() ['Mailman.addMember', 'Mailman.changeMemberAddress', 'Mailman.createList', 'Mailman.deleteList', 'Mailman.deleteMember', 'Mailman.getDigestMembers', 'Mailman.getMembers', 'Mailman.getOptions', 'Mailman.getRegularMembers', 'Mailman.listAdvertisedLists', 'Mailman.listAllLists', 'Mailman.resetListPassword', 'Mailman.setOptions', 'system.listMethods', 'system.methodHelp', 'system.methodSignature'] So these are the methods exported by the Mailman RPC listener. So how do they work? >>> print sp.system.methodHelp('Mailman.addMember') "add_member(listname, admin_pw, address, fullname, password, digest, now): Subscribes the email address provided to the mailing list. listname -- the name of the list to configure admin_pw -- the list or site administrator password address -- the email address to add fullname -- the user's full name password -- the password the user would like to have, leave blank to generate a random password digest -- True or False implying if they wish to receive batched digest delivery now -- True or False implying whether to bypass normal mailing list rules about confirmation/approval Returns True if everything succeeded; raises Fault -32501 if the user needs to confirm their subscription; raises Fault -32502 if the list administrator needs to approve their subscription" So I could execute Mailman.addMember('whatifnet-announce', 'f00bar', 'jag(a)fsf.org', 'jagpass', False, True) to add myself to the list whatifnet-announce with regular delivery and without having to confirm my email address. The method would return True if everything succeeded. In Python, I'd do: >>> sp.Mailman.addMember('whatifnet-announce', 'f00bar', 'jag(a)fsf.org', 'jagpass', False, True) There are some pretty good references for how PHP's XMLRPC client works, so I'd refer to those to figure out how to write a PHP client for this interface. Does that answer your questions somewhat? -jag On Thu, 2005-11-17 at 09:55 -0500, Adrian Wells wrote: > Jag, > > Thank you for the reply. I had briefly looked over this XMLRPC patch > before posting to the mailing list, but I do not understand how it > would provide the desired functionality. However, having received > your message, I want to learn more and understand how this might > work. Do you have some examples, documentation, or other resources > that I might be able to review to learn more? > > In the meantime, I'll look at the patch more closely to try to > understand how it works and how to interface with it. > > Thank you, > -Adrian > > Joshua Ginsberg <jag(a)fsf.org> on Wednesday, November 16, 2005 at 3:01 > PM +0000 wrote: > This would be something that could take advantage of the XMLRPC patch > under review: > http://www.lnk4.com/?437B8F9B45D7 > See also: > http://www.lnk4.com/?437B900345F7 > http://www.lnk4.com/?437B901745F9 > -jag > On Wed, 2005-11-16 at 13:12 -0400, Adrian Wells wrote: > > Hello. How might one configure Mailman (version 2.1.6) list > settings > > using PHP scripts? The goal is to configure Mailman list settings > such as > > domain name of list, non-digest footer, set welcome/goodbye > messages, etc. > > An approach that comes to mind is to use bin/config_list. This > would > > require writing/reading files and using bin/config_list to process > them. > > Is there another recommended or preferred way to accomplish this? > > > > There was a post about "PHP Wrappers" which suggested, "...just use > a > > setuid mailman wrapper script that does caller-checking to see if > it's > > called correctly, by the right user, and with 'safe' values" > > > <http://mail.python.org/pipermail/mailman-developers/2001-March/008421.html>. > > This was recommended over simply adding the www user to the mailman > group. > > > > I do not completely understand how one creates a setuid mailman > wrapper > > script. Is this a matter of creating something similar to > mail-wrapper.c? > > > > If someone has written a wrapper script or has some good resources > further > > explaining this to share and is willing to do so, I would appreciate > it. > > Thank you, > > -Adrian > > > > _______________________________________________ > > Mailman-Developers mailing list > > Mailman-Developers(a)python.org > > http://mail.python.org/mailman/listinfo/mailman-developers > > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > > Searchable Archives: http://www.mail-archive.com/mailman-users% > 40python.org/ > > Unsubscribe: > http://mail.python.org/mailman/options/mailman-developers/jag% > 40fsf.org > > > > Security Policy: > http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp > > > -- > Joshua Ginsberg <jag(a)fsf.org> > Free Software Foundation - Senior Systems Administrator -- Joshua Ginsberg <jag(a)fsf.org> Free Software Foundation - Senior Systems Administrator

2 1

MM3?
by Mike Burton Nov. 17, 2005

Nov. 17, 2005

Hi folks, I have been watching with anticipation, but it's been a while since I have heard anything on MM3. Any noteworthy updates? Take care, Mike

3 3

Re: [Mailman-Developers] Mailman-Developers Digest, Vol 199, Issue 11
by Levente Torok Nov. 14, 2005

Nov. 14, 2005

Hi All, I have put the Listserv-to-Mailman migration toolkit in on the web. It can be downloaded from: http://www.sztaki.hu/~lev/miscellaneous.html or http://www.sztaki.hu/~lev/ls_mm/ls_mm_migration_toolkit-0.1.tar.gz Best regards, Levente Torok __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com

1 0

Listserv Migration Toolkit
by Levente Torok Nov. 11, 2005

Nov. 11, 2005

Dead Developers, Currently we have come through a project that was aiming to convert 100 of lists with about 12000 users from Listserv to Mailman. And we succeeded. It was and extreme burden in the near past. The reason of my posting is that. Up to know, I have no information if anyone has done this before automatically. We have made a package that helps to achieve this. I hope it serves many users purpose in the future. Since it is not a big file, I post it the list (published under GPL3) We will set up a site for this purpose in the near future but we also want to receive some feedback from you guys. Best regards, Levente Torok __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com

1 0

Re: [Mailman-Developers] Another take at MysqlMemberAdaptor + a migration utility
by Kyrian (list) Nov. 7, 2005

Nov. 7, 2005

Folks, Well, after a gargantuan cull of my inbox, it's down from 9,000+ to more like 9, and as mentioned, I would work on MysqlMemberships.py at that point. I have, I believe incorporated everyone's non-destructive patches and comments so far into the distribution (I have erred on the side of caution with incorporating stuff in, so please don't take offence if I have not included your contributions), crediting where appropriate, and pending some testing (as I now have a development environment built in which to do so) before I send a sourceforge announcement, etc. If anyone else feels like testing it, I have fairly silently uploaded the latest version (1.69) of it to the oRe Net Opensource pages, although that has only been tested to the point of a python syntax check pass. Considerable thanks go to Adrian Wells for his repeated contributions, Fil for his large-scale suggestions, and everyone else, I didn't think for an instant that my very first piece of Python coding would generate such interest. In any case, before I go any further with regards to development, since Mailman appears to be undergoing internal changes that may cause future issues, and I already have a large TODO list, I'd like the input of the development team and others on both the progress of Mailman and future plans, and its relation to my (slightly amended) TODO list for the MySQL Member Adaptor stands as follows... Firstly, those items in it which I need help with, or to discuss with folks: * Figure out how to make passwords work. Currently using "!" as the default password, so that things don't barf, but that is probably not the right way to go about it. What is the Mailman equivalent of "No password", etc? * Ensure that what the patch is doing ties up with Barry's input wrt. what it should be doing. * Check up on whether Adrian Wells is correct with regards to the user flags ('hide', 'noemail', 'ack', 'not_metoo', and 'plain'), and hence columns in the adaptor's database tables are fully deprecated from Mailman, in favour of the user_options flag/column if so, make changes to the adaptor accordingly. * Adrian Wells Bouncer.py patch. Discuss with Mailman team. Is it the right way to go. Moving this patch deeper into the guts of mailman seems to be a little anathema to the whole idea of Member Adaptors in the first place, not to mention that it scares me a little ;-) * Await responses to fil (at) rezo.net's ideas. I would not mind at all incorporating a migration ultility into the MysqlMemberships.py tarball I'm sending out, and I certainly see the merit of the other suggestions, but some of it strikes me as a little premature, or perhaps overkill given various factors. And of course the obvious ones, which I shouldn't have much of a problem with. * PRIORITY: Database escaping, need to work out how to to this with the Python MYSQLdb module, after all it would only take a well-crafted email to raise merry hell as things are at the moment. * MYSQL_MEMBER_DB_WHERE so you can specify a "WHERE x = y" on all the queries in the database. ??? * MYSQL_MEMBER_DB_SOCKET, to support a local socket connection to the MySQL server. This should be easy using the "unix_socket" attribute of MySQLdb's connect call. I guess if anyone would care to add anything to the above or make suggestions that would be cool, but please try and keep them short, I don't want 9,000 emails in my inbox again any time in the next six months or so, please. K.

3 2

Sibling list
by Tokio Kikuchi Nov. 6, 2005

Nov. 6, 2005

Hi Developers, I've just uploaded a new patch to enable 'sibling list' feature in mailman non-digest delivery. I'd like to get feedback from develpers on this feature, particularly on the naming ... sibling. ;-) https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1347962&group_… Here are excerpts from the patch tracker. - Sibling lists are other mailing lists on this site whose members are excluded from regular delivery if those list addresses appear in To: or Cc: header. - The list addresses should be witten in full mail address format (e.g. mailman(a)example.com). Do not specify the list address mutually in the sibling list configuration page or those doubled members won't get message. TBD: - Is the terminology 'sibling' appropriate? - Need more comments in the processing code (CalcRecips.py). -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/

3 3