From mss at mawhrin.net Tue Apr 1 13:09:51 2003 From: mss at mawhrin.net (Mikhail Sobolev) Date: Tue Apr 1 07:09:56 2003 Subject: [Mailman-Developers] translation update Message-ID: <20030401120951.GA27889@mawhrin.net> Lately I was not able to invest enough time to support the Russian translation. Now I think that I would be able to catch up with the latest changes (both sent to me by some Russian speaking users and working changes). However, I am not sure where to commit my updates to. Can you please advise? Thanks -- Misha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20030401/506735fb/attachment.bin From barry at python.org Tue Apr 1 20:38:03 2003 From: barry at python.org (Barry Warsaw) Date: Tue Apr 1 15:38:04 2003 Subject: [Mailman-Developers] Experimental spambayes integration Message-ID: <1049229580.29477.30.camel@barry> Back in January, I worked out this patch for Mailman/Spambayes integration. Simone finally prodded me to upload it so here it is: http://sourceforge.net/tracker/index.php?func=detail&aid=713522&group_id=103&atid=300103 I really only played with this on the train ride up and back and haven't touched it since (except to update the patch). Let me know what you think and whether this would make a good addition for Mailman 2.2/3.0 Cheers, -Barry From barry at python.org Wed Apr 2 05:00:39 2003 From: barry at python.org (Barry Warsaw) Date: Wed Apr 2 00:00:41 2003 Subject: [Mailman-Developers] translation update In-Reply-To: <20030401120951.GA27889@mawhrin.net> References: <20030401120951.GA27889@mawhrin.net> Message-ID: <1049259647.3075.18.camel@geddy> On Tue, 2003-04-01 at 07:09, Mikhail Sobolev wrote: > Lately I was not able to invest enough time to support the Russian > translation. Now I think that I would be able to catch up with the > latest changes (both sent to me by some Russian speaking users and > working changes). > > However, I am not sure where to commit my updates to. > > Can you please advise? If you can, it would be best to apply updates to both the cvs trunk and the Release_2_1-maint branch. Unfortunately this probably means you need to check out both branches. On the positive side, the code bases are pretty close right now so it should be fairly easy to apply the changes to both branches. If not, please apply them to the trunk and I will backport them to the maint branch. At some point, the trunk will diverge. That'll happen when I commit to a 2.2 or 3.0 release (a decision I'm putting off as long as possible ;). At that point, managing the translations will get more, er, interesting, so I'm up for suggestions (although some of the Zope work I'm doing might be applicable). -Barry From terri at zone12.com Wed Apr 2 01:00:24 2003 From: terri at zone12.com (Terri Oda) Date: Wed Apr 2 00:53:42 2003 Subject: [Mailman-Developers] Hi all, In-Reply-To: <003a01c2f09a$354e9f10$858992cb@PATTHAI> References: <003a01c2f09a$354e9f10$858992cb@PATTHAI> Message-ID: <20030402060024.GD5027@ostraya.zone12.com> On Sat, Mar 22, 2003 at 11:41:01PM +0600, John Kromodimedjo wrote: > I am very new to Mailman. Can one of you direct me to the complete > documentation of Mailman?? Someone's probably already answered this privately, but for the archives, here I go... Your best bet is http://list.org/docs.html If you're desperate for more up-to-date stuff, you can see the partially finished 2.1 list admin manual in sourceforge. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mailman/mailman/doc/ I'm *hoping* to have the 2.1 member manual in sourceforge Real Soon Now, but I'm prepping the final copy of my paper for a genetic computing conference, so the documentation's been put on hold for a little bit. I have an almost finished draft online if you're desperate, though. Anyone interested will have to email me for the url at the moment: I just don't want to start posting it publically when I've still got a bunch of proofreading comments to apply to it. Terri From carson at taltos.org Wed Apr 2 04:54:52 2003 From: carson at taltos.org (Carson Gaspar) Date: Wed Apr 2 04:54:51 2003 Subject: [Mailman-Developers] Password reminder envelope source address strangeness Message-ID: <1836002500.1049259292@[192.168.20.2]> It appears that my lists' password reminders are being sent from a now bogus (but previously valid) envelope from address. I can't seem to track down where it's getting the ancient address from. All the list traffic has the correct envelope from address, it's just the password reminders that are b0rked. This is with mailman from CVS on 2002-11-11, FYI (yes, I should upgrade, I know...) -- Carson From mch at cix.compulink.co.uk Wed Apr 2 15:55:00 2003 From: mch at cix.compulink.co.uk (Mike Holderness) Date: Wed Apr 2 09:55:49 2003 Subject: [Mailman-Developers] RFE: list-rules field Message-ID: When someone has a free moment, this shouldn't be difficult to do ;-) If there were a field "rules", usable in the templates as <MM-list-rules>, it would be a bit easier to maintain multiple lists with a single custom subscriber interface. Yes, I know I could include the Rules of the House with the list description, but I like flexibility in layout... To see what I'm on about, visit www.londonfreelance.org/indynet/ - from which, apart from this, I was able to generate a new list without any editing. Mike From charlie at begeistert.org Wed Apr 2 22:06:17 2003 From: charlie at begeistert.org (Charlie Clark) Date: Wed Apr 2 15:04:26 2003 Subject: [Mailman-Developers] Weird problem with Mailman when using Phoenix In-Reply-To: References: Message-ID: <20030402220617.12827.3@wonderland.1049313481.fake> Hi, just discovereed that I can't actually do anything with the forms with Phoenix, ie. "Submit" just doesn't work, under BeOS at least. I'll check Mozilla and other platforms. Charlie From matthew.davis at dogpound.vnet.net Wed Apr 2 17:08:36 2003 From: matthew.davis at dogpound.vnet.net (Matthew Davis) Date: Wed Apr 2 17:01:51 2003 Subject: [Mailman-Developers] Weird problem with Mailman when using Phoenix In-Reply-To: <20030402220617.12827.3@wonderland.1049313481.fake>; from charlie@begeistert.org on Wed, Apr 02, 2003 at 10:06:17PM +0200 References: <20030402220617.12827.3@wonderland.1049313481.fake> Message-ID: <20030402170836.A25636@dogpound.vnet.net> * Charlie Clark (charlie@begeistert.org) wrote: > just discovereed that I can't actually do anything with the forms with > Phoenix, ie. "Submit" just doesn't work, under BeOS at least. I'll check > Mozilla and other platforms. I've been using Mozilla 1.2.1 & 1.3 and mailman 2.1.1 for some time now with no problems. Just tested with phoenix 0.4 (dont have a copy of .5 right now, and it works with no problems. -- Matthew Davis http://dogpound.vnet.net/ Individualists of the world, UNITE! From barry at python.org Thu Apr 3 05:31:47 2003 From: barry at python.org (Barry Warsaw) Date: Thu Apr 3 00:31:49 2003 Subject: [Mailman-Developers] Weird problem with Mailman when using Phoenix In-Reply-To: <20030402170836.A25636@dogpound.vnet.net> References: <20030402220617.12827.3@wonderland.1049313481.fake> <20030402170836.A25636@dogpound.vnet.net> Message-ID: <1049347918.31237.5.camel@geddy> On Wed, 2003-04-02 at 17:08, Matthew Davis wrote: > I've been using Mozilla 1.2.1 & 1.3 and mailman 2.1.1 for some time now with > no problems. > > Just tested with phoenix 0.4 (dont have a copy of .5 right now, and it works > with no problems. I generally test Mailman with Moz (1.2.1 and 1.3) on Linux, and Moz, Camino, and Safari on MacOSX. Haven't seen a problem with any of them. Mailman's html is pretty pedestrian so I'd be very surprised if it's a problem with our output. -Barry From charlie at begeistert.org Thu Apr 3 10:08:53 2003 From: charlie at begeistert.org (Charlie Clark) Date: Thu Apr 3 03:06:54 2003 Subject: [Mailman-Developers] Weird problem with Mailman when using Phoenix In-Reply-To: <1049347918.31237.5.camel@geddy> References: <20030402220617.12827.3@wonderland.1049313481.fake> <20030402170836.A25636@dogpound.vnet.net> <1049347918.31237.5.camel@geddy> Message-ID: <20030403100853.613.3@wonderland.1049356500.fake> On 2003-04-03 at 07:31:58 [+0200], you wrote: > I generally test Mailman with Moz (1.2.1 and 1.3) on Linux, and Moz, > Camino, and Safari on MacOSX. Haven't seen a problem with any of them. > Mailman's html is pretty pedestrian so I'd be very surprised if it's a > problem with our output. mm, it's likely to be a BeOS issue and having looked at the source it looks like it might be something to do with multipart forms. I'll take it up with the maintainers of Phoenix for BeOS as it's clearly not a Mailman issue. Charlie From ricardo at rixhq.nu Thu Apr 3 20:56:34 2003 From: ricardo at rixhq.nu (Ricardo Kustner) Date: Thu Apr 3 13:56:38 2003 Subject: [Mailman-Developers] plaintext digest & message headers... bug? Message-ID: <3E8C83E2.70401@rixhq.nu> Hi, I'm running mailman 2.1.1 with a moderated list and digest. I noticed that often (but not always), messages in the plaintext digest include more headers than needed. Sometimes it's only a "content-type" header at the end, but sometimes it's even the complete header (includindg the whole "List-" header story). Before I submit this as a bug I wanted to make sure if somebody noticed this before. I can't imagine nobody had this problem already... Regards, Ricardo. From mentor at alb-net.com Sat Apr 5 10:49:09 2003 From: mentor at alb-net.com (Mentor Cana) Date: Sat Apr 5 10:49:13 2003 Subject: [Mailman-Developers] suggestion for two important (I think) features Message-ID: Barry, Recently I started shopping for some web hosting service and obviously was looking for a web hosting service that uses mailman for mailing lists management. Soon realized that all of these services have installed one instance of Mailman and serve the lists for the various domains using some sort of scripting and the virtual domain functionality in Mailman. Now, not being able to have control of the Mailman installation, there are two problems related to those who would like to move a list with its archives and listmembers from one hosting service to another. 1. Without admin help a listowner can't move the archives of a list from one hosting service to another. This can be resolved by providing an "Upload old archive" option/button under "Archiving Options" and after the 'old' archive is uploaded successfully, the bin/arch command is run for that list. We already have the capability to download full archives, i.e. the *.mbox raw file. In addition, this removes some work from the Mailman admin and into the hands of the listowners. 2. Also, without the help of the Mailman admin, a listowner can't get the full list of listmembers. A button "E-mail me the raw list of listmembers" can run the "bin/list_members" for the list and e-mail it to the list admin from the list's configuration. Any thoughts? thanks, Mentor From barry at python.org Sun Apr 6 22:26:32 2003 From: barry at python.org (Barry Warsaw) Date: Sun Apr 6 17:26:34 2003 Subject: [Mailman-Developers] Re: suggestion for two important (I think) features In-Reply-To: References: Message-ID: <1049600370.6645.12.camel@geddy> On Sat, 2003-04-05 at 10:49, Mentor Cana wrote: > 1. Without admin help a listowner can't move the archives of a list from > one hosting service to another. This can be resolved by providing an > "Upload old archive" option/button under "Archiving Options" and after > the 'old' archive is uploaded successfully, the bin/arch command is run > for that list. We already have the capability to download full archives, > i.e. the *.mbox raw file. > In addition, this removes some work from the Mailman admin and into the > hands of the listowners. Several things frighten me about this: - What do you do about huge archive files? - bin/arch is extremely memory unfriendly - concurrency on the list and the archive while the update is occurring We could impose upload limits to address the first two, although I'm not sure what good defaults would be, and it adds another layer of complexity to the scenario. The list admin would be forced to split up their archives and submit each independently (tedious, plus the concurrency issue raises its ugly head again). Or you'd have to fall back to admin help anyway. > 2. Also, without the help of the Mailman admin, a listowner can't get the > full list of listmembers. A button "E-mail me the raw list of > listmembers" can run the "bin/list_members" for the list and e-mail it > to the list admin from the list's configuration. Why doesn't an email to listname-request with the subject "who adminpw" do the trick? :) Okay, maybe the format isn't perfect, but have I told you about my idea of hooking Mailman up to Twisted so you could have XMLRPC access to your list databases almost for free? :) I'm seriously thinking about this because you'd potentially gain other benefits: the default out-of-the-box implementation probably wouldn't need a web server or an mta, and we /might/ be able to get rid of the multiple processes (but I'm not sure about that). -Barry From barry at python.org Sun Apr 6 22:27:06 2003 From: barry at python.org (Barry Warsaw) Date: Sun Apr 6 17:27:27 2003 Subject: [Mailman-Developers] plaintext digest & message headers... bug? In-Reply-To: <3E8C83E2.70401@rixhq.nu> References: <3E8C83E2.70401@rixhq.nu> Message-ID: <1049609731.6665.66.camel@geddy> On Thu, 2003-04-03 at 13:56, Ricardo Kustner wrote: > I'm running mailman 2.1.1 with a moderated list and digest. > I noticed that often (but not always), messages in the plaintext digest > include more headers than needed. Sometimes it's only a "content-type" > header at the end, but sometimes it's even the complete header > (includindg the whole "List-" header story). > Before I submit this as a bug I wanted to make sure if somebody noticed > this before. I can't imagine nobody had this problem already... Nope, haven't seen it before. If you do submit a bug report, it would be extremely helpful to have a digest.mbox file that exhibits the problem. Capturing that might require you to hack the code to make a backup copy of each digest.mbox file before using it to generate the digests. Also, see Defaults.py for the list of headers kept in digests (I can't remember if this changed in 2.1.1 or only in cvs, and I'm offline at the moment). -Barry From barry at python.org Sun Apr 6 22:27:36 2003 From: barry at python.org (Barry Warsaw) Date: Sun Apr 6 17:27:44 2003 Subject: [Mailman-Developers] still having admin cookie problem In-Reply-To: <20030329215515.GN13285@mrbill.net> References: <20030329215515.GN13285@mrbill.net> Message-ID: <1049612729.6665.106.camel@geddy> On Sat, 2003-03-29 at 16:55, Bill Bradford wrote: > I'm running MM 2.1.1, and am *still* seeing the admin cookie problem - > when I go to accept/discard posts that were held for moderation, select the > option for each one, then hit submit - it then takes me *back* to the > password entry screen, I have to enter the admin password *again*, and > then do it all over and hit submit a second time before it will take > effect. > > This has been tested and happens even with new installations of browsers > that have *no* cookies stored. > > Suggestions? Unfortunately, no. Maybe a browser problem? Are you proxying anywhere in the http trail? -Barry From barry at python.org Sun Apr 6 22:27:36 2003 From: barry at python.org (Barry Warsaw) Date: Sun Apr 6 17:27:46 2003 Subject: [Mailman-Developers] Password reminder envelope source address strangeness In-Reply-To: <1836002500.1049259292@[192.168.20.2]> References: <1836002500.1049259292@[192.168.20.2]> Message-ID: <1049612651.6665.104.camel@geddy> On Wed, 2003-04-02 at 04:54, Carson Gaspar wrote: > It appears that my lists' password reminders are being sent from a now > bogus (but previously valid) envelope from address. I can't seem to track > down where it's getting the ancient address from. All the list traffic has > the correct envelope from address, it's just the password reminders that > are b0rked. > > This is with mailman from CVS on 2002-11-11, FYI (yes, I should upgrade, I > know...) The password reminders come from the site list, so maybe something's screwed up with its configuation? -Barry From pioppo at ferrara.linux.it Mon Apr 7 01:24:14 2003 From: pioppo at ferrara.linux.it (Simone Piunno) Date: Sun Apr 6 18:25:56 2003 Subject: [Mailman-Developers] spambayes integration Message-ID: <20030406222414.GA22091@ferrara.linux.it> Hi, The last few days I've played with Barry's patch for spambayes integration and after some little tweak (patches available on both Mailman and spambayes SF bug trackers) it worked very well. Now I'm planning some enhancement: - optionally, use a "continuos train" model, where the filter is trained automatically for each incoming messaged categorized as either ham or spam (unsure messages won't be used for automatic training). In this case the "train on this message" option in admindb will become "re-train on this message", because we'll have to unlearn the previous train before doing the new. This is almost done. - interface for training on leaked spam (messages that got categorized as ham or unsure and therefore delivered to the list members). Currently I have to log on the server and through the shell use some script to load the spam message, because non-spam doesn't get held in admindb. This is not acceptable. What I'm thinking now, is that each message delivered to the list could be saved somewhere in its pristine state (e.g. before CookHeaders, probably in SpamDetect itself) so that at a later time I (the list admin) could say "that was spam, please train on it", maybe refererring it by Message-ID. This buffer of pristine messages should be cleaned periodically (number of days configurable?) I thought also to different schemes, but they all have problems: - forward the received message to listname-train@server with the list password somewhere on the headers. Even if I use MIME-forward to keep the message intact, it's not the same message that was examinated by SpamDetect. We have a dozen headers added or munged. - upload through the web, same problems and we've also to force the user to save in a commond format, e.g. unix mbox. This would be a nightmare for windows users. - stats where you can see how well the filter is performing, a list of all token learnt with ham/spam counters and different colors (green for ham indicators, red for spam indicators, yellow for neutral ones). This is probably related to the more general "Should be able to gather statistics, such as deliveries/day, performance, number of subscribers over time, etc." in the TODO page. -- Simone Piunno -- http://members.ferrara.linux.it/pioppo .------- Adde parvum parvo magnus acervus erit -------. Ferrara Linux Users Group - http://www.ferrara.linux.it Deep Space 6, IPv6 on Linux - http://www.deepspace6.net GNU Mailman, Mailing List Manager - http://www.list.org `-------------------------------------------------------' From mrbill at mrbill.net Mon Apr 7 11:40:42 2003 From: mrbill at mrbill.net (Bill Bradford) Date: Mon Apr 7 11:40:46 2003 Subject: [Mailman-Developers] still having admin cookie problem In-Reply-To: <1049612729.6665.106.camel@geddy> References: <20030329215515.GN13285@mrbill.net> <1049612729.6665.106.camel@geddy> Message-ID: <20030407154042.GD12601@mrbill.net> On Sun, Apr 06, 2003 at 04:27:05PM -0400, Barry Warsaw wrote: > Unfortunately, no. Maybe a browser problem? Are you proxying anywhere > in the http trail? Nope - tried multiple browsers (Mozilla, Safari, Camino, Opera) on multiple platforms (OS X, Solaris, Windows) and I still have it. No proxies anywhere; straight HTTP connections. Bill -- bill bradford mrbill@mrbill.net austin, texas From ricardo at rixhq.nu Mon Apr 7 22:36:37 2003 From: ricardo at rixhq.nu (Ricardo Kustner) Date: Mon Apr 7 15:36:41 2003 Subject: [Mailman-Developers] plaintext digest & message headers... bug? In-Reply-To: <1049609731.6665.66.camel@geddy> References: <3E8C83E2.70401@rixhq.nu> <1049609731.6665.66.camel@geddy> Message-ID: <3E91D345.5060500@rixhq.nu> Hi, Barry Warsaw wrote: >>I'm running mailman 2.1.1 with a moderated list and digest. >>I noticed that often (but not always), messages in the plaintext digest >>include more headers than needed. Sometimes it's only a "content-type" >>header at the end, but sometimes it's even the complete header >>(includindg the whole "List-" header story). >>Before I submit this as a bug I wanted to make sure if somebody noticed >>this before. I can't imagine nobody had this problem already... > Nope, haven't seen it before. If you do submit a bug report, it would > be extremely helpful to have a digest.mbox file that exhibits the > problem. Capturing that might require you to hack the code to make a > backup copy of each digest.mbox file before using it to generate the > digests. I saw you fixed the bug (thanks for that! :))... could you eloborate on what was wrong? maybe I can fix it in my own installation without having to revert to running the cvs version... Regards, Ricardo. From jdennis at redhat.com Mon Apr 7 21:16:03 2003 From: jdennis at redhat.com (John Dennis) Date: Mon Apr 7 16:16:04 2003 Subject: [Mailman-Developers] configure/build/packaging problems Message-ID: <1049746563.1214.105.camel@finch.boston.redhat.com> I picked up responsibility for the mailman rpm here at Red Hat a little while ago, just about the time of the 2.1 release. As a consequence I don't have a history with the prior releases, but I seem to have run into some build and packaging problems that I think were introduced in 2.1 and then carried over into 2.1.1. I believe as of 2.1 it became a requirement that the mailman user and group exist before the configure script is run. As far as I can tell this is because the configure script looks up user ids and/or user names in the system passwd database when its building its set of substitution strings for the .in files. One of the problems I've encountered is that production of the mailman RPM is done on machines where the set of users and groups are fixed for a variety of package production robustness reasons and I've lost the battle and have been told mailman must build without requiring the existence of a specific user. Whether one has sympathy for the rule or not is of little value, it is what it is. By the way, this problem just came to light as Red Hat users upgraded to Red Hat 9 which includes the mailman 2.1 release. In the interim I have produced a 2.1.1 rpm, but that is only available as a separate download. The problem was that some build machines had the user/group 'mailman' predefined and others did not, so some rpm's were good but others ended up with bogus configurations. I've studied the configure script in some detail and I think I understand the areas that need fixing but before I do that I'd like to ask some questions to sanity check my thinking before I go down the wrong rat hole. 1) At the heart of the mailman build philosophy seems to be the notion that mailman will (must?) be built on the target system. This seems to be in opposition to packaging concepts where a software component is built on an unrelated build machine, the resulting files gathered into an installation package, and then that package is installed on the target. Given that packaging is a common distribution mechanism I assume the approach of requiring the package to build on the target was a deliberate choice for some reason. If so what was the reason? If there isn't a compelling reason for the approach are you open to receiving patches that make the configure/build step friendly to packaging requirements or does this violate some principle mailman is trying to maintain? 2) I've noticed that some of the checks and lookups done in configure can be controlled with with-permcheck & without-permcheck. But not all the lookups are under the control of this variable. My initial thoughts were to have ALL the local lookups under the control of this variable, if without-permcheck is set then NO local lookups during configure/build are performed, configuration values are used as supplied. Does this sound reasonable? Is this overloading this variable with meaning that was not intended? 3) I've also run into problems where the .py files cannot be compiled into .pyc files on build system during the build. The culprit is the paths.py file which is included by quite a few of the python files. The problem is that paths.py has a hardcoded pathname (generated by the configure step) that only exists in the post-installed target. It does not exist on the build machine. Therefore some of the compiles fail because some of the source python files include files via paths.py that don't exist (yet). This means the compilation needs to be postponed to post-installation on the target. My understanding is that the python interpreter will drop a .pyc file in the source directory the first time it compiles the .py file so in theory its like a lazy compilation. But this has a few problems too, the python process has to have permission to write in that directory and it violates some packaging requirements that every file belonging to a package exists and is known at both package install and package remove time. I haven't really looked into what is required to fix this problem yet but it seems like we have to get rid of the hardcoded pathnames in paths.py and if someone has a suggestion I'd be curious to hear. I'd really like to be able to compile the python files during build before producing the installation package. John From manrique at fundacite.arg.gov.ve Wed Apr 2 16:24:03 2003 From: manrique at fundacite.arg.gov.ve (Eduardo Manrique (Fundacite Aragua)) Date: Mon Apr 7 17:17:51 2003 Subject: [Mailman-Developers] post got bad listname Message-ID: <20030402122403.M18875@fundacite.arg.gov.ve> Hello... I recently installed the new Mailman 2.1.1, i follow all the steps that the install file said me to did, i created a list, but when i send a test mail to the list return me this -------------------------------------------------------------------------- This is the Postfix program at host chuao.fundacite.arg.gov.ve. I'm sorry to have to inform you that the message returned below could not be delivered to one or more destinations. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the message returned below. The Postfix program : Command died with status 1: "/usr/local/mailman/mail/mailman post prueba2". Command output: Mailman error: post got bad listname: prueba2 Final-Recipient: rfc822; prueba2@fundacite.arg.gov.ve Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; Command died with status 1: "/usr/local/mailman/mail/mailman post prueba2". Command output: Mailman error: post got bad listname: prueba2 -------------------------------------------------------------------------- Please Help..... Thanks...... Eduardo Manrique Network adm... From a.carter at cordis.lu Thu Apr 3 14:09:48 2003 From: a.carter at cordis.lu (CARTER Anthony) Date: Mon Apr 7 17:17:52 2003 Subject: [Mailman-Developers] Mailman web interfaces and design Message-ID: <200304031409.48479.a.carter@intrasoft.lu> Hi, I am looking for a means of customizing the mailman we pages. I have noticed that some pages can be edited via the interface, but I would like to make more drastic changes (removing links to admin page for example). My first thing that I would like to do is, if possible, to add our own CSSs to the web pages. Does anyone know if this is possible, and if so, where do I start? Thanks, Anthony Carter From sen at codingtechnologies.com Fri Apr 4 17:44:39 2003 From: sen at codingtechnologies.com (Norbert Sendetzky) Date: Mon Apr 7 17:17:54 2003 Subject: [Mailman-Developers] "Sender:" header probably breaks S/MIME in Outlook Message-ID: <3E8DA867.9060708@codingtechnologies.com> Hi all I've set up mailman 2.0.13 for our mailing lists and we want to use S/MIME encryption for one of them. Thus, each member got his own cert and the cert of the mailing list. While this setup works for Mozilla and Netscape 4.7, our "beloved" Outlook clients complain about a missing certs if the users want to open an encrypted mail. This is problably due to the fact that the "Sender:" header is "mailinglist-admin@..." instead of "mailinglist@..". Therefore determining the correct cert fails. My question is now: How can I change the mailman 2.0.13 code (I havn't found a config option) to force "Sender:" to be only "mailinglist@..."? Thanks in advance -- _______________________________________________________________________ Dipl.-Inf. Norbert Sendetzky | SysAdmin & Software Engineer | Coding Technologies | phone: +49 (0) 911 92891 -36 | Deutschherrnstr. 15-19 fax: +49 (0) 911 92891 -99 | 90429 Nuernberg, Germany mailto:sen@CodingTechnologies.com | http://www.CodingTechnologies.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4094 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.python.org/pipermail/mailman-developers/attachments/20030404/96f6ad4b/smime-0001.bin From tag at cs.utah.edu Sat Apr 5 10:14:13 2003 From: tag at cs.utah.edu (Todd Green) Date: Mon Apr 7 17:17:56 2003 Subject: [Mailman-Developers] Lists actions not happening Message-ID: <200304051714.h35HEDV02104@faith.cs.utah.edu> I sent this to the main users list but didn't get a response. Hopefully a developer will know what's going on. Thanks ------- Forwarded Message We recently migrated from majordomo to mailman and created all the lists via a perl script. 99% of the lists transfered just fine however some of them seem to fail to actually perform their actions though mailman thinks that they did. For example a user tried to subcribe, got the confirmation but dumping the database shows he's not in the list (nor is the request pending in requests.db (it is a simple confirmation list.)) >From the logs: subscribe:Apr 02 11:19:51 2003 (17495) hsci: pending Eric Eide 155.98.63.200 subscribe:Apr 02 11:20:27 2003 (17498) hsci: new "edited" subscribe:Apr 02 11:23:23 2003 (17518) hsci: pending Eric Eide 155.98.63.200 subscribe:Apr 02 11:23:43 2003 (17520) hsci: new "edited" I've replaced the actual email addr with "edited". If I delete the list with rmlist and create it via the web interface all is fine. Here is a difference of the config.pck before and after the list was removed and recreated: diff hsci_old.dumpdb hsci_new.dumpdb 33c33 < 'created_at': 1048126881.44232, - --- > 'created_at': 1049309007.866532, 37c37 < 'description': 'Hsci', - --- > 'description': 'High School Computing Initiative', 83c83 < 'next_request_id': 21, - --- > 'next_request_id': 1, 109c109 < 'subject_prefix': '[Hsci] ', - --- > 'subject_prefix': u'[Hsci] ', All the perms on files also look fine (at least not different than any other list we're running.) We're running on Solaris9, with Python 2.2.2, and Mailman 2.1.1 Thanks, Todd ------- End of Forwarded Message From tom at plik.net Sat Apr 5 14:37:35 2003 From: tom at plik.net (Thomas C. Meggs) Date: Mon Apr 7 17:17:57 2003 Subject: [Mailman-Developers] encrypted mailing list Message-ID: <3E8F307F.6020300@plik.net> Hi, I've been playing around with the idea of making software for an encrypted mailing list that would be based around GPG. Each mailing list would have its own public key. All members of a list would have to submit a public key on subscription. When incoming mail is received, the mailing list software would decrypt the email and then re-encrypt with the public key for each of the members of the list. Has anyone played around with this idea? Has anyone already done a working concept? I was just curious, and I wanted to throw the idea out there. Thanks! Regards, Tom From joe at skyrush.com Sun Apr 6 20:41:45 2003 From: joe at skyrush.com (Joe Peterson) Date: Mon Apr 7 17:17:59 2003 Subject: [Mailman-Developers] I have found and fixed a bug in MailList.py (global addr change) Message-ID: <3E90D759.3090007@skyrush.com> Hi, sorry if this is not the right avenue for this (I looked on sourceforge for a way to submit a patch, but could not figure out how). Anyway, I found a bug today in Mailman 2.1.1. Again, sorry if this has been fixed, but I did not find it searching the bug tracker. If you have a user who is on some, but not all, of the lists on your server, and he/she goes and tries to change his/her address *globally*, it will let the person get the confirmation email, and when he/she clicks the link in the email and then the button on the page to make the change, it will only change the address on the list originally chose, and then give a "Bad Confirmation code" error. The problem is that the call, "self.__assertIsMember(member)" in OldStyleMemberships.py fails and raises the error. The isMember() call should have been checked in ApprovedChangeMemberAddress before trying to change the address in the other "global" lists: if not mlist.isMember(oldaddr): continue Note that this sort of check *is* done in ChangeMemberName: if not mlist.isMember(addr): continue Anyway, attached is the new MailList.py file. I hope the fix makes it into the next release. Please let me know how to submit this if it was inappropriate to post it here. Thanks for a great piece of software!! Joe -------------- next part -------------- # Copyright (C) 1998-2003 by the Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License # as published by the Free Software Foundation; either version 2 # of the License, or (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. """The class representing a Mailman mailing list. Mixes in many task-specific classes. """ import sys import os import time import marshal import errno import re import shutil import socket import urllib import cPickle from cStringIO import StringIO from UserDict import UserDict from urlparse import urlparse from types import * import email.Iterators from email.Utils import getaddresses, formataddr, parseaddr from Mailman import mm_cfg from Mailman import Utils from Mailman import Errors from Mailman import LockFile from Mailman.UserDesc import UserDesc # base classes from Mailman.Archiver import Archiver from Mailman.Autoresponder import Autoresponder from Mailman.Bouncer import Bouncer from Mailman.Deliverer import Deliverer from Mailman.Digester import Digester from Mailman.GatewayManager import GatewayManager from Mailman.HTMLFormatter import HTMLFormatter from Mailman.ListAdmin import ListAdmin from Mailman.SecurityManager import SecurityManager from Mailman.TopicMgr import TopicMgr # gui components package from Mailman import Gui # other useful classes from Mailman import MemberAdaptor from Mailman.OldStyleMemberships import OldStyleMemberships from Mailman import Message from Mailman import Pending from Mailman import Site from Mailman.i18n import _ from Mailman.Logging.Syslog import syslog EMPTYSTRING = '' # Use mixins here just to avoid having any one chunk be too large. class MailList(HTMLFormatter, Deliverer, ListAdmin, Archiver, Digester, SecurityManager, Bouncer, GatewayManager, Autoresponder, TopicMgr): # # A MailList object's basic Python object model support # def __init__(self, name=None, lock=1): # No timeout by default. If you want to timeout, open the list # unlocked, then lock explicitly. # # Only one level of mixin inheritance allowed for baseclass in self.__class__.__bases__: if hasattr(baseclass, '__init__'): baseclass.__init__(self) # Initialize volatile attributes self.InitTempVars(name) # Default membership adaptor class self._memberadaptor = OldStyleMemberships(self) if name: if lock: # This will load the database. self.Lock() else: self.Load() # This extension mechanism allows list-specific overrides of any # method (well, except __init__(), InitTempVars(), and InitVars() # I think). filename = os.path.join(self.fullpath(), 'extend.py') dict = {} try: execfile(filename, dict) except IOError, e: if e.errno <> errno.ENOENT: raise else: func = dict.get('extend') if func: func(self) def __getattr__(self, name): # Because we're using delegation, we want to be sure that attribute # access to a delegated member function gets passed to the # sub-objects. This of course imposes a specific name resolution # order. try: return getattr(self._memberadaptor, name) except AttributeError: for guicomponent in self._gui: try: return getattr(guicomponent, name) except AttributeError: pass else: raise AttributeError, name def __repr__(self): if self.Locked(): status = '(locked)' else: status = '(unlocked)' return '' % ( self.internal_name(), status, id(self)) # # Lock management # def Lock(self, timeout=0): self.__lock.lock(timeout) # Must reload our database for consistency. Watch out for lists that # don't exist. try: self.Load() except Exception: self.Unlock() raise def Unlock(self): self.__lock.unlock(unconditionally=1) def Locked(self): return self.__lock.locked() # # Useful accessors # def internal_name(self): return self._internal_name def fullpath(self): return self._full_path def getListAddress(self, extra=None): if extra is None: return '%s@%s' % (self.internal_name(), self.host_name) return '%s-%s@%s' % (self.internal_name(), extra, self.host_name) # For backwards compatibility def GetBouncesEmail(self): return self.getListAddress('bounces') def GetOwnerEmail(self): return self.getListAddress('owner') def GetRequestEmail(self): return self.getListAddress('request') def GetConfirmEmail(self, cookie): return mm_cfg.VERP_CONFIRM_FORMAT % { 'addr' : '%s-confirm' % self.internal_name(), 'cookie': cookie, } + '@' + self.host_name def GetListEmail(self): return self.getListAddress() def GetMemberAdminEmail(self, member): """Usually the member addr, but modified for umbrella lists. Umbrella lists have other mailing lists as members, and so admin stuff like confirmation requests and passwords must not be sent to the member addresses - the sublists - but rather to the administrators of the sublists. This routine picks the right address, considering regular member address to be their own administrative addresses. """ if not self.umbrella_list: return member else: acct, host = tuple(member.split('@')) return "%s%s@%s" % (acct, self.umbrella_member_suffix, host) def GetScriptURL(self, scriptname, absolute=0): return Utils.ScriptURL(scriptname, self.web_page_url, absolute) + \ '/' + self.internal_name() def GetOptionsURL(self, user, obscure=0, absolute=0): url = self.GetScriptURL('options', absolute) if obscure: user = Utils.ObscureEmail(user) return '%s/%s' % (url, urllib.quote(user.lower())) # # Instance and subcomponent initialization # def InitTempVars(self, name): """Set transient variables of this and inherited classes.""" # The timestamp is set whenever we load the state from disk. If our # timestamp is newer than the modtime of the config.pck file, we don't # need to reload, otherwise... we do. self.__timestamp = 0 self.__lock = LockFile.LockFile( os.path.join(mm_cfg.LOCK_DIR, name or '') + '.lock', # TBD: is this a good choice of lifetime? lifetime = mm_cfg.LIST_LOCK_LIFETIME, withlogging = mm_cfg.LIST_LOCK_DEBUGGING) self._internal_name = name if name: self._full_path = Site.get_listpath(name) else: self._full_path = None # Only one level of mixin inheritance allowed for baseclass in self.__class__.__bases__: if hasattr(baseclass, 'InitTempVars'): baseclass.InitTempVars(self) # Now, initialize our gui components self._gui = [] for component in dir(Gui): if component.startswith('_'): continue self._gui.append(getattr(Gui, component)()) def InitVars(self, name=None, admin='', crypted_password=''): """Assign default values - some will be overriden by stored state.""" # Non-configurable list info if name: self._internal_name = name # When was the list created? self.created_at = time.time() # Must save this state, even though it isn't configurable self.volume = 1 self.members = {} # self.digest_members is initted in mm_digest self.data_version = mm_cfg.DATA_FILE_VERSION self.last_post_time = 0 self.post_id = 1. # A float so it never has a chance to overflow. self.user_options = {} self.language = {} self.usernames = {} self.passwords = {} self.new_member_options = mm_cfg.DEFAULT_NEW_MEMBER_OPTIONS # This stuff is configurable self.respond_to_post_requests = 1 self.advertised = mm_cfg.DEFAULT_LIST_ADVERTISED self.max_num_recipients = mm_cfg.DEFAULT_MAX_NUM_RECIPIENTS self.max_message_size = mm_cfg.DEFAULT_MAX_MESSAGE_SIZE # See the note in Defaults.py concerning DEFAULT_HOST_NAME # vs. DEFAULT_EMAIL_HOST. self.host_name = mm_cfg.DEFAULT_HOST_NAME or mm_cfg.DEFAULT_EMAIL_HOST self.web_page_url = ( mm_cfg.DEFAULT_URL or mm_cfg.DEFAULT_URL_PATTERN % mm_cfg.DEFAULT_URL_HOST) self.owner = [admin] self.moderator = [] self.reply_goes_to_list = mm_cfg.DEFAULT_REPLY_GOES_TO_LIST self.reply_to_address = '' self.first_strip_reply_to = mm_cfg.DEFAULT_FIRST_STRIP_REPLY_TO self.admin_immed_notify = mm_cfg.DEFAULT_ADMIN_IMMED_NOTIFY self.admin_notify_mchanges = \ mm_cfg.DEFAULT_ADMIN_NOTIFY_MCHANGES self.require_explicit_destination = \ mm_cfg.DEFAULT_REQUIRE_EXPLICIT_DESTINATION self.acceptable_aliases = mm_cfg.DEFAULT_ACCEPTABLE_ALIASES self.umbrella_list = mm_cfg.DEFAULT_UMBRELLA_LIST self.umbrella_member_suffix = \ mm_cfg.DEFAULT_UMBRELLA_MEMBER_ADMIN_SUFFIX self.send_reminders = mm_cfg.DEFAULT_SEND_REMINDERS self.send_welcome_msg = mm_cfg.DEFAULT_SEND_WELCOME_MSG self.send_goodbye_msg = mm_cfg.DEFAULT_SEND_GOODBYE_MSG self.bounce_matching_headers = \ mm_cfg.DEFAULT_BOUNCE_MATCHING_HEADERS self.anonymous_list = mm_cfg.DEFAULT_ANONYMOUS_LIST internalname = self.internal_name() self.real_name = internalname[0].upper() + internalname[1:] self.description = '' self.info = '' self.welcome_msg = '' self.goodbye_msg = '' self.subscribe_policy = mm_cfg.DEFAULT_SUBSCRIBE_POLICY self.unsubscribe_policy = mm_cfg.DEFAULT_UNSUBSCRIBE_POLICY self.private_roster = mm_cfg.DEFAULT_PRIVATE_ROSTER self.obscure_addresses = mm_cfg.DEFAULT_OBSCURE_ADDRESSES self.admin_member_chunksize = mm_cfg.DEFAULT_ADMIN_MEMBER_CHUNKSIZE self.administrivia = mm_cfg.DEFAULT_ADMINISTRIVIA self.preferred_language = mm_cfg.DEFAULT_SERVER_LANGUAGE self.available_languages = [] self.include_rfc2369_headers = 1 self.include_list_post_header = 1 self.filter_mime_types = mm_cfg.DEFAULT_FILTER_MIME_TYPES self.pass_mime_types = mm_cfg.DEFAULT_PASS_MIME_TYPES self.filter_content = mm_cfg.DEFAULT_FILTER_CONTENT self.convert_html_to_plaintext = \ mm_cfg.DEFAULT_CONVERT_HTML_TO_PLAINTEXT self.filter_action = mm_cfg.DEFAULT_FILTER_ACTION # Analogs to these are initted in Digester.InitVars self.nondigestable = mm_cfg.DEFAULT_NONDIGESTABLE self.personalize = 0 # New sender-centric moderation (privacy) options self.default_member_moderation = \ mm_cfg.DEFAULT_DEFAULT_MEMBER_MODERATION # Emergency moderation bit self.emergency = 0 # This really ought to default to mm_cfg.HOLD, but that doesn't work # with the current GUI description model. So, 0==Hold, 1==Reject, # 2==Discard self.member_moderation_action = 0 self.member_moderation_notice = '' self.accept_these_nonmembers = [] self.hold_these_nonmembers = [] self.reject_these_nonmembers = [] self.discard_these_nonmembers = [] self.forward_auto_discards = mm_cfg.DEFAULT_FORWARD_AUTO_DISCARDS self.generic_nonmember_action = mm_cfg.DEFAULT_GENERIC_NONMEMBER_ACTION # Ban lists self.ban_list = [] # BAW: This should really be set in SecurityManager.InitVars() self.password = crypted_password # Max autoresponses per day. A mapping between addresses and a # 2-tuple of the date of the last autoresponse and the number of # autoresponses sent on that date. self.hold_and_cmd_autoresponses = {} # Only one level of mixin inheritance allowed for baseclass in self.__class__.__bases__: if hasattr(baseclass, 'InitVars'): baseclass.InitVars(self) # These need to come near the bottom because they're dependent on # other settings. self.subject_prefix = mm_cfg.DEFAULT_SUBJECT_PREFIX % self.__dict__ self.msg_header = mm_cfg.DEFAULT_MSG_HEADER self.msg_footer = mm_cfg.DEFAULT_MSG_FOOTER # Set this to Never if the list's preferred language uses us-ascii, # otherwise set it to As Needed if Utils.GetCharSet(self.preferred_language) == 'us-ascii': self.encode_ascii_prefixes = 0 else: self.encode_ascii_prefixes = 2 # # Web API support via administrative categories # def GetConfigCategories(self): class CategoryDict(UserDict): def __init__(self): UserDict.__init__(self) self.keysinorder = mm_cfg.ADMIN_CATEGORIES[:] def keys(self): return self.keysinorder def items(self): items = [] for k in mm_cfg.ADMIN_CATEGORIES: items.append((k, self.data[k])) return items def values(self): values = [] for k in mm_cfg.ADMIN_CATEGORIES: values.append(self.data[k]) return values categories = CategoryDict() # Only one level of mixin inheritance allowed for gui in self._gui: k, v = gui.GetConfigCategory() categories[k] = (v, gui) return categories def GetConfigSubCategories(self, category): for gui in self._gui: if hasattr(gui, 'GetConfigSubCategories'): # Return the first one that knows about the given subcategory subcat = gui.GetConfigSubCategories(category) if subcat is not None: return subcat return None def GetConfigInfo(self, category, subcat=None): for gui in self._gui: if hasattr(gui, 'GetConfigInfo'): value = gui.GetConfigInfo(self, category, subcat) if value: return value # # List creation # def Create(self, name, admin, crypted_password, langs=None): if Utils.list_exists(name): raise Errors.MMListAlreadyExistsError, name # Validate what will be the list's posting address. If that's # invalid, we don't want to create the mailing list. The hostname # part doesn't really matter, since that better already be valid. # However, most scripts already catch MMBadEmailError as exceptions on # the admin's email address, so transform the exception. postingaddr = '%s@%s' % (name, mm_cfg.DEFAULT_EMAIL_HOST) try: Utils.ValidateEmail(postingaddr) except Errors.MMBadEmailError: raise Errors.BadListNameError, postingaddr # Validate the admin's email address Utils.ValidateEmail(admin) self._internal_name = name self._full_path = Site.get_listpath(name, create=1) # Don't use Lock() since that tries to load the non-existant config.pck self.__lock.lock() self.InitVars(name, admin, crypted_password) self.CheckValues() if langs is None: self.available_languages = [self.preferred_language] else: self.available_languages = langs # # Database and filesystem I/O # def __save(self, dict): # Save the file as a binary pickle, and rotate the old version to a # backup file. We must guarantee that config.pck is always valid so # we never rotate unless the we've successfully written the temp file. # We use pickle now because marshal is not guaranteed to be compatible # between Python versions. fname = os.path.join(self.fullpath(), 'config.pck') fname_tmp = fname + '.tmp.%s.%d' % (socket.gethostname(), os.getpid()) fname_last = fname + '.last' fp = None try: fp = open(fname_tmp, 'w') # Use a binary format... it's more efficient. cPickle.dump(dict, fp, 1) fp.close() except IOError, e: syslog('error', 'Failed config.pck write, retaining old state.\n%s', e) if fp is not None: os.unlink(fname_tmp) raise # Now do config.pck.tmp.xxx -> config.pck -> config.pck.last rotation # as safely as possible. try: # might not exist yet os.unlink(fname_last) except OSError, e: if e.errno <> errno.ENOENT: raise try: # might not exist yet os.link(fname, fname_last) except OSError, e: if e.errno <> errno.ENOENT: raise os.rename(fname_tmp, fname) # Reset the timestamp self.__timestamp = os.path.getmtime(fname) def Save(self): # Refresh the lock, just to let other processes know we're still # interested in it. This will raise a NotLockedError if we don't have # the lock (which is a serious problem!). TBD: do we need to be more # defensive? self.__lock.refresh() # copy all public attributes to serializable dictionary dict = {} for key, value in self.__dict__.items(): if key[0] == '_' or type(value) is MethodType: continue dict[key] = value # Make config.pck unreadable by `other', as it contains all the # list members' passwords (in clear text). omask = os.umask(007) try: self.__save(dict) finally: os.umask(omask) self.SaveRequestsDb() self.CheckHTMLArchiveDir() def __load(self, dbfile): # Attempt to load and unserialize the specified database file. This # could actually be a config.db (for pre-2.1alpha3) or config.pck, # i.e. a marshal or a binary pickle. Actually, it could also be a # .last backup file if the primary storage file was corrupt. The # decision on whether to unpickle or unmarshal is based on the file # extension, but we always save it using pickle (since only it, and # not marshal is guaranteed to be compatible across Python versions). # # On success return a 2-tuple of (dictionary, None). On error, return # a 2-tuple of the form (None, errorobj). if dbfile.endswith('.db') or dbfile.endswith('.db.last'): loadfunc = marshal.load elif dbfile.endswith('.pck') or dbfile.endswith('.pck.last'): loadfunc = cPickle.load else: assert 0, 'Bad database file name' try: # Check the mod time of the file first. If it matches our # timestamp, then the state hasn't change since the last time we # loaded it. Otherwise open the file for loading, below. If the # file doesn't exist, we'll get an EnvironmentError with errno set # to ENOENT (EnvironmentError is the base class of IOError and # OSError). mtime = os.path.getmtime(dbfile) if mtime <= self.__timestamp: # File is not newer return None, None fp = open(dbfile) except EnvironmentError, e: if e.errno <> errno.ENOENT: raise # The file doesn't exist yet return None, e try: try: dict = loadfunc(fp) if type(dict) <> DictType: return None, 'Load() expected to return a dictionary' except (EOFError, ValueError, TypeError, MemoryError, cPickle.PicklingError), e: return None, e finally: fp.close() # Update timestamp self.__timestamp = mtime return dict, None def Load(self, check_version=1): if not Utils.list_exists(self.internal_name()): raise Errors.MMUnknownListError # We first try to load config.pck, which contains the up-to-date # version of the database. If that fails, perhaps because it's # corrupted or missing, we'll try to load the backup file # config.pck.last. # # Should both of those fail, we'll look for config.db and # config.db.last for backwards compatibility with pre-2.1alpha3 pfile = os.path.join(self.fullpath(), 'config.pck') plast = pfile + '.last' dfile = os.path.join(self.fullpath(), 'config.db') dlast = dfile + '.last' for file in (pfile, plast, dfile, dlast): dict, e = self.__load(file) if dict is None: if e is not None: # Had problems with this file; log it and try the next one. syslog('error', "couldn't load config file %s\n%s", file, e) else: # We already have the most up-to-date state return else: break else: # Nothing worked, so we have to give up syslog('error', 'All %s fallbacks were corrupt, giving up', self.internal_name()) raise Errors.MMCorruptListDatabaseError, e # Now, if we didn't end up using the primary database file, we want to # copy the fallback into the primary so that the logic in Save() will # still work. For giggles, we'll copy it to a safety backup. if file == plast: shutil.copy(file, pfile) shutil.copy(file, pfile + '.safety') elif file == dlast: shutil.copy(file, dfile) shutil.copy(file, pfile + '.safety') # Copy the loaded dictionary into the attributes of the current # mailing list object, then run sanity check on the data. self.__dict__.update(dict) if check_version: self.CheckVersion(dict) self.CheckValues() # # Sanity checks # def CheckVersion(self, stored_state): """Auto-update schema if necessary.""" if self.data_version >= mm_cfg.DATA_FILE_VERSION: return # Initialize any new variables self.InitVars() # Then reload the database (but don't recurse). Force a reload even # if we have the most up-to-date state. self.__timestamp = 0 self.Load(check_version=0) # We must hold the list lock in order to update the schema waslocked = self.Locked() if not waslocked: self.Lock() try: from versions import Update Update(self, stored_state) self.data_version = mm_cfg.DATA_FILE_VERSION self.Save() finally: if not waslocked: self.Unlock() def CheckValues(self): """Normalize selected values to known formats.""" if '' in urlparse(self.web_page_url)[:2]: # Either the "scheme" or the "network location" part of the parsed # URL is empty; substitute faulty value with (hopefully sane) # default. Note that DEFAULT_URL is obsolete. self.web_page_url = ( mm_cfg.DEFAULT_URL or mm_cfg.DEFAULT_URL_PATTERN % mm_cfg.DEFAULT_URL_HOST) if self.web_page_url and self.web_page_url[-1] <> '/': self.web_page_url = self.web_page_url + '/' # Legacy reply_to_address could be an illegal value. We now verify # upon setting and don't check it at the point of use. try: if self.reply_to_address.strip() and self.reply_goes_to_list: Utils.ValidateEmail(self.reply_to_address) except Errors.EmailAddressError: syslog('error', 'Bad reply_to_address "%s" cleared for list: %s', self.reply_to_address, self.internal_name()) self.reply_to_address = '' self.reply_goes_to_list = 0 # Legacy topics may have bad regular expressions in their patterns goodtopics = [] for name, pattern, desc, emptyflag in self.topics: try: re.compile(pattern) except (re.error, TypeError): syslog('error', 'Bad topic pattern "%s" for list: %s', pattern, self.internal_name()) else: goodtopics.append((name, pattern, desc, emptyflag)) self.topics = goodtopics # # Membership management front-ends and assertion checks # def InviteNewMember(self, userdesc, text=''): """Invite a new member to the list. This is done by creating a subscription pending for the user, and then crafting a message to the member informing them of the invitation. """ invitee = userdesc.address requestaddr = self.GetRequestEmail() # Hack alert! Squirrel away a flag that only invitations have, so # that we can do something slightly different when an invitation # subscription is confirmed. In those cases, we don't need further # admin approval, even if the list is so configured userdesc.invitation = 1 cookie = Pending.new(Pending.SUBSCRIPTION, userdesc) confirmurl = '%s/%s' % (self.GetScriptURL('confirm', absolute=1), cookie) listname = self.real_name text += Utils.maketext( 'invite.txt', {'email' : invitee, 'listname' : listname, 'hostname' : self.host_name, 'confirmurl' : confirmurl, 'requestaddr': requestaddr, 'cookie' : cookie, 'listowner' : self.GetOwnerEmail(), }, mlist=self) if mm_cfg.VERP_CONFIRMATIONS: subj = _( 'You have been invited to join the %(listname)s mailing list') sender = self.GetConfirmEmail(cookie) else: # Do it the old fashioned way subj = 'confirm ' + cookie sender = requestaddr msg = Message.UserNotification( invitee, sender, subj, text, lang=self.preferred_language) msg.send(self) def AddMember(self, userdesc, remote=None): """Front end to member subscription. This method enforces subscription policy, validates values, sends notifications, and any other grunt work involved in subscribing a user. It eventually calls ApprovedAddMember() to do the actual work of subscribing the user. userdesc is an instance with the following public attributes: address -- the unvalidated email address of the member fullname -- the member's full name (i.e. John Smith) digest -- a flag indicating whether the user wants digests or not language -- the requested default language for the user password -- the user's password Other attributes may be defined later. Only address is required; the others all have defaults (fullname='', digests=0, language=list's preferred language, password=generated). remote is a string which describes where this add request came from. """ assert self.Locked() # Suck values out of userdesc, apply defaults, and reset the userdesc # attributes (for passing on to ApprovedAddMember()). Lowercase the # addr's domain part. email = Utils.LCDomain(userdesc.address) name = getattr(userdesc, 'fullname', '') lang = getattr(userdesc, 'language', self.preferred_language) digest = getattr(userdesc, 'digest', None) password = getattr(userdesc, 'password', Utils.MakeRandomPassword()) if digest is None: if self.nondigestable: digest = 0 else: digest = 1 # Validate the e-mail address to some degree. Utils.ValidateEmail(email) if self.isMember(email): raise Errors.MMAlreadyAMember, email if email.lower() == self.GetListEmail().lower(): # Trying to subscribe the list to itself! raise Errors.MMBadEmailError # Is the subscribing address banned from this list? ban = 0 for pattern in self.ban_list: if pattern.startswith('^'): # This is a regular expression match try: if re.search(pattern, email, re.IGNORECASE): ban = 1 break except re.error: # BAW: we should probably remove this pattern pass else: # Do the comparison case insensitively if pattern.lower() == email.lower(): ban = 1 break if ban: syslog('vette', 'banned subscription: %s (matched: %s)', email, pattern) raise Errors.MembershipIsBanned, pattern # Sanity check the digest flag if digest and not self.digestable: raise Errors.MMCantDigestError elif not digest and not self.nondigestable: raise Errors.MMMustDigestError userdesc.address = email userdesc.fullname = name userdesc.digest = digest userdesc.language = lang userdesc.password = password # Apply the list's subscription policy. 0 means open subscriptions; 1 # means the user must confirm; 2 means the admin must approve; 3 means # the user must confirm and then the admin must approve if self.subscribe_policy == 0: self.ApprovedAddMember(userdesc) elif self.subscribe_policy == 1 or self.subscribe_policy == 3: # User confirmation required. BAW: this should probably just # accept a userdesc instance. cookie = Pending.new(Pending.SUBSCRIPTION, userdesc) # Send the user the confirmation mailback if remote is None: by = remote = '' else: by = ' ' + remote remote = _(' from %(remote)s') recipient = self.GetMemberAdminEmail(email) realname = self.real_name confirmurl = '%s/%s' % (self.GetScriptURL('confirm', absolute=1), cookie) text = Utils.maketext( 'verify.txt', {'email' : email, 'listaddr' : self.GetListEmail(), 'listname' : realname, 'cookie' : cookie, 'requestaddr' : self.GetRequestEmail(), 'remote' : remote, 'listadmin' : self.GetOwnerEmail(), 'confirmurl' : confirmurl, }, lang=lang, mlist=self) msg = Message.UserNotification( recipient, self.GetRequestEmail(), text=text, lang=lang) # BAW: See ChangeMemberAddress() for why we do it this way... del msg['subject'] msg['Subject'] = 'confirm ' + cookie msg['Reply-To'] = self.GetRequestEmail() msg.send(self) who = formataddr((name, email)) syslog('subscribe', '%s: pending %s %s', self.internal_name(), who, by) raise Errors.MMSubscribeNeedsConfirmation else: # Subscription approval is required. Add this entry to the admin # requests database. BAW: this should probably take a userdesc # just like above. self.HoldSubscription(email, name, password, digest, lang) raise Errors.MMNeedApproval, _( 'subscriptions to %(realname)s require moderator approval') def ApprovedAddMember(self, userdesc, ack=None, admin_notif=None, text=''): """Add a member right now. The member's subscription must be approved by what ever policy the list enforces. userdesc is as above in AddMember(). ack is a flag that specifies whether the user should get an acknowledgement of their being subscribed. Default is to use the list's default flag value. admin_notif is a flag that specifies whether the list owner should get an acknowledgement of this subscription. Default is to use the list's default flag value. """ assert self.Locked() # Set up default flag values if ack is None: ack = self.send_welcome_msg if admin_notif is None: admin_notif = self.admin_notify_mchanges # Suck values out of userdesc, and apply defaults. email = Utils.LCDomain(userdesc.address) name = getattr(userdesc, 'fullname', '') lang = getattr(userdesc, 'language', self.preferred_language) digest = getattr(userdesc, 'digest', None) password = getattr(userdesc, 'password', Utils.MakeRandomPassword()) if digest is None: if self.nondigestable: digest = 0 else: digest = 1 # Let's be extra cautious Utils.ValidateEmail(email) if self.isMember(email): raise Errors.MMAlreadyAMember, email # Do the actual addition self.addNewMember(email, realname=name, digest=digest, password=password, language=lang) self.setMemberOption(email, mm_cfg.DisableMime, 1 - self.mime_is_default_digest) self.setMemberOption(email, mm_cfg.Moderate, self.default_member_moderation) # Now send and log results if digest: kind = ' (digest)' else: kind = '' syslog('subscribe', '%s: new%s %s', self.internal_name(), kind, formataddr((email, name))) if ack: self.SendSubscribeAck(email, self.getMemberPassword(email), digest, text) if admin_notif: realname = self.real_name subject = _('%(realname)s subscription notification') text = Utils.maketext( "adminsubscribeack.txt", {"listname" : self.real_name, "member" : formataddr((name, email)), }, mlist=self) msg = Message.OwnerNotification(self, subject, text) msg.send(self) def DeleteMember(self, name, whence=None, admin_notif=0, userack=1): realname, email = parseaddr(name) if self.unsubscribe_policy == 0: self.ApprovedDeleteMember(name, whence, admin_notif, userack) else: self.HoldUnsubscription(email) raise Errors.MMNeedApproval, _( 'unsubscriptions require moderator approval') def ApprovedDeleteMember(self, name, whence=None, admin_notif=None, userack=None): if userack is None: userack = self.send_goodbye_msg if admin_notif is None: admin_notif = self.admin_notify_mchanges # Delete a member, for which we know the approval has been made fullname, emailaddr = parseaddr(name) userlang = self.getMemberLanguage(emailaddr) # Remove the member self.removeMember(emailaddr) # And send an acknowledgement to the user... if userack: self.SendUnsubscribeAck(emailaddr, userlang) # ...and to the administrator if admin_notif: realname = self.real_name subject = _('%(realname)s unsubscribe notification') text = Utils.maketext( 'adminunsubscribeack.txt', {'member' : name, 'listname': self.real_name, }, mlist=self) msg = Message.OwnerNotification(self, subject, text) msg.send(self) if whence: whence = "; %s" % whence else: whence = "" syslog('subscribe', '%s: deleted %s%s', self.internal_name(), name, whence) def ChangeMemberName(self, addr, name, globally): self.setMemberName(addr, name) if not globally: return for listname in Utils.list_names(): # Don't bother with ourselves if listname == self.internal_name(): continue mlist = MailList(listname, lock=0) if mlist.host_name <> self.host_name: continue if not mlist.isMember(addr): continue mlist.Lock() try: mlist.setMemberName(addr, name) mlist.Save() finally: mlist.Unlock() def ChangeMemberAddress(self, oldaddr, newaddr, globally): # Changing a member address consists of verifying the new address, # making sure the new address isn't already a member, and optionally # going through the confirmation process. # # Most of these checks are copied from AddMember newaddr = Utils.LCDomain(newaddr) Utils.ValidateEmail(newaddr) # Raise an exception if this email address is already a member of the # list, but only if the new address is the same case-wise as the old # address and we're not doing a global change. if not globally and newaddr == oldaddr and self.isMember(newaddr): raise Errors.MMAlreadyAMember if newaddr == self.GetListEmail().lower(): raise Errors.MMBadEmailError # Pend the subscription change cookie = Pending.new(Pending.CHANGE_OF_ADDRESS, oldaddr, newaddr, globally) confirmurl = '%s/%s' % (self.GetScriptURL('confirm', absolute=1), cookie) realname = self.real_name lang = self.getMemberLanguage(oldaddr) text = Utils.maketext( 'verify.txt', {'email' : newaddr, 'listaddr' : self.GetListEmail(), 'listname' : realname, 'cookie' : cookie, 'requestaddr': self.GetRequestEmail(), 'remote' : '', 'listadmin' : self.GetOwnerEmail(), 'confirmurl' : confirmurl, }, lang=lang, mlist=self) # BAW: We don't pass the Subject: into the UserNotification # constructor because it will encode it in the charset of the language # being used. For non-us-ascii charsets, this means it will probably # quopri quote it, and thus replies will also be quopri encoded. But # CommandRunner doesn't yet grok such headers. So, just set the # Subject: in a separate step, although we have to delete the one # UserNotification adds. msg = Message.UserNotification( newaddr, self.GetRequestEmail(), text=text, lang=lang) del msg['subject'] msg['Subject'] = 'confirm ' + cookie msg['Reply-To'] = self.GetRequestEmail() msg.send(self) def ApprovedChangeMemberAddress(self, oldaddr, newaddr, globally): self.changeMemberAddress(oldaddr, newaddr) # If globally is true, then we also include every list for which # oldaddr is a member. if not globally: return for listname in Utils.list_names(): # Don't bother with ourselves if listname == self.internal_name(): continue mlist = MailList(listname, lock=0) if mlist.host_name <> self.host_name: continue if not mlist.isMember(oldaddr): continue mlist.Lock() try: mlist.changeMemberAddress(oldaddr, newaddr) mlist.Save() finally: mlist.Unlock() # # Confirmation processing # def ProcessConfirmation(self, cookie, context=None): data = Pending.confirm(cookie) if data is None: raise Errors.MMBadConfirmation, 'data is None' try: op = data[0] data = data[1:] except ValueError: raise Errors.MMBadConfirmation, 'op-less data %s' % (data,) if op == Pending.SUBSCRIPTION: try: userdesc = data[0] # If confirmation comes from the web, context should be a # UserDesc instance which contains overrides of the original # subscription information. If it comes from email, then # context is a Message and isn't relevant, so ignore it. if isinstance(context, UserDesc): userdesc += context addr = userdesc.address fullname = userdesc.fullname password = userdesc.password digest = userdesc.digest lang = userdesc.language except ValueError: raise Errors.MMBadConfirmation, 'bad subscr data %s' % (data,) # Hack alert! Was this a confirmation of an invitation? invitation = getattr(userdesc, 'invitation', 0) # We check for both 2 (approval required) and 3 (confirm + # approval) because the policy could have been changed in the # middle of the confirmation dance. if not invitation and self.subscribe_policy in (2, 3): self.HoldSubscription(addr, fullname, password, digest, lang) name = self.real_name raise Errors.MMNeedApproval, _( 'subscriptions to %(name)s require administrator approval') self.ApprovedAddMember(userdesc) return op, addr, password, digest, lang elif op == Pending.UNSUBSCRIPTION: addr = data[0] # Log file messages don't need to be i18n'd if isinstance(context, Message.Message): whence = 'email confirmation' else: whence = 'web confirmation' # Can raise NotAMemberError if they unsub'd via other means self.ApprovedDeleteMember(addr, whence=whence) return op, addr elif op == Pending.CHANGE_OF_ADDRESS: oldaddr, newaddr, globally = data self.ApprovedChangeMemberAddress(oldaddr, newaddr, globally) return op, oldaddr, newaddr elif op == Pending.HELD_MESSAGE: id = data[0] approved = None # Confirmation should be coming from email, where context should # be the confirming message. If the message does not have an # Approved: header, this is a discard, otherwise it's an approval # (if the passwords match). if isinstance(context, Message.Message): # See if it's got an Approved: header, either in the headers, # or in the first text/plain section of the response. For # robustness, we'll accept Approve: as well. approved = context.get('Approved', context.get('Approve')) if not approved: try: subpart = list(email.Iterators.typed_subpart_iterator( context, 'text', 'plain'))[0] except IndexError: subpart = None if subpart: s = StringIO(subpart.get_payload()) while 1: line = s.readline() if not line: break if not line.strip(): continue i = line.find(':') if i > 0: if (line[:i].lower() == 'approve' or line[:i].lower() == 'approved'): # then approved = line[i+1:].strip() break # Okay, does the approved header match the list password? if approved and self.Authenticate([mm_cfg.AuthListAdmin, mm_cfg.AuthListModerator], approved) <> mm_cfg.UnAuthorized: action = mm_cfg.APPROVE else: action = mm_cfg.DISCARD try: self.HandleRequest(id, action) except KeyError: # Most likely because the message has already been disposed of # via the admindb page. syslog('error', 'Could not process HELD_MESSAGE: %s', id) return (op,) elif op == Pending.RE_ENABLE: member = data[1] self.setDeliveryStatus(member, MemberAdaptor.ENABLED) return op, member def ConfirmUnsubscription(self, addr, lang=None, remote=None): if lang is None: lang = self.getMemberLanguage(addr) cookie = Pending.new(Pending.UNSUBSCRIPTION, addr) confirmurl = '%s/%s' % (self.GetScriptURL('confirm', absolute=1), cookie) realname = self.real_name if remote is not None: by = " " + remote remote = _(" from %(remote)s") else: by = "" remote = "" text = Utils.maketext( 'unsub.txt', {'email' : addr, 'listaddr' : self.GetListEmail(), 'listname' : realname, 'cookie' : cookie, 'requestaddr' : self.GetRequestEmail(), 'remote' : remote, 'listadmin' : self.GetOwnerEmail(), 'confirmurl' : confirmurl, }, lang=lang, mlist=self) msg = Message.UserNotification( addr, self.GetRequestEmail(), text=text, lang=lang) # BAW: See ChangeMemberAddress() for why we do it this way... del msg['subject'] msg['Subject'] = 'confirm ' + cookie msg['Reply-To'] = self.GetRequestEmail() msg.send(self) # # Miscellaneous stuff # def HasExplicitDest(self, msg): """True if list name or any acceptable_alias is included among the to or cc addrs.""" # BAW: fall back to Utils.ParseAddr if the first test fails. # this is the list's full address listfullname = '%s@%s' % (self.internal_name(), self.host_name) recips = [] # check all recipient addresses against the list's explicit addresses, # specifically To: Cc: and Resent-to: to = [] for header in ('to', 'cc', 'resent-to', 'resent-cc'): to.extend(getaddresses(msg.get_all(header, []))) for fullname, addr in to: # It's possible that if the header doesn't have a valid # (i.e. RFC822) value, we'll get None for the address. So skip # it. if addr is None: continue addr = addr.lower() localpart = addr.split('@')[0] if (# TBD: backwards compatibility: deprecated localpart == self.internal_name() or # exact match against the complete list address addr == listfullname): return 1 recips.append((addr, localpart)) # # helper function used to match a pattern against an address. Do it def domatch(pattern, addr): try: if re.match(pattern, addr): return 1 except re.error: # The pattern is a malformed regexp -- try matching safely, # with all non-alphanumerics backslashed: if re.match(re.escape(pattern), addr): return 1 # # Here's the current algorithm for matching acceptable_aliases: # # 1. If the pattern does not have an `@' in it, we first try matching # it against just the localpart. This was the behavior prior to # 2.0beta3, and is kept for backwards compatibility. # (deprecated). # # 2. If that match fails, or the pattern does have an `@' in it, we # try matching against the entire recip address. for addr, localpart in recips: for alias in self.acceptable_aliases.split('\n'): stripped = alias.strip() if not stripped: # ignore blank or empty lines continue if '@' not in stripped and domatch(stripped, localpart): return 1 if domatch(stripped, addr): return 1 return 0 def parse_matching_header_opt(self): """Return a list of triples [(field name, regex, line), ...].""" # - Blank lines and lines with '#' as first char are skipped. # - Leading whitespace in the matchexp is trimmed - you can defeat # that by, eg, containing it in gratuitous square brackets. all = [] for line in self.bounce_matching_headers.split('\n'): line = line.strip() # Skip blank lines and lines *starting* with a '#'. if not line or line[0] == "#": continue i = line.find(':') if i < 0: # This didn't look like a header line. BAW: should do a # better job of informing the list admin. syslog('config', 'bad bounce_matching_header line: %s\n%s', self.real_name, line) else: header = line[:i] value = line[i+1:].lstrip() try: cre = re.compile(value, re.IGNORECASE) except re.error, e: # The regexp was malformed. BAW: should do a better # job of informing the list admin. syslog('config', '''\ bad regexp in bounce_matching_header line: %s \n%s (cause: %s)''', self.real_name, value, e) else: all.append((header, cre, line)) return all def hasMatchingHeader(self, msg): """Return true if named header field matches a regexp in the bounce_matching_header list variable. Returns constraint line which matches or empty string for no matches. """ for header, cre, line in self.parse_matching_header_opt(): for value in msg.get_all(header, []): if cre.search(value): return line return 0 def autorespondToSender(self, sender): """Return true if Mailman should auto-respond to this sender. This is only consulted for messages sent to the -request address, or for posting hold notifications, and serves only as a safety value for mail loops with email 'bots. """ # No limit if mm_cfg.MAX_AUTORESPONSES_PER_DAY == 0: return 1 today = time.localtime()[:3] info = self.hold_and_cmd_autoresponses.get(sender) if info is None or info[0] <> today: # First time we've seen a -request/post-hold for this sender self.hold_and_cmd_autoresponses[sender] = (today, 1) # BAW: no check for MAX_AUTORESPONSES_PER_DAY <= 1 return 1 date, count = info if count < 0: # They've already hit the limit for today. syslog('vette', '-request/hold autoresponse discarded for: %s', sender) return 0 if count >= mm_cfg.MAX_AUTORESPONSES_PER_DAY: syslog('vette', '-request/hold autoresponse limit hit for: %s', sender) self.hold_and_cmd_autoresponses[sender] = (today, -1) # Send this notification message instead text = Utils.maketext( 'nomoretoday.txt', {'sender' : sender, 'listname': '%s@%s' % (self.real_name, self.host_name), 'num' : count, 'owneremail': self.GetOwnerEmail(), }) msg = Message.UserNotification( sender, self.GetOwnerEmail(), _('Last autoresponse notification for today'), text) msg.send(self) return 0 self.hold_and_cmd_autoresponses[sender] = (today, count+1) return 1 # # Multilingual (i18n) support # def GetAvailableLanguages(self): langs = self.available_languages # If we don't add this, and the site admin has never added any # language support to the list, then the general admin page may have a # blank field where the list owner is supposed to chose the list's # preferred language. if mm_cfg.DEFAULT_SERVER_LANGUAGE not in langs: langs.append(mm_cfg.DEFAULT_SERVER_LANGUAGE) return langs From a.carter at cordis.lu Mon Apr 7 15:02:04 2003 From: a.carter at cordis.lu (CARTER Anthony) Date: Mon Apr 7 17:18:02 2003 Subject: [Mailman-Developers] Info Message-ID: <200304071402.04598.a.carter@intrasoft.lu> If I make changes to the templates, how can I get them to be re-read by mailman to display correctly? Do I need to run a particular command or does Mailman create HTML files being served by Apache on the fly? Thanks, Anthony From barry at python.org Tue Apr 8 04:14:20 2003 From: barry at python.org (Barry Warsaw) Date: Mon Apr 7 23:14:22 2003 Subject: [Mailman-Developers] configure/build/packaging problems In-Reply-To: <1049746563.1214.105.camel@finch.boston.redhat.com> References: <1049746563.1214.105.camel@finch.boston.redhat.com> Message-ID: <1049768076.11801.30.camel@geddy> On Mon, 2003-04-07 at 16:16, John Dennis wrote: > I picked up responsibility for the mailman rpm here at Red Hat a little > while ago, just about the time of the 2.1 release. As a consequence I > don't have a history with the prior releases, but I seem to have run > into some build and packaging problems that I think were introduced in > 2.1 and then carried over into 2.1.1. Hi John. Say, were you at PyCon a while back? I don't remember if I met you there or not. > I believe as of 2.1 it became a requirement that the mailman user and > group exist before the configure script is run. As far as I can tell > this is because the configure script looks up user ids and/or user > names in the system passwd database when its building its set of > substitution strings for the .in files. Yes, but there is a --without-permcheck option to configure that will bypass the check. In 2.1.1 you'll get a traceback from the configure script, which I think you can ignore. I'm about to check in a fix for that which should be part of 2.1.2. > 1) At the heart of the mailman build philosophy seems to be the notion > that mailman will (must?) be built on the target system. Traditionally this has been true, yes. I would definitely be willing to make Mailman easier to package, as long as we can continue to ensure adequate security. > I > assume the approach of requiring the package to build on the target > was a deliberate choice for some reason. If so what was the reason? Much of the build process is historical. It works for me but I won't claim it's optimal. > If there isn't a compelling reason for the approach are you open to > receiving patches that make the configure/build step friendly to > packaging requirements or does this violate some principle mailman is > trying to maintain? Sure. > 2) I've noticed that some of the checks and lookups done in configure > can be controlled with with-permcheck & without-permcheck. But not all > the lookups are under the control of this variable. My initial > thoughts were to have ALL the local lookups under the control of this > variable, if without-permcheck is set then NO local lookups during > configure/build are performed, configuration values are used as > supplied. Does this sound reasonable? Is this overloading this > variable with meaning that was not intended? Which checks did you have in mind specifically? Mailman 2.1 encodes symbolic user and group names now, so as long as mailman:mailman exists on the target system (which I hope you agree is not unreasonable), everything should still work. The intent was definitely to have --without-permcheck support packagers building on systems without that group and user. > 3) I've also run into problems where the .py files cannot be compiled > into .pyc files on build system during the build. > but it > seems like we have to get rid of the hardcoded pathnames in paths.py > and if someone has a suggestion I'd be curious to hear. I'd really > like to be able to compile the python files during build before > producing the installation package. That's going to be a problem too, because you're in a catch-22. The whole point of the paths.py files is to add hardcoded paths to sys.path so all the other modules can be found. I can't really think of any other way of doing it. Here's a suggestion though: you already /know/ what .pyc files will exist on the target machine after the compilation phase is complete, so can you add those to the rpm's list of files it knows about anyway? Then the post-install phase can do the compileall to build the pycs. You definitely don't want to leave things to lazy byte compilation. I'm up for any other suggestions you might have to make 2.1 easier to package. I'm also up for any longer term (read: more disruptive ;) changes that might be appropriate for a 2.2 or 3.0 release. I'm leaning strongly toward adopting some of the Zope3 build mechanisms (i.e. largely setup.py based). -Barry From barry at python.org Tue Apr 8 04:28:44 2003 From: barry at python.org (Barry Warsaw) Date: Mon Apr 7 23:28:46 2003 Subject: [Mailman-Developers] plaintext digest & message headers... bug? In-Reply-To: <3E91D345.5060500@rixhq.nu> References: <3E8C83E2.70401@rixhq.nu> <1049609731.6665.66.camel@geddy> <3E91D345.5060500@rixhq.nu> Message-ID: <1049768943.11801.32.camel@geddy> On Mon, 2003-04-07 at 15:36, Ricardo Kustner wrote: > I saw you fixed the bug (thanks for that! :))... could you eloborate on > what was wrong? maybe I can fix it in my own installation without having > to revert to running the cvs version... IIRC Mailman was just ignoring the KKEP variable to calculate some of the digest headers. You can always wait for 2.1.2 which will be released RSN . -Barry From barry at python.org Tue Apr 8 04:29:45 2003 From: barry at python.org (Barry Warsaw) Date: Mon Apr 7 23:29:46 2003 Subject: [Mailman-Developers] still having admin cookie problem In-Reply-To: <20030407154042.GD12601@mrbill.net> References: <20030329215515.GN13285@mrbill.net> <1049612729.6665.106.camel@geddy> <20030407154042.GD12601@mrbill.net> Message-ID: <1049769003.11767.34.camel@geddy> On Mon, 2003-04-07 at 11:40, Bill Bradford wrote: > On Sun, Apr 06, 2003 at 04:27:05PM -0400, Barry Warsaw wrote: > > Unfortunately, no. Maybe a browser problem? Are you proxying anywhere > > in the http trail? > > Nope - tried multiple browsers (Mozilla, Safari, Camino, Opera) on multiple > platforms (OS X, Solaris, Windows) and I still have it. No proxies anywhere; > straight HTTP connections. Has anyone else noticed any cookie problems? I've definitely interacted with 2.0 and 2.1 lists using a similar mix of browsers (Linux and MacOSX). I've not seen problems since installing the patch. -Barry From barry at python.org Tue Apr 8 04:31:10 2003 From: barry at python.org (Barry Warsaw) Date: Mon Apr 7 23:31:12 2003 Subject: [Mailman-Developers] Info In-Reply-To: <200304071402.04598.a.carter@intrasoft.lu> References: <200304071402.04598.a.carter@intrasoft.lu> Message-ID: <1049769088.11801.36.camel@geddy> On Mon, 2003-04-07 at 08:02, CARTER Anthony wrote: > If I make changes to the templates, how can I get them to be re-read by > mailman to display correctly? Do I need to run a particular command or does > Mailman create HTML files being served by Apache on the fly? Because the cgi's are one-shot processes, your changes should be visible on the next web hit. -Barry From carson at taltos.org Tue Apr 8 09:10:40 2003 From: carson at taltos.org (Carson Gaspar) Date: Tue Apr 8 08:10:44 2003 Subject: [Mailman-Developers] Password reminder envelope source address strangeness In-Reply-To: <1049612651.6665.104.camel@geddy> References: <1836002500.1049259292@[192.168.20.2]> <1049612651.6665.104.camel@geddy> Message-ID: <441401859.1049789440@[192.168.20.2]> --On Sunday, April 06, 2003 4:27 PM -0400 Barry Warsaw wrote: > On Wed, 2003-04-02 at 04:54, Carson Gaspar wrote: >> It appears that my lists' password reminders are being sent from a now >> bogus (but previously valid) envelope from address. I can't seem to > > The password reminders come from the site list, so maybe something's > screwed up with its configuation? That was it. Thanks, Barry! -- Carson From mrbill at mrbill.net Tue Apr 8 10:40:08 2003 From: mrbill at mrbill.net (Bill Bradford) Date: Tue Apr 8 10:40:30 2003 Subject: [Mailman-Developers] still having admin cookie problem In-Reply-To: <1049769003.11767.34.camel@geddy> References: <20030329215515.GN13285@mrbill.net> <1049612729.6665.106.camel@geddy> <20030407154042.GD12601@mrbill.net> <1049769003.11767.34.camel@geddy> Message-ID: <20030408144008.GN12601@mrbill.net> On Mon, Apr 07, 2003 at 10:30:03PM -0400, Barry Warsaw wrote: > Has anyone else noticed any cookie problems? I've definitely interacted > with 2.0 and 2.1 lists using a similar mix of browsers (Linux and > MacOSX). I've not seen problems since installing the patch. Has there been a patch post-2.1.1? Bill -- bill bradford mrbill@mrbill.net austin, texas From barry at python.org Tue Apr 8 15:53:05 2003 From: barry at python.org (Barry Warsaw) Date: Tue Apr 8 10:53:06 2003 Subject: [Mailman-Developers] still having admin cookie problem In-Reply-To: <20030408144008.GN12601@mrbill.net> References: <20030329215515.GN13285@mrbill.net> <1049612729.6665.106.camel@geddy> <20030407154042.GD12601@mrbill.net> <1049769003.11767.34.camel@geddy> <20030408144008.GN12601@mrbill.net> Message-ID: <1049813765.10233.12.camel@barry> On Tue, 2003-04-08 at 10:40, Bill Bradford wrote: > On Mon, Apr 07, 2003 at 10:30:03PM -0400, Barry Warsaw wrote: > > Has anyone else noticed any cookie problems? I've definitely interacted > > with 2.0 and 2.1 lists using a similar mix of browsers (Linux and > > MacOSX). I've not seen problems since installing the patch. > > Has there been a patch post-2.1.1? No, I don't think so. -Barry From yfeng at whittier.edu Tue Apr 8 12:32:20 2003 From: yfeng at whittier.edu (Feng Jeffrey) Date: Tue Apr 8 15:49:43 2003 Subject: [Mailman-Developers] Digest delivery scheduling Message-ID: Hi Guys, How can I set the time that the digest will be sent on Mailman? For example, I'd like to have the digests for all lists to be delivered at 6:00 AM everyday. Any help will be appreciated. Jeffrey Feng Whittier College From barry at python.org Wed Apr 9 05:30:10 2003 From: barry at python.org (Barry Warsaw) Date: Wed Apr 9 00:30:11 2003 Subject: [Mailman-Developers] Digest delivery scheduling In-Reply-To: References: Message-ID: <1049859029.22099.15.camel@geddy> On Tue, 2003-04-08 at 14:32, Feng Jeffrey wrote: > How can I set the time that the digest will be sent on Mailman? For example, > I'd like to have the digests for all lists to be delivered at 6:00 AM > everyday. You can change the time the script is run in the cron entry. -Barry From terri at zone12.com Wed Apr 9 02:13:16 2003 From: terri at zone12.com (Terri Oda) Date: Wed Apr 9 01:05:01 2003 Subject: [Mailman-Developers] Digest delivery scheduling In-Reply-To: References: Message-ID: <20030409051316.GJ1226@ostraya.zone12.com> > How can I set the time that the digest will be sent on Mailman? For example, > I'd like to have the digests for all lists to be delivered at 6:00 AM > everyday. You change the crontab entry to something like this: # 6am, mail digests for lists that do periodic as well as threshhold delivery. 0 6 * * * /usr/bin/python -S /home/mailman/cron/senddigests Terri From tkikuchi at is.kochi-u.ac.jp Wed Apr 9 15:24:31 2003 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Wed Apr 9 01:24:37 2003 Subject: [Mailman-Developers] patch verification Message-ID: <3E93AE8F.2030900@is.kochi-u.ac.jp> Hi Developers, Can anyone verify this patch ? https://sourceforge.net/tracker/?func=detail&atid=300103&aid=694902&group_id=103 Without this patch, MIME digest message will be delivered with links to the saved attachments. With this, the attached file is included in the delivered digest mail. I think MIME digest should be delivered latter way and this patch should be included in the next release. A person who applied this patch claims that this caused every message to be shunted. So, I want to know if this patch is useful or not. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From mch at cix.compulink.co.uk Wed Apr 9 14:54:00 2003 From: mch at cix.compulink.co.uk (Mike Holderness) Date: Wed Apr 9 08:54:16 2003 Subject: [Mailman-Developers] Mailman web interfaces and design Message-ID: In-Reply-To: CARTER Anthony wrote: > > I am looking for a means of customizing the mailman we pages. I have > noticed that some pages can be edited via the interface, but I would > like to make more drastic changes (removing links to admin page for > example). > > My first thing that I would like to do is, if possible, to add our own > CSSs to the web pages. Does anyone know if this is possible, and if so, > where do I start? Yes. You can put any HTML at all in there, so long as you use the <MM-thing-name> tags correctly. Take a look at www.londonfreelance.org/indynet for an example - which not only uses a style sheet but also ECMA scripting - strongly encouraging people to introduce themselves to the list and proofreading their email before hitting the server for example. If cordis wants to licen{c|s}e the error-checking code I expect I'll discount it for the usefulness of your service :-) Now, to everyone else... where do I get to play with the templates for the archives? I know they're in there somewhere, because of internationali{s|z}ation discussions here. I'm using MM running on an ISP's machine, so I can't just grep for them... Mike Holderness From terri at zone12.com Wed Apr 9 12:10:38 2003 From: terri at zone12.com (Terri Oda) Date: Wed Apr 9 11:02:28 2003 Subject: [Mailman-Developers] Mailman web interfaces and design In-Reply-To: References: Message-ID: <20030409151037.GB663@ostraya.zone12.com> > Now, to everyone else... where do I get to play with the > templates for the archives? I know they're in there > somewhere, because of internationali{s|z}ation > discussions here. I'm using MM running on an ISP's > machine, so I can't just grep for them... The templates are in, unsuprisingly, the $MAILMAN/templates directory, under the appropriate languages. I don't know how they get handled from there, though, so I don't know if you need to do anything special to edit them and have the changes actually appear. Terri From a.carter at cordis.lu Wed Apr 9 18:14:10 2003 From: a.carter at cordis.lu (CARTER Anthony) Date: Wed Apr 9 11:14:33 2003 Subject: [Mailman-Developers] Mailman web interfaces and design In-Reply-To: <20030409151037.GB663@ostraya.zone12.com> References: <20030409151037.GB663@ostraya.zone12.com> Message-ID: <200304091714.10234.a.carter@intrasoft.lu> Hi, I know that there are templates, and I have defined the tag, but for some of those templates it doesn't get translated...It is the bit that you don't know that really interests me ;) Anthony On Wednesday 09 April 2003 17:10, Terri Oda wrote: > > Now, to everyone else... where do I get to play with the > > templates for the archives? I know they're in there > > somewhere, because of internationali{s|z}ation > > discussions here. I'm using MM running on an ISP's > > machine, so I can't just grep for them... > > The templates are in, unsuprisingly, the $MAILMAN/templates directory, > under the appropriate languages. > > I don't know how they get handled from there, though, so I don't know if > you need to do anything special to edit them and have the changes actually > appear. > > Terri > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From stone at hkust.se Wed Apr 9 19:04:24 2003 From: stone at hkust.se (Magnus Stenman) Date: Wed Apr 9 12:05:36 2003 Subject: [Mailman-Developers] Mailman web interfaces and design References: <20030409151037.GB663@ostraya.zone12.com> <200304091714.10234.a.carter@intrasoft.lu> Message-ID: <3E944488.D6DA4055@hkust.se> have a look at the latest stylesheet patch, it should hopefully stylesheetize the archives also. http://sourceforge.net/tracker/index.php?func=detail&aid=687704&group_id=103&atid=300103 note that you have to recreate the archives, e.g. $mmbasedir/bin/arch listname /magnus CARTER Anthony wrote: > > Hi, > > I know that there are templates, and I have defined the tag, > but for some of those templates it doesn't get translated...It is the bit > that you don't know that really interests me ;) > > Anthony > > On Wednesday 09 April 2003 17:10, Terri Oda wrote: > > > Now, to everyone else... where do I get to play with the > > > templates for the archives? I know they're in there > > > somewhere, because of internationali{s|z}ation > > > discussions here. I'm using MM running on an ISP's > > > machine, so I can't just grep for them... > > > > The templates are in, unsuprisingly, the $MAILMAN/templates directory, > > under the appropriate languages. > > > > I don't know how they get handled from there, though, so I don't know if > > you need to do anything special to edit them and have the changes actually > > appear. > > > > Terri > > > > _______________________________________________ > > Mailman-Developers mailing list > > Mailman-Developers@python.org > > http://mail.python.org/mailman/listinfo/mailman-developers > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From a.carter at cordis.lu Thu Apr 10 14:41:28 2003 From: a.carter at cordis.lu (CARTER Anthony) Date: Thu Apr 10 07:41:44 2003 Subject: [Mailman-Developers] Mailman web interfaces and design In-Reply-To: <200304091714.10234.a.carter@intrasoft.lu> References: <20030409151037.GB663@ostraya.zone12.com> <200304091714.10234.a.carter@intrasoft.lu> Message-ID: <200304101341.28501.a.carter@intrasoft.lu> For a reduced fee I can send you the code to add CSS stylesheet support to the archives... :D Or... You could check out the sourceforge project patch section for snugge's recent update (its a diff file)... Anthony On Wednesday 09 April 2003 17:14, CARTER Anthony wrote: > Hi, > > I know that there are templates, and I have defined the > tag, but for some of those templates it doesn't get translated...It is the > bit that you don't know that really interests me ;) > > Anthony > > On Wednesday 09 April 2003 17:10, Terri Oda wrote: > > > Now, to everyone else... where do I get to play with the > > > templates for the archives? I know they're in there > > > somewhere, because of internationali{s|z}ation > > > discussions here. I'm using MM running on an ISP's > > > machine, so I can't just grep for them... > > > > The templates are in, unsuprisingly, the $MAILMAN/templates directory, > > under the appropriate languages. > > > > I don't know how they get handled from there, though, so I don't know if > > you need to do anything special to edit them and have the changes > > actually appear. > > > > Terri > > > > _______________________________________________ > > Mailman-Developers mailing list > > Mailman-Developers@python.org > > http://mail.python.org/mailman/listinfo/mailman-developers > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From mch at cix.compulink.co.uk Thu Apr 10 18:46:00 2003 From: mch at cix.compulink.co.uk (Mike Holderness) Date: Thu Apr 10 12:46:55 2003 Subject: [Mailman-Developers] Mailman web interfaces and design Message-ID: In-Reply-To: Anthony wrote: > > I know that there are templates, and I have defined the > > tag, but for some of those templates it doesn't get translated...It > is the bit that you don't know that really interests me ;) Ah. Didn't know about the tag... as you may have seen, I used a fully-qualified URL for the stylesheet. That saved me worrying about the path to the stylesheet... which, I *guess*, may be your problem... It would be, er, elegant, to make the default templates point to a stylesheet in the list's own directory, and supply a default stylesheet? No? Mike From jeffh at gryphongardens.com Thu Apr 10 13:26:56 2003 From: jeffh at gryphongardens.com (Jeff Hahn) Date: Thu Apr 10 13:28:17 2003 Subject: [Mailman-Developers] blankety-blank AOL bounces (not accepting mail from...) Message-ID: <000d01c2ff86$62bfe940$14cca8c0@internal.gryphongardens.com> Mailman 2.1.1 Apparently AOL has a "feature" that you can use to bounce email from certain senders. See example below. Aoluser123 (email address aoluser123@aol.com) is not accepting mail from jkl@gryphongardens.com who has posted to list abc@gryphongardens.com in this example. On verped deliveries, this bounce is counted as a bounce for aoluser123@aol.com On non-verped deliveries, this bounce is returned to list-owner as unrecognized. While I like the idea of having the aol user bounce off, it's probably not the correct answer. Probably all of these bounces (verped and non-verped) should be silently discarded. I guess this is a feature request/bug report. Thanks for a great product! -Jeff example bounce------------------------------------------------------------ Received: from omr-d07.mx.aol.com ([205.188.159.13]) by abc.gryphongardens.com with esmtp (Exim 3.36 #1 (Debian)) id 193ep8-0006yg-00 for ; Thu, 10 Apr 2003 11:22:50 -0500 Received: from air-xb01.mail.aol.com (air-xb01.mail.aol.com [172.20.105.97])by omr-d07.mx.aol.com (v90_r2.6) with ESMTP id RELAYIN9-0410122200; Thu, 10 Apr 2003 12:22:00 -0500 from: Mail Delivery Subsystem Date: Thu, 10 Apr 2003 12:17:56 EDT To: Subject: Mail Delivery Problem Mailer: AIRmail [v92.17] Message-ID: <200304101222.09MwPKKa18178@omr-d07.mx.aol.com> Your mail to the following recipients could not be delivered because they are not accepting mail from jkl@gryphongardens.com: Aoluser123 From chuqui at plaidworks.com Thu Apr 10 11:32:31 2003 From: chuqui at plaidworks.com (Chuq Von Rospach) Date: Thu Apr 10 13:32:39 2003 Subject: [Mailman-Developers] blankety-blank AOL bounces (not accepting mail from...) In-Reply-To: <000d01c2ff86$62bfe940$14cca8c0@internal.gryphongardens.com> Message-ID: <68C59B94-6B7A-11D7-96CD-0003934516A8@plaidworks.com> On Thursday, April 10, 2003, at 10:26 AM, Jeff Hahn wrote: > Mailman 2.1.1 > > Apparently AOL has a "feature" that you can use to bounce email from > certain > senders. See example below. Aoluser123 (email address > aoluser123@aol.com) > is not accepting mail from jkl@gryphongardens.com who has posted to > list > abc@gryphongardens.com in this example. > > On verped deliveries, this bounce is counted as a bounce for > aoluser123@aol.com > > On non-verped deliveries, this bounce is returned to list-owner as > unrecognized. I use verped delivery (with sendmail) and my mailman sees them as bounces. > > While I like the idea of having the aol user bounce off, it's probably > not > the correct answer. Probably all of these bounces (verped and > non-verped) > should be silently discarded. > > I guess this is a feature request/bug report. > I tell my AOL users that when they subscribe to a list, they agree to accept mail from the list. If they start generating bounces, they're going to get unsubscribed. I see this as a feature. AOL is basically broken. I don't see any reason to work around AOL's bugs in mailman. From chuqui at plaidworks.com Thu Apr 10 11:32:31 2003 From: chuqui at plaidworks.com (Chuq Von Rospach) Date: Thu Apr 10 13:53:48 2003 Subject: [Mailman-Developers] blankety-blank AOL bounces (not accepting mail from...) In-Reply-To: <000d01c2ff86$62bfe940$14cca8c0@internal.gryphongardens.com> Message-ID: <68C59B94-6B7A-11D7-96CD-0003934516A8@plaidworks.com> On Thursday, April 10, 2003, at 10:26 AM, Jeff Hahn wrote: > Mailman 2.1.1 > > Apparently AOL has a "feature" that you can use to bounce email from > certain > senders. See example below. Aoluser123 (email address > aoluser123@aol.com) > is not accepting mail from jkl@gryphongardens.com who has posted to > list > abc@gryphongardens.com in this example. > > On verped deliveries, this bounce is counted as a bounce for > aoluser123@aol.com > > On non-verped deliveries, this bounce is returned to list-owner as > unrecognized. I use verped delivery (with sendmail) and my mailman sees them as bounces. > > While I like the idea of having the aol user bounce off, it's probably > not > the correct answer. Probably all of these bounces (verped and > non-verped) > should be silently discarded. > > I guess this is a feature request/bug report. > I tell my AOL users that when they subscribe to a list, they agree to accept mail from the list. If they start generating bounces, they're going to get unsubscribed. I see this as a feature. AOL is basically broken. I don't see any reason to work around AOL's bugs in mailman. From jeffh at gryphongardens.com Thu Apr 10 14:09:11 2003 From: jeffh at gryphongardens.com (Jeff Hahn) Date: Thu Apr 10 14:11:05 2003 Subject: [Mailman-Developers] blankety-blank AOL bounces (not accepting mail from...) In-Reply-To: <68C59B94-6B7A-11D7-96CD-0003934516A8@plaidworks.com> Message-ID: <001f01c2ff8c$49b97370$14cca8c0@internal.gryphongardens.com> > > I tell my AOL users that when they subscribe to a list, they agree to > accept mail from the list. If they start generating bounces, they're > going to get unsubscribed. > > I see this as a feature. AOL is basically broken. I don't see any > reason to work around AOL's bugs in mailman. > On a philosophical level, I agree with you completely. On a technical list, I agree with you. On a non-technical list, it's very difficult to enforce. AOL is basically broken. However, AOL is one of the two 600 pound guerillas in this market/arena. If we decide that we're not going to make adjustments to make Mailman work with AOL (no matter who's "fault" it is), Mailman won't get the critical mass of users necessary to survive. AOL IS broken. AOL won't change. Do you want to survive or do you want to be right?? -Jeff From chuqui at plaidworks.com Thu Apr 10 12:18:29 2003 From: chuqui at plaidworks.com (Chuq Von Rospach) Date: Thu Apr 10 14:18:41 2003 Subject: [Mailman-Developers] blankety-blank AOL bounces (not accepting mail from...) In-Reply-To: <001f01c2ff8c$49b97370$14cca8c0@internal.gryphongardens.com> Message-ID: On Thursday, April 10, 2003, at 11:09 AM, Jeff Hahn wrote: > On a philosophical level, I agree with you completely. On a technical > list, > I agree with you. On a non-technical list, it's very difficult to > enforce. many of my lists are non technical. it's simple. someone complains about being unsubscribed, I send them a copy of the bounce and tell them to stop doing it. I do the same when I get spam complaints from AOL for messages posted to lists. they get unsubscribed, they complain, I point out what they did. If they do it twice, they get unsubscribed permanently. > AOL IS broken. AOL won't change. Do you want to survive or do you > want to > be right?? > you haven't read my blog, have you? AOL will change, if it has to to survive. I plan on surviving no matter what. AOL long ago convinced me to stop bending over backwards to make up for its screwups, though. I spend enough time as list admin trying to teach AOL users how to use the tools AOL gives them properly as it is, something I really appreciate. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.plaidworks.com/chuqui/blog/ The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after From stone at hkust.se Fri Apr 11 02:28:30 2003 From: stone at hkust.se (Magnus Stenman) Date: Thu Apr 10 19:28:52 2003 Subject: [Mailman-Developers] Mailman web interfaces and design References: Message-ID: <3E95FE1E.F5EBB555@hkust.se> Mike Holderness wrote: > > In-Reply-To: > Anthony wrote: > > > > I know that there are templates, and I have defined the > > > tag, but for some of those templates it doesn't get translated...It > > is the bit that you don't know that really interests me ;) > > Ah. Didn't know about the tag... as > you may have seen, I used a fully-qualified URL > for the stylesheet. That saved me worrying about > the path to the stylesheet... which, I *guess*, > may be your problem... > > It would be, er, elegant, to make the default > templates point to a stylesheet in the list's own > directory, and supply a default stylesheet? No? The patch adds support for a configurable HREF pointing to wherever you want to place the stylesheet. LINK REL="stylesheet" TYPE="text/css" HREF="**whatever**" it also includes a sample stylesheet. /m > > Mike > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From barry at python.org Fri Apr 11 04:41:35 2003 From: barry at python.org (Barry Warsaw) Date: Thu Apr 10 23:41:36 2003 Subject: [Mailman-Developers] patch verification In-Reply-To: <3E93AE8F.2030900@is.kochi-u.ac.jp> References: <3E93AE8F.2030900@is.kochi-u.ac.jp> Message-ID: <1050032456.3676.25.camel@geddy> On Wed, 2003-04-09 at 01:24, Tokio Kikuchi wrote: > Can anyone verify this patch ? I applied the patch since it seemed right and I can't see any way it causes but reported in the tracker. -Barry From marc_news at merlins.org Fri Apr 11 11:49:21 2003 From: marc_news at merlins.org (Marc MERLIN) Date: Fri Apr 11 13:49:26 2003 Subject: [Mailman-Developers] Cron /usr/bin/python -S /var/local/mailman/cron/disabled Message-ID: <20030411174921.GC16266@merlins.org> This is CVS as of a few days ago. Any ideas? ----- Forwarded message from Cron Daemon ----- From: root@svlug.org (Cron Daemon) To: mailman@svlug.org Traceback (most recent call last): File "/var/local/mailman/cron/disabled", line 209, in ? main() File "/var/local/mailman/cron/disabled", line 201, in main mlist.sendNextNotification(member) File "/var/local/mailman/Mailman/Bouncer.py", line 212, in sendNextNotification Pending.confirm(info.cookie) File "/var/local/mailman/Mailman/Pending.py", line 133, in confirm db = _load() File "/var/local/mailman/Mailman/Pending.py", line 163, in _load return cPickle.load(fp) EOFError ----- End forwarded message ----- -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From davidb at pins.net Wed Apr 9 16:05:02 2003 From: davidb at pins.net (David Birnbaum) Date: Sat Apr 12 10:23:47 2003 Subject: [Mailman-Developers] notify disabled not working; bad subscribed address problem Message-ID: Howdy, As near as I can tell, the bounce_notify_owner_on_disable option is not working. At the moment, even though it is set to "yes" for lists, no notifications are being sent. Unsubscribe notifications are being sent, however. I have double checked the list option, and switched the options around, to no avail. This was a conversion from 2.0 to 2.1.1 (what I'm currently running) in case that makes any difference. Problem No. 2, had to do with a e-mail address that somehow got subscribed with a non-ASCII character and it. I cannot delete the address, either on the web site or any other way, as best as I can tell. list_members breaks: prompt% list_members thebody [ names up to hm... ] Traceback (most recent call last): File "list_members", line 232, in ? main() File "list_members", line 207, in main s = formataddr((name, addr)).encode(enc, 'replace') UnicodeError: ASCII decoding error: ordinal not in range(128) Any python gurus who can suggest a simple fix to at least get the entire list enumerated? I suppose I don't really need to unsubscribe the bad address as long as I can list everything. Otherwise, 2.1.1 has been functioning flawlessly. Bounce detection is much better, as well. Thanks in advance, David. From davidb at pins.net Wed Apr 9 16:30:11 2003 From: davidb at pins.net (David Birnbaum) Date: Sat Apr 12 10:23:49 2003 Subject: [Mailman-Developers] Re: notify disabled not working; bad subscribed address problem In-Reply-To: References: Message-ID: I should clarify - notifications to the USER are working, just not notifications to the owner. David. ----- On Wed, 9 Apr 2003, David Birnbaum wrote: > Howdy, > > As near as I can tell, the bounce_notify_owner_on_disable option is not > working. At the moment, even though it is set to "yes" for lists, no > notifications are being sent. Unsubscribe notifications are being sent, > however. > > I have double checked the list option, and switched the options around, to > no avail. This was a conversion from 2.0 to 2.1.1 (what I'm currently > running) in case that makes any difference. > > Problem No. 2, had to do with a e-mail address that somehow got subscribed > with a non-ASCII character and it. I cannot delete the address, either on > the web site or any other way, as best as I can tell. list_members > breaks: > > prompt% list_members thebody > [ names up to hm... ] > Traceback (most recent call last): > File "list_members", line 232, in ? > main() > File "list_members", line 207, in main > s = formataddr((name, addr)).encode(enc, 'replace') > UnicodeError: ASCII decoding error: ordinal not in range(128) > > Any python gurus who can suggest a simple fix to at least get the entire > list enumerated? I suppose I don't really need to unsubscribe the bad > address as long as I can list everything. > > Otherwise, 2.1.1 has been functioning flawlessly. Bounce detection is > much better, as well. > > Thanks in advance, > > David. > From mailman at lanoffice.ru Fri Apr 11 12:46:39 2003 From: mailman at lanoffice.ru (mailman) Date: Sat Apr 12 10:23:51 2003 Subject: [Mailman-Developers] Strange Subject: handling Message-ID: <3E9672DF.5010506@lanoffice.ru> Good day! I've started to use Mailman in my production environment. I am impressed of its huge number of features ! Thank You for your job. But I have discovered a bug (or I missed something in mailman tuning). When a message with certain Subject: arrived to list from one of subscribers, the message silently dies and nobody receives any warnings. If I changed only Subject field of the message - then the message had passed happily. Moreover, if I've changed only encoding of a message (from windows-1251 to koi8-r) the message passed again! The Subject: is a Russian text encoded in the following styles: The 'Subject:' of the messages which had beed killed: Outlook Express: X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Subject: =?windows-1251?B?IC0tIEVneXB0IC0tINHz8u737fvlIPbl7fsgIzE3IO7yIDEwLjA0Lg==?= =?windows-1251?B?MjAwMw==?= Mozilla: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ru-RU; rv:1.3) Gecko/20030312 Subject: -- Egypt -- =?windows-1251?Q?=D1=F3=F2=EE=F7=ED=FB=E5_=F6=E5=ED?= =?windows-1251?Q?=FB_=2317_=EE=F2_10=2E04=2E2003?= The 'Subject:' of the messages which had beed happily posted: Mozilla: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ru-RU; rv:1.3) Gecko/20030312 Subject: [Test2] -- Egypt -- =?koi8-r?b?89XUz97O2cUgw8XO2SAjMTcgz9QgMTAuMDQuMjAwMw==?= Outlook Express: X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Subject: [Test2] =?koi8-r?b?IC0tIEVneXB0IC0tIPPV1M/eztnFIA==?= =?koi8-r?b?w8XO2SAjMTcgz9QgMTAuMDQuMjAwMw==?= So the questions is: Is this a bug or there is some tuning options for this? Can I enable some additional debugging for the cases like this? Mailman 2.1.1 Python 2.1.3 Debian 3.0r1 Woody Best regards, Maxim Yakubenko From R.Barrett at ftel.co.uk Fri Apr 11 11:37:53 2003 From: R.Barrett at ftel.co.uk (Richard Barrett) Date: Sat Apr 12 10:23:53 2003 Subject: [Mailman-Developers] encrypted mailing list In-Reply-To: <3E8F307F.6020300@plik.net> Message-ID: <5.1.1.6.0.20030411103401.03a7d3d8@ext-proxy.ftel.co.uk> At 20:37 05/04/2003, Thomas C. Meggs wrote: >Hi, > >I've been playing around with the idea of making software for an encrypted >mailing list that would be based around GPG. Each mailing list would have >its own public key. All members of a list would have to submit a public >key on subscription. When incoming mail is received, the mailing list >software would decrypt the email and then re-encrypt with the public key >for each of the members of the list. > >Has anyone played around with this idea? Has anyone already done a working >concept? I was just curious, and I wanted to throw the idea out there. Thanks! > >Regards, >Tom Found this bookmark lying around: http://sourceforge.net/projects/mmreencrypt/ but it doesn't look like it has been worked on for a long while. From boettiger at pobox.com Fri Apr 11 11:51:19 2003 From: boettiger at pobox.com (Adam Boettiger) Date: Sat Apr 12 10:23:56 2003 Subject: [Mailman-Developers] Help with patch install Message-ID: I need help installing this patch on 2.1.1: Edit header/body of messages Rather than have someone do it for me, I'd like someone to walk me through it so that I can install future patches myself. I am willing to pay money. Please contact me off-list at boettiger@pobox.com Thanks. AB From Roger at compsoc.man.ac.uk Sat Apr 12 00:02:43 2003 From: Roger at compsoc.man.ac.uk (Roger Lynn) Date: Sat Apr 12 10:23:58 2003 Subject: [Mailman-Developers] English (USA) Message-ID: <3E973B83.8040103@compsoc.man.ac.uk> On Tue 18 Mar, Thomas Wouters thomas@xs4all.net wrote: > On Wed, Mar 12, 2003 at 12:44:46PM +0100, CARTER Anthony wrote: > >> I would like to know if there is any way that we can remove the "USA" >> bit from the language options? For example, instead of "English (USA)" >> have just "English" > > Well, you can certainly do that for your own Mailman installation; just > search for 'USA' and remove the string where you see it :) Whether we want > that by default in the distributed Mailman is something else. I'd personally > be against it, because there is a real difference between, for instance, > English for the British and English for the Americans. Calling it English > (USA) at least makes it clear which version it is, even if there isn't > (yet) a British variant. Or is there ? I think having "English (USA)" appear as the only available language is more annoying for non-Americans than any Americanisms that might be in Mailman (and which are to be expected in most software anyway). So far, I've only noticed one, the spelling of "internationalisation", and that only appears on an admin page. Unless alternative English translations appear I would prefer the option to just be "English". To the original poster, if you haven't already discovered this: The languages can be renamed at the bottom of the Mailman/Defaults.py file. "internationalization" appears in Mailman/Gui/Language.py Roger From noc at kaibren.com Sat Apr 12 03:56:13 2003 From: noc at kaibren.com (Net Ops Center) Date: Sat Apr 12 10:24:00 2003 Subject: [Mailman-Developers] Display full name in roster display Message-ID: <5.2.1.1.2.20030412025604.0268c5e8@gw.kaibren.com> The following diff to HTMLFormatter.py in Ver 2.1.1 will display the full name if defined in the roster (view subscriber) list. It will display in full email address format as: "Full Name" < [obscured]email.addr > Caveat- I don't think this breaks anything else. I don't know for sure. Enjoy, MB /usr/local/mailman/Mailman/$ diff HTMLFormatter.py.dist HTMLFormatter.py 92c92 < showing = Utils.ObscureEmail(person, for_text=1) --- > email = Utils.ObscureEmail(person, for_text=1) 94c94,99 < showing = person --- > email = person > fullname = Utils.uncanonstr(self.getMemberName(person), lang) > if fullname: > showing = '"%s" < %s >' % (fullname, email) > else: > showing = email From marty at penguinarts.com Sat Apr 12 16:09:44 2003 From: marty at penguinarts.com (Marty Galyean) Date: Sat Apr 12 11:09:46 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <3E973B83.8040103@compsoc.man.ac.uk> References: <3E973B83.8040103@compsoc.man.ac.uk> Message-ID: <1050160045.1890.49.camel@localhost.localdomain> On Fri, 2003-04-11 at 16:02, Roger Lynn wrote: > I think having "English (USA)" appear as the only available language is more > annoying for non-Americans than any Americanisms that might be in Mailman > (and which are to be expected in most software anyway). So far, I've only > noticed one, the spelling of "internationalisation", and that only appears > on an admin page. Unless alternative English translations appear I would > prefer the option to just be "English". Maybe that should read 'anti-Americans' instead of 'non-Americans'. Ha ha. Personally, I like it the way it is. How hard would it really be for someone really concerned about the lack of a non-USA English option to port a non-USA English (UK I assume) and so add to the project rather than just trying to relabel what is clearly in reality American English? It doesn't look like more than a few hours work to create a new language directory, copy over 'en' contents, then vim through them. One could even run any blocks of text through 'worldlingo.com' or whatever (if they differentiate the UK and US English) then eyeball scan the output. It seems fairly clear that the person who wrote the 'en' files was American. Maybe not. But the fact remains he/she put in the time and effort to represent American English. Why should it be relabeled when the best thing to do would be for someone, probably a UK or resident of a prior UK colony to create a UK version. Then those who speak the various pidgin versions of English around the world can create their own ports. Am I missing something or does there seem to be a metallic political tang to the bringing up of this issue of American English being labeled 'English (USA)' in the interface? Why would my approach of other's creating the ports they want to see not more valid than relabeling US English as mere English if this is perceived to be the case? What I find ironic is that I am strongly of the mind that if American English had been labeled as merely 'English' to start with that someone out there would have been offended about "Americans *assuming* that their brand of English is standard! I want it labeled 'English (USA) so that people are not deceived!". To show my good will, I would attempt a port from US to UK English. I think I know most of the spelling issues, but some of the terminology variance might escape me unless there are lots of places to use the word 'lorry' instead of 'truck' in the 'en' directory. Oh yeah, almost forgot. I suppose we need a Canadian English also. I don't think I'd do very well on that. As far as I know it is the same as UK which shows how little I know, I am sure. :^) Marty From bob at nleaudio.com Sat Apr 12 11:54:07 2003 From: bob at nleaudio.com (Bob Puff@NLE) Date: Sat Apr 12 11:54:16 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <1050160045.1890.49.camel@localhost.localdomain> References: <3E973B83.8040103@compsoc.man.ac.uk> <1050160045.1890.49.camel@localhost.localdomain> Message-ID: <20030412155407.M46987@nleaudio.com> All you need for "Canadian english" is just to add some "Eh?"s to the prompts. Bob > > Oh yeah, almost forgot. I suppose we need a Canadian English also. > I don't think I'd do very well on that. As far as I know it is the same > as UK which shows how little I know, I am sure. > From mjm at michaelmeltzer.com Sat Apr 12 23:11:55 2003 From: mjm at michaelmeltzer.com (Michael Meltzer) Date: Sat Apr 12 22:16:00 2003 Subject: [Mailman-Developers] SMTPServerDisconnected bug Message-ID: <036901c30162$1047ce70$0b01a8c0@mjm2> I just updated my system, it is a FreeBSD 4.8-stable(Thursday) plus full ports with python 2.2.2, after the upgrade mailman started refusing to deliver any messages, it started with a 2.0.13b4 install that's been good for months and I also tried a clean install of 2.1.1(also reinstalled python 2.2.2 a few times after reading the archives), it a hard failure that happens with all messages. Right now I got the list working using the sendmail method but would like to stop that. Frankly I think it a problem with python 2.2.2 and FreeBSD 4.8-stable, the "latest and greatest", I am not sure of what to do next(not on any python lists). Maybe this might be a heads up of things to come. Any one have an idea what's up, is this a know bug/patch(python/mailman/FreeBSD) or any ideas of a workaround/fix. Happy to supply any information or run any tests, looking for some help please. MJM File "/home/mailman/Mailman/Queue/Runner.py", line 105, in _oneloop self._onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 155, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/OutgoingRunner.py", line 61, in _dispose self._func(mlist, msg, msgdata) File "/home/mailman/Mailman/Handlers/SMTPDirect.py", line 150, in process conn.quit() File "/home/mailman/Mailman/Handlers/SMTPDirect.py", line 80, in quit self.__conn.quit() File "/usr/local/lib/python2.2/smtplib.py", line 702, in quit self.docmd("quit") File "/usr/local/lib/python2.2/smtplib.py", line 357, in docmd self.putcmd(cmd,args) File "/usr/local/lib/python2.2/smtplib.py", line 313, in putcmd self.send(str) File "/usr/local/lib/python2.2/smtplib.py", line 305, in send raise SMTPServerDisconnected('please run connect() first') SMTPServerDisconnected: please run connect() first Apr 12 03:26:19 2003 (46119) SHUNTING: 1050132199.892874+1248b43fe8a0fd5c91e64db7d3aeed2735c6cbf2 From maechler at stat.math.ethz.ch Mon Apr 14 15:26:38 2003 From: maechler at stat.math.ethz.ch (Martin Maechler) Date: Mon Apr 14 08:26:53 2003 Subject: [Mailman-Developers] Outgoing qrunner dies on 'None' object has no attribute... Message-ID: <16026.43262.815474.913850@gargle.gargle.HOWL> This has happened with increasing intensity here, only since running mailman 2.1.1 (since March 4 or so). Note that the following is an informal bug report of what I think at least two different problems. ------------------------------------------------------------------------------- AttributeError: 'None' object has no attribute 'has_key' Traceback (most recent call last): File "/usr/local/app/mailman-sfs/2.1.1/bin/qrunner", line 270, in ? main() File "/usr/local/app/mailman-sfs/2.1.1/bin/qrunner", line 230, in main qrunner.run() File "/usr/local/app/mailman-sfs/2.1.1/Mailman/Queue/Runner.py", line 59, in run filecnt = self._oneloop() File "/usr/local/app/mailman-sfs/2.1.1/Mailman/Queue/Runner.py", line 88, in _oneloop msg, msgdata = self._switchboard.dequeue(filebase) File "/usr/local/app/mailman-sfs/2.1.1/Mailman/Queue/Switchboard.py", line 151, in dequeue if data.has_key('rejection-notice'): ------------------------------------------------------------------------------- Qrunner dies and is restarted -- but only 10 times when it really dies with ------ logs/qrunner ------------------------------------- Apr 14 11:06:24 2003 (1230) Qrunner OutgoingRunner reached maximum restart limit of 10, not restarting. --------------------------------------------------------- I have just now set this (MAX_RESTARTS in bin/mailmanctl) to 10000 instead of 10 (BTW, shouldn't this be configurable via mm_cfg.py as well?) >From then on, qfiles/out/* starts growing and growing and mailing list delivery becomes very slow at least in the case, where I have two (or 4) slices Outgoing Runners. --- Bug # 2 --- BTW: When I do have more than one runner, things get faster, *BUT* I sometimes get the same message delivered by more than one of the outgoing runners. This seems to happen (almost?) ony in the case where the queue is almost empty. But it is quite embarrassing to this twice delivered to everyone on the list. Thank you for mailman, and thanks for feedback / suggestions / fixes ... Martin Maechler http://stat.ethz.ch/~maechler/ Seminar fuer Statistik, ETH-Zentrum LEO C16 Leonhardstr. 27 ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND phone: x-41-1-632-3408 fax: ...-1228 <>< From Roger at compsoc.man.ac.uk Mon Apr 14 23:07:41 2003 From: Roger at compsoc.man.ac.uk (Roger Lynn) Date: Mon Apr 14 17:07:51 2003 Subject: [Mailman-Developers] English (USA) References: <3E973B83.8040103@compsoc.man.ac.uk> <1050159998.1890.47.camel@localhost.localdomain> Message-ID: <3E9B231D.60205@compsoc.man.ac.uk> Marty Galyean wrote: > How hard would it really be for someone really concerned about the lack > of a non-USA English option to port a non-USA English (UK I assume) and > so add to the project rather than just trying to relabel what is clearly > in reality American English? This was my preferred solution, but I couldn't find any documentation on www.list.org on how to produce a new translation. I might have another go when I have some time, but renaming the language was the easy fix. As I said before, so far I've noticed only *ONE* word that needed changing. > What I find ironic is that I am strongly of the mind that if American > English had been labeled as merely 'English' to start with that someone > out there would have been offended about "Americans *assuming* that > their brand of English is standard! I want it labeled 'English (USA) so > that people are not deceived!". This is probably true. > Oh yeah, almost forgot. I suppose we need a Canadian English also. I > don't think I'd do very well on that. As far as I know it is the same > as UK which shows how little I know, I am sure. I'm probably wrong, but afaik US spelling is used in Canada. Roger From terri at zone12.com Mon Apr 14 19:02:38 2003 From: terri at zone12.com (Terri Oda) Date: Mon Apr 14 17:54:18 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <3E9B231D.60205@compsoc.man.ac.uk> References: <3E973B83.8040103@compsoc.man.ac.uk> <1050159998.1890.47.camel@localhost.localdomain> <3E9B231D.60205@compsoc.man.ac.uk> Message-ID: <20030414220238.GB1742@ostraya.zone12.com> > >Oh yeah, almost forgot. I suppose we need a Canadian English also. I > >don't think I'd do very well on that. As far as I know it is the same > >as UK which shows how little I know, I am sure. > > I'm probably wrong, but afaik US spelling is used in Canada. Most Canadian English is the same as UK English, as long as you're talking spelling. (Some words are defined differently, more like the US, and the slang is different, of course.) There are Canadian English dictionaries for the truely dedicated. (And yes, they include "eh") Most people (and many programs) are pretty forgiving about using either spelling in Canadian English, but you may get teased by primary school children if you don't put a u in colour. :) I'm tempted to make a Canadian translation now, just for amusement value. I don't know how different Canadian French is from France French... but that's another can of worms entirely! Terri From terri at zone12.com Mon Apr 14 19:11:56 2003 From: terri at zone12.com (Terri Oda) Date: Mon Apr 14 18:04:04 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <20030414220238.GB1742@ostraya.zone12.com> References: <3E973B83.8040103@compsoc.man.ac.uk> <1050159998.1890.47.camel@localhost.localdomain> <3E9B231D.60205@compsoc.man.ac.uk> <20030414220238.GB1742@ostraya.zone12.com> Message-ID: <20030414221156.GC1742@ostraya.zone12.com> > There are Canadian English dictionaries for the truely dedicated. Whoops. Meant to provide a link to one: http://www.fedpubs.com/subject/refer/oxfdic.htm Terri From tag at cs.utah.edu Tue Apr 15 18:42:42 2003 From: tag at cs.utah.edu (Todd Green) Date: Tue Apr 15 19:43:34 2003 Subject: [Mailman-Developers] Implicit destination default action RFE Message-ID: <200304152342.h3FNgg503516@faith.cs.utah.edu> Ok, this is driving me bonkers. We get a ton of spam that is sent to our lists as implicit destinations. There is no way to automatically discard these messages under Mailman 2.1.1 (Python 2.2.2 on Solaris9) As an RFE, could a feature be added along the lines of the default handler for posts from non-members so that you can select what do to with mail for implicit destinations? i.e. Under Privacy -> Recipient Filters Action to take for postings to implicit destinations for which no explicit action is defined. (Details for generic_implicit_action) [ ] Accept [ ] Hold [ ] Reject [ ] Discard Right now the there is no option and all mail is held. Thanks, Todd From barry at python.org Thu Apr 17 05:18:33 2003 From: barry at python.org (Barry Warsaw) Date: Thu Apr 17 00:18:35 2003 Subject: [Mailman-Developers] Re: [Mailman-Users] 2.1.1 mbox archive doesn't handle lines starting with "From " correctly? In-Reply-To: <1050454268.27442.187.camel@kicktest.razafoundries.com> References: <1050454268.27442.187.camel@kicktest.razafoundries.com> Message-ID: <1050553087.26382.53.camel@anthem> On Tue, 2003-04-15 at 20:51, Eric D. Christensen wrote: > I'm seeing problems with the mbox archives after upgrading mailman from > 2.0 to 2.1.1. I started to report these as bugs, but then thought that > I'd better check in here first just in case I'm missing something silly. > Apologies for cross posting to both users and developers lists.... > > First, a little background... > > I use both pipermail and mbox format archives for all of our lists. I > use the mbox format mainly as a backup so we can regenerate the > pipermail archives (via 'arch --wipe list'). Since some of our lists > have over 5 years of mailman archives now, having the mbox archives > around has save my butt several times. Too bad servers don't last as > long as the mailing lists running on them! :-) > > I'll admit up front that I'm NOT a python programmer.... perl, C, java, > PHP, but not python. So I'm only slightly familiar with the syntax and > totally clueless beyond that. I'm hoping to NOT have to use this problem > as a reason to learn python (though I'd like to someday when I'm not > quite so busy). > > Anyway, here are the two problems I'm seeing with mbox archives: > > After upgrading mailman from 2.0 to 2.1.1 (and python itself to 2.2.2) I > regenerated the pipermail archives from the mbox archives and found that > suddenly I had a bunch of messages with "[no subject]", all together > starting just about the time I switched the lists over the 2.1.1. Upon > further investigation I found two issues that make the mbox file invalid > (or at least suspect): > > 1. No newline before "From " lines in the mbox with 2.1.1. > Sine the 2.1.1 update it appears the the mbox archiver is no > longer instering a newline before starting a new message. This > results in the "From_" line being directly below the last line > of the previous message. This confuses the mbox parser something > awful.... it also confuses elm, mutt, and mh if I try to read > the mbox files with them. > > I found the code in Mailbox.py (in AppendMessage @ line 46) that > gets called from Archiver/Archiver.py to handle inserting the > newline if the last thing in the mbox file isn't already a > newline before appending the message, but it doesn't seem to be > working correctly. > > Am I missing something or is AppendMessage broken in this > respect? > > 2. Lines beginning with "From " inside of a message body are not > handled. > If a line inside a message body starts with the string "From ", > it is being mis-interpreted as the beginning of a new message > (i.e. it's being treated as an envelope "From " line. > > I'm not quite sure who to fault on this one... I believe that > it's common practice to somehow quote this case, in which case > it s Generator that's not doing the right thing. I think this is > supported by the fact the other mail agents (elm, mutt, etc...) > are confused by this unquoted "From " in the message body. It's > probably a bit much to ask utilities like arch to try to discern > body from envelope on the fly while reading in the mbox file. > > Any insight, pointers or ideas on these before I report them as bugs? These are genuine bugs. Please submit a bug report on them. Thanks, -Barry From barry at python.org Thu Apr 17 05:34:44 2003 From: barry at python.org (Barry Warsaw) Date: Thu Apr 17 00:34:45 2003 Subject: [Mailman-Developers] Re: [Mailman-Users] 2.1.1 mbox archive doesn't handle lines starting with "From " correctly? In-Reply-To: <1050553087.26382.53.camel@anthem> References: <1050454268.27442.187.camel@kicktest.razafoundries.com> <1050553087.26382.53.camel@anthem> Message-ID: <1050554063.26379.55.camel@anthem> On Thu, 2003-04-17 at 00:18, Barry Warsaw wrote: > > Any insight, pointers or ideas on these before I report them as bugs? > > These are genuine bugs. Please submit a bug report on them. Actually, don't. I'm about to check in two fixes. -Barry From maechler at stat.math.ethz.ch Thu Apr 17 17:55:13 2003 From: maechler at stat.math.ethz.ch (Martin Maechler) Date: Thu Apr 17 10:55:41 2003 Subject: [Mailman-Developers] Bug in Mailman version 2.1.1 -- ASCII decoding error Message-ID: <16030.49233.366110.409212@gargle.gargle.HOWL> Dear developers, I got this from a user of one of my mailing list, where I have allowed all possible languages for a user interface -- and I *do* get bad errors that kill the outgoing runner, seen mostly when users chose "ja" (Japanese) and "fr" (French) Can you advise me (as site and list administrator) what I could / should do and try? Is this the proper mailing list? Regards, Martin Maechler http://stat.ethz.ch/~maechler/ Seminar fuer Statistik, ETH-Zentrum LEO C16 Leonhardstr. 27 ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND phone: x-41-1-632-3408 fax: ...-1228 <>< ------- start of forwarded message ------- Hi, I have the following bug when I click on the button "R?silier" (unsubscribe in french) after having received the mail with the URL for unsubscription. As a result, I can not unsubscribe ! Thanks ! <.......> Bug in Mailman version 2.1.1 We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (most recent call last): File "/usr/local/app/mailman-sfs/2.1.1/scripts/driver", line 87, in run_main main() File "/usr/local/app/mailman-sfs/2.1.1/Mailman/Cgi/confirm.py", line 118, in main unsubscription_confirm(mlist, doc, cookie) File "/usr/local/app/mailman-sfs/2.1.1/Mailman/Cgi/confirm.py", line 399, in unsubscription_confirm op, addr = mlist.ProcessConfirmation(cookie) File "/usr/local/app/mailman-sfs/2.1.1/Mailman/MailList.py", line 1081, in ProcessConfirmation self.ApprovedDeleteMember(addr, whence=whence) File "/usr/local/app/mailman-sfs/2.1.1/Mailman/MailList.py", line 935, in ApprovedDeleteMember msg = Message.OwnerNotification(self, subject, text) File "/usr/local/app/mailman-sfs/2.1.1/Mailman/Message.py", line 257, in __init__ UserNotification.__init__(self, recips, sender, subject, text, lang) File "/usr/local/app/mailman-sfs/2.1.1/Mailman/Message.py", line 203, in __init__ self['Subject'] = Header(subject, charset, header_name='Subject') File "/usr/local/app/mailman-sfs/2.1.1/pythonlib/email/Header.py", line 164, in __init__ self.append(s, charset) File "/usr/local/app/mailman-sfs/2.1.1/pythonlib/email/Header.py", line 230, in append ustr = unicode(s, incodec) UnicodeError: ASCII decoding error: ordinal not in range(128) ------------------------------------------------------------------------ -------- Python information: Variable Value sys.version 2.1.3 (#2, Jul 11 2002, 15:08:42) [GCC 3.1] sys.executable /usr/local/app/python/current/bin/python sys.prefix /usr/local/app/python/current sys.exec_prefix /usr/local/app/python/current sys.path /usr/local/app/python/current sys.platform sunos5 ------------------------------------------------------------------------ -------- Environment variables: Variable Value SSL_SERVER_I_DN /C=CH/ST=Switzerland/L=Zurich/O=ETH Zurich/OU=Department of Mathematics/CN=ISG D-MATH/Email=webmaster@math.ethz.ch downgrade_1_0 1 SSL_SERVER_S_DN_O ETH Zurich SSL_CIPHER_USEKEYSIZE 128 SSL_SERVER_M_VERSION 1 SSL_VERSION_INTERFACE mod_ssl/2.8.10 CONTENT_TYPE application/x-www-form-urlencoded SSL_SERVER_V_END Feb 4 16:20:08 2013 GMT ssl_unclean_shutdown 1 REQUEST_METHOD POST HTTP_ACCEPT_LANGUAGE fr SSL_PROTOCOL SSLv3 GATEWAY_INTERFACE CGI/1.1 nokeepalive 1 SSL_SERVER_I_DN_Email webmaster@math.ethz.ch HTTP_ACCEPT image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */* REQUEST_URI /mailman/confirm/r-help SSL_SERVER_S_DN_C CH HTTP_ACCEPT_ENCODING gzip, deflate HTTPS on HTTP_HOST www.stat.math.ethz.ch TZ MET SSL_SERVER_S_DN_L Zurich SSL_SERVER_A_SIG md5WithRSAEncryption SSL_SERVER_M_SERIAL 07 SERVER_ADMIN webmaster@math.ethz.ch SCRIPT_FILENAME /usr/local.hg/app/apache/vhosts/sfs/mailman/confirm PYTHONPATH /usr/local/app/mailman-sfs/2.1.1 SSL_VERSION_LIBRARY OpenSSL/0.9.6c SSL_SERVER_S_DN_OU Seminar for Statistics SERVER_PROTOCOL HTTP/1.1 SSL_SERVER_S_DN_Email webmaster@math.ethz.ch SSL_SERVER_I_DN_OU Department of Mathematics DOCUMENT_ROOT /usr/local.hg/app/apache/vhosts/sfs/htdocs SERVER_ADDR 129.132.148.206 SSL_SERVER_V_START Feb 7 16:20:08 2003 GMT SSL_SERVER_I_DN_O ETH Zurich SSL_SERVER_I_DN_L Zurich SERVER_PORT 443 PATH_TRANSLATED /usr/local.hg/app/apache/vhosts/sfs/htdocs/r-help UNIQUE_ID Pp5yw4GElMUAAA@goHM SSL_CIPHER_ALGKEYSIZE 128 REMOTE_ADDR 81.1.18.46 SERVER_NAME www.stat.math.ethz.ch SSL_SERVER_I_DN_CN ISG D-MATH HTTP_CONNECTION Keep-Alive HTTP_USER_AGENT Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) SSL_CLIENT_VERIFY NONE CONTENT_LENGTH 65 SSL_SESSION_ID B923993173D4BEB1CA2680BA3F265B6E234FBC330ECE7F6CD7A5FE374EF1E126 SSL_SERVER_I_DN_ST Switzerland SSL_CIPHER RC4-MD5 SSL_SERVER_S_DN /C=CH/ST=Switzerland/L=Zurich/O=ETH Zurich/OU=Seminar for Statistics/CN=www.stat.math.ethz.ch/Email=webmaster@math.ethz.ch SSL_SERVER_S_DN_CN www.stat.math.ethz.ch PATH_INFO /r-help REMOTE_PORT 4038 SSL_SERVER_I_DN_C CH SERVER_SIGNATURE Apache/1.3.26 Server at www.stat.math.ethz.ch Port 443 SSL_SERVER_S_DN_ST Switzerland SSL_SERVER_A_KEY rsaEncryption SCRIPT_NAME /mailman/confirm QUERY_STRING SERVER_SOFTWARE Apache/1.3.26 (Unix) PHP/4.2.2 DAV/1.0.3 mod_perl/1.27 mod_ssl/2.8.10 OpenSSL/0.9.6c HTTP_CACHE_CONTROL no-cache SSL_CIPHER_EXPORT false HTTP_REFERER https://www.stat.math.ethz.ch/mailman/confirm/r-help/ae97e43f39ab5e9884f 6f8c5a75a1a56eb56ed65 force_response_1_0 1 ------- end of forwarded message ------- From a.carter at cordis.lu Fri Apr 18 11:10:02 2003 From: a.carter at cordis.lu (CARTER Anthony) Date: Fri Apr 18 04:10:11 2003 Subject: [Mailman-Developers] Registering another email address via mail... In-Reply-To: References: Message-ID: <200304181010.02680.a.carter@intrasoft.lu> Hi, Is there a way I can subscribe an e-mail address to a mailman list from another email address? What I mean is something like: To: mailinglist@mailman.com From: a.b@c.com Subject: Subscribe x.y@z.com Thanks, Anthony Carter From bisho at eurielec.etsit.upm.es Tue Apr 15 05:06:35 2003 From: bisho at eurielec.etsit.upm.es (Guille -bisho-) Date: Fri Apr 18 18:26:22 2003 Subject: [Mailman-Developers] Bug on mailman 2.1.1 with non ascii mails? Message-ID: <1050379589.1343.24.camel@localhost> I have a problem with mailman 2.1.1 (Debian package 2.1.1-4) The OutgoingRunner was failing as follows: Traceback (most recent call last): File "/var/lib/mailman/bin/qrunner", line 270, in ? main() File "/var/lib/mailman/bin/qrunner", line 230, in main qrunner.run() File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 59, in run filecnt = self._oneloop() File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 114, in _oneloop self._doperiodic() File "/usr/lib/mailman/Mailman/Queue/OutgoingRunner.py", line 136, in _doperiodic mlist.registerBounce(recip, msg) File "/var/lib/mailman/Mailman/Bouncer.py", line 155, in registerBounce self.disableBouncingMember(member, info, msg) File "/var/lib/mailman/Mailman/Bouncer.py", line 165, in disableBouncingMember self.__sendAdminBounceNotice(member, msg) File "/var/lib/mailman/Mailman/Bouncer.py", line 187, in __sendAdminBounceNotice lang=self.preferred_language) File "/var/lib/mailman/Mailman/Message.py", line 203, in __init__ self['Subject'] = Header(subject, charset, header_name='Subject') File "/var/lib/mailman/pythonlib/email/Header.py", line 164, in __init__ self.append(s, charset) File "/var/lib/mailman/pythonlib/email/Header.py", line 230, in append ustr = unicode(s, incodec) UnicodeError : ASCII decoding error: ordinal not in range(128) In that line there was a: ustr = unicode(s, ustr = unicode(s, incodecincodec) And the incodec was set on line 229 as: incodec = charset.input_codec or 'us-ascii' It seems that charset.input_codec was not set, and the pending to send emails were not us-ascii code. I have to change that line to: incodec = charset.input_codec or 'iso-8859-15' And also change the line 234: - outcodec = charset.output_codec or 'us-ascii' + outcodec = charset.output_codec or 'iso-8859-15' and the OutgoingRunner was able then to process the emails without hanging. Is important to make more checks, to avoid DOS atacks to mailman servers. A message with non-ascii chars could be considered as ascii making the OutgoingRunner to die, and stoping the service. This only happens if: if isinstance(s, StringType): because the exception is not caught later the the conversion is done properly capturing the exception: elif isinstance(s, UnicodeType): for charset in USASCII, charset, UTF8: try: outcodec = charset.output_codec or 'us-ascii' s = s.encode(outcodec) break except UnicodeError: ... How you think this should be solved? I'm not and expert in python... -- ,,,.. .-. / -_.' ' "" ,/ ,/, / , ,\ , , ``-, , , , ) PAZ S? /,,' ,/ ,/ / ?GUERRA NO! , / bisho! -=] 15/04/2003 [=- From jerry.hinshaw at hp.com Tue Apr 15 06:32:09 2003 From: jerry.hinshaw at hp.com (HINSHAW,JERRY L (HP-Boise,ex1)) Date: Fri Apr 18 18:26:25 2003 Subject: [Mailman-Developers] Umbrella and nested lists moderation requests Message-ID: HI, SORRY to send this to developers directly. This question is still awaiting approval to the Mailman users list. I want to create an umbrella list (a list with ONLY lists nested within it). The top level list is simply named top. The nested lists are injerry, inclint, and incat. I have mailman-v2.1.1 installed and is the FIRST mailman to be installed on these servers. I have reviewed the FAQs and the mailing lists archives, which currently only address ensuring unique mail addresses are in the nested lists. I have currently set ALL lists (top, injerry, incat, and inclint) with NO Moderation and accepting from everyone. If I mail to any one of the nested (injerry, incat, and inclint) lists as anyone the message delivers no problems. HOWEVER when I send to the umbrella list (top) the List owner of the nested lists (injerry, incat, and inclint) get a message indicating moderation is required for the message sent. Have a missed something or is this incorrect behavior?? BELOW is the config_list output of the parameters I think are important. Attached is the complete config_list output for the umbrella list (top) and a nested list (injerry). Also is the mm_cfg.py settings for the site. Any help or ideas would be appreciated. Thanks Jerry TOP Level List (Umbrella List) bash-2.04$ grep member top | grep -v "^#" umbrella_member_suffix = '-owner' new_member_options = 256 default_member_moderation = 0 member_moderation_action = 0 member_moderation_notice = '' accept_these_nonmembers = [] hold_these_nonmembers = [] reject_these_nonmembers = [] discard_these_nonmembers = [] generic_nonmember_action = 0 NESTED LIST bash-2.04$ grep member injerry | grep -v "^#" umbrella_member_suffix = '-owner' new_member_options = 256 default_member_moderation = 0 member_moderation_action = 0 member_moderation_notice = '' accept_these_nonmembers = [] hold_these_nonmembers = [] reject_these_nonmembers = [] discard_these_nonmembers = [] generic_nonmember_action = 0 Mm_cfg.py settings other than virtual host which is set. # Should a list, by default be advertised? What is the default maximum number # of explicit recipients allowed? What is the default maximum message size # allowed? DEFAULT_LIST_ADVERTISED = 1 DEFAULT_MAX_NUM_RECIPIENTS = 100000 DEFAULT_MAX_MESSAGE_SIZE = 0 # KB # Are archives on or off by default? DEFAULT_ARCHIVE = 0 # 0=Off, 1=On # Set this variable to 1 to allow list owners to delete their own mailing # lists. You may not want to give them this power, in which case, setting # this variable to 0 instead requires list removal to be done by the site # administrator, via the command line script bin/rmlist. OWNERS_CAN_DELETE_THEIR_OWN_LISTS = 1 ##### # Digestification defaults ##### # Will list be available in non-digested form? DEFAULT_NONDIGESTABLE = 1 # Will list be available in digested form? DEFAULT_DIGESTABLE = 0 DEFAULT_DIGEST_IS_DEFAULT = 0 # This variable controls whether monthly password reminders are sent. DEFAULT_SEND_REMINDERS = 0 # Send welcome messages to new users? Probably should keep this set to 1. DEFAULT_SEND_WELCOME_MSG = 0 # Send goodbye messages to unsubscribed members? Probably should keep this # set to 1. DEFAULT_SEND_GOODBYE_MSG = 0 # How long should messages which have delivery failures continue to be # retried? After this period of time, a message that has failed recipients # will be dequeued and those recipients will never receive the message. DELIVERY_RETRY_PERIOD = days(3) # Should list members, by default, have their posts be moderated? DEFAULT_DEFAULT_MEMBER_MODERATION = 0 # What shold happen to non-member posts which are do not match explicit # non-member actions? # 0 = Accept # 1 = Hold # 2 = Reject # 3 = Discard DEFAULT_GENERIC_NONMEMBER_ACTION = 0 # See "Bitfield for user options" below; make this a sum of those options, to # make all new members of lists start with those options flagged. We assume # by default that people don't want to receive two copies of posts. Note # however that the member moderation flag's initial value is controlled by the # list's config variable default_member_moderation. # Bitfield for user options. See DEFAULT_NEW_MEMBER_OPTIONS above to set # defaults for all new lists. #Digests = 0 # handled by other mechanism, doesn't need a flag. #DisableDelivery = 1 # Obsolete; use set/getDeliveryStatus() #DontReceiveOwnPosts = 2 # Non-digesters only #AcknowledgePosts = 4 #DisableMime = 8 # Digesters only #ConcealSubscription = 16 #SuppressPasswordReminder = 32 #ReceiveNonmatchingTopics = 64 #Moderate = 128 #DontReceiveDuplicates = 256 #DEFAULT_NEW_MEMBER_OPTIONS = 256 -------------- next part -------------- A non-text attachment was scrubbed... Name: top Type: application/octet-stream Size: 44955 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20030415/4fe07ff9/top-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: injerry Type: application/octet-stream Size: 44971 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20030415/4fe07ff9/injerry-0001.obj From edc at proadmin.com Wed Apr 16 01:51:42 2003 From: edc at proadmin.com (Eric D. Christensen) Date: Fri Apr 18 18:26:29 2003 Subject: [Mailman-Developers] 2.1.1 mbox archive doesn't handle lines starting with "From " correctly? Message-ID: <1050454268.27442.187.camel@kicktest.razafoundries.com> I'm seeing problems with the mbox archives after upgrading mailman from 2.0 to 2.1.1. I started to report these as bugs, but then thought that I'd better check in here first just in case I'm missing something silly. Apologies for cross posting to both users and developers lists.... First, a little background... I use both pipermail and mbox format archives for all of our lists. I use the mbox format mainly as a backup so we can regenerate the pipermail archives (via 'arch --wipe list'). Since some of our lists have over 5 years of mailman archives now, having the mbox archives around has save my butt several times. Too bad servers don't last as long as the mailing lists running on them! :-) I'll admit up front that I'm NOT a python programmer.... perl, C, java, PHP, but not python. So I'm only slightly familiar with the syntax and totally clueless beyond that. I'm hoping to NOT have to use this problem as a reason to learn python (though I'd like to someday when I'm not quite so busy). Anyway, here are the two problems I'm seeing with mbox archives: After upgrading mailman from 2.0 to 2.1.1 (and python itself to 2.2.2) I regenerated the pipermail archives from the mbox archives and found that suddenly I had a bunch of messages with "[no subject]", all together starting just about the time I switched the lists over the 2.1.1. Upon further investigation I found two issues that make the mbox file invalid (or at least suspect): 1. No newline before "From " lines in the mbox with 2.1.1. Sine the 2.1.1 update it appears the the mbox archiver is no longer instering a newline before starting a new message. This results in the "From_" line being directly below the last line of the previous message. This confuses the mbox parser something awful.... it also confuses elm, mutt, and mh if I try to read the mbox files with them. I found the code in Mailbox.py (in AppendMessage @ line 46) that gets called from Archiver/Archiver.py to handle inserting the newline if the last thing in the mbox file isn't already a newline before appending the message, but it doesn't seem to be working correctly. Am I missing something or is AppendMessage broken in this respect? 2. Lines beginning with "From " inside of a message body are not handled. If a line inside a message body starts with the string "From ", it is being mis-interpreted as the beginning of a new message (i.e. it's being treated as an envelope "From " line. I'm not quite sure who to fault on this one... I believe that it's common practice to somehow quote this case, in which case it s Generator that's not doing the right thing. I think this is supported by the fact the other mail agents (elm, mutt, etc...) are confused by this unquoted "From " in the message body. It's probably a bit much to ask utilities like arch to try to discern body from envelope on the fly while reading in the mbox file. Any insight, pointers or ideas on these before I report them as bugs? -- Eric D. Christensen Proadmin, Inc. - http://www.proadmin.com From aks at stebbens.org Fri Apr 18 16:22:48 2003 From: aks at stebbens.org (Alan K. Stebbens) Date: Fri Apr 18 18:26:33 2003 Subject: [Mailman-Developers] New MTA Handler Message-ID: <859747231.20030418152248@stebbens.org> Howdy, I've written a new MTA handler for mailman for integrating a procmail delivery system with Mailman. In particular, it is very useful for delivery through a virtual host user. The MTA handler has hooks for the creation and deletion of lists. When a list is created, or when one is deleted, the MTA handler causes the a procmail recipe file to be (re)created with the appropriate recipes to direct incoming mail to the appropriate Mailman commands. I've posted it to the patches at: https://sourceforge.net/tracker/index.php?func=detail&aid=723918&group_id=103&atid=300103 The patch includes a shar archive of the Procmail.py and updated Defaults.py modules. -- Best regards, Alan K. Stebbens (Voice/Fax: +1.866.579.0801) Ill-chosen abstraction is particularly evident in the design of the ADA runtime system. The interface to the ADA runtime system is so opaque that it is impossible to model or predict its performance, making it effectively useless for real-time systems. -- Marc D. Donner and David H. Jameson. From terri at zone12.com Sat Apr 19 11:43:19 2003 From: terri at zone12.com (Terri Oda) Date: Sat Apr 19 10:43:03 2003 Subject: [Mailman-Developers] Umbrella and nested lists moderation requests In-Reply-To: References: Message-ID: <20030419144318.GB981@ostraya.zone12.com> > I have currently set ALL lists (top, injerry, incat, and inclint) > with NO Moderation and accepting from everyone. If I mail to any one of the > nested (injerry, incat, and inclint) lists as anyone the message delivers no > problems. HOWEVER when I send to the umbrella list (top) the List owner of > the nested lists (injerry, incat, and inclint) get a message indicating > moderation is required for the message sent. Have a missed something or is > this incorrect behavior?? My *guess* is that you need to add the umbrella list's address to the list of acceptable aliases for each list. Terri From terri at zone12.com Sat Apr 19 11:47:26 2003 From: terri at zone12.com (Terri Oda) Date: Sat Apr 19 10:46:56 2003 Subject: [Mailman-Developers] Registering another email address via mail... In-Reply-To: <200304181010.02680.a.carter@intrasoft.lu> References: <200304181010.02680.a.carter@intrasoft.lu> Message-ID: <20030419144726.GA1054@ostraya.zone12.com> > Is there a way I can subscribe an e-mail address to a mailman list from > another email address? > > What I mean is something like: > > To: mailinglist@mailman.com > From: a.b@c.com > Subject: Subscribe x.y@z.com This would be To: mailinglist-request@mailman.com From: a.b@c.com Subject: subscribe address=x.y@z.com From barry at python.org Sat Apr 19 16:15:35 2003 From: barry at python.org (Barry Warsaw) Date: Sat Apr 19 11:15:37 2003 Subject: [Mailman-Developers] Implicit destination default action RFE In-Reply-To: <200304152342.h3FNgg503516@faith.cs.utah.edu> References: <200304152342.h3FNgg503516@faith.cs.utah.edu> Message-ID: <1050765306.29001.4.camel@anthem> On Tue, 2003-04-15 at 19:42, Todd Green wrote: > Ok, this is driving me bonkers. We get a ton of spam that is sent to > our lists as implicit destinations. There is no way to automatically > discard these messages under Mailman 2.1.1 (Python 2.2.2 on Solaris9) > > As an RFE, could a feature be added along the lines of the default > handler for posts from non-members so that you can select what do to > with mail for implicit destinations? > > i.e. Under Privacy -> Recipient Filters > > Action to take for postings to implicit destinations for which no > explicit action is defined. (Details for generic_implicit_action) > > [ ] Accept [ ] Hold [ ] Reject [ ] Discard > > Right now the there is no option and all mail is held. I have plans for rewriting the Hold/Moderate workflow so that you could do something like this much more easily. It's probably a MM3.0 thing. -Barry From barry at python.org Sat Apr 19 16:19:25 2003 From: barry at python.org (Barry Warsaw) Date: Sat Apr 19 11:19:26 2003 Subject: [Mailman-Developers] Bug on mailman 2.1.1 with non ascii mails? In-Reply-To: <1050379589.1343.24.camel@localhost> References: <1050379589.1343.24.camel@localhost> Message-ID: <1050765537.29014.8.camel@anthem> On Tue, 2003-04-15 at 00:06, Guille -bisho- wrote: > I have a problem with mailman 2.1.1 (Debian package 2.1.1-4) > How you think this should be solved? I'm not and expert in python... As a general rule, whenever you have a message that is crashing a qrunner, the /only/ way to debug it properly is to submit a SF bug report and upload the offending message on the report. Then I can download it and run it on the cvs snapshot to see if the problem has been fixed or not. Be sure that when you upload the message, it has been properly sanitized. The SF tracker is a public forum and I may need to add the message (or a portion of it) to a test suite. Cheers, -Barry From pioppo at ferrara.linux.it Sat Apr 19 18:20:52 2003 From: pioppo at ferrara.linux.it (Simone Piunno) Date: Sat Apr 19 11:22:31 2003 Subject: [Mailman-Developers] Implicit destination default action RFE In-Reply-To: <1050765306.29001.4.camel@anthem> References: <200304152342.h3FNgg503516@faith.cs.utah.edu> <1050765306.29001.4.camel@anthem> Message-ID: <20030419152052.GG22158@ferrara.linux.it> On Sat, Apr 19, 2003 at 11:15:06AM -0400, Barry A. Warsaw wrote: > I have plans for rewriting the Hold/Moderate workflow so that you could > do something like this much more easily. It's probably a MM3.0 thing. I'm trying to extend the current workflow to allow training of false negatives when using spambayes as the filter, so I'm very interested to have some info on your plans :) -- Simone Piunno -- http://members.ferrara.linux.it/pioppo .------- Adde parvum parvo magnus acervus erit -------. Ferrara Linux Users Group - http://www.ferrara.linux.it Deep Space 6, IPv6 on Linux - http://www.deepspace6.net GNU Mailman, Mailing List Manager - http://www.list.org `-------------------------------------------------------' From barry at python.org Sat Apr 19 16:48:30 2003 From: barry at python.org (Barry Warsaw) Date: Sat Apr 19 11:48:32 2003 Subject: [Mailman-Developers] Outgoing qrunner dies on 'None' object has no attribute... In-Reply-To: <16026.43262.815474.913850@gargle.gargle.HOWL> References: <16026.43262.815474.913850@gargle.gargle.HOWL> Message-ID: <1050767282.29001.10.camel@anthem> On Mon, 2003-04-14 at 08:26, Martin Maechler wrote: > This has happened with increasing intensity here, only since > running mailman 2.1.1 (since March 4 or so). > Note that the following is an informal bug report of what I > think at least two different problems. > > ------------------------------------------------------------------------------- > AttributeError: 'None' object has no attribute 'has_key' > Traceback (most recent call last): > File "/usr/local/app/mailman-sfs/2.1.1/bin/qrunner", line 270, in ? > main() > File "/usr/local/app/mailman-sfs/2.1.1/bin/qrunner", line 230, in main > qrunner.run() > File "/usr/local/app/mailman-sfs/2.1.1/Mailman/Queue/Runner.py", line 59, in run > filecnt = self._oneloop() > File "/usr/local/app/mailman-sfs/2.1.1/Mailman/Queue/Runner.py", line 88, in _oneloop > msg, msgdata = self._switchboard.dequeue(filebase) > File "/usr/local/app/mailman-sfs/2.1.1/Mailman/Queue/Switchboard.py", line 151, in dequeue > if data.has_key('rejection-notice'): > ------------------------------------------------------------------------------- This is fixed in cvs. > --- Bug # 2 --- > > BTW: When I do have more than one runner, things get faster, > *BUT* I sometimes get the same message delivered by more than > one of the outgoing runners. > This seems to happen (almost?) ony in the case where the queue is > almost empty. But it is quite embarrassing to this twice > delivered to everyone on the list. I think I just fixed this in cvs. There was an off-by-one error in the slice hash space calculation. -Barry From jam at jamux.com Sat Apr 19 12:59:19 2003 From: jam at jamux.com (John A. Martin) Date: Sat Apr 19 11:59:31 2003 Subject: [Mailman-Developers] Implicit destination default action RFE In-Reply-To: <1050765306.29001.4.camel@anthem> (Barry Warsaw's message of "19 Apr 2003 11:15:06 -0400") References: <200304152342.h3FNgg503516@faith.cs.utah.edu> <1050765306.29001.4.camel@anthem> Message-ID: <87r87yiilk.fsf@athene.jamux.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "baw" == Barry Warsaw >>>>> "Re: [Mailman-Developers] Implicit destination default action RFE" >>>>> 19 Apr 2003 11:15:06 -0400 baw> I have plans for rewriting the Hold/Moderate workflow so that baw> you could do something like this much more easily. Another situation that it might be possible to address better than now arises when list owners/moderators are themselves the false senders of spam as well as the real senders of ham to the list. With announce lists (v 2.0.13) these folks (or their minions) are moderating _all_ mail including their own. It would be nice if they could automatically discard all mails except those mails pretending to be from themselves which they would want to continue to moderate. jam -----BEGIN PGP SIGNATURE----- iD8DBQE+oXJJUEvv1b/iXy8RAgVPAJ9OQF2r+Sccs1A7LY8/8xlefdcYRACfRj0L HX85r9CCNmy4E3Qsh+cASug= =iUcY -----END PGP SIGNATURE----- From barry at python.org Sat Apr 19 17:25:17 2003 From: barry at python.org (Barry Warsaw) Date: Sat Apr 19 12:25:18 2003 Subject: [Mailman-Developers] Implicit destination default action RFE In-Reply-To: <20030419152052.GG22158@ferrara.linux.it> References: <200304152342.h3FNgg503516@faith.cs.utah.edu> <1050765306.29001.4.camel@anthem> <20030419152052.GG22158@ferrara.linux.it> Message-ID: <1050769489.29001.26.camel@anthem> On Sat, 2003-04-19 at 11:20, Simone Piunno wrote: > On Sat, Apr 19, 2003 at 11:15:06AM -0400, Barry A. Warsaw wrote: > > > I have plans for rewriting the Hold/Moderate workflow so that you could > > do something like this much more easily. It's probably a MM3.0 thing. > > I'm trying to extend the current workflow to allow training of > false negatives when using spambayes as the filter, so I'm very > interested to have some info on your plans :) Very briefly: Thomas Wouters and I talked a bit about this at Pycon. What I think we want to do is to apply all the tests on a message and keep track of all the results. Right now, the first test match short-circuits the rest of the tests. Once we've done that, then we want to have a way for a list admin to build a ruleset for how the tests should map into one of the following states: accept, hold, reject, discard, defer. Defer would mean to apply the next rule in the ruleset, while the others are terminal states. When a held message is shown to the moderator, they get to (perhaps optionally) see the complete match results for the message. So you might see e.g. implicit-destination, non-member-post, max-size. Spambayes filtering would simply be another test to apply. -Barry From barry at python.org Sat Apr 19 22:19:00 2003 From: barry at python.org (Barry Warsaw) Date: Sat Apr 19 17:19:02 2003 Subject: [Mailman-Developers] Removing add_members -c Message-ID: <1050787113.29001.39.camel@anthem> In bug # 659011, Jost Krieger writes about a privacy leak when using add_members -c. This has prompted me to believe that -c / --changes-msg is an anachronism that should just be removed. While I usually don't like to do this for micro releases, I think in this case it's justified. I won't (yet) delete the convert.txt files, since folks might still want to refer to these. But I'll delete them with the next full release. -Barry http://sourceforge.net/tracker/index.php?func=detail&aid=659011&group_id=103&atid=100103 From barry at python.org Sat Apr 19 23:57:26 2003 From: barry at python.org (Barry Warsaw) Date: Sat Apr 19 18:57:27 2003 Subject: [Mailman-Developers] SMTPServerDisconnected bug In-Reply-To: <036901c30162$1047ce70$0b01a8c0@mjm2> References: <036901c30162$1047ce70$0b01a8c0@mjm2> Message-ID: <1050793020.29014.41.camel@anthem> On Sat, 2003-04-12 at 22:11, Michael Meltzer wrote: > SMTPServerDisconnected: please run connect() first I've worked on the logic in SMTPDirect.py for Mailman 2.1.2. I think I've fixed this. -Barry From barry at python.org Sun Apr 20 01:20:20 2003 From: barry at python.org (Barry Warsaw) Date: Sun Apr 20 22:52:29 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <1050160045.1890.49.camel@localhost.localdomain> References: <3E973B83.8040103@compsoc.man.ac.uk> <1050160045.1890.49.camel@localhost.localdomain> Message-ID: <1050797996.29014.59.camel@anthem> Since John, Ken, and I are all American, I think it's only mildly surprising that all the source code human readable text, and the en templates are written in American English. As for supporting alternative dialects, there is a fairly concrete standard in the i18n world, however Mailman doesn't support it very well. A language specification, e.g. in HTTP's HTTP_ACCEPT_LANGUAGES header, can have a language, a country, and a variant. An example might be en_US or de_DE_PREEURO. In Mailman we have pt and pt_BR for Portuguese and Brazilian Portuguese. However, what you'd want is for pt_BR for example to simply contain the overrides to pt, or en_UK to contain just the overrides for en. That way a British translation of Mailman would only need those few entries that are different than American English (glossing over en_US for now). I definitely want to add this in a future release. For now, a non-American English translation would have to do all the work that any other translation would have to do (see README-I18N.en) except that you have an advantage. If you leave a message or template untranslated, it uses the default source string, which in this case is American English. :) I'm not in favor of changing the label from "English (USA)". -Barry From barry at python.org Mon Apr 21 04:02:29 2003 From: barry at python.org (Barry Warsaw) Date: Sun Apr 20 23:02:30 2003 Subject: [Mailman-Developers] Mailman 2.1.2 Message-ID: <1050894128.26697.6.camel@geddy> Mailman 2.1.2 is essentially in place in cvs under the Release_2_1_2 tag. I'm going to run this snapshot on python.org until tomorrow, then I'll make the release. Enjoy, -Barry From mjm at michaelmeltzer.com Mon Apr 21 00:34:27 2003 From: mjm at michaelmeltzer.com (Michael Meltzer) Date: Sun Apr 20 23:34:43 2003 Subject: [ham] Re: [Mailman-Developers] SMTPServerDisconnected bug References: <036901c30162$1047ce70$0b01a8c0@mjm2> <1050793020.29014.41.camel@anthem> Message-ID: <02d901c307b6$ea33ee20$0b01a8c0@mjm2> ThankYou very much, Your efforts and dedication are appreciated. I pulled from CVS about 10pm(mailman branch, I updated after seeing the 2.1.2 announcement but did not see anything), the code is not throwing an exception, nothing in logs/error, on the other hand "No Joy", logs/smtp-failure showing an error for every mail recipients. tail logs/smtp-failure: Apr 20 22:51:13 2003 (50845) delivery to mjmaxwell@xxx.com failed with code -1: ignore Apr 20 22:51:13 2003 (50845) delivery to CarolN8@xxx.com failed with code -1: ignore Apr 20 22:51:13 2003 (50845) delivery to al.shell@xxx.net failed with code -1: ignore Apr 20 22:51:13 2003 (50845) delivery to logicunltd@xxx.com failed with code -1: ignore Apr 20 22:51:13 2003 (50845) delivery to Dayz@xxx.com failed with code -1: ignore Apr 20 22:51:13 2003 (50845) delivery to anima13@xxx.net failed with code -1: ignore Apr 20 22:51:13 2003 (50845) delivery to sk8ersr@xxx.net failed with code -1: ignore Apr 20 22:51:13 2003 (50845) delivery to GeorgeS@xxx.tv failed with code 554: : Relay access denied Apr 20 22:51:13 2003 (50845) delivery to wchurchman@xxx.com failed with code -1: ignore Apr 20 22:51:13 2003 (50845) delivery to captrhardt@xxx.com failed with code -1: ignore MJM ----- Original Message ----- From: "Barry Warsaw" To: "Michael Meltzer" Cc: Sent: Saturday, April 19, 2003 6:57 PM Subject: [ham] Re: [Mailman-Developers] SMTPServerDisconnected bug > On Sat, 2003-04-12 at 22:11, Michael Meltzer wrote: > > > SMTPServerDisconnected: please run connect() first > > I've worked on the logic in SMTPDirect.py for Mailman 2.1.2. I think > I've fixed this. > > -Barry > > > From barry at python.org Mon Apr 21 19:11:37 2003 From: barry at python.org (Barry Warsaw) Date: Mon Apr 21 14:11:38 2003 Subject: [Mailman-Developers] Removing .mo files from cvs Message-ID: <1050949045.30943.39.camel@barry> I'm strongly considering removing .mo files from cvs and the tar.gz file, possibly for Mailman 2.1.2. - The files can easily be created at build time, even if gettext doesn't exist. We have a pure-Python version of msgfmt - It cuts out about 4MB uncompressed from the tar file - Having .mos makes creating patches more difficult. - It should greatly speed up cvs update. I'd like to know if anybody has objections to this. It would actually make the translation teams job easier since you won't have to worry about building or checking in the .mo files. I have this working in an unchecked in snapshot. Before I commit it I wanted to see if anybody has major objections or can see any flaws. -Barry From jordi at sindominio.net Mon Apr 21 21:24:24 2003 From: jordi at sindominio.net (Jordi Mallach) Date: Mon Apr 21 14:32:39 2003 Subject: [Mailman-Developers] Re: [Mailman-i18n] Removing .mo files from cvs In-Reply-To: <1050949045.30943.39.camel@barry> References: <1050949045.30943.39.camel@barry> Message-ID: <20030421182424.GA15146@nubol.int.oskuro.net> On Mon, Apr 21, 2003 at 02:17:26PM -0400, Barry Warsaw wrote: > I'm strongly considering removing .mo files from cvs and the tar.gz > file, possibly for Mailman 2.1.2. From CVS, it's a Good Thing. I'm not sure about tar.gz's. > - The files can easily be created at build time, even if gettext doesn't > exist. We have a pure-Python version of msgfmt Is this msgfmt.py distributed in the tarball? If yes, I guess it's ok. If no, I'd leave them in. If they are removed, they should probably be built by the normal "make all" rule without needing external tools (automake-made tarballs are like this). Jordi -- Jordi Mallach P?rez -- Debian developer http://www.debian.org/ jordi@sindominio.net jordi@debian.org http://www.sindominio.net/ GnuPG public key information available at http://oskuro.net/~jordi/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20030421/64ba349c/attachment.bin From barry at python.org Mon Apr 21 19:32:53 2003 From: barry at python.org (Barry Warsaw) Date: Mon Apr 21 14:32:54 2003 Subject: [Mailman-Developers] Re: [Mailman-i18n] Removing .mo files from cvs In-Reply-To: <20030421182424.GA15146@nubol.int.oskuro.net> References: <1050949045.30943.39.camel@barry> <20030421182424.GA15146@nubol.int.oskuro.net> Message-ID: <1050950318.30943.43.camel@barry> On Mon, 2003-04-21 at 14:24, Jordi Mallach wrote: > On Mon, Apr 21, 2003 at 02:17:26PM -0400, Barry Warsaw wrote: > > I'm strongly considering removing .mo files from cvs and the tar.gz > > file, possibly for Mailman 2.1.2. > > From CVS, it's a Good Thing. I'm not sure about tar.gz's. > > > - The files can easily be created at build time, even if gettext doesn't > > exist. We have a pure-Python version of msgfmt > > Is this msgfmt.py distributed in the tarball? It would be. It comes verbatim from Python's Tools/i18n/msgfmt.py. > If yes, I guess it's ok. > If no, I'd leave them in. If they are removed, they should probably be > built by the normal "make all" rule without needing external tools > (automake-made tarballs are like this). They would definitely be built with "make all". Thanks for the feedback. -Barry From mentor at alb-net.com Mon Apr 21 18:38:42 2003 From: mentor at alb-net.com (Mentor Cana) Date: Mon Apr 21 17:38:46 2003 Subject: [Mailman-Developers] virtual problem with latest CVS Message-ID: Hi, I'm trying to setup a virtual domain and it seems like I've gotten the virtual e-mail host to be properly recognized. However, the %(web_page_url) variable still does not get replaced by the virtual host URL. As a result, I'm also not getting the test list with the virtual domain to show on the virtual listinfo (or admin) pages for the virtual domain. I think I've made the proper changes in the mm_cfg.py for the virtual domains. I have the following entries: POSTFIX_STYLE_VIRTUAL_DOMAINS = ['virtual.domain'] add_virtualhost('www.virtual.domain', 'virtual.domain') add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST) VIRTUAL_HOST_OVERVIEW = 1 Have I done something wrong? What am I missing? Any help will be greatly appreciated. thanks, Mentor From barry at python.org Tue Apr 22 03:16:11 2003 From: barry at python.org (Barry Warsaw) Date: Mon Apr 21 22:16:13 2003 Subject: [ham] Re: [Mailman-Developers] SMTPServerDisconnected bug In-Reply-To: <02d901c307b6$ea33ee20$0b01a8c0@mjm2> References: <036901c30162$1047ce70$0b01a8c0@mjm2> <1050793020.29014.41.camel@anthem> <02d901c307b6$ea33ee20$0b01a8c0@mjm2> Message-ID: <1050977745.4303.16.camel@anthem> On Sun, 2003-04-20 at 23:34, Michael Meltzer wrote: > ThankYou very much, Your efforts and dedication are appreciated. I just wish we could fix the problem! > I pulled from CVS about 10pm(mailman branch, I updated after seeing the 2.1.2 announcement but did not see anything), the code is > not throwing an exception, nothing in logs/error, on the other hand "No Joy", logs/smtp-failure showing an error for every mail > recipients. > tail logs/smtp-failure: > > Apr 20 22:51:13 2003 (50845) delivery to mjmaxwell@xxx.com failed with code -1: ignore > Apr 20 22:51:13 2003 (50845) delivery to CarolN8@xxx.com failed with code -1: ignore > Apr 20 22:51:13 2003 (50845) delivery to al.shell@xxx.net failed with code -1: ignore > Apr 20 22:51:13 2003 (50845) delivery to logicunltd@xxx.com failed with code -1: ignore > Apr 20 22:51:13 2003 (50845) delivery to Dayz@xxx.com failed with code -1: ignore > Apr 20 22:51:13 2003 (50845) delivery to anima13@xxx.net failed with code -1: ignore > Apr 20 22:51:13 2003 (50845) delivery to sk8ersr@xxx.net failed with code -1: ignore > Apr 20 22:51:13 2003 (50845) delivery to GeorgeS@xxx.tv failed with code 554: : Relay access denied > Apr 20 22:51:13 2003 (50845) delivery to wchurchman@xxx.com failed with code -1: ignore > Apr 20 22:51:13 2003 (50845) delivery to captrhardt@xxx.com failed with code -1: ignore Please look in logs/smtp and try to correlate these errors with entries in that file. You should see something like "All recipients refused: " followed by a reason. The -1 code means that one of the following exceptions occurred during the send: socket.error, SMTPException, IOError. The reason in the file should give us our clue. You might also try correlating these entries with any that might be in your MTA log file. -Barry From jknapka at earthlink.net Mon Apr 21 20:18:04 2003 From: jknapka at earthlink.net (Joseph Knapka) Date: Tue Apr 22 00:32:13 2003 Subject: [Mailman-Developers] [Patch] [long] Reply-To munging: stop the madness Message-ID: <200304220118.h3M1I4Wv026227@orado.kneuro.net> And by "the madness", I mean the fact that I've seen more list traffic devoted to reply-to munging in the past year than to any other single subject. That's just silly; but Reply-To flamewars seem to break out every three months or so on every list I'm subscribed to. It's a tragic waste of bandwidth. It seems to me that the obvious way to make everyone happy is to make the presence of "Reply-To: list" headers a per-subscriber option. I have implemented something simple that achieves this goal in a fairly icky way; patch and explanation below. However, the main purpose of this message is to suggest that in some future Mailman release, "Reply-To: list" be a subscriber-centric option rather than a list-centric one. --- The patch below permits a list's accept_these_nonmembers attribute to contain entries of the form "^+listname", which causes Mailman to assume, for post-moderation purposes, that all subscribers to "listname" are also subscribed to the list being managed. For example, if list A's accept_these_nonmembers contains ^+B, then all subscribers to B will be allowed to post to A. This permits the following (suboptimal) solution to the Reply-To munging controversy: For each list L for which L.reply_goes_to_list="This list", create a second list L-no-reply-to with L-no-reply-to.reply_goes_to_list="Poster". Add L-no-reply-to to L's subscriber list. Add ^+L-no-reply-to to L.accept_these_nonmembers. Add ^+L to L-no-reply-to.accept_these_nonmembers. Now, anyone who doesn't want to get Reply-To headers subscribes to L-no-reply-to instead of L. Everyone still posts to L, however, and all traffic posted to L appears on both lists. Due to the ^+ options, anyone subscribed to either list can post to L and have their posts picked up by L-no-reply-to. (Of course, we could have allowed nonsubscribers to post to both lists, but no one on the particular list for which I produced these patches wanted to do that, due to spam problems.) This is obviously a less-than-perfect solution, which is why I'm suggesting it be done differently in a future release. I'm willing to look into implementing Reply-To as a subscriber option, but I may not have time to do so. Here are the patches, to GUIBase.py and Moderate.py. The patch to GUIBase.py simply relaxes the input validation to allow the ^+listname entries; the Moderate.py patch implements the additional moderation logic. ===File /usr/local/mailman/GUIBase.py.diff================== --- /usr/local/mailman/src/mailman-2.1.1/Mailman/Gui/GUIBase.py 2002-08-14 18:02:27.000000000 -0600 +++ GUIBase.py 2003-04-21 07:16:55.000000000 -0600 @@ -73,10 +73,11 @@ # See if this is a context that accepts regular # expressions, and that the re is legal if wtype == mm_cfg.EmailListEx and addr.startswith('^'): - try: - re.compile(addr) - except re.error: - raise ValueError + if not addr.startswith('^+'): + try: + re.compile(addr) + except re.error: + raise ValueError else: raise addrs.append(addr) ============================================================ ===File /usr/local/mailman/Moderate.py.diff================= --- /usr/local/mailman/src/mailman-2.1.1/Mailman/Handlers/Moderate.py 2002-12-30 20:28:41.000000000 -0700 +++ Moderate.py 2003-04-21 09:43:18.000000000 -0600 @@ -16,7 +16,6 @@ """Posting moderation filter. """ - import re from email.MIMEMessage import MIMEMessage from email.MIMEText import MIMEText @@ -28,6 +27,7 @@ from Mailman.i18n import _ from Mailman.Handlers import Hold from Mailman.Logging.Syslog import syslog +import Mailman.MailList @@ -115,14 +115,27 @@ def matches_p(sender, nonmembers): - # First strip out all the regular expressions - plainaddrs = [addr for addr in nonmembers if not addr.startswith('^')] + # First do list inclusions. + incAdd = [] + for linc in nonmembers: + if linc.startswith('^+'): + otherListName = linc[2:] + try: + otherList = Mailman.MailList.MailList(otherListName,lock=0) + otherMembers = otherList.getMembers() + incAdd = incAdd + otherMembers + except: + syslog.write("Moderator","Could not process list inclusion %s"%otherListName) + pass + nonmembers = nonmembers+incAdd + # Strip out all the regular expressions and list inclusions + plainaddrs = [addr for addr in nonmembers if not addr.startswith('^')] addrdict = Utils.List2Dict(plainaddrs, foldcase=1) if addrdict.has_key(sender): return 1 # Now do the regular expression matches for are in nonmembers: - if are.startswith('^'): + if are.startswith('^') and not are.startswith('^+'): try: cre = re.compile(are, re.IGNORECASE) except re.error: ============================================================ Cheers, -- Joe Knapka From philb at philb.us Tue Apr 22 01:53:35 2003 From: philb at philb.us (Phil Barnett) Date: Tue Apr 22 08:15:48 2003 Subject: [Mailman-Developers] [Patch] [long] Reply-To munging: stop the madness In-Reply-To: <200304220118.h3M1I4Wv026227@orado.kneuro.net> References: <200304220118.h3M1I4Wv026227@orado.kneuro.net> Message-ID: <200304220053.35810.philb@philb.us> On Monday 21 April 2003 9:18 pm, Joseph Knapka wrote: > However, the main purpose of > this message is to suggest that in some future Mailman release, > "Reply-To: list" be a subscriber-centric option rather than a > list-centric one. Amen. -- Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is a well-armed lamb contesting the vote. From mjm at michaelmeltzer.com Tue Apr 22 02:00:20 2003 From: mjm at michaelmeltzer.com (Michael Meltzer) Date: Tue Apr 22 08:15:51 2003 Subject: [ham] Re: [Mailman-Developers] SMTPServerDisconnected bug References: <036901c30162$1047ce70$0b01a8c0@mjm2> <1050793020.29014.41.camel@anthem> <02d901c307b6$ea33ee20$0b01a8c0@mjm2> <1050977745.4303.16.camel@anthem> Message-ID: <023a01c3088c$13078750$34f820c0@ix1x1000> Looks like I am wearing the pointy hat, The MTA log had the answer, I upgraded postfix, the new version did not permit localhost to relay by default, I had to add it by hand. kicking myself for not spotting it before. If will permit an unworthy individual , "Thank You for time and attention, this product would not be what it is without the effort you provide, I appreciate it and conmen you on the selfless sharing of your time." MJM ----- Original Message ----- From: "Barry Warsaw" To: "Michael Meltzer" Cc: Sent: Monday, April 21, 2003 10:15 PM Subject: Re: [ham] Re: [Mailman-Developers] SMTPServerDisconnected bug > On Sun, 2003-04-20 at 23:34, Michael Meltzer wrote: > > ThankYou very much, Your efforts and dedication are appreciated. > > I just wish we could fix the problem! > > > I pulled from CVS about 10pm(mailman branch, I updated after seeing the 2.1.2 announcement but did not see anything), the code is > > not throwing an exception, nothing in logs/error, on the other hand "No Joy", logs/smtp-failure showing an error for every mail > > recipients. > > > tail logs/smtp-failure: > > > > Apr 20 22:51:13 2003 (50845) delivery to mjmaxwell@xxx.com failed with code -1: ignore > > Apr 20 22:51:13 2003 (50845) delivery to CarolN8@xxx.com failed with code -1: ignore > > Apr 20 22:51:13 2003 (50845) delivery to al.shell@xxx.net failed with code -1: ignore > > Apr 20 22:51:13 2003 (50845) delivery to logicunltd@xxx.com failed with code -1: ignore > > Apr 20 22:51:13 2003 (50845) delivery to Dayz@xxx.com failed with code -1: ignore > > Apr 20 22:51:13 2003 (50845) delivery to anima13@xxx.net failed with code -1: ignore > > Apr 20 22:51:13 2003 (50845) delivery to sk8ersr@xxx.net failed with code -1: ignore > > Apr 20 22:51:13 2003 (50845) delivery to GeorgeS@xxx.tv failed with code 554: : Relay access denied > > Apr 20 22:51:13 2003 (50845) delivery to wchurchman@xxx.com failed with code -1: ignore > > Apr 20 22:51:13 2003 (50845) delivery to captrhardt@xxx.com failed with code -1: ignore > > Please look in logs/smtp and try to correlate these errors with entries > in that file. You should see something like "All recipients refused: " > followed by a reason. The -1 code means that one of the following > exceptions occurred during the send: socket.error, SMTPException, > IOError. The reason in the file should give us our clue. > > You might also try correlating these entries with any that might be in > your MTA log file. > > -Barry > > > From marc_news at merlins.org Mon Apr 21 23:34:21 2003 From: marc_news at merlins.org (Marc MERLIN) Date: Tue Apr 22 08:15:54 2003 Subject: [Mailman-Developers] Reply-To munging: stop the madness In-Reply-To: <200304220118.h3M1I4Wv026227@orado.kneuro.net> References: <200304220118.h3M1I4Wv026227@orado.kneuro.net> Message-ID: <20030422053421.GG23242@merlins.org> On Mon, Apr 21, 2003 at 07:18:04PM -0600, Joseph Knapka wrote: > > And by "the madness", I mean the fact that I've seen more list traffic > devoted to reply-to munging in the past year than to any other single > subject. That's just silly; but Reply-To flamewars seem to break out > every three months or so on every list I'm subscribed to. It's a > tragic waste of bandwidth. > It seems to me that the obvious way to make everyone happy is to make > the presence of "Reply-To: list" headers a per-subscriber option. I Amen. I spent more hours than I care to admit writing a very extensive patch that did that in many details. Unfortunately, it was a bit too complex for Barry's comfort when he thought the release was close (it ended up taking another 9 months or so, but neither of us knew that back then) I have to admit that after having seen all that personal time ultimately go to waste, I kind of lost interest. (incidently, I was also mainly writing this for the benefit of lists.sourceforge.net, but considering that 1) the site manager ultimately caved in to the few reply-to whiners 2) I was layed off a few months after that anyway, this is not something I really feel like touching anymore) > have implemented something simple that achieves this goal in a fairly > icky way; patch and explanation below. However, the main purpose of > this message is to suggest that in some future Mailman release, > "Reply-To: list" be a subscriber-centric option rather than a > list-centric one. > > --- > > The patch below permits a list's accept_these_nonmembers attribute to > contain entries of the form "^+listname", which causes Mailman to > assume, for post-moderation purposes, that all subscribers to > "listname" are also subscribed to the list being managed. For example, > if list A's accept_these_nonmembers contains ^+B, then all > subscribers to B will be allowed to post to A. This permits the > following (suboptimal) solution to the Reply-To munging controversy: > > For each list L for which L.reply_goes_to_list="This list", create > a second list L-no-reply-to with L-no-reply-to.reply_goes_to_list="Poster". > > Add L-no-reply-to to L's subscriber list. > > Add ^+L-no-reply-to to L.accept_these_nonmembers. > > Add ^+L to L-no-reply-to.accept_these_nonmembers. > > Now, anyone who doesn't want to get Reply-To headers subscribes to > L-no-reply-to instead of L. Everyone still posts to L, however, and > all traffic posted to L appears on both lists. Due to the ^+ options, > anyone subscribed to either list can post to L and have their posts > picked up by L-no-reply-to. (Of course, we could have allowed > nonsubscribers to post to both lists, but no one on the particular > list for which I produced these patches wanted to do that, due to spam > problems.) Mmmh, that's another way to do what I tried to do I guess. Not very transparent, but interesting... > This is obviously a less-than-perfect solution, which is why I'm > suggesting it be done differently in a future release. I'm willing > to look into implementing Reply-To as a subscriber option, but > I may not have time to do so. Let me save you some time: http://marc.merlins.org/tmp/replyto.diff.cvs The patch doesn't apply as is anymore since it's a year old, but you get the idea But then again, this was a year ago, and even if some patch ever makes it in, it will be years before the next stable mailman comes out, admins upgrade to it, and this problem eventually goes away :( Cheers, Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From pioppo at ferrara.linux.it Tue Apr 22 10:55:40 2003 From: pioppo at ferrara.linux.it (Simone Piunno) Date: Tue Apr 22 08:16:25 2003 Subject: [Mailman-Developers] Re: [Mailman-i18n] Removing .mo files from cvs In-Reply-To: <1050949045.30943.39.camel@barry> References: <1050949045.30943.39.camel@barry> Message-ID: <20030422075540.GA32602@pioppo.wired> luned?, 21 aprile 2003 alle 14:17:26, Barry Warsaw ha scritto: > I'm strongly considering removing .mo files from cvs and the tar.gz > file, possibly for Mailman 2.1.2. [...] > I have this working in an unchecked in snapshot. Before I commit it I > wanted to see if anybody has major objections or can see any flaws. +1 -- This signature intentionally left blank From a.carter at cordis.lu Tue Apr 22 12:55:52 2003 From: a.carter at cordis.lu (CARTER Anthony) Date: Tue Apr 22 08:17:01 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <1050797996.29014.59.camel@anthem> References: <3E973B83.8040103@compsoc.man.ac.uk> <1050160045.1890.49.camel@localhost.localdomain> <1050797996.29014.59.camel@anthem> Message-ID: <200304221155.52141.a.carter@intrasoft.lu> The changing of the label is only in this particular instance, not in the source...I never intended to step on any toes about this. We don't really care if the are americanisms in the app, just not a blatant (USA) in there. It is the European ******* (hashed but consider it a big and important part of europe) afterall ;) ;) Anyway, I removed the label from the Defaults.py file, and things seem to be fine... Thanks, Anthony Carter Cordis Operations On Sunday 20 April 2003 02:19, Barry Warsaw wrote: > Since John, Ken, and I are all American, I think it's only mildly > surprising that all the source code human readable text, and the > en templates are written in American English. > > As for supporting alternative dialects, there is a fairly concrete > standard in the i18n world, however Mailman doesn't support it very > well. A language specification, e.g. in HTTP's HTTP_ACCEPT_LANGUAGES > header, can have a language, a country, and a variant. An example might > be en_US or de_DE_PREEURO. In Mailman we have pt and pt_BR for > Portuguese and Brazilian Portuguese. > > However, what you'd want is for pt_BR for example to simply contain the > overrides to pt, or en_UK to contain just the overrides for en. That > way a British translation of Mailman would only need those few entries > that are different than American English (glossing over en_US for now). > I definitely want to add this in a future release. > > For now, a non-American English translation would have to do all the > work that any other translation would have to do (see README-I18N.en) > except that you have an advantage. If you leave a message or template > untranslated, it uses the default source string, which in this case is > American English. :) > > I'm not in favor of changing the label from "English (USA)". > > -Barry > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From barry at python.org Tue Apr 22 13:27:45 2003 From: barry at python.org (Barry Warsaw) Date: Tue Apr 22 08:27:46 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <200304221155.52141.a.carter@intrasoft.lu> References: <3E973B83.8040103@compsoc.man.ac.uk> <1050160045.1890.49.camel@localhost.localdomain> <1050797996.29014.59.camel@anthem> <200304221155.52141.a.carter@intrasoft.lu> Message-ID: <1051014435.12939.3.camel@anthem> On Tue, 2003-04-22 at 05:55, CARTER Anthony wrote: > The changing of the label is only in this particular instance, not in the > source. That's the beauty of open source! :) -Barry From barry at python.org Tue Apr 22 13:31:10 2003 From: barry at python.org (Barry Warsaw) Date: Tue Apr 22 08:31:11 2003 Subject: [ham] Re: [Mailman-Developers] SMTPServerDisconnected bug In-Reply-To: <023a01c3088c$13078750$34f820c0@ix1x1000> References: <036901c30162$1047ce70$0b01a8c0@mjm2> <1050793020.29014.41.camel@anthem> <02d901c307b6$ea33ee20$0b01a8c0@mjm2> <1050977745.4303.16.camel@anthem> <023a01c3088c$13078750$34f820c0@ix1x1000> Message-ID: <1051014641.12971.9.camel@anthem> On Tue, 2003-04-22 at 01:00, Michael Meltzer wrote: > Looks like I am wearing the pointy hat, The MTA log had the answer, I upgraded postfix, the new version did not permit localhost to > relay by default, I had to add it by hand. kicking myself for not spotting it before. No problem, glad it's working now! Please let me know how the new SMTPDirect.py module works for you. > If will permit an unworthy individual , "Thank You for time and attention, this product would not be what it is without the effort > you provide, I appreciate it and conmen you on the selfless sharing of your time." No problem, -Barry From barry at python.org Tue Apr 22 13:36:28 2003 From: barry at python.org (Barry Warsaw) Date: Tue Apr 22 08:36:28 2003 Subject: [Mailman-Developers] Reply-To munging: stop the madness In-Reply-To: <20030422053421.GG23242@merlins.org> References: <200304220118.h3M1I4Wv026227@orado.kneuro.net> <20030422053421.GG23242@merlins.org> Message-ID: <1051014959.12939.14.camel@anthem> On Tue, 2003-04-22 at 01:34, Marc MERLIN wrote: > But then again, this was a year ago, and even if some patch ever makes > it in, it will be years before the next stable mailman comes out, admins > upgrade to it, and this problem eventually goes away :( Gawd, I hope not, but since I'm not actually paid to work on Mailman any more, who knows? I do feel bad that Marc's hard work never made it in, and I've apologized to him for it. At some point, we'll look at this again and maybe there's a way to architect it to alleviate my concerns. no-good-deed-goes-unpunished-ly y'rs, -Barry From mal at lemburg.com Tue Apr 22 15:54:01 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Apr 22 08:54:35 2003 Subject: [Mailman-Developers] Header & Footer for non-ASCII messages Message-ID: <3EA53B69.9020001@lemburg.com> We have run into a problem which is probably not uncommon for international mailing lists: whenever a message is sent that does not have US-ASCII as content type, header and footer are attached to this message via additional mime parts. This doesn't really look nice in the mail applications. Wouldn't it be wise to decode the message payload and prepend/ append the header and footer properly encoded to the payload instead ? -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Apr 22 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2003, Charleroi, Belgium: 63 days left From charlie at begeistert.org Tue Apr 22 16:30:42 2003 From: charlie at begeistert.org (Charlie Clark) Date: Tue Apr 22 09:30:37 2003 Subject: [Mailman-Developers] Re: Mailman-Developers English (USA) In-Reply-To: References: Message-ID: <20030422153042.2165.15@wonderland.1051009163.fake> Barry was (w)riting: > Since John, Ken, and I are all American, I think it's only mildly > surprising that all the source code human readable text, and the > en templates are written in American English. I think there's an oxymoron in there somewhere! as American English != human readable . Going back to what the real problem with the "language" selection is: a conflation of user interface elements (user-language settings) and the code-page settings. The two things need to be kept separate and both should be configurable. We just had an "interesting" situation where a UTF-8 body gets a plain text MIME attachment for the footer and as we couldn't find a way in Mailman to enforce UTF-8 for the whole mail had to find a work-around outside of Mailman, ie. insert the footer in body. Being able to set the code page for a list would seem to make sense. What are the lists thoughts on this issue? Charlie From marc_news at merlins.org Tue Apr 22 08:00:33 2003 From: marc_news at merlins.org (Marc MERLIN) Date: Tue Apr 22 10:00:39 2003 Subject: [Mailman-Developers] Reply-To munging: stop the madness In-Reply-To: <1051014959.12939.14.camel@anthem> References: <200304220118.h3M1I4Wv026227@orado.kneuro.net> <20030422053421.GG23242@merlins.org> <1051014959.12939.14.camel@anthem> Message-ID: <20030422140033.GE5933@merlins.org> On Tue, Apr 22, 2003 at 08:35:59AM -0400, Barry Warsaw wrote: > On Tue, 2003-04-22 at 01:34, Marc MERLIN wrote: > > But then again, this was a year ago, and even if some patch ever makes > > it in, it will be years before the next stable mailman comes out, admins > > upgrade to it, and this problem eventually goes away :( > > Gawd, I hope not, but since I'm not actually paid to work on Mailman any > more, who knows? Note, I didn't mean to imply that it'd take you years to get 2.3 out the door, but that + people upgrading probably will. Most people still run mailman 2.0 > I do feel bad that Marc's hard work never made it in, and I've (...) Sorry, that wasn't meant as a slam, I know you spent time looking at this and you tried to put it in. I was more trying to explain that it's a sore point for me and I was not really looking forward to working on it again (before someone asked me to update the patch for mm 2.1) Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From jeffh at gryphongardens.com Tue Apr 22 10:32:06 2003 From: jeffh at gryphongardens.com (Jeff Hahn) Date: Tue Apr 22 10:34:41 2003 Subject: [Mailman-Developers] Header & Footer for non-ASCII messages In-Reply-To: <3EA53B69.9020001@lemburg.com> Message-ID: <000c01c308db$f2d8cb60$14cca8c0@internal.gryphongardens.com> > -----Original Message----- > From: M.-A. Lemburg > Sent: Tuesday, April 22, 2003 7:54 AM > Subject: [Mailman-Developers] Header & Footer for non-ASCII messages > > We have run into a problem which is probably not uncommon for > international mailing lists: whenever a message is sent that does > not have US-ASCII as content type, header and footer are attached > to this message via additional mime parts. > Unfortunately this is a problem here in the US as well. Various Microsoft clients and other clients as well create character set problems, especially when using Mailman content filtering to convert mail to plain test. The only solution we've come up with is to pre-process list mail through demime to convert mail to plain text before being process by mailman. I realize that mailman content filtering is a more "general purpose" filter that has other jobs besides plain text conversions, but I would really like to avoid pre-processing list mail. Demime converts mail to 'Content-Type: text/plain; charset="us-ascii"' and at this point headers and footers are no problem. I realize that this won't work on international lists. I don't really have a suggestion for the solution. -Jeff From rommel at suse.de Tue Apr 22 18:04:30 2003 From: rommel at suse.de (Heiko Rommel) Date: Tue Apr 22 11:01:50 2003 Subject: [Mailman-Developers] suppressing appending of generic welcome message Message-ID: Hi, when sending welcome messages to new subscribees I need a way to suppress the automatically appended " To post to this list, send your email to: alist@suse.de General information about the mailing list is at: ... " for some lists. I need this because the mail list (web) server is on an internal network. However, I'd like to make some lists available to the public (via email only). Is there currently a way to accompish that ? Heiko Rommel SuSE Linux AG From tneff at bigfoot.com Tue Apr 22 12:16:24 2003 From: tneff at bigfoot.com (Tom Neff) Date: Tue Apr 22 11:16:28 2003 Subject: [Mailman-Developers] Re: Reply-To munging & member_aliases In-Reply-To: References: Message-ID: <469658171.1051010184@[192.168.254.64]> Reality check: Most mailers today already theoretically give users some kind of option over where a reply goes. The problems arise because in the real world, users pay no attention to that stuff. They barely know how to hit Send. So what in the world would delude us into thinking that if we introduced some kind of per-member Reply-To: option, these people would know or bother to use it? They'll never touch it! The only people who will change it are the people who are already savvy enough to direct their replies correctly without it. Also, on lists of the COMET-ANNOUNCE-L variety, where the admin has specifically set a reply policy or reply address, it seems positively harmful to allow individual members to override it. I do not see the usefulness of this per-member patch. The per-member patch that I WOULD like to see added is member_aliases - a list of alternate addresses under which a given member posts. "Address creep" is a daily plague, and it's not adequately answered by creating nomail "ghost members" or stuffing the accept_these_nonmembers pool, because when people leave things get out of sync. If the per-user options screen allowed both user and admin to edit an alias list, and if we wrote a little add_member_alias script, things would go a lot easier. From jknapka at earthlink.net Tue Apr 22 18:08:13 2003 From: jknapka at earthlink.net (Joseph Knapka) Date: Tue Apr 22 13:08:14 2003 Subject: [Mailman-Developers] Re: Reply-To munging & member_aliases In-Reply-To: <469658171.1051010184@[192.168.254.64]> References: <469658171.1051010184@[192.168.254.64]> Message-ID: Tom Neff writes: > Reality check: Most mailers today already theoretically give users some > kind of option over where a reply goes. The problems arise because in the > real world, users pay no attention to that stuff. They barely know how to > hit Send. > > So what in the world would delude us into thinking that if we introduced > some kind of per-member Reply-To: option, these people would know or bother > to use it? They'll never touch it! The only people who will change it are > the people who are already savvy enough to direct their replies correctly > without it. > > Also, on lists of the COMET-ANNOUNCE-L variety, where the admin has > specifically set a reply policy or reply address, it seems positively harmful > to allow individual members to override it. > > I do not see the usefulness of this per-member patch. The usefulness of a subscriber reply-to option is that it should reduce the bandwidth devoted to reply-to munging dramatically. Rather than each "let's change reply-to" post turing into a several-hundred-post thread, as they always seem to, those threads would be squashed by a single reply: "If you don't like it the way it is, go to this URL and change it." Cheers, -- Joe Knapka From tneff at bigfoot.com Tue Apr 22 14:34:35 2003 From: tneff at bigfoot.com (Tom Neff) Date: Tue Apr 22 13:34:42 2003 Subject: [Mailman-Developers] Re: Reply-To munging & member_aliases In-Reply-To: References: <469658171.1051010184@[192.168.254.64]> Message-ID: <477949093.1051018475@[192.168.254.64]> --On Tuesday, April 22, 2003 8:04 AM -0600 Joseph Knapka wrote: > The usefulness of a subscriber reply-to option is that it should > reduce the bandwidth devoted to reply-to munging dramatically. Rather > than each "let's change reply-to" post turing into a > several-hundred-post thread, as they always seem to, those threads > would be squashed by a single reply: "If you don't like it the way it > is, go to this URL and change it." Except that doesn't change it for the whole list, which is what the "let's change reply-to" complainers want - it only changes it for replies from that particular person. The bandwidth will still be consumed. From jam at jamux.com Tue Apr 22 14:53:21 2003 From: jam at jamux.com (John A. Martin) Date: Tue Apr 22 13:53:26 2003 Subject: [Mailman-Developers] Re: Reply-To munging & member_aliases In-Reply-To: (Joseph Knapka's message of "22 Apr 2003 08:04:31 -0600") References: <469658171.1051010184@[192.168.254.64]> Message-ID: <873ckah10u.fsf@athene.jamux.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "jk" == Joseph Knapka >>>>> "Re: [Mailman-Developers] Re: Reply-To munging & member_aliases" >>>>> 22 Apr 2003 08:04:31 -0600 jk> Tom Neff writes: >> I do not see the usefulness of this per-member patch. jk> The usefulness of a subscriber reply-to option is that it ...takes the management of the list out of the list owner's hands. If there is to be such an option one would hope that the list owner would be able to determine whether or not it is available to the subscribers of his particular list. jam -----BEGIN PGP SIGNATURE----- iD8DBQE+pYGDUEvv1b/iXy8RAovrAJ0boffUsnQKdSNZ3gOgFM2bI0weLwCfabz5 FuUIk/zI4Cu2R3VYl7l+yoQ= =oW4m -----END PGP SIGNATURE----- From marc_news at merlins.org Tue Apr 22 12:10:03 2003 From: marc_news at merlins.org (Marc MERLIN) Date: Tue Apr 22 14:10:09 2003 Subject: [Mailman-Developers] Re: Reply-To munging & member_aliases In-Reply-To: <477949093.1051018475@[192.168.254.64]> References: <469658171.1051010184@[192.168.254.64]> <477949093.1051018475@[192.168.254.64]> Message-ID: <20030422181003.GR5933@merlins.org> On Tue, Apr 22, 2003 at 01:34:35PM -0400, Tom Neff wrote: > Except that doesn't change it for the whole list, which is what the "let's > change reply-to" complainers want - it only changes it for replies from that > particular person. The bandwidth will still be consumed. reply-to whiners can have the option they want. Those who feel that they need to say how the list should be for others can have their posting priviledges removed. It's simple, really :-) Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From che at debian.org Tue Apr 22 15:22:49 2003 From: che at debian.org (Ben Gertzfield) Date: Tue Apr 22 17:22:19 2003 Subject: [Mailman-Developers] Header & Footer for non-ASCII messages In-Reply-To: <3EA53B69.9020001@lemburg.com> References: <3EA53B69.9020001@lemburg.com> Message-ID: <3EA5B2A9.4030304@debian.org> M.-A. Lemburg wrote: > We have run into a problem which is probably not uncommon for > international mailing lists: whenever a message is sent that does > not have US-ASCII as content type, header and footer are attached > to this message via additional mime parts. > > This doesn't really look nice in the mail applications. I've done a lot of looking in to this, and "the mail applications" that you mention are pretty much just Outlook, which is pretty broken with inline attachments. Just about every other mail reader will inline the header/footer MIME parts, but Outlook shows them as separate attachments for no good reason. Mailman does everything it can do to hint to the MUA to keep the header and footer MIME parts inline with the body, but Outlook just ignores this. > Wouldn't it be wise to decode the message payload and prepend/ > append the header and footer properly encoded to the payload > instead ? This just doesn't work. We have to assume the header and footer are in the same charset as the language of the mailing list (by default, us-ascii). If a message posted is in a language that doesn't match the language of the mailing list (say, UTF-8), and the header and footer of the list are ISO-8859-1, you can't just "decode" them both and concatenate them, as this will make a message with two unrelated character sets combined. If you can come up with any hack to make Outlook include MIME attachments inline, it would be appreciated. That's really all we need, because then we'll have the best of all worlds. Ben From mal at lemburg.com Wed Apr 23 00:33:10 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Apr 22 17:34:16 2003 Subject: [Mailman-Developers] Header & Footer for non-ASCII messages In-Reply-To: <3EA5B2A9.4030304@debian.org> References: <3EA53B69.9020001@lemburg.com> <3EA5B2A9.4030304@debian.org> Message-ID: <3EA5B516.1010307@lemburg.com> Ben Gertzfield wrote: > M.-A. Lemburg wrote: > >> We have run into a problem which is probably not uncommon for >> international mailing lists: whenever a message is sent that does >> not have US-ASCII as content type, header and footer are attached >> to this message via additional mime parts. >> >> This doesn't really look nice in the mail applications. > > I've done a lot of looking in to this, and "the mail applications" that > you mention are pretty much just Outlook, which is pretty broken with > inline attachments. Just about every other mail reader will inline the > header/footer MIME parts, but Outlook shows them as separate attachments > for no good reason. Hmm, I'm using Mozilla's mail app and it doesn't look right in there either. > Mailman does everything it can do to hint to the MUA to keep the header > and footer MIME parts inline with the body, but Outlook just ignores this. > >> Wouldn't it be wise to decode the message payload and prepend/ >> append the header and footer properly encoded to the payload >> instead ? > > This just doesn't work. We have to assume the header and footer are in > the same charset as the language of the mailing list (by default, > us-ascii). Right. > If a message posted is in a language that doesn't match the language of > the mailing list (say, UTF-8), and the header and footer of the list are > ISO-8859-1, you can't just "decode" them both and concatenate them, as > this will make a message with two unrelated character sets combined. Uhm, you can decode both into Unicode, paste them together and then encode the result again in either the mailing lists default charset or UTF-8. > If you can come up with any hack to make Outlook include MIME > attachments inline, it would be appreciated. That's really all we need, > because then we'll have the best of all worlds. Not really -- inline MIME parts simply don't look right for things like headers and footers. They are fine for images and the like, but headers and footers really belong right into the main message text. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Apr 22 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2003, Charleroi, Belgium: 63 days left From mjm at michaelmeltzer.com Tue Apr 22 19:18:07 2003 From: mjm at michaelmeltzer.com (Michael Meltzer) Date: Tue Apr 22 18:18:42 2003 Subject: [ham] Re: [Mailman-Developers] SMTPServerDisconnected bug References: <036901c30162$1047ce70$0b01a8c0@mjm2> <1050793020.29014.41.camel@anthem> <02d901c307b6$ea33ee20$0b01a8c0@mjm2> <1050977745.4303.16.camel@anthem> <023a01c3088c$13078750$34f820c0@ix1x1000> <1051014641.12971.9.camel@anthem> Message-ID: <018001c3091d$0cf85a10$34f820c0@ix1x1000> It has been running for the last 18 hours+-, about 20 posts leading to 3000 messages, plus an other 12 +- administration messages, so far so good, everything looks clean and the user are happy, good job. MJM ----- Original Message ----- From: "Barry Warsaw" To: "Michael Meltzer" Cc: Sent: Tuesday, April 22, 2003 8:30 AM Subject: Re: [ham] Re: [Mailman-Developers] SMTPServerDisconnected bug > On Tue, 2003-04-22 at 01:00, Michael Meltzer wrote: > > Looks like I am wearing the pointy hat, The MTA log had the answer, I upgraded postfix, the new version did not permit localhost to > > relay by default, I had to add it by hand. kicking myself for not spotting it before. > > No problem, glad it's working now! Please let me know how the new > SMTPDirect.py module works for you. > > > If will permit an unworthy individual , "Thank You for time and attention, this product would not be what it is without the effort > > you provide, I appreciate it and conmen you on the selfless sharing of your time." > > No problem, > -Barry > > > > From che at debian.org Tue Apr 22 16:21:11 2003 From: che at debian.org (Ben Gertzfield) Date: Tue Apr 22 18:20:42 2003 Subject: [Mailman-Developers] Header & Footer for non-ASCII messages In-Reply-To: <3EA5B516.1010307@lemburg.com> References: <3EA53B69.9020001@lemburg.com> <3EA5B2A9.4030304@debian.org> <3EA5B516.1010307@lemburg.com> Message-ID: <3EA5C057.5000509@debian.org> M.-A. Lemburg wrote: > Uhm, you can decode both into Unicode, paste them together and then > encode the result again in either the mailing lists default charset > or UTF-8. This is a definite possibility. But then we risk changing the actual contents of the message -- transforming everything to UTF-8 and back is not an operation that's guaranteed one-to-one. If I get some time, I'll try to code this up. Ben From aks at stebbens.org Tue Apr 22 16:25:20 2003 From: aks at stebbens.org (Alan K. Stebbens) Date: Tue Apr 22 18:25:31 2003 Subject: [Mailman-Developers] Re: Reply-To munging & member_aliases In-Reply-To: <469658171.1051010184@[192\.168\.254\.64]> References: <469658171.1051010184@[192.168.254.64]> Message-ID: <70405499217.20030422152520@stebbens.org> TN> The per-member patch that I WOULD like to see added is member_aliases - TN> a list of alternate addresses under which a given member posts. "Address TN> creep" is a daily plague, and it's not adequately answered by creating TN> nomail "ghost members" or stuffing the accept_these_nonmembers pool, TN> because when people leave things get out of sync. If the per-user TN> options screen allowed both user and admin to edit an alias list, and if TN> we wrote a little add_member_alias script, things would go a lot easier. I agree with this suggestion. If you check out "www.topica.com", the following functionality is provided: a. multiple addresses per person b. when a person is subscribed to a list, a submission from *any* of a that person's email aliases is acceptable c. for each subscriber, each list has a designated *primary* distribution address -- one of the subscriber's email aliases I was thinking of hacking Mailman to support this functionality, but was going to first ask if it might already be "in the works". Is it? -- Best regards, Alan K. Stebbens (Voice/Fax: +1.866.579.0801) Wear me as a seal upon your heart, as a seal upon your arm; for love is strong as death, passion cruel as the grave; it blazes up like blazing fire, fiercer than any flame. -- [Song of Solomon 8:6 (NEB)] From pioppo at ferrara.linux.it Wed Apr 23 01:32:27 2003 From: pioppo at ferrara.linux.it (Simone Piunno) Date: Tue Apr 22 18:35:12 2003 Subject: [Mailman-Developers] Header & Footer for non-ASCII messages In-Reply-To: <3EA5C057.5000509@debian.org> References: <3EA53B69.9020001@lemburg.com> <3EA5B2A9.4030304@debian.org> <3EA5B516.1010307@lemburg.com> <3EA5C057.5000509@debian.org> Message-ID: <20030422223227.GA5866@ferrara.linux.it> On Tue, Apr 22, 2003 at 03:21:11PM -0700, Ben Gertzfield wrote: > >Uhm, you can decode both into Unicode, paste them together and then > >encode the result again in either the mailing lists default charset > >or UTF-8. I'd suggest trying this sequence for charset down-conversion: - plaintext (e.g. us-ascii) - the list's default charset - utf-8 maybe just before utf-8 we could have a per-language (or per-list) configurable array of preferred fallbacks, just to kill every other complaint :) > This is a definite possibility. But then we risk changing the actual > contents of the message -- transforming everything to UTF-8 and back > is not an operation that's guaranteed one-to-one. Absolutely agreed, so the whole procedure should be a per-list option, defaulting to off. -- Simone Piunno -- http://members.ferrara.linux.it/pioppo .------- Adde parvum parvo magnus acervus erit -------. Ferrara Linux Users Group - http://www.ferrara.linux.it Deep Space 6, IPv6 on Linux - http://www.deepspace6.net GNU Mailman, Mailing List Manager - http://www.list.org `-------------------------------------------------------' From tkikuchi at is.kochi-u.ac.jp Wed Apr 23 09:45:30 2003 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue Apr 22 19:47:22 2003 Subject: [Mailman-Developers] Header & Footer for non-ASCII messages References: <3EA53B69.9020001@lemburg.com> Message-ID: <3EA5D41A.2030104@is.kochi-u.ac.jp> Hi, Have you tried this patch ? http://sourceforge.net/tracker/?func=detail&aid=664209&group_id=103&atid=300103 Good luck. M.-A. Lemburg wrote: > We have run into a problem which is probably not uncommon for > international mailing lists: whenever a message is sent that does > not have US-ASCII as content type, header and footer are attached > to this message via additional mime parts. > > This doesn't really look nice in the mail applications. > > Wouldn't it be wise to decode the message payload and prepend/ > append the header and footer properly encoded to the payload > instead ? > -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From dan.mick at sun.com Tue Apr 22 17:52:24 2003 From: dan.mick at sun.com (Dan Mick) Date: Tue Apr 22 19:58:28 2003 Subject: [Mailman-Developers] Reply-To munging: stop the madness In-Reply-To: <20030422053421.GG23242@merlins.org> References: <200304220118.h3M1I4Wv026227@orado.kneuro.net> <20030422053421.GG23242@merlins.org> Message-ID: <3EA5D5B8.7020807@sun.com> > On Mon, Apr 21, 2003 at 07:18:04PM -0600, Joseph Knapka wrote: >>It seems to me that the obvious way to make everyone happy is to make >>the presence of "Reply-To: list" headers a per-subscriber option. I > It *is* a per-subscriber option. It's called "reply all". Fume. From marty at penguinarts.com Wed Apr 23 01:57:43 2003 From: marty at penguinarts.com (Marty Galyean) Date: Tue Apr 22 20:57:44 2003 Subject: [Mailman-Developers] Reply-To munging: stop the madness In-Reply-To: <3EA5D5B8.7020807@sun.com> References: <200304220118.h3M1I4Wv026227@orado.kneuro.net> <20030422053421.GG23242@merlins.org> <3EA5D5B8.7020807@sun.com> Message-ID: <1051058723.1495.35.camel@localhost.localdomain> On Tue, 2003-04-22 at 17:52, Dan Mick wrote: > It *is* a per-subscriber option. It's called "reply all". I'm not sure if it is in the spirit of a typical software 'option' if you have to decide and choose 'reply all' every time. Usually 'option' means a setting you set and forget. When cruising through my mail from various lists I inevitably forget to 'reply all' on lists where it is warranted and I end up sending a second time to the list in a separate email. What is really needed is for the user to be able to set on a folder by folder (or even sender by sender) default reply behavior in the *mailer*. But this is no different than allowing them to specify it on the list server really, I suppose. Also, 'reply all' can be very annoying if the original message has a bunch of other cc addys going on. It comes back to an adage that formed in my mind years ago after dealing with certain project managers and clients: By definition, there are no simple solutions to complex problems. Complexity must be unraveled on some level, either in code, or by the user and the unraveling is never simple because the problem is complex. Which leads to the corollary: Complex code solutions will never be satisfactory to the user if the user doesn't take the time to comprehend the internal complexity to a meaningful degree (at least at the user interface level) so that they work with the grain of the solution instead of against it. The last hurdle above makes some complex problems pointless to tackle at all for tools of mass use because they will rarely be useful to the user because they will never see the value of studying the complexity enough to grok proper use of the 'solution'. So it comes full circle in that complex people will always write complex code for themselves and other complex people and simple people will simply have to sink (drown in the confusion of options) or swim (take the time to understand the options and the effect they have) or deal with a simpler version that has fewer options. I really thinkg that the 'tech stock bubble' popped because marketing departments (and sometimes even developers) were promising simple solutions to complex problems and there wasn't enough real money to engineer complex solutions in the simple time/budget frames promised to venture capitalists and consumers. People will always have to understand tools to use them effectively. And complex solutions to complex problems will always cost more in time/money than simple solutions. There is no way around it. I personally prefer lists that always reply to the list. This is because lists interface with all types of people and I refuse to force education on anyone, not out of high ideal, but out of exasperation. So I 'vote' for the user pressing the 'Delete' button and creating filters for dealing with too much traffic over using 'Reply-All' button judiciously to limit traffic on the post end. Not to mention the fact that by using 'reply' instead of 'reply all' you are basically deciding for the entire list membership whether your response is useful to them or not. I prefer people sling it out there and let the reader decide if it's useful. Ok, I feel better now. :) Marty From jknapka at earthlink.net Wed Apr 23 07:22:36 2003 From: jknapka at earthlink.net (Joseph Knapka) Date: Wed Apr 23 02:22:37 2003 Subject: [Mailman-Developers] Reply-To munging: stop the madness In-Reply-To: <1051058723.1495.35.camel@localhost.localdomain> References: <200304220118.h3M1I4Wv026227@orado.kneuro.net> <20030422053421.GG23242@merlins.org> <3EA5D5B8.7020807@sun.com> <1051058723.1495.35.camel@localhost.localdomain> Message-ID: See, this is exactly the sort of traffic I wish to see the end of :-) Can't... resist... posting... ...urgh... followup.... Marty Galyean writes: > On Tue, 2003-04-22 at 17:52, Dan Mick wrote: > > It *is* a per-subscriber option. It's called "reply all". > > > > I'm not sure if it is in the spirit of a typical software 'option' if > you have to decide and choose 'reply all' every time. Usually 'option' > means a setting you set and forget. > > When cruising through my mail from various lists I inevitably forget to > 'reply all' on lists where it is warranted and I end up sending a second > time to the list in a separate email. Hmm, I just did that with this message :-) Why doesn't this list munge Reply-To???? You guys must be a bunch of real losers!!!!!!!!!!! > What is really needed is for the user to be able to set on a folder by > folder (or even sender by sender) default reply behavior in the > *mailer*. But this is no different than allowing them to specify it on > the list server really, I suppose. Yes, it is. Because expecting this functionality in a client means waiting for every client to implement it; people choose their email client for many reasons besides the useful array of "reply" functions they display. Whereas implementing the option at the list server means that everyone gets the benefit of the fuctionality, regardless of what client they use. The list server is the most potent lever for addressing this particular issue - and note that IMO, the *only* reason to address the reply-to-munging issue *at all* is to make the damned flamewars go away. So doing the simplest thing that can possibly work, as opposed to the most elegant or most useful, is called for. (Obviously, there are other listservers in the world besides Mailman, but there are far fewer of them than there are email clients. And Mailman seems to be well on the way to dominating the market at this point; I think every list I'm subscribed to uses it. But that's a totally subjective impression, and therefore probably worth what you're paying for it, or maybe a smidgen less.) [scissors of brevity] Cheers, -- Joe Knapka From mal at lemburg.com Wed Apr 23 11:54:02 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Apr 23 04:54:49 2003 Subject: [Mailman-Developers] Header & Footer for non-ASCII messages In-Reply-To: <3EA5D41A.2030104@is.kochi-u.ac.jp> References: <3EA53B69.9020001@lemburg.com> <3EA5D41A.2030104@is.kochi-u.ac.jp> Message-ID: <3EA654AA.5050904@lemburg.com> Tokio Kikuchi wrote: > Hi, > > Have you tried this patch ? > > http://sourceforge.net/tracker/?func=detail&aid=664209&group_id=103&atid=300103 Thanks. This looks like a start, but I'd add your new if case as elif to the existing one; you'll also have to deal with errors from trying to decode the payload and have to make sure that in case of a conversion error, the default action (add MIME parts) is chosen as fallback. > Good luck. > > M.-A. Lemburg wrote: > >> We have run into a problem which is probably not uncommon for >> international mailing lists: whenever a message is sent that does >> not have US-ASCII as content type, header and footer are attached >> to this message via additional mime parts. >> >> This doesn't really look nice in the mail applications. >> >> Wouldn't it be wise to decode the message payload and prepend/ >> append the header and footer properly encoded to the payload >> instead ? >> > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Apr 23 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2003, Charleroi, Belgium: 62 days left From nb at thinkcoach.com Wed Apr 23 12:14:30 2003 From: nb at thinkcoach.com (Norbert Bollow) Date: Wed Apr 23 04:58:07 2003 Subject: [Mailman-Developers] Reply-To munging: stop the madness In-Reply-To: <1051058723.1495.35.camel@localhost.localdomain> (message from Marty Galyean on 22 Apr 2003 18:45:16 -0600) References: <200304220118.h3M1I4Wv026227@orado.kneuro.net> <20030422053421.GG23242@merlins.org> <3EA5D5B8.7020807@sun.com> <1051058723.1495.35.camel@localhost.localdomain> Message-ID: <20030423091430.730FD2E910@quill.cisto.com> Marty Galyean wrote: > On Tue, 2003-04-22 at 17:52, Dan Mick wrote: > > It *is* a per-subscriber option. It's called "reply all". > > > > I'm not sure if it is in the spirit of a typical software 'option' if > you have to decide and choose 'reply all' every time. Usually 'option' > means a setting you set and forget. > > When cruising through my mail from various lists I inevitably forget to > 'reply all' on lists where it is warranted and I end up sending a second > time to the list in a separate email. I think there's a pretty straightforward way in which this problem could be solved, by using a little robot for managing all you Mailman list subscriptions. I've wiki'd this idea up at http://wiki.dotgnu.org/GroupsBot Greetings, Norbert. -- Founder & Steering Committee member of http://gnu.org/projects/dotgnu/ Free Software Business Strategy Guide ---> http://FreeStrategy.info Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://norbert.ch From nb at thinkcoach.com Wed Apr 23 13:01:01 2003 From: nb at thinkcoach.com (Norbert Bollow) Date: Wed Apr 23 05:45:34 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <1050797996.29014.59.camel@anthem> (message from Barry Warsaw on 19 Apr 2003 20:19:56 -0400) References: <3E973B83.8040103@compsoc.man.ac.uk> <1050160045.1890.49.camel@localhost.localdomain> <1050797996.29014.59.camel@anthem> Message-ID: <20030423100101.779942FAFA@quill.cisto.com> > Since John, Ken, and I are all American, I think it's only mildly > surprising that all the source code human readable text, and the > en templates are written in American English. >From my European perspective I'd say that that's not a problem for most people around here. Well it's possible that some folks in the UK might care enough to do what it takes to "fix" the spelling from their perspective, but in the majority of Europe (where English is not spoken natively anyway) the locale-dependant details of spelling don't matter at all. > I'm not in favor of changing the label from "English (USA)". The "English (USA)" label *is* a problem. Please don't underestimate the strong anti-USA feelings in significant parts of the world. For example here in Switzerland, many people feel that US politicians and lawyers have blackmailed the Swiss banks for a couple of billion dollars a few years ago. Many other countries have their own historic roots for bitter feelings towards the USA. Then there are *many* people in many countries who are upset about more recent events that I don't want to mention explicitly in order to avoid sparking a flame war. For example, think of an Arab with a good command of the English language who'd like to subscribe to a technical mailing list. Wouldn't the "English (USA)" label feel like a slap in the face for such a user? Greetings, Norbert. -- Founder & Steering Committee member of http://gnu.org/projects/dotgnu/ Free Software Business Strategy Guide ---> http://FreeStrategy.info Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://norbert.ch From a.carter at cordis.lu Wed Apr 23 13:51:09 2003 From: a.carter at cordis.lu (CARTER Anthony) Date: Wed Apr 23 06:51:21 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <20030423100101.779942FAFA@quill.cisto.com> References: <3E973B83.8040103@compsoc.man.ac.uk> <1050797996.29014.59.camel@anthem> <20030423100101.779942FAFA@quill.cisto.com> Message-ID: <200304231251.09520.a.carter@intrasoft.lu> Extremely good point Norbert... Televisions were invented in Britain...Doesn't mean that every tele has to start up with a union jack on its screen...huh? Besides, for my purpose it wasn't cause we dislike the USA, it is cause it is a European Union institution that requires to be distinguished as a seperate entity completely to the US. It is politics, nothing more, nothing less... Anthony On Wednesday 23 April 2003 12:01, Norbert Bollow wrote: > > Since John, Ken, and I are all American, I think it's only mildly > > surprising that all the source code human readable text, and the > > en templates are written in American English. > > From my European perspective I'd say that that's not a problem for > most people around here. Well it's possible that some folks in the > UK might care enough to do what it takes to "fix" the spelling from > their perspective, but in the majority of Europe (where English is > not spoken natively anyway) the locale-dependant details of spelling > don't matter at all. > > > I'm not in favor of changing the label from "English (USA)". > > The "English (USA)" label *is* a problem. Please don't underestimate > the strong anti-USA feelings in significant parts of the world. For > example here in Switzerland, many people feel that US politicians and > lawyers have blackmailed the Swiss banks for a couple of billion > dollars a few years ago. Many other countries have their own historic > roots for bitter feelings towards the USA. Then there are *many* > people in many countries who are upset about more recent events that I > don't want to mention explicitly in order to avoid sparking a flame > war. For example, think of an Arab with a good command of the English > language who'd like to subscribe to a technical mailing list. > > Wouldn't the "English (USA)" label feel like a slap in the face for > such a user? > > Greetings, Norbert. From barry at python.org Wed Apr 23 13:09:12 2003 From: barry at python.org (Barry Warsaw) Date: Wed Apr 23 08:09:13 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <20030423100101.779942FAFA@quill.cisto.com> References: <3E973B83.8040103@compsoc.man.ac.uk> <1050160045.1890.49.camel@localhost.localdomain> <1050797996.29014.59.camel@anthem> <20030423100101.779942FAFA@quill.cisto.com> Message-ID: <1051099722.19699.23.camel@anthem> On Wed, 2003-04-23 at 06:01, Norbert Bollow wrote: > Wouldn't the "English (USA)" label feel like a slap in the face for > such a user? As much as I'm itching to, I really do /not/ want to get into a political discussion on this mailing list. I'm happy to discuss off-list as time allows with anybody who could give a shit what /I/ think. :) Here's a compromise that might actually be more useful technically. Let's say every language tag in that pull down had the language code appended to it, which would include any country and variant code, if used. These codes would not be translated, since the RFCs specify them as English letters. Thus, "English (USA)" would change to "English (en)", and we'd see other entries like "France (fr)" and "Portuguese (pt_BR)". You'd still see "(en)" in the Japanese translation too. Would this be too jarring for non-English, non-European users? -Barry From mal at lemburg.com Wed Apr 23 15:30:54 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Apr 23 08:31:32 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <1051099722.19699.23.camel@anthem> References: <3E973B83.8040103@compsoc.man.ac.uk> <1050160045.1890.49.camel@localhost.localdomain> <1050797996.29014.59.camel@anthem> <20030423100101.779942FAFA@quill.cisto.com> <1051099722.19699.23.camel@anthem> Message-ID: <3EA6877E.2010005@lemburg.com> Barry Warsaw wrote: > On Wed, 2003-04-23 at 06:01, Norbert Bollow wrote: > >>Wouldn't the "English (USA)" label feel like a slap in the face for >>such a user? > > Here's a compromise that might actually be more useful technically. > Let's say every language tag in that pull down had the language code > appended to it, which would include any country and variant code, if > used. These codes would not be translated, since the RFCs specify them > as English letters. > > Thus, "English (USA)" would change to "English (en)", and we'd see other > entries like "France (fr)" and "Portuguese (pt_BR)". You'd still see > "(en)" in the Japanese translation too. Would this be too jarring for > non-English, non-European users? Why not stick to the standard English language names ? E.g. 'de': 'German', 'de-at': 'German/Austria', 'de-de': 'German/Germany', 'de-ch': 'German/Switzerland', 'dz': 'Bhutani', 'el': 'Greek', 'en': 'English', 'en-gb': 'English/United Kingdom', 'en-us': 'English/United States', 'eo': 'Esperanto', 'es': 'Spanish', 'es-ar': 'Spanish/Argentina', 'es-es': 'Spanish/Spain', 'es-co': 'Spanish/Colombia', 'es-mx': 'Spanish/Mexico', See "Names of Languages - ISO 639" and "Language Tag - RFC 1766/3066" for more background information. Resources: - http://rfc.sunsite.dk/rfc/rfc3066.html - http://www.loc.gov/standards/iso639-2/langhome.html - http://www.iana.org/assignments/language-tags -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Apr 23 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2003, Charleroi, Belgium: 62 days left From barry at python.org Wed Apr 23 13:44:56 2003 From: barry at python.org (Barry Warsaw) Date: Wed Apr 23 08:44:58 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <3EA6877E.2010005@lemburg.com> References: <3E973B83.8040103@compsoc.man.ac.uk> <1050160045.1890.49.camel@localhost.localdomain> <1050797996.29014.59.camel@anthem> <20030423100101.779942FAFA@quill.cisto.com> <1051099722.19699.23.camel@anthem> <3EA6877E.2010005@lemburg.com> Message-ID: <1051101807.19699.31.camel@anthem> On Wed, 2003-04-23 at 08:30, M.-A. Lemburg wrote: > Why not stick to the standard English language names ? Good idea, thanks for the link! -Barry From mal at lemburg.com Wed Apr 23 15:57:10 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Apr 23 08:57:46 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <1051101807.19699.31.camel@anthem> References: <3E973B83.8040103@compsoc.man.ac.uk> <1050160045.1890.49.camel@localhost.localdomain> <1050797996.29014.59.camel@anthem> <20030423100101.779942FAFA@quill.cisto.com> <1051099722.19699.23.camel@anthem> <3EA6877E.2010005@lemburg.com> <1051101807.19699.31.camel@anthem> Message-ID: <3EA68DA6.5010907@lemburg.com> Barry Warsaw wrote: > On Wed, 2003-04-23 at 08:30, M.-A. Lemburg wrote: > > >>Why not stick to the standard English language names ? > > Good idea, thanks for the link! Here's the complete list I'm using (collected from various sources): # # Mapping tables # # Keys must language names. The tables themselves must map # ISO codes using lowercase letters only to language names. # Names = { 'English': { 'aa': 'Afar', 'ab': 'Abkhazian', 'af': 'Afrikaans', 'am': 'Amharic', 'ar': 'Arabic', 'as': 'Assamese', 'ay': 'Aymara', 'az': 'Azerbaijani', 'ba': 'Bashkir', 'be': 'Byelorussian', 'bg': 'Bulgarian', 'bh': 'Bihari', 'bi': 'Bislama', 'bn': 'Bengali', 'bo': 'Tibetan', 'br': 'Breton', 'ca': 'Catalan', 'co': 'Corsican', 'cs': 'Czech', 'cy': 'Welsh', 'da': 'Danish', 'de': 'German', 'de-at': 'German/Austria', 'de-de': 'German/Germany', 'de-ch': 'German/Switzerland', 'dz': 'Bhutani', 'el': 'Greek', 'en': 'English', 'en-gb': 'English/United Kingdom', 'en-us': 'English/United States', 'eo': 'Esperanto', 'es': 'Spanish', 'es-ar': 'Spanish/Argentina', 'es-es': 'Spanish/Spain', 'es-co': 'Spanish/Colombia', 'es-mx': 'Spanish/Mexico', 'et': 'Estonian', 'eu': 'Basque', 'fa': 'Persian', 'fi': 'Finnish', 'fj': 'Fiji', 'fo': 'Faroese', 'fr': 'French', 'fr-be': 'French/Belgium', 'fr-ca': 'French/Canada', 'fr-fr': 'French/France', 'fr-ch': 'French/Switzerland', 'fy': 'Frisian', 'ga': 'Irish', 'gd': 'Scots Gaelic', 'gl': 'Galician', 'gn': 'Guarani', 'gu': 'Gujarati', 'ha': 'Hausa', 'he': 'Hebrew', 'hi': 'Hindi', 'hr': 'Croatian', 'hu': 'Hungarian', 'hy': 'Armenian', 'ia': 'Interlingua', 'id': 'Indonesian', 'ie': 'Interlingue', 'ik': 'Inupiak', 'is': 'Icelandic', 'it': 'Italian', 'iu': 'Inuktitut', 'ja': 'Japanese', 'jw': 'Javanese', 'ka': 'Georgian', 'kk': 'Kazakh', 'kl': 'Greenlandic', 'km': 'Cambodian', 'kn': 'Kannada', 'ko': 'Korean', 'ks': 'Kashmiri', 'ku': 'Kurdish', 'ky': 'Kirghiz', 'la': 'Latin', 'ln': 'Lingala', 'lo': 'Laothian', 'lt': 'Lithuanian', 'lv': 'Latvian', 'mg': 'Malagasy', 'mi': 'Maori', 'mk': 'Macedonian', 'ml': 'Malayalam', 'mn': 'Mongolian', 'mo': 'Moldavian', 'mr': 'Marathi', 'ms': 'Malay', 'mt': 'Maltese', 'my': 'Burmese', 'na': 'Nauru', 'ne': 'Nepali', 'nl': 'Dutch', 'nl-be': 'Dutch/Belgium', 'no': 'Norwegian', 'oc': 'Occitan', 'om': '(Afan) Oromo', 'or': 'Oriya', 'pa': 'Punjabi', 'pl': 'Polish', 'ps': 'Pashto, Pushto', 'pt': 'Portuguese', 'pt-br': 'Portuguese/Brazil', 'qu': 'Quechua', 'rm': 'Rhaeto-Romance', 'rn': 'Kirundi', 'ro': 'Romanian', 'ru': 'Russian', 'rw': 'Kinyarwanda', 'sa': 'Sanskrit', 'sd': 'Sindhi', 'sg': 'Sangho', 'sh': 'Serbo-Croatian', 'si': 'Sinhalese', 'sk': 'Slovak', 'sl': 'Slovenian', 'sm': 'Samoan', 'sn': 'Shona', 'so': 'Somali', 'sq': 'Albanian', 'sr': 'Serbian', 'ss': 'Siswati', 'st': 'Sesotho', 'su': 'Sundanese', 'sv': 'Swedish', 'sw': 'Swahili', 'ta': 'Tamil', 'te': 'Telugu', 'tg': 'Tajik', 'th': 'Thai', 'ti': 'Tigrinya', 'tk': 'Turkmen', 'tl': 'Tagalog', 'tn': 'Setswana', 'to': 'Tonga', 'tr': 'Turkish', 'ts': 'Tsonga', 'tt': 'Tatar', 'tw': 'Twi', 'ug': 'Uighur', 'uk': 'Ukrainian', 'ur': 'Urdu', 'uz': 'Uzbek', 'vi': 'Vietnamese', 'vo': 'Volapuk', 'wo': 'Wolof', 'xh': 'Xhosa', 'yi': 'Yiddish', 'yo': 'Yoruba', 'za': 'Zhuang', 'zh': 'Chinese', 'zh-cn': 'Chinese/China', 'zh-tw': 'Chinese/Taiwan', 'zu': 'Zulu', }, } -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Apr 23 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2003, Charleroi, Belgium: 62 days left From pioppo at ferrara.linux.it Wed Apr 23 17:16:32 2003 From: pioppo at ferrara.linux.it (Simone Piunno) Date: Wed Apr 23 10:09:09 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <3EA68DA6.5010907@lemburg.com> References: <3E973B83.8040103@compsoc.man.ac.uk> <1050160045.1890.49.camel@localhost.localdomain> <1050797996.29014.59.camel@anthem> <20030423100101.779942FAFA@quill.cisto.com> <1051099722.19699.23.camel@anthem> <3EA6877E.2010005@lemburg.com> <1051101807.19699.31.camel@anthem> <3EA68DA6.5010907@lemburg.com> Message-ID: <20030423141632.GA14427@pioppo.wired> mercoled?, 23 aprile 2003 alle 14:57:10, M.-A. Lemburg ha scritto: > Here's the complete list I'm using (collected from various sources): I believe the Mandrake's installation CD has an even more complete list, e.g. they have Italian, Italian/Italy and Italian/Switzerland -- This signature intentionally left blank From marty at penguinarts.com Wed Apr 23 16:42:24 2003 From: marty at penguinarts.com (Marty Galyean) Date: Wed Apr 23 11:42:25 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <200304231251.09520.a.carter@intrasoft.lu> References: <3E973B83.8040103@compsoc.man.ac.uk> <1050797996.29014.59.camel@anthem> <20030423100101.779942FAFA@quill.cisto.com> <200304231251.09520.a.carter@intrasoft.lu> Message-ID: <1051112386.1477.31.camel@localhost.localdomain> On Wed, 2003-04-23 at 04:51, CARTER Anthony wrote: > Televisions were invented in Britain...Doesn't mean that every tele has to > start up with a union jack on its screen...huh? Televisions invented in Britain? Only if you believe Charles Babbage "invented" electronic computers. What was more important to the Information Revolution? Babbages mechanical Difference Engine? Or the electronic silicon chip? As for television, see the link below, Key excerpt: ?Zworykin had a patent, but Farnsworth had a picture?? Both were Americans. Many were involved in the development of the idea, including important British contributions, but the first working televisions, in the modern sense, that is electronic, not mechanical, were decidedly American. And when they start up, they do not show the Stars and Stripes, I might add. Not to start a peeing contest, but after the incredibly raw deal that Philo Farnsworth got in his life I can't stand by and see him bent over once again. Marty From marty at penguinarts.com Wed Apr 23 16:47:40 2003 From: marty at penguinarts.com (Marty Galyean) Date: Wed Apr 23 11:47:41 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <20030423100101.779942FAFA@quill.cisto.com> References: <3E973B83.8040103@compsoc.man.ac.uk> <1050160045.1890.49.camel@localhost.localdomain> <1050797996.29014.59.camel@anthem> <20030423100101.779942FAFA@quill.cisto.com> Message-ID: <1051112702.1477.37.camel@localhost.localdomain> On Wed, 2003-04-23 at 04:01, Norbert Bollow wrote: > Wouldn't the "English (USA)" label feel like a slap in the face for > such a user? Why should it be a problem if it's USA English? Coddling the world is a poor substitute for truth. If it said "USA is #1!" I could perhaps see your point, but it is simply stating that the English is of a USA type. What ever happened to rationality? When did emotional moping take precedence over sanity? Marty From nb at cisto.com Wed Apr 23 19:59:52 2003 From: nb at cisto.com (Norbert Bollow) Date: Wed Apr 23 12:44:36 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <1051112702.1477.37.camel@localhost.localdomain> (message from Marty Galyean on 23 Apr 2003 09:45:00 -0600) References: <3E973B83.8040103@compsoc.man.ac.uk> <1050160045.1890.49.camel@localhost.localdomain> <1050797996.29014.59.camel@anthem> <20030423100101.779942FAFA@quill.cisto.com> <1051112702.1477.37.camel@localhost.localdomain> Message-ID: <20030423165952.7AE002FCB4@quill.cisto.com> Barry Warsaw wrote: > Thus, "English (USA)" would change to "English (en)" That'd IMO be perfect! > and we'd see other entries like "France (fr)" and "Portuguese > (pt_BR)". Actually, why not make that "Portuguese (pt)"? I think that'd increase the acceptance of Mailman in Portugal :-) > You'd still see "(en)" in the Japanese translation too. Sounds good. That'll mean that I'll not be totally lost if I ever get on a list at Mailman site with Japanese as default language :-) > Would this be too jarring for non-English, non-European users? I don't think so, but of course I can't speak for them. :-) Marty Galyean wrote: > What ever happened to rationality? When did emotional moping take > precedence over sanity? Please accept it as a rational fact that many people will often react emotionally to what they see. And please accept it as a rational fact that the ways in which superpowers often treat weaker countries tend to make a lot of people in those weaker countries emotionally upset. > On Wed, 2003-04-23 at 04:01, Norbert Bollow wrote: > > Wouldn't the "English (USA)" label feel like a slap in the face for > > such a user? > > Why should it be a problem if it's USA English? I made very clear that I don't consider it a problem that USA English is used. The problem is the "(USA)" label. It serves no useful purpose in the user interface for subscribers because the difference between various English-language locales is not important enough that users would want to be bothered with choosing between the English/USA and the English/UK locale. (If both locales were available, it would make sense though for the list-owner or site-admin to set the Mailman user interface to use the same style of spelling that is used in other list-related documentation). My point is that the Mailman UI should avoid sticking labels on stuff that needlessly evoke nationalistic emotions. Greetings, Norbert. -- Founder & Steering Committee member of http://gnu.org/projects/dotgnu/ Free Software Business Strategy Guide ---> http://FreeStrategy.info Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://norbert.ch From mal at lemburg.com Wed Apr 23 20:25:34 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Apr 23 13:26:16 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <20030423141632.GA14427@pioppo.wired> References: <3E973B83.8040103@compsoc.man.ac.uk> <1050160045.1890.49.camel@localhost.localdomain> <1050797996.29014.59.camel@anthem> <20030423100101.779942FAFA@quill.cisto.com> <1051099722.19699.23.camel@anthem> <3EA6877E.2010005@lemburg.com> <1051101807.19699.31.camel@anthem> <3EA68DA6.5010907@lemburg.com> <20030423141632.GA14427@pioppo.wired> Message-ID: <3EA6CC8E.7030501@lemburg.com> Simone Piunno wrote: > mercoled?, 23 aprile 2003 alle 14:57:10, M.-A. Lemburg ha scritto: > > >>Here's the complete list I'm using (collected from various sources): > > > I believe the Mandrake's installation CD has an even more complete list, > e.g. they have Italian, Italian/Italy and Italian/Switzerland Additions are appreciated. I haven't yet found the "definite" list on the net... just adding bits and pieces as they come along. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Apr 23 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2003, Charleroi, Belgium: 62 days left From barry at python.org Wed Apr 23 18:36:16 2003 From: barry at python.org (Barry Warsaw) Date: Wed Apr 23 13:36:16 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <20030423165952.7AE002FCB4@quill.cisto.com> References: <3E973B83.8040103@compsoc.man.ac.uk> <1050160045.1890.49.camel@localhost.localdomain> <1050797996.29014.59.camel@anthem> <20030423100101.779942FAFA@quill.cisto.com> <1051112702.1477.37.camel@localhost.localdomain> <20030423165952.7AE002FCB4@quill.cisto.com> Message-ID: <1051119388.27990.3.camel@geddy> On Wed, 2003-04-23 at 12:59, Norbert Bollow wrote: > > and we'd see other entries like "France (fr)" and "Portuguese > > (pt_BR)". > > Actually, why not make that "Portuguese (pt)"? Actually, we have both! :) > > You'd still see "(en)" in the Japanese translation too. > > Sounds good. That'll mean that I'll not be totally lost if I ever get > on a list at Mailman site with Japanese as default language :-) And now you've discovered my ulterior motive for my compromise position! When I'm debugging Japanese, Korean, or Russian, I have to look for those parentheses to get back to English. I've memorize the order of links in the Categories columns but still haven't managed to do the same on the language pull down. :) -Barry From barry at python.org Wed Apr 23 18:37:00 2003 From: barry at python.org (Barry Warsaw) Date: Wed Apr 23 13:37:02 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <3EA6CC8E.7030501@lemburg.com> References: <3E973B83.8040103@compsoc.man.ac.uk> <1050160045.1890.49.camel@localhost.localdomain> <1050797996.29014.59.camel@anthem> <20030423100101.779942FAFA@quill.cisto.com> <1051099722.19699.23.camel@anthem> <3EA6877E.2010005@lemburg.com> <1051101807.19699.31.camel@anthem> <3EA68DA6.5010907@lemburg.com> <20030423141632.GA14427@pioppo.wired> <3EA6CC8E.7030501@lemburg.com> Message-ID: <1051119432.27990.5.camel@geddy> On Wed, 2003-04-23 at 13:25, M.-A. Lemburg wrote: > Additions are appreciated. I haven't yet found the "definite" list > on the net... just adding bits and pieces as they come along. (Un)Fortunately, for now we only have to worry about 20 of them. -Barry From marty at penguinarts.com Wed Apr 23 18:44:57 2003 From: marty at penguinarts.com (Marty Galyean) Date: Wed Apr 23 13:44:59 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <20030423165952.7AE002FCB4@quill.cisto.com> References: <3E973B83.8040103@compsoc.man.ac.uk> <1050160045.1890.49.camel@localhost.localdomain> <1050797996.29014.59.camel@anthem> <20030423100101.779942FAFA@quill.cisto.com> <1051112702.1477.37.camel@localhost.localdomain> <20030423165952.7AE002FCB4@quill.cisto.com> Message-ID: <1051119712.5484.72.camel@localhost.localdomain> On Wed, 2003-04-23 at 10:59, Norbert Bollow wrote: > > What ever happened to rationality? When did emotional moping take > > precedence over sanity? > > Please accept it as a rational fact that many people will often react > emotionally to what they see. And please accept it as a rational fact > that the ways in which superpowers often treat weaker countries tend > to make a lot of people in those weaker countries emotionally upset. Ok. I didn't say it was not a fact that they may become upset. What I dispute is whether they are responsible for being upset over what they read or whether the writer is responsible. I, like most others who value Liberty, hold adults responsible for thier emotion and think that the State/Collective/Whatever should decidedly NOT be in the business of managing individuals emotions as that is a prelude to a very deep tyranny involving "thought crime" and such. I give up trying to explain. I cannot argue against the "Earth as a Big Kindergarten" theory of Socialism from which the "emotionally upset" argument seems to stem. Marty From r.barrett at openinfo.demon.co.uk Wed Apr 23 20:47:03 2003 From: r.barrett at openinfo.demon.co.uk (Richard Barrett) Date: Wed Apr 23 14:51:04 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <1051119712.5484.72.camel@localhost.localdomain> References: <20030423165952.7AE002FCB4@quill.cisto.com> <3E973B83.8040103@compsoc.man.ac.uk> <1050160045.1890.49.camel@localhost.localdomain> <1050797996.29014.59.camel@anthem> <20030423100101.779942FAFA@quill.cisto.com> <1051112702.1477.37.camel@localhost.localdomain> <20030423165952.7AE002FCB4@quill.cisto.com> Message-ID: <5.1.1.6.0.20030423194143.03df83d0@pop3.demon.co.uk> Barry Can we put a cap on this before people decide that they have better things to do than develop Mailman. I'm sure there is mailing list for naive political rants but I would prefer not to be subscribed to it. If that list is the Mailman-Developers list them I'm off! Richard At 18:41 23/04/2003, Marty Galyean wrote: >On Wed, 2003-04-23 at 10:59, Norbert Bollow wrote: > > > What ever happened to rationality? When did emotional moping take > > > precedence over sanity? > > > > Please accept it as a rational fact that many people will often react > > emotionally to what they see. And please accept it as a rational fact > > that the ways in which superpowers often treat weaker countries tend > > to make a lot of people in those weaker countries emotionally upset. > >Ok. I didn't say it was not a fact that they may become upset. What I >dispute is whether they are responsible for being upset over what they >read or whether the writer is responsible. I, like most others who >value Liberty, hold adults responsible for thier emotion and think that >the State/Collective/Whatever should decidedly NOT be in the business of >managing individuals emotions as that is a prelude to a very deep >tyranny involving "thought crime" and such. I give up trying to >explain. I cannot argue against the "Earth as a Big Kindergarten" >theory of Socialism from which the "emotionally upset" argument seems to >stem. > >Marty From fil at rezo.net Wed Apr 23 23:19:50 2003 From: fil at rezo.net (Fil) Date: Wed Apr 23 16:19:55 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <3EA68DA6.5010907@lemburg.com> References: <3E973B83.8040103@compsoc.man.ac.uk> <1050160045.1890.49.camel@localhost.localdomain> <1050797996.29014.59.camel@anthem> <20030423100101.779942FAFA@quill.cisto.com> <1051099722.19699.23.camel@anthem> <3EA6877E.2010005@lemburg.com> <1051101807.19699.31.camel@anthem> <3EA68DA6.5010907@lemburg.com> Message-ID: <20030423201950.GK25093@rezo.net> In our project, SPIP (www.uzine.net/spip), we're using a similar list, but in which every language is identified in its own writing. When two translations belong to the same ISO family, we just use the branches pt_BR and pt_PT, whereas when only one translation belongs to the family we use just the family code (and name), unflavoured. This can help groups join in a common effort, then split *if* needed. (However, we don't have that much experience to say if it works; but it's really an exciting process). BTW, and slightly off-topic, the usual translation tools were really too clumsy to use (you can't expect translators to know which one to choose, and to install it and understand it -- at least it raises the bar too high --, plus you want to have a team effort, so you need people to be able to tap the same translation database). We finally decided to build a translation website with lists of "strings awaiting for translation" in every language, and a web interface to edit them. It works really well. @ M.-A. Lemburg : > Barry Warsaw wrote: > >On Wed, 2003-04-23 at 08:30, M.-A. Lemburg wrote: > > > > > >>Why not stick to the standard English language names ? > > > >Good idea, thanks for the link! > > Here's the complete list I'm using (collected from various sources): > > # > # Mapping tables > # > # Keys must language names. The tables themselves must map > # ISO codes using lowercase letters only to language names. > # -- Fil From barry at python.org Thu Apr 24 04:25:47 2003 From: barry at python.org (Barry Warsaw) Date: Wed Apr 23 23:25:49 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <20030423201950.GK25093@rezo.net> References: <3E973B83.8040103@compsoc.man.ac.uk> <1050160045.1890.49.camel@localhost.localdomain> <1050797996.29014.59.camel@anthem> <20030423100101.779942FAFA@quill.cisto.com> <1051099722.19699.23.camel@anthem> <3EA6877E.2010005@lemburg.com> <1051101807.19699.31.camel@anthem> <3EA68DA6.5010907@lemburg.com> <20030423201950.GK25093@rezo.net> Message-ID: <1051154714.1393.3.camel@geddy> On Wed, 2003-04-23 at 16:19, Fil wrote: > In our project, SPIP (www.uzine.net/spip), we're using a similar list, > but in which every language is identified in its own writing. When two > translations belong to the same ISO family, we just use the branches pt_BR > and pt_PT, whereas when only one translation belongs to the family we use > just the family code (and name), unflavoured. This can help groups join in a > common effort, then split *if* needed. (However, we don't have that much > experience to say if it works; but it's really an exciting process). Interesting, you'll have to let us know how it works. :) > BTW, and slightly off-topic, the usual translation tools were really too > clumsy to use (you can't expect translators to know which one to choose, and > to install it and understand it -- at least it raises the bar too high --, > plus you want to have a team effort, so you need people to be able to tap > the same translation database). We finally decided to build a translation > website with lists of "strings awaiting for translation" in every language, > and a web interface to edit them. It works really well. We have plans to do something similar, initially for Zope, but ideally (at least in my mind) open source projects in general: http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TranslationWebService Now we'll see if we get some free time to actually work on this. ;) -Barry From a.carter at cordis.lu Thu Apr 24 11:39:13 2003 From: a.carter at cordis.lu (CARTER Anthony) Date: Thu Apr 24 04:39:59 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <1051112386.1477.31.camel@localhost.localdomain> References: <3E973B83.8040103@compsoc.man.ac.uk> <200304231251.09520.a.carter@intrasoft.lu> <1051112386.1477.31.camel@localhost.localdomain> Message-ID: <200304241039.13606.a.carter@intrasoft.lu> Excuse me but: http://www.hastings.uk.net/latest/stories/050502/baird.html I know this cause I lived in hastings and in London Road there is a plaque on one of the building stating:"Television was born here"... I quote: Baird famously transmitted the first television pictures in a workshop above the Hastings Town Centre Queen's Arcade. I quote from http://www.hastings.uk.net/famouspeople/logiebaird.html "John Logie Baird was born in 1888, Helensburgh in Scotland. " and "Baird filed a patent for his television design in early July 1923. It was not until 1924 that he had an actual working prototype. Dubbed the 'televisor', Baird had used an old tea chest as a base, mounted a motor and attached a home-made Nipkow disc, a cardboard circle cut from a hat box. A darning needle became a spindle, and a discarded biscuit box made a suitable lamp housing. Apart from the motor, his greatest investment was a few bull's-eye lenses bought for four pence a piece. Glued together with sealing wax and string, it was a precarious contraption, but it worked. In his room, he managed to transmit a silhouette of a Maltese cross two or three yards to a receiver. The image was beautiful to Baird, and proved his basic assumptions were correct." And from your own site: "Another player of the times was John Logie Baird, a Scottish engineer and entrepreneur who 'achieved his first transmissions of simple face shapes in 1924 using mechanical television. On March 25, 1925, Baird held his first public demonstration of 'television' at the London department store Selfridges on Oxford Street in London. In this demonstration, he had not yet obtained adequate half-tones in the moving pictures, and only silhouettes were visible.' - MZTV " But Baird's work was the first showing of a working model (although mechanical) of the principles of television... Anthony On Wednesday 23 April 2003 17:39, Marty Galyean wrote: > On Wed, 2003-04-23 at 04:51, CARTER Anthony wrote: > > Televisions were invented in Britain...Doesn't mean that every tele has > > to start up with a union jack on its screen...huh? > > Televisions invented in Britain? Only if you believe Charles Babbage > "invented" electronic computers. What was more important to the > Information Revolution? Babbages mechanical Difference Engine? Or the > electronic silicon chip? > > As for television, see the link below, > > Key excerpt: ?Zworykin had a patent, but Farnsworth had a picture?? > > Both were Americans. > > > > Many were involved in the development of the idea, including important > British contributions, but the first working televisions, in the modern > sense, that is electronic, not mechanical, were decidedly American. > > And when they start up, they do not show the Stars and Stripes, I might > add. > > Not to start a peeing contest, but after the incredibly raw deal that > Philo Farnsworth got in his life I can't stand by and see him bent over > once again. > > Marty From charlie at begeistert.org Thu Apr 24 12:02:14 2003 From: charlie at begeistert.org (Charlie Clark) Date: Thu Apr 24 05:02:15 2003 Subject: [Mailman-Developers] Re: Mailman-Developers Weird encoding problem In-Reply-To: References: Message-ID: <20030424110214.1289.1@wonderland.1051174219.fake> Has anything changed on the digest side recently? My mailer (Beam, http://beam.sourceforge.net/) has been complaining that the digest isn't actually ASCII although it claims to be so the conversion to UTF-8 doesn't work properly. I've passed a few to the developer to see if this is a mail client issue but he says it seems to be Mailman's fault... any ideas? Charlie Clark accepted languages: en-EN, fr-FR, de-DE, nl-NL, se-SE, it-IT From fil at rezo.net Thu Apr 24 12:33:23 2003 From: fil at rezo.net (Fil) Date: Thu Apr 24 05:33:28 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <1051154714.1393.3.camel@geddy> References: <3E973B83.8040103@compsoc.man.ac.uk> <1050160045.1890.49.camel@localhost.localdomain> <1050797996.29014.59.camel@anthem> <20030423100101.779942FAFA@quill.cisto.com> <1051099722.19699.23.camel@anthem> <3EA6877E.2010005@lemburg.com> <1051101807.19699.31.camel@anthem> <3EA68DA6.5010907@lemburg.com> <20030423201950.GK25093@rezo.net> <1051154714.1393.3.camel@geddy> Message-ID: <20030424093323.GB25214@rezo.net> > > In our project, SPIP (www.uzine.net/spip), we're using a similar list, > Interesting, you'll have to let us know how it works. :) Currently we have 11 languages and 2 more are almost ready. What's interesting is that the web interface includes arabic translation, with some bidi trouble ;) The first split to occur will probably be between two languages of the cpf family (French Creols and Pidgins) - the Reunion (which is complete) and the Caribbean types (which is starting). > > and a web interface to edit them. It works really well. > We have plans to do something similar, initially for Zope, but ideally > (at least in my mind) open source projects in general: > http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TranslationWebService > Now we'll see if we get some free time to actually work on this. ;) I remember we had discussed this idea a while ago on the Mailman list. I'm glad to see that it became a wiki think. If you want our code, you can have it (but eeeek it's php). -- Fil From mch at cix.compulink.co.uk Thu Apr 24 15:42:00 2003 From: mch at cix.compulink.co.uk (Mike Holderness) Date: Thu Apr 24 09:42:53 2003 Subject: [Mailman-Developers] English (USA) Message-ID: In-Reply-To: Quoth Norbert Bollow : > What ever happened to rationality? When did emotional moping take > precedence over sanity? When was there ever a rational definition of "sanity"? Start with some Foucault (in French, s'il te plait) - not that he's right, but that'll get you set on the questions. Including how the concept "sanity" may be used as a coercive instrument of power. Which, to get back to software, is the whole point of internationali{s|z}ation: to take account of local preferences and expectations *as they exist* so that the product is usable, with the fewest rough edges, by all. Think Oxford Dictionary (descriptive of how language *is* used) not Fowler (prescriptive). So, we go for the ISO codes. With 'en-co' - Cockney, innit, love - as the default, and list other variants for the weird :-) Mike From marty at penguinarts.com Thu Apr 24 15:01:24 2003 From: marty at penguinarts.com (Marty Galyean) Date: Thu Apr 24 10:01:26 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: References: Message-ID: <1051192486.1640.42.camel@localhost.localdomain> On Thu, 2003-04-24 at 07:42, Mike Holderness wrote: > In-Reply-To: > Quoth Norbert Bollow : > > > What ever happened to rationality? When did emotional moping take > > precedence over sanity? > > When was there ever a rational definition of "sanity"? > > Start with some Foucault (in French, s'il te plait) > - not that he's right, but that'll get you set on > the questions. Including how the concept "sanity" may > be used as a coercive instrument of power. At some point conceptual reality must meet measurable physical reality. The degree of efficiency of that interface defines "sanity". You can only pull that "relativism" card so many times before it gets all worn out. Yes, those who define "sanity" wield a lot of power. Take a close look at the politics of those who currently define "sanity". The perception of measurable physical reality is a decentralized function and not controllable by any committee. Is it sane/feasible to cater to every emotional whim on the planet no matter how divorced from fact that emotional reality is? > Which, to get back to software, is the whole point > of internationali{s|z}ation: to take account of > local preferences and expectations *as they exist* > so that the product is usable, with the fewest > rough edges, by all. I like this approach. > Think Oxford Dictionary (descriptive of how language > *is* used) not Fowler (prescriptive). > > So, we go for the ISO codes. > > With 'en-co' - Cockney, innit, love - as the default, > and list other variants for the weird :-) LOL. I hadn't noticed that particular code! I say, if enough people of 'en-co' bent are interested enough, let them write their own module! I'd love to check it out when it's done. Trying to satisfy the world with committee has nearly always, resoundingly, and utterly, failed. Give people the elbow room to solve their own problems and magic nearly always resoundingly happens. So how can we make it easier for people to create pluggable charset and language modules for mailman? That is the question that some are addressing and some aren't. Using a standard (like ISO) to categorize the menu language choices makes a lot of sense, of course, because it is generally accepted. But why not make it flexible enough to handle ad hoc solutions like cockney English since that would not involve a custom charset and would only involve the use of alternate verbiage? It is an impossible task to paternally cater to all possible morphings of human utterance. But it is far easier to allow for these variations should someone take and interest in some variant and want to do the work. Marty From fil at rezo.net Thu Apr 24 17:05:57 2003 From: fil at rezo.net (Fil) Date: Thu Apr 24 10:06:01 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <1051192486.1640.42.camel@localhost.localdomain> References: <1051192486.1640.42.camel@localhost.localdomain> Message-ID: <20030424140557.GG25214@rezo.net> > But it is far easier to allow for these variations should someone take > and interest in some variant and want to do the work. This is also what I'm advocating for. You might have non-ISO codes then, when you deal with Klingon or with other subcultural creations of new languages (Tolkien invented quite a few). -- Fil From marty at penguinarts.com Thu Apr 24 15:09:11 2003 From: marty at penguinarts.com (Marty Galyean) Date: Thu Apr 24 10:09:12 2003 Subject: [Mailman-Developers] English (USA) In-Reply-To: <20030424140557.GG25214@rezo.net> References: <1051192486.1640.42.camel@localhost.localdomain> <20030424140557.GG25214@rezo.net> Message-ID: <1051192952.1492.48.camel@localhost.localdomain> On Thu, 2003-04-24 at 08:05, Fil wrote: > > But it is far easier to allow for these variations should someone take > > and interest in some variant and want to do the work. > > This is also what I'm advocating for. You might have non-ISO codes then, > when you deal with Klingon or with other subcultural creations of new > languages (Tolkien invented quite a few). LOL! If I can't have a Mailman list that can handle Dwarvish then I'll just have to toss Mailman! Marty From tneff at bigfoot.com Thu Apr 24 21:19:00 2003 From: tneff at bigfoot.com (Tom Neff) Date: Thu Apr 24 20:19:03 2003 Subject: [Mailman-Developers] Wanted: canned replies In-Reply-To: References: Message-ID: <1806081171.1051215540@tomdual.nyc.rr.com> The OTHER most-wanted feature for me, besides per-member aliases, is moderator editable canned rejection reasons. Most lists have a slowly growing and changing - but otherwise quasi-stable - list of "most popular reasons" for rejecting a posting. This is the comet announcement list - asteroids go to ASTEROID-ANNOUNCE@XYZ.EDU. There was no text in your message. We don't post for-sale-by-owner ads here on PLUTONIUM-DIGEST. :) etcetera, etcetera. I'm sure most moderators would jump at the chance to select from a customizable set of canned reasons when plowing through the admindb queue. If you needed something new or different you could always type it in, as now - but there could also be a "Save this as a canned response" button. Or maybe it's simpler to do all that maintenance on a separate admin subscreen. From marc_news at merlins.org Fri Apr 25 09:59:15 2003 From: marc_news at merlins.org (Marc MERLIN) Date: Fri Apr 25 11:59:21 2003 Subject: [Mailman-Developers] What happened to MAILMAN_UID, MAILMAN_GID? Message-ID: <20030425155915.GM24554@merlins.org> It looks like those were removed or renamed recently and it broke check_perms_grsecurity.py What am I supposed to use now? Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news at merlins.org Fri Apr 25 10:01:24 2003 From: marc_news at merlins.org (Marc MERLIN) Date: Fri Apr 25 12:01:30 2003 Subject: [Mailman-Developers] More tracebacks with mailman-cvs Message-ID: <20030425160124.GN24554@merlins.org> I just did a CVS update again since I was still getting these, and one of my installs also dies on subscriptions Traceback (most recent call last): File "/var/local/mailman/scripts/driver", line 87, in run_main main() File "/var/local/mailman/Mailman/Cgi/subscribe.py", line 96, in main process_form(mlist, doc, cgidata, language) File "/var/local/mailman/Mailman/Cgi/subscribe.py", line 176, in process_form mlist.AddMember(userdesc, remote) File "/var/local/mailman/Mailman/MailList.py", line 806, in AddMember cookie = Pending.new(Pending.SUBSCRIPTION, userdesc) File "/var/local/mailman/Mailman/Pending.py", line 75, in new db = _load() File "/var/local/mailman/Mailman/Pending.py", line 163, in _load return cPickle.load(fp) EOFError (go to http://lists.svlug.org/lists/listinfo/svlug and join if you want to reproduce) Thanks Marc ----- Forwarded message from Cron Daemon ----- From: root@svlug.org (Cron Daemon) To: mailman@svlug.org X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: Subject: Cron /usr/bin/python -S /var/local/mailman/cron/disabled Traceback (most recent call last): File "/var/local/mailman/cron/disabled", line 209, in ? main() File "/var/local/mailman/cron/disabled", line 201, in main mlist.sendNextNotification(member) File "/var/local/mailman/Mailman/Bouncer.py", line 212, in sendNextNotification Pending.confirm(info.cookie) File "/var/local/mailman/Mailman/Pending.py", line 133, in confirm db = _load() File "/var/local/mailman/Mailman/Pending.py", line 163, in _load return cPickle.load(fp) EOFError ----- End forwarded message ----- -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From les at 2pi.org Fri Apr 25 18:39:14 2003 From: les at 2pi.org (Les Niles) Date: Fri Apr 25 20:43:58 2003 Subject: [Mailman-Developers] Wanted: canned replies In-Reply-To: <1806081171.1051215540@tomdual.nyc.rr.com> (message from Tom Neff on Thu, 24 Apr 2003 20:19:00 -0400) References: <1806081171.1051215540@tomdual.nyc.rr.com> Message-ID: <200304260039.h3Q0dEJ5000427@grumman.kjsl.com> Yes! Things like "don't quote the whole friggin' issue of the digest!" I had hacked something like this into an old version of Mailman, but never re-implemented it for the new admindb interface -- the implementation would be quite different. -les On Thu, 24 Apr 2003 20:19:00 -0400 Tom Neff wrote: >The OTHER most-wanted feature for me, besides per-member aliases, is >moderator editable canned rejection reasons. Most lists have a slowly >growing and changing - but otherwise quasi-stable - list of "most popular >reasons" for rejecting a posting. > > This is the comet announcement list - asteroids go to >ASTEROID-ANNOUNCE@XYZ.EDU. > > There was no text in your message. > > We don't post for-sale-by-owner ads here on PLUTONIUM-DIGEST. :) > >etcetera, etcetera. I'm sure most moderators would jump at the chance to >select from a customizable set of canned reasons when plowing through the >admindb queue. If you needed something new or different you could always >type it in, as now - but there could also be a "Save this as a canned >response" button. Or maybe it's simpler to do all that maintenance on a >separate admin subscreen. From marty at penguinarts.com Sat Apr 26 02:20:31 2003 From: marty at penguinarts.com (Marty Galyean) Date: Fri Apr 25 21:20:32 2003 Subject: [Mailman-Developers] Wanted: canned replies In-Reply-To: <200304260039.h3Q0dEJ5000427@grumman.kjsl.com> References: <1806081171.1051215540@tomdual.nyc.rr.com> <200304260039.h3Q0dEJ5000427@grumman.kjsl.com> Message-ID: <1051319202.1463.291.camel@localhost.localdomain> I would like to have any embedded list footers in replies to the list to be stripped out. They can really add up in a long thread and because they are static, it is a no brainer that the server could strip them and save those replying some effort. Marty On Fri, 2003-04-25 at 18:39, Les Niles wrote: > Yes! Things like "don't quote the whole friggin' issue of the > digest!" > > I had hacked something like this into an old version of Mailman, > but never re-implemented it for the new admindb interface -- the > implementation would be quite different. > > -les > > On Thu, 24 Apr 2003 20:19:00 -0400 Tom Neff wrote: > >The OTHER most-wanted feature for me, besides per-member aliases, is > >moderator editable canned rejection reasons. Most lists have a slowly > >growing and changing - but otherwise quasi-stable - list of "most popular > >reasons" for rejecting a posting. > > > > This is the comet announcement list - asteroids go to > >ASTEROID-ANNOUNCE@XYZ.EDU. > > > > There was no text in your message. > > > > We don't post for-sale-by-owner ads here on PLUTONIUM-DIGEST. :) > > > >etcetera, etcetera. I'm sure most moderators would jump at the chance to > >select from a customizable set of canned reasons when plowing through the > >admindb queue. If you needed something new or different you could always > >type it in, as now - but there could also be a "Save this as a canned > >response" button. Or maybe it's simpler to do all that maintenance on a > >separate admin subscreen. > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From john at momsview.com Sat Apr 26 09:45:18 2003 From: john at momsview.com (John Distler) Date: Sat Apr 26 08:44:25 2003 Subject: [Mailman-Developers] Bounce processing performance, pending.pck possible bug/redesign Message-ID: <015f01c30bf1$b19ebce0$0201a8c0@p3> I'm currently running Mailman 2.1.1 I recently completed splitting my large 190,000 member list into 72 sublists for performance reasons (primarily bounce processing). I split the lists leaving bounce disabled addresses in the mix to be able to measure performance of the new setup. My first mailing to my 72 sublists generated over 15,000 bounces, however the performance wasn't what I expected. The first few bounces were processed at over 8 per second. However that slowed to 5 seconds PER BOUNCE near the end. After investigation I noticed that ~mailman/data/pending.pck had grown to almost 2 megabytes in size. Even though I have my bounce threshold set to 5.0 and NO addresses were disabled because of bouncing, pending.pck contained over 15,000 "re-enable" entries along with generated confirmation strings. I double checked the bounce information was correctly registered by dumping the config.pck for the mailing list. None of these addresses were disabled and the bounce information is correct. I looked at the code in Bouncer.py at the "registerbounce" routine and this behavior appears to be by design. Am I missing something here or is this a bug? From r.barrett at openinfo.demon.co.uk Sat Apr 26 18:20:50 2003 From: r.barrett at openinfo.demon.co.uk (Richard Barrett) Date: Sat Apr 26 12:30:38 2003 Subject: [Mailman-Developers] Bounce processing performance, pending.pck possible bug/redesign In-Reply-To: <015f01c30bf1$b19ebce0$0201a8c0@p3> Message-ID: <5.1.1.6.0.20030426171404.03c306e8@pop3.demon.co.uk> At 13:45 26/04/2003, John Distler wrote: >I'm currently running Mailman 2.1.1 >I recently completed splitting my large 190,000 member list into 72 sublists >for performance >reasons (primarily bounce processing). > >I split the lists leaving bounce disabled addresses in the mix to be able to >measure performance >of the new setup. > >My first mailing to my 72 sublists generated over 15,000 bounces, however >the performance wasn't what I expected. > >The first few bounces were processed at over 8 per second. However that >slowed to 5 seconds PER BOUNCE near the end. > >After investigation I noticed that ~mailman/data/pending.pck had grown to >almost 2 megabytes in size. > >Even though I have my bounce threshold set to 5.0 and NO addresses were >disabled because of bouncing, pending.pck contained over >15,000 "re-enable" entries along with generated confirmation strings. With a threshold of 5.0, it is going to require multiple bounces for each mail address to get it disabled. MM needs to keep records to do this. If you have a 'dirty' membership list, why not drop the threshhold to less than one e.g. 0.5, so that the next mailing disables the bouncing subscribers immediately; that is assuming that the returning addresses matches the subscribed addresses and you are not using VERP. >I double checked the bounce information was correctly registered by dumping >the config.pck for the mailing list. None of these addresses were disabled >and the bounce information is correct. > >I looked at the code in Bouncer.py at the "registerbounce" routine and this >behavior appears to be by design. >Am I missing something here or is this a bug? > > >_______________________________________________ >Mailman-Developers mailing list >Mailman-Developers@python.org >http://mail.python.org/mailman/listinfo/mailman-developers From john at momsview.com Sat Apr 26 18:21:17 2003 From: john at momsview.com (John Distler) Date: Sat Apr 26 17:20:33 2003 Subject: [Mailman-Developers] Bounce processing performance, pending.pck possible bug/redesign References: <5.1.1.6.0.20030426171404.03c306e8@pop3.demon.co.uk> Message-ID: <019101c30c39$c7088780$0201a8c0@p3> Thanks for the reply. I should have been more clear in my original message: Only when a subscriber exceeds the bounce threshold (and gets disabled) should a record be added to the pending.pck file. From that point on "You are disabled messages" would be sent to the subscriber with a confirmation string. It appears that Bouncer.py currently makes an entry in pending.pck for the very FIRST bounce even though the bounce disable threshold is set MUCH higher than one for the list. It is my understanding that the bounce date and count information is stored in the config.pck database. It appears than the extra processing of the pending.pck database may be increasing the bounce processing time significantly and possibly unnecessarily. Richard, I also want to thank you for your earlier help with umbrella lists it was invaluable. From fil at rezo.net Sun Apr 27 00:25:45 2003 From: fil at rezo.net (Fil) Date: Sat Apr 26 17:25:49 2003 Subject: [Mailman-Developers] Bounce processing performance, pending.pck possible bug/redesign In-Reply-To: <019101c30c39$c7088780$0201a8c0@p3> References: <5.1.1.6.0.20030426171404.03c306e8@pop3.demon.co.uk> <019101c30c39$c7088780$0201a8c0@p3> Message-ID: <20030426212545.GC27128@rezo.net> > It appears that Bouncer.py currently makes an entry in pending.pck for the > very FIRST bounce even though the bounce disable threshold is set MUCH > higher than one for the list. I would agree. > It is my understanding that the bounce date and count information is stored > in the config.pck database. Yes, and this choice is pretty much impossible to understand: it increases the risk of corruption of the config.pck file, and it makes the BounceRunner lock the config.pck file for ages when it needs just lock the "bouncers" part of that file. > It appears than the extra processing of the pending.pck database may be > increasing the bounce processing time significantly and possibly > unnecessarily. In my view it would be better to have a seperate bounce.pck file -- Fil From john at momsview.com Sat Apr 26 18:52:13 2003 From: john at momsview.com (John Distler) Date: Sat Apr 26 17:51:25 2003 Subject: [Mailman-Developers] Bounce processing performance, pending.pck possible bug/redesign References: <5.1.1.6.0.20030426171404.03c306e8@pop3.demon.co.uk> Message-ID: <019e01c30c3e$19395800$0201a8c0@p3> Yes, a redesign would ultimately be the solution. BUT, Is the current behavior a bug (writing a confirmation string on the first bounce) that should be easily fixed for better performance or am I not understanding the logic? From kmccann at bellanet.org Thu Apr 24 22:19:30 2003 From: kmccann at bellanet.org (Kevin McCann) Date: Sun Apr 27 10:35:06 2003 Subject: [Mailman-Developers] Priority/status of moderated-edit and external user DB Message-ID: <009b01c30ac8$b8c82fd0$0501a8c0@kevinduron> Hello, I'm curious about the status and priority of two features which, as far as I know, have yet to be implemented in Mailman. 1) External user database. I'm sure you're all aware of the desire of some folks to have this. I found a Wiki document somewhere on the zope.org site that had discussions on this but I believe it was somewhat dated. Have any conclusions been reached with respect to the direction here? I think I read talk of a Zope-specific solution. I'm wondering if this means that we're likely never to see a Mailman that can talk to a MySQL database. I believe this one feature alone would elevate Mailman significantly. How hgh of a priority is this to the development team and what is the status? Are there current discussions on this somewhere other than the list (wiki boards, chats, what-have-you) , and if so, may I take part? 2) Moderated-edit. I'm running Mailman on a couple of boxes but I also have a few hundred lists on a box running Lyris. I want to move them but one of the deal breakers at the moment is moderated-edit - the ability of a moderator to edit a message before it goes out. I personally don't use this feature for the lists I am the admin of but this seems to be a very important feature to some. An absolute must, in fact. I'm wonderig if this is in the cards, is it high on the priority list, should we expect to see it soon? I understand this is a non-paying gig for Barry and others, and I understand there are likely a ton of other items to deal with. But knowing what the priority and status of these two items are would give me a realistic idea of when I might be able to drop the oh-so-commercial Lyris. Finally, I'm not a Python programmer (yet), mostly Perl and PHP. But if I can help the cause in non-Python coding ways let me know. Thanks, Kevin From kevin at eorbit.net Fri Apr 25 17:40:57 2003 From: kevin at eorbit.net (Kevin Murphy) Date: Sun Apr 27 10:35:10 2003 Subject: [Mailman-Developers] Problems subclassing Mailman.Archiver.Archiver Message-ID: <1051288849.4696.18.camel@neko> Bewildered newbie seeks aid. For sinister reasons known only to myself, I want to subclass Mailman.Archiver.Archiver to extend the ArchiveMail method to do some extra work on each invocation. I created Mailman.Archiver.MyArchiver, subclassed Archiver, and made my changes. It compiles fine. I then changed MailList.py, replacing all references to Mailman.Archiver.Archiver to MyArchiver. It compiles fine. However, when install my changes and restart with mailmanctl, I get the following error: [root]# /home/mailman/bin/mailmanctl start Traceback (most recent call last): File "/home/mailman/bin/mailmanctl", line 538, in ? main() File "/home/mailman/bin/mailmanctl", line 357, in main check_for_site_list() File "/home/mailman/bin/mailmanctl", line 275, in check_for_site_list sitelist = MailList(sitelistname, lock=0) TypeError: 'module' object is not callable I suspect this has something to do with some pickled MailList object that's different than my altered MailList. But what do I know? I learned Python last week. :) Is there a way to get this to work, or am I going about it all wrong? -- Kevin Murphy From barry at python.org Sun Apr 27 18:11:41 2003 From: barry at python.org (Barry Warsaw) Date: Sun Apr 27 13:11:44 2003 Subject: [Mailman-Developers] RELEASED Mailman 2.1.2 Message-ID: <1051463473.9733.105.camel@anthem> I've just released Mailman 2.1.2 which includes many bug fixes and language updates, as well as support for two new languages, Portuguese/Portugal and Polish. I recommend all Mailman 2.1 users upgrade to this release. The full source tarball has been made available from the usual sites. Currently, there is no patch available, but you should be able to install 2.1.2 over your existing 2.1.x installation. See http://sourceforge.net/project/showfiles.php?group_id=103 for links to download all the patches and the source tarballs. Be sure you restart your mailman daemon by doing a "mailmanctl restart" after installing. See also: http://www.gnu.org/software/mailman http://www.list.org (not yet updated) http://mailman.sf.net Cheers, -Barry -------------------- snip snip -------------------- 2.1.2 (22-Apr-2003) - New languages Portuguese (Portugal) and Polish. - Many convenient constants have been added to the Defaults.py module to (hopefully) make it more readable. - Email addresses which contain 8-bit characters in them are now rejected and won't be subscribed. This is not the same as 8-bit characters in the realname, which is still allowed. - The X-Originating-Email header is removed for anonymous lists. Hotmail apparently adds this header. - When running make to build Mailman, you can specify $DESTDIR to the install target to specify an alternative location for installation, without influencing the paths stored in e.g. Defaults.py. This is useful to package managers. - New Defaults.py variable DELIVERY_RETRY_WAIT which controls how long the outgoing qrunner will wait before it retries a tempfailure delivery. - The semantics for the extend.py hook to MailList objects has changed slightly. The hook is now called before attempting to lock and load the database. - Mailman now uses the email package version 2.5.1 - bin/transcheck now checks for double-%'s - bin/genaliases grew a -q / --quiet flag - cron/checkdbs grew a -h / --help option. - The -c / --change-msg option has been removed from bin/add_members - bin/msgfmt.py has been added, taken from Python 2.3's Tools/i18n directory. The various .mo files are now no longer distributed with Mailman. They are generated at build time instead. - A new file misc/sitelist.cfg which can be used with bin/config_list provides a small number of recommended settings for your site list. Be sure to read it over before applying! sitelist.cfg is installed into the data directory. - Many bug fixes, including these SourceForge bugs closed and patches applied: 677668, 690448, 700538, 700537, 673294, 683906, 671294, 522080, 521124, 534297, 699900, 697321, 695526, 703941, 658261, 710678, 707608, 671303, 717096, 694912, 707624, 716755, 661138, 716754, 716702, 667167, 725369, 726415 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 350 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20030427/8a6a555b/attachment.bin From barry at python.org Sun Apr 27 18:23:01 2003 From: barry at python.org (Barry Warsaw) Date: Sun Apr 27 13:23:04 2003 Subject: [Mailman-Developers] RELEASED Mailman 2.1.2 Message-ID: <1051464154.9733.116.camel@anthem> I've just released Mailman 2.1.2 which includes many bug fixes and language updates, as well as support for two new languages, Portuguese/Portugal and Polish. I recommend all Mailman 2.1 users upgrade to this release. The full source tarball has been made available from the usual sites. Currently, there is no patch available, but you should be able to install 2.1.2 over your existing 2.1.x installation. See http://sourceforge.net/project/showfiles.php?group_id=103 for links to download all the patches and the source tarballs. Be sure you restart your mailman daemon by doing a "mailmanctl restart" after installing. See also: http://www.gnu.org/software/mailman http://www.list.org (not yet updated) http://mailman.sf.net Cheers, -Barry -------------------- snip snip -------------------- 2.1.2 (22-Apr-2003) - New languages Portuguese (Portugal) and Polish. - Many convenient constants have been added to the Defaults.py module to (hopefully) make it more readable. - Email addresses which contain 8-bit characters in them are now rejected and won't be subscribed. This is not the same as 8-bit characters in the realname, which is still allowed. - The X-Originating-Email header is removed for anonymous lists. Hotmail apparently adds this header. - When running make to build Mailman, you can specify $DESTDIR to the install target to specify an alternative location for installation, without influencing the paths stored in e.g. Defaults.py. This is useful to package managers. - New Defaults.py variable DELIVERY_RETRY_WAIT which controls how long the outgoing qrunner will wait before it retries a tempfailure delivery. - The semantics for the extend.py hook to MailList objects has changed slightly. The hook is now called before attempting to lock and load the database. - Mailman now uses the email package version 2.5.1 - bin/transcheck now checks for double-%'s - bin/genaliases grew a -q / --quiet flag - cron/checkdbs grew a -h / --help option. - The -c / --change-msg option has been removed from bin/add_members - bin/msgfmt.py has been added, taken from Python 2.3's Tools/i18n directory. The various .mo files are now no longer distributed with Mailman. They are generated at build time instead. - A new file misc/sitelist.cfg which can be used with bin/config_list provides a small number of recommended settings for your site list. Be sure to read it over before applying! sitelist.cfg is installed into the data directory. - Many bug fixes, including these SourceForge bugs closed and patches applied: 677668, 690448, 700538, 700537, 673294, 683906, 671294, 522080, 521124, 534297, 699900, 697321, 695526, 703941, 658261, 710678, 707608, 671303, 717096, 694912, 707624, 716755, 661138, 716754, 716702, 667167, 725369, 726415 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 350 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20030427/c68e35da/attachment.bin From barry at python.org Sun Apr 27 18:31:33 2003 From: barry at python.org (Barry Warsaw) Date: Sun Apr 27 13:31:36 2003 Subject: [Mailman-Developers] RELEASED Mailman 2.1.2 Message-ID: <1051464666.5933.126.camel@anthem> [Apologies for the empty dups -- been fiddling with my email client again. ;} -BAW] I've just released Mailman 2.1.2 which includes many bug fixes and language updates, as well as support for two new languages, Portuguese/Portugal and Polish. I recommend all Mailman 2.1 users upgrade to this release. The full source tarball has been made available from the usual sites. Currently, there is no patch available, but you should be able to install 2.1.2 over your existing 2.1.x installation. See http://sourceforge.net/project/showfiles.php?group_id=103 for links to download all the patches and the source tarballs. Be sure you restart your mailman daemon by doing a "mailmanctl restart" after installing. See also: http://www.gnu.org/software/mailman http://www.list.org (not yet updated) http://mailman.sf.net Cheers, -Barry -------------------- snip snip -------------------- 2.1.2 (22-Apr-2003) - New languages Portuguese (Portugal) and Polish. - Many convenient constants have been added to the Defaults.py module to (hopefully) make it more readable. - Email addresses which contain 8-bit characters in them are now rejected and won't be subscribed. This is not the same as 8-bit characters in the realname, which is still allowed. - The X-Originating-Email header is removed for anonymous lists. Hotmail apparently adds this header. - When running make to build Mailman, you can specify $DESTDIR to the install target to specify an alternative location for installation, without influencing the paths stored in e.g. Defaults.py. This is useful to package managers. - New Defaults.py variable DELIVERY_RETRY_WAIT which controls how long the outgoing qrunner will wait before it retries a tempfailure delivery. - The semantics for the extend.py hook to MailList objects has changed slightly. The hook is now called before attempting to lock and load the database. - Mailman now uses the email package version 2.5.1 - bin/transcheck now checks for double-%'s - bin/genaliases grew a -q / --quiet flag - cron/checkdbs grew a -h / --help option. - The -c / --change-msg option has been removed from bin/add_members - bin/msgfmt.py has been added, taken from Python 2.3's Tools/i18n directory. The various .mo files are now no longer distributed with Mailman. They are generated at build time instead. - A new file misc/sitelist.cfg which can be used with bin/config_list provides a small number of recommended settings for your site list. Be sure to read it over before applying! sitelist.cfg is installed into the data directory. - Many bug fixes, including these SourceForge bugs closed and patches applied: 677668, 690448, 700538, 700537, 673294, 683906, 671294, 522080, 521124, 534297, 699900, 697321, 695526, 703941, 658261, 710678, 707608, 671303, 717096, 694912, 707624, 716755, 661138, 716754, 716702, 667167, 725369, 726415 From marc_news at merlins.org Sun Apr 27 23:01:25 2003 From: marc_news at merlins.org (Marc MERLIN) Date: Mon Apr 28 01:01:33 2003 Subject: [Mailman-Developers] More tracebacks with mailman-cvs In-Reply-To: <20030425160124.GN24554@merlins.org> References: <20030425160124.GN24554@merlins.org> Message-ID: <20030428050125.GD4054@merlins.org> On Fri, Apr 25, 2003 at 09:01:24AM -0700, Marc MERLIN wrote: > I just did a CVS update again since I was still getting these, and one of > my installs also dies on subscriptions > > Traceback (most recent call last): > File "/var/local/mailman/scripts/driver", line 87, in run_main > main() > File "/var/local/mailman/Mailman/Cgi/subscribe.py", line 96, in main > process_form(mlist, doc, cgidata, language) > File "/var/local/mailman/Mailman/Cgi/subscribe.py", line 176, in process_form > mlist.AddMember(userdesc, remote) > File "/var/local/mailman/Mailman/MailList.py", line 806, in AddMember > cookie = Pending.new(Pending.SUBSCRIPTION, userdesc) > File "/var/local/mailman/Mailman/Pending.py", line 75, in new > db = _load() > File "/var/local/mailman/Mailman/Pending.py", line 163, in _load > return cPickle.load(fp) > EOFError This is seriously impacting me now. I downgraded to mm 2.1.2 and the problem is still there. No one can subscribe anymore... Do I need to blow a pickle? Thanks Marc > (go to http://lists.svlug.org/lists/listinfo/svlug and join if you want > to reproduce) > > Thanks > Marc > > ----- Forwarded message from Cron Daemon ----- > > From: root@svlug.org (Cron Daemon) > To: mailman@svlug.org > X-Cron-Env: > X-Cron-Env: > X-Cron-Env: > X-Cron-Env: > Subject: Cron /usr/bin/python -S /var/local/mailman/cron/disabled > > Traceback (most recent call last): > File "/var/local/mailman/cron/disabled", line 209, in ? > main() > File "/var/local/mailman/cron/disabled", line 201, in main > mlist.sendNextNotification(member) > File "/var/local/mailman/Mailman/Bouncer.py", line 212, in sendNextNotification > Pending.confirm(info.cookie) > File "/var/local/mailman/Mailman/Pending.py", line 133, in confirm > db = _load() > File "/var/local/mailman/Mailman/Pending.py", line 163, in _load > return cPickle.load(fp) > EOFError > > > ----- End forwarded message ----- > > -- > "A mouse is a device used to point at the xterm you want to type in" - A.S.R. > Microsoft is to operating systems & security .... > .... what McDonalds is to gourmet cooking > Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From john at momsview.com Mon Apr 28 06:44:07 2003 From: john at momsview.com (John Distler) Date: Mon Apr 28 05:44:33 2003 Subject: [Mailman-Developers] suppressing appending of generic welcome message References: <5.1.1.6.0.20030426171404.03c306e8@pop3.demon.co.uk> Message-ID: <005601c30d6a$b6f35280$0201a8c0@p3> This is for Mailman 2.1 or later Create a directory as mailman.mailman called ~mailman/lists/your-list-name/language-of-choice/ where your-list-name is the name of your list and language-of-choice would be "en" for english "de" for german, etc. Copy the file subscribeack.txt from ~mailman/templates/language-of-choice/ to ~mailman/lists/your-list-name/language-of-choice/ Edit subscribeack.txt with your favorite text editor so it contains this on the first line: %(welcome)s This will leave only the contents of the welcome message that you entered in the web ui Cheers! From marc_news at merlins.org Tue Apr 29 09:57:46 2003 From: marc_news at merlins.org (Marc MERLIN) Date: Tue Apr 29 11:57:52 2003 Subject: [Mailman-Developers] What happened to MAILMAN_UID, MAILMAN_GID? In-Reply-To: <20030425155915.GM24554@merlins.org> References: <20030425155915.GM24554@merlins.org> Message-ID: <20030429155746.GA4368@merlins.org> On Fri, Apr 25, 2003 at 08:59:15AM -0700, Marc MERLIN wrote: > It looks like those were removed or renamed recently and it broke > check_perms_grsecurity.py > > What am I supposed to use now? MAILMAN_USER/MAILMAN_GROUP, I see... Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From wheakory at isu.edu Wed Apr 30 13:20:45 2003 From: wheakory at isu.edu (Kory Wheatley) Date: Wed Apr 30 14:20:48 2003 Subject: [Mailman-Developers] public and private archives problem Message-ID: <3EB013FD.7090506@isu.edu> I'm getting this below error when an user tries to open up there archives. I've run check_perms and all the permissions are correct. When I change the archive options on this list to public I get this below error when I change it back to private I can view the threaded archives fine, is there a solution to this. I've tested this with my other lists and it does the same thing. There most be something that I've got configured wrong that a list can't be setup to view the archives in the (public) setting. ACCESS DENIED ! You don't have permission to access the requested directory. There is either no index document or the directory is read-protected. If you think this is a server error, please contact the webmaster ERROR 403 mm.isu.edu Wed Apr 30 11:47:13 2003 Apache/2.0.40 (Red Hat Linux) -- Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 ######################################### Everything must point to him. From wheakory at isu.edu Wed Apr 30 13:26:51 2003 From: wheakory at isu.edu (Kory Wheatley) Date: Wed Apr 30 14:26:51 2003 Subject: [Mailman-Developers] public and private archives problem References: <3EB013FD.7090506@isu.edu> Message-ID: <3EB0156B.4020204@isu.edu> Never Miind I fixed the problem. Kory Wheatley wrote: > I'm getting this below error when an user tries to open up there > archives. I've run check_perms and all the permissions are correct. > When I change the archive options on this list to public I get this > below error when I change it back to private I can view the threaded > archives fine, is there a solution to this. I've tested this with my > other lists and it does the same thing. There most be something that > I've got configured wrong that a list can't be setup to view the > archives in the (public) setting. > > > ACCESS DENIED ! > > You don't have permission to access the requested directory. There > is either no index document or the directory is read-protected. > > If you think this is a server error, please contact the webmaster > > ERROR 403 > > mm.isu.edu > Wed Apr 30 11:47:13 2003 > Apache/2.0.40 (Red Hat Linux) > > -- Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 ######################################### Everything must point to him. From jdub at perkypants.org Mon Apr 28 03:02:42 2003 From: jdub at perkypants.org (Jeff Waugh) Date: Wed Apr 30 17:29:31 2003 Subject: [Mailman-Developers] Priority/status of moderated-edit and external user DB In-Reply-To: <009b01c30ac8$b8c82fd0$0501a8c0@kevinduron> References: <009b01c30ac8$b8c82fd0$0501a8c0@kevinduron> Message-ID: <20030427160242.GL11992@lazarus> > 1) External user database. I'm sure you're all aware of the desire of some > folks to have this. I found a Wiki document somewhere on the zope.org site > that had discussions on this but I believe it was somewhat dated. Have any > conclusions been reached with respect to the direction here? I think I > read talk of a Zope-specific solution. I'm wondering if this means that > we're likely never to see a Mailman that can talk to a MySQL database. I > believe this one feature alone would elevate Mailman significantly. How > hgh of a priority is this to the development team and what is the status? > Are there current discussions on this somewhere other than the list (wiki > boards, chats, what-have-you) , and if so, may I take part? See MemberAdapter in Mailman 2.1.x. As it happens, I'm currently writing an advanced LDAP backend [ yes, I've see the other one :-) ]. - Jeff -- linux.conf.au 2004: Adelaide, Australia http://lca2004.linux.org.au/ "We are peaking sexually when they are peaking. And two peaks makes a hell of a good mount." - SMH From RabbiSim at earthlink.net Sun Apr 27 11:45:42 2003 From: RabbiSim at earthlink.net (Rabbi Simcha Backman) Date: Wed Apr 30 17:29:35 2003 Subject: [Mailman-Developers] RE: [Mailman-Announce] RELEASED Mailman 2.1.2 In-Reply-To: <1051463473.9733.105.camel@anthem> Message-ID: <001501c30ce4$d6254770$0201a8c0@smile> Are you by any chance planning a Hebrew release of Mailman, do you know of anyone using it for a Hebrew list? Thanks -----Original Message----- From: mailman-announce-bounces@python.org [mailto:mailman-announce-bounces@python.org] On Behalf Of Barry Warsaw Sent: Sunday, April 27, 2003 10:11 AM To: mailman-announce@python.org Cc: mailman-developers@python.org; mailman-users@python.org Subject: [Mailman-Announce] RELEASED Mailman 2.1.2 I've just released Mailman 2.1.2 which includes many bug fixes and language updates, as well as support for two new languages, Portuguese/Portugal and Polish. I recommend all Mailman 2.1 users upgrade to this release. The full source tarball has been made available from the usual sites. Currently, there is no patch available, but you should be able to install 2.1.2 over your existing 2.1.x installation. See http://sourceforge.net/project/showfiles.php?group_id=103 for links to download all the patches and the source tarballs. Be sure you restart your mailman daemon by doing a "mailmanctl restart" after installing. See also: http://www.gnu.org/software/mailman http://www.list.org (not yet updated) http://mailman.sf.net Cheers, -Barry -------------------- snip snip -------------------- 2.1.2 (22-Apr-2003) - New languages Portuguese (Portugal) and Polish. - Many convenient constants have been added to the Defaults.py module to (hopefully) make it more readable. - Email addresses which contain 8-bit characters in them are now rejected and won't be subscribed. This is not the same as 8-bit characters in the realname, which is still allowed. - The X-Originating-Email header is removed for anonymous lists. Hotmail apparently adds this header. - When running make to build Mailman, you can specify $DESTDIR to the install target to specify an alternative location for installation, without influencing the paths stored in e.g. Defaults.py. This is useful to package managers. - New Defaults.py variable DELIVERY_RETRY_WAIT which controls how long the outgoing qrunner will wait before it retries a tempfailure delivery. - The semantics for the extend.py hook to MailList objects has changed slightly. The hook is now called before attempting to lock and load the database. - Mailman now uses the email package version 2.5.1 - bin/transcheck now checks for double-%'s - bin/genaliases grew a -q / --quiet flag - cron/checkdbs grew a -h / --help option. - The -c / --change-msg option has been removed from bin/add_members - bin/msgfmt.py has been added, taken from Python 2.3's Tools/i18n directory. The various .mo files are now no longer distributed with Mailman. They are generated at build time instead. - A new file misc/sitelist.cfg which can be used with bin/config_list provides a small number of recommended settings for your site list. Be sure to read it over before applying! sitelist.cfg is installed into the data directory. - Many bug fixes, including these SourceForge bugs closed and patches applied: 677668, 690448, 700538, 700537, 673294, 683906, 671294, 522080, 521124, 534297, 699900, 697321, 695526, 703941, 658261, 710678, 707608, 671303, 717096, 694912, 707624, 716755, 661138, 716754, 716702, 667167, 725369, 726415 From jdub at perkypants.org Mon Apr 28 16:56:20 2003 From: jdub at perkypants.org (Jeff Waugh) Date: Wed Apr 30 17:29:39 2003 Subject: [Mailman-Developers] RELEASED Mailman 2.1.2 In-Reply-To: <1051464666.5933.126.camel@anthem> References: <1051464666.5933.126.camel@anthem> Message-ID: <20030428055620.GB24149@lazarus> > [Apologies for the empty dups -- been fiddling with my email client again. > ;} -BAW] In that case, *thrice* congrats and thanks for the new release. :-) - Jeff -- linux.conf.au 2004: Adelaide, Australia http://lca2004.linux.org.au/ "Whoever wrote [the Twisted documentation] uses a vivid and interesting style of prose which triggers pleasure." - Francois Pinard From knauff at urz.uni-halle.de Mon Apr 28 09:32:05 2003 From: knauff at urz.uni-halle.de (Leonhard Knauff) Date: Wed Apr 30 17:29:42 2003 Subject: [Mailman-Developers] Mailman with Exim: README.EXIM to correct Message-ID: <200304280632.IAA20964@mlucom6.urz.uni-halle.de> Hallo, I use (will use) Mailman 2.1.1 in a Solaris 8 Sun Cluster 3.0 High Availability Environment (with Exim 3.36). Therefore I installed the binaries, configurations, ... on each host of the cluster (so I can update on each host separate), and the variable data only one times on the shared disks: ./configure --prefix=/usr/local/mailman --with-var-prefix=/global/web/mailman The different prefixes ($prefix, $varprefix) must reflect in the Exim 3 "configure" file now: > MAILMAN_HOME = /usr/local/mailman # OK, $prefix > MAILMAN_VAR = /global/web/mailman # NEW, $varprefix !!! > > mailman_director: > require_files= MAILMAN_VAR/lists/$local_part/config.pck ^^^^^^^^^^^ CORRECTED !!!!! Use of MAILMAN_HOME is wrong! I think the same must be done in the mailman_router under Exim 4. So the file README.EXIM should be updated. The mailman_transport under Exim 3 seens to work. :-) Regards, Leonhard Knauff -- /---------------------------------------------------------------------------\ | Leonhard Knauff Phone: +49 345 55-21890 | | Martin-Luther-Universitaet Halle-Wittenberg Fax: +49 345 55-27008 | | Universitaetsrechenzentrum, Kurt-Mothes-Str. 1, D-06120 Halle (Saale) | | EMail: knauff@urz.uni-halle.de | \---------------------------------------------------------------------------/ From U.Linn at LinnWeb.de Mon Apr 28 09:47:34 2003 From: U.Linn at LinnWeb.de (Uli Linn) Date: Wed Apr 30 17:29:46 2003 Subject: [Mailman-Developers] AW: [Mailman-Announce] RELEASED Mailman 2.1.2 In-Reply-To: <1051464666.5933.126.camel@anthem> Message-ID: <004e01c30d52$0d0f6d20$0a00a8c0@MIRACULIX> Hi Barry! > [Apologies for the empty dups -- been fiddling with my email > client again. ;} -BAW] My Webspace-Provider has installed Mailman on all Accounts and so I use it for about 2 years - fine thing. But Since the last update my provider made (a few month ago) All Mails with attachments look the same way the mail you sent - 3 Attachments with Mailtext, Attachment, and Footer in it. My Provider could'nt help me - do you have any suggestions what to do? The 1.x Versions of Mailman did not have this Problem. Greetings from Germany Uli Linn ------------------------------------------------------ Uli Linn LINN Internet Marketing Fon: +49-6831-976789 Waldstra?e 19 Fax: +49-6831-976788 D-66763 Dillingen Mail: U.Linn@LinnWeb.de URL: http://www.LinnWeb.de > -----Urspr?ngliche Nachricht----- > Von: mailman-announce-bounces@python.org > [mailto:mailman-announce-bounces@python.org] Im Auftrag von > Barry Warsaw > Gesendet: Sonntag, 27. April 2003 19:31 > An: mailman-announce@python.org > Cc: mailman-developers@python.org; mailman-users@python.org > Betreff: [Mailman-Announce] RELEASED Mailman 2.1.2 > > > > I've just released Mailman 2.1.2 which includes many bug > fixes and language updates, as well as support for two new > languages, Portuguese/Portugal and Polish. I recommend all > Mailman 2.1 users upgrade to this release. > > The full source tarball has been made available from the usual sites. > Currently, there is no patch available, but you should be > able to install 2.1.2 over your existing 2.1.x installation. See > > http://sourceforge.net/project/showfiles.php?group_id=103 > > for links to download all the patches and the source tarballs. > > Be sure you restart your mailman daemon by doing a > "mailmanctl restart" after installing. > > See also: > > http://www.gnu.org/software/mailman > http://www.list.org (not yet updated) > http://mailman.sf.net > > Cheers, > -Barry > > -------------------- snip snip -------------------- > 2.1.2 (22-Apr-2003) > > - New languages Portuguese (Portugal) and Polish. > > - Many convenient constants have been added to the Defaults.py > module to (hopefully) make it more readable. > > - Email addresses which contain 8-bit characters in them are now > rejected and won't be subscribed. This is not the same as 8-bit > characters in the realname, which is still allowed. > > - The X-Originating-Email header is removed for anonymous lists. > Hotmail apparently adds this header. > > - When running make to build Mailman, you can specify $DESTDIR to > the install target to specify an alternative location for > installation, without influencing the paths stored in > e.g. Defaults.py. This is useful to package managers. > > - New Defaults.py variable DELIVERY_RETRY_WAIT which controls how > long the outgoing qrunner will wait before it retries a > tempfailure delivery. > > - The semantics for the extend.py hook to MailList objects has > changed slightly. The hook is now called before attempting to > lock and load the database. > > - Mailman now uses the email package version 2.5.1 > > - bin/transcheck now checks for double-%'s > > - bin/genaliases grew a -q / --quiet flag > > - cron/checkdbs grew a -h / --help option. > > - The -c / --change-msg option has been removed from > bin/add_members > > - bin/msgfmt.py has been added, taken from Python 2.3's Tools/i18n > directory. The various .mo files are now no longer distributed > with Mailman. They are generated at build time instead. > > - A new file misc/sitelist.cfg which can be used with > bin/config_list provides a small number of recommended settings > for your site list. Be sure to read it over before applying! > sitelist.cfg is installed into the data directory. > > - Many bug fixes, including these SourceForge bugs closed and > patches applied: 677668, 690448, 700538, 700537, 673294, 683906, > 671294, 522080, 521124, 534297, 699900, 697321, 695526, 703941, > 658261, 710678, 707608, 671303, 717096, 694912, 707624, 716755, > 661138, 716754, 716702, 667167, 725369, 726415 > > > > _______________________________________________ > Mailman-announce mailing list > Mailman-announce@python.org > http://mail.python.org/mailman/listinfo/mailma> n-announce > From agreene at pobox.com Mon Apr 28 08:47:34 2003 From: agreene at pobox.com (Anthony E. Greene) Date: Wed Apr 30 17:29:50 2003 Subject: [Mailman-Developers] Request update of list information page Message-ID: <3EAD14D6.1020807@pobox.com> I've been a list owner for several years, using several different list mgt packages. I've also managed web sites and done some help desk work. I'm not a Mailman developer, but the Sourceforge page for bug submission suggested that the developers be notified directly of bug submissions, so here goes. ******************************************************************** Bug# 728122: Unsub instructions difficult to find The default Mailman info page for the list could stand some improvements. I've noticed it over and over and finally decided to contribute to a solution instead of griping about the problem. ;-) I recommend these two changes: 1. Move the administrative "$listname Subscribers" section to the bottom of the page. Admins will know where to look and subscribers should not have to read through admin info to get to the section that concerns them (changing subscription options). 2. Add a standard colored section header titled "Change Options or Unsubscribe". The original format for this section did not clearly indicate that this is the section for unsubscribing. Users have to read the fine print. Reading the fine print is fine for detailed instructions, but the users should have some idea that the unsub instructions are there just by looking at the section header. ********************************************************************* A sample HTML page is attached to the Bug record. Tony -- Anthony E. Greene OpenPGP Key: 0x6C94239D/7B3D BD7D 7D91 1B44 BA26 C484 A42A 60DD 6C94 239D AOL/Yahoo Chat: TonyG05 HomePage: Linux. The choice of a GNU generation. From tonu at spam.ee Mon Apr 28 14:00:28 2003 From: tonu at spam.ee (Tonu Samuel) Date: Wed Apr 30 17:29:53 2003 Subject: [Mailman-Developers] Mails get lost with different 2.1.x mailmans, including today's CVS Message-ID: <1051534792.14541.67.camel@linux.local> New to this list but checked FAQ. Was not able to find solution. I am using mailman from CVS and this bug seems to be unfixed. Description: We are running company with 200 computer workstations and over 20 lists on mailman. Once our user was able to prove, that sometime mailman just deletes the subject. Instead of original subject we have "[foo] (no subject)". My first reaction was to upgrade mailman. I did "cvs update" and behaviour changed - no mails come through from this user. I believe after many tests I knopw what is the issue but I do not want to dig into Python code. Hope, someone else can fix it. We are located in Estonia and our native language uses some unique characters ä and õ (in HTML terms). At some point Microsoft invented new charset "Windows-1257" while actually "ISO8859-15" covers our needs. Many kind of software tries to interpret charsets and gets confused on pretty usual characters because this "windows-1257". I have no power to make different people change their country settings. Only way is to make software act different when unknown charset appears. Mailman currently "eats" characters with unknown charsets and this is bad for us. Original mail subject line in raw data: Subject: =?windows-1257?Q?FW:_=E4=E4test_kustutage_=E4ra?= And this makes mailman to loose mail. With latest version it archives mail without subject and never sends it out to subscribers. No error messages sent to anyone indicating mail loss. In some point it saved this mail in "shunt" folder but mail lost without any tracks after "unshunt" command. Any fixes? ideas? I propose to include bytes from unknown charsets in redistributed mails. If this seems not possible, read "windows-1257" as ISO8859-15 and I think it will work for most cases. -- Tonu Samuel From admin at chirolists.com Wed Apr 30 13:48:30 2003 From: admin at chirolists.com (admin@chirolists.com) Date: Wed Apr 30 17:29:57 2003 Subject: [Mailman-Developers] Hacking at MM In-Reply-To: <3EB013FD.7090506@isu.edu> Message-ID: <5.2.0.9.0.20030430124630.026f9888@jbod.calchiro.com> I've been doing a bit of hacking on MM the past couple of weeks, mainly HTML related formatting (straight and in python)...I was kinda curious how someone got involved in the project.... Thanks, Brian