From andyster at gmail.com Tue Nov 2 20:16:21 2004 From: andyster at gmail.com (Andy Smith) Date: Tue Nov 2 20:16:28 2004 Subject: [Mailman-Developers] Sxip and Mailman Message-ID: <5419014104110211165c2c3880@mail.gmail.com> Hey, My name is Andy Smith, I'm one of the open source developers over at Sxip Networks (https://sxip.org), and I've been charged with adding SXIP support to Mailman, initially for our own internal uses but to be released open source and as an add-on to Mailman. SXIP is a protocol for digital identity (Simple eXstensible Identity Protocol) that allows, among other things, single-sign on and secure attribute verification (ssl signing of xml data and whatnot). It's all open source and non-evil, too. It's fairly interesting and if you're interested hit up the site for more info (or just ask). I am mailing this to you folks here on the developers list for two reasons, one, because I'd like to be giving this work over to you (the community) once I am finished, and two, because you all know much more about Mailman than I do in the short time I have been examining the code and any pointers or suggestions you can give me will surely be very helpful. So, the goal of my work is to enable single-sign on for Mailman along the lines of the following scenario: ( "sxip in" = sign on, just using our branding ) - User arrives at a mailman site for the first time, and is presented with an overview of public lists. On the page will be a sxip in button and a paragraph informing the user that he/she will have to sxip in to subscribe to a list or see any non-public lists that he/she might have permission to. - If a user sxips in right there the overview will be updated to to contain checkboxes and other relevant links so that a user can subscribe to any number of lists at the same time, or if they have mod or admin access they would see a couple other options. I'm not totally sure at this point what these options should be. - If a user does not sxip in on this first page and instead clicks on a list to see the list info, he/she will be taken to the list info page, with a similar sxip in button and paragraph. In order to subscribe to a list or get any further, the user will have to sxip in. A "subscribe to this list" link will be provided but it will just force the user to sxip in and then present them with a prompt to confirm that they'd like to subscribe. - Once the user sxips in here, they will be taken back to the list info page but with more options available, including mod or admin links if appropriate to their authentication level. - A user will not need to confirm subscription via an email when subscribing this way, because during sxip in a verified email address (as well as first and last name) will be provided through the sxip in process (this is one of the features of the protocol). How I plan to do this, and please let me know if some of these things seem totally off, I've looked through the code but I may have misunderstood something: - Data will be stored in the same way as the other mailman data, using pickled flat files. * There will be a new file that represents all the admins and moderators on the system keyed on listname, with values consisting of a dictionary of keyed on user email addresses with values containing their authorization level * Note: How to handle list creator privilege? specific "site" key in the root of the structure? * It should be possible to make use of the current password scheme involved with the cookies to associate privileges with a user based on list in this data structure, this has the benefit of allowing the simple overloading of the function that checks the cookie data. See Mailman.SecurityManager for the functions used to handle passwords and check cookies. - User properties will remain in the current format, as will list info, nothing new is required there. - To enable sxipping out, true sessions will have to be implemented, which could be done using code as described at http://starship.python.net/crew/davem/cgifaq/faqw.cgi?req=show&file=faq02.011.htp, however the code there is not fully secure and sxip out support may not be a priority at the beginning (just let the cookie expire?). - There will be a new set of UI pages once the initial work is done to allow a user to sxip in to a session * A page requesting a sxip in, to be called by the various CGI scripts when a user attempts to go somewhere that requires auth. Overload Mailman.Cgi.Auth.loginpage * List Overview will have to be overloaded to show subscription options once sxipped in * List Info will give admin and mod options when sxipped in * All cgi scripts will have to be checked to be sure they authenticate first - To add a new member during sxipped in subscription will overload ApprovedAddMember in Mailman.MailList to be used automatically by sxipping in - To get the lists that a user belongs to and their privileges, a sweep of the list data will have to be performed, which is a little bit of a performance hit, ideally this could be cached in the future but for now I will just hope the performance isn't too drastically poor. Hopefully this model makes sense, I look forward to any comments or suggestions you may have. - Andy Smith Army of Coding Monkeys MSN: msn@anarkystic.com Jabber: termie@jabber.org http://anarkystic.com/blog From scphantm at yahoo.com Thu Nov 4 22:31:45 2004 From: scphantm at yahoo.com (Steel City Phantom) Date: Thu Nov 4 22:30:55 2004 Subject: [Mailman-Developers] hooking mailman into bbs forum Message-ID: <418A9FC1.2060808@yahoo.com> i am in the planning stages of building a knowledge storage system. i have decided to organize the data and the discussions in a forum type layout and i want an email interaction with the PHP pages on the forum. so my question is this, does anyone know of any effort to port the message archive systems in mailman to MySQL? the reason i want to use mailman is i have used it in the past for various lists and really like its speed and stability. when it comes to a distribution list, i really don't want to reinvent the wheel. i don't want my web server or my JBoss server to have to deal with emailing people every day. i want that to be a third server sitting in the network handling that task. the plan i have been kicking around is my PHP and JBoss systems would automatically create a mailman list for every forum subject. for the users, i will create another interface where they can opt to be emailed all the discussions that happen in the forum. when they opt in, the scripts will create a user for that person in the list. The PHP interface will be set up so when someone goes into the interface to post a topic or reply, it will save it to the database and send a copy to the mailman list. that email that is sent to mailman will have hidden fields in the HTML that will be used if the person replys to the email in order to track the threading and such in the database. up to this point, its easy enough, now the hard part. if someone replys to the email they receive from mailman, how to i get mailman to either post the reply into the mysql database, or another option will be send my JBoss servlet the email formatted into some kind of xml that the JBoss can use to post into the forum. if anyone can point me into a direction to do this, it would help me a lot. i just downloaded 2.1.5 and am starting to find my way around the code, but that will take a while. thanks willie From terri at zone12.com Thu Nov 4 23:40:51 2004 From: terri at zone12.com (Terri Oda) Date: Thu Nov 4 23:40:58 2004 Subject: [Mailman-Developers] hooking mailman into bbs forum In-Reply-To: <418A9FC1.2060808@yahoo.com> References: <418A9FC1.2060808@yahoo.com> Message-ID: <949F7E24-2EB2-11D9-8AE1-000D934FBF38@zone12.com> On Nov 4, 2004, at 4:31 PM, Steel City Phantom wrote: > if someone replys to the email they receive from mailman, how to i get > mailman to either post the reply into the mysql database, or another > option will be send my JBoss servlet the email formatted into some > kind of xml that the JBoss can use to post into the forum. > > if anyone can point me into a direction to do this, it would help me a > lot. i just downloaded 2.1.5 and am starting to find my way around > the code, but that will take a while. Have you looked at making an archiver for mailman that just dumps stuff into your database? I'd guess that you could go webform -> mailman -> jboss email -> mailman -> jboss then, so you'd have to switch your bbs to send everything to mailman and not archive it, then have posts archived after they've been handled by mailman. But then it wouldn't matter where the message came from initially, be it a web submission or an email reply. A BBS system might make a particularly nice archiver, too... Terri From scphantm at yahoo.com Thu Nov 4 23:53:22 2004 From: scphantm at yahoo.com (Steel City Phantom) Date: Thu Nov 4 23:52:33 2004 Subject: [Mailman-Developers] hooking mailman into bbs forum In-Reply-To: <949F7E24-2EB2-11D9-8AE1-000D934FBF38@zone12.com> References: <418A9FC1.2060808@yahoo.com> <949F7E24-2EB2-11D9-8AE1-000D934FBF38@zone12.com> Message-ID: <418AB2E2.3030202@yahoo.com> the term archiver tells me some routine that runs at night to roll everything up. could i do it with an archiver and still be real time? Terri Oda wrote: > On Nov 4, 2004, at 4:31 PM, Steel City Phantom wrote: > >> if someone replys to the email they receive from mailman, how to i >> get mailman to either post the reply into the mysql database, or >> another option will be send my JBoss servlet the email formatted into >> some kind of xml that the JBoss can use to post into the forum. >> >> if anyone can point me into a direction to do this, it would help me >> a lot. i just downloaded 2.1.5 and am starting to find my way around >> the code, but that will take a while. > > > Have you looked at making an archiver for mailman that just dumps > stuff into your database? I'd guess that you could go > > webform -> mailman -> jboss > email -> mailman -> jboss > > then, so you'd have to switch your bbs to send everything to mailman > and not archive it, then have posts archived after they've been > handled by mailman. But then it wouldn't matter where the message > came from initially, be it a web submission or an email reply. A BBS > system might make a particularly nice archiver, too... > > Terri > > > From skitta at abo.fi Wed Nov 10 13:39:35 2004 From: skitta at abo.fi (Tomas Lindroos DC) Date: Wed Nov 10 13:39:39 2004 Subject: [Mailman-Developers] scrubber crash due to insanely long filename Message-ID: Hello everybody, I am running Mailman 2.1.5 and noticed this problem with the "senddigests" cron-job. If a message has an attachment with a really long filename, Scrubber.py crashes: --- Traceback (most recent call last): File "/export/mailman/cron/senddigests", line 94, in ? main() File "/export/mailman/cron/senddigests", line 86, in main mlist.send_digest_now() File "/export/mailman/Mailman/Digester.py", line 60, in send_digest_now ToDigest.send_digests(self, mboxfp) File "/export/mailman/Mailman/Handlers/ToDigest.py", line 132, in send_digests send_i18n_digests(mlist, mboxfp) File "/export/mailman/Mailman/Handlers/ToDigest.py", line 306, in send_i18n_digests msg = scrubber(mlist, msg) File "/export/mailman/Mailman/Handlers/Scrubber.py", line 240, in process url = save_attachment(mlist, part, dir) File "/export/mailman/Mailman/Handlers/Scrubber.py", line 445, in save_attachment fp = open(path, 'w') IOError: [Errno 36] File name too long: '/var/mailman/archives/private/LISTNAME/attachments/20041007/16a8914c/INSANELY_LONG_FILENAME_WITH_320_CHARS_TOTAL.eml' --- The problem didn't go away without admin intervention, and I suspect that no digest-mail was sent out while the problem persisted. The actual bug seems to be that there is not a try-except-block around the open() call, if the call fails, the Scrubber fails. Perhaps it could be added? To get around this particular problem, I made this small patch to Scrubber.py: --- Scrubber.py~ Thu Sep 30 14:15:19 2004 +++ Scrubber.py Wed Nov 10 11:51:21 2004 @@ -396,6 +396,10 @@ # after filebase, e.g. msgdir/filebase-cnt.ext counter = 0 extra = '' + # check for insanely long filenames + if len(filebase + extra + ext)>=256: + filebase=filebase[:255-5-len(ext)] # 5 chars for extra + while True: path = os.path.join(fsdir, filebase + extra + ext) # Generally it is not a good idea to test for file existance Now, this is not a perfect solution, since the same problem will occur if the string "extra" becomes longer than 5 chars in the while-loop below. Perhaps the 5 should be substituted by min(5,len(extra)) or something... This is not thouroghly tested, I just wanted to get the digests working again, so there may be pitfalls I didn't think of. Someone else with more insight into Mailman could probably implement this better. (How to get 320 chars into a filename? Send an attachment with a 245 char long filename containing a lot of scandinavian or other 8-bit characters in it. Watch the ???'s get mangeled into a strings like 'sE4ISO-8859-1QE4ntF6muutokset2C', and you'll have a lot more than 255 chars in a while...) /skitta -- Tomas 'Skitta' Lindroos. Planerare vid Datacentralen, UNIX-sektionen , tel.nr. (215)4469 From tkikuchi at is.kochi-u.ac.jp Wed Nov 10 14:01:09 2004 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Wed Nov 10 14:01:27 2004 Subject: [Mailman-Developers] scrubber crash due to insanely long filename In-Reply-To: References: Message-ID: <41921115.3090502@is.kochi-u.ac.jp> Hi, Tomas Lindroos DC wrote: > > Hello everybody, > > I am running Mailman 2.1.5 and noticed this problem with the > "senddigests" cron-job. > > If a message has an attachment with a really long filename, Scrubber.py > crashes: This was the reason why I introduced SCRUBBER_DONT_USE_ATTACHMENT_FILENAME in Defaults.py in the latest CVS (Release_2_1-maint). You can set this True in mm_cfg.py and 'attachment(-NNN)' will be used for the file name. Cheers, -- Tokio Kikuchi tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From tgc at statsbiblioteket.dk Thu Nov 11 10:02:56 2004 From: tgc at statsbiblioteket.dk (Tom G. Christensen) Date: Thu Nov 11 10:02:59 2004 Subject: [Mailman-Developers] New much improved danish translation available Message-ID: <41932AC0.1010704@statsbiblioteket.dk> Hi, Over the summer myself and a colleague completely redid the danish translation and it is now *much* improved. All the templates are now translated and so is all of the messagecatalog. I've talked to the Danish i18n champion and he agrees that this new translation should be committed to CVS and replace what is there now. Unfortunately he's not able to do it (no CVS access). Is there anyone here who can help me? -tgc -- Tom G. Christensen - State and University Library - Aarhus - Denmark Email: tgc@statsbiblioteket.dk - Tel: +45 8946 2027 - Fax: +45 8946 2029 From tkikuchi at is.kochi-u.ac.jp Thu Nov 11 11:28:43 2004 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Thu Nov 11 11:28:57 2004 Subject: [Mailman-Developers] New much improved danish translation available In-Reply-To: <41932AC0.1010704@statsbiblioteket.dk> References: <41932AC0.1010704@statsbiblioteket.dk> Message-ID: <41933EDB.8020506@is.kochi-u.ac.jp> Send me the files in tar format. I am in charge of updating 2.1 maint branch now. Tom G. Christensen wrote: > Hi, > > Over the summer myself and a colleague completely redid the danish > translation and it is now *much* improved. > All the templates are now translated and so is all of the messagecatalog. > > I've talked to the Danish i18n champion and he agrees that this new > translation should be committed to CVS and replace what is there now. > Unfortunately he's not able to do it (no CVS access). > > Is there anyone here who can help me? > > -tgc > -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From barry at python.org Thu Nov 11 17:48:38 2004 From: barry at python.org (Barry Warsaw) Date: Thu Nov 11 17:48:42 2004 Subject: [Mailman-Developers] New much improved danish translation available In-Reply-To: <41932AC0.1010704@statsbiblioteket.dk> References: <41932AC0.1010704@statsbiblioteket.dk> Message-ID: <1100191718.8606.65.camel@geddy.wooz.org> On Thu, 2004-11-11 at 04:02, Tom G. Christensen wrote: > I've talked to the Danish i18n champion and he agrees that this new > translation should be committed to CVS and replace what is there now. > Unfortunately he's not able to do it (no CVS access). > > Is there anyone here who can help me? Tokio has offered to update the translation (thanks to you both!). Should we update the Danish champion information on the i18n.html page? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041111/2d91c004/attachment.pgp From andyster at gmail.com Fri Nov 12 03:23:19 2004 From: andyster at gmail.com (Andy Smith) Date: Fri Nov 12 03:23:21 2004 Subject: [Mailman-Developers] Mailman with SXIP support, preliminary demo Message-ID: <5419014104111118233b500a40@mail.gmail.com> I posted earlier about my mission to add SXIP support to Mailman, so this is a follow-up on that now that some code is complete. I think I have hit all the areas that needed authentication, although the options area is notably weak as far as integration goes. To use the demo you will need a sxip account on https://demohomesite.com, it is a pretty painless sign up (and it ideally will prevent having to do these kinds of sign ups again). Demo at: http://listserva.beta.sxip.org/mailman/sxip/listinfo (Anybody who would like an admin account to test out that interface is welcome to email me so that I can add their email address as an admin or moderator) Everything should be contained under the /mailman/sxip/ path, if it should fall into /mailman/ I'd appreciate a bug report ;) Current code available at: http://an9.org/data/mm_sxip.tar.gz or in svn at http://an9.org/p/browser/mm_sxip Any comments, suggestions (especially those that include code) are eagerly awaited. - Andy Smith From andyster at gmail.com Fri Nov 12 03:25:15 2004 From: andyster at gmail.com (Andy Smith) Date: Fri Nov 12 03:25:18 2004 Subject: [Mailman-Developers] Re: Mailman with SXIP support, preliminary demo In-Reply-To: <5419014104111118233b500a40@mail.gmail.com> References: <5419014104111118233b500a40@mail.gmail.com> Message-ID: <5419014104111118251a315da7@mail.gmail.com> That should have been http://listserv.beta.sxip.org/mailman/sxip/listinfo (no 'a') From bob at nleaudio.com Fri Nov 12 03:31:40 2004 From: bob at nleaudio.com (Bob Puff@NLE) Date: Fri Nov 12 03:35:55 2004 Subject: [Mailman-Developers] Mailman with SXIP support, preliminary demo In-Reply-To: <5419014104111118233b500a40@mail.gmail.com> References: <5419014104111118233b500a40@mail.gmail.com> Message-ID: <4194208C.5000205@nleaudio.com> ...and SXIP would be?? Andy Smith wrote: > I posted earlier about my mission to add SXIP support to Mailman, so > this is a follow-up on that now that some code is complete. > > I think I have hit all the areas that needed authentication, although > the options area is notably weak as far as integration goes. > > To use the demo you will need a sxip account on > https://demohomesite.com, it is a pretty painless sign up (and it > ideally will prevent having to do these kinds of sign ups again). > > Demo at: > http://listserva.beta.sxip.org/mailman/sxip/listinfo > > (Anybody who would like an admin account to test out that interface is > welcome to email me so that I can add their email address as an admin > or moderator) > > Everything should be contained under the /mailman/sxip/ path, if it > should fall into /mailman/ I'd appreciate a bug report ;) > > Current code available at: http://an9.org/data/mm_sxip.tar.gz or in > svn at http://an9.org/p/browser/mm_sxip > > Any comments, suggestions (especially those that include code) are > eagerly awaited. > > - Andy Smith > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com > From andyster at gmail.com Fri Nov 12 05:42:10 2004 From: andyster at gmail.com (Andy Smith) Date: Fri Nov 12 05:42:12 2004 Subject: [Mailman-Developers] Mailman with SXIP support, preliminary demo In-Reply-To: <4194208C.5000205@nleaudio.com> References: <5419014104111118233b500a40@mail.gmail.com> <4194208C.5000205@nleaudio.com> Message-ID: <541901410411112042129ca6ec@mail.gmail.com> On Thu, 11 Nov 2004 21:31:40 -0500, Bob Puff@NLE wrote: > ...and SXIP would be?? I wrote about it a bit in my previous email, I figured I would spare you reading it a second time... but... SXIP stands for "Simple eXstenible Identity Protocol" which is a protocol developed by the company I work for, coincidentally named "Sxip Networks" http://sxip.com and https://sxip.org SXIP is, at it's least powerful level, an authentication protocol, however it has the benefits of securely asserting that information is valid, in this case the prime target is a user's email address. So, since we have an email address that has already been validated by another site, we can trust that it is valid (needs no confirmation) and belongs to the user (it can be used as the identifier for admin and mod stuff instead of password). From russ.pagenkopf at uas.alaska.edu Fri Nov 12 07:39:08 2004 From: russ.pagenkopf at uas.alaska.edu (Russ Pagenkopf) Date: Fri Nov 12 07:39:14 2004 Subject: [Mailman-Developers] Offer of help Message-ID: <41945A8C.70304@uas.alaska.edu> Not quite sure where to post this, so I thought I'd send it here. I've just started working with Mailman and when I started to print out the administrator commands with --help I noticed, ummm, a bit of, well, shall we say, inconsistency. :) Now I'm not a python programmer (sigh, another to learn?), but in looking through the files it looks like it would be fairly simple to edit them to a consistent standard. I want to contribute back and this is something I can do. Who and how should I submit these changes? I think a lot of the text descriptions could also be cleaned up and used on the web page, so I'd be happy to do that as well. Russ Pagenkopf From iane at sussex.ac.uk Fri Nov 12 12:10:24 2004 From: iane at sussex.ac.uk (Ian Eiloart) Date: Fri Nov 12 12:10:32 2004 Subject: [Mailman-Developers] Mailman with SXIP support, preliminary demo In-Reply-To: <541901410411112042129ca6ec@mail.gmail.com> References: <5419014104111118233b500a40@mail.gmail.com> <4194208C.5000205@nleaudio.com> <541901410411112042129ca6ec@mail.gmail.com> Message-ID: <23E5D1D266E16A110CB38189@lewes.staff.uscs.susx.ac.uk> --On Thursday, November 11, 2004 20:42:10 GMT -0800 Andy Smith wrote: > On Thu, 11 Nov 2004 21:31:40 -0500, Bob Puff@NLE wrote: >> ...and SXIP would be?? > I wrote about it a bit in my previous email, I figured I would spare > you reading it a second time... but... > > SXIP stands for "Simple eXstenible Identity Protocol" which is a > protocol developed by the company I work for, coincidentally named > "Sxip Networks" http://sxip.com and https://sxip.org So, how is it licensed. On your web site, you refer to an "open source" license, but don't say which version. I can't find a copy of your license. > SXIP is, at it's least powerful level, an authentication protocol, > however it has the benefits of securely asserting that information is > valid, in this case the prime target is a user's email address. So, > since we have an email address that has already been validated by > another site, we can trust that it is valid (needs no confirmation) > and belongs to the user (it can be used as the identifier for admin > and mod stuff instead of password). > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Unsubscribe: > http://mail.python.org/mailman/options/mailman-developers/iane%40sussex.a > c.uk -- Ian Eiloart Servers Team Sussex University ITS From brad at stop.mail-abuse.org Fri Nov 12 11:33:41 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Fri Nov 12 12:37:58 2004 Subject: [Mailman-Developers] Offer of help In-Reply-To: <41945A8C.70304@uas.alaska.edu> References: <41945A8C.70304@uas.alaska.edu> Message-ID: At 9:39 PM -0900 2004-11-11, Russ Pagenkopf wrote: > I want to contribute back and this is something I can do. Who and how > should I submit these changes? Tokio Kikuchi is now in charge of the 2.1-maint branch. He has requested updates for the Danish translations be sent to him in tar format, and I presume he'd want the same for your work. His e-mail address is tkikuchi@is.kochi-u.ac.jp. > I think a lot of the text descriptions > could also be cleaned up and used on the web page, so I'd be happy to > do that as well. That's a different process. To update that stuff requires access to the webserver and using CVS. You'd have to ask Barry about that. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From tkikuchi at is.kochi-u.ac.jp Fri Nov 12 14:24:38 2004 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Fri Nov 12 14:24:49 2004 Subject: [Mailman-Developers] Offer of help In-Reply-To: References: <41945A8C.70304@uas.alaska.edu> Message-ID: <4194B996.30002@is.kochi-u.ac.jp> Hi, Brad Knowles wrote: > At 9:39 PM -0900 2004-11-11, Russ Pagenkopf wrote: > >> I want to contribute back and this is something I can do. Who and how >> should I submit these changes? > > > Tokio Kikuchi is now in charge of the 2.1-maint branch. He has > requested updates for the Danish translations be sent to him in tar > format, and I presume he'd want the same for your work. > > His e-mail address is tkikuchi@is.kochi-u.ac.jp. Well, patches should be uploaded to SourceForge tracker first: http://sourceforge.net/tracker/?group_id=103&atid=300103 In the case of translations, some champions have the privilege of accessing their language area in the CVS. Barry and also most recently I will take care for the others. > >> I think a lot of the text descriptions >> could also be cleaned up and used on the web page, so I'd be happy to >> do that as well. > > > That's a different process. To update that stuff requires access to > the webserver and using CVS. You'd have to ask Barry about that. > -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From terri at zone12.com Fri Nov 12 17:26:00 2004 From: terri at zone12.com (Terri Oda) Date: Fri Nov 12 17:26:09 2004 Subject: [Mailman-Developers] Offer of help In-Reply-To: <41945A8C.70304@uas.alaska.edu> References: <41945A8C.70304@uas.alaska.edu> Message-ID: <8A6106A1-34C7-11D9-9DCD-000D934FBF38@zone12.com> On Nov 12, 2004, at 1:39 AM, Russ Pagenkopf wrote: > Not quite sure where to post this, so I thought I'd send it here. I've > just started working with Mailman and when I started to print out the > administrator commands with --help I noticed, ummm, a bit of, well, > shall we say, inconsistency. :) Now I'm not a python programmer (sigh, > another to learn?), but in looking through the files it looks like it > would be fairly simple to edit them to a consistent standard. > > I want to contribute back and this is something I can do. Who and how > should I submit these changes? I think a lot of the text descriptions > could also be cleaned up and used on the web page, so I'd be happy to > do that as well. I started working on this, but I'd *love* to have someone else do it. If you're bored, you can finish up the man pages I'd been writing for each command. I also started doing the web stuff, but I realise quite a lot of it could use more work. I'm running out the door at the moment, but I'll get in touch with you to let you know exactly what I *have* been doing. And if Tokio doesn't mind, you can deal with me as the documentation person and save him the trouble of fussing over that part of things. I accept patches to documentation if need be. :) Terri From andyster at gmail.com Fri Nov 12 22:11:37 2004 From: andyster at gmail.com (Andy Smith) Date: Fri Nov 12 22:11:40 2004 Subject: [Mailman-Developers] Mailman with SXIP support, preliminary demo In-Reply-To: <23E5D1D266E16A110CB38189@lewes.staff.uscs.susx.ac.uk> References: <5419014104111118233b500a40@mail.gmail.com> <4194208C.5000205@nleaudio.com> <541901410411112042129ca6ec@mail.gmail.com> <23E5D1D266E16A110CB38189@lewes.staff.uscs.susx.ac.uk> Message-ID: <5419014104111213117ef098a2@mail.gmail.com> On Fri, 12 Nov 2004 11:10:24 +0000, Ian Eiloart wrote: > So, how is it licensed. On your web site, you refer to an "open source" > license, but don't say which version. I can't find a copy of your license. > The license may be a tiny bit weird right now because some stuff was still in beta and code hadn't yet been released, but we've got a public svn repository up now (svn://svn.sxip.org/trunk anon/anon) and I believe everything falls under the Apache 1.1 license. I am not a big licensing guy myself, I'm of the mentality that everything should be given freely so who cares about licenses, but we've got a licensing pro on board (Zak Greant, he did a lot of GPL work while trying to fix MySQL's licenses) and I'm confident that the open source community will have no problems with using the software. From tgc at statsbiblioteket.dk Sat Nov 13 20:06:54 2004 From: tgc at statsbiblioteket.dk (Tom G. Christensen) Date: Sat Nov 13 20:06:56 2004 Subject: [Mailman-Developers] New much improved danish translation available In-Reply-To: <1100191718.8606.65.camel@geddy.wooz.org> References: <41932AC0.1010704@statsbiblioteket.dk> <1100191718.8606.65.camel@geddy.wooz.org> Message-ID: <41965B4E.20801@statsbiblioteket.dk> Barry Warsaw wrote: > On Thu, 2004-11-11 at 04:02, Tom G. Christensen wrote: > > >>I've talked to the Danish i18n champion and he agrees that this new >>translation should be committed to CVS and replace what is there now. >>Unfortunately he's not able to do it (no CVS access). >> >>Is there anyone here who can help me? > > > Tokio has offered to update the translation (thanks to you both!). > Should we update the Danish champion information on the i18n.html page? > Sorry about the late reply, the answer is yes. I've talked to S?ren and he'd very much like to get rid of the title. I've setup an address for the purpose: mm-da@statsbiblioteket.dk please use that and not my personal address. You can put my name on it for now and list it as supported. -tgc From iane at sussex.ac.uk Mon Nov 15 11:05:22 2004 From: iane at sussex.ac.uk (Ian Eiloart) Date: Mon Nov 15 11:05:24 2004 Subject: [Mailman-Developers] Mailman with SXIP support, preliminary demo In-Reply-To: <5419014104111213117ef098a2@mail.gmail.com> References: <5419014104111118233b500a40@mail.gmail.com> <4194208C.5000205@nleaudio.com> <541901410411112042129ca6ec@mail.gmail.com> <23E5D1D266E16A110CB38189@lewes.staff.uscs.susx.ac.uk> <5419014104111213117ef098a2@mail.gmail.com> Message-ID: <180CB5378F125EAC476924C7@lewes.staff.uscs.susx.ac.uk> --On Friday, November 12, 2004 13:11:37 GMT -0800 Andy Smith wrote: > On Fri, 12 Nov 2004 11:10:24 +0000, Ian Eiloart wrote: >> So, how is it licensed. On your web site, you refer to an "open source" >> license, but don't say which version. I can't find a copy of your >> license. >> > > The license may be a tiny bit weird right now because some stuff was > still in beta and code hadn't yet been released, but we've got a > public svn repository up now (svn://svn.sxip.org/trunk anon/anon) and > I believe everything falls under the Apache 1.1 license. I am not a > big licensing guy myself, I'm of the mentality that everything should > be given freely so who cares about licenses, but we've got a licensing > pro on board (Zak Greant, he did a lot of GPL work while trying to fix > MySQL's licenses) and I'm confident that the open source community > will have no problems with using the software. Well, its good to hear that your intentions are honourable. The thing about licences is that we don't have to guess about the intentions of your successors, or how your own intentions might change - so its also good that you have someone on board to sort that out. -- Ian Eiloart Servers Team Sussex University ITS From chris at scorpion.nl Mon Nov 15 12:54:59 2004 From: chris at scorpion.nl (Christiaan den Besten) Date: Mon Nov 15 12:55:16 2004 Subject: [Mailman-Developers] Translation not working? Message-ID: <01e601c4cb09$eeef7070$3d64880a@speedy> Hi ! I am using a MailMan (mailman-2.1.5-6.src.rpm) list with the "Dutch" language. Unfortunately, one of the templates is not working 100%. The 'confirm subscription' message is displayed in English and not in Dutch ;( I have pinpointed the correct return value to be present in the translation file (see below). Is there anything I could check / change to debug this ? bye, Chris --- #: Mailman/Cgi/confirm.py:245 #, fuzzy msgid "" "Your confirmation is required in order to complete the\n" " subscription request to the mailing list %(listname)s. Your\n" " subscription settings are shown below; make any necessary changes and " "hit\n" " Subscribe to complete the confirmation process. Once you've\n" " confirmed your subscription request, you will be shown your account\n" " options page which you can use to further customize your membership\n" " options.\n" "\n" "

Note: your password will be emailed to you once your subscription is\n" " confirmed. You can change it by visiting your personal options page.\n" "\n" "

Or hit Cancel my subscription request if you no longer want " "to\n" " subscribe to this list." msgstr "" "Uw bevestiging is vereist om uw aanmeldingsverzoek voor de maillijst\n" " %(listname)s te voltooien. Uw lidmaatschapsinstellingen\n" " zijn hieronder weergegeven. Indien nodig kunt u deze gegevens wijzigen\n" " en op Aanmelden klikken om verder te gaan. Nadat u uw\n" " aanmeldingsverzoek heeft bevestigd komt u op uw lidmaatmaatschaps-\n" " instellingenpagina die u kunt gebruiken om uw lidmaatschap verder aan " "uw\n" " wensen aan te passen.\n" "\n" "

Opmerking: uw wachtwoord zal naar u worden verstuurd via e-mial " "nadat\n" " uw lidmaatschap is bevestigd. U kunt het wachtwoord veranderen als u " "uw\n" " lidmaatschapsinstellingenpagina bezoekt.\n" "\n" "

Of klik op Annuleren om dit aanmeldingsverzoek af te breken." --- From tkikuchi at is.kochi-u.ac.jp Mon Nov 15 13:48:56 2004 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Mon Nov 15 13:49:09 2004 Subject: [Mailman-Developers] Translation not working? In-Reply-To: <01e601c4cb09$eeef7070$3d64880a@speedy> References: <01e601c4cb09$eeef7070$3d64880a@speedy> Message-ID: <4198A5B8.6090103@is.kochi-u.ac.jp> Christiaan den Besten wrote: > Hi ! > > I am using a MailMan (mailman-2.1.5-6.src.rpm) list with the "Dutch" > language. Unfortunately, one of the templates is not working 100%. The > 'confirm subscription' message is displayed in English and not in Dutch ;( > > I have pinpointed the correct return value to be present in the translation > file (see below). Is there anything I could check / change to debug this ? According to the mailman i18n page http://www.list.org/i18n.html, the Dutch language champion is Danny Terweij (danny@terweij.nl). Please send your patch to him and he will be able to correct the translation in the SourceForge CVS. You can also fix YOUR installation by editing the .po file and generating the .mo file by msgfmt. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From chris at scorpion.nl Mon Nov 15 14:00:11 2004 From: chris at scorpion.nl (Christiaan den Besten) Date: Mon Nov 15 14:00:28 2004 Subject: [Mailman-Developers] Translation not working? References: <01e601c4cb09$eeef7070$3d64880a@speedy> <4198A5B8.6090103@is.kochi-u.ac.jp> Message-ID: <028d01c4cb13$0a89d9c0$3d64880a@speedy> Well, I have already send him some emails asking the same thing, but no reply :( Actually, the translation is there ... it just doesn't show up in the "confirm subscription" page. Is there anyway I can check if the .po/.mo file is ok? bye, Chris ----- Original Message ----- From: "Tokio Kikuchi" To: "Christiaan den Besten" Cc: ; "mailman-i18n" Sent: Monday, November 15, 2004 1:48 PM Subject: Re: [Mailman-Developers] Translation not working? > Christiaan den Besten wrote: > >> Hi ! >> >> I am using a MailMan (mailman-2.1.5-6.src.rpm) list with the "Dutch" >> language. Unfortunately, one of the templates is not working 100%. The >> 'confirm subscription' message is displayed in English and not in Dutch >> ;( >> >> I have pinpointed the correct return value to be present in the >> translation >> file (see below). Is there anything I could check / change to debug this >> ? > > According to the mailman i18n page http://www.list.org/i18n.html, the > Dutch language champion is Danny Terweij (danny@terweij.nl). Please send > your patch to him and he will be able to correct the translation in the > SourceForge CVS. > > You can also fix YOUR installation by editing the .po file and generating > the .mo file by msgfmt. > > > -- > Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp > http://weather.is.kochi-u.ac.jp/ > > > From grnbrg at gmail.com Mon Nov 15 17:05:23 2004 From: grnbrg at gmail.com (Brian Greenberg) Date: Mon Nov 15 17:05:28 2004 Subject: [Mailman-Developers] Translation not working? In-Reply-To: <2f30f34504111508045d0ad17f@mail.gmail.com> References: <01e601c4cb09$eeef7070$3d64880a@speedy> <4198A5B8.6090103@is.kochi-u.ac.jp> <028d01c4cb13$0a89d9c0$3d64880a@speedy> <2f30f34504111508045d0ad17f@mail.gmail.com> Message-ID: <2f30f34504111508054eafff46@mail.gmail.com> On Mon, 15 Nov 2004 14:00:11 +0100, Christiaan den Besten wrote: > Well, > > I have already send him some emails asking the same thing, but no reply :( > > Actually, the translation is there ... it just doesn't show up in the > "confirm subscription" page. Is there anyway I can check if the .po/.mo file > is ok? I've found that the install does not seem to copy over all of the *.mo files. After the make install completes, I do: cd $BUILD_TREE for MAILMAN_MO in $( ls messages/*/LC_MESSAGES/mailman.mo ) do cp $BUILD_TREE/$MAILMAN_MO /usr/local/mailman/$MAILMAN_MO done This seems to fix the problem. Brian. -- Brian Greenberg grnbrg@gmail.com From chris at scorpion.nl Mon Nov 15 17:44:48 2004 From: chris at scorpion.nl (Christiaan den Besten) Date: Mon Nov 15 17:45:33 2004 Subject: [Mailman-Developers] Translation not working? References: <01e601c4cb09$eeef7070$3d64880a@speedy><4198A5B8.6090103@is.kochi-u.ac.jp><028d01c4cb13$0a89d9c0$3d64880a@speedy><2f30f34504111508045d0ad17f@mail.gmail.com> <2f30f34504111508054eafff46@mail.gmail.com> Message-ID: <043701c4cb32$6b799530$3d64880a@speedy> Hi ! I have just confirmed that I have a correct .po and .mo file. Furthermore I have regenerated the .mo file with msgfmt. After further investigation I now see that the text displayed to the user is the one in "Mailman/Cgi/confirm.py". It is defined in the function "subscription_prompt". I am not yet sure how the whole language translation stuff works, so I cannot yet see if it calls a 'label' or if it is supposed to be static text. Any of the confirm.py developers on the list :) See http://lists.wooninvest.nl/mailman/confirm/woningen/9f22402869c91c0781e0af3182f9751f2ef5d0b8 as an example. The text you can't understand is Dutch :) bye, Chris ----- Original Message ----- From: "Brian Greenberg" To: Sent: Monday, November 15, 2004 5:05 PM Subject: [Mailman-Developers] Translation not working? > On Mon, 15 Nov 2004 14:00:11 +0100, Christiaan den Besten > wrote: >> Well, >> >> I have already send him some emails asking the same thing, but no reply >> :( >> >> Actually, the translation is there ... it just doesn't show up in the >> "confirm subscription" page. Is there anyway I can check if the .po/.mo >> file >> is ok? > > I've found that the install does not seem to copy over all of the *.mo > files. After the make install completes, I do: > > cd $BUILD_TREE > for MAILMAN_MO in $( ls messages/*/LC_MESSAGES/mailman.mo ) > do > > cp $BUILD_TREE/$MAILMAN_MO /usr/local/mailman/$MAILMAN_MO > > done > > This seems to fix the problem. > > Brian. > -- > Brian Greenberg > grnbrg@gmail.com > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Unsubscribe: > http://mail.python.org/mailman/options/mailman-developers/chris%40scorpion.nl > > From terri at zone12.com Mon Nov 15 18:12:12 2004 From: terri at zone12.com (Terri Oda) Date: Mon Nov 15 18:12:10 2004 Subject: [Mailman-Developers] Offer of help In-Reply-To: <41945A8C.70304@uas.alaska.edu> References: <41945A8C.70304@uas.alaska.edu> Message-ID: <7DAD3CB1-3729-11D9-AB76-000D934FBF38@zone12.com> On Nov 12, 2004, at 1:39 AM, Russ Pagenkopf wrote: > Not quite sure where to post this, so I thought I'd send it here. I've > just started working with Mailman and when I started to print out the > administrator commands with --help I noticed, ummm, a bit of, well, > shall we say, inconsistency. :) Now I'm not a python programmer (sigh, > another to learn?), but in looking through the files it looks like it > would be fairly simple to edit them to a consistent standard. > I want to contribute back and this is something I can do. Who and how > should I submit these changes? I think a lot of the text descriptions > could also be cleaned up and used on the web page, so I'd be happy to > do that as well. Okey dokey. Sorry I didn't get right back to you. So I would *love* it if you did revisions on the --help for the commands. I don't know if you were planning on changing any code or just the --help output, but do be super-careful about changing any of the actual functionality -- basically, we'd prefer not to change the way anything works so upgrades don't break people's automated scripts, but if you add additional syntaxes for the same thing, that's okay. I've been working on man pages, and the lack of consistency was getting on my nerves, but I hadn't had time to go through and do anything about it. If you've got more time once you've got the --help documentation made consistent, I'd really love it if you could update/create man pages for the commands in bin/. I'm pretty sure you'll need to alter some of the ones I have to be more consistent when you alter the commands. If you check out CVS, the man pages are all in doc/man, and it should be fairly obvious how they're formatted. I'm not a big expert on writing man pages, so if you get into it and find a better way to format them, don't feel you have to stick with my work. My eventual plan for the man pages is to convert these to HTML for the website as well as bundling them with a future release of 2.1. That way, I only have to update the man pages and regenerate the HTML rather than handling them separately. (Although if you want to start writing the site admin manual, which would include descriptions of these commands...) If this is too much work, do feel free to do whatever you're able to do and I'll try to make things match. :) And thank you *so* much for offering. You're right and it really should be done, and I think it's one of those little things that can make those scripts more pleasant to use. Terri From tkikuchi at is.kochi-u.ac.jp Tue Nov 16 00:59:45 2004 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue Nov 16 00:59:56 2004 Subject: [Mailman-Developers] Translation not working? In-Reply-To: <01e601c4cb09$eeef7070$3d64880a@speedy> References: <01e601c4cb09$eeef7070$3d64880a@speedy> Message-ID: <419942F1.8000409@is.kochi-u.ac.jp> One point to make clear. Christiaan den Besten wrote: > > --- > #: Mailman/Cgi/confirm.py:245 > #, fuzzy ^^^^^^^^^^ > msgid "" > "Your confirmation is required in order to complete the\n" You have to remove '#, fuzzy' line once you have completed your translation because msgfmt won't compile this item into .mo file. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From tkikuchi at is.kochi-u.ac.jp Tue Nov 16 01:06:43 2004 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue Nov 16 01:06:52 2004 Subject: [Mailman-Developers] Translation not working? In-Reply-To: <2f30f34504111508054eafff46@mail.gmail.com> References: <01e601c4cb09$eeef7070$3d64880a@speedy> <4198A5B8.6090103@is.kochi-u.ac.jp> <028d01c4cb13$0a89d9c0$3d64880a@speedy> <2f30f34504111508045d0ad17f@mail.gmail.com> <2f30f34504111508054eafff46@mail.gmail.com> Message-ID: <41994493.1060706@is.kochi-u.ac.jp> > I've found that the install does not seem to copy over all of the *.mo > files. After the make install completes, I do: (snip) There was a bug in the Makefile when install-sh script was used in installing the message directory, especially on Solaris. This was fixed in the SourceForge CVS Release_2_1-maint. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From chris at scorpion.nl Tue Nov 16 01:56:10 2004 From: chris at scorpion.nl (Christiaan den Besten) Date: Tue Nov 16 01:56:26 2004 Subject: [Mailman-Developers] Translation not working? References: <01e601c4cb09$eeef7070$3d64880a@speedy> <419942F1.8000409@is.kochi-u.ac.jp> Message-ID: <05f101c4cb77$102e8f10$3d64880a@speedy> > One point to make clear. > > Christiaan den Besten wrote: > >> >> --- >> #: Mailman/Cgi/confirm.py:245 >> #, fuzzy > ^^^^^^^^^^ >> msgid "" >> "Your confirmation is required in order to complete the\n" > > You have to remove '#, fuzzy' line once you have completed your > translation because msgfmt won't compile this item into .mo file. Great, done that .. works like a charm ! Thank you. Now ehm ... just one more thing I just noticed. If somebody chooses the "I do not want to subscribe, remove my request" button (the left one) I get this: --- Bug in Mailman version 2.1.5 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 "/var/mailman/scripts/driver", line 87, in run_main main() File "/var/mailman/Mailman/Cgi/confirm.py", line 114, in main subscription_cancel(mlist, doc, cookie) File "/var/mailman/Mailman/Cgi/confirm.py", line 312, in subscription_cancel userdesc = mlist.pend_confirm(cookie)[1] File "/var/mailman/Mailman/Pending.py", line 141, in pend_confirm assert self.Locked() AssertionError Python information: VariableValue sys.version2.2.3 (#1, Oct 15 2003, 23:33:35) [GCC 3.3.1 20030930 (Red Hat Linux 3.3.1-6)] sys.executable/usr/bin/python sys.prefix/usr sys.exec_prefix/usr sys.path/usr sys.platformlinux2 Environment variables: VariableValue PATH_INFO /woningen CONTENT_LENGTH 115 CONTENT_TYPE application/x-www-form-urlencoded HTTP_REFERER http://lists.wooninvest.nl/mailman/confirm/woningen/851ebe8085456d9ba0cb0bdfada7d1303c4bdecf SCRIPT_FILENAME /var/mailman/cgi-bin/confirm PYTHONPATH /var/mailman SERVER_SOFTWARE Apache SERVER_ADMIN webmaster@prolocation.net SCRIPT_NAME /mailman/confirm SERVER_SIGNATURE REQUEST_METHOD POST HTTP_HOST lists.wooninvest.nl HTTP_KEEP_ALIVE 300 SERVER_PROTOCOL HTTP/1.1 QUERY_STRING PATH_TRANSLATED /var/www/html/wooninvest/woningen REQUEST_URI /mailman/confirm/woningen HTTP_ACCEPT text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 HTTP_ACCEPT_CHARSET ISO-8859-1,utf-8;q=0.7,*;q=0.7 HTTP_USER_AGENT Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 HTTP_CONNECTION keep-alive SERVER_NAME lists.wooninvest.nl REMOTE_ADDR 84.35.71.36 REMOTE_PORT 3572 HTTP_ACCEPT_LANGUAGE en-us,en;q=0.5 UNIQUE_ID lDwzclEX5gcAAB5vytQAAAAJ SERVER_PORT 80 GATEWAY_INTERFACE CGI/1.1 HTTP_ACCEPT_ENCODING gzip,deflate SERVER_ADDR 81.23.230.7 DOCUMENT_ROOT /var/www/html/wooninvest --- bye, Chris From jwt at OnJapan.net Tue Nov 16 02:03:19 2004 From: jwt at OnJapan.net (Jim Tittsler) Date: Tue Nov 16 02:01:31 2004 Subject: [Mailman-Developers] Translation not working? In-Reply-To: <05f101c4cb77$102e8f10$3d64880a@speedy> References: <01e601c4cb09$eeef7070$3d64880a@speedy> <419942F1.8000409@is.kochi-u.ac.jp> <05f101c4cb77$102e8f10$3d64880a@speedy> Message-ID: <20041116010319.GA13806@server.onjapan.net> On Tue, Nov 16, 2004 at 01:56:10AM +0100, Christiaan den Besten wrote: > Now ehm ... just one more thing I just noticed. If somebody chooses the "I > do not want to subscribe, remove my request" button (the left one) I get > this: This is a known bug in 2.1.5. It should be fixed in CVS, or apply this: -- Jim Tittsler http://www.OnJapan.net/ GPG: 0x01159DB6 Python Starship http://Starship.Python.net/ Ringo MUG Tokyo http://www.ringo.net/rss.html From chris at scorpion.nl Tue Nov 16 02:21:44 2004 From: chris at scorpion.nl (Christiaan den Besten) Date: Tue Nov 16 02:22:02 2004 Subject: [Mailman-Developers] Translation not working? References: <01e601c4cb09$eeef7070$3d64880a@speedy> <419942F1.8000409@is.kochi-u.ac.jp> <05f101c4cb77$102e8f10$3d64880a@speedy> <20041116010319.GA13806@server.onjapan.net> Message-ID: <064201c4cb7a$a235a5d0$3d64880a@speedy> Thanks, that fixed the problem. bye, Chris ----- Original Message ----- From: "Jim Tittsler" To: "Christiaan den Besten" Cc: Sent: Tuesday, November 16, 2004 2:03 AM Subject: Re: [Mailman-Developers] Translation not working? > On Tue, Nov 16, 2004 at 01:56:10AM +0100, Christiaan den Besten wrote: >> Now ehm ... just one more thing I just noticed. If somebody chooses the >> "I >> do not want to subscribe, remove my request" button (the left one) I get >> this: > > This is a known bug in 2.1.5. It should be fixed in CVS, or > apply this: > > > -- > Jim Tittsler http://www.OnJapan.net/ GPG: 0x01159DB6 > Python Starship http://Starship.Python.net/ > Ringo MUG Tokyo http://www.ringo.net/rss.html > > > From scrib at afn.org Sat Nov 20 09:31:38 2004 From: scrib at afn.org (Steven Kuck) Date: Sat Nov 20 09:31:46 2004 Subject: [Mailman-Developers] Dates again Message-ID: <419F00EA.7010207@afn.org> I see this topic has been discussed years ago, but I recently started running some MailMan lists and this problem came up almost as soon as I started running it. (Version 2.1.5) Users WILL NOT set their clocks to some nicely synchronized time. This is especially true since many of my subscribers are computer neophytes. When sorted by date, some replies come before the original posting. The worst offender is actually a highly competent computer user who claims to have a defective clock in his laptop that produces messages from the year 2080. (The truth of his claim is immaterial.) In an ideal world, these things would never happen. This is not an ideal world. There was a discussion about "not munging" the headers as a validation for objecting to altering the "Date" header. Considering the actions of "CookHeaders.py" and other files that variously alter the "Reply To" header, delete unwanted headers, and obviously alter the "Subject" line, these objections seem weak, if not ironic. The date set by the senders computer is not sacrosanct. While it may have some "meaning," it is of no "use." Also, if the date isn't set properly, it probably isn't even important to the sender. Since all of these messages are, in fact, being sent by my server I think it quite reasonable to change the "Date" to reflect the time that it was processed and changed by the server. I'm the one who has to answer questions about why the archive dates seem wrong and who is ultimately responsible for the smooth operation of the service. I would LIKE this to be an option that I could set. I do not have the time or inclination to write the code to make this a user option. However, since it something I wanted applied to all of my lists, I added the code to copy the "Date" field to "X-Original-Date" and put in the server's time as the "Date." Suddenly, my new archives are coherent. I don't have to worry about aberrant or obnoxious users. I only added six lines of code (and two imports) to "CookHeaders.py" to make this work. PLEASE tell me I wasted my time and there is a simple option I can set! Tell me that I don't have to port this code when I want to upgrade! I don't speak Python, and I know I imported more than necessary, but it seems to work. I'm including the code changes both to share what I found to be Very Useful and to have others sanity-check my code. As I said, I never wrote a line of Python before this. Steven Kuck PS I considered sending this message from the year 2080 as I've had to deal with, but I thought I'd give you a chance to implement this patch first. PPS No, I don't WANT there to be a "fuzzfactor" allowing "close enough" dates. Server Time Only. # SKuck Header additions to CookHeaders.py of Mailman 2.1.5 - Nov 18, 2004 import time from email.Utils import parsedate_tz, mktime_tz, formatdate # End SKuck Header additions ... msg['List-Id'] = listid_h # The above included as an insertion location reference. I think it'll work from anywhere in "def process" # SKuck added to pounce on bad email time stamps. originaldate = msg.get('date') receivedtime = formatdate(time.time()) del msg['date'] del msg['x-original-date'] msg['Date'] = receivedtime msg['X-Original-Date'] = originaldate # End SKuck added ... From jwt at OnJapan.net Sat Nov 20 10:04:31 2004 From: jwt at OnJapan.net (Jim Tittsler) Date: Sat Nov 20 10:02:36 2004 Subject: [Mailman-Developers] Dates again In-Reply-To: <419F00EA.7010207@afn.org> References: <419F00EA.7010207@afn.org> Message-ID: <20041120090431.GA11151@server.onjapan.net> On Sat, Nov 20, 2004 at 03:31:38AM -0500, Steven Kuck wrote: > Suddenly, my new archives are coherent. I don't have to worry about To keep your archives coherent, you can just set: ARCHIVER_CLOBBER_DATE_POLICY = 1 in your mm_cfg.py. > my time and there is a simple option I can set! Tell me that I don't > have to port this code when I want to upgrade! Rather than patching CookHeaders, you might consider making your own handler that only mungs the date, and then add that handler to the global pipeline in your mm_cfg. Then a new version of CookHeaders.py is not a problem. -- Jim Tittsler http://www.OnJapan.net/ GPG: 0x01159DB6 Python Starship http://Starship.Python.net/ Ringo MUG Tokyo http://www.ringo.net/rss.html From brad at stop.mail-abuse.org Sat Nov 20 10:42:24 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Sat Nov 20 11:13:05 2004 Subject: [Mailman-Developers] Dates again In-Reply-To: <419F00EA.7010207@afn.org> References: <419F00EA.7010207@afn.org> Message-ID: At 3:31 AM -0500 2004-11-20, Steven Kuck wrote: > Since all of these messages are, in fact, being sent by my server I think > it quite reasonable to change the "Date" to reflect the time that it was > processed and changed by the server. The problem is that you can't tell which "Date:" headers are good and which ones aren't. The message may have been held up in a queue for several days, or the date it was sent could be off by several days. By the time the message gets to you, it is impossible to distinguish between these two events. IMO, you should adhere to the principle of minimal munging, and not replace a "Date:" header unless you can pretty conclusively prove that it was set wrong to begin with. > I'm the one who has to answer > questions about why the archive dates seem wrong and who is ultimately > responsible for the smooth operation of the service. I would LIKE this > to be an option that I could set. I do not have the time or inclination > to write the code to make this a user option. However, since it something > I wanted applied to all of my lists, I added the code to copy the "Date" > field to "X-Original-Date" and put in the server's time as the "Date." I would be violently opposed to any system-wide modification that would arbitrarily replace all "Date:" headers with ones based on the time of reception. If there were a way to effectively detect when a "Date:" header was wrong and when it was okay, then I might be willing to allow the system to correct the "Date:" header in those particular cases. If you've got a patch or additional code that can do that, I'd like to see it, although I can't promise it would be accepted by the Mailman developers for inclusion in an upcoming version. > PS I considered sending this message from the year 2080 as I've had to > deal with, but I thought I'd give you a chance to implement this patch first. We've all had the problem. > PPS No, I don't WANT there to be a "fuzzfactor" allowing "close enough" > dates. Server Time Only. I can't speak for Barry, Tokio, or the other Mailman developers, but I would be violently opposed to a change of this sort. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From scrib at afn.org Sat Nov 20 12:22:12 2004 From: scrib at afn.org (Steven Kuck) Date: Sat Nov 20 12:22:20 2004 Subject: [Mailman-Developers] Dates again In-Reply-To: References: <419F00EA.7010207@afn.org> Message-ID: <419F28E4.1000309@afn.org> Brad Knowles wrote: > At 3:31 AM -0500 2004-11-20, Steven Kuck wrote: > >> Since all of these messages are, in fact, being sent by my server I >> think >> it quite reasonable to change the "Date" to reflect the time that it >> was >> processed and changed by the server. > > The problem is that you can't tell which "Date:" headers are good > and which ones aren't. The message may have been held up in a queue > for several days, or the date it was sent could be off by several > days. By the time the message gets to you, it is impossible to > distinguish between these two events. I feel as though I've suggested making burgers from a sacred cow... I would like to figure out why it is sacred, so pardon my sacrilegious question: why does it matter? Please, no flames... Can you point me to the definitive text for mail header definitions? RFC 733 only defines the format - it doesn't say they are any more inviolate than the "Subject" line. True, you can't tell if a message was sent from a misbehaving computer or if it got stuck in the queue of a misbehaving server. Surely, any dates in the future would be fair game for alteration - they can't have been "stuck" there since NEXT week. I'd also be suspect of any dates before 1970. Frankly, I'd be suspect of any date older than a three days (over a weekend). I still think that the time on the originating computer (assuming the sender isn't inserting false dates) is a matter for trivia, and archival in a "X-Sender-Universal-Disjointed-Time" field. Why do I care if the message was stuck (unless it's my server) or if the user's clock is wrong? > IMO, you should adhere to the principle of minimal munging, and > not replace a "Date:" header unless you can pretty conclusively prove > that it was set wrong to begin with. Come now, it's not like I'm adding content to the body of the message! Oh wait, mailman does that too. > I would be violently opposed to any system-wide modification that > would arbitrarily replace all "Date:" headers with ones based on the > time of reception. As I said, I can guarantee messages from the future are wrong. Disagree? Perhaps messages from more than a day (or N days) in the past could be bounced saying: "Either your system clock is wrong or your message was unreasonably delayed. Either fix your clock, or make sure your message is still current and send it again." Alternately, the message could be held for approval or date fixing, and you could set that user as "Date Impaired" so that all messages from that individual get fixed - if they're off. > >> PS I considered sending this message from the year 2080 as I've had to >> deal with, but I thought I'd give you a chance to implement this >> patch first. > > We've all had the problem. At least you recognize it as a "problem." I would be more than happy to work on a reasonable, if not totally infallible "solution." I know as a current solution we tolerate a message archive on this list from 2006. If date > now, replace. Can we at least get that in there? I'll worry about messages from 1989 or earlier on my own. Steven Kuck - no need for "violent opposition" - I'll behave. From barry at python.org Sat Nov 20 18:30:41 2004 From: barry at python.org (Barry Warsaw) Date: Sat Nov 20 18:30:43 2004 Subject: [Mailman-Developers] Dates again In-Reply-To: <20041120090431.GA11151@server.onjapan.net> References: <419F00EA.7010207@afn.org> <20041120090431.GA11151@server.onjapan.net> Message-ID: <1100971840.8199.3.camel@presto.wooz.org> On Sat, 2004-11-20 at 04:04, Jim Tittsler wrote: > On Sat, Nov 20, 2004 at 03:31:38AM -0500, Steven Kuck wrote: > > Suddenly, my new archives are coherent. I don't have to worry about > > To keep your archives coherent, you can just set: > ARCHIVER_CLOBBER_DATE_POLICY = 1 > in your mm_cfg.py. Right, and if Steven really wants server time to always override, you can set ARCHIVE_CLOBBER_DATE_POLICY = 2 and ARCHIVER_ALLOWABLE_SANE_DATE_SKEW to some really small value (minutes(5) or even 0). -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041120/93a95f04/attachment.pgp From shiva at sewingwitch.com Sat Nov 20 22:26:12 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sat Nov 20 22:26:25 2004 Subject: [Mailman-Developers] Dates again In-Reply-To: <419F28E4.1000309@afn.org> References: <419F00EA.7010207@afn.org> <419F28E4.1000309@afn.org> Message-ID: <85BEEC8C423D47B6F2297644@[10.0.0.4]> --On Saturday, November 20, 2004 6:22 AM -0500 Steven Kuck wrote: > As I said, I can guarantee messages from the future are wrong. Disagree? > > Perhaps messages from more than a day (or N days) in the past could be > bounced saying: > "Either your system clock is wrong or your message was unreasonably > delayed. Either fix your clock, or make sure your message is still > current and send it again." > Alternately, the message could be held for approval or date fixing, and > you could set that user as "Date Impaired" so that all messages from that > individual get fixed - if they're off. This seems a reasonable approach, given a configurable delivery delay tolerance. One could also cross-check References headers against messages already received, to set a lower limit on the time stamp. If a message claims to have been sent prior to one it references (modulo some tolerance), then it can be bounced/modified/moderated. From jwblist at olympus.net Sat Nov 20 22:55:31 2004 From: jwblist at olympus.net (John W. Baxter) Date: Sat Nov 20 22:55:44 2004 Subject: [Mailman-Developers] Dates again In-Reply-To: <85BEEC8C423D47B6F2297644@[10.0.0.4]> Message-ID: On 11/20/2004 13:26, "Kenneth Porter" wrote: > --On Saturday, November 20, 2004 6:22 AM -0500 Steven Kuck > wrote: > >> As I said, I can guarantee messages from the future are wrong. Disagree? >> >> Perhaps messages from more than a day (or N days) in the past could be >> bounced saying: >> "Either your system clock is wrong or your message was unreasonably >> delayed. Either fix your clock, or make sure your message is still >> current and send it again." >> Alternately, the message could be held for approval or date fixing, and >> you could set that user as "Date Impaired" so that all messages from that >> individual get fixed - if they're off. > > This seems a reasonable approach, given a configurable delivery delay > tolerance. One could also cross-check References headers against messages > already received, to set a lower limit on the time stamp. If a message > claims to have been sent prior to one it references (modulo some > tolerance), then it can be bounced/modified/moderated. Keep in mind that there are MUAs which set the Date: as the message is begun, not when it is sent. If the sender leaves it as a draft for a couple of days before sending, the Date: will be "two days old". (What one wants to do with that date is another matter.) --John From brad at stop.mail-abuse.org Sun Nov 21 01:53:50 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Sun Nov 21 02:43:52 2004 Subject: [Mailman-Developers] Dates again In-Reply-To: <419F28E4.1000309@afn.org> References: <419F00EA.7010207@afn.org> <419F28E4.1000309@afn.org> Message-ID: At 6:22 AM -0500 2004-11-20, Steven Kuck wrote: > I feel as though I've suggested making burgers from a sacred cow... I > would like to figure out why it is sacred, so pardon my sacrilegious > question: why does it matter? Please, no flames... Riiiiiiiiiiiiiiiiiiiiiiiight. You feel free to include all your own inflamatory comments before the question, and then insist that this can't lead to a flame war. This is not a good start. > Can you point me to > the definitive text for mail header definitions? RFC 733 only defines > the format - it doesn't say they are any more inviolate than the > "Subject" line. I believe that the current RFC on this matter is 2822, see . The last paragraph of Section 3.6 says: | The only required header fields are the origination date field and | the originator address field(s). All other header fields are | syntactically optional. More information is contained in the table | following this definition. This implies to me that the "Date:" header is one of the two most important headers on the entire message. Keep that in mind. Section 3.6.1 says: |3.6.1. The origination date field | | The origination date field consists of the field name "Date" followed | by a date-time specification. | |orig-date = "Date:" date-time CRLF | | The origination date specifies the date and time at which the creator | of the message indicated that the message was complete and ready to | enter the mail delivery system. For instance, this might be the time | that a user pushes the "send" or "submit" button in an application | program. In any case, it is specifically not intended to convey the | time that the message is actually transported, but rather the time at | which the human or other creator of the message has put the message | into its final form, ready for transport. (For example, a portable | computer user who is not connected to a network might queue a message | for delivery. The origination date is intended to contain the date | and time that the user queued the message, not the time when the user | connected to the network to send the message.) There's nothing here that says that an MTA should, or can, correct a "Date:" header that it believes to be incorrect. There's nothing here that says an application can or should correct a "Date:" header that it believes to be incorrect. You should also read section 3.6.6, and note that it is not applicable since "Resent-" fields are for when a user has re-introduced a message into the transport system, and this is not what we are doing. Moreover, the "Resent-" fields are purely informational, and do not over-ride the original fields in the message in any way. For my part, all this means that the "Date:" header is even more inviolable than the "Reply-to:" header, which is a very old flamewar. See . As for the rest of your message, I consider it to be sufficiently inflamatory that I will not attempt to respond. You seem to have a clear agenda here, and there is nothing that will deter you from this path. If you wish to modify your system to function the way you want, there's not really much that any of us can do to try to change your mind. However, if you do actually want to try to benefit the rest of the Mailman community, or at least to avoid having to keep re-porting your change to every new version of Mailman, you're going to have to make some concessions to the patch you are proposing. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From gward at python.net Sun Nov 21 20:10:00 2004 From: gward at python.net (Greg Ward) Date: Sun Nov 21 20:10:03 2004 Subject: [Mailman-Developers] Re: Two problems upgrading from 2.1.4 to 2.1.5 In-Reply-To: <20041121183426.GA1249@cthulhu.gerg.ca> References: <20041121183426.GA1249@cthulhu.gerg.ca> Message-ID: <20041121191000.GA1327@cthulhu.gerg.ca> [moving thread to mailman-developers, since I think I found a bug -- and sorry for the huge quote, but I think the change of audience requires it] On 21 November 2004, I said: > I'm trying to upgrade from Mailman 2.1.4 to 2.1.5 on a Debian "testing" > system, using "apt-get install mailman". The upgrade seems to be > falling down in two places at various times. First variation: > > """ > # apt-get install mailman > Reading Package Lists... Done > Building Dependency Tree... Done > mailman is already the newest version. > 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded. > 1 not fully installed or removed. > Need to get 0B of archives. > After unpacking 0B of additional disk space will be used. > Setting up mailman (2.1.5-3) ... > Looking for enabled languages (this may take some time) ... done. > Installing site language de ................................ done. > Installing site language en ............................................ done. > Upgrading from version 0x20103f0 to 0x20105f0 > getting rid of old source files > Updating mailing list: mailman > Updating the held requests database. > - updating old private mbox file > Your installation seems up-to-date, great! > - updating old public mbox file > Fixing language templates: mailman > > Updating mailing list: crew > Resetting 2 BYBOUNCEs disabled addrs with no bounce info > Traceback (most recent call last): > File "/usr/lib/mailman/bin/update", line 753, in ? > errors = main() > File "/usr/lib/mailman/bin/update", line 643, in main > errors = errors + dolist(listname) > File "/usr/lib/mailman/bin/update", line 218, in dolist > mlist.setDeliveryStatus(addr, ENABLED) > File "/var/lib/mailman/Mailman/OldStyleMemberships.py", line 338, in setDeliveryStatus > self.__assertIsMember(member) > File "/var/lib/mailman/Mailman/OldStyleMemberships.py", line 113, in __assertIsMember > raise Errors.NotAMemberError, member > Mailman.Errors.NotAMemberError: timehorse,timehorse@unforgettable.com > dpkg: error processing mailman (--configure): > subprocess post-installation script returned error exit status 1 > Errors were encountered while processing: > mailman > E: Sub-process /usr/bin/dpkg returned an error code (1) > """ > > When I saw this, I shrugged, figured I'd look in more detail later, and > just tried again. This time it's getting bogged down in the middle of > updating the pending.pck file: > > """ > # apt-get install mailman > Reading Package Lists... Done > Building Dependency Tree... Done > mailman is already the newest version. > 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded. > 1 not fully installed or removed. > Need to get 0B of archives. > After unpacking 0B of additional disk space will be used. > Setting up mailman (2.1.5-3) ... > Looking for enabled languages (this may take some time) ... done. > Installing site language de ................................ done. > Installing site language en ............................................ done. > Upgrading from version 0x20103f0 to 0x20105f0 > getting rid of old source files > Updating mailing list: mailman > [...] > Updating Usenet watermarks > - nothing to update here > Updating Mailman 2.1.4 pending.pck database > """ > > The [...] went by quite quickly. After printing the last line, 'update' > just sits there. Interrupting it gives a useful traceback: > > Traceback (most recent call last): > File "/usr/lib/mailman/bin/update", line 753, in ? > errors = main() > File "/usr/lib/mailman/bin/update", line 677, in main > update_pending() > File "/usr/lib/mailman/bin/update", line 572, in update_pending > mlist = MailList.MailList(listname) > File "/var/lib/mailman/Mailman/MailList.py", line 126, in __init__ > self.Lock() > File "/var/lib/mailman/Mailman/MailList.py", line 159, in Lock > self.__lock.lock(timeout) > File "/var/lib/mailman/Mailman/LockFile.py", line 312, in lock > self.__sleep() > File "/var/lib/mailman/Mailman/LockFile.py", line 496, in __sleep > time.sleep(interval) > KeyboardInterrupt > > Hmmmm... so it looks like it's trying to get the lock on a list. Not > sure which one, but here's a clue: OK, it looks like this is what happened: * the first failure (NotAMemberError) crashed update, and it did not clean up its locks * so when I ran update again, it hung trying to lock the list that it crashed on the last time through Looking at the loop of setDeliveryStatus() calls in dolist() (see around lines 215-220 in bin/update), it's pretty obvious how an exception from setDeliveryStatus() can cause havoc. One naive fix is to catch MemberError from setDeliveryStatus(): --- update 2004-11-01 11:22:53.000000000 +0100 +++ update.hacked 2004-11-21 20:08:21.000000000 +0100 @@ -51,6 +51,7 @@ from Mailman import MailList from Mailman import Message from Mailman import Pending +from Mailman import Errors from Mailman.LockFile import TimeOutError from Mailman.i18n import _ from Mailman.Queue.Switchboard import Switchboard @@ -215,7 +216,11 @@ print _( 'Resetting %(n)s BYBOUNCEs disabled addrs with no bounce info') for addr in noinfo.keys(): - mlist.setDeliveryStatus(addr, ENABLED) + try: + mlist.setDeliveryStatus(addr, ENABLED) + except Errors.MemberError, err: + print "ERROR setting delivery status" + print repr(err) # Update the held requests database print _("""Updating the held requests database.""") (patch relative to bin/update from a Debian mailman_2.1.5-3 installation). But I presume it would be cleaner to wrap a try/finally around most of dolist(). Anyways, with this patch in place, I am able to run update successfully -- ie. no hanging getting a lock. Greg -- Greg Ward http://www.gerg.ca/ Jesus Saves -- but Moses gets the rebound, he shoots, he SCORES! From carson at taltos.org Sun Nov 21 21:19:42 2004 From: carson at taltos.org (Carson Gaspar) Date: Sun Nov 21 21:17:44 2004 Subject: [Mailman-Developers] Bug when canceling invites... Message-ID: If the invited person uses the link included in an invite and tries to cancel the invitation themselves, this happens.... Bug in Mailman version 2.1.5 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 "/Tools/SunOS_5.9_i86pc/mailman-2.1.5/scripts/driver", line 87, in run_main main() File "/Tools/SunOS_5.9_i86pc/mailman-2.1.5/Mailman/Cgi/confirm.py", line 114, in main subscription_cancel(mlist, doc, cookie) File "/Tools/SunOS_5.9_i86pc/mailman-2.1.5/Mailman/Cgi/confirm.py", line 312, in subscription_cancel userdesc = mlist.pend_confirm(cookie)[1] File "/Tools/SunOS_5.9_i86pc/mailman-2.1.5/Mailman/Pending.py", line 141, in pend_confirm assert self.Locked() AssertionError Python information: Variable Value sys.version 2.3.4 (#1, Oct 5 2004, 07:57:49) [C] From chris at scorpion.nl Mon Nov 22 00:01:40 2004 From: chris at scorpion.nl (Christiaan den Besten) Date: Mon Nov 22 00:02:01 2004 Subject: [Mailman-Developers] Bug when canceling invites... References: Message-ID: <004c01c4d01e$0ffd20a0$3d64880a@speedy> Seems you found the same bug I reported a few days ago. At which Jim Tittsler responded the following: --- This is a known bug in 2.1.5. It should be fixed in CVS, or apply this: --Jim Tittsler http://www.OnJapan.net/ GPG: 0x01159DB6Python Starship http://Starship.Python.net/Ringo MUG Tokyo http://www.ringo.net/rss.html---Apply the patch, it works! :)bye,Chris----- Original Message -----From: "Carson Gaspar" To: Sent: Sunday, November 21, 2004 9:19 PMSubject: [Mailman-Developers] Bug when canceling invites...>> If the invited person uses the link included in an invite and tries tocancel the invitation themselves, this happens....>> Bug in Mailman version 2.1.5>> 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 "/Tools/SunOS_5.9_i86pc/mailman-2.1.5/scripts/driver", line 87, in> run_main> main()> File "/Tools/SunOS_5.9_i86pc/mailman-2.1.5/Mailman/Cgi/confirm.py", line> 114, in main> subscription_cancel(mlist, doc, cookie)> File "/Tools/SunOS_5.9_i86pc/mailman-2.1.5/Mailman/Cgi/confirm.py", line> 312, in subscription_cancel> userdesc = mlist.pend_confirm(cookie)[1]> File "/Tools/SunOS_5.9_i86pc/mailman-2.1.5/Mailman/Pending.py", line 141,> in pend_confirm> assert self.Locked()> AssertionError>>>>> Python information:>> Variable> Value>> sys.version> 2.3.4 (#1, Oct 5 2004, 07:57:49) [C]>> _______________________________________________> Mailman-Developers mailing list> Mailman-Developers@python.org> http://mail.python.org/mailman/listinfo/mailman-developers> Unsubscribe:http://mail.python.org/mailman/options/mailman-developers/chris%40scorpion.nl>> From stephen at xemacs.org Mon Nov 22 10:28:20 2004 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Mon Nov 22 10:28:34 2004 Subject: [Mailman-Developers] Dates again In-Reply-To: <419F28E4.1000309@afn.org> (Steven Kuck's message of "Sat, 20 Nov 2004 06:22:12 -0500") References: <419F00EA.7010207@afn.org> <419F28E4.1000309@afn.org> Message-ID: <873bz26xmz.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "Steven" == Steven Kuck writes: >> At 3:31 AM -0500 2004-11-20, Steven Kuck wrote: >>> Since all of these messages are, in fact, being sent by my >>> server I think it quite reasonable to change the "Date" to >>> reflect the time that it was processed and changed by the >>> server. It's equally reasonable to disobey "no trespassing" signs if you plan to avoid making a mess. In both cases, however, you're using a facility that is somebody else's property, and in both cases you may inadvertantly cause problems for the person who has the right to use it. Steven> Can you point me to the definitive text for mail header Steven> definitions? RFC 733 only defines the format - it doesn't Steven> say they are any more inviolate than the "Subject" line. That's true. In fact, they're equally property of the author(s) (in the wording of RFC 822 and reaffirmed by 2822), and I detest mailing lists that insist on munging the Subject header, too. Even this one. If an MUA can't do the right thing based on the List-* headers, I want no part of it, not even to share a mailing list with it. Of course, unlike "no trespassing", there are no courts to enforce the RFCs. But don't let that fool you. They are "legislation", the product of the skull sweat of dozens of "representatives" far more competent and hardworking than my Congresszombie, tested in practice, introduced and maintained through the cooperation and hard work of hundreds or thousands of programmers, distributors, and sys admins. The social contract says "These headers are for the use of authors", and you (as a list admin) want to hijack the "Date" header. You say "well, it would be very convenient if I could use these facilities for my own purposes". I can't blame you for _wishing_; still, an honest man would create an appropriate header _for the use of the mailing list manager_, and then lobby and write the software to get it accepted and diffused through the community. Specifically, you could use either an X-List-Sequence-Number header or an X-List-Receipt-Date header for your purpose. Teach the archivers about them (and the versions without "X-", since of course you'll submit an RFC, right?) for the benefit of web readers. Re your examples: Steven> Why do I care if the message was stuck (unless it's my Steven> server) or if the user's clock is wrong? You don't. You've already proved that. But authors will care, if they are not responsible for the stuckage, and they look like idiots because their post was written without the benefit of a week's worth of further information, but nonetheless appears with a current date. Steven> As I said, I can guarantee messages from the future are Steven> wrong. Disagree? Depends on what you mean by "wrong". Your server may very well change the interval between, or even the order of, two posts from the same (ie, consistently translated) future. Whether this information is interesting or not is another question; you are, however, destroying it, and there's nothing in the RFCs that permits you to do that. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. From l.hilton at chello.nl Mon Nov 22 11:11:47 2004 From: l.hilton at chello.nl (Luke Hilton) Date: Mon Nov 22 11:11:15 2004 Subject: [Mailman-Developers] Excessive unsubscriptions Message-ID: <20041122101112.FJC7692.amsfep18-int.chello.nl@home> Hi All, I am very new to Linux, but will tell you what I can. I am trying to diagnose a problem on a. Linux Redhat server Mailman version 2.1.4 Spamassassin Squirrelmail The particular mailing list has over 20,000 members. The list is being sent to on a on a monthly basis one way. A mass mail (80k - html) was sent out to the 20,000 members approximately 2 weeks ago. All seemed to go fine. I was alerted that the server performance had dropped dramatically so I checked the obvious and then bounced it. The following day I received approx. 3000 unsubscribe notices. This is highly irregular as in the past only a few unsubscribe notices come in per month. I checked these entries in the Membership list and they are still there, but the 'nomail' box is now checked and reason 'B' displayed. A colleague of mine restarted the server again yesterday and I have just received another huge amount of unsubscribe notices again. I followed the following faq yesterday in an attempt to diagnose. http://www.python.org/cgi-bin/faqw-mm.py?req=show &file=faq03.014.htp 1. Permissions seemed fine 2. Cron daemon was running 3. Aliases are in /etc/aliases + did a 'newaliases' 4. I checked the mailman/locks and there are a number of locks from around the time the list was sent 5. I checked to see if the processes are still around for the above locks and they are Should I delete the locks? If so how do I do this safely? Has anyone heard of this type of problem happening before? I want to make sure there are no pending mailman tasks to complete and that if another restart occurs I won't get bombarded by another wad of unsubscribes. I have a copy of the membership list and was thinking I could create 3 new mailing lists and divide the 20000 people over the 4 lists. Is this worth it? Should mailman be able to send 20,000 mails easily? Any help with this would be fantastic. Luke From stephen_pollei at comcast.net Mon Nov 22 11:32:49 2004 From: stephen_pollei at comcast.net (Stephen Pollei) Date: Mon Nov 22 11:30:33 2004 Subject: [Mailman-Developers] Dates again In-Reply-To: <873bz26xmz.fsf@tleepslib.sk.tsukuba.ac.jp> References: <419F00EA.7010207@afn.org> <419F28E4.1000309@afn.org> <873bz26xmz.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <1101119570.1096.176.camel@fury> On Mon, 2004-11-22 at 01:28, Stephen J. Turnbull wrote: > Specifically, you could use either an X-List-Sequence-Number header or > an X-List-Receipt-Date header for your purpose. Teach the archivers > about them (and the versions without "X-", since of course you'll > submit an RFC, right?) for the benefit of web readers. Cool three Steves. Well I think that a more generic approach might be great. Something that could show who received the message from who, at what time, for what address, and maybe other information as well. You could then teach the archivers what is the name of your mailing list. I think we can call it simply "received". Quick someone write a RFC for this one; I think it's a winner. Below are a few examples of just what might be possible. Anyway I think that maybe the existing headers might have enough information to do the job. I also think that if the date shows too much skew into either the past or the future you shouldn't be forwarded seems someone already gave a config option that you can tweak for that. Actually I think it could be cool to integrate in something like http://hashcash.org/ which would also force clocks to be in sync by at least a month. I guess that I'm just trying to think of how things like spf/ses/srs, http://www.doaml.net/ , http://sourceforge.net/projects/gossip-project/ , hashcash, and a few other things might fit into the mailman world. Received: from smtp-vbr8.xs4all.nl ([194.109.24.28]) by sccrmxc19.comcast.net (sccrmxc19) with ESMTP id <20041122092847s1900g6dkoe>; Mon, 22 Nov 2004 09:28:47 +0000 Received: from bag.python.org (bag.python.org [194.109.207.14]) by smtp-vbr8.xs4all.nl (8.12.11/8.12.11) with ESMTP id iAM9SliV035191 for ; Mon, 22 Nov 2004 10:28:47 +0100 (CET) (envelope-from mailman-developers-bounces+stephen_pollei=comcast.net@python.org) Received: from bag.python.org (bag [127.0.0.1]) by bag.python.org (Postfix) with ESMTP id 3DE791E400B for ; Mon, 22 Nov 2004 10:28:46 +0100 (CET) Received: from bag.python.org (bag [127.0.0.1]) by bag.python.org (Postfix) with ESMTP id EEFE01E4002 for ; Mon, 22 Nov 2004 10:28:32 +0100 (CET) Received: from bag (HELO bag.python.org) (127.0.0.1) by bag.python.org with SMTP; 22 Nov 2004 10:28:32 +0100 Received: from tleepslib.sk.tsukuba.ac.jp (tleepslib.sk.tsukuba.ac.jp [130.158.98.109]) by bag.python.org (Postfix) with ESMTP for ; Mon, 22 Nov 2004 10:28:32 +0100 (CET) Received: from steve by tleepslib.sk.tsukuba.ac.jp with local (Exim 4.34) id 1CWAUh-0005yb-Ai; Mon, 22 Nov 2004 18:28:23 +0900 -- http://dmoz.org/profiles/pollei.html http://sourceforge.net/users/stephen_pollei/ http://www.orkut.com/Profile.aspx?uid=2455954990164098214 http://stephen_pollei.home.comcast.net/ GPG Key fingerprint = EF6F 1486 EC27 B5E7 E6E1 3C01 910F 6BB5 4A7D 9677 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041122/b6ad5cb7/attachment-0001.pgp From mailman at primatesynthesis.com Mon Nov 22 19:30:24 2004 From: mailman at primatesynthesis.com (Mark) Date: Mon Nov 22 19:30:34 2004 Subject: [Mailman-Developers] new feature request (was: Re: setting a list for no daily reminders?) In-Reply-To: References: Message-ID: Thanks to everyone who responded. Please forgive this crosspost to the developers group. Seeing that there is no way to do this without changing the code, and that many Mailman users are not Python programmers or do not have the permission to make such changes on the server they are using, I think it would be best if this was made an option that could be set through the web interface for each list. That way administrators could choose immediate notifications, daily summaries, or both. THANX!! :) On 11/20/04, Mark Sapiro put forth: >Mark wrote: > > > >I am running a list set to immediately send administrative requests > >(admin_immed_notify set to yes), but I am getting daily notices as > >well. I don't want to receive daily notices. The immediate notices > >are sufficient. Nor do I see the logic in filling my inbox with > >daily notices when I'm not around or haven't had a chance to process > >the immediate notices that are already sitting there. > > > >Is there any way to change this?? > >You could delete the checkdbs entry from crontab, but this would affect >all lists and also would have the side effect of never clearing stale >entries from hold_and_cmd_autoresponses[] (I don't think this is >serious because I don't think there is ever more than one entry per >user - stale entries get "reused"). > >The only other way and the only way to do it per list is to change the >code in checkdbs. From brad at stop.mail-abuse.org Mon Nov 22 20:16:52 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Mon Nov 22 20:18:08 2004 Subject: [Mailman-Developers] Re: [Mailman-Users] new feature request (was: Re: setting a list for no daily reminders?) In-Reply-To: References: Message-ID: At 1:30 PM -0500 2004-11-22, Mark wrote: > Seeing that there is no way to do this without > changing the code, and that many Mailman users are not Python > programmers or do not have the permission to make such changes on the > server they are using, I think it would be best if this was made an > option that could be set through the web interface for each list. If you want this to actually get on the list of requested feature enhancements, you should use the Mailman RFE page at to submit your request. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From mailman at primatesynthesis.com Mon Nov 22 22:55:43 2004 From: mailman at primatesynthesis.com (Mark) Date: Mon Nov 22 22:56:15 2004 Subject: [Mailman-Developers] Re: [Mailman-Users] new feature request (was: Re: setting a list for no daily reminders?) In-Reply-To: References: Message-ID: On 11/22/04, Brad Knowles put forth: >At 1:30 PM -0500 2004-11-22, Mark wrote: > >> Seeing that there is no way to do this without >> changing the code, and that many Mailman users are not Python >> programmers or do not have the permission to make such changes on the >> server they are using, I think it would be best if this was made an >> option that could be set through the web interface for each list. > > If you want this to actually get on the list of requested >feature enhancements, you should use the Mailman RFE page at > to submit >your request. Thanks. Done. From msapiro at value.net Tue Nov 23 19:45:41 2004 From: msapiro at value.net (Mark Sapiro) Date: Tue Nov 23 19:45:46 2004 Subject: [Mailman-Developers] admin_member_chunksize not available in GUI or config_list Message-ID: I have submitted this at https://sourceforge.net/tracker/index.php?func=detail&aid=1072002&group_id=103&atid=100103 -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From jrhett at meer.net Wed Nov 24 04:13:58 2004 From: jrhett at meer.net (Joe Rhett) Date: Wed Nov 24 04:14:06 2004 Subject: [Mailman-Developers] Dates again In-Reply-To: References: <419F00EA.7010207@afn.org> Message-ID: <20041124031358.GB65907@meer.net> On Sat, Nov 20, 2004 at 10:42:24AM +0100, Brad Knowles wrote: > If there were a way to effectively detect when a "Date:" header > was wrong and when it was okay, then I might be willing to allow the > system to correct the "Date:" header in those particular cases. If > you've got a patch or additional code that can do that, I'd like to > see it, although I can't promise it would be accepted by the Mailman > developers for inclusion in an upcoming version. > > I can't speak for Barry, Tokio, or the other Mailman developers, > but I would be violently opposed to a change of this sort. Out of curiosity, am I overlooking something or are we over-generalizing the solution? My straw man (which may be wildly under-educated) is that we have no need at all to modify any headers, but instead to ignore the Date: header entirely for archive and digest purposes. Leave the Date header there, but don't use it. Instead use time of receipt. Now, go grab a 2x4 and clue me in... -- Joe Rhett Senior Geek Meer.net From brad at stop.mail-abuse.org Wed Nov 24 10:52:05 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Wed Nov 24 11:05:43 2004 Subject: [Mailman-Developers] Dates again In-Reply-To: <20041124031358.GB65907@meer.net> References: <419F00EA.7010207@afn.org> <20041124031358.GB65907@meer.net> Message-ID: At 7:13 PM -0800 2004-11-23, Joe Rhett wrote: > My straw man (which may be wildly under-educated) is that we have no need > at all to modify any headers, but instead to ignore the Date: header > entirely for archive and digest purposes. Leave the Date header there, but > don't use it. Instead use time of receipt. Date is one of the ways that the archive is sorted. You'd have to display a different header which would be consistent with the sort order, and change some other links to read "time of receipt" instead of "date". Overall, more work than just correcting the "Date:" header, although it would be more correct. Do-able, yes. But not currently being done. Moreover, there are already other methods currently built into the code for handling this issue with respect to the archives -- see previous messages from Barry and Jim. For my part, this issue has as much to do with "correcting" messages as they arrive into the system (and before they are archived or sent back out again), as it is keeping the archives clean. It's one thing to just keep the archives clean, it's another to "correct" the message before it gets recorded in the archives or sent back out again. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From iane at sussex.ac.uk Wed Nov 24 20:09:58 2004 From: iane at sussex.ac.uk (Ian Eiloart) Date: Wed Nov 24 20:10:01 2004 Subject: [Mailman-Developers] Dates again In-Reply-To: <20041124031358.GB65907@meer.net> References: <419F00EA.7010207@afn.org> <20041124031358.GB65907@meer.net> Message-ID: <6EAAE0935BDDBDBDDF8DCC4B@lewes.staff.uscs.susx.ac.uk> --On Tuesday, November 23, 2004 19:13:58 GMT -0800 Joe Rhett wrote: > On Sat, Nov 20, 2004 at 10:42:24AM +0100, Brad Knowles wrote: >> If there were a way to effectively detect when a "Date:" header >> was wrong and when it was okay, then I might be willing to allow the >> system to correct the "Date:" header in those particular cases. If >> you've got a patch or additional code that can do that, I'd like to >> see it, although I can't promise it would be accepted by the Mailman >> developers for inclusion in an upcoming version. >> >> I can't speak for Barry, Tokio, or the other Mailman developers, >> but I would be violently opposed to a change of this sort. > > Out of curiosity, am I overlooking something or are we over-generalizing > the solution? > > My straw man (which may be wildly under-educated) is that we have no need > at all to modify any headers, but instead to ignore the Date: header > entirely for archive and digest purposes. Leave the Date header there, > but don't use it. Instead use time of receipt. > > Now, go grab a 2x4 and clue me in... Hmm, I think that this whole conversation is not seeing the wood for the trees. Why would anyone want to sort a list by date? The date of a posting isn't really relevant except: 1. So that we can understand the currency of the information. For example, I don't want to be reading 1998 postings if I'm looking for information on the latest version of - say - Apache. For that it doesn't matter much that a date might be a few hours out. 2. Location in a conversational thread. It is important to read threads in order. For that, the important thing is the time that the email was sent, not the time that it arrived - which may differ by minutes, hours or days. However, the better solution is to sort by threads using in-reply-to headers. Google's gmail, and Apple's Mail application do this nicely. I think that development focus should be on displaying threads properly, not on "fixing" dates that the system can't possibly know are right or wrong. -- Ian Eiloart Servers Team Sussex University ITS From terri at zone12.com Wed Nov 24 21:25:42 2004 From: terri at zone12.com (Terri Oda) Date: Wed Nov 24 21:25:37 2004 Subject: [Mailman-Developers] Dates again In-Reply-To: <6EAAE0935BDDBDBDDF8DCC4B@lewes.staff.uscs.susx.ac.uk> References: <419F00EA.7010207@afn.org> <20041124031358.GB65907@meer.net> <6EAAE0935BDDBDBDDF8DCC4B@lewes.staff.uscs.susx.ac.uk> Message-ID: <036A1395-3E57-11D9-BDB0-000D934FBF38@zone12.com> On Nov 24, 2004, at 2:09 PM, Ian Eiloart wrote: > Hmm, I think that this whole conversation is not seeing the wood for > the trees. Why would anyone want to sort a list by date? The date of a > posting isn't really relevant except: [snip several good reasons] 3. Helping users sort the email in their inboxes. This can be important to some people, since I know when we had one user posting from 1980, many other list members weren't noticing her posts because their mail clients put those messages where the date: header said they should be. That said, I think this is something that is better handled by mail clients and the original senders, not Mailman. But in the past, I've been asked for this feature for this reason, so I imagine other people want it for similar reasons. Terri From brad at stop.mail-abuse.org Thu Nov 25 00:36:08 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu Nov 25 00:40:22 2004 Subject: [Mailman-Developers] Dates again In-Reply-To: <6EAAE0935BDDBDBDDF8DCC4B@lewes.staff.uscs.susx.ac.uk> References: <419F00EA.7010207@afn.org> <20041124031358.GB65907@meer.net> <6EAAE0935BDDBDBDDF8DCC4B@lewes.staff.uscs.susx.ac.uk> Message-ID: At 7:09 PM +0000 2004-11-24, Ian Eiloart wrote: > I think that development focus should be on displaying threads properly, > not on "fixing" dates that the system can't possibly know are right or > wrong. There is already a "thread sort" mode within the archiving system. There is also a "date sort" mode. If we're going to have a given mode, it makes sense that we'd want to be able to display that mode "correctly". My issue has more to do with doing that as a display-only matter as opposed to "correcting" the messages on input and before they are sent back out to the list recipients, as well as being recorded in the archives. Where we do the "correction" is as important as the correction itself. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From shiva at sewingwitch.com Thu Nov 25 02:10:26 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu Nov 25 02:10:50 2004 Subject: [Mailman-Developers] Dates again In-Reply-To: <036A1395-3E57-11D9-BDB0-000D934FBF38@zone12.com> References: <419F00EA.7010207@afn.org> <20041124031358.GB65907@meer.net> <6EAAE0935BDDBDBDDF8DCC4B@lewes.staff.uscs.susx.ac.uk> <036A1395-3E57-11D9-BDB0-000D934FBF38@zone12.com> Message-ID: --On Wednesday, November 24, 2004 3:25 PM -0500 Terri Oda wrote: > 3. Helping users sort the email in their inboxes. This can be important > to some people, since I know when we had one user posting from 1980, many > other list members weren't noticing her posts because their mail clients > put those messages where the date: header said they should be. And the reverse problem of a message with date in the extreme future, which always sorts to the end of the mailbox. From jwblist at olympus.net Thu Nov 25 04:16:17 2004 From: jwblist at olympus.net (John W. Baxter) Date: Thu Nov 25 04:16:32 2004 Subject: [Mailman-Developers] Dates again In-Reply-To: <036A1395-3E57-11D9-BDB0-000D934FBF38@zone12.com> Message-ID: On 11/24/2004 12:25, "Terri Oda" wrote: > 3. Helping users sort the email in their inboxes. This can be > important to some people, since I know when we had one user posting > from 1980, many other list members weren't noticing her posts because > their mail clients put those messages where the date: header said they > should be. I seem to be unusual in that a. I prefer to keep my In boxes empty enough that all the messages show b. My attitude about problem mail is that if it's hard to read, toss it out...there's lots of other email in the world. Hard to read would--stretching things--include "hides itself due to faulty date." --John From stephen at xemacs.org Thu Nov 25 05:04:48 2004 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu Nov 25 05:05:05 2004 Subject: [Mailman-Developers] Dates again In-Reply-To: <1101119570.1096.176.camel@fury> (Stephen Pollei's message of "22 Nov 2004 02:32:49 -0800") References: <419F00EA.7010207@afn.org> <419F28E4.1000309@afn.org> <873bz26xmz.fsf@tleepslib.sk.tsukuba.ac.jp> <1101119570.1096.176.camel@fury> Message-ID: <87oehm1sm7.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "Stephen" == Stephen Pollei writes: Stephen> Anyway I think that maybe the existing headers might have Stephen> enough information to do the job. I agree. The point of adding a new header would be to make the result of the fairly complex analysis required available to other clients (both human and automatic), and to the current "internal pipeline", for that matter. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. From tkikuchi at is.kochi-u.ac.jp Thu Nov 25 14:10:41 2004 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Thu Nov 25 14:10:47 2004 Subject: [Mailman-Developers] Maybe it's time to release 2.1.6 Message-ID: <41A5D9D1.70808@is.kochi-u.ac.jp> Hi Developers, Since I took charge of CVS committer this September, I belive we could fix number of bugs, merged a few new small-but-nice features, and the code became fairly stable. And, I write 'fixed in CVS' many times answering bug reports these days. Although I have some new features to be added in mind in a longer time scale, I think it is time to take the schedule of new release into consideration. I would like you the developers to download the current source from the CVS (Release_2_1-maint) and test on your testing/working sites before Barry can arrange the time schedule of releasing 2.1.6. Cheers, -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From msapiro at value.net Thu Nov 25 19:56:04 2004 From: msapiro at value.net (Mark Sapiro) Date: Thu Nov 25 19:56:16 2004 Subject: [Mailman-Developers] Excessive unsubscriptions In-Reply-To: <20041122101112.FJC7692.amsfep18-int.chello.nl@home> Message-ID: Luke Hilton wrote: > >A mass mail (80k - html) was sent out to the 20,000 members approximately 2 >weeks ago. All seemed to go fine. I was alerted that the server >performance had dropped dramatically so I checked the obvious and then >bounced it. The following day I received approx. 3000 unsubscribe notices. >This is highly irregular as in the past only a few unsubscribe notices come >in per month. I checked these entries in the Membership list and they are >still there, but the 'nomail' box is now checked and reason 'B' displayed. These are not unsubscribes. They are subscription disables due to "bouncing". See your list's Bounce Processing page for settings that control this process (normally, you don't want to disable someone on the first bounce). -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at python.org Sun Nov 28 19:31:23 2004 From: barry at python.org (Barry Warsaw) Date: Sun Nov 28 19:31:26 2004 Subject: [Mailman-Developers] Dates again In-Reply-To: <6EAAE0935BDDBDBDDF8DCC4B@lewes.staff.uscs.susx.ac.uk> References: <419F00EA.7010207@afn.org> <20041124031358.GB65907@meer.net> <6EAAE0935BDDBDBDDF8DCC4B@lewes.staff.uscs.susx.ac.uk> Message-ID: <1101325424.8202.278.camel@presto.wooz.org> On Wed, 2004-11-24 at 14:09, Ian Eiloart wrote: > I think that development focus should be on displaying threads properly, > not on "fixing" dates that the system can't possibly know are right or > wrong. +1 ! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041128/c0b0a30e/attachment.pgp From barry at python.org Sun Nov 28 20:06:20 2004 From: barry at python.org (Barry Warsaw) Date: Sun Nov 28 20:06:22 2004 Subject: [Mailman-Developers] Maybe it's time to release 2.1.6 In-Reply-To: <41A5D9D1.70808@is.kochi-u.ac.jp> References: <41A5D9D1.70808@is.kochi-u.ac.jp> Message-ID: <1101668779.19175.5.camel@presto.wooz.org> On Thu, 2004-11-25 at 08:10, Tokio Kikuchi wrote: > Since I took charge of CVS committer this September, I belive we could > fix number of bugs, merged a few new small-but-nice features, and the > code became fairly stable. And, I write 'fixed in CVS' many times > answering bug reports these days. Although I have some new features to > be added in mind in a longer time scale, I think it is time to take the > schedule of new release into consideration. I would like you the > developers to download the current source from the CVS > (Release_2_1-maint) and test on your testing/working sites before Barry > can arrange the time schedule of releasing 2.1.6. I'd love to see a 2.1.6 release "soon-ish". I will have some time near Christmas to work toward this (testing, docs, spinning tarballs, updating web sites, etc.). It would be nice if we could get 2.1.6 out before the first of the year. Do you think that's feasible? AS for longer term, bigger new features, it probably makes more sense to start that work on the CVS trunk, targeting a Mailman 2.2 release. Of course, merging the 2.1 branch back to the trunk is going to be a "fun" job. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041128/1681f56d/attachment.pgp From stephen at xemacs.org Tue Nov 30 11:41:00 2004 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue Nov 30 11:41:18 2004 Subject: [Mailman-Developers] Status of bug #974290 unknown encoding crashes qrunner? Message-ID: <87llcjoc03.fsf@tleepslib.sk.tsukuba.ac.jp> What is the status of these bugs? bug #974290 unknown encoding crashes qrunner bug #926034 crashes on encoding errors I seem to recall that Tokio Kikuchi or maybe Jim Tittsler had a fix, but there's nothing about it in the tracker, and I can't find it in my mailman-developers archive. There are a few posts with the words "unknown encoding" in them on mailman-users and mailman-developers, but no fixes. :-( I can probably get my host to install the codecs (I assume that would help), but this really shouldn't crash the runner. I'm seeing this under Mailman 2.1.5, on a fairly motley RedHat system (I think it was running 5.x when we started hosting our lists there, it's been upgraded piece-by-piece, often from source, since then). Of course it's all Chinese spam in GB2312, but it would be nice if it didn't fill the error log and the shunt queue, and simply evaporated instead. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. From tkikuchi at is.kochi-u.ac.jp Tue Nov 30 14:18:12 2004 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue Nov 30 14:18:17 2004 Subject: [Mailman-Developers] Status of bug #974290 unknown encoding crashes qrunner? In-Reply-To: <87llcjoc03.fsf@tleepslib.sk.tsukuba.ac.jp> References: <87llcjoc03.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <41AC7314.7090907@is.kochi-u.ac.jp> Hi, Stephen J. Turnbull wrote: > What is the status of these bugs? > > bug #974290 unknown encoding crashes qrunner > bug #926034 crashes on encoding errors > > I seem to recall that Tokio Kikuchi or maybe Jim Tittsler had a fix, > but there's nothing about it in the tracker, and I can't find it in my > mailman-developers archive. There are a few posts with the words > "unknown encoding" in them on mailman-users and mailman-developers, > but no fixes. :-( Well, these problems are essentially from absence of codecs for the charset used. You will need to upgrade python to 2.2 for 'windows-1252' was introduced in python 2.2 and not present in 2.1 for the latter #926034 case. You may want to upgrade python to 2.4 because gb2312 and CJK charset was finally supported in the Python distribution. > > I can probably get my host to install the codecs (I assume that would > help), but this really shouldn't crash the runner. > > I'm seeing this under Mailman 2.1.5, on a fairly motley RedHat system > (I think it was running 5.x when we started hosting our lists there, > it's been upgraded piece-by-piece, often from source, since then). Of > course it's all Chinese spam in GB2312, but it would be nice if it > didn't fill the error log and the shunt queue, and simply evaporated > instead. > You can reduce the number of shunts by using privacy filters. In the forthcoming mailman 2.1.6, list-request address is more robust against the spams having alian charset. Again, all developers are encourged to upgrade your installation to the latest CVS (Release_2_1-maint branch). Cheers, -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/