Mailman 3 May 2005 - Mailman-Developers

PGP and Mailman
by Joost van Baal 22 Jul '05

22 Jul '05

Hi, I will write and publish a patch which integrates PGP signature validation and re-encryption of encrypted posts to mailman. Specs are: - A post will be distributed only if the PGP signature on the post is from one of the list members. - For sending encrypted email, a list member encrypts to the public key of the list. The post will be decrypted and re-encrypted to the public keys of all list members. (Later, the patch will handle RFC 2633 (S/MIME) messages too, next to RFC 2440 (OpenPGP)). I've taken a look at the NAH6 secure list patch #646989 at http://sourceforge.net/tracker/index.php?func=detail&aid=646989&group_id=10… and at Ben Laurie's patch #645297 at http://sourceforge.net/tracker/index.php?func=detail&aid=645297&group_id=10… , but I believe none of these completely implements the listed requirements (although these will help me implementing, of course). I am asking you to take a look at my plan for implementation. Am I on the right track? So, the plan: I think one way to implement it would be to add two modules to GLOBAL_PIPELINE: in front, before SpamDetect, there would be 'PGPCheck'. PGPCheck would check wether the message is encrypted, and, if so, make a temporary decrypted copy in order to verify with which key is was signed. If the message is unencrypted, it would check the signature. It would store this information in new properties of the Mailman Message object. A second new module in GLOBAL_PIPELINE would be 'PGPRecrypt', to be called after CookHeaders' and before 'ToDigest'. This would, if needed, decrypt the message and reencrypt it to all recipients, and would sign it. If for instance a list member erroneously signs a post with a wrong public key, and encrypts the message, this message should be handled carefully. I believe the Hold module should be adapted for this. A copy of the original encrypted message should be kept. The message should be decrypted, signed with the listkey, encrypted to the list moderator key, and sent for acknowledgement. If the moderator chooses to deny the message, the poster should get her original message back. (I guess.) For all PGP handling, I plan to use Frank J. Tobin's GnuPGInterface ( http://py-gnupg.sourceforge.net/ ). I plan to write the patch against current stable Mailman. Any insight to share on this? Thanks! Bye, Joost -- Joost van Baal http://abramowitz.uvt.nl/ Tilburg University j.e.vanbaal(a)uvt.nl The Netherlands

4 12

Suspending subscribers on vacation?
by Bjørn Vermo 31 May '05

31 May '05

It is a problem that some people think it is cool to automatically generate "out of office" messages when they are away, especially when they are subscribed to high-volume lists. Is there an easy way to have Mailman temporarily unsubscribe them when it receives one of those messages? -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

2 1

RE: [Mailman-Developers] Min requirements for running Mailman?
by John.Airey＠rnib.org.uk 31 May '05

31 May '05

> -----Original Message----- > From: mailman-developers-bounces+john.airey=rnib.org.uk(a)python.org > [mailto:mailman-developers-bounces+john.airey=rnib.org.uk@pyth > on.org]On > Behalf Of Tollef Fog Heen > Sent: Monday, 06 September 2004 16:47 > To: mailman-developers(a)python.org > Subject: Re: [Mailman-Developers] Min requirements for > running Mailman? > > > * Nigel Metheringham > > | I'd tend to take this as:- > | * Mailman is a bitch to package > > Not really. It's fairly well-behaved in my experience. It's a > semi-large web application with some requirements, but nothing > unreasonable. > > | * RH have packaged it for a while > | * RH found a good few of the gotchas in packaging Mailman > | * RH have subsequently learnt from their mistakes and recently > | have produced good packages. > | * Other distros may do better, or may yet have to > learn from their > | mistakes :-) > > Mailman has been in Debian since June 1998 (1.0b4), so we've been > working on it for a while as well. I think our packages are of good > quality (far from perfect, but making perfect packages is _a lot_ of > work. ;) > Just to throw my tuppence worth in... I've used mailman since Red Hat 7.2. I found that the version that came with Red Hat 9.0 wouldn't work for me (ie I couldn't upgrade to it) so I stuck with the 7.2 version (2.0.13) till the end of Red Hat 9 support. We are now running the 2.1.5 version that comes with Fedora but running it on Red Hat Enterprise Linux (RHEL). I did however have to recreate all the lists by hand in an overnight shift (what fun that was...) a few days before leaving the country (hence the rush). At that time I didn't know I could export the configuration (Doh!). Red Hat have taken some packages out of RHEL eg arpwatch and mysql-server (although this is in the "extras" channel) even though these are in the source RPM. Mailman is currently not included but might be being put back in to RHEL 4.0. I would like to hope so, as I find 2.1.5 far superior to 2.0.13. -- John Airey, BSc (Jt Hons), CNA, RHCE Internet systems support officer, ITCSD, Royal National Institute of the Blind, Bakewell Road, Peterborough PE2 6XU, Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 John.Airey(a)rnib.org.uk To truly believe in Evolution requires complete faith that life has no meaning. Fortunately there are billions of people who aren't that stupid. -- DISCLAIMER: NOTICE: The information contained in this email and any attachments is confidential and may be privileged. If you are not the intended recipient you should not use, disclose, distribute or copy any of the content of it or of any attachment; you are requested to notify the sender immediately of your receipt of the email and then to delete it and any attachments from your system. RNIB endeavours to ensure that emails and any attachments generated by its staff are free from viruses or other contaminants. However, it cannot accept any responsibility for any such which are transmitted. We therefore recommend you scan all attachments. Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB. RNIB Registered Charity Number: 226227 Website: http://www.rnib.org.uk

6 11

RELEASED Mailman 2.1.6
by Barry Warsaw 31 May '05

31 May '05

On behalf of the development team, I'm pleased to announce the release of GNU Mailman 2.1.6. This is a significant release, which includes three important security patches, updated Chinese (zh_TW and zh_CN) support, better compatibility with Python 2.4, a few new features, and many bug fixes. Mailman is free software for managing email mailing lists and e-newsletters. This release fixes CAN-2005-0202, a reported vulnerability in path traversal in the private archive script. This release also provides an option for sites to produce more cryptographically secure auto-generated passwords, and it closes a potential cross-site scripting hole. Because of the security (and other) fixes, it is highly recommended that all sites upgrade to 2.1.6. For more information, please see: http://www.list.org http://mailman.sf.net http://www.gnu.org/software/mailman On a personal note, I owe a debt of gratitude to Tokio Kikuchi, who served as release manager for 2.1.6, integrated countless patches, and coordinated the Chinese language updates for this release. Please join me in thanking him for helping out so much. For links to download the Mailman 2.1.6 source tarball, see: http://sourceforge.net/project/showfiles.php?group_id=103 Enjoy, -Barry

1 0

mbox archive
by Jean-Philippe GIOLA 25 May '05

25 May '05

Hi all! I want to know when the mbox archive is created for a list (in archives/private/listname.mbox/listname.mbox) /I have still ask this question in the mailman-users list but noboby has answer me... /reguards./ / -- Jean-Philippe Giola - 6577

3 2

Plugin architecture? If not, suggestions on extending functionality?
by Carl Fink 20 May '05

20 May '05

Hi. I'm running mailing lists for a nonprofit organization. We'd like to create a customized newsletter. The idea is that subscribers would visit a configuration page, and check off the topics that they're interested in. Then, monthly or so, a customized newsletter would be generated for each subscriber and mailed out. Since I'm already administering a Mailman server, it struck me that extending Mailman was the way to go. I'm only slightly familiar with Python, but it would be my seventh or eighth language, so that doesn't intimidate me. What I'd like to do is write a plugin. However, I have been unable to find a description of a Mailman plugin API in dozens of web searches using multiple engines. I find *references* to such an API going back four years, but no actual documentation of one. So: does the current Mailman support plugins? If not, what do you, the Mailman developers, think of extending the package to support custom newsletters? Any suggestions on where to start? Thanks for reading. -- Carl Fink postmaster(a)iconsf.org I-Con System Administrator and Postmaster <http://www.iconsf.org/>

3 2

Storing other data in the list object
by Matthew Newton 19 May '05

19 May '05

Hi, The Mailman system I'm putting together has lists automatically created/deleted depending on another database (i.e. the university database defines what lists exist, and who owns them, and Mailman should then match this). I need to be able to store information about when the list was created (this is used in the synchronization procedure). I could save this in another text file, but that is something else to go wrong / get out of synch. Therefore, is the following safe to do, (assuming I use a variable that is unlikely to be used by Mailman itself)? Is there a place I should be using instead of this (i.e. a dictionary in the object called "localdata")? m = MailList.MailList(listname, lock=1) m.uol_createddate = "something" m.Save() m.Unlock() 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

2 1

Re: [Mailman-Developers] [Fwd: [ mailman-Bugs-1188133 ] CGI group id not properly tested]
by Barry Warsaw 18 May '05

18 May '05

On Wed, 2005-05-18 at 09:49, Graham Klyne wrote: > This comment surprises me a little, as I am using postfix and I was > experiencing access-related problems. However, following my initial > installation, I did find that I had to change the file protection on the > alias files [*], otherwise I was unable to use Mailman to create new > mailing lists, so maybe that was my problem all along? (This being after > encountering the previous problem and applying the "patch".) Yes, you need to have both the aliases and the aliases.db file writable by group mailman, and group owned by mailman. However, additionally, the aliases.db file must be /user/ owned by mailman in order for Postfix to execute the scripts with the proper permissions. If that's not clear in the documentation (and enforced by check_perms) then you should file a bug report so we can make sure those issues are addressed. -Barry

1 0

(no subject)
by loisbert1＠aol.com 17 May '05

17 May '05

Please get more off of this list server!!!!!!! NOW

1 0

Search members bug?
by Jimmy Svensson 15 May '05

15 May '05

I'm using the latest release candidate of Mailman and have a problem with the search function. When the result from the search is more than could be viewed on one page the result is divided into several pages depending on the beginning character of the email address... but when I want to view the results from the search beginning with anything other than A (for example B) the search is forgotten and all members beginning with B is shown instead of the ones I searched for. The problem is that the links for the different characters only contain the get variable "letter" and not "findmember" which is the variable posted by the search form. Have anyone else had the same problem? Would be nice with a fix for this. /Jimmy Svensson

5 7

Re: [Mailman-Developers] Patch for Mail Archive mirroring
by Jeff Marshall 14 May '05

14 May '05

Barry wrote: > I think I've stated my general philosophy in a previous message. > If WizzyMTA came with a new plug-in, documentation, and some promise > of support help (if only to answer questions on mailman-users), we'd > probably add the module in the next release. If we had a similar plug-in > architecture for multiple 3rd-party archivers, we'd facilitate the same > kind of thing for that service. I'd be all for that. Thanks for your feedback. I'll be happy to dig into the current archive system and work on a plug-in architecture to support multiple external archivers. I originally thought the Archive component of Mailman was something intended only to support the local pipermail archive, but using that API like you mention sounds like it would work well. I'm guessing it'd be a fair amount of work to make the internal pipermail work with the plug-in approach just like the external archivers. At the very least, it would need a lot of testing to make sure it doesn't break existing installations. I'll get back with MARC and possibly GMane so I can try to make things as general as is reasonable. I'll try to run a proposed approach in front of the list before coding it (unless it's easy enough to demonstrate the proposal via code). I think the only concern is that I think admins *would* find value in per-list control of external archives. This is speculation, though. Jeff

6 6

Mailman 2.1.6 release candidate 4
by Barry Warsaw 14 May '05

14 May '05

A few more last minute fixes and some language updates. Please let me know if you encounter any show stoppers. Barring any really critical bugs, this is going to be 2.1.6 final. -Barry https://sourceforge.net/project/shownotes.php?release_id=327367

1 0

subject_prefix multiplication
by Mark Sapiro 13 May '05

13 May '05

All of a sudden, within the last hour or so, subject_prefix on both mailman-users(a)python.org and mailman-developers(a)python.org is being added to replies even though it's already present resulting in doubling and tripling (so far not more) of the prefix. -- Mark Sapiro <msapiro(a)value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 5

Patch for Mail Archive mirroring
by Jeff Marshall 13 May '05

13 May '05

I have submitted a patch to SourceForge for consideration. Feature: - New third party archiving option that uses The Mail Archive. The implementation subscribes or unsubscribes the archive(a)mail-archive.com address from the subscriber list. The benefit to the list admin is to have a one-click setup option to provide them with mirroring and searchable archives. We (me and the other Jeff that admin The Mail Archive) have spoken with Lars at Gmane to see if we could make this work for Gmane as well, but he said their subscription process is manual and requires extra information, so Lars didn't think it would work for him. Patch was made against the latest CVS in branch Release_2_1-maint, which is currently 2.1.6rc3. Feedback? Thanks. Jeff Marshall marshman(a)frozenbear.com

13 36

Re: [Mailman-Developers] Patch for Mail Archive mirroring
by Jeff Marshall 12 May '05

12 May '05

I wrote: > I will check with Hank at MARC. One more followup. I emailed with Hank at MARC (marc.theaimsgroup.com). Hank really likes the idea and tried enhancing the patch to cover MARC as well. He ran into a few issues that caused him to abort the attempt ["...setting of the List-Archive: URL header. MARC (and I think Gmane too) sometimes takes liberty with list names, such as for a project foo, if they've a list "users" we add it as "foo-users" (as opposed to Mail Archive's equivalent "users(a)foo.org" which works to keep them unique). That also makes it difficult to make meaningful predictions for what the resulting URLs will be, or checking the subscription list, etc. "]. So for now Hank is passing on resolving those issues, although he's willing to put more effort into it if people want the MARC option. Jeff

1 0

Re: [Mailman-Developers] Patch for Mail Archive mirroring
by Jeff Marshall 06 May '05

06 May '05

I figured I would attempt a brief summary of major points brought up by the discussion. Concerns - proper documentation describing the feature and possibly Mailman's position on archiver tie-ins - make sure it defaults to off (it currently does) - we should look for opportunities to add safeguards - one possible safeguard - an option for admins to add the "X-No-Archive: yes" header - has pros and cons (cons: does it conflict with local pipermail archiving? possible conflict with user's X-No-Archive intentions?) Is it an endorsement? - people ranged from "seems like an endorsement" to "no more than mailman endorses the other software it works with" - I'm happy to do the work to make this feature work with other archiving services as well. Gmane looks like it is out. I will check with Hank at MARC. Overall - seems like most people think it is a positive patch (with the caveat that it defaults to "off") because it makes things easy for admins that choose to use it - in the end, it's up to Barry and Tokio. Hopefully one of them can jump in briefly and make the call, or ask me for some rework on the patch. Corrections or clarifications are welcome. Thanks to everyone for their consideration and response; people seemed to put a lot of energy into this. Much appreciated. Jeff Marshall marshman(a)frozenbear.com -----Original Message----- From: Brad Knowles Date: 5/3/05 1:56 am To: Stephen J. Turnbull Cc: mailman-developers(a)python.org, Chuq Von Rospach , Chuq Von Rospach Subj: Re: [Mailman-Developers] Patch for Mail Archive mirroring At 5:37 PM +0900 2005-05-03, Stephen J. Turnbull wrote: > Sure, they _are_ different, in a relevant way---they exist to broaden > distribution, including archiving. But I think that in the great > majority of cases where random users can just sign up, that is a > service to be encouraged. It's not a good idea to put the burden of > proof on them, when either the list-owner can be more selective about > membership, or they can use X-No-Archive. The problem here is that Mailman should not be adding an "X-No-Archive:" header to messages that it is processing. This is something that should be controlled from the perspective of the user, and Mailman should not be stepping on their toes. Moreover, if Mailman did add such a header, what would happen to the internal archiving system? Would Mailman ignore the header that it has added while honoring the same header that might have been put on the message by the user? As a list admin, I can see a strong desire to keep your own archive, but to want to prevent anyone else from maintaining an archive, at least not without your express approval. Unless, that is, you gateway to USENET news, in which case Google and others have news archives that you could not control and could not even be aware of in most cases. But then if you gateway to USENET news, you should be aware of this issue, and be prepared for what might happen. > Again, I'm not really arguing against the patch. It's the people who > might be doing extra releases (Barry and Tokio, right?) or answering > the FAQs (Brad and Mark, primus inter pares) who should decide if it > belongs in the Mailman distribution. IMO, the ultimate decision is up to Barry -- it's his project, and he gets to decide how things go. However, he is currently focusing on Mailman3 right now, and Tokio is the release engineer for Mailman2, and in the past Barry has been open to comments and suggestions from others. So, I imagine he might make his feelings known, but then leave the ultimate decision to Tokio, who would hopefully also take input from others. However, I don't see that Mark or I would necessarily have any more weight given to our comments during that discussion as a result of our work with the FAQ and answering the questions. I would hope that we would be heard along with the others commenting on the subject, and appropriate weight would be given to them by Barry and Tokio, but more based on their merits than on the work we do with the FAQ. There are plenty of other knowledgeable people on mailman-users and mailman-developers who don't (or haven't recently) done much of anything with the FAQ, and I would hope that their voices would be given as much weight relative to their experience as would ours. > I do advocate some kind of public statement about the policy toward > adding new facilities of this kind. One easy one would be "you write > the patch, and show that you conform to certain rules such as 'patch > defaults off' and 'service respects X-No-Archive as well as conforming > to relevant RFCs', and we'll put it in to the next regular release > that isn't already in feature freeze." I'm not so sure this is a good idea. At least, not so far as guaranteeing that it would be put in the next regular release. IMO, if the patch defaults to off, and the service conforms to the relevant RFCs and BCPs, then I think we should give it serious consideration, but I wouldn't want to guarantee anything more than serious consideration. > Or maybe it's worth encouraging such services, and being more helpful > about it. I would encourage more people to make patches, and to try to be more helpful about this process in general. But I wouldn't want to make any guarantees as to what would/would not get included -- everything should get the appropriate level of consideration, but no guarantees beyond that. -- Brad Knowles, <brad(a)stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info. _______________________________________________ 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/marshman%40frozze… Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.http

3 2

XHTML Compliant Web UI - 2.1.6 Patch
by Bryan Carbonnell 05 May '05

05 May '05

I have just uploaded a patch that will make the web UI for MM 2.1.6rc1 XHTML 1 strict compliant. This patch allows for some CSS formatting as well. I have tried to make all the pages compliant, but I may have missed some combinations of pages and options, so if you find some that aren't compliant, please let me know which page isn't compliant and under which circumstances it's not. 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,since this is my first attempt at something like this. -- Bryan Carbonnell - carbonnb(a)gmail.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!"

3 2

Re: [Mailman-Developers] [ mailman-Bugs-871050 ] Uncought runner exception: Empty module name
by Steven G. Willis 02 May '05

02 May '05

It hath once been written: >UITB-Originating-Server: 194.109.24.25 (smtp-vbr5.xs4all.nl) The email (SMTP) server at 194.109.24.25 has been documented as: sending unsolicted email; on a network that sends unsolicited email; participated in a coordinated attack on our network (open bounce relay). You can view a direct report for the IP in question at: http://www.uitb.deepskytech.com/show_ip_report.php?ip=194.109.24.25 The bounces contain enough information for you to identify the general source of the problem. You should also have enough information to contact us directly for any details you may need in identifying the specific problem that exists in your email server(s)/network. Once you have corrected the problem(s) , please notify us of this. We can then confirm that the problem(s) has been corrected and remove the block that is in place for your email server(s)/network. ------------------------------------------------------------ NOTE: the issues on file from this location are simple enough to correct. Once these issues have been corrected, please contact us with the following information: IP Address(es) of SMTP Server(s) Managed: Host names of SMTP Server(s): Full Name/Role: Company Name (if any): Voice Phone Contact: Email Address: Full Snail Mail Address: We will use this information to create an "Allow record" for the IP addresses managed as SMTP servers by this individual/role. The information within an Allow record is kept private within the UITB.com system. And, once an Allow record has been created for particular IP address(es), then any future issues we see originating from there will result in a notification email being dispatched instead of immediate blocking; this allows for the situation noted to be corrected before any blocking is put into place that may possibly affect users. Let me know if you have any questions on this or if we can help in any way. Cheers! ================================================================ Steven G. Willis sgwillis(a)deepskytech.com 866.224.3058 Deep Sky Technologies, Inc. http://www.deepskytech.com/ http://www.badchickens.com/ http://www.store-secure.com/ AIM-iChat: dstisgwillis ================================================================ All words are plastic. Word images begin to distort in the instance of utterance. Ideas imbedded in a language require that particular language for expression. This is the very essence of the meaning within the word "exotic". ================================================================

1 1

max_days_to_hold
by Barry Warsaw 02 May '05

02 May '05

I just upgraded all the lists @python.org from 2.1.5 to 2.1.6rc3. I noticed that they all grew a max_days_to_hold = 3 value. I actually don't understand this since version.py has a add_only_if_missing('max_days_to_hold', 0) call. So shouldn't they all have gotten set to zero? I'd like to figure this out before we release 2.1.6 final. Also, I plan on changing DEFAULT_MAX_DAYS_TO_HOLD to 0 in Defaults.py.in because I don't think this should be enabled by default for new lists (it's a new feature in a maintenance release). -Barry

1 0