Mailman 3 March 2005 - Mailman-Developers

list-owner address spam
by Bob Puff＠NLE March 17, 2005

March 17, 2005

Hi Gang, I've got a list where the <listname>-owner address is getting directly spammed. Any ideas on how to combat this? I don't suppose I can just change it to owner-<listname> and still have mailman pass along admin requests, huh? Bob

2 1

Mailman 3 Sprint at Pycon2005
by Barry Warsaw March 17, 2005

March 17, 2005

Just a reminder that we're going to do a Mailman 3 sprint again this year at Pycon2005, which starts Saturday. I plan on being there all four sprint days (Sat-Tues) and I hope you will be able to join us. For the meager information on the MM3 sprint see: http://www.python.org/moin/Mailman3Sprint Please sign up on this page if you plan on coming. Remember that the sprint days at Pycon are free; for more information on the conference in general see: http://www.pycon.org I plan on logging into the #mailman channel on irc.freenode.net so if you can't make it and have questions, we'll try to discuss things there, although we might be too busy to pay much attention to irc. I should have more information about the Subversion repository for MM3 later today. -Barry

1 0

Re: [Mailman-Developers] Two patches for site-wide configuration
by J C Lawrence March 16, 2005

March 16, 2005

On Wed, 16 Mar 2005 13:36:41 +0000 Matthew Newton <mcn4(a)leicester.ac.uk> wrote: I've not reviewd the patches and so am reacting to their descriptions only. > Lets the site administrator stop list owners from changing certain > configuration options. Example is to stop the list owner making > someone else the owner. +1 (this is also useful to me) > Gives a hook into the add member routines that allow the subscribers > address to be changed before it is added to the list. This could be > dangerous if used incorrectly, but is needed for sites that have two > "identical" domain names, such as "leicester.ac.uk" and "le.ac.uk". +1 as a hidden hook. -0 as an exposed feature. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

1 0

Two patches for site-wide configuration
by Matthew Newton March 16, 2005

March 16, 2005

Hi! I've written two small patches for Mailman that add the following functionality: site_hide_list_options.patch, sourceforge number 1164457 Lets the site administrator stop list owners from changing certain configuration options. Example is to stop the list owner making someone else the owner. transform_address_hook.patch, sourceforge number 1164464 Gives a hook into the add member routines that allow the subscribers address to be changed before it is added to the list. This could be dangerous if used incorrectly, but is needed for sites that have two "identical" domain names, such as "leicester.ac.uk" and "le.ac.uk". Any comments on these patches would be most appreciated! Is there a better way of doing these things, or are there any improvements that could be made to the patches? Patches apply to 2.1.5. Thanks! Matthew -- Matthew Newton <mcn4(a)le.ac.uk> UNIX and e-mail Systems Administrator, Network Support Section, Computer Centre, University of Leicester, Leicester LE1 7RH, United Kingdom

1 0

bug in ListAdmin._UpdateRecords in 2.1.5 - 2.1.6b4?
by Zoran Dzelajlija March 15, 2005

March 15, 2005

Hello. I have been trying to migrate from 2.0.13 to 2.1.5 a few lists at a time, and run 2.0 and 2.1 in parallel. We have a lot of pending requests around, and we would not like to lose them. Luckily, it looks like almost everything is handled in bin/update, although some things require special attention, like pending_subscriptions.db (haven't tried yet, but it looks like it should be enough to copy it over to the Mailman 2.1 installation each time a list is migrated, and run bin/update or the relevant portion thereof). Most other stuff is done on a per-list basis, like held messages. class ListAdmin has an sort-of-private function _UpdateRecords, used in bin/update to upgrade from 2.0-style request.db which holds the held messages metadata. It writes the entries to the new database like this: if op == SUBSCRIPTION: [munge...] # Here's the new layout self.__db[id] = when, addr, fullname, passwd, digest, lang However, other code uses it like: type, data = self.__db[id] Seems like the correct way should be something like self.__db[id] = TYPE, (when, addr, fullname, passwd, digest, lang) I'v made a script to mv files and directories from 2.0 to 2.1 installation, fix the aliases, and do stuff withlist, _UpdateRecords() among other. After this, some of the migrated lists would have munged requests without a request type. AFAICT this would happen on a regular 2.0.x -> 2.1.5 upgrade with bin/update too. So here's a patch for 2.1.5 which includes crude heuristics to guess the forgotten request type, it can be used in withlist to fix the damage, or in bin/update. I'm not sure if this is adequate to put in the main tree. It applies to 2.1.6b4 too, but I've not tested yet if it works. Should I file a bug report at sourceforge? Regards, Zoran Index: ListAdmin.py =================================================================== RCS file: /var/lib/cvs/mailman-conf/ListAdmin.py,v retrieving revision 1.1 retrieving revision 1.3 diff -u -r1.1 -r1.3 --- ListAdmin.py 7 Sep 2004 02:48:50 -0000 1.1 +++ ListAdmin.py 7 Sep 2004 03:33:17 -0000 1.3 @@ -530,7 +530,19 @@ except IOError, e: if e.errno <> errno.ENOENT: raise self.__db = {} - for id, (op, info) in self.__db.items(): + for id, rest in self.__db.items(): + if len(rest) == 2: + op, info = rest + # repair junk from 2.1.5 + elif len(rest) == 6: + op = SUBSCRIPTION + if len(rest[5]) > 10 and rest[2] != '': + op = HELDMSG + self.__db[id] = op, rest + continue + else: + assert len(rest) == 2, 'Found broken database' + continue if op == SUBSCRIPTION: if len(info) == 4: # pre-2.1a2 compatibility @@ -545,7 +557,7 @@ assert len(info) == 6, 'Unknown subscription record layout' continue # Here's the new layout - self.__db[id] = when, addr, fullname, passwd, digest, lang + self.__db[id] = op, (when, addr, fullname, passwd, digest, lang) elif op == HELDMSG: if len(info) == 5: when, sender, subject, reason, text = info @@ -554,7 +566,7 @@ assert len(info) == 6, 'Unknown held msg record layout' continue # Here's the new layout - self.__db[id] = when, sender, subject, reason, text, msgdata + self.__db[id] = op, (when, sender, subject, reason, text, msgdata) # All done self.__closedb()

1 0

middleware requirements contribution
by John-Paul Robinson March 11, 2005

March 11, 2005

Hello Mailman Developers, Some of you may be aware of an Internet2 sponsored and NSF funded effort to improve the integration of popular open source mailing list software with emerging middleware technologies for identity management and authorization. http://middleware.internet2.edu/mlist The mlist working group of Internet2 has been gathering information related to mailing list software needs of higher education and working on integration scenarios for mailing list software related to these needs. As part of this effort, we have put together much of the knowledge we have gathered over the past year into a how-to guide for mailing list developers. http://webapp.lab.ac.uab.edu/wiki/mlist/index.php/HomePage Our initial version of this guide has been put together over the past few weeks in the hopes that it is useful to the Mailman developers in light of the upcoming Mailman developer sprint at PyCon2005. We hope that it will contribute positively to the development requirements of the next major release of Mailman. As I mentioned, this is our initial version of the document. We have put it online as a wiki in order to solicit feedback on the utility of the information and to allow people to easily contribute to this discussion. Please let us know if you find this information useful or if there are areas you feel should be improved. Our goal is to provide requirements guidance to mailing list system developers to help promote the changing needs of the higher education community. We feel that these same requirements represent the future needs of many organizations that use Mailman and that by addressing the general requirements Mailman will continue to be a popular and adaptable part of future mailing list systems. Thanks for your time and let me know if you have any questions or requests. Thanks, ~jpr

1 0

Appropriate text for private archive login
by Mark Sapiro March 11, 2005

March 11, 2005

Much of the template templates/en/private.html is based on (copied from) the template templates/en/admlogin.html. Thus, the language about cookies is not appropriate for this function. I have submitted a patch with suggested changes to the english template at https://sourceforge.net/tracker/index.php?func=detail&aid=1161505&group_id=… -- Mark Sapiro <msapiro(a)value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 0

XHTML Compliant Web UI 2.1.6b4 Patch
by Bryan Carbonnell March 10, 2005

March 10, 2005

I have just uploaded a patch that will make the web UI for MM 2.1.6b4 XHTML 1 strict compliant. Well, the start of a patch. Currently only the listinfo pages are xhtml 1 compliant and some minor CSS formating ability. As time goes by, I'm going to update the patch to include more of the UI pages. Since this is my first atempt at something like this I thought I'd post it incrementally in case anyone finds something terrible wrong with what I'm doing :) It it patch 1160353 in the Sourceforge Mailman patch repository. http://sourceforge.net/tracker/index.php?func=detail&aid=1160353&group _id=103&atid=300103 If anyone has any feedback on it, I'd love to hear it. -- Bryan Carbonnell - carbonnb(a)sympatico.ca "When they put 'unknown' at the end of a quote, that means they probably don't know how to spell 'anonymous'." ~Author Unknown

1 0

Fwd: <incom> Design for Civil Society / Technology and Social Action
by Tobias Eigen March 7, 2005

March 7, 2005

Hi all, The link below might be of interest in the context of usability discussions we've been having. Best wishes, Tobias Begin forwarded message: > From: Maja van der Velden <maja(a)xs4all.nl> > Date: March 4, 2005 10:11:01 AM EST > To: Maja van der Velden <maja(a)xs4all.nl> > Cc: Subject: <incom> Design for Civil Society / Technology and Social > Action > > FYI, some work I am participating in: > > A special issue of Interacting with Computers - Volume 17, Issue 1, > Pages 1-120 (January 2005) - on Design for Civil Society, edited by > Steve Walker and Andy Dearden, is available full text online as a > complementary issue. Yu can read the articles online, download them or > send them in pdf format. > > A follow-up on this is a project called Technology and Social Action > (see http://www.technologyandsocialaction.org ): "a project to foster > dialogue and collaboration between activists in social movements, > voluntary and community organisations and technology designers. We are > committed to supporting communities of practice exploring effective > ways of using technology to support social action, and of ensuring > that technological innovation responds to social priorities. > > Greetings, Maja > > The (very unhandy) link to the Design for Civil Society issue is: > http://www.sciencedirect.com/science? > _ob=IssueURL&_tockey=%23TOC%235644%232005%23999829998%23549345%23FLA%23 > Volume_17,_Issue_1,_Pages_1 > -120_(January_2005)%2BMDesign_for_Civil_Society%2BMEdited_by_S._Walker_ > and_A._Dearden&_auth=y&view=c&_acct=C000050221&_version=1&_urlVersion=0 > &_userid=10&md5=59c069dfff5e2e729975cf03dfead78b > > It has the following articles: > > 1. Inside Front Cover > Page CO2 > > 2. Designing for civil society • EDITORIAL > Pages 1-8 > Steve Walker and Andy Dearden > > 3. Participating in civil society: the case of networked communities > • ARTICLE > Pages 9-33 > Andrea Kavanaugh, John M. Carroll, Mary Beth Rosson, Debbie D. Reese > and Than T. Zin > > 4. Net neighbours: adapting HCI methods to cross the digital divide • > ARTICLE > Pages 35-56 > Mark Blythe and Andrew Monk > > 5. Fairtrade.com versus Fairtrade.org—how Fairtrade organisations use > the Internet • ARTICLE > Pages 57-83 > Dorothea Kleine > > 6. Online design for bilingual civil society: a Welsh perspective • > ARTICLE > Pages 85-104 > Daniel Cunliffe and Dilwyn Roberts-Young > > 7. Programming for cognitive justice: Towards an ethical framework for > democratic code • ARTICLE > Pages 105-120 > Maja van der Velden > > > Maja van der Velden > Oslo, Norway > http://www.globalagenda.org > http://blogger.xs4all.nl/ > maja_______________________________________________ > incom-l mailing list > incom-l(a)incommunicado.info > http://mail.kein.org/mailman/listinfo/incom-l > -- Tobias Eigen Executive Director Kabissa - Space for Change in Africa http://www.kabissa.org * Kabissa's vision is for a socially, economically, politically, and environmentally vibrant Africa, supported by a strong network of effective civil society organizations. *

1 0

Re: [Mailman-Developers] Postfix.py extension for virtual_domain management
by clif March 6, 2005

March 6, 2005

Hi Mike, I've also wished mailman handled Virtual lists better. PostfixVirtual.py Works great, and I also tried removeing the name change restriction in General.py: vi /usr/lib/mailman/Mailman/Gui/General.py /real_name # Lets try this just for fun... if property == 'real_name_NOT' and \ I did some quick testing and found most of the obvious references to com.foo.test became test without any problems. Though the URLs and some other text still refers to it by the "correct" name. Anyway you mentioned in your post that you had customized mailman in other ways. Do you feel like publishing them as well? Thanks, Clif

2 3