From jcrey@uma.es Thu Jul 1 09:12:11 1999 From: jcrey@uma.es (Juan Carlos Rey Anaya) Date: Thu, 01 Jul 1999 10:12:11 +0200 Subject: [Mailman-Developers] Re: i18n References: Message-ID: <377B22DB.7FF21996@uma.es> Fabio Dorival Victorelli wrote: > > Hello all, > > We've made today the i18n just for one file "bin/newlist" and toke > some minutes... > > I'd like to know if there are somebody working in i18n? > Yes, as I commented to list-developers one month and a half ago. I've been working in Mailman i18n all this time. Mesages I sent to this list were dated 05/21/99 Re: [Mailman-Developers] features suggestion: languages 05/06/99 [Mailman-Developers] Mailman internationalization. Report from the trenches. VERY LONG I have made TONS and TONS of modifications to Mailman code to achieve what I told in the first message. The only work that remains to be done is exactly the translation of strings inside code. I am waiting for Dan Ohnesorg to give the code he made to generate .PO I have a demo version of what I have done at http://joker.sci.uma.es/mailman/listinfo/test This version can switch between templates of differents languages. We can work together if you like. Cheers -- ___ / F \ [[[]]]] ( O O ) #----------------0000--(_)--0000---------------# | Juan Carlos Rey Anaya (jcrey@uma.es) | | Servicio Central de informática | | Universidad de Málaga - España | #----------------------------------------------# # Solo se que cada vez se menos :-| # #----------------------------------------------# From Harald.Meland@usit.uio.no Thu Jul 1 20:33:05 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 01 Jul 1999 21:33:05 +0200 Subject: [Mailman-Developers] forwarded message from David Thiessen In-Reply-To: "Barry A. Warsaw"'s message of "Sun, 27 Jun 1999 17:27:27 -0400 (EDT)" References: <14198.38719.23553.585277@anthem.cnri.reston.va.us> Message-ID: [David Thiessen] > To whom it may concern: > > I have recently installed Mailman on a system where I work and I have found > it to be a fantastic software package. But to use it here, the people need > documentation and so I have written some. Great! > I was not quite sure where to send it, so I grabbed your email > address. I guess ( would be fine -- if you could post a pointer to where the file can be retrieved from rather than the entire word file, that'd probably be best for files that big. If that for some reason isn't possible, just post the file as an attachment (like you did to Barry). As Mailman is quite web-based, I guess that it would make most sense if the manual is on the web, as well (but a printable version should also be available). I have done a quick'n'dirty Save as HTML "conversion" of the word document -- for now, it is available at . It probably needs to be massaged some more (I somehow suspect that MSWord doesn't create the prettiest HTML in the world, and the web version should probably be split into several files) before going into the distribution, but it is very much better than *no* documentation! Thanks! > And to repeat myself one more time, Mailman is a fantastic program > which I hope the use of will continue to expand. Thanks -- and so do we ;) > By the way, when is the date for a final release. I've given up trying to give specific dates for this, and I haven't been keeping to well up with reported bugs lately :( However, if the bottleneck Barry found is /the/ bottleneck that has been causing some high-volume users of Mailman headaches, and no similarly critical deficiencies has been reported, I think we're nearly there. If anyone still have any faith at all in whatever guesstimates us core developers give on the 1.0 release date, I'd say that it should be out this summer -- let me know if you think that wasn't vague enough :) -- Harald From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Jul 1 21:40:15 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 1 Jul 1999 16:40:15 -0400 (EDT) Subject: [Mailman-Developers] my recent checkins Message-ID: <14203.53807.601067.562228@anthem.cnri.reston.va.us> Not much time, but I went ahead and checked in both changes for which I sent patches about. Having run python.org on these patches for about a day, and esp. over the new month, I feel that they at least don't make things worse. Performance on python.org has gotten /dramatically/ better. I've yet to see a cpu pegged at 100% for more than about 2 minutes, and load averages look much better now (usually <1 where they were consistantly running in the 6-7 range). -Barry From Harald.Meland@usit.uio.no Thu Jul 1 22:23:10 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 01 Jul 1999 23:23:10 +0200 Subject: [Mailman-Developers] Unsubscribed users still getting monthly reminders In-Reply-To: J C Lawrence's message of "Tue, 15 Jun 1999 11:08:54 -0700" References: Message-ID: [J C Lawrence] > I have Mailman v 1.0b8 running at Kanga.Nu (yes, I know its old, > I'll upgrade tonight), and have two list members complaining that > they are no longer subscribed to a list and yet receive monthly > password reminders. When I check the web interfaces, they are in > fact unsubscribed. > > Ideas? cron/mailpasswds gets it's user data from the `passwords' entry of a list, while it's really the `members' (combined with the `user_options') entry that says whether someone will get mail from the list. If an address somehow is present in `passwords', but not in `members', the result would be as you describe. I think you'd have to tweak the list's config.db by hand (e.g. using bin/withlist) to fix this. I wonder whether such inconsistencies could be caused by the mixed-case-address bug which I _think_ was still in there in 1.0b8... Anyway, I guess all of this will be redone after 1.0 with the user object database and all. -- Harald From Harald.Meland@usit.uio.no Thu Jul 1 22:34:08 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 01 Jul 1999 23:34:08 +0200 Subject: [Mailman-Developers] Viewing anyone's options w/o a password In-Reply-To: Rob Francis's message of "Wed, 23 Jun 1999 14:24:13 -0400 (EDT)" References: Message-ID: [Rob Francis] > It seems kind of odd to me that if I know someone's email address on > a list that I can go to the Info page and enter their email address, > and then w/o a password see what options they have set. I agree -- in principle this really is giving away more info than it should, e.g. if I suspect that someone is subscribed to a list, I can use this "feature" to verify my suspicion. However, if we make access to the user options page password restricted, we'd (obviously) have to put the "Email my password to me" button on some other page -- and I sort of think the listinfo page is crowded enough as it is. > Just wondering if this was a decision made on purpose, or perhaps an > oversight. I don't know for sure, but I suspect it was done like this because of the "Email my password to me" issue. Good suggestions on how this should best be solved are welcome. -- Harald From Harald.Meland@usit.uio.no Thu Jul 1 22:42:57 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 01 Jul 1999 23:42:57 +0200 Subject: [Mailman-Developers] Cooki e problem with current CVS tree In-Reply-To: J C Lawrence's message of "Wed, 23 Jun 1999 12:54:25 -0700" References: Message-ID: [J C Lawrence] > I just revved a 1.0rc1 installation to the current CVS tree. > Cookies no longer track properly -- you are asked to re-authenticate > on every page and nothing gets done. > > Known fix? Nope, it works fine for me -- could you try instrumenting the WebAuthenticate(), MakeCookie() and CheckCookie() methods in Mailman/SecurityManager.py (e.g. by inserting debug "print" statements) to pinpoint exactly what it is that makes cookie authentication fail? -- Harald From Harald.Meland@usit.uio.no Thu Jul 1 22:50:05 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 01 Jul 1999 23:50:05 +0200 Subject: [Mailman-Developers] config.db In-Reply-To: Ricardo Kustner's message of "Wed, 23 Jun 1999 22:13:31 +0200 (CEST)" References: Message-ID: [Ricardo Kustner] > Hi, > > Yesterday i was looking where mailman stores the > pending-for-moderation messages ... it took a while before I found > out... cause i'd never suspect it to be inside config.db ? I must confess that this caught me by surprise when I first saw it, too, but I've never gotten round to try changing it. Ideally we shouldn't tempt Murphy by saving non-config data in config.db, so I guess this is one more to be fixed post 1.0. > what's the philosophy on that... I guess it was put there because "it's convenient" and/or "it works" :) -- Harald From Harald.Meland@usit.uio.no Thu Jul 1 23:02:01 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 02 Jul 1999 00:02:01 +0200 Subject: [Mailman-Developers] Setting Reply-To In-Reply-To: J C Lawrence's message of "Wed, 23 Jun 1999 14:43:27 -0700" References: Message-ID: [J C Lawrence] > A peculiar need: > > I need to set Reply-To on a list to something OTHER than the list > address. Specifically I need to set Reply-To to the address of > another list. > > Can do? I guess you could do this by having a list-specific filter add the necessary Reply-To: headers -- but it'll be rather kludgy. Read the scripts/post code for when and how list-specific filters are invoked. I guess this will be solved by the general "add these headers" planned for post-1.0. -- Harald From Harald.Meland@usit.uio.no Thu Jul 1 23:26:11 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 02 Jul 1999 00:26:11 +0200 Subject: [Mailman-Developers] Re: Bug#40101: mailman: unexpected mailman error In-Reply-To: Gergely Madarasz's message of "Thu, 24 Jun 1999 15:57:30 +0200 (METDST)" References: Message-ID: [Gergely Madarasz] > someone who is already subscribed tried to subscribe again. mailman > should catch this exception and reply politely, I'm forwarding this > upstream. Thanks for the bug report, this has now been fixed in CVS. -- Harald From Harald.Meland@usit.uio.no Thu Jul 1 23:38:46 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 02 Jul 1999 00:38:46 +0200 Subject: [Mailman-Developers] Bug in GatewayManager.py, 1.0rc2 In-Reply-To: Ben Gertzfield's message of "25 Jun 1999 16:02:19 -0700" References: Message-ID: [Ben Gertzfield] > I'm not subscribed to this list, so please Cc: me on any replies. > I hope this is the right place to send bug reports. > > Anyway, the bug looks like a think-o in GatewayManager.py: Thanks for the report, fixed in CVS. -- Harald From che@debian.org Thu Jul 1 23:59:22 1999 From: che@debian.org (Ben Gertzfield) Date: 01 Jul 1999 15:59:22 -0700 Subject: [Mailman-Developers] Bug in GatewayManager.py, 1.0rc2 In-Reply-To: Harald Meland's message of "02 Jul 1999 00:38:46 +0200" References: Message-ID: >>>>> "Harald" == Harald Meland writes: Ben> I'm not subscribed to this list, so please Cc: me on any Ben> replies. I hope this is the right place to send bug reports. Ben> Ben> Anyway, the bug looks like a think-o in GatewayManager.py: Harald> Thanks for the report, fixed in CVS. -- Harald Thanks, Harald! Also, I've noticed that gate_news is extremely poor at handling any kinds of exceptions if something goes wrong when gatewaying mail to news. I've been getting about 15-20 mails a day from cron about all the uncaught exceptions from gate_news. Here are some examples of the different exceptions I've been getting: [snip] Subject: Cron /usr/bin/python /usr/lib/mailman/cron/gate_news Date: Fri, 25 Jun 1999 04:10:07 -0700 Exception exceptions.IOError: (2, 'No such file or directory') in ignored [snip] Subject: Cron /usr/bin/python /usr/lib/mailman/cron/gate_news Date: Fri, 25 Jun 1999 06:06:34 -0700 Traceback (innermost last): File "/usr/lib/mailman/cron/gate_news", line 119, in ? main() File "/usr/lib/mailman/cron/gate_news", line 78, in main conn = nntplib.NNTP(mlist.nntp_host) File "/usr/lib/python1.5/nntplib.py", line 73, in __init__ self.welcome = self.getresp() File "/usr/lib/python1.5/nntplib.py", line 132, in getresp raise error_temp, resp nntplib.error_temp: 400 Flushing log and syslog files [snip] Subject: Cron /usr/bin/python /usr/lib/mailman/cron/gate_news Date: Fri, 25 Jun 1999 08:40:04 -0700 Exception exceptions.ValueError: 'unpack list of wrong size' in ignored [snip] Subject: Cron /usr/bin/python /usr/lib/mailman/cron/gate_news Date: Fri, 25 Jun 1999 08:50:03 -0700 Exception NotLockedError in ignored [snip] I assume all of these can be fixed by properly dealing with these exceptions. It's extremely frustrating to be getting so many exception reports every day.. -- Brought to you by the letters P and F and the number 8. "You forgot Uranus." "Goooooooooodnight everybody!" Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From richarde@eskom.co.za Fri Jul 2 07:24:13 1999 From: richarde@eskom.co.za (Richard Ellerbrock) Date: Fri, 02 Jul 1999 08:24:13 +0200 Subject: [Mailman-Developers] Another news gateing problem Message-ID: If the news server is too busy or down, the following error is generated to cron (not nice)! This should just fail gracefully, be logged and be tried again later at the next cron run. Traceback (innermost last): File "/home/mailman/cron/gate_news", line 119, in ? main() File "/home/mailman/cron/gate_news", line 78, in main conn = nntplib.NNTP(mlist.nntp_host) File "/usr/lib/python1.5/nntplib.py", line 70, in __init__ self.sock.connect(self.host, self.port) socket.error: (111, 'Connection refused') -- Richard Ellerbrock richarde@eskom.co.za From eugene.leitl@lrz.uni-muenchen.de Sun Jul 4 07:27:43 1999 From: eugene.leitl@lrz.uni-muenchen.de (Eugene Leitl) Date: Sat, 3 Jul 1999 23:27:43 -0700 (PDT) Subject: [Mailman-Developers] personal server-side filtering Message-ID: <14206.64854.775517.831387@lrz.de> Hi. Another list I'm on often goes into regimes with bad signal/noise regularly provoking cries for moderation. Here's a scheme I/friend of mine come with --I'd like to know how difficult it would be to add to mailman (particularly, where to massage it in). "To recapitulate: my original proposal was to establish a pair of lists: fnord-moderated/fnord-unmoderated. Everything rejected from fnord-moderated would go to fnord-unmoderated that anybody who subscribed to both lists would get the full feed, if so inclined. This scheme is simple to implement, but has obvious flaws. To avoid pressing anybody in a single quality metric it should be possible to associate each subscriber with a ranking matrix against the other participants (which could be inquirable remotely). With 1 k subscribers this means keeping track of 1 M short integers, which is tolerable nowadays (besides, this can be implemented as sparse matrix). Each mail will be attached a pair of urls/listserv commands to increment/decrement your individual ranking of the poster this mail came from. The matrix gets initialized with zero. All positive values including zero mean no filtering. -1 means every second post gets through, -2 every third, etc. This doesn't include topic filtering, but this can be addressed separately. To address this, we can agree on an initial keyword pool (META:SPACE:GUNS: etc.) and make the listserv let through only properly classified messages. If a message is unclassified it gets send back with a list of current keywords. There should be a mechanism of creating new keywords, and discarding obsolete ones (e.g. by aging). I'm fairly certain it would be possible to hack mailman into supporting this. Does anybody see any obvious flaws in the scheme?" So, any comments on that? TIA, Eugene From gorgo@caesar.elte.hu Mon Jul 5 16:25:01 1999 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Mon, 5 Jul 1999 17:25:01 +0200 (METDST) Subject: [Mailman-Developers] cookie problem ? Message-ID: Hello, If I want to access the mailman pages thru a different url (like http://somehost/cgi-bin/mailman/, the cgi-bin directory has a symlink to mailman/cgi-bin) the cookie authentication is problematic. It allows access for the first time but after that it wants authentication again. Could this be fixed somehow ? This way there wouldn't be need to configure the webserver to use the /mailman/ alias. -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From gonter@maestria.wu-wien.ac.at Wed Jul 7 18:31:23 1999 From: gonter@maestria.wu-wien.ac.at (Gerhard Gonter) Date: Wed, 7 Jul 1999 19:31:23 +0200 (MES) Subject: [Mailman-Developers] automatically generated password too complicated? In-Reply-To: <199904201821.UAA20318@maestria.wu-wien.ac.at> from Gerhard Gonter at "Apr 20, 99 08:21:54 pm" Message-ID: <199907071731.TAA31534@maestria.wu-wien.ac.at> Huh? Did that posting hide in a mail queue for 2.5 months?? > Received: from python.org (localhost [127.0.0.1]) > by python.org (8.9.1a/8.9.1) with ESMTP id NAA01107; > Wed, 7 Jul 1999 13:24:39 -0400 (EDT) > Received: from maestria.wu-wien.ac.at (maestria.wu-wien.ac.at [137.208.7.7]) > by python.org (8.9.1a/8.9.1) with ESMTP id OAA09471 > for ; Tue, 20 Apr 1999 14:21:55 -0400 (EDT) +gg -- Gerhard.Gonter@wu-wien.ac.at Fax: +43/1/31336/702 g.gonter@ieee.org Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria --- Linux or FreeBSD, it's like blondes or brunettes. I like both. -- From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Jul 7 18:51:05 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 7 Jul 1999 13:51:05 -0400 (EDT) Subject: [Mailman-Developers] automatically generated password too complicated? References: <199904201821.UAA20318@maestria.wu-wien.ac.at> <199907071731.TAA31534@maestria.wu-wien.ac.at> Message-ID: <14211.37769.349229.720435@anthem.cnri.reston.va.us> >>>>> "GG" == Gerhard Gonter writes: GG> Huh? Did that posting hide in a mail queue for 2.5 months?? Yes. Suffice to say the logjam on python.org is now getting cleared ;) -Barry From jeffh@streek.com Wed Jul 7 19:07:08 1999 From: jeffh@streek.com (Jeff Hahn) Date: Wed, 7 Jul 1999 13:07:08 -0500 Subject: [Mailman-Developers] FW: Returned mail: unknown mailer error 1 Message-ID: <004801bec8a3$871cf940$1e0a5ad1@SINGSING.STREEK.COM> A mail message with the following To: line generated this error... "To: :" (The following message has been "somewhat" sanitized) -Jeff -----Original Message----- From: Mail Delivery Subsystem [mailto:Postmaster@rikers.streek.com] Sent: Wednesday, July 07, 1999 7:21 AM To: xxx-request@xxx.com Subject: Returned mail: unknown mailer error 1 The original message was received at Wed, 7 Jul 1999 07:20:17 -0500 from maillist@xxx.xxx.com [xxx.xx.xx.xx] ----- The following addresses had permanent fatal errors ----- "|/home/mailman/MM/mail/wrapper post xxx" (expanded from: ) ----- Transcript of session follows ----- Traceback (innermost last): File "/home/mailman/MM/scripts/post", line 73, in ? mlist.Post(msg, approved=fromusenet) File "/home/mailman/MM/Mailman/MailList.py", line 1243, in Post if (self.require_explicit_destination and File "/home/mailman/MM/Mailman/MailList.py", line 1081, in HasExplicitDest for recip in msg.getaddrlist('to') + msg.getaddrlist('cc'): File "/home/mailman/MM/Mailman/pythonlib/rfc822.py", line 320, in getaddrlist return a.getaddrlist() File "/home/mailman/MM/Mailman/pythonlib/rfc822.py", line 496, in getaddrlist ad = self.getaddress() File "/home/mailman/MM/Mailman/pythonlib/rfc822.py", line 533, in getaddress if self.field[self.pos] == ';': IndexError: string index out of range 554 "|/home/mailman/MM/mail/wrapper post xxx"... unknown mailer error 1 From dragondm@integral.org Wed Jul 7 20:25:37 1999 From: dragondm@integral.org (The Dragon De Monsyne) Date: Wed, 7 Jul 1999 14:25:37 -0500 (CDT) Subject: [Mailman-Developers] automatically generated password too complicated? In-Reply-To: <199904201821.UAA20318@maestria.wu-wien.ac.at> Message-ID: On Tue, 20 Apr 1999, Gerhard Gonter wrote: > Some of our users complained about the automatically generated > passwords that are sent out when a list is imported or if an admin > subscribes someone. Especially the ` and ^ characters are major > problem because these may be treated as parts of composite characters > in some enviroments (` followed by a might be displayed as the same > character as à in HTML) and so on. Also, upper case characters > impose an extra mental burden ;) > Hm... I've long been using a replacement for the standard random password generator that greates three word phrases separated by dashes (such as 'wise-red-fox') The words are randomly picked from a list for each position. with about 20-50 words in each list there's abt 100 thousand combos. If the list of words are picked right, the password phrases 'sort of' make sense, and thus are easy to remember. (the caveat being the fact that since the phrases are words there is a language issue... Whatever) -The Dragon De Monsyne From hhielscher@unternehmen.com Mon Jul 5 22:03:40 1999 From: hhielscher@unternehmen.com (Helge Hielscher) Date: Mon, 05 Jul 1999 23:03:40 +0200 Subject: [Mailman-Developers] Re: Mailman-Developers digest References: <199907020500.BAA28872@python.org> Message-ID: <37811DAC.5CAA465F@unternehmen.com> Hello, Some days ago I joined the list and I wonder why the Mailman-Users list´s digest is in MIME but not the developer digest where the mails are only seperated with --__--__-- which makes it harder to read. Who can/may change that behavior? BTW are HTML Index Digests implemented in Mailman? Helge From dragondm@integral.org Fri Jul 9 04:35:26 1999 From: dragondm@integral.org (The Dragon De Monsyne) Date: Thu, 8 Jul 1999 22:35:26 -0500 (CDT) Subject: [Mailman-Developers] Performance problems and MailMan In-Reply-To: <14201.26521.848925.327481@anthem.cnri.reston.va.us> Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --YhIK0mKoxU Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: message body text > Just a quick note 'cause I have very little time. I'm currently > seeing python.org massively pegged, and Guido and I were talking about > some Python tools we'd like to develop that would help debug > situations like this. What I wanted was something like gdb's ability > to attach to and print stack traces of running external programs. We > got into some brainstorming and came up with A Certified Very Cool > Trick[1]. > > This yielded a traceback for where at least two pegged processes are > spinning. Seems to make sense, but I'm not very familar with the > archiving guts, so I post this traceback to spur some discussion. > Maybe Scott or Harald can craft a fix. Hmm... A few thoughts.. I've never seen the load problem on my mailman site, even though I run several reasonabally well trafficked lists, HOWEVER, I run a slightly customized version of HyperArch.py which stil.l uses bsddb for data storage. Also, my site does not immedeately archive messages, it runs an archiving cronjob every few hours.(it still dosen't draw much cpu whence the cronjob kicks in, tho) really, this archiving system was never meant to be used in the current method of operation (being invoked on each incoming message), and it's design is probably rather non-optimal for this use. It spends substantial time building & tearing down & (un)pickling various structures incurring a bit of overhead. -The Dragon De Monsyne --YhIK0mKoxU-- From bwarsaw@python.org Fri Jul 9 04:53:40 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Thu, 8 Jul 1999 23:53:40 -0400 (EDT) Subject: [Mailman-Developers] Performance problems and MailMan References: <14201.26521.848925.327481@anthem.cnri.reston.va.us> Message-ID: <14213.29252.289352.684394@anthem.cnri.reston.va.us> >>>>> "TDDM" == The Dragon De Monsyne writes: TDDM> Hmm... A few thoughts.. I've never seen the load TDDM> problem on my mailman site, even though I run several TDDM> reasonabally well trafficked lists, HOWEVER, I run a TDDM> slightly customized version of HyperArch.py which stil.l TDDM> uses bsddb for data storage. TDDM> Also, my site does not immedeately archive messages, it runs TDDM> an archiving cronjob every few hours.(it still dosen't draw TDDM> much cpu whence the cronjob kicks in, tho) Both those differences (using bsddb and not archiving immediately) explains why you wouldn't see the hit. The bug (now fixed) was in the DumbBTree implementation. TDDM> really, this archiving system was never meant to be TDDM> used in the current method of operation (being invoked on TDDM> each incoming message), and it's design is probably rather TDDM> non-optimal for this use. It spends substantial time TDDM> building & tearing down & (un)pickling various structures TDDM> incurring a bit of overhead. Wonderful understatement Dragon! :) Running with the patches in the CVS tree, I think the current system can work for a site as heavily trafficked as python.org, but it is very inefficient. Maybe we should document that for high traffic sites, you might want to use an external archiver which only runs from a cronjob. Unfortunately, I haven't done this, so if anybody can contribute a HOWTO, I'd appreciate it. -Barry From bwarsaw@cnri.reston.va.us Sat Jul 10 18:00:53 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Sat, 10 Jul 1999 13:00:53 -0400 (EDT) Subject: [Mailman-Developers] (no subject) Message-ID: <14215.31813.854234.222802@anthem.cnri.reston.va.us> Cc python-announce@python.org Subject: [ANNOUNCE] Mailman 1.0rc3 X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) Reply-To: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) X-Attribution: BAW X-Oblique-Strategy: A very small object. Its center X-Url: http://www.python.org/~bwarsaw X-Face: bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass Hi folks, Mailman 1.0 release candidate 3 (1.0rc3) has just been uploaded to www.list.org. This is an important bug fix release which primarily fixes a performance problem in the archiver. Since the GNU folks are getting ready to put together their next source CDROM, this increases the possibility that 1.0rc3 will be short-lived -- with 1.0 final right around the corner! From the NEWS file: 1.0rc3 - new script bin/check_perms which checks (and optionally fixes) the permissions and group ownerships of the files in your Mailman installation. - Removed a bottleneck in the archiving code that was causing performance problems on highly loaded servers. - The code that saves a list's state and configuration database has been made more robust. - Additional exception handlers have been added in several places to alleviate problems with Mailman bombing out when it really would be better to print/log a helpful message. - The "password" mail command will now mail back the sender's subscription password when given with no arguments. - The embarrassing subject-prefixing bug present in rc2 has been fixed. - A small (but nice :) collection of other squashed bugs. On behalf of the entire development team, -Barry From ppp@theporch.com Sat Jul 10 23:28:11 1999 From: ppp@theporch.com (Phillip Porch) Date: Sat, 10 Jul 1999 17:28:11 -0500 (CDT) Subject: [Mailman-Developers] Re: what is being checked? In-Reply-To: Message-ID: On Sat, 10 Jul 1999, Stephen Modena wrote: > Phil-- > > >From MindSpring, I change my "return address" inside of Eudora to > "shimshon@theporch.com". Then I sent a "who" request to test-request. > I succeeded in mailing the list of subscribers to shimshon@thePorch.com. > > I did the same thing giving "ab4el@MindSpring.com" and it explicitly > refused me because I am not a subscriber. That is yet another setting. I can set the list to show the subscription list to anyone, to list subscribers or only to the list admin. > > My suggestion is: these sort of things should require the "password=<>" on > the same line as the request. If I am a legitimate subscriber, I can > punch the HTML button to get my password mailed to me...it's not like I > have to keep it on a post and would be an inconvenient imposition to > require that parameter as part of the request. > I think it is the way it is to accomidate the different privacy settings. If I had set the list up where the subscribers were veiwable to anyone who had not set themselves as hidden, then it would not make sense to have the password. I would guess it would be relatively easy to check the list settings and if it was restricted, it would require a password. Again, I'll forward this to the mailman-developer list. > Now for a positive comment: I switch my password to a pass phrase and it > took it...and it can use it from the HTML page. I'm about to try it in an > email. > > -- > 73/Steve/AB4EL shimshon@thePorch.thePorch.com QTH: Raleigh, NC > -- Phillip P. Porch NIC:PP1573 finger for http://www.theporch.com UTM - 16 514548E 3994397N PGP key Key fingerprint = F9 4D 41 7D 25 31 A5 1F 65 93 6B 84 A9 F9 5B 90 From ricardo@miss-janet.com Sun Jul 11 22:01:47 1999 From: ricardo@miss-janet.com (Ricardo Kustner) Date: Sun, 11 Jul 1999 23:01:47 +0200 (CEST) Subject: [Mailman-Developers] rc3 check_perms : adm.pw ?? Message-ID: Hi, first of all thanks for adding a permission check script to the new mailman release! :) anyway, after upgrading to rc3, i immediately tried out the permission script just to see if it works... at the end it gives me an error cause it's looking for a ~mailman/data/adm.pw file... but that one doesn't exist anywhere in my mailman tree?? Traceback (innermost last): File "./check_perms", line 164, in ? checkadminpw() File "./check_perms", line 128, in checkadminpw mode = statmode(adminpw) File "./check_perms", line 39, in statmode return os.stat(path)[ST_MODE] OSError: [Errno 2] No such file or directory: '/usr/local/mailman/data/adm.pw' Ricardo. -- From root@theporch.com Mon Jul 12 01:00:56 1999 From: root@theporch.com (Phillip Porch) Date: Sun, 11 Jul 1999 19:00:56 -0500 (CDT) Subject: [Mailman-Developers] Feature Request Message-ID: My partner has been administering several lists here under listproc 8.2 and we have been considering moving to mailman as our list server. His main complaint is that he has been using the subscriber file to store extra information about subscribers under listproc but can't under mailman. How difficult would it be to add a freeform text field associated with an email name that would only be accessible to the list owner or site manager? -- Phillip P. Porch NIC:PP1573 finger for http://www.theporch.com UTM - 16 514548E 3994397N PGP key From Dionysos@Dionysia.org Mon Jul 12 04:56:37 1999 From: Dionysos@Dionysia.org (Dan Delaney) Date: Sun, 11 Jul 1999 23:56:37 -0400 (EDT) Subject: [Mailman-Developers] Fix for bug "incoming/64"--the prefix replication problem Message-ID: Hi all. I just transferred all of my majordomo lists over to Mailman and I must say, it is quite nice. There are a few things I'd like to see in the future, but they would just be icing on the cake. There is only one actual problem I've had. When someone replies to a message and his program prepends "Re: " to the subject, Mailman then adds a NEW list prefix to the subject line every time, even if there is already one somewhere in the subject line, so we end up with something like this: Subject: [MyList] Re: [MyList] Re: [MyList] A few observations After a while, the subject lines accumulate quite a few of those prefixes, which I think is a BIG problem. I was looking at the code in the MailList.py program, and it looks like the code only checks to see if the prefix is already present AT THE BEGINNING of the line before it adds the prefix, thus ignoring the fact that it might be there after a "Re: " or "Fwd: ". Here are the relevant lines from MailList.py: -------------------------------------------------------------------- 1267: # Prepend the subject_prefix to the subject line. 1268: subj = msg.getheader('subject') 1269: prefix = self.subject_prefix 1270: if not subj: 1271: msg.SetHeader('Subject', '%s(no subject)' % prefix) *1272: elif prefix and not re.match(re.escape(self.subject_prefix), *1273: subj, re.I): 1274: msg.SetHeader('Subject', '%s%s' % (prefix, subj)) -------------------------------------------------------------------- The simplest solution to this problem is to replace the "re.match" in line 1272 with "re.search". The difference between the two is that re.match only matches the pattern if it occurs at the BEGINNING of the line, whereas re.search will match the pattern anywhere in the line. I've already tried this in my installation and it works quite well. In this case, after someone sends a message with a subject something like this... Subject: [MyList] Hello there ...all of the following replies, no matter how many there are, will never add another [MyList] prefix because it is already present SOMEWHERE in the subject. Thus all subsequent replies will have the following as their subject: Subject: Re: [MyList] Hello there Now that would be sufficient to at least fix the problem of "subject prefix replication". However, I still am not satisfied with the result because now the prefix is not the FIRST thing in the subject. Being a graphic designer, I am particularly sensitive to the visual aspect of all of this, and to me it would be much more aesthetically pleasing to have the list name tags all lined up in my inbox list of messages, rather than some of them offset four places from the left edge. One way to get around this would be to use an "re.sub" method to actually strip out all occurances of the list tag in the subject line before adding another one to the beginning. That would be great except for one thing: that would lead to the build up of "Re: "s! After a while you would end up with: Subject: [MyList] Re: Re: RE: Re: Hello there So, what you have to do is remove all of the extra "Re: "s as well. Which brings me to another problem: "RE: and FWD: replication", which is a big problem with email in general (especially with all this damn chain-letter spam!). And since the email programs aren't doing their job by cleaning up that crapola, why not have the mailing list manager do it? I wrote a mailing list archive program a while back which does this and it really helps with "threading" the messages based on the subject lines. (In fact, I store the subject without ANY 'Re:'s or 'Fwd:'s so that the subjects will be exactly the same, and I save the fact that it is a reply in a separate field. You can check out the archive if you like at www.LouisvilleTimes.org/harmonet/). Anyway, this would make the following subject line... Subject: Re: [MyList] Re: Fwd: [MyList] Re: Hello there (fwd) ...end up looking like this: Subject: [MyList] Re: Hello there The result is that your list messages always have readable, comprehendable subjects that don't take 5 minutes to decode, AND your list archives are much more functional and easier to browse because messages which REALLY have the same subject won't be bogged down with 'Re:'s and 'Fwd:'s. This is the basic procedure: 1. First, with a regex substitution, strip the subject line of all occurances of the list's subject prefix. 2. Then, using a case-insensitive regex, check to see if the subject BEGINS with "fw: " or "fwd: ", or if it ends with a "(fwd)". If so, set a second prefix variable (prefix2) to "Fwd: " to be added after the first prefix (the one from the list). 3. Next, check to see if the subject line begins with an "re: ". If it does, this takes precedence over the "Fwd: ", so just go ahead and set prefix2 to "Re: " even if it already contains "Fwd: " 4. Next, with a case-insensitive regex substitution, remove ALL instances of "re: ", "fw: ", "fwd: ", and "(fwd)" from the subject. 5. Finally, add both the list prefix and the new prefix2 to the beginning of the subject. So, here's a replacement for the segment of code that I quoted earlier from the MailList.py program which accomplishes this task quite well (I'm using it in my Mailman installation right now): -------------------------------------------------------------------- # Prepend the subject_prefix to the subject line. subj = msg.getheader('subject') prefix = self.subject_prefix # If there's no subject, give it one if not subj: msg.SetHeader('Subject', '%s(no subject)' % prefix) else: # Delete all occurances of the prefix from the subject if prefix: subj = re.sub(re.escape(self.subject_prefix), '', subj) # Check to see if the message is a reply or forward prefix2 = '' if re.search('^fwd*: |\(fwd\)', subj, re.I): prefix2 = 'Fwd: ' if re.match('re: ', subj, re.I): prefix2 = 'Re: ' # Clean up all that 're:' and 'fwd: ' garbage subj = re.sub('[rR][eE]: | *\(*[fF][wW][dD]*\)*:* *', '', subj) # Set the new subject line in place msg.SetHeader('Subject', '%s%s%s' % (prefix, prefix2, subj)) -------------------------------------------------------------------- Give it a try for a while on your own mailing lists. I think you'll like the results. Cheers. -- Dan ________________________________________________________________________ Dionysos@Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html From Dionysos@Dionysia.org Mon Jul 12 16:12:34 1999 From: Dionysos@Dionysia.org (Dan Delaney) Date: Mon, 12 Jul 1999 11:12:34 -0400 Subject: [Mailman-Developers] Documentation for config.db file? Message-ID: Is there any documentation for the format of the config.db file? Here's my situation. I've written a large database system for the membership information of an organization. Each member of the organization can login to the website with a password and edit his or her own member information (address, bio, password, etc). When a member makes a change to his email address, or when I add a new member, the program automatically makes a change to the majordomo list file, which is simply a text file with the email addresses in it. Well, now that I've switched the list to Mailman, I can no longer do this because I don't know how Mailman stores the subscriber info. I can easily modify a db file with PHP, I just need to know how the info in laid out in the file. Thanks. --Dan ________________________________________________________________________ Dionysos@Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Mon Jul 12 16:35:04 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 12 Jul 1999 11:35:04 -0400 (EDT) Subject: [Mailman-Developers] Feature Request References: Message-ID: <14218.2856.81492.482042@anthem.cnri.reston.va.us> >>>>> "PP" == Phillip Porch writes: PP> My partner has been administering several lists here under PP> listproc 8.2 and we have been considering moving to mailman as PP> our list server. His main complaint is that he has been using PP> the subscriber file to store extra information about PP> subscribers under listproc but can't under mailman. How PP> difficult would it be to add a freeform text field associated PP> with an email name that would only be accessible to the list PP> owner or site manager? Since the data structure that list information gets stored into is just a dictionary (glommed from attributes on the class), you could probably store all kinds of extra information in there. The trick would be hooking it up to the Web interface, but if that's not important, you can do all kinds of things by hacking a little Python into a command line script. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Mon Jul 12 16:52:41 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 12 Jul 1999 11:52:41 -0400 (EDT) Subject: [Mailman-Developers] Fix for bug "incoming/64"--the prefix replication problem References: Message-ID: <14218.3913.166102.299860@anthem.cnri.reston.va.us> >>>>> "DD" == Dan Delaney writes: DD> The simplest solution to this problem is to replace the DD> "re.match" in line 1272 with "re.search". Harald already made this change for 1.0rc3. The rest sounds interesting, but I probably it'll definitely have to wait until after 1.0 final. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Mon Jul 12 17:36:35 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 12 Jul 1999 12:36:35 -0400 (EDT) Subject: [Mailman-Developers] Documentation for config.db file? References: Message-ID: <14218.6547.205838.638118@anthem.cnri.reston.va.us> >>>>> "DD" == Dan Delaney writes: DD> Is there any documentation for the format of the config.db DD> file? It is a Python marshal containing a Python dictionary. The keys are taken from the attributes on the MailList object. Only the attributes which don't start with a leading underscore are saved. DD> Here's my situation. I've written a large database system for DD> the membership information of an organization. Each member of DD> the organization can login to the website with a password and DD> edit his or her own member information (address, bio, DD> password, etc). When a member makes a change to his email DD> address, or when I add a new member, the program automatically DD> makes a change to the majordomo list file, which is simply a DD> text file with the email addresses in it. Well, now that I've DD> switched the list to Mailman, I can no longer do this because DD> I don't know how Mailman stores the subscriber info. I can DD> easily modify a db file with PHP, I just need to know how the DD> info in laid out in the file. We do something very similar with the PSA membership. We use bin/sync_members to automate synchronizing the mailing list with our PSA members database, but depending on the information you've got, it's possible that bin/add_members or bin/remove_members might be more appropriate. If not fit your bill exactly, remember that this stuff is very easy to code in Python. Take a look at the three scripts above for examples. -Barry From Nigel.Metheringham@vdata.co.uk Tue Jul 13 18:05:12 1999 From: Nigel.Metheringham@vdata.co.uk (Nigel Metheringham) Date: Tue, 13 Jul 1999 18:05:12 +0100 Subject: [Mailman-Developers] Further on jitterbug open/75 - timezone handling in archiver Message-ID: [Note: there is no way for me as a bug reporter to make a follow up note into the bug report - ie I have fixed/worked round this for myself but am having to put it to the list since I can't add a comment to the bug report...] The problem was that I was seeing a wierd time skew on my archives dating back to the point where DST kicked in (suspicious eh). Basically I had 2 archives for each week - one with the correct date on - ie Monday 12 July and the other with just one or two messages with a duff date on - specifically in this example it would be Monday 13 July The code in HyperArch.py has:- def dateToVolName(self,date): datetuple=time.gmtime(date) It appears the later call to strftime is applying its own localtime rules. This may be a libc oddity - I am not good enough on POSIX to know that. If you change the gmtime call to a localtime then it all works correctly. For the record this is on a Red Hat 6.0 system - so Python 1.5.1, glibc 2.1. This fix will have side effects that your archive roll over changes with the server localtime rather than GMT - I don't know if this is a problem for people. Nigel. -- [ Nigel Metheringham Nigel.Metheringham@VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] From da@ski.org Thu Jul 15 05:42:08 1999 From: da@ski.org (David Ascher) Date: Wed, 14 Jul 1999 21:42:08 -0700 (Pacific Daylight Time) Subject: [Mailman-Developers] mailman & unsubs Message-ID: I subscribe to lots of mailman lists. Sometimes, mailman disables my email address. I have no doubt that it's for a good reason. However, that reason is for a certain group of users fairly temporary (down server). As it stands, I periodically find out that I've been disabled on fairly quiet lists that I don't expect to read every day. It'd be nice if mailman could 'ping' the email address periodically (once a week?) to find out if the problem is resolved. Something progressively more expensive like if ping_ok and SMTP_VRFY_ok and first_email_goes_in_queue_goes_through: undisable_email() would do the job in 96% of the cases w/ low overhead, I suspect. --david From lannert@uni-duesseldorf.de Thu Jul 15 08:44:33 1999 From: lannert@uni-duesseldorf.de (lannert@uni-duesseldorf.de) Date: Thu, 15 Jul 1999 09:44:33 +0200 (MEST) Subject: [Mailman-Developers] mailman & unsubs In-Reply-To: from David Ascher at "Jul 14, 99 09:42:08 pm" Message-ID: <19990715074433.14286.qmail@lannert.rz.uni-duesseldorf.de> "David Ascher" wrote: > if ping_ok and SMTP_VRFY_ok and first_email_goes_in_queue_goes_through: > undisable_email() > > would do the job in 96% of the cases w/ low overhead, I suspect. There are quite a few MTAs that don't perform VRFY, either because they are configured like this or because they can't do it at all (e.g. qmail). Maybe "(SMTP_VRFY_ok or SMTP_VRFY_rej_252)" would do an even better job. Detlef From evaldas.auryla@pheur.org Thu Jul 15 14:11:18 1999 From: evaldas.auryla@pheur.org (Evaldas Auryla) Date: Thu, 15 Jul 1999 15:11:18 +0200 Subject: [Mailman-Developers] Cookies and MSIE 4.x Message-ID: <378DDDF6.7D6F3ACF@pheur.org> Hello! It seems like MS Internet Explorer 4.x (except 4.7x for NT) is not following RFC 2109 and storing cookies sent by Mailman _without_ dbl.quotes "". Mailman fails verifying these cookies, because Cookie.py module thinks the incoming cookie does not contain any special chars (not true) as it is _not_ enclosed with dbl.quotes so decoding goes wrong. The consequence is that for the administration of the Mailman over the web you have to re-enter password to authenticate on every page. Annoying. I made a little patch to SecurityManager.py to get around this problem, experienced in Mailman 1.0rc2 and 1.0rc3, (for the Mailman in fact it's a feature, not a bug :-)) and submitted it to the JitterBug database http://www.python.org/mailman-bugs/ . Does anybody had something similar ? Regards -- Evaldas From jc@jonathanclark.com Thu Jul 15 21:52:49 1999 From: jc@jonathanclark.com (Jonathan Clark) Date: Thu, 15 Jul 1999 13:52:49 -0700 Subject: [Mailman-Developers] spam control Message-ID: <000801becf04$02f19c40$0202a8c0@jitit.com> This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BECEC9.536D8F70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi guys, I just tried out mailman for the first time and I like it a = lot. I noticed there is some attempt to stop spam crawlers. However, some of the email addresses displayed (like the list owner) are shown in the clear. Here is a little trick I use to allow mailto: to work correctly = and at the same time stop spam crawlers from gathering email addresses. Email: jc at jonathanclark.com When this is displayed on a browser that has java script turned off, it will only display: "Email: jc at jonathanclark.com" When the end user has javascript on (as most people do), they will see the same thing, but when they click on it they will get the correct mailto: command to launch their mail program. Since crawlers don't execute javascript, they can't collect the name. Generally I don't worry about non java script but I recently turned it off because of those annoying (open-another-window-on-close) tricks people do. I think it would be great if mailman used (or had the option) to use this technique for all email addresses it displayed. Jonathan P.S. I'm not on the list, so cc: me any discussion on this. Thanks! ------=_NextPart_000_0005_01BECEC9.536D8F70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi guys,  I just tried out mailman = for the=20 first time and I like it a lot.
I noticed there is some attempt = to stop spam=20 crawlers.  However, some
of the email addresses displayed (like = the list=20 owner) are shown in the
clear.   Here is a little = trick I use to=20 allow mailto: to work correctly and
at the same time stop spam crawlers = from gathering=20 email addresses.
 
Email: <script=20 language=3D"JavaScript"><!--
document.write("<a=20 href=3Dmai");
document.write("lto:","jc","@","jonathanclark",".com>= ");
//=20 --></script>
jc at jonathanclark.com
<script=20 language=3D"JavaScript"><!--
document.write("</a>");
//= =20 --></script>
 
When this is displayed on a browser = that has java=20 script turned off,
it will only display:   = "Email: jc at=20 jonathanclark.com"
When the end user has javascript on (as = most people=20 do), they
will see the same thing, but when they = click on it=20 they will get
the correct mailto: command to launch = their mail=20 program.
Since crawlers don't execute = javascript, they can't=20 collect the
name.  Generally I don't worry = about non java=20 script but I recently
turned it off because of those annoying = (open-another-window-on-close)
tricks people do.
 
I think it would be great if mailman = used (or had=20 the option)
to use this technique for all email = addresses it=20 displayed.
 
 
Jonathan
 
P.S. I'm not on the list, so cc: me any = discussion=20 on this.  Thanks!
------=_NextPart_000_0005_01BECEC9.536D8F70-- From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Jul 16 20:57:08 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 16 Jul 1999 15:57:08 -0400 (EDT) Subject: [Mailman-Developers] FW: Returned mail: unknown mailer error 1 References: <004801bec8a3$871cf940$1e0a5ad1@SINGSING.STREEK.COM> Message-ID: <14223.36500.291673.766679@anthem.cnri.reston.va.us> >>>>> "JH" == Jeff Hahn writes: JH> A mail message with the following To: line generated this JH> error... JH> "To: :" JH> (The following message has been "somewhat" sanitized) This is actually a bug in rfc822.py! It has been fixed in Python's CVS tree, and I copied the latest rfc822.py to Mailman/pythonlib, so it'll be fixed in 1.0 final. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Jul 16 21:05:49 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 16 Jul 1999 16:05:49 -0400 (EDT) Subject: [Mailman-Developers] Re: Mailman-Developers digest References: <199907020500.BAA28872@python.org> <37811DAC.5CAA465F@unternehmen.com> Message-ID: <14223.37021.88265.917569@anthem.cnri.reston.va.us> >>>>> "HH" == Helge Hielscher writes: HH> Some days ago I joined the list and I wonder why the HH> Mailman-Users list´s digest is in MIME but not the developer HH> digest where the mails are only seperated with HH> --__--__-- HH> which makes it harder to read. Who can/may change that HH> behavior? Check your subscription options. You can change your personal options to deliver either plain text or MIME, with IIRC plain text as the default. HH> BTW are HTML Index Digests implemented in Mailman? Not sure what you mean, but IMHO HTML in email is evil! :) But perhaps I misunderstand what you're asking for? -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sun Jul 18 21:10:46 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sun, 18 Jul 1999 16:10:46 -0400 (EDT) Subject: [Mailman-Developers] mailman & unsubs References: Message-ID: <14226.13510.670256.292606@anthem.cnri.reston.va.us> >>>>> "DA" == David Ascher writes: DA> Sometimes, mailman disables my email address. I have no doubt DA> that it's for a good reason. However, that reason is for a DA> certain group of users fairly temporary (down server). As it DA> stands, I periodically find out that I've been disabled on DA> fairly quiet lists that I don't expect to read every day. DA> It'd be nice if mailman could 'ping' the email address DA> periodically (once a week?) to find out if the problem is DA> resolved. You haven't read our TODO list have ya? :) Okay, it's buried in there (it's a biiiig todo list!): *Bounce handling - Reminders to disabled addresses. The idea is that if an addr is disabled due to bouncing, we should send out periodic reminders. We may want to do this for explicitly disabled addrs too, but perhaps with a different schedule. -Barry From Harald.Meland@usit.uio.no Mon Jul 19 16:36:49 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 19 Jul 1999 17:36:49 +0200 Subject: [Mailman-Developers] patch candidate for MailList.Save() In-Reply-To: "Barry A. Warsaw"'s message of "Wed, 30 Jun 1999 12:56:14 -0400 (EDT)" References: <14202.19502.341621.221263@anthem.cnri.reston.va.us> Message-ID: [Barry A. Warsaw] > The idea is that the marshal is first written to a temp file called > config.db.tmp.. If this succeeds completely, then > > 1) config.db.last is unlinked > 2) a hard link config.db.last -> config.db is created > 3) a hard link config.db -> config.db.tmp. is created > 4) config.db.tmp. is unlinked > > Comments? You missed 2.5) config.db is removed which constitutes a race condition -- I think the below patch fixes that (but as you say, this really is crucial code to get right, so I'm posting it here for others to comment before committing): Index: MailList.py =================================================================== RCS file: /export/public/cvsroot/mailman/Mailman/MailList.py,v retrieving revision 1.130 diff -u -r1.130 MailList.py --- MailList.py 1999/07/18 17:26:55 1.130 +++ MailList.py 1999/07/19 15:09:08 @@ -759,6 +759,8 @@ fname = os.path.join(self._full_path, 'config.db') fname_tmp = fname + '.tmp.' + `os.getpid()` fname_last = fname + ".last" + # Make config.db unreadable by `other', as it contains all the + # list members' passwords (in clear text). omask = os.umask(007) try: try: @@ -771,10 +773,14 @@ 'Failed config.db file write, retaining old state' '\n %s' % `status.args`) Utils.reraise() - # now move config.db -> config.db.last - # then move config.db.tmp.xxx -> config.db - aside_new(fname, fname_last) - aside_new(fname_tmp, fname) + # Now do config.db.tmp.xxx -> config.db -> config.db.last + # rotation -- safely. + if os.path.exists(fname_last): + os.unlink(fname_last) + os.link(fname, fname_last) + os.rename(fname_tmp, fname) +## aside_new(fname, fname_last) +## aside_new(fname_tmp, fname) finally: os.umask(omask) self.CheckHTMLArchiveDir() After this change, the function aside_new() in MailList.py can be removed (or moved to Utils.py), as it isn't being used anywhere else. -- Harald From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Mon Jul 19 23:30:17 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 19 Jul 1999 18:30:17 -0400 (EDT) Subject: [Mailman-Developers] patch candidate for MailList.Save() References: <14202.19502.341621.221263@anthem.cnri.reston.va.us> Message-ID: <14227.42745.327704.776954@anthem.cnri.reston.va.us> >>>>> "HM" == Harald Meland writes: HM> You missed HM> 2.5) config.db is removed HM> which constitutes a race condition -- I think the below patch HM> fixes that (but as you say, this really is crucial code to get HM> right, so I'm posting it here for others to comment before HM> committing): Arg! You're right of course. Here's a slightly reworked version of your patch. Also, not committed yet, but seems to work for me. -Barry -------------------- snip snip -------------------- Index: MailList.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/MailList.py,v retrieving revision 1.130 diff -c -r1.130 MailList.py *** MailList.py 1999/07/18 17:26:55 1.130 --- MailList.py 1999/07/19 22:22:56 *************** *** 26,31 **** --- 26,32 ---- 'for the site?') import sys, os, marshal, string, posixfile, time + import errno import re import Utils import Errors *************** *** 759,764 **** --- 760,767 ---- fname = os.path.join(self._full_path, 'config.db') fname_tmp = fname + '.tmp.' + `os.getpid()` fname_last = fname + ".last" + # Make config.db unreadable by `other', as it contains all the + # list members' passwords (in clear text). omask = os.umask(007) try: try: *************** *** 771,780 **** 'Failed config.db file write, retaining old state' '\n %s' % `status.args`) Utils.reraise() ! # now move config.db -> config.db.last ! # then move config.db.tmp.xxx -> config.db ! aside_new(fname, fname_last) ! aside_new(fname_tmp, fname) finally: os.umask(omask) self.CheckHTMLArchiveDir() --- 774,789 ---- 'Failed config.db file write, retaining old state' '\n %s' % `status.args`) Utils.reraise() ! # Now do config.db.tmp.xxx -> config.db -> config.db.last ! # rotation -- safely. ! try: ! # might not exist yet ! os.unlink(fname_last) ! except os.error, (code, msg): ! if code <> errno.ENOENT: ! Utils.reraise() ! os.link(fname, fname_last) ! os.rename(fname_tmp, fname) finally: os.umask(omask) self.CheckHTMLArchiveDir() *************** *** 1376,1397 **** return ("<%s.%s %s%s at %s>" % (self.__module__, self.__class__.__name__, `self._internal_name`, status, hex(id(self))[2:])) - - def aside_new(old_name, new_name, reopen=0): - """Utility to move aside a file, optionally returning a fresh open version. - - We ensure maintanance of proper umask in the process.""" - # Make config.db unreadable by `other', as it contains all the list - # members' passwords (in clear text). - ou = os.umask(007) - try: - if os.path.exists(new_name): - os.unlink(new_name) - if os.path.exists(old_name): - os.link(old_name, new_name) - os.unlink(old_name) - if reopen: - file = open(old_name, 'w') - return file - finally: - os.umask(ou) --- 1385,1387 ---- From marc@merlins.org Tue Jul 20 23:42:28 1999 From: marc@merlins.org (Marc Merlin) Date: Tue, 20 Jul 1999 15:42:28 -0700 Subject: [Mailman-Developers] Mailman v 1.0rc1 Message-ID: <19990720154227.A6911@marc.merlins.org> First off, I didn't install it, nor do I have access to it, so I can't really give more information than what's in this mail unfortunately. However if the bug hasn't been found and fixed yet, this report should be enough to find it. I had a user that was sending mail with the following in the "From: " field: Jason T. Collins Mailman would send mail back to jasont.collins@valinux.com and say the person wasn't subscribed. The problem went away when I had him remove the "." after the T in his name. My guess is that some regular expression in mailman is being fooled by the "." Marc -- Microsoft is to software what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ (friendly to non IE browsers) Finger marc_f@merlins.org for PGP key and other contact information From hhielscher@unternehmen.com Tue Jul 20 01:46:37 1999 From: hhielscher@unternehmen.com (Helge Hielscher) Date: Tue, 20 Jul 1999 02:46:37 +0200 Subject: [Mailman-Developers] html index References: <199907020500.BAA28872@python.org> <37811DAC.5CAA465F@unternehmen.com> <14223.37021.88265.917569@anthem.cnri.reston.va.us> Message-ID: <3793C6EC.9B581BBB@unternehmen.com> Hello Barry, you were right, the MIME feature was switched off. So hopefully the next digest will be in MIME. To the html index: it is only an index in the mail you see first like:
  • A doubt on scalability.... (2)
  • AW: Multiple servlets and a shared class (2)
  • REDHAT 5.2 / Apache / JServ you click and get here
  • A doubt on scalability....
  • AW: Multiple servlets and a shared class
  • REDHAT 5.2 / Apache / JServ later with links to the mails itself like you get here: Content-ID: <13761@JAVA.SUN.COM> Content-Type: message/rfc822 Date: Thu, 15 Jul 1999 01:04:08 -0700 From: Hans Bergsten Subject: Re: A doubt on scalability.... MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit and so on. That I think makes it very comfortable to read some but not all mails. I am not sure if you can/should create a thread list like when reading news in HTML? Listserv only sorts after Name of the Thread and the Time I think. Regards, Helge From Harald.Meland@usit.uio.no Wed Jul 21 07:03:28 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 21 Jul 1999 08:03:28 +0200 Subject: [Mailman-Developers] Various In-Reply-To: Per Starback's message of "11 Jun 1999 15:33:07 +0200" References: Message-ID: [Per Starback] > * Privacy Options > I don't like the combined meanings of the fields A = "Restrict posting > privilege to list members?" and B = "Addresses of members accepted for > posting to this list without implicit approval requirement". [...] > Perhaps it would be better if A had three possible values: > Noone, Members only, Anyone. And then B always is a list of > *additional* addresses besides what option A states? Yup, I agree that a three-state switch might be more intuitive -- but I'm hoping we'll find some even more general "posting access control" configuration setting -- i.e. one might want to restrict postings to members and addresses in the example.com domain, or everyone but addresses in badboys.net, or even only addresses with a localpart matching "\w+\.\w+". Either way, I don't see this changing before 1.0. > * Digest-member options > > "Header added to every digest" is empty as the default value. > I would prefer if the whole > > Send xxx maillist submissions to [...] > When replying, please [...] > "Re: Contents of xxx digest...") > > blurb was there instead, so all of that could be edited. Noted. > * List-specific programs > > Something I'm missing from Smartlist which I have been using since > before is the possibility there of adjusting everything for a > particular list by making a special version of the list programs for > that list. In this way it would great if I could just put a changed > Digester.pyc (for example) in the directory for a particular list to > have that list use that one instead of the default one. > > This wouldn't be needed for most lists, or course, but still such a > minor(?) change would make it *possible* to do almost anything, > including stuff that there probably will be support for in the future > but that someone could need to fix "by hand" for one particular list > right now, and specialized stuff for which there never will be > generalized support. I don't think this would be a smart move -- it could potentially cause _serious_ troubles when the list-specific files (e.g. old, installed by some previous site-admin which is now long gone) assumes interfaces that the Mailman distribution (which we'd like people to be able to upgrade from time to time without too much trouble) are trying to move away from. -- Harald From Harald.Meland@usit.uio.no Wed Jul 21 08:47:42 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 21 Jul 1999 09:47:42 +0200 Subject: [Mailman-Developers] cookie problem ? In-Reply-To: Gergely Madarasz's message of "Mon, 5 Jul 1999 17:25:01 +0200 (METDST)" References: Message-ID: [Gergely Madarasz] > Hello, > > If I want to access the mailman pages thru a different url (like > http://somehost/cgi-bin/mailman/, the cgi-bin directory has a > symlink to mailman/cgi-bin) the cookie authentication is > problematic. Yup -- we wouldn't want browsers to send out Mailman cookies unless they actually are getting a Mailman page. Thus, the "path" setting of the Mailman-issued cookies are set to whatever the path part of mm_cfg.DEFAULT_URL is (i.e. normally "/mailman"). This means that Mailman cookies won't be sent to the server if you access the Mailman interface via some other CGI-script path. > It allows access for the first time but after that it wants > authentication again. Actually it is the password you send that gets you through the first time, and not any cookie. > Could this be fixed somehow ? I don't think we want to try being clever with any of the CGI environment variables for figuring out what URLs the cookies should be sent out for. > This way there wouldn't be need to configure the webserver to use > the /mailman/ alias. If you don't want to add the /mailman/ ScriptAlias (or whatever) to your web server configuration, Mailman's setting of mm_cfg.DEFAULT_URL should reflect this. This means that if you access all your Mailman CGI wrappers as e.g. , you should set DEFAULT_URL = "http://mailman-host/cgi-bin" in $prefix/Mailman/mm_cfg.py. Mailman cookies will then be sent out to any script in this cgi-bin directory. If you use both .../cgi-bin/wrappername and .../mailman/wrappername type URLs interchangeably, the cookies won't work for (at least) one of those -- so, you *shouldn't* use both types of URLs interchangeably. -- Harald From Harald.Meland@usit.uio.no Wed Jul 21 09:13:49 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 21 Jul 1999 10:13:49 +0200 Subject: [Mailman-Developers] Re: what is being checked? In-Reply-To: Phillip Porch's message of "Sat, 10 Jul 1999 17:28:11 -0500 (CDT)" References: Message-ID: [Phillip Porch] > > My suggestion is: these sort of things should require the "password=<>" on > > the same line as the request. If I am a legitimate subscriber, I can > > punch the HTML button to get my password mailed to me...it's not like I > > have to keep it on a post and would be an inconvenient imposition to > > require that parameter as part of the request. > > I think it is the way it is to accomidate the different privacy > settings. I'm not sure of the exact context here, but yes, different private_roster settings will give different results for the "who" mail command. * If "private_roster" is set to "List admin only", the "who" mail command will tell you "Private list: No one may see subscription list." * If set to "List members", it wil tell you "Private list: only members may see list of subscribers." unless the request sender address is a list member. This is the same algorithm that is used for deciding whether or not the "password" command with no arguments should mail back the member password or not -- so requiring a password to the "who" command in this case would just mean extra hassle, and not extra security. * If set to "Anyone", the roster will be mailed back without forther checking. In all cases only non-hidden member addresses are included in the roster. This all mimics the information available via the web interface closely. Does that answer the questions you have? -- Harald From Harald.Meland@usit.uio.no Wed Jul 21 10:02:43 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 21 Jul 1999 11:02:43 +0200 Subject: [Mailman-Developers] Fix for bug "incoming/64"--the prefix replication problem In-Reply-To: Dan Delaney's message of "Sun, 11 Jul 1999 23:56:37 -0400 (EDT)" References: Message-ID: [Dan Delaney] > Anyway, this would make the following subject line... > > Subject: Re: [MyList] Re: Fwd: [MyList] Re: Hello there (fwd) > > ...end up looking like this: > > Subject: [MyList] Re: Hello there So, if I send a mail with subject Subject: Administrivia: [foo] will be changed to [bar] Mailman should change it to Subject: [foo] Administrivia: will be changed to [bar] ? I don't think messing with the subject prefix to that extent is a good idea. Regarding stripping of consecutive "Re:" and "Fwd:" strings -- you'd still have problems with the nationalized versions of these ("SV:", "AD:", etc.) that some MUA vendors in their infinite wisdom have implemented, and besides this too have potential problems with stripping away substrings that really was meant to stay where they where. > The result is that your list messages always have readable, > comprehendable subjects that don't take 5 minutes to decode, AND > your list archives are much more functional and easier to browse > because messages which REALLY have the same subject won't be bogged > down with 'Re:'s and 'Fwd:'s. I think this "problem" should be solved in the user's MUA configuration (if the user wants the subjects mangled) and/or in the archiver thread generator. The archiver thread generator could be made to display sender address for all messages in the thread, but only display the subject at the top of the thread and every time the subject changes _substantially_. Non-substantial subject changes could e.g. be defined as changes which only include addition or removal of "Re:", "Fwd:" and instances of the subject prefix. The _real_ subjects, looking just the way they were sent (modulo subject prefix), would be available in the archive of each particular message. Example: Instead of having the archive thread view look like this: * [Mailman-Developers] foobar gazonk -- Harald Meland Re: [Mailman-Developers] foobar gazonk -- Barry A. Warsaw Re: [Mailman-Developers] florp -- Harald Meland it could look like this: * Harald Meland -- [Mailman-Developers] foobar gazonk Barry A. Warsaw Harald Meland -- [Mailman-Developers] florp (though I admit that it isn't entirely intuitive that "Barry A. Warsaw" is a link to an archived message and not a mailto: URL in this context.) -- Harald From root@theporch.com Wed Jul 21 11:40:15 1999 From: root@theporch.com (Phillip Porch) Date: Wed, 21 Jul 1999 05:40:15 -0500 (CDT) Subject: [Mailman-Developers] Re: what is being checked? In-Reply-To: Message-ID: On 21 Jul 1999, Harald Meland wrote: > Date: 21 Jul 1999 10:13:49 +0200 > From: Harald Meland > To: Phillip Porch > Cc: Stephen Modena , test-admin@theporch.com, mailman-developers@python.org > Subject: Re: [Mailman-Developers] Re: what is being checked? > > [Phillip Porch] > > > > My suggestion is: these sort of things should require the "password=<>" on > > > the same line as the request. If I am a legitimate subscriber, I can > > > punch the HTML button to get my password mailed to me...it's not like I > > > have to keep it on a post and would be an inconvenient imposition to > > > require that parameter as part of the request. > > > > I think it is the way it is to accomidate the different privacy > > settings. > > I'm not sure of the exact context here, but yes, different > private_roster settings will give different results for the "who" mail > command. > > * If "private_roster" is set to "List admin only", the "who" mail > command will tell you "Private list: No one may see subscription > list." > > * If set to "List members", it wil tell you "Private list: only > members may see list of subscribers." unless the request sender > address is a list member. This is the same algorithm that is used > for deciding whether or not the "password" command with no > arguments should mail back the member password or not -- so > requiring a password to the "who" command in this case would just > mean extra hassle, and not extra security. > > * If set to "Anyone", the roster will be mailed back without forther > checking. > > In all cases only non-hidden member addresses are included in the > roster. > > This all mimics the information available via the web interface > closely. > > Does that answer the questions you have? > It does for me. How about you Steve? -- Phillip P. Porch NIC:PP1573 finger for http://www.theporch.com UTM - 16 514548E 3994397N PGP key From gorgo@caesar.elte.hu Wed Jul 21 11:54:38 1999 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Wed, 21 Jul 1999 12:54:38 +0200 (METDST) Subject: [Mailman-Developers] cookie problem ? In-Reply-To: Message-ID: On 21 Jul 1999, Harald Meland wrote: > [Gergely Madarasz] > > > Hello, > > > > If I want to access the mailman pages thru a different url (like > > http://somehost/cgi-bin/mailman/, the cgi-bin directory has a > > symlink to mailman/cgi-bin) the cookie authentication is > > problematic. > > Yup -- we wouldn't want browsers to send out Mailman cookies unless > they actually are getting a Mailman page. Thus, the "path" setting of > the Mailman-issued cookies are set to whatever the path part of > mm_cfg.DEFAULT_URL is (i.e. normally "/mailman"). Ah, thanks, it actually works. Btw I thought it should be enough to set the base url in the general options section. -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From Harald.Meland@usit.uio.no Thu Jul 22 08:33:35 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 22 Jul 1999 09:33:35 +0200 Subject: [Mailman-Developers] cookie problem ? In-Reply-To: Gergely Madarasz's message of "Wed, 21 Jul 1999 12:54:38 +0200 (METDST)" References: Message-ID: [Gergely Madarasz] > Btw I thought it should be enough to set the base url in the general > options section. Oops... you're right, the cookie's path should be based on the URL path[1] of self.web_page_url instead of the global default mm_cfg.DEFAULT_URL. Here's a quick patch to do this: Index: SecurityManager.py =================================================================== RCS file: /export/public/cvsroot/mailman/Mailman/SecurityManager.py,v retrieving revision 1.21 diff -u -r1.21 SecurityManager.py --- SecurityManager.py 1999/07/16 22:40:28 1.21 +++ SecurityManager.py 1999/07/22 07:27:15 @@ -95,7 +95,7 @@ c = Cookie.Cookie() c[key] = [client_ip, issued, expires, mac] # place in oven, - path = urlparse(mm_cfg.DEFAULT_URL)[2] # '/mailman' + path = urlparse(self.web_page_url)[2] # '/mailman' c[key]['path'] = path # and bake until golden brown c[key]['expires'] = mm_cfg.ADMIN_COOKIE_LIFE [1] I don't know what else to call the part of an URL with proto://hostname stripped off the front, and anything from "?" and to the end of the string removed as well. -- Harald From johnr@eecs.berkeley.edu Fri Jul 23 01:49:42 1999 From: johnr@eecs.berkeley.edu (John Reekie) Date: Thu, 22 Jul 1999 17:49:42 -0700 Subject: [Mailman-Developers] Creating lists through cgi? In-Reply-To: <3793C6EC.9B581BBB@unternehmen.com> Message-ID: <001301bed4a5$446eb170$683e2080@bean.eecs.berkeley.edu> I was wondering... are there any plans to make it possible to create mail lists through the Web/CGI interface? (Needed for a "community" site.) JohnR From m.d.t.evans@qmw.ac.uk Fri Jul 23 16:22:31 1999 From: m.d.t.evans@qmw.ac.uk (Martin Evans) Date: Fri, 23 Jul 1999 16:22:31 +0100 Subject: [Mailman-Developers] subscribe problem. and search timescale. Message-ID: <379888B7.6E250A9B@qmw.ac.uk> Hello all, I may be wrong but I think I've managed st subscribe someone with an invalid email address to my test list. I subscribed 'asd@asd.qw.sd.' as a digest member. Mailman claims to send off a confirm message but then subscribes him to the list anyway. Im using version 1.00rc1. Is this a known bug, or has it been fixed in a later release? which brings me on to my second question... I see in the TODO list that an archive search engine is planned... is there any timescale for a release even a simple grep string type interface would be extremely useful? Cheers, martin. -- --- M.D.T.Evans - Computing Services - Queen Mary & Westfield College --- From brown9@niehs.nih.gov Fri Jul 23 19:34:21 1999 From: brown9@niehs.nih.gov (Lance A. Brown) Date: Fri, 23 Jul 1999 14:34:21 -0400 Subject: [Mailman-Developers] Missing vnsprintf on Compaq Tru64 Unix Message-ID: <10110.932754861@niehs.nih.gov> Greetings, I'm trying to install mailman 1.0rc3 on a Compaq Alpha 2100 running Tru64 V4.0D but am missing the vnsprintf call when linking the cgi-wrapper. I'm using gcc 2.8.1 to compile it. Is the code for this function available someplace? --[Lance] From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Jul 23 21:03:55 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 23 Jul 1999 16:03:55 -0400 (EDT) Subject: [Mailman-Developers] Missing vnsprintf on Compaq Tru64 Unix References: <10110.932754861@niehs.nih.gov> Message-ID: <14232.51883.510919.167758@anthem.cnri.reston.va.us> >>>>> "LAB" == Lance A Brown writes: LAB> Greetings, LAB> I'm trying to install mailman 1.0rc3 on a Compaq Alpha 2100 LAB> running Tru64 V4.0D but am missing the vnsprintf call when LAB> linking the cgi-wrapper. I'm using gcc 2.8.1 to compile it. LAB> Is the code for this function available someplace? Yes. You can grab it from the CVS repository: http://www.python.org/mailman/listinfo/mailman-checkins Please let me know how it goes. I haven't gotten much feedback on our workaround. -Barry From John@list.org Sun Jul 25 19:40:58 1999 From: John@list.org (John Viega) Date: Sun, 25 Jul 1999 11:40:58 -0700 Subject: [Mailman-Developers] Creating lists through cgi? In-Reply-To: <001301bed4a5$446eb170$683e2080@bean.eecs.berkeley.edu>; from John Reekie on Thu, Jul 22, 1999 at 05:49:42PM -0700 References: <3793C6EC.9B581BBB@unternehmen.com> <001301bed4a5$446eb170$683e2080@bean.eecs.berkeley.edu> Message-ID: <19990725114058.H2366@viega.org> Well, it's always been on the radar screen, but no one has gotten around to it yet. That part wouldn't be such a big deal, but the whole site admin UI we'd like to see would take quite a bit of work. If you have the time and inclination to hack something together to make this possible, please post a patch here. John On Thu, Jul 22, 1999 at 05:49:42PM -0700, John Reekie wrote: > I was wondering... are there any plans to make it possible > to create mail lists through the Web/CGI interface? (Needed > for a "community" site.) > > JohnR > > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From widmaster@yahoo.com Mon Jul 26 17:21:17 1999 From: widmaster@yahoo.com (Romain GRIFFITHS) Date: Mon, 26 Jul 1999 12:21:17 -0400 (EDT) Subject: [Mailman-Developers] internationalization of Mailman Message-ID: <19990726162117.22806.rocketmail@web601.yahoomail.com> I am french and i need to translate -at least- all the member and user part in French. I noticed that all of the message that are not in the templates are hard-coded into mailman. I am ready to translate the member and user message to french but i need to know how i can do that. We'd like the translation to be easily adapted to next versions of mailman. In the archive someone seem to have started i8n with GNU gettext to spanish, i'd like to do same for french if no one has done it yet. But i need to be sure that french translation will be compatible with next versions of mailman. Currently i don't see any .mo ou .mo file in mailman rc3 dist. Where can i find the framework to implement i8n ? PS: I need to have a quick answer because i have a deadline of 4 days to finish the mailing-list in my society (ZDNet France). _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From dan@feld.cvut.cz Mon Jul 26 20:52:30 1999 From: dan@feld.cvut.cz (Dan Ohnesorg) Date: Mon, 26 Jul 1999 21:52:30 +0200 (CEST) Subject: [Mailman-Developers] internationalization of Mailman In-Reply-To: <19990726162117.22806.rocketmail@web601.yahoomail.com> Message-ID: On Mon, 26 Jul 1999, Romain GRIFFITHS wrote: > PS: I need to have a quick answer because i have a deadline of 4 days > to finish the mailing-list in my society (ZDNet France). You can translate html templates. Nothing more is done. The project is in early stage and the result is not usable for any public accesible listserver. I see no posibility to make all right in 4 days. But there is probably no one listserv software, which is translated in French, so You can still use mailman and wait for usable internazionalized version. We can send You the .po catalog for future translation. cheers dan -- ________________________________________ DDDDDD DD DD Dan Ohnesorg, supervisor on POWER DD OOOO Dan@feld.cvut.cz DD OODDOO Dep. of Power Engineering DDDDDD OO CTU FEL Prague, Bohemia OO OO work: +420 2 24352785;+420 2 24972109 OOOO home: +420 311 679679;+420 311 679311 ________________________________________ Na svete jsou dva prostredky, Jak se povznest: bud vlastnimi schopnostmi, anebo hlouposti jinych. From Dionysos@Dionysia.org Tue Jul 27 21:59:33 1999 From: Dionysos@Dionysia.org (Dan Delaney) Date: Tue, 27 Jul 1999 16:59:33 -0400 Subject: [Mailman-Developers] Face lift for User Interface Message-ID: Hi all. Being a graphic designer I'm particularly interested in the "look and feel" of the interface for Mailman. The current interface is pretty good, certainly better than most I've used. But it could use some improvement. With that in mind, I've made a mockup page for the General Options page. For those who are interested, and especially those who actually work on the HTML for the interface, please take a look at www.Dionysia.org/temp/mailman/ and see what you think. Thanks. --Dan ________________________________________________________________________ Dionysos@Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html From aahz@searchbutton.com Tue Jul 27 22:05:09 1999 From: aahz@searchbutton.com (Aahz) Date: Tue, 27 Jul 1999 14:05:09 -0700 Subject: [Mailman-Developers] Viewing anyone's options w/o a password Message-ID: <219B76713101D31183B000902762824E0442AF@draco.searchbutton.com> This is late, but I'd suggest something like this: Require both e-mail address and password on sign-in. If no match is made, the error page contains a link to the form for "mail me password". I could go either way on the error page stating that the e-mail address is valid. -----Original Message----- From: Harald Meland [mailto:Harald.Meland@usit.uio.no] Sent: Thursday, July 01, 1999 2:34 PM To: Rob Francis Cc: mailman-developers@python.org Subject: Re: [Mailman-Developers] Viewing anyone's options w/o a password [Rob Francis] > It seems kind of odd to me that if I know someone's email address on > a list that I can go to the Info page and enter their email address, > and then w/o a password see what options they have set. I agree -- in principle this really is giving away more info than it should, e.g. if I suspect that someone is subscribed to a list, I can use this "feature" to verify my suspicion. However, if we make access to the user options page password restricted, we'd (obviously) have to put the "Email my password to me" button on some other page -- and I sort of think the listinfo page is crowded enough as it is. > Just wondering if this was a decision made on purpose, or perhaps an > oversight. I don't know for sure, but I suspect it was done like this because of the "Email my password to me" issue. Good suggestions on how this should best be solved are welcome. -- Harald _______________________________________________ Mailman-Developers maillist - Mailman-Developers@python.org http://www.python.org/mailman/listinfo/mailman-developers From corbett.klempay@trilogy.com Tue Jul 27 10:17:44 1999 From: corbett.klempay@trilogy.com (Corbett J. Klempay) Date: Tue, 27 Jul 1999 04:17:44 -0500 Subject: [Mailman-Developers] Face lift for User Interface In-Reply-To: Message-ID: I just took a look at the mock-up...I agree. The mockup has a more refined, 'clean' look...thumbs up! (but as Dan said, the existing interface puts most competitors to shame) --- Corbett J. Klempay Trilogy Software, Inc. 512.685.4193 (W) | 512.750.1372 (C) corbett.klempay@trilogy.com > -----Original Message----- > From: mailman-developers-admin@python.org > [mailto:mailman-developers-admin@python.org]On Behalf Of Dan Delaney > Sent: Tuesday, July 27, 1999 4:00 PM > To: mailman-developers@python.org > Subject: [Mailman-Developers] Face lift for User Interface > > > Hi all. > Being a graphic designer I'm particularly interested in the "look and > feel" of the interface for Mailman. The current interface is pretty good, > certainly better than most I've used. But it could use some improvement. > With that in mind, I've made a mockup page for the General Options page. > For those who are interested, and especially those who actually work on > the HTML for the interface, please take a look at > www.Dionysia.org/temp/mailman/ and see what you think. > Thanks. > --Dan > ________________________________________________________________________ > Dionysos@Dionysia.org Daniel G. Delaney > www.Dionysia.org/~dionysos/ > PGP Public Key: /~dionysos/pgp.html > > > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers > From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Jul 27 22:28:32 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 27 Jul 1999 17:28:32 -0400 (EDT) Subject: [Mailman-Developers] Face lift for User Interface References: Message-ID: <14238.9344.118190.260231@anthem.cnri.reston.va.us> >>>>> "CJK" == Corbett J Klempay writes: CJK> I just took a look at the mock-up...I agree. The mockup has CJK> a more refined, 'clean' look...thumbs up! (but as Dan said, CJK> the existing interface puts most competitors to shame) I saw a few of Dan's early attempts at the redesign, and this one (mockup3) is by far the best. Dan, I really like what you've done! If other people agree, let's look at getting these changes into Mailman post 1.0. -Barry From claw@varesearch.com Wed Jul 28 03:56:50 1999 From: claw@varesearch.com (J C Lawrence) Date: Tue, 27 Jul 1999 19:56:50 -0700 Subject: [Mailman-Developers] Face lift for User Interface In-Reply-To: Message from "Dan Delaney" of "Tue, 27 Jul 1999 16:59:33 EDT." Message-ID: On Tue, 27 Jul 1999 16:59:33 -0400 Dan Delaney wrote: > www.Dionysia.org/temp/mailman/ I like. -- J C Lawrence Home: claw@kanga.nu ---------(*) Linux/IA64 - Work: claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ... From petrilli@amber.org Wed Jul 28 04:29:00 1999 From: petrilli@amber.org (Christopher Petrilli) Date: Tue, 27 Jul 1999 23:29:00 -0400 Subject: [Mailman-Developers] Face lift for User Interface In-Reply-To: ; from Dan Delaney on Tue, Jul 27, 1999 at 04:59:33PM -0400 References: Message-ID: <19990727232900.A18815@amber.org> On Tue, Jul 27, 1999 at 04:59:33PM -0400, Dan Delaney wrote: > Hi all. > Being a graphic designer I'm particularly interested in the "look and > feel" of the interface for Mailman. The current interface is pretty good, > certainly better than most I've used. But it could use some improvement. > With that in mind, I've made a mockup page for the General Options page. > For those who are interested, and especially those who actually work on > the HTML for the interface, please take a look at > www.Dionysia.org/temp/mailman/ and see what you think. I would make only one major recommendations... drop all the style information out of the tags, and put it in a style sheet. Most of the stuff you're doing, especially colors would be better that way. Then you could actually ship 3-4 style sheets with different colors on them to people :-) Also, it reduces the amount of code in the page A LOT. Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright From cherub@azrael.dyn.cheapnet.net Wed Jul 28 07:18:04 1999 From: cherub@azrael.dyn.cheapnet.net (Steven Hazel) Date: Wed, 28 Jul 1999 01:18:04 -0500 (CDT) Subject: [Mailman-Developers] message board functionality? Message-ID: wwwthreads, a web-based threaded message board software, formerly released under the GPL, is now being released under a non-free license by the original author. I'm the administrator of wwwthreads for a user community, and we've decided to stick with free software. I suggested to the GNU project that I fork the code and work on extending and improving the capabilies of wwwthreads with the aim of inclusion in GNU. After a bit of discussion with RMS, I'm thinking that perhaps the best thing to do is to work on GNU Mailman to make it capable of doing what wwwthreads does. Many of the extensions I was planning for wwwthreads (for example, integration with email and optionalization of the web interface) are already done in Mailman, and I think that maybe Mailman could benefit from some of the additional functionality I am proposing. Besides which, I'd really like to be able to deal with all of my email in one place, rather than having to zoom off to some web site for a portion of it. I think a lot of web-based-forum users feel the same way. So I'm writing this email to find out what you think -- is this possible? Is it a good idea? My current minimum list of features needed to make GNU Mailman useable as a replacement for wwwthreads (with the web-based part fully optional) is as follows: - web logins for user accounts - user option to not actually receive mail from lists (for those who want to read lists purely on the web) - web interface for posting to mailing lists - web interface for administrator and moderator functions - web appearance configurability on both an administrator and user level - program to convert wwwthreads databases to Mailman configurations Of course, further features would follow those, based on what users say when they've switched from other forum software. I expect that the web frontend would benefit greatly. Your comments are appriciated. -Steven From root@theporch.com Wed Jul 28 11:27:18 1999 From: root@theporch.com (Phillip Porch) Date: Wed, 28 Jul 1999 05:27:18 -0500 (CDT) Subject: [Mailman-Developers] Face lift for User Interface In-Reply-To: Message-ID: I like the new look also. Add my vote to the Yes side please. -- Phillip P. Porch NIC:PP1573 finger for http://www.theporch.com UTM - 16 514548E 3994397N PGP key From adamj@shadowrun.html.com Wed Jul 28 12:01:13 1999 From: adamj@shadowrun.html.com (Adam J) Date: Wed, 28 Jul 1999 05:01:13 -0600 Subject: [Mailman-Developers] Face lift for User Interface In-Reply-To: <14238.9344.118190.260231@anthem.cnri.reston.va.us> References: Message-ID: <4.2.0.58.19990728045618.00a67bd0@shadowrun.html.com> At 17:28 7/27/99 -0400, Barry A. Warsaw wrote: > CJK> I just took a look at the mock-up...I agree. The mockup has > CJK> a more refined, 'clean' look...thumbs up! (but as Dan said, > CJK> the existing interface puts most competitors to shame) > >I saw a few of Dan's early attempts at the redesign, and this one >(mockup3) is by far the best. Dan, I really like what you've done! >If other people agree, let's look at getting these changes into >Mailman post 1.0. I definitely agree. The new design is much cleaner and looks much more professional. Adam < http://shadowrun.html.com/tss / adamj@shadowrun.html.com / ICQ# 2350330 > From John@list.org Wed Jul 28 12:07:11 1999 From: John@list.org (John Viega) Date: Wed, 28 Jul 1999 04:07:11 -0700 Subject: [Mailman-Developers] message board functionality? In-Reply-To: ; from Steven Hazel on Wed, Jul 28, 1999 at 01:18:04AM -0500 References: Message-ID: <19990728040711.E25427@viega.org> Steven, Yes, I like the idea. Some comments: "user option to not actually receive mail from lists"... for lists with archiving, you can already just go and read the archive. I know a lot of people who do this on real lists. You'd just have to change the link to say, "visit the list in forum format" or something like that. It does sound like Mailman meets many of your requirements already, but not all of them. I'd love to see this stuff get included. Please do work on it. John On Wed, Jul 28, 1999 at 01:18:04AM -0500, Steven Hazel wrote: > > wwwthreads, a web-based threaded message board software, formerly released > under the GPL, is now being released under a non-free license by the original > author. I'm the administrator of wwwthreads for a user community, and we've > decided to stick with free software. I suggested to the GNU project that I > fork the code and work on extending and improving the capabilies of > wwwthreads with the aim of inclusion in GNU. After a bit of discussion with > RMS, I'm thinking that perhaps the best thing to do is to work on GNU Mailman > to make it capable of doing what wwwthreads does. Many of the extensions I > was planning for wwwthreads (for example, integration with email and > optionalization of the web interface) are already done in Mailman, and I think > that maybe Mailman could benefit from some of the additional functionality I > am proposing. Besides which, I'd really like to be able to deal with all of > my email in one place, rather than having to zoom off to some web site for > a portion of it. I think a lot of web-based-forum users feel the same way. > > So I'm writing this email to find out what you think -- is this possible? > Is it a good idea? > > My current minimum list of features needed to make GNU Mailman useable as a > replacement for wwwthreads (with the web-based part fully optional) is as > follows: > > - web logins for user accounts > - user option to not actually receive mail from lists (for those who want > to read lists purely on the web) > - web interface for posting to mailing lists > - web interface for administrator and moderator functions > - web appearance configurability on both an administrator and user level > - program to convert wwwthreads databases to Mailman configurations > > Of course, further features would follow those, based on what users say when > they've switched from other forum software. I expect that the web frontend > would benefit greatly. > > Your comments are appriciated. > > -Steven > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From Nigel.Metheringham@vdata.co.uk Wed Jul 28 12:45:30 1999 From: Nigel.Metheringham@vdata.co.uk (Nigel Metheringham) Date: Wed, 28 Jul 1999 12:45:30 +0100 Subject: [Mailman-Developers] Face lift for User Interface In-Reply-To: Message from Adam J of "Wed, 28 Jul 1999 05:01:13 MDT." <4.2.0.58.19990728045618.00a67bd0@shadowrun.html.com> Message-ID: I also like the mockup interface, and would like the idea of making large chunks of this template-able - ie colour selection etc. At the risk of this becoming a general wish-list as well, I would also like finer control of some of the current information emitted by the mailman web interface. For example I have just changed the owner information for one of my lists so that it is delivered direct to my work mail account, and also has a mailbox suffix on it to enable it to be sorted automatically. This makes the address long, ugly, and I intended it for use by the stuff forwarded by mailman. However this now appears on the bottom of all the web pages (... list run by...). I don't appear to be able to remove that without dropping the tag from the pages, which is more extensive a change than I want. So finer control of these elements would also be advantageous. Nigel. -- [ Nigel Metheringham Nigel.Metheringham@VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] From klm@digicool.com Wed Jul 28 16:06:50 1999 From: klm@digicool.com (Ken Manheimer) Date: Wed, 28 Jul 1999 11:06:50 -0400 Subject: [Mailman-Developers] RE: Mailman-Developers digest, Vol 1 #328 - 6 msgs Message-ID: <613145F79272D211914B0020AFF640191D1C3C@gandalf.digicool.com> > From: "Dan Delaney" > To: > Date: Tue, 27 Jul 1999 16:59:33 -0400 > charset="iso-8859-1" > Subject: [Mailman-Developers] Face lift for User Interface > > Hi all. > Being a graphic designer I'm particularly interested in the "look and > feel" of the interface for Mailman. The current interface is pretty good, > certainly better than most I've used. But it could use some improvement. > With that in mind, I've made a mockup page for the General Options page. > For those who are interested, and especially those who actually work on > the HTML for the interface, please take a look at > www.Dionysia.org/temp/mailman/ and see what you think. I agree with everyone's admiration for your changes. I have one reservation, however - i much prefer the existing arrangement, if not necessarily the appearance, of the activity index at the top of the page. I think the regular matrix you use is too regular - i'd prefer the links to the configuration options pages to be more clearly separate from the "other" activities. I think having them in two separate columns, as we currently do, is not a bad arrangement - though i can see how it can be incongruous with everything else being arranged in tables. I also have a logistical reservation about the 70-character-wide text entry boxes at the bottom. One thing we've been thinking about for improving navigation through mailman, in general, is use of a sidebar and a "top"bar. This would use up some of the real estate needed for hard-wrapped, full width text entry boxes. (We've also been thinking about how we would make mailman "play nicely" with the existing style of a host site, another potential real-estate loss, but this is getting pretty hypothetical.) I just mention this to enter it into the picture... (BTW, i guess i'm primarily responsible for the existing layout of many of the mailman pages - though really, i refined/reworked to greater and lesser degrees what i originally got from john viega, and based some of my changes on contributions, particularly from robin friedrich. And i have to admit to a possibly stubborn liking of the "cumbersome white lines", which nicely delineate the options, to my eye. That said, i think the only real reservation i have is the one concerning the activity index at the top, and would be happy to go with all your other changes - thanks!!) Ken Manheimer klm@digicool.com From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Jul 28 16:22:18 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 28 Jul 1999 11:22:18 -0400 (EDT) Subject: [Mailman-Developers] Face lift for User Interface References: <19990727232900.A18815@amber.org> Message-ID: <14239.8234.795188.606005@anthem.cnri.reston.va.us> >>>>> "CP" == Christopher Petrilli writes: CP> I would make only one major recommendations... drop all the CP> style information out of the tags, and put it in a style CP> sheet. Most of the stuff you're doing, especially colors CP> would be better that way. Then you could actually ship 3-4 CP> style sheets with different colors on them to people :-) Also, CP> it reduces the amount of code in the page A LOT. Don't forget though, that we have to support older browsers. I think there are list admins with users still using e.g. NS 3. This stuff must work for them too. -Barry From petrilli@amber.org Wed Jul 28 16:32:51 1999 From: petrilli@amber.org (Christopher Petrilli) Date: Wed, 28 Jul 1999 11:32:51 -0400 Subject: [Mailman-Developers] Face lift for User Interface In-Reply-To: <14239.8234.795188.606005@anthem.cnri.reston.va.us>; from Barry A. Warsaw on Wed, Jul 28, 1999 at 11:22:18AM -0400 References: <19990727232900.A18815@amber.org> <14239.8234.795188.606005@anthem.cnri.reston.va.us> Message-ID: <19990728113251.A21085@amber.org> On Wed, Jul 28, 1999 at 11:22:18AM -0400, Barry A. Warsaw wrote: > >>>>> "CP" == Christopher Petrilli writes: > > CP> I would make only one major recommendations... drop all the > CP> style information out of the tags, and put it in a style > CP> sheet. Most of the stuff you're doing, especially colors > CP> would be better that way. Then you could actually ship 3-4 > CP> style sheets with different colors on them to people :-) Also, > CP> it reduces the amount of code in the page A LOT. > > Don't forget though, that we have to support older browsers. I think > there are list admins with users still using e.g. NS 3. This stuff > must work for them too. If you know how to use style-sheets, it's not a problem. You would get a gradual degredation, where colors would disappear, and maybe somesmall formatting details, but it gains you a lot of flexibility in formatting, and makes it easier for people to change how things look to suit their own site. Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright From Dionysos@Dionysia.org Wed Jul 28 17:18:57 1999 From: Dionysos@Dionysia.org (Dan Delaney) Date: Wed, 28 Jul 1999 12:18:57 -0400 Subject: [Mailman-Developers] Face lift for User Interface In-Reply-To: <14239.8234.795188.606005@anthem.cnri.reston.va.us> Message-ID: > -----Original Message----- > From: Barry A. Warsaw > >>>>> "CP" == Christopher Petrilli writes: > CP> I would make only one major recommendations... drop all the > CP> style information out of the tags, and put it in a style > CP> sheet. Most of the stuff you're doing, especially colors > CP> would be better that way. Then you could actually ship 3-4 > CP> style sheets with different colors on them to people :-) Also, > CP> it reduces the amount of code in the page A LOT. > > Don't forget though, that we have to support older browsers. I think > there are list admins with users still using e.g. NS 3. This stuff > must work for them too. That's correct. And even though (as someone else said) the pages would still work on older browsers if the style sheets are done correctly, there is still one major stumbling block to style sheets: the fact that they are not implimented completely correctly in ANY browser. I've found several problems with the way IE5 implements style sheets, and Netscrape's style sheet support is worthless. Nonetheless, I'll set up a second mockup using style sheets and see how it works out. I'll let you all know when it's ready. As far as making it so that it is easy to change the colors to match your site, there are two options. Style sheets is certainly a good way to do that. But the other option is to have option variables set for the colors and have the "COLOR=" parts of the HTMl file generated by the Python code which can insert the contents of the color preferences variables. --Dan ________________________________________________________________________ Dionysos@Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html From petrilli@amber.org Wed Jul 28 17:39:47 1999 From: petrilli@amber.org (Christopher Petrilli) Date: Wed, 28 Jul 1999 12:39:47 -0400 Subject: [Mailman-Developers] Face lift for User Interface In-Reply-To: ; from Dan Delaney on Wed, Jul 28, 1999 at 12:18:57PM -0400 References: <14239.8234.795188.606005@anthem.cnri.reston.va.us> Message-ID: <19990728123947.B21085@amber.org> On Wed, Jul 28, 1999 at 12:18:57PM -0400, Dan Delaney wrote: > That's correct. And even though (as someone else said) the pages would still > work on older browsers if the style sheets are done correctly, there is > still one major stumbling block to style sheets: the fact that they are not > implimented completely correctly in ANY browser. I've found several problems > with the way IE5 implements style sheets, and Netscrape's style sheet > support is worthless. Nonetheless, I'll set up a second mockup using style > sheets and see how it works out. I'll let you all know when it's ready. Well, colors work fine across all browsers that I've been able to test with. More advanced features aren't consistent, but some things that I've not had any real problems with: * Colors * Font size, especially relative (never use absolute) * Faces * Alignment (generally, except when nested) Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright From Harald.Meland@usit.uio.no Wed Jul 28 18:51:42 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 28 Jul 1999 19:51:42 +0200 Subject: [Mailman-Developers] RE: Mailman-Developers digest, Vol 1 #328 - 6 msgs In-Reply-To: Ken Manheimer's message of "Wed, 28 Jul 1999 11:06:50 -0400" References: <613145F79272D211914B0020AFF640191D1C3C@gandalf.digicool.com> Message-ID: [Ken Manheimer] > I agree with everyone's admiration for your changes. Yeah, even _I_ like'em :) > I have one reservation, however - i much prefer the existing > arrangement, if not necessarily the appearance, of the activity > index at the top of the page. I think the regular matrix you use is > too regular - i'd prefer the links to the configuration options > pages to be more clearly separate from the "other" activities. Like, in a separate frame, maybe? That's what I've been thinking, anyway... However, the frame-full UI should be optional. For a frame-less UI, I agree with Ken. > I think having them in two separate columns, as we currently do, is > not a bad arrangement - though i can see how it can be incongruous > with everything else being arranged in tables. Umm, I'm definitely _not_ a graphic designer (by far), but wouldn't a borderless table with one row of two columns, where each column contains a bordered/coloured table corresponding to the "columns" we have now, work nicely? -- Harald From cherub@azrael.dyn.cheapnet.net Thu Jul 29 01:35:14 1999 From: cherub@azrael.dyn.cheapnet.net (Steven Hazel) Date: Wed, 28 Jul 1999 19:35:14 -0500 (CDT) Subject: [Mailman-Developers] message board functionality? In-Reply-To: <19990728040711.E25427@viega.org> (message from John Viega on Wed, 28 Jul 1999 04:07:11 -0700) References: <19990728040711.E25427@viega.org> Message-ID: "user option to not actually receive mail from lists"... for lists with archiving, you can already just go and read the archive. I know a lot of people who do this on real lists. You'd just have to change the link to say, "visit the list in forum format" or something like that. Well, I was thinking that it might be a good idea to have some sort of user account system. This is a functionality which might be objectionable in a mailing list manager, but I'm not sure, since it would have some benefits as well. The idea is that rather than simply subscribing to a mailing list, users would create an account -- complete with username and password -- with Mailman. Perhaps the accounts should be per-list or perhaps a single account could subscribe to a set of lists. The account would include information about one or more addresses to which mail should be sent. At that point, for the ordinary mailing list user, everything is the same. For users who want to make exclusive use of the web interface, though, their username and password would be required at least to post under their username and maybe sometimes for read access (for private lists). One possibility this opens up is that posts could (optionally, of course) be listed under usernames for those who want anonymity, or with usernames as well as email addresses. One nice thing about that is that if someone has a subscription to a mailing list and switches email addresses, they can just tell Mailman that the new address belongs to them, and posts from that address could be recognized and given their username. From there, things like prefered email addresses for replies to posts regardless of the origin of the post are possible, which would sometimes be nice. I know I'd like to be able to post to certain mailing lists from my work email account and have replies uniformly show up at my regular email address. I'm wondering what your take on user accounts will be. It's important functionality for a web-based forum, but seems sort of tangental to mailing list management, though it does have some advantages. Perhaps they should be optional, or perhaps they don't belong in a mailing list manager at all and should be handled in a wrapper of some sort. My thought is that they should be optional, and turning them on could also turn on a great deal of web-based funtionality. -Steven From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Jul 29 15:55:48 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 29 Jul 1999 10:55:48 -0400 (EDT) Subject: [Mailman-Developers] message board functionality? References: <19990728040711.E25427@viega.org> Message-ID: <14240.27508.634165.859250@anthem.cnri.reston.va.us> >>>>> "SH" == Steven Hazel writes: SH> I'm wondering what your take on user accounts will be. It's SH> important functionality for a web-based forum, but seems sort SH> of tangental to mailing list management, though it does have SH> some advantages. Perhaps they should be optional, or perhaps SH> they don't belong in a mailing list manager at all and should SH> be handled in a wrapper of some sort. My thought is that they SH> should be optional, and turning them on could also turn on a SH> great deal of web-based funtionality. I actually believe user accounts are essential, but perhaps that's because of my unique relationship with the python.org lists. I agree with everything you've said. The biggest problem that I have is remembering all the dang passwords, both user and admin passwords, that I have to use every day. So I would go one step further; I would let the site administrator designate which user accounts can have admin privileges for which lists, so they'd only have to remember one password to administer any list of theirs. Users should also be able to manage all their lists on one screen. Say they're going on vacation. One button could allow them to disable all their accounts on the site, and another would enable them upon their return. It's interesting that user accounts are so important for message boarding (a feature that I think would be cool to add to Mailman), because I've been seriously considering this to better support existing functionality. The question in my mind is whether to homebrew all this support, or to leverage off of Zope, which I think already has much of this functionality. -Barry From widmaster@yahoo.com Thu Jul 29 16:16:45 1999 From: widmaster@yahoo.com (Romain GRIFFITHS) Date: Thu, 29 Jul 1999 08:16:45 -0700 (PDT) Subject: [Mailman-Developers] French Templates Message-ID: <19990729151645.15396.rocketmail@web601.yahoomail.com> We did the translation of the templates to french. We need to correct them a bit but it is ok _____________________________________________________________ Do You Yahoo!? Free instant messaging and more at http://messenger.yahoo.com From Dionysos@Dionysia.org Thu Jul 29 16:49:09 1999 From: Dionysos@Dionysia.org (Dan Delaney) Date: Thu, 29 Jul 1999 11:49:09 -0400 Subject: [Mailman-Developers] message board functionality? In-Reply-To: <14240.27508.634165.859250@anthem.cnri.reston.va.us> Message-ID: From: Barry A. Warsaw > they'd only have to remember one password to administer any > list of theirs. > Users should also be able to manage all their lists on one screen. > Say they're going on vacation. One button could allow them to disable > all their accounts on the site, and another would enable them upon > their return. That would be FANTASTIC! I run a bunch of email lists for members of an organization. Each person is on several lists. It would be great if they could just have one screen which could change their preferences for all of the lists they are on. Even to change the email address that the lists send to, and to specify alternate email addresses that they might be sending from (home and work, for instance). They should also, however, still be able to set separate preferences for each list. What would be great also, if it is set up this way, is to have a SITE ADMIN account, so that the person who runs mailman can have one password to be able to get into anything. On my sight, for instance, I have a lot of mailing lists for which other people are disignated as the administrators. Well, what happens when one of the admins forgets his password to one of the lists? It would be great if I, as the SITE admin, had an overall password which would allow me to go into any of the lists to fix them if the admins don't know how. --Dan ________________________________________________________________________ Dionysos@Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html From Dionysos@Dionysia.org Thu Jul 29 16:58:05 1999 From: Dionysos@Dionysia.org (Dan Delaney) Date: Thu, 29 Jul 1999 11:58:05 -0400 Subject: [Mailman-Developers] Face lift for User Interface In-Reply-To: <19990728123947.B21085@amber.org> Message-ID: From: Christopher Petrilli > Well, colors work fine across all browsers that I've been able to test > with. More advanced features aren't consistent, but some things that > I've not had any real problems with: > * Colors Well, everything works great in these new CSS mockups except for one thing. NETSCRAPE DOESN'T SET THE COLORS FOR THE BODY TAG! Yes. I'm using Netscrape 4.5 and when I specify a style sheet like "BODY { background-color: #000000; color: #FFFFFF }", Netscrape doesn't set the page background to black and text to white. I don't know whether or not MSIE does because my copy of MSIE5 bombs as soon as it is launched (it's running on WinNT, what do you expect! :-), so could someone please check it out (CSS mockup 3 is the one that should have a black background for the page) with MSIE (versions 3, 4, and 5) and let me know what it does? Anyway, go check out the new CSS mockups at www.Dionysia.org/temp/mailman/ and let me know what you think. > * Font size, especially relative (never use absolute) I always specify type size in ems, which is the ideal relative type size measurment unit. --Dan ________________________________________________________________________ Dionysos@Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html From Dionysos@Dionysia.org Thu Jul 29 18:27:33 1999 From: Dionysos@Dionysia.org (Dan Delaney) Date: Thu, 29 Jul 1999 13:27:33 -0400 (EDT) Subject: [Mailman-Developers] Re: Subject Cleanup Routine Message-ID: From: Harald Meland > So, if I send a mail with subject > Subject: Administrivia: [foo] will be changed to [bar] > Mailman should change it to > Subject: [foo] Administrivia: will be changed to [bar] > > ? I don't think messing with the subject prefix to that extent is a > good idea. First, how often are you really gonna put the list's prefix in the subject of a message to the list? Not very often. Maybe once in the lifetime of the list, if that often? Second, even if you do need to refer to the list name in the subject, you could just use quotes instead of brackets, as in: Subject: [foo] Administrivia: "foo" will be changing to "bar" I don't think that's really that big a deal. > Regarding stripping of consecutive "Re:" and "Fwd:" > strings -- you'd still have problems with the nationalized versions of > these ("SV:", "AD:", etc.) that some MUA vendors in their infinite > wisdom have implemented That's a good point. Maybe on the options page there could be a list of "subject tags" to strip from the subjects, instead of having them hard coded in the program. > I think this "problem" should be solved in the user's MUA > configuration (if the user wants the subjects mangled) and/or in the > archiver thread generator. Unfortunately the MUAs out there do a crappy job of this. Look at how many messages you get with things like "Re: Fwd: RE:" in the subject. I get a lot, and it's awefully annoying. Anyway. What would be nice would be a radio button option in the General Options to choose between the existing routine, which simply checks to see if the Prefix is already present in the subject, and a the more aggressive subject cleanup routine. Here, by the way, is a new copy of the routine which takes into account those aweful NUMBERED reply tags (as in "Re[2]:"): --------------------------------------------------------------------------- # Prepend the subject_prefix to the subject line. subj = msg.getheader('subject') prefix = self.subject_prefix # If there's no subject, give it one if not subj: msg.SetHeader('Subject', '%s(no subject)' % prefix) else: # Delete all occurances of the prefix from the subject if prefix: subj = re.sub(re.escape(self.subject_prefix), '', subj) # Check to see if the message is a reply or forward prefix2 = '' if re.search('^fwd*[0-9\[\]]*: |\(fwd\)', subj, re.I): prefix2 = 'Fwd: ' if re.match('re[0-9\[\]]*: ', subj, re.I): prefix2 = 'Re: ' # Clean up all that 're:' and 'fwd: ' garbage subj = re.sub('[rR][eE][0-9\[\]]*: | *\(*[fF][wW][dD]*[0-9\[\]\)]*:* *', '', subj) # Set the new subject line in place msg.SetHeader('Subject', '%s%s%s' % (prefix, prefix2, subj)) --------------------------------------------------------------------------- -- Dan ________________________________________________________________________ Dionysos@Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html From hebble@ncsa.uiuc.edu Thu Jul 29 18:27:29 1999 From: hebble@ncsa.uiuc.edu (Paul Hebble) Date: Thu, 29 Jul 1999 12:27:29 -0500 (CDT) Subject: [Mailman-Developers] message board functionality? In-Reply-To: Message-ID: On Thu, 29 Jul 1999, Dan Delaney wrote: > What would be great also, if it is set up this way, is to have a SITE ADMIN > account, so that the person who runs mailman can have one password to be > able to get into anything. On my sight, for instance, I have a lot of > mailing lists for which other people are disignated as the administrators. > Well, what happens when one of the admins forgets his password to one of the > lists? It would be great if I, as the SITE admin, had an overall password > which would allow me to go into any of the lists to fix them if the admins > don't know how. Err, isn't this already implimented? Try using your site admin passwd to get into list admin pages. -- Paul Hebble From Dionysos@Dionysia.org Thu Jul 29 18:30:49 1999 From: Dionysos@Dionysia.org (Dan Delaney) Date: Thu, 29 Jul 1999 13:30:49 -0400 Subject: [Mailman-Developers] message board functionality? In-Reply-To: Message-ID: > -----Original Message----- > From: Paul Hebble [mailto:hebble@ncsa.uiuc.edu] > Err, isn't this already implimented? Try using your site admin passwd to > get into list admin pages. Hmmm. Maybe so. I don't remember there being an overall site admin password. If so, kindly disregard that last paragraph ;=) --Dan ________________________________________________________________________ Dionysos@Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html From hebble@ncsa.uiuc.edu Thu Jul 29 18:36:32 1999 From: hebble@ncsa.uiuc.edu (Paul Hebble) Date: Thu, 29 Jul 1999 12:36:32 -0500 (CDT) Subject: [Mailman-Developers] message board functionality? In-Reply-To: Message-ID: On Thu, 29 Jul 1999, Dan Delaney wrote: > Hmmm. Maybe so. I don't remember there being an overall site admin password. > If so, kindly disregard that last paragraph ;=) Yeah, that's what $prefix/bin/mmsitepass does. -- Paul From johnr@eecs.berkeley.edu Thu Jul 29 20:02:30 1999 From: johnr@eecs.berkeley.edu (John Reekie) Date: Thu, 29 Jul 1999 12:02:30 -0700 Subject: [Mailman-Developers] message board functionality? In-Reply-To: <14240.27508.634165.859250@anthem.cnri.reston.va.us> Message-ID: <000201bed9f4$e9043fd0$723e2080@bean.eecs.berkeley.edu> > The biggest problem that I have is remembering all the dang passwords, > both user and admin passwords, that I have to use every day. So I > would go one step further; I would let the site administrator > designate which user accounts can have admin privileges for which > lists, so they'd only have to remember one password to administer any > list of theirs. User accounts are a great idea, but I would like to suggest that it be done so that websites that _already have_ user accounts can integrate mailman easily. Sites with accounts are popping up like mushrooms after the rain :) and it would be awesome if mailman had an interface that allowed them to "wrap" mailman in their existing setup. Of course, my motivation for this request is entirely selfish :-) To make this more concrete, this is the kind of stuff I do now to make mailman appear to be an integrated part of an existing site with user accounts: * Manufacture a password * Generate a query string with the password * Call apache via http and get the headers * Extract the cookie * Generate another query string with the user data * Call apache back with the cookie and the query string * Get the HTML back and strip out everything but the body * Munge the body to change URLs. * Plonk what's left into my own auto-generated HTML and send it back to the browser. Amazingly enough, this actually works. The reason for doing it this way was so I didn't have to modify MailMan (apart from about ten lines commented out). And of course I don't want users who are already logged in to enter any passwords or accept any more cookies. Anyway, if this sounds like it's worth at least discussing I am more than happy to help figure out how to go about it and volunteer to contribute a PHP script as an example of MailMan integration (the rest of my site is written in PHP). Thanks! JohnR From Paul Hebble Thu Jul 29 20:13:14 1999 From: Paul Hebble (Paul Hebble) Date: Thu, 29 Jul 1999 14:13:14 -0500 (CDT) Subject: [Mailman-Developers] Configurable Archiving Proposal Message-ID: Hi all, I want to set up Mailman to support other archiving methods, more cleanly than subscribing a procmailrc to a list. I know a few other people are interested in this as well. I would like to add a per-list configuration option to each list's config.db which tells Mailman a command line to run to archive a message. Is this any more complicated than adding a variable to the MailList class and adding a few lines to Archiver/Archiver.py? What do other users and developers think of this idea? Is it dangerous to allow a list adminstrator to execute arbitrary commands? If so, how else could this be done? -- Paul From Dionysos@Dionysia.org Thu Jul 29 20:27:29 1999 From: Dionysos@Dionysia.org (Dan Delaney) Date: Thu, 29 Jul 1999 15:27:29 -0400 Subject: [Mailman-Developers] message board functionality? In-Reply-To: <000201bed9f4$e9043fd0$723e2080@bean.eecs.berkeley.edu> Message-ID: From: John Reekie > I would like to suggest > that it be done so that websites that _already have_ user accounts > can integrate mailman easily. > I don't want users who are > already logged in to enter any passwords or accept any more > cookies. I'm in the same boat as John on this one. Consider an Intranet situation. The user has already logged into an Intranet on which he is subscribed to several mailing lists. He should not have to enter another password to configure his lists, he should just be able to click on a link and do it. Purhaps a good way to facilitate this would be to publish a clear specification for how all of the data is stored in the config.db files for lists so that if you already have an Intranet application set up you can just add in a little code to change the Mailman list data yourself. For instance, I already have a screen which allows the Intranet users to changes their password and personal information, including their email address. It'd be great if, when they change their email address, I could just add code into my PHP program which would automatically change their email address on all of the lists to which they are subscribed. --Dan ________________________________________________________________________ Dionysos@Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Jul 29 22:58:39 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 29 Jul 1999 17:58:39 -0400 (EDT) Subject: [Mailman-Developers] internationalization of Mailman References: <19990726162117.22806.rocketmail@web601.yahoomail.com> Message-ID: <14240.52879.986015.20651@anthem.cnri.reston.va.us> >>>>> "RG" == Romain GRIFFITHS writes: RG> Where can i find the framework to implement i8n ? There really is no comprehensive framework for supporting I18N in Mailman 1.0, but I would really like to put together a task force for supporting this in the next release. -Barry From bwarsaw@python.org Thu Jul 29 23:23:22 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Thu, 29 Jul 1999 18:23:22 -0400 (EDT) Subject: [Mailman-Developers] message board functionality? References: <14240.27508.634165.859250@anthem.cnri.reston.va.us> <000201bed9f4$e9043fd0$723e2080@bean.eecs.berkeley.edu> Message-ID: <14240.54362.921170.841818@anthem.cnri.reston.va.us> >>>>> "JR" == John Reekie writes: JR> User accounts are a great idea, but I would like to suggest JR> that it be done so that websites that _already have_ user JR> accounts can integrate mailman easily. Sites with accounts are JR> popping up like mushrooms after the rain :) and it would be JR> awesome if mailman had an interface that allowed them to JR> "wrap" mailman in their existing setup. So it sounds like there are a couple of issues here. One is making Mailman's web interface customizable so that you can make it look like it's an integrated part of the site. It sounds like you go to a lot of work to make this happen. I have some thoughts on this based on the ht2html scripts[1] I wrote, but I'm not sure if they're general or flexible enough. Then again, maybe using style sheets would get us close enough. Second, it sounds like you want to perhaps have a Mailman hook for authenticating users. Would it be enough to design an API that Mailman would call, given an email address (future: login name) and a password, and ask if they matched? This way, you could write a little Python glue code to consult any password database available. -Barry [1] http://www.python.org/~bwarsaw/software/pyware.html From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Jul 29 23:26:03 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 29 Jul 1999 18:26:03 -0400 (EDT) Subject: [Mailman-Developers] message board functionality? References: <000201bed9f4$e9043fd0$723e2080@bean.eecs.berkeley.edu> Message-ID: <14240.54523.53233.90128@anthem.cnri.reston.va.us> >>>>> "DD" == Dan Delaney writes: DD> Purhaps a good way to facilitate this would be to publish a DD> clear specification for how all of the data is stored in the DD> config.db files for lists so that if you already have an DD> Intranet application set up you can just add in a little code DD> to change the Mailman list data yourself. This wouldn't be hard to do, and you might not even need to know the format for the config.db file. You could probably write a small script (using bin/sync_members, etc.) that does the modification for you. In fact, I wrote sync_members to make it easy to synchronize PSA member addresses with our external database. Writing a script for hacking a user's password wouldn't be hard. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Jul 29 23:28:58 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 29 Jul 1999 18:28:58 -0400 (EDT) Subject: [Mailman-Developers] RE: Mailman-Developers digest, Vol 1 #328 - 6 msgs References: <613145F79272D211914B0020AFF640191D1C3C@gandalf.digicool.com> Message-ID: <14240.54698.306259.682268@anthem.cnri.reston.va.us> >>>>> "KM" == Ken Manheimer writes: KM> I think the regular matrix you use is too regular - i'd prefer KM> the links to the configuration options pages to be more KM> clearly separate from the "other" activities. I think having KM> them in two separate columns, as we currently do, is not a bad KM> arrangement I agree. Dan, would it be difficult to simply separate columns 1&2 from column 3? -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Jul 29 23:31:29 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 29 Jul 1999 18:31:29 -0400 (EDT) Subject: [Mailman-Developers] RE: Mailman-Developers digest, Vol 1 #328 - 6 msgs References: <613145F79272D211914B0020AFF640191D1C3C@gandalf.digicool.com> Message-ID: <14240.54849.147230.336426@anthem.cnri.reston.va.us> >>>>> "HM" == Harald Meland writes: HM> Like, in a separate frame, maybe? That's what I've been HM> thinking, anyway... HM> However, the frame-full UI should be optional. For a HM> frame-less UI, I agree with Ken. Harald, I hope you're not advocating using HTML s! I absolutely detest those things :). I think we can get all the benefits of frames without the headaches by using an arrangement similar to www.python.org and www.jpython.org (and not-coincidentally www.python.org/~bwarsaw :) I'm hoping the sidebar idea will be useful for eliminating the HTML dead-ends we currently have. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Jul 29 23:46:33 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 29 Jul 1999 18:46:33 -0400 (EDT) Subject: [Mailman-Developers] Re: Subject Cleanup Routine References: Message-ID: <14240.55753.592871.296391@anthem.cnri.reston.va.us> >>>>> "DD" == Dan Delaney writes: DD> Unfortunately the MUAs out there do a crappy job of this. Look DD> at how many messages you get with things like "Re: Fwd: RE:" DD> in the subject. I get a lot, and it's awefully annoying. I agree, but trying to work around every f*cked up MUA (let alone MTA, let alone Web browser, let alone OS) will keep us all very busy for a very long time! Okay, maybe I'm being extreme... :) DD> Anyway. What would be nice would be a radio button option in DD> the General Options to choose between the existing routine, DD> which simply checks to see if the Prefix is already present in DD> the subject, and a the more aggressive subject cleanup DD> routine. I'm very leary about adding even more configuration options to the Web interface. I'd like to /simplify/ the interfaces as much as possible. That's the beauty of having the source though, isn't it? :) -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Jul 29 23:51:13 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 29 Jul 1999 18:51:13 -0400 (EDT) Subject: [Mailman-Developers] Configurable Archiving Proposal References: Message-ID: <14240.56033.996260.137896@anthem.cnri.reston.va.us> >>>>> "PH" == Paul Hebble writes: PH> I want to set up Mailman to support other archiving methods, PH> more cleanly than subscribing a procmailrc to a list. I know PH> a few other people are interested in this as well. PH> I would like to add a per-list configuration option to each PH> list's config.db which tells Mailman a command line to run to PH> archive a message. Is this any more complicated than adding a PH> variable to the MailList class and adding a few lines to PH> Archiver/Archiver.py? PH> What do other users and developers think of this idea? Is it PH> dangerous to allow a list adminstrator to execute arbitrary PH> commands? If so, how else could this be done? Is it that important to allow individual lists to have different archiving mechanisms? Dave Cinege posted[1] a message to mailman-users explaining how he hooks MHonArc to Mailman and I'm playing with the approach right now (if I can actually get perl to build :). -Barry [1] http://www.python.org/pipermail/mailman-users/1999-July/001726.html From lindsey@ncsa.uiuc.edu Fri Jul 30 00:07:57 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Thu, 29 Jul 1999 18:07:57 -0500 (CDT) Subject: [Mailman-Developers] Configurable Archiving Proposal In-Reply-To: <14240.56033.996260.137896@anthem.cnri.reston.va.us> from "Barry A. Warsaw" at Jul 29, 99 06:51:13 pm Message-ID: <199907292307.SAA06604@ferret.ncsa.uiuc.edu> > Is it that important to allow individual lists to have different > archiving mechanisms? I don't think so, although it might be useful to use different archiving mechanisms for internal vs. external. Actually I might be to blame for this -- Paul asked me about it and I may have misunderstood his question. > Dave Cinege posted[1] a message to mailman-users explaining how he > hooks MHonArc to Mailman and I'm playing with the approach right now > (if I can actually get perl to build :). It's an icky approach, though... Like he mentions, it's pre-filtering based *and* requires admin permissions to modify anything. If it has to be hacked, I prefer to subscribe a known alias or account to the list, then have that call a .procmailrc file (which can call other files writeable by the Web group, etc.) What we're trying to do is generalize Mailman's archiver enough so that you can drop any binary into pipermail's place. Chris From bwarsaw@python.org Fri Jul 30 00:17:22 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Thu, 29 Jul 1999 19:17:22 -0400 (EDT) Subject: [Mailman-Developers] Configurable Archiving Proposal References: <14240.56033.996260.137896@anthem.cnri.reston.va.us> <199907292307.SAA06604@ferret.ncsa.uiuc.edu> Message-ID: <14240.57602.943388.662500@anthem.cnri.reston.va.us> >>>>> "CL" == Christopher Lindsey writes: CL> I don't think so, although it might be useful to use different CL> archiving mechanisms for internal vs. external. In that case, we might be able to add a Default.py variable to control this. CL> It's an icky approach, though... Like he mentions, it's CL> pre-filtering based *and* requires admin permissions to modify CL> anything. If it has to be hacked, I prefer to subscribe a CL> known alias or account to the list, then have that call a CL> .procmailrc file (which can call other files writeable by the CL> Web group, etc.) CL> What we're trying to do is generalize Mailman's archiver CL> enough so that you can drop any binary into pipermail's place. A laudable goal. BTW, I just converted my first mbox to HTML using MHonArc. There are some things I don't like (where are the by-author and by-date archives? Can I split my months and give an overview similar to Pipermail? Perhaps I can and haven't read enough of the manual...) -Barry From lindsey@ncsa.uiuc.edu Fri Jul 30 00:26:18 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Thu, 29 Jul 1999 18:26:18 -0500 (CDT) Subject: [Mailman-Developers] Configurable Archiving Proposal In-Reply-To: <14240.57602.943388.662500@anthem.cnri.reston.va.us> from "Barry A. Warsaw" at Jul 29, 99 07:17:22 pm Message-ID: <199907292326.SAA06725@ferret.ncsa.uiuc.edu> > BTW, I just converted my first mbox to HTML using MHonArc. There are > some things I don't like (where are the by-author and by-date > archives? Can I split my months and give an overview similar to > Pipermail? Perhaps I can and haven't read enough of the manual...) MHonArc won't split by month (it expects you to do this beforehand), but you can create author/by-date archives using rc files. I usually pre-process with procmail to do the splitting (and create an archive of the actual Berkeley-style mbox in case I need to recreate the archives, etc.) Take a look at http://www.mallorn.com/lists/ for lists in action, and http://www.mallorn.com/~lindsey/mhonarc/ for the rc files that make the definitions that you're looking for. They're old though -- our newer ones are site-specific based on local patches. Chris From petrilli@amber.org Fri Jul 30 00:55:24 1999 From: petrilli@amber.org (Christopher Petrilli) Date: Thu, 29 Jul 1999 19:55:24 -0400 Subject: [Mailman-Developers] Face lift for User Interface In-Reply-To: ; from Dan Delaney on Thu, Jul 29, 1999 at 11:58:05AM -0400 References: <19990728123947.B21085@amber.org> Message-ID: <19990729195524.A1656@amber.org> On Thu, Jul 29, 1999 at 11:58:05AM -0400, Dan Delaney wrote: > From: Christopher Petrilli > > Well, colors work fine across all browsers that I've been able to test > > with. More advanced features aren't consistent, but some things that > > I've not had any real problems with: > > * Colors > > Well, everything works great in these new CSS mockups except for one thing. > NETSCRAPE DOESN'T SET THE COLORS FOR THE BODY TAG! Yes. I'm using Netscrape > 4.5 and when I specify a style sheet like "BODY { background-color: #000000; > color: #FFFFFF }", Netscrape doesn't set the page background to black and > text to white. I don't know whether or not MSIE does because my copy of > MSIE5 bombs as soon as it is launched (it's running on WinNT, what do you > expect! :-), so could someone please check it out (CSS mockup 3 is the one > that should have a black background for the page) with MSIE (versions 3, 4, > and 5) and let me know what it does? Well, I forgot about this, IE behaves properly in this case... but that's definately a bummer... I just set the body tag manually. > Anyway, go check out the new CSS mockups at www.Dionysia.org/temp/mailman/ > and let me know what you think. Looks good, and loads faster for me. > > * Font size, especially relative (never use absolute) > > I always specify type size in ems, which is the ideal relative type size > measurment unit. Um, this breaks on *NIX because tehy have rather antiquated ideas about fonts. I get this constantly from Linux people "whine whine, your fonts are too small"... I have to set them to like 18pt before they quit whining, so I just quitsetting ANYTHING in absolute. Um, setting font size in "ems" is a riot, BTW, since the definition of an em depends on the font you're in, no? :-) Try using percentages. Spacing is defined in ems, not fonts. Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright From u.wisser@luna-park.de Fri Jul 30 08:35:02 1999 From: u.wisser@luna-park.de (Ulrich Wisser) Date: Fri, 30 Jul 1999 09:35:02 +0200 Subject: [Mailman-Developers] internationalization of Mailman References: <19990726162117.22806.rocketmail@web601.yahoomail.com> <14240.52879.986015.20651@anthem.cnri.reston.va.us> Message-ID: <37A155A6.35AC987F@luna-park.de> Hello, > There really is no comprehensive framework for supporting I18N in > Mailman 1.0, but I would really like to put together a task force for > supporting this in the next release. I'd like to be in that TF. I18N is really needed at my site. BTW I have another feature request: MODERATOR-WEB-INTRFACE How abount a moderator web-interface? The normal admin interface is much to "technical" for the moderators at my site. They just need to subscribe/unsubscribe, change users and authorize posts to the list. They should not have any options to change the webpages the listinfo... So long Ulli -- ----------------- Die Website Effizienzer ------------------ luna-park Bravo Sanchez, Vollmert, Wisser GbR Ulrich Wisser mailto:u.wisser@luna-park.de Alter Schlachthof, Immenburgstr. 20 Tel +49-228-9654055 D-53121 Bonn Fax +49-228-9654057 ------------------http://www.luna-park.de ------------------ From bwarsaw@python.org Fri Jul 30 15:45:56 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Fri, 30 Jul 1999 10:45:56 -0400 (EDT) Subject: [Mailman-Developers] internationalization of Mailman References: <19990726162117.22806.rocketmail@web601.yahoomail.com> <14240.52879.986015.20651@anthem.cnri.reston.va.us> <37A155A6.35AC987F@luna-park.de> Message-ID: <14241.47780.867382.82846@anthem.cnri.reston.va.us> >>>>> "UW" == Ulrich Wisser writes: UW> BTW I have another feature request: MODERATOR-WEB-INTRFACE UW> How abount a moderator web-interface? The normal admin UW> interface is much to "technical" for the moderators at my UW> site. They just need to subscribe/unsubscribe, change users UW> and authorize posts to the list. They should not have any UW> options to change the webpages the listinfo... I agree. Moderator and admin should be two separate roles. -Barry From jcrey@uma.es Thu Jul 1 09:12:11 1999 From: jcrey@uma.es (Juan Carlos Rey Anaya) Date: Thu, 01 Jul 1999 10:12:11 +0200 Subject: [Mailman-Developers] Re: i18n References: Message-ID: <377B22DB.7FF21996@uma.es> Fabio Dorival Victorelli wrote: > > Hello all, > > We've made today the i18n just for one file "bin/newlist" and toke > some minutes... > > I'd like to know if there are somebody working in i18n? > Yes, as I commented to list-developers one month and a half ago. I've been working in Mailman i18n all this time. Mesages I sent to this list were dated 05/21/99 Re: [Mailman-Developers] features suggestion: languages 05/06/99 [Mailman-Developers] Mailman internationalization. Report from the trenches. VERY LONG I have made TONS and TONS of modifications to Mailman code to achieve what I told in the first message. The only work that remains to be done is exactly the translation of strings inside code. I am waiting for Dan Ohnesorg to give the code he made to generate .PO I have a demo version of what I have done at http://joker.sci.uma.es/mailman/listinfo/test This version can switch between templates of differents languages. We can work together if you like. Cheers -- ___ / F \ [[[]]]] ( O O ) #----------------0000--(_)--0000---------------# | Juan Carlos Rey Anaya (jcrey@uma.es) | | Servicio Central de informática | | Universidad de Málaga - España | #----------------------------------------------# # Solo se que cada vez se menos :-| # #----------------------------------------------# From Harald.Meland@usit.uio.no Thu Jul 1 20:33:05 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 01 Jul 1999 21:33:05 +0200 Subject: [Mailman-Developers] forwarded message from David Thiessen In-Reply-To: "Barry A. Warsaw"'s message of "Sun, 27 Jun 1999 17:27:27 -0400 (EDT)" References: <14198.38719.23553.585277@anthem.cnri.reston.va.us> Message-ID: [David Thiessen] > To whom it may concern: > > I have recently installed Mailman on a system where I work and I have found > it to be a fantastic software package. But to use it here, the people need > documentation and so I have written some. Great! > I was not quite sure where to send it, so I grabbed your email > address. I guess ( would be fine -- if you could post a pointer to where the file can be retrieved from rather than the entire word file, that'd probably be best for files that big. If that for some reason isn't possible, just post the file as an attachment (like you did to Barry). As Mailman is quite web-based, I guess that it would make most sense if the manual is on the web, as well (but a printable version should also be available). I have done a quick'n'dirty Save as HTML "conversion" of the word document -- for now, it is available at . It probably needs to be massaged some more (I somehow suspect that MSWord doesn't create the prettiest HTML in the world, and the web version should probably be split into several files) before going into the distribution, but it is very much better than *no* documentation! Thanks! > And to repeat myself one more time, Mailman is a fantastic program > which I hope the use of will continue to expand. Thanks -- and so do we ;) > By the way, when is the date for a final release. I've given up trying to give specific dates for this, and I haven't been keeping to well up with reported bugs lately :( However, if the bottleneck Barry found is /the/ bottleneck that has been causing some high-volume users of Mailman headaches, and no similarly critical deficiencies has been reported, I think we're nearly there. If anyone still have any faith at all in whatever guesstimates us core developers give on the 1.0 release date, I'd say that it should be out this summer -- let me know if you think that wasn't vague enough :) -- Harald From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Jul 1 21:40:15 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 1 Jul 1999 16:40:15 -0400 (EDT) Subject: [Mailman-Developers] my recent checkins Message-ID: <14203.53807.601067.562228@anthem.cnri.reston.va.us> Not much time, but I went ahead and checked in both changes for which I sent patches about. Having run python.org on these patches for about a day, and esp. over the new month, I feel that they at least don't make things worse. Performance on python.org has gotten /dramatically/ better. I've yet to see a cpu pegged at 100% for more than about 2 minutes, and load averages look much better now (usually <1 where they were consistantly running in the 6-7 range). -Barry From Harald.Meland@usit.uio.no Thu Jul 1 22:23:10 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 01 Jul 1999 23:23:10 +0200 Subject: [Mailman-Developers] Unsubscribed users still getting monthly reminders In-Reply-To: J C Lawrence's message of "Tue, 15 Jun 1999 11:08:54 -0700" References: Message-ID: [J C Lawrence] > I have Mailman v 1.0b8 running at Kanga.Nu (yes, I know its old, > I'll upgrade tonight), and have two list members complaining that > they are no longer subscribed to a list and yet receive monthly > password reminders. When I check the web interfaces, they are in > fact unsubscribed. > > Ideas? cron/mailpasswds gets it's user data from the `passwords' entry of a list, while it's really the `members' (combined with the `user_options') entry that says whether someone will get mail from the list. If an address somehow is present in `passwords', but not in `members', the result would be as you describe. I think you'd have to tweak the list's config.db by hand (e.g. using bin/withlist) to fix this. I wonder whether such inconsistencies could be caused by the mixed-case-address bug which I _think_ was still in there in 1.0b8... Anyway, I guess all of this will be redone after 1.0 with the user object database and all. -- Harald From Harald.Meland@usit.uio.no Thu Jul 1 22:34:08 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 01 Jul 1999 23:34:08 +0200 Subject: [Mailman-Developers] Viewing anyone's options w/o a password In-Reply-To: Rob Francis's message of "Wed, 23 Jun 1999 14:24:13 -0400 (EDT)" References: Message-ID: [Rob Francis] > It seems kind of odd to me that if I know someone's email address on > a list that I can go to the Info page and enter their email address, > and then w/o a password see what options they have set. I agree -- in principle this really is giving away more info than it should, e.g. if I suspect that someone is subscribed to a list, I can use this "feature" to verify my suspicion. However, if we make access to the user options page password restricted, we'd (obviously) have to put the "Email my password to me" button on some other page -- and I sort of think the listinfo page is crowded enough as it is. > Just wondering if this was a decision made on purpose, or perhaps an > oversight. I don't know for sure, but I suspect it was done like this because of the "Email my password to me" issue. Good suggestions on how this should best be solved are welcome. -- Harald From Harald.Meland@usit.uio.no Thu Jul 1 22:42:57 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 01 Jul 1999 23:42:57 +0200 Subject: [Mailman-Developers] Cooki e problem with current CVS tree In-Reply-To: J C Lawrence's message of "Wed, 23 Jun 1999 12:54:25 -0700" References: Message-ID: [J C Lawrence] > I just revved a 1.0rc1 installation to the current CVS tree. > Cookies no longer track properly -- you are asked to re-authenticate > on every page and nothing gets done. > > Known fix? Nope, it works fine for me -- could you try instrumenting the WebAuthenticate(), MakeCookie() and CheckCookie() methods in Mailman/SecurityManager.py (e.g. by inserting debug "print" statements) to pinpoint exactly what it is that makes cookie authentication fail? -- Harald From Harald.Meland@usit.uio.no Thu Jul 1 22:50:05 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 01 Jul 1999 23:50:05 +0200 Subject: [Mailman-Developers] config.db In-Reply-To: Ricardo Kustner's message of "Wed, 23 Jun 1999 22:13:31 +0200 (CEST)" References: Message-ID: [Ricardo Kustner] > Hi, > > Yesterday i was looking where mailman stores the > pending-for-moderation messages ... it took a while before I found > out... cause i'd never suspect it to be inside config.db ? I must confess that this caught me by surprise when I first saw it, too, but I've never gotten round to try changing it. Ideally we shouldn't tempt Murphy by saving non-config data in config.db, so I guess this is one more to be fixed post 1.0. > what's the philosophy on that... I guess it was put there because "it's convenient" and/or "it works" :) -- Harald From Harald.Meland@usit.uio.no Thu Jul 1 23:02:01 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 02 Jul 1999 00:02:01 +0200 Subject: [Mailman-Developers] Setting Reply-To In-Reply-To: J C Lawrence's message of "Wed, 23 Jun 1999 14:43:27 -0700" References: Message-ID: [J C Lawrence] > A peculiar need: > > I need to set Reply-To on a list to something OTHER than the list > address. Specifically I need to set Reply-To to the address of > another list. > > Can do? I guess you could do this by having a list-specific filter add the necessary Reply-To: headers -- but it'll be rather kludgy. Read the scripts/post code for when and how list-specific filters are invoked. I guess this will be solved by the general "add these headers" planned for post-1.0. -- Harald From Harald.Meland@usit.uio.no Thu Jul 1 23:26:11 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 02 Jul 1999 00:26:11 +0200 Subject: [Mailman-Developers] Re: Bug#40101: mailman: unexpected mailman error In-Reply-To: Gergely Madarasz's message of "Thu, 24 Jun 1999 15:57:30 +0200 (METDST)" References: Message-ID: [Gergely Madarasz] > someone who is already subscribed tried to subscribe again. mailman > should catch this exception and reply politely, I'm forwarding this > upstream. Thanks for the bug report, this has now been fixed in CVS. -- Harald From Harald.Meland@usit.uio.no Thu Jul 1 23:38:46 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 02 Jul 1999 00:38:46 +0200 Subject: [Mailman-Developers] Bug in GatewayManager.py, 1.0rc2 In-Reply-To: Ben Gertzfield's message of "25 Jun 1999 16:02:19 -0700" References: Message-ID: [Ben Gertzfield] > I'm not subscribed to this list, so please Cc: me on any replies. > I hope this is the right place to send bug reports. > > Anyway, the bug looks like a think-o in GatewayManager.py: Thanks for the report, fixed in CVS. -- Harald From che@debian.org Thu Jul 1 23:59:22 1999 From: che@debian.org (Ben Gertzfield) Date: 01 Jul 1999 15:59:22 -0700 Subject: [Mailman-Developers] Bug in GatewayManager.py, 1.0rc2 In-Reply-To: Harald Meland's message of "02 Jul 1999 00:38:46 +0200" References: Message-ID: >>>>> "Harald" == Harald Meland writes: Ben> I'm not subscribed to this list, so please Cc: me on any Ben> replies. I hope this is the right place to send bug reports. Ben> Ben> Anyway, the bug looks like a think-o in GatewayManager.py: Harald> Thanks for the report, fixed in CVS. -- Harald Thanks, Harald! Also, I've noticed that gate_news is extremely poor at handling any kinds of exceptions if something goes wrong when gatewaying mail to news. I've been getting about 15-20 mails a day from cron about all the uncaught exceptions from gate_news. Here are some examples of the different exceptions I've been getting: [snip] Subject: Cron /usr/bin/python /usr/lib/mailman/cron/gate_news Date: Fri, 25 Jun 1999 04:10:07 -0700 Exception exceptions.IOError: (2, 'No such file or directory') in ignored [snip] Subject: Cron /usr/bin/python /usr/lib/mailman/cron/gate_news Date: Fri, 25 Jun 1999 06:06:34 -0700 Traceback (innermost last): File "/usr/lib/mailman/cron/gate_news", line 119, in ? main() File "/usr/lib/mailman/cron/gate_news", line 78, in main conn = nntplib.NNTP(mlist.nntp_host) File "/usr/lib/python1.5/nntplib.py", line 73, in __init__ self.welcome = self.getresp() File "/usr/lib/python1.5/nntplib.py", line 132, in getresp raise error_temp, resp nntplib.error_temp: 400 Flushing log and syslog files [snip] Subject: Cron /usr/bin/python /usr/lib/mailman/cron/gate_news Date: Fri, 25 Jun 1999 08:40:04 -0700 Exception exceptions.ValueError: 'unpack list of wrong size' in ignored [snip] Subject: Cron /usr/bin/python /usr/lib/mailman/cron/gate_news Date: Fri, 25 Jun 1999 08:50:03 -0700 Exception NotLockedError in ignored [snip] I assume all of these can be fixed by properly dealing with these exceptions. It's extremely frustrating to be getting so many exception reports every day.. -- Brought to you by the letters P and F and the number 8. "You forgot Uranus." "Goooooooooodnight everybody!" Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From richarde@eskom.co.za Fri Jul 2 07:24:13 1999 From: richarde@eskom.co.za (Richard Ellerbrock) Date: Fri, 02 Jul 1999 08:24:13 +0200 Subject: [Mailman-Developers] Another news gateing problem Message-ID: If the news server is too busy or down, the following error is generated to cron (not nice)! This should just fail gracefully, be logged and be tried again later at the next cron run. Traceback (innermost last): File "/home/mailman/cron/gate_news", line 119, in ? main() File "/home/mailman/cron/gate_news", line 78, in main conn = nntplib.NNTP(mlist.nntp_host) File "/usr/lib/python1.5/nntplib.py", line 70, in __init__ self.sock.connect(self.host, self.port) socket.error: (111, 'Connection refused') -- Richard Ellerbrock richarde@eskom.co.za From eugene.leitl@lrz.uni-muenchen.de Sun Jul 4 07:27:43 1999 From: eugene.leitl@lrz.uni-muenchen.de (Eugene Leitl) Date: Sat, 3 Jul 1999 23:27:43 -0700 (PDT) Subject: [Mailman-Developers] personal server-side filtering Message-ID: <14206.64854.775517.831387@lrz.de> Hi. Another list I'm on often goes into regimes with bad signal/noise regularly provoking cries for moderation. Here's a scheme I/friend of mine come with --I'd like to know how difficult it would be to add to mailman (particularly, where to massage it in). "To recapitulate: my original proposal was to establish a pair of lists: fnord-moderated/fnord-unmoderated. Everything rejected from fnord-moderated would go to fnord-unmoderated that anybody who subscribed to both lists would get the full feed, if so inclined. This scheme is simple to implement, but has obvious flaws. To avoid pressing anybody in a single quality metric it should be possible to associate each subscriber with a ranking matrix against the other participants (which could be inquirable remotely). With 1 k subscribers this means keeping track of 1 M short integers, which is tolerable nowadays (besides, this can be implemented as sparse matrix). Each mail will be attached a pair of urls/listserv commands to increment/decrement your individual ranking of the poster this mail came from. The matrix gets initialized with zero. All positive values including zero mean no filtering. -1 means every second post gets through, -2 every third, etc. This doesn't include topic filtering, but this can be addressed separately. To address this, we can agree on an initial keyword pool (META:SPACE:GUNS: etc.) and make the listserv let through only properly classified messages. If a message is unclassified it gets send back with a list of current keywords. There should be a mechanism of creating new keywords, and discarding obsolete ones (e.g. by aging). I'm fairly certain it would be possible to hack mailman into supporting this. Does anybody see any obvious flaws in the scheme?" So, any comments on that? TIA, Eugene From gorgo@caesar.elte.hu Mon Jul 5 16:25:01 1999 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Mon, 5 Jul 1999 17:25:01 +0200 (METDST) Subject: [Mailman-Developers] cookie problem ? Message-ID: Hello, If I want to access the mailman pages thru a different url (like http://somehost/cgi-bin/mailman/, the cgi-bin directory has a symlink to mailman/cgi-bin) the cookie authentication is problematic. It allows access for the first time but after that it wants authentication again. Could this be fixed somehow ? This way there wouldn't be need to configure the webserver to use the /mailman/ alias. -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From gonter@maestria.wu-wien.ac.at Wed Jul 7 18:31:23 1999 From: gonter@maestria.wu-wien.ac.at (Gerhard Gonter) Date: Wed, 7 Jul 1999 19:31:23 +0200 (MES) Subject: [Mailman-Developers] automatically generated password too complicated? In-Reply-To: <199904201821.UAA20318@maestria.wu-wien.ac.at> from Gerhard Gonter at "Apr 20, 99 08:21:54 pm" Message-ID: <199907071731.TAA31534@maestria.wu-wien.ac.at> Huh? Did that posting hide in a mail queue for 2.5 months?? > Received: from python.org (localhost [127.0.0.1]) > by python.org (8.9.1a/8.9.1) with ESMTP id NAA01107; > Wed, 7 Jul 1999 13:24:39 -0400 (EDT) > Received: from maestria.wu-wien.ac.at (maestria.wu-wien.ac.at [137.208.7.7]) > by python.org (8.9.1a/8.9.1) with ESMTP id OAA09471 > for ; Tue, 20 Apr 1999 14:21:55 -0400 (EDT) +gg -- Gerhard.Gonter@wu-wien.ac.at Fax: +43/1/31336/702 g.gonter@ieee.org Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria --- Linux or FreeBSD, it's like blondes or brunettes. I like both. -- From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Jul 7 18:51:05 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 7 Jul 1999 13:51:05 -0400 (EDT) Subject: [Mailman-Developers] automatically generated password too complicated? References: <199904201821.UAA20318@maestria.wu-wien.ac.at> <199907071731.TAA31534@maestria.wu-wien.ac.at> Message-ID: <14211.37769.349229.720435@anthem.cnri.reston.va.us> >>>>> "GG" == Gerhard Gonter writes: GG> Huh? Did that posting hide in a mail queue for 2.5 months?? Yes. Suffice to say the logjam on python.org is now getting cleared ;) -Barry From jeffh@streek.com Wed Jul 7 19:07:08 1999 From: jeffh@streek.com (Jeff Hahn) Date: Wed, 7 Jul 1999 13:07:08 -0500 Subject: [Mailman-Developers] FW: Returned mail: unknown mailer error 1 Message-ID: <004801bec8a3$871cf940$1e0a5ad1@SINGSING.STREEK.COM> A mail message with the following To: line generated this error... "To: :" (The following message has been "somewhat" sanitized) -Jeff -----Original Message----- From: Mail Delivery Subsystem [mailto:Postmaster@rikers.streek.com] Sent: Wednesday, July 07, 1999 7:21 AM To: xxx-request@xxx.com Subject: Returned mail: unknown mailer error 1 The original message was received at Wed, 7 Jul 1999 07:20:17 -0500 from maillist@xxx.xxx.com [xxx.xx.xx.xx] ----- The following addresses had permanent fatal errors ----- "|/home/mailman/MM/mail/wrapper post xxx" (expanded from: ) ----- Transcript of session follows ----- Traceback (innermost last): File "/home/mailman/MM/scripts/post", line 73, in ? mlist.Post(msg, approved=fromusenet) File "/home/mailman/MM/Mailman/MailList.py", line 1243, in Post if (self.require_explicit_destination and File "/home/mailman/MM/Mailman/MailList.py", line 1081, in HasExplicitDest for recip in msg.getaddrlist('to') + msg.getaddrlist('cc'): File "/home/mailman/MM/Mailman/pythonlib/rfc822.py", line 320, in getaddrlist return a.getaddrlist() File "/home/mailman/MM/Mailman/pythonlib/rfc822.py", line 496, in getaddrlist ad = self.getaddress() File "/home/mailman/MM/Mailman/pythonlib/rfc822.py", line 533, in getaddress if self.field[self.pos] == ';': IndexError: string index out of range 554 "|/home/mailman/MM/mail/wrapper post xxx"... unknown mailer error 1 From dragondm@integral.org Wed Jul 7 20:25:37 1999 From: dragondm@integral.org (The Dragon De Monsyne) Date: Wed, 7 Jul 1999 14:25:37 -0500 (CDT) Subject: [Mailman-Developers] automatically generated password too complicated? In-Reply-To: <199904201821.UAA20318@maestria.wu-wien.ac.at> Message-ID: On Tue, 20 Apr 1999, Gerhard Gonter wrote: > Some of our users complained about the automatically generated > passwords that are sent out when a list is imported or if an admin > subscribes someone. Especially the ` and ^ characters are major > problem because these may be treated as parts of composite characters > in some enviroments (` followed by a might be displayed as the same > character as à in HTML) and so on. Also, upper case characters > impose an extra mental burden ;) > Hm... I've long been using a replacement for the standard random password generator that greates three word phrases separated by dashes (such as 'wise-red-fox') The words are randomly picked from a list for each position. with about 20-50 words in each list there's abt 100 thousand combos. If the list of words are picked right, the password phrases 'sort of' make sense, and thus are easy to remember. (the caveat being the fact that since the phrases are words there is a language issue... Whatever) -The Dragon De Monsyne From hhielscher@unternehmen.com Mon Jul 5 22:03:40 1999 From: hhielscher@unternehmen.com (Helge Hielscher) Date: Mon, 05 Jul 1999 23:03:40 +0200 Subject: [Mailman-Developers] Re: Mailman-Developers digest References: <199907020500.BAA28872@python.org> Message-ID: <37811DAC.5CAA465F@unternehmen.com> Hello, Some days ago I joined the list and I wonder why the Mailman-Users list´s digest is in MIME but not the developer digest where the mails are only seperated with --__--__-- which makes it harder to read. Who can/may change that behavior? BTW are HTML Index Digests implemented in Mailman? Helge From dragondm@integral.org Fri Jul 9 04:35:26 1999 From: dragondm@integral.org (The Dragon De Monsyne) Date: Thu, 8 Jul 1999 22:35:26 -0500 (CDT) Subject: [Mailman-Developers] Performance problems and MailMan In-Reply-To: <14201.26521.848925.327481@anthem.cnri.reston.va.us> Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --YhIK0mKoxU Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: message body text > Just a quick note 'cause I have very little time. I'm currently > seeing python.org massively pegged, and Guido and I were talking about > some Python tools we'd like to develop that would help debug > situations like this. What I wanted was something like gdb's ability > to attach to and print stack traces of running external programs. We > got into some brainstorming and came up with A Certified Very Cool > Trick[1]. > > This yielded a traceback for where at least two pegged processes are > spinning. Seems to make sense, but I'm not very familar with the > archiving guts, so I post this traceback to spur some discussion. > Maybe Scott or Harald can craft a fix. Hmm... A few thoughts.. I've never seen the load problem on my mailman site, even though I run several reasonabally well trafficked lists, HOWEVER, I run a slightly customized version of HyperArch.py which stil.l uses bsddb for data storage. Also, my site does not immedeately archive messages, it runs an archiving cronjob every few hours.(it still dosen't draw much cpu whence the cronjob kicks in, tho) really, this archiving system was never meant to be used in the current method of operation (being invoked on each incoming message), and it's design is probably rather non-optimal for this use. It spends substantial time building & tearing down & (un)pickling various structures incurring a bit of overhead. -The Dragon De Monsyne --YhIK0mKoxU-- From bwarsaw@python.org Fri Jul 9 04:53:40 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Thu, 8 Jul 1999 23:53:40 -0400 (EDT) Subject: [Mailman-Developers] Performance problems and MailMan References: <14201.26521.848925.327481@anthem.cnri.reston.va.us> Message-ID: <14213.29252.289352.684394@anthem.cnri.reston.va.us> >>>>> "TDDM" == The Dragon De Monsyne writes: TDDM> Hmm... A few thoughts.. I've never seen the load TDDM> problem on my mailman site, even though I run several TDDM> reasonabally well trafficked lists, HOWEVER, I run a TDDM> slightly customized version of HyperArch.py which stil.l TDDM> uses bsddb for data storage. TDDM> Also, my site does not immedeately archive messages, it runs TDDM> an archiving cronjob every few hours.(it still dosen't draw TDDM> much cpu whence the cronjob kicks in, tho) Both those differences (using bsddb and not archiving immediately) explains why you wouldn't see the hit. The bug (now fixed) was in the DumbBTree implementation. TDDM> really, this archiving system was never meant to be TDDM> used in the current method of operation (being invoked on TDDM> each incoming message), and it's design is probably rather TDDM> non-optimal for this use. It spends substantial time TDDM> building & tearing down & (un)pickling various structures TDDM> incurring a bit of overhead. Wonderful understatement Dragon! :) Running with the patches in the CVS tree, I think the current system can work for a site as heavily trafficked as python.org, but it is very inefficient. Maybe we should document that for high traffic sites, you might want to use an external archiver which only runs from a cronjob. Unfortunately, I haven't done this, so if anybody can contribute a HOWTO, I'd appreciate it. -Barry From bwarsaw@cnri.reston.va.us Sat Jul 10 18:00:53 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Sat, 10 Jul 1999 13:00:53 -0400 (EDT) Subject: [Mailman-Developers] (no subject) Message-ID: <14215.31813.854234.222802@anthem.cnri.reston.va.us> Cc python-announce@python.org Subject: [ANNOUNCE] Mailman 1.0rc3 X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) Reply-To: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) X-Attribution: BAW X-Oblique-Strategy: A very small object. Its center X-Url: http://www.python.org/~bwarsaw X-Face: bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass bass Hi folks, Mailman 1.0 release candidate 3 (1.0rc3) has just been uploaded to www.list.org. This is an important bug fix release which primarily fixes a performance problem in the archiver. Since the GNU folks are getting ready to put together their next source CDROM, this increases the possibility that 1.0rc3 will be short-lived -- with 1.0 final right around the corner! From the NEWS file: 1.0rc3 - new script bin/check_perms which checks (and optionally fixes) the permissions and group ownerships of the files in your Mailman installation. - Removed a bottleneck in the archiving code that was causing performance problems on highly loaded servers. - The code that saves a list's state and configuration database has been made more robust. - Additional exception handlers have been added in several places to alleviate problems with Mailman bombing out when it really would be better to print/log a helpful message. - The "password" mail command will now mail back the sender's subscription password when given with no arguments. - The embarrassing subject-prefixing bug present in rc2 has been fixed. - A small (but nice :) collection of other squashed bugs. On behalf of the entire development team, -Barry From ppp@theporch.com Sat Jul 10 23:28:11 1999 From: ppp@theporch.com (Phillip Porch) Date: Sat, 10 Jul 1999 17:28:11 -0500 (CDT) Subject: [Mailman-Developers] Re: what is being checked? In-Reply-To: Message-ID: On Sat, 10 Jul 1999, Stephen Modena wrote: > Phil-- > > >From MindSpring, I change my "return address" inside of Eudora to > "shimshon@theporch.com". Then I sent a "who" request to test-request. > I succeeded in mailing the list of subscribers to shimshon@thePorch.com. > > I did the same thing giving "ab4el@MindSpring.com" and it explicitly > refused me because I am not a subscriber. That is yet another setting. I can set the list to show the subscription list to anyone, to list subscribers or only to the list admin. > > My suggestion is: these sort of things should require the "password=<>" on > the same line as the request. If I am a legitimate subscriber, I can > punch the HTML button to get my password mailed to me...it's not like I > have to keep it on a post and would be an inconvenient imposition to > require that parameter as part of the request. > I think it is the way it is to accomidate the different privacy settings. If I had set the list up where the subscribers were veiwable to anyone who had not set themselves as hidden, then it would not make sense to have the password. I would guess it would be relatively easy to check the list settings and if it was restricted, it would require a password. Again, I'll forward this to the mailman-developer list. > Now for a positive comment: I switch my password to a pass phrase and it > took it...and it can use it from the HTML page. I'm about to try it in an > email. > > -- > 73/Steve/AB4EL shimshon@thePorch.thePorch.com QTH: Raleigh, NC > -- Phillip P. Porch NIC:PP1573 finger for http://www.theporch.com UTM - 16 514548E 3994397N PGP key Key fingerprint = F9 4D 41 7D 25 31 A5 1F 65 93 6B 84 A9 F9 5B 90 From ricardo@miss-janet.com Sun Jul 11 22:01:47 1999 From: ricardo@miss-janet.com (Ricardo Kustner) Date: Sun, 11 Jul 1999 23:01:47 +0200 (CEST) Subject: [Mailman-Developers] rc3 check_perms : adm.pw ?? Message-ID: Hi, first of all thanks for adding a permission check script to the new mailman release! :) anyway, after upgrading to rc3, i immediately tried out the permission script just to see if it works... at the end it gives me an error cause it's looking for a ~mailman/data/adm.pw file... but that one doesn't exist anywhere in my mailman tree?? Traceback (innermost last): File "./check_perms", line 164, in ? checkadminpw() File "./check_perms", line 128, in checkadminpw mode = statmode(adminpw) File "./check_perms", line 39, in statmode return os.stat(path)[ST_MODE] OSError: [Errno 2] No such file or directory: '/usr/local/mailman/data/adm.pw' Ricardo. -- From root@theporch.com Mon Jul 12 01:00:56 1999 From: root@theporch.com (Phillip Porch) Date: Sun, 11 Jul 1999 19:00:56 -0500 (CDT) Subject: [Mailman-Developers] Feature Request Message-ID: My partner has been administering several lists here under listproc 8.2 and we have been considering moving to mailman as our list server. His main complaint is that he has been using the subscriber file to store extra information about subscribers under listproc but can't under mailman. How difficult would it be to add a freeform text field associated with an email name that would only be accessible to the list owner or site manager? -- Phillip P. Porch NIC:PP1573 finger for http://www.theporch.com UTM - 16 514548E 3994397N PGP key From Dionysos@Dionysia.org Mon Jul 12 04:56:37 1999 From: Dionysos@Dionysia.org (Dan Delaney) Date: Sun, 11 Jul 1999 23:56:37 -0400 (EDT) Subject: [Mailman-Developers] Fix for bug "incoming/64"--the prefix replication problem Message-ID: Hi all. I just transferred all of my majordomo lists over to Mailman and I must say, it is quite nice. There are a few things I'd like to see in the future, but they would just be icing on the cake. There is only one actual problem I've had. When someone replies to a message and his program prepends "Re: " to the subject, Mailman then adds a NEW list prefix to the subject line every time, even if there is already one somewhere in the subject line, so we end up with something like this: Subject: [MyList] Re: [MyList] Re: [MyList] A few observations After a while, the subject lines accumulate quite a few of those prefixes, which I think is a BIG problem. I was looking at the code in the MailList.py program, and it looks like the code only checks to see if the prefix is already present AT THE BEGINNING of the line before it adds the prefix, thus ignoring the fact that it might be there after a "Re: " or "Fwd: ". Here are the relevant lines from MailList.py: -------------------------------------------------------------------- 1267: # Prepend the subject_prefix to the subject line. 1268: subj = msg.getheader('subject') 1269: prefix = self.subject_prefix 1270: if not subj: 1271: msg.SetHeader('Subject', '%s(no subject)' % prefix) *1272: elif prefix and not re.match(re.escape(self.subject_prefix), *1273: subj, re.I): 1274: msg.SetHeader('Subject', '%s%s' % (prefix, subj)) -------------------------------------------------------------------- The simplest solution to this problem is to replace the "re.match" in line 1272 with "re.search". The difference between the two is that re.match only matches the pattern if it occurs at the BEGINNING of the line, whereas re.search will match the pattern anywhere in the line. I've already tried this in my installation and it works quite well. In this case, after someone sends a message with a subject something like this... Subject: [MyList] Hello there ...all of the following replies, no matter how many there are, will never add another [MyList] prefix because it is already present SOMEWHERE in the subject. Thus all subsequent replies will have the following as their subject: Subject: Re: [MyList] Hello there Now that would be sufficient to at least fix the problem of "subject prefix replication". However, I still am not satisfied with the result because now the prefix is not the FIRST thing in the subject. Being a graphic designer, I am particularly sensitive to the visual aspect of all of this, and to me it would be much more aesthetically pleasing to have the list name tags all lined up in my inbox list of messages, rather than some of them offset four places from the left edge. One way to get around this would be to use an "re.sub" method to actually strip out all occurances of the list tag in the subject line before adding another one to the beginning. That would be great except for one thing: that would lead to the build up of "Re: "s! After a while you would end up with: Subject: [MyList] Re: Re: RE: Re: Hello there So, what you have to do is remove all of the extra "Re: "s as well. Which brings me to another problem: "RE: and FWD: replication", which is a big problem with email in general (especially with all this damn chain-letter spam!). And since the email programs aren't doing their job by cleaning up that crapola, why not have the mailing list manager do it? I wrote a mailing list archive program a while back which does this and it really helps with "threading" the messages based on the subject lines. (In fact, I store the subject without ANY 'Re:'s or 'Fwd:'s so that the subjects will be exactly the same, and I save the fact that it is a reply in a separate field. You can check out the archive if you like at www.LouisvilleTimes.org/harmonet/). Anyway, this would make the following subject line... Subject: Re: [MyList] Re: Fwd: [MyList] Re: Hello there (fwd) ...end up looking like this: Subject: [MyList] Re: Hello there The result is that your list messages always have readable, comprehendable subjects that don't take 5 minutes to decode, AND your list archives are much more functional and easier to browse because messages which REALLY have the same subject won't be bogged down with 'Re:'s and 'Fwd:'s. This is the basic procedure: 1. First, with a regex substitution, strip the subject line of all occurances of the list's subject prefix. 2. Then, using a case-insensitive regex, check to see if the subject BEGINS with "fw: " or "fwd: ", or if it ends with a "(fwd)". If so, set a second prefix variable (prefix2) to "Fwd: " to be added after the first prefix (the one from the list). 3. Next, check to see if the subject line begins with an "re: ". If it does, this takes precedence over the "Fwd: ", so just go ahead and set prefix2 to "Re: " even if it already contains "Fwd: " 4. Next, with a case-insensitive regex substitution, remove ALL instances of "re: ", "fw: ", "fwd: ", and "(fwd)" from the subject. 5. Finally, add both the list prefix and the new prefix2 to the beginning of the subject. So, here's a replacement for the segment of code that I quoted earlier from the MailList.py program which accomplishes this task quite well (I'm using it in my Mailman installation right now): -------------------------------------------------------------------- # Prepend the subject_prefix to the subject line. subj = msg.getheader('subject') prefix = self.subject_prefix # If there's no subject, give it one if not subj: msg.SetHeader('Subject', '%s(no subject)' % prefix) else: # Delete all occurances of the prefix from the subject if prefix: subj = re.sub(re.escape(self.subject_prefix), '', subj) # Check to see if the message is a reply or forward prefix2 = '' if re.search('^fwd*: |\(fwd\)', subj, re.I): prefix2 = 'Fwd: ' if re.match('re: ', subj, re.I): prefix2 = 'Re: ' # Clean up all that 're:' and 'fwd: ' garbage subj = re.sub('[rR][eE]: | *\(*[fF][wW][dD]*\)*:* *', '', subj) # Set the new subject line in place msg.SetHeader('Subject', '%s%s%s' % (prefix, prefix2, subj)) -------------------------------------------------------------------- Give it a try for a while on your own mailing lists. I think you'll like the results. Cheers. -- Dan ________________________________________________________________________ Dionysos@Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html From Dionysos@Dionysia.org Mon Jul 12 16:12:34 1999 From: Dionysos@Dionysia.org (Dan Delaney) Date: Mon, 12 Jul 1999 11:12:34 -0400 Subject: [Mailman-Developers] Documentation for config.db file? Message-ID: Is there any documentation for the format of the config.db file? Here's my situation. I've written a large database system for the membership information of an organization. Each member of the organization can login to the website with a password and edit his or her own member information (address, bio, password, etc). When a member makes a change to his email address, or when I add a new member, the program automatically makes a change to the majordomo list file, which is simply a text file with the email addresses in it. Well, now that I've switched the list to Mailman, I can no longer do this because I don't know how Mailman stores the subscriber info. I can easily modify a db file with PHP, I just need to know how the info in laid out in the file. Thanks. --Dan ________________________________________________________________________ Dionysos@Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Mon Jul 12 16:35:04 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 12 Jul 1999 11:35:04 -0400 (EDT) Subject: [Mailman-Developers] Feature Request References: Message-ID: <14218.2856.81492.482042@anthem.cnri.reston.va.us> >>>>> "PP" == Phillip Porch writes: PP> My partner has been administering several lists here under PP> listproc 8.2 and we have been considering moving to mailman as PP> our list server. His main complaint is that he has been using PP> the subscriber file to store extra information about PP> subscribers under listproc but can't under mailman. How PP> difficult would it be to add a freeform text field associated PP> with an email name that would only be accessible to the list PP> owner or site manager? Since the data structure that list information gets stored into is just a dictionary (glommed from attributes on the class), you could probably store all kinds of extra information in there. The trick would be hooking it up to the Web interface, but if that's not important, you can do all kinds of things by hacking a little Python into a command line script. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Mon Jul 12 16:52:41 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 12 Jul 1999 11:52:41 -0400 (EDT) Subject: [Mailman-Developers] Fix for bug "incoming/64"--the prefix replication problem References: Message-ID: <14218.3913.166102.299860@anthem.cnri.reston.va.us> >>>>> "DD" == Dan Delaney writes: DD> The simplest solution to this problem is to replace the DD> "re.match" in line 1272 with "re.search". Harald already made this change for 1.0rc3. The rest sounds interesting, but I probably it'll definitely have to wait until after 1.0 final. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Mon Jul 12 17:36:35 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 12 Jul 1999 12:36:35 -0400 (EDT) Subject: [Mailman-Developers] Documentation for config.db file? References: Message-ID: <14218.6547.205838.638118@anthem.cnri.reston.va.us> >>>>> "DD" == Dan Delaney writes: DD> Is there any documentation for the format of the config.db DD> file? It is a Python marshal containing a Python dictionary. The keys are taken from the attributes on the MailList object. Only the attributes which don't start with a leading underscore are saved. DD> Here's my situation. I've written a large database system for DD> the membership information of an organization. Each member of DD> the organization can login to the website with a password and DD> edit his or her own member information (address, bio, DD> password, etc). When a member makes a change to his email DD> address, or when I add a new member, the program automatically DD> makes a change to the majordomo list file, which is simply a DD> text file with the email addresses in it. Well, now that I've DD> switched the list to Mailman, I can no longer do this because DD> I don't know how Mailman stores the subscriber info. I can DD> easily modify a db file with PHP, I just need to know how the DD> info in laid out in the file. We do something very similar with the PSA membership. We use bin/sync_members to automate synchronizing the mailing list with our PSA members database, but depending on the information you've got, it's possible that bin/add_members or bin/remove_members might be more appropriate. If not fit your bill exactly, remember that this stuff is very easy to code in Python. Take a look at the three scripts above for examples. -Barry From Nigel.Metheringham@vdata.co.uk Tue Jul 13 18:05:12 1999 From: Nigel.Metheringham@vdata.co.uk (Nigel Metheringham) Date: Tue, 13 Jul 1999 18:05:12 +0100 Subject: [Mailman-Developers] Further on jitterbug open/75 - timezone handling in archiver Message-ID: [Note: there is no way for me as a bug reporter to make a follow up note into the bug report - ie I have fixed/worked round this for myself but am having to put it to the list since I can't add a comment to the bug report...] The problem was that I was seeing a wierd time skew on my archives dating back to the point where DST kicked in (suspicious eh). Basically I had 2 archives for each week - one with the correct date on - ie Monday 12 July and the other with just one or two messages with a duff date on - specifically in this example it would be Monday 13 July The code in HyperArch.py has:- def dateToVolName(self,date): datetuple=time.gmtime(date) It appears the later call to strftime is applying its own localtime rules. This may be a libc oddity - I am not good enough on POSIX to know that. If you change the gmtime call to a localtime then it all works correctly. For the record this is on a Red Hat 6.0 system - so Python 1.5.1, glibc 2.1. This fix will have side effects that your archive roll over changes with the server localtime rather than GMT - I don't know if this is a problem for people. Nigel. -- [ Nigel Metheringham Nigel.Metheringham@VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] From da@ski.org Thu Jul 15 05:42:08 1999 From: da@ski.org (David Ascher) Date: Wed, 14 Jul 1999 21:42:08 -0700 (Pacific Daylight Time) Subject: [Mailman-Developers] mailman & unsubs Message-ID: I subscribe to lots of mailman lists. Sometimes, mailman disables my email address. I have no doubt that it's for a good reason. However, that reason is for a certain group of users fairly temporary (down server). As it stands, I periodically find out that I've been disabled on fairly quiet lists that I don't expect to read every day. It'd be nice if mailman could 'ping' the email address periodically (once a week?) to find out if the problem is resolved. Something progressively more expensive like if ping_ok and SMTP_VRFY_ok and first_email_goes_in_queue_goes_through: undisable_email() would do the job in 96% of the cases w/ low overhead, I suspect. --david From lannert@uni-duesseldorf.de Thu Jul 15 08:44:33 1999 From: lannert@uni-duesseldorf.de (lannert@uni-duesseldorf.de) Date: Thu, 15 Jul 1999 09:44:33 +0200 (MEST) Subject: [Mailman-Developers] mailman & unsubs In-Reply-To: from David Ascher at "Jul 14, 99 09:42:08 pm" Message-ID: <19990715074433.14286.qmail@lannert.rz.uni-duesseldorf.de> "David Ascher" wrote: > if ping_ok and SMTP_VRFY_ok and first_email_goes_in_queue_goes_through: > undisable_email() > > would do the job in 96% of the cases w/ low overhead, I suspect. There are quite a few MTAs that don't perform VRFY, either because they are configured like this or because they can't do it at all (e.g. qmail). Maybe "(SMTP_VRFY_ok or SMTP_VRFY_rej_252)" would do an even better job. Detlef From evaldas.auryla@pheur.org Thu Jul 15 14:11:18 1999 From: evaldas.auryla@pheur.org (Evaldas Auryla) Date: Thu, 15 Jul 1999 15:11:18 +0200 Subject: [Mailman-Developers] Cookies and MSIE 4.x Message-ID: <378DDDF6.7D6F3ACF@pheur.org> Hello! It seems like MS Internet Explorer 4.x (except 4.7x for NT) is not following RFC 2109 and storing cookies sent by Mailman _without_ dbl.quotes "". Mailman fails verifying these cookies, because Cookie.py module thinks the incoming cookie does not contain any special chars (not true) as it is _not_ enclosed with dbl.quotes so decoding goes wrong. The consequence is that for the administration of the Mailman over the web you have to re-enter password to authenticate on every page. Annoying. I made a little patch to SecurityManager.py to get around this problem, experienced in Mailman 1.0rc2 and 1.0rc3, (for the Mailman in fact it's a feature, not a bug :-)) and submitted it to the JitterBug database http://www.python.org/mailman-bugs/ . Does anybody had something similar ? Regards -- Evaldas From jc@xxxxxxxxxxxxx.com Thu Jul 15 21:52:49 1999 From: jc@xxxxxxxxxxxxx.com (Jonathan Clark) Date: Thu, 15 Jul 1999 13:52:49 -0700 Subject: [Mailman-Developers] spam control Message-ID: <000801becf04$02f19c40$0202a8c0@jitit.com> This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BECEC9.536D8F70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi guys, I just tried out mailman for the first time and I like it a = lot. I noticed there is some attempt to stop spam crawlers. However, some of the email addresses displayed (like the list owner) are shown in the clear. Here is a little trick I use to allow mailto: to work correctly = and at the same time stop spam crawlers from gathering email addresses. Email: jc at jonathanclark.com When this is displayed on a browser that has java script turned off, it will only display: "Email: jc at jonathanclark.com" When the end user has javascript on (as most people do), they will see the same thing, but when they click on it they will get the correct mailto: command to launch their mail program. Since crawlers don't execute javascript, they can't collect the name. Generally I don't worry about non java script but I recently turned it off because of those annoying (open-another-window-on-close) tricks people do. I think it would be great if mailman used (or had the option) to use this technique for all email addresses it displayed. Jonathan P.S. I'm not on the list, so cc: me any discussion on this. Thanks! ------=_NextPart_000_0005_01BECEC9.536D8F70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Hi guys,  I just tried out mailman = for the=20 first time and I like it a lot.
    I noticed there is some attempt = to stop spam=20 crawlers.  However, some
    of the email addresses displayed (like = the list=20 owner) are shown in the
    clear.   Here is a little = trick I use to=20 allow mailto: to work correctly and
    at the same time stop spam crawlers = from gathering=20 email addresses.
     
    Email: <script=20 language=3D"JavaScript"><!--
    document.write("<a=20 href=3Dmai");
    document.write("lto:","jc","@","jonathanclark",".com>= ");
    //=20 --></script>
    jc at jonathanclark.com
    <script=20 language=3D"JavaScript"><!--
    document.write("</a>");
    //= =20 --></script>
     
    When this is displayed on a browser = that has java=20 script turned off,
    it will only display:   = "Email: jc at=20 jonathanclark.com"
    When the end user has javascript on (as = most people=20 do), they
    will see the same thing, but when they = click on it=20 they will get
    the correct mailto: command to launch = their mail=20 program.
    Since crawlers don't execute = javascript, they can't=20 collect the
    name.  Generally I don't worry = about non java=20 script but I recently
    turned it off because of those annoying = (open-another-window-on-close)
    tricks people do.
     
    I think it would be great if mailman = used (or had=20 the option)
    to use this technique for all email = addresses it=20 displayed.
     
     
    Jonathan
     
    P.S. I'm not on the list, so cc: me any = discussion=20 on this.  Thanks!
    ------=_NextPart_000_0005_01BECEC9.536D8F70-- From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Jul 16 20:57:08 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 16 Jul 1999 15:57:08 -0400 (EDT) Subject: [Mailman-Developers] FW: Returned mail: unknown mailer error 1 References: <004801bec8a3$871cf940$1e0a5ad1@SINGSING.STREEK.COM> Message-ID: <14223.36500.291673.766679@anthem.cnri.reston.va.us> >>>>> "JH" == Jeff Hahn writes: JH> A mail message with the following To: line generated this JH> error... JH> "To: :" JH> (The following message has been "somewhat" sanitized) This is actually a bug in rfc822.py! It has been fixed in Python's CVS tree, and I copied the latest rfc822.py to Mailman/pythonlib, so it'll be fixed in 1.0 final. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Jul 16 21:05:49 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 16 Jul 1999 16:05:49 -0400 (EDT) Subject: [Mailman-Developers] Re: Mailman-Developers digest References: <199907020500.BAA28872@python.org> <37811DAC.5CAA465F@unternehmen.com> Message-ID: <14223.37021.88265.917569@anthem.cnri.reston.va.us> >>>>> "HH" == Helge Hielscher writes: HH> Some days ago I joined the list and I wonder why the HH> Mailman-Users list´s digest is in MIME but not the developer HH> digest where the mails are only seperated with HH> --__--__-- HH> which makes it harder to read. Who can/may change that HH> behavior? Check your subscription options. You can change your personal options to deliver either plain text or MIME, with IIRC plain text as the default. HH> BTW are HTML Index Digests implemented in Mailman? Not sure what you mean, but IMHO HTML in email is evil! :) But perhaps I misunderstand what you're asking for? -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sun Jul 18 21:10:46 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sun, 18 Jul 1999 16:10:46 -0400 (EDT) Subject: [Mailman-Developers] mailman & unsubs References: Message-ID: <14226.13510.670256.292606@anthem.cnri.reston.va.us> >>>>> "DA" == David Ascher writes: DA> Sometimes, mailman disables my email address. I have no doubt DA> that it's for a good reason. However, that reason is for a DA> certain group of users fairly temporary (down server). As it DA> stands, I periodically find out that I've been disabled on DA> fairly quiet lists that I don't expect to read every day. DA> It'd be nice if mailman could 'ping' the email address DA> periodically (once a week?) to find out if the problem is DA> resolved. You haven't read our TODO list have ya? :) Okay, it's buried in there (it's a biiiig todo list!): *Bounce handling - Reminders to disabled addresses. The idea is that if an addr is disabled due to bouncing, we should send out periodic reminders. We may want to do this for explicitly disabled addrs too, but perhaps with a different schedule. -Barry From Harald.Meland@usit.uio.no Mon Jul 19 16:36:49 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 19 Jul 1999 17:36:49 +0200 Subject: [Mailman-Developers] patch candidate for MailList.Save() In-Reply-To: "Barry A. Warsaw"'s message of "Wed, 30 Jun 1999 12:56:14 -0400 (EDT)" References: <14202.19502.341621.221263@anthem.cnri.reston.va.us> Message-ID: [Barry A. Warsaw] > The idea is that the marshal is first written to a temp file called > config.db.tmp.. If this succeeds completely, then > > 1) config.db.last is unlinked > 2) a hard link config.db.last -> config.db is created > 3) a hard link config.db -> config.db.tmp. is created > 4) config.db.tmp. is unlinked > > Comments? You missed 2.5) config.db is removed which constitutes a race condition -- I think the below patch fixes that (but as you say, this really is crucial code to get right, so I'm posting it here for others to comment before committing): Index: MailList.py =================================================================== RCS file: /export/public/cvsroot/mailman/Mailman/MailList.py,v retrieving revision 1.130 diff -u -r1.130 MailList.py --- MailList.py 1999/07/18 17:26:55 1.130 +++ MailList.py 1999/07/19 15:09:08 @@ -759,6 +759,8 @@ fname = os.path.join(self._full_path, 'config.db') fname_tmp = fname + '.tmp.' + `os.getpid()` fname_last = fname + ".last" + # Make config.db unreadable by `other', as it contains all the + # list members' passwords (in clear text). omask = os.umask(007) try: try: @@ -771,10 +773,14 @@ 'Failed config.db file write, retaining old state' '\n %s' % `status.args`) Utils.reraise() - # now move config.db -> config.db.last - # then move config.db.tmp.xxx -> config.db - aside_new(fname, fname_last) - aside_new(fname_tmp, fname) + # Now do config.db.tmp.xxx -> config.db -> config.db.last + # rotation -- safely. + if os.path.exists(fname_last): + os.unlink(fname_last) + os.link(fname, fname_last) + os.rename(fname_tmp, fname) +## aside_new(fname, fname_last) +## aside_new(fname_tmp, fname) finally: os.umask(omask) self.CheckHTMLArchiveDir() After this change, the function aside_new() in MailList.py can be removed (or moved to Utils.py), as it isn't being used anywhere else. -- Harald From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Mon Jul 19 23:30:17 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 19 Jul 1999 18:30:17 -0400 (EDT) Subject: [Mailman-Developers] patch candidate for MailList.Save() References: <14202.19502.341621.221263@anthem.cnri.reston.va.us> Message-ID: <14227.42745.327704.776954@anthem.cnri.reston.va.us> >>>>> "HM" == Harald Meland writes: HM> You missed HM> 2.5) config.db is removed HM> which constitutes a race condition -- I think the below patch HM> fixes that (but as you say, this really is crucial code to get HM> right, so I'm posting it here for others to comment before HM> committing): Arg! You're right of course. Here's a slightly reworked version of your patch. Also, not committed yet, but seems to work for me. -Barry -------------------- snip snip -------------------- Index: MailList.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/MailList.py,v retrieving revision 1.130 diff -c -r1.130 MailList.py *** MailList.py 1999/07/18 17:26:55 1.130 --- MailList.py 1999/07/19 22:22:56 *************** *** 26,31 **** --- 26,32 ---- 'for the site?') import sys, os, marshal, string, posixfile, time + import errno import re import Utils import Errors *************** *** 759,764 **** --- 760,767 ---- fname = os.path.join(self._full_path, 'config.db') fname_tmp = fname + '.tmp.' + `os.getpid()` fname_last = fname + ".last" + # Make config.db unreadable by `other', as it contains all the + # list members' passwords (in clear text). omask = os.umask(007) try: try: *************** *** 771,780 **** 'Failed config.db file write, retaining old state' '\n %s' % `status.args`) Utils.reraise() ! # now move config.db -> config.db.last ! # then move config.db.tmp.xxx -> config.db ! aside_new(fname, fname_last) ! aside_new(fname_tmp, fname) finally: os.umask(omask) self.CheckHTMLArchiveDir() --- 774,789 ---- 'Failed config.db file write, retaining old state' '\n %s' % `status.args`) Utils.reraise() ! # Now do config.db.tmp.xxx -> config.db -> config.db.last ! # rotation -- safely. ! try: ! # might not exist yet ! os.unlink(fname_last) ! except os.error, (code, msg): ! if code <> errno.ENOENT: ! Utils.reraise() ! os.link(fname, fname_last) ! os.rename(fname_tmp, fname) finally: os.umask(omask) self.CheckHTMLArchiveDir() *************** *** 1376,1397 **** return ("<%s.%s %s%s at %s>" % (self.__module__, self.__class__.__name__, `self._internal_name`, status, hex(id(self))[2:])) - - def aside_new(old_name, new_name, reopen=0): - """Utility to move aside a file, optionally returning a fresh open version. - - We ensure maintanance of proper umask in the process.""" - # Make config.db unreadable by `other', as it contains all the list - # members' passwords (in clear text). - ou = os.umask(007) - try: - if os.path.exists(new_name): - os.unlink(new_name) - if os.path.exists(old_name): - os.link(old_name, new_name) - os.unlink(old_name) - if reopen: - file = open(old_name, 'w') - return file - finally: - os.umask(ou) --- 1385,1387 ---- From marc@merlins.org Tue Jul 20 23:42:28 1999 From: marc@merlins.org (Marc Merlin) Date: Tue, 20 Jul 1999 15:42:28 -0700 Subject: [Mailman-Developers] Mailman v 1.0rc1 Message-ID: <19990720154227.A6911@marc.merlins.org> First off, I didn't install it, nor do I have access to it, so I can't really give more information than what's in this mail unfortunately. However if the bug hasn't been found and fixed yet, this report should be enough to find it. I had a user that was sending mail with the following in the "From: " field: Jason T. Collins Mailman would send mail back to jasont.collins@valinux.com and say the person wasn't subscribed. The problem went away when I had him remove the "." after the T in his name. My guess is that some regular expression in mailman is being fooled by the "." Marc -- Microsoft is to software what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ (friendly to non IE browsers) Finger marc_f@merlins.org for PGP key and other contact information From hhielscher@unternehmen.com Tue Jul 20 01:46:37 1999 From: hhielscher@unternehmen.com (Helge Hielscher) Date: Tue, 20 Jul 1999 02:46:37 +0200 Subject: [Mailman-Developers] html index References: <199907020500.BAA28872@python.org> <37811DAC.5CAA465F@unternehmen.com> <14223.37021.88265.917569@anthem.cnri.reston.va.us> Message-ID: <3793C6EC.9B581BBB@unternehmen.com> Hello Barry, you were right, the MIME feature was switched off. So hopefully the next digest will be in MIME. To the html index: it is only an index in the mail you see first like:
  • A doubt on scalability.... (2)
  • AW: Multiple servlets and a shared class (2)
  • REDHAT 5.2 / Apache / JServ you click and get here
  • A doubt on scalability....
  • AW: Multiple servlets and a shared class
  • REDHAT 5.2 / Apache / JServ later with links to the mails itself like you get here: Content-ID: <13761@JAVA.SUN.COM> Content-Type: message/rfc822 Date: Thu, 15 Jul 1999 01:04:08 -0700 From: Hans Bergsten Subject: Re: A doubt on scalability.... MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit and so on. That I think makes it very comfortable to read some but not all mails. I am not sure if you can/should create a thread list like when reading news in HTML? Listserv only sorts after Name of the Thread and the Time I think. Regards, Helge From Harald.Meland@usit.uio.no Wed Jul 21 07:03:28 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 21 Jul 1999 08:03:28 +0200 Subject: [Mailman-Developers] Various In-Reply-To: Per Starback's message of "11 Jun 1999 15:33:07 +0200" References: Message-ID: [Per Starback] > * Privacy Options > I don't like the combined meanings of the fields A = "Restrict posting > privilege to list members?" and B = "Addresses of members accepted for > posting to this list without implicit approval requirement". [...] > Perhaps it would be better if A had three possible values: > Noone, Members only, Anyone. And then B always is a list of > *additional* addresses besides what option A states? Yup, I agree that a three-state switch might be more intuitive -- but I'm hoping we'll find some even more general "posting access control" configuration setting -- i.e. one might want to restrict postings to members and addresses in the example.com domain, or everyone but addresses in badboys.net, or even only addresses with a localpart matching "\w+\.\w+". Either way, I don't see this changing before 1.0. > * Digest-member options > > "Header added to every digest" is empty as the default value. > I would prefer if the whole > > Send xxx maillist submissions to [...] > When replying, please [...] > "Re: Contents of xxx digest...") > > blurb was there instead, so all of that could be edited. Noted. > * List-specific programs > > Something I'm missing from Smartlist which I have been using since > before is the possibility there of adjusting everything for a > particular list by making a special version of the list programs for > that list. In this way it would great if I could just put a changed > Digester.pyc (for example) in the directory for a particular list to > have that list use that one instead of the default one. > > This wouldn't be needed for most lists, or course, but still such a > minor(?) change would make it *possible* to do almost anything, > including stuff that there probably will be support for in the future > but that someone could need to fix "by hand" for one particular list > right now, and specialized stuff for which there never will be > generalized support. I don't think this would be a smart move -- it could potentially cause _serious_ troubles when the list-specific files (e.g. old, installed by some previous site-admin which is now long gone) assumes interfaces that the Mailman distribution (which we'd like people to be able to upgrade from time to time without too much trouble) are trying to move away from. -- Harald From Harald.Meland@usit.uio.no Wed Jul 21 08:47:42 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 21 Jul 1999 09:47:42 +0200 Subject: [Mailman-Developers] cookie problem ? In-Reply-To: Gergely Madarasz's message of "Mon, 5 Jul 1999 17:25:01 +0200 (METDST)" References: Message-ID: [Gergely Madarasz] > Hello, > > If I want to access the mailman pages thru a different url (like > http://somehost/cgi-bin/mailman/, the cgi-bin directory has a > symlink to mailman/cgi-bin) the cookie authentication is > problematic. Yup -- we wouldn't want browsers to send out Mailman cookies unless they actually are getting a Mailman page. Thus, the "path" setting of the Mailman-issued cookies are set to whatever the path part of mm_cfg.DEFAULT_URL is (i.e. normally "/mailman"). This means that Mailman cookies won't be sent to the server if you access the Mailman interface via some other CGI-script path. > It allows access for the first time but after that it wants > authentication again. Actually it is the password you send that gets you through the first time, and not any cookie. > Could this be fixed somehow ? I don't think we want to try being clever with any of the CGI environment variables for figuring out what URLs the cookies should be sent out for. > This way there wouldn't be need to configure the webserver to use > the /mailman/ alias. If you don't want to add the /mailman/ ScriptAlias (or whatever) to your web server configuration, Mailman's setting of mm_cfg.DEFAULT_URL should reflect this. This means that if you access all your Mailman CGI wrappers as e.g. , you should set DEFAULT_URL = "http://mailman-host/cgi-bin" in $prefix/Mailman/mm_cfg.py. Mailman cookies will then be sent out to any script in this cgi-bin directory. If you use both .../cgi-bin/wrappername and .../mailman/wrappername type URLs interchangeably, the cookies won't work for (at least) one of those -- so, you *shouldn't* use both types of URLs interchangeably. -- Harald From Harald.Meland@usit.uio.no Wed Jul 21 09:13:49 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 21 Jul 1999 10:13:49 +0200 Subject: [Mailman-Developers] Re: what is being checked? In-Reply-To: Phillip Porch's message of "Sat, 10 Jul 1999 17:28:11 -0500 (CDT)" References: Message-ID: [Phillip Porch] > > My suggestion is: these sort of things should require the "password=<>" on > > the same line as the request. If I am a legitimate subscriber, I can > > punch the HTML button to get my password mailed to me...it's not like I > > have to keep it on a post and would be an inconvenient imposition to > > require that parameter as part of the request. > > I think it is the way it is to accomidate the different privacy > settings. I'm not sure of the exact context here, but yes, different private_roster settings will give different results for the "who" mail command. * If "private_roster" is set to "List admin only", the "who" mail command will tell you "Private list: No one may see subscription list." * If set to "List members", it wil tell you "Private list: only members may see list of subscribers." unless the request sender address is a list member. This is the same algorithm that is used for deciding whether or not the "password" command with no arguments should mail back the member password or not -- so requiring a password to the "who" command in this case would just mean extra hassle, and not extra security. * If set to "Anyone", the roster will be mailed back without forther checking. In all cases only non-hidden member addresses are included in the roster. This all mimics the information available via the web interface closely. Does that answer the questions you have? -- Harald From Harald.Meland@usit.uio.no Wed Jul 21 10:02:43 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 21 Jul 1999 11:02:43 +0200 Subject: [Mailman-Developers] Fix for bug "incoming/64"--the prefix replication problem In-Reply-To: Dan Delaney's message of "Sun, 11 Jul 1999 23:56:37 -0400 (EDT)" References: Message-ID: [Dan Delaney] > Anyway, this would make the following subject line... > > Subject: Re: [MyList] Re: Fwd: [MyList] Re: Hello there (fwd) > > ...end up looking like this: > > Subject: [MyList] Re: Hello there So, if I send a mail with subject Subject: Administrivia: [foo] will be changed to [bar] Mailman should change it to Subject: [foo] Administrivia: will be changed to [bar] ? I don't think messing with the subject prefix to that extent is a good idea. Regarding stripping of consecutive "Re:" and "Fwd:" strings -- you'd still have problems with the nationalized versions of these ("SV:", "AD:", etc.) that some MUA vendors in their infinite wisdom have implemented, and besides this too have potential problems with stripping away substrings that really was meant to stay where they where. > The result is that your list messages always have readable, > comprehendable subjects that don't take 5 minutes to decode, AND > your list archives are much more functional and easier to browse > because messages which REALLY have the same subject won't be bogged > down with 'Re:'s and 'Fwd:'s. I think this "problem" should be solved in the user's MUA configuration (if the user wants the subjects mangled) and/or in the archiver thread generator. The archiver thread generator could be made to display sender address for all messages in the thread, but only display the subject at the top of the thread and every time the subject changes _substantially_. Non-substantial subject changes could e.g. be defined as changes which only include addition or removal of "Re:", "Fwd:" and instances of the subject prefix. The _real_ subjects, looking just the way they were sent (modulo subject prefix), would be available in the archive of each particular message. Example: Instead of having the archive thread view look like this: * [Mailman-Developers] foobar gazonk -- Harald Meland Re: [Mailman-Developers] foobar gazonk -- Barry A. Warsaw Re: [Mailman-Developers] florp -- Harald Meland it could look like this: * Harald Meland -- [Mailman-Developers] foobar gazonk Barry A. Warsaw Harald Meland -- [Mailman-Developers] florp (though I admit that it isn't entirely intuitive that "Barry A. Warsaw" is a link to an archived message and not a mailto: URL in this context.) -- Harald From root@theporch.com Wed Jul 21 11:40:15 1999 From: root@theporch.com (Phillip Porch) Date: Wed, 21 Jul 1999 05:40:15 -0500 (CDT) Subject: [Mailman-Developers] Re: what is being checked? In-Reply-To: Message-ID: On 21 Jul 1999, Harald Meland wrote: > Date: 21 Jul 1999 10:13:49 +0200 > From: Harald Meland > To: Phillip Porch > Cc: Stephen Modena , test-admin@theporch.com, mailman-developers@python.org > Subject: Re: [Mailman-Developers] Re: what is being checked? > > [Phillip Porch] > > > > My suggestion is: these sort of things should require the "password=<>" on > > > the same line as the request. If I am a legitimate subscriber, I can > > > punch the HTML button to get my password mailed to me...it's not like I > > > have to keep it on a post and would be an inconvenient imposition to > > > require that parameter as part of the request. > > > > I think it is the way it is to accomidate the different privacy > > settings. > > I'm not sure of the exact context here, but yes, different > private_roster settings will give different results for the "who" mail > command. > > * If "private_roster" is set to "List admin only", the "who" mail > command will tell you "Private list: No one may see subscription > list." > > * If set to "List members", it wil tell you "Private list: only > members may see list of subscribers." unless the request sender > address is a list member. This is the same algorithm that is used > for deciding whether or not the "password" command with no > arguments should mail back the member password or not -- so > requiring a password to the "who" command in this case would just > mean extra hassle, and not extra security. > > * If set to "Anyone", the roster will be mailed back without forther > checking. > > In all cases only non-hidden member addresses are included in the > roster. > > This all mimics the information available via the web interface > closely. > > Does that answer the questions you have? > It does for me. How about you Steve? -- Phillip P. Porch NIC:PP1573 finger for http://www.theporch.com UTM - 16 514548E 3994397N PGP key From gorgo@caesar.elte.hu Wed Jul 21 11:54:38 1999 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Wed, 21 Jul 1999 12:54:38 +0200 (METDST) Subject: [Mailman-Developers] cookie problem ? In-Reply-To: Message-ID: On 21 Jul 1999, Harald Meland wrote: > [Gergely Madarasz] > > > Hello, > > > > If I want to access the mailman pages thru a different url (like > > http://somehost/cgi-bin/mailman/, the cgi-bin directory has a > > symlink to mailman/cgi-bin) the cookie authentication is > > problematic. > > Yup -- we wouldn't want browsers to send out Mailman cookies unless > they actually are getting a Mailman page. Thus, the "path" setting of > the Mailman-issued cookies are set to whatever the path part of > mm_cfg.DEFAULT_URL is (i.e. normally "/mailman"). Ah, thanks, it actually works. Btw I thought it should be enough to set the base url in the general options section. -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From Harald.Meland@usit.uio.no Thu Jul 22 08:33:35 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 22 Jul 1999 09:33:35 +0200 Subject: [Mailman-Developers] cookie problem ? In-Reply-To: Gergely Madarasz's message of "Wed, 21 Jul 1999 12:54:38 +0200 (METDST)" References: Message-ID: [Gergely Madarasz] > Btw I thought it should be enough to set the base url in the general > options section. Oops... you're right, the cookie's path should be based on the URL path[1] of self.web_page_url instead of the global default mm_cfg.DEFAULT_URL. Here's a quick patch to do this: Index: SecurityManager.py =================================================================== RCS file: /export/public/cvsroot/mailman/Mailman/SecurityManager.py,v retrieving revision 1.21 diff -u -r1.21 SecurityManager.py --- SecurityManager.py 1999/07/16 22:40:28 1.21 +++ SecurityManager.py 1999/07/22 07:27:15 @@ -95,7 +95,7 @@ c = Cookie.Cookie() c[key] = [client_ip, issued, expires, mac] # place in oven, - path = urlparse(mm_cfg.DEFAULT_URL)[2] # '/mailman' + path = urlparse(self.web_page_url)[2] # '/mailman' c[key]['path'] = path # and bake until golden brown c[key]['expires'] = mm_cfg.ADMIN_COOKIE_LIFE [1] I don't know what else to call the part of an URL with proto://hostname stripped off the front, and anything from "?" and to the end of the string removed as well. -- Harald From johnr@eecs.berkeley.edu Fri Jul 23 01:49:42 1999 From: johnr@eecs.berkeley.edu (John Reekie) Date: Thu, 22 Jul 1999 17:49:42 -0700 Subject: [Mailman-Developers] Creating lists through cgi? In-Reply-To: <3793C6EC.9B581BBB@unternehmen.com> Message-ID: <001301bed4a5$446eb170$683e2080@bean.eecs.berkeley.edu> I was wondering... are there any plans to make it possible to create mail lists through the Web/CGI interface? (Needed for a "community" site.) JohnR From m.d.t.evans@qmw.ac.uk Fri Jul 23 16:22:31 1999 From: m.d.t.evans@qmw.ac.uk (Martin Evans) Date: Fri, 23 Jul 1999 16:22:31 +0100 Subject: [Mailman-Developers] subscribe problem. and search timescale. Message-ID: <379888B7.6E250A9B@qmw.ac.uk> Hello all, I may be wrong but I think I've managed st subscribe someone with an invalid email address to my test list. I subscribed 'asd@asd.qw.sd.' as a digest member. Mailman claims to send off a confirm message but then subscribes him to the list anyway. Im using version 1.00rc1. Is this a known bug, or has it been fixed in a later release? which brings me on to my second question... I see in the TODO list that an archive search engine is planned... is there any timescale for a release even a simple grep string type interface would be extremely useful? Cheers, martin. -- --- M.D.T.Evans - Computing Services - Queen Mary & Westfield College --- From brown9@niehs.nih.gov Fri Jul 23 19:34:21 1999 From: brown9@niehs.nih.gov (Lance A. Brown) Date: Fri, 23 Jul 1999 14:34:21 -0400 Subject: [Mailman-Developers] Missing vnsprintf on Compaq Tru64 Unix Message-ID: <10110.932754861@niehs.nih.gov> Greetings, I'm trying to install mailman 1.0rc3 on a Compaq Alpha 2100 running Tru64 V4.0D but am missing the vnsprintf call when linking the cgi-wrapper. I'm using gcc 2.8.1 to compile it. Is the code for this function available someplace? --[Lance] From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Jul 23 21:03:55 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 23 Jul 1999 16:03:55 -0400 (EDT) Subject: [Mailman-Developers] Missing vnsprintf on Compaq Tru64 Unix References: <10110.932754861@niehs.nih.gov> Message-ID: <14232.51883.510919.167758@anthem.cnri.reston.va.us> >>>>> "LAB" == Lance A Brown writes: LAB> Greetings, LAB> I'm trying to install mailman 1.0rc3 on a Compaq Alpha 2100 LAB> running Tru64 V4.0D but am missing the vnsprintf call when LAB> linking the cgi-wrapper. I'm using gcc 2.8.1 to compile it. LAB> Is the code for this function available someplace? Yes. You can grab it from the CVS repository: http://www.python.org/mailman/listinfo/mailman-checkins Please let me know how it goes. I haven't gotten much feedback on our workaround. -Barry From John@list.org Sun Jul 25 19:40:58 1999 From: John@list.org (John Viega) Date: Sun, 25 Jul 1999 11:40:58 -0700 Subject: [Mailman-Developers] Creating lists through cgi? In-Reply-To: <001301bed4a5$446eb170$683e2080@bean.eecs.berkeley.edu>; from John Reekie on Thu, Jul 22, 1999 at 05:49:42PM -0700 References: <3793C6EC.9B581BBB@unternehmen.com> <001301bed4a5$446eb170$683e2080@bean.eecs.berkeley.edu> Message-ID: <19990725114058.H2366@viega.org> Well, it's always been on the radar screen, but no one has gotten around to it yet. That part wouldn't be such a big deal, but the whole site admin UI we'd like to see would take quite a bit of work. If you have the time and inclination to hack something together to make this possible, please post a patch here. John On Thu, Jul 22, 1999 at 05:49:42PM -0700, John Reekie wrote: > I was wondering... are there any plans to make it possible > to create mail lists through the Web/CGI interface? (Needed > for a "community" site.) > > JohnR > > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From widmaster@yahoo.com Mon Jul 26 17:21:17 1999 From: widmaster@yahoo.com (Romain GRIFFITHS) Date: Mon, 26 Jul 1999 12:21:17 -0400 (EDT) Subject: [Mailman-Developers] internationalization of Mailman Message-ID: <19990726162117.22806.rocketmail@web601.yahoomail.com> I am french and i need to translate -at least- all the member and user part in French. I noticed that all of the message that are not in the templates are hard-coded into mailman. I am ready to translate the member and user message to french but i need to know how i can do that. We'd like the translation to be easily adapted to next versions of mailman. In the archive someone seem to have started i8n with GNU gettext to spanish, i'd like to do same for french if no one has done it yet. But i need to be sure that french translation will be compatible with next versions of mailman. Currently i don't see any .mo ou .mo file in mailman rc3 dist. Where can i find the framework to implement i8n ? PS: I need to have a quick answer because i have a deadline of 4 days to finish the mailing-list in my society (ZDNet France). _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From dan@feld.cvut.cz Mon Jul 26 20:52:30 1999 From: dan@feld.cvut.cz (Dan Ohnesorg) Date: Mon, 26 Jul 1999 21:52:30 +0200 (CEST) Subject: [Mailman-Developers] internationalization of Mailman In-Reply-To: <19990726162117.22806.rocketmail@web601.yahoomail.com> Message-ID: On Mon, 26 Jul 1999, Romain GRIFFITHS wrote: > PS: I need to have a quick answer because i have a deadline of 4 days > to finish the mailing-list in my society (ZDNet France). You can translate html templates. Nothing more is done. The project is in early stage and the result is not usable for any public accesible listserver. I see no posibility to make all right in 4 days. But there is probably no one listserv software, which is translated in French, so You can still use mailman and wait for usable internazionalized version. We can send You the .po catalog for future translation. cheers dan -- ________________________________________ DDDDDD DD DD Dan Ohnesorg, supervisor on POWER DD OOOO Dan@feld.cvut.cz DD OODDOO Dep. of Power Engineering DDDDDD OO CTU FEL Prague, Bohemia OO OO work: +420 2 24352785;+420 2 24972109 OOOO home: +420 311 679679;+420 311 679311 ________________________________________ Na svete jsou dva prostredky, Jak se povznest: bud vlastnimi schopnostmi, anebo hlouposti jinych. From Dionysos@Dionysia.org Tue Jul 27 21:59:33 1999 From: Dionysos@Dionysia.org (Dan Delaney) Date: Tue, 27 Jul 1999 16:59:33 -0400 Subject: [Mailman-Developers] Face lift for User Interface Message-ID: Hi all. Being a graphic designer I'm particularly interested in the "look and feel" of the interface for Mailman. The current interface is pretty good, certainly better than most I've used. But it could use some improvement. With that in mind, I've made a mockup page for the General Options page. For those who are interested, and especially those who actually work on the HTML for the interface, please take a look at www.Dionysia.org/temp/mailman/ and see what you think. Thanks. --Dan ________________________________________________________________________ Dionysos@Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html From aahz@searchbutton.com Tue Jul 27 22:05:09 1999 From: aahz@searchbutton.com (Aahz) Date: Tue, 27 Jul 1999 14:05:09 -0700 Subject: [Mailman-Developers] Viewing anyone's options w/o a password Message-ID: <219B76713101D31183B000902762824E0442AF@draco.searchbutton.com> This is late, but I'd suggest something like this: Require both e-mail address and password on sign-in. If no match is made, the error page contains a link to the form for "mail me password". I could go either way on the error page stating that the e-mail address is valid. -----Original Message----- From: Harald Meland [mailto:Harald.Meland@usit.uio.no] Sent: Thursday, July 01, 1999 2:34 PM To: Rob Francis Cc: mailman-developers@python.org Subject: Re: [Mailman-Developers] Viewing anyone's options w/o a password [Rob Francis] > It seems kind of odd to me that if I know someone's email address on > a list that I can go to the Info page and enter their email address, > and then w/o a password see what options they have set. I agree -- in principle this really is giving away more info than it should, e.g. if I suspect that someone is subscribed to a list, I can use this "feature" to verify my suspicion. However, if we make access to the user options page password restricted, we'd (obviously) have to put the "Email my password to me" button on some other page -- and I sort of think the listinfo page is crowded enough as it is. > Just wondering if this was a decision made on purpose, or perhaps an > oversight. I don't know for sure, but I suspect it was done like this because of the "Email my password to me" issue. Good suggestions on how this should best be solved are welcome. -- Harald _______________________________________________ Mailman-Developers maillist - Mailman-Developers@python.org http://www.python.org/mailman/listinfo/mailman-developers From corbett.klempay@trilogy.com Tue Jul 27 10:17:44 1999 From: corbett.klempay@trilogy.com (Corbett J. Klempay) Date: Tue, 27 Jul 1999 04:17:44 -0500 Subject: [Mailman-Developers] Face lift for User Interface In-Reply-To: Message-ID: I just took a look at the mock-up...I agree. The mockup has a more refined, 'clean' look...thumbs up! (but as Dan said, the existing interface puts most competitors to shame) --- Corbett J. Klempay Trilogy Software, Inc. 512.685.4193 (W) | 512.750.1372 (C) corbett.klempay@trilogy.com > -----Original Message----- > From: mailman-developers-admin@python.org > [mailto:mailman-developers-admin@python.org]On Behalf Of Dan Delaney > Sent: Tuesday, July 27, 1999 4:00 PM > To: mailman-developers@python.org > Subject: [Mailman-Developers] Face lift for User Interface > > > Hi all. > Being a graphic designer I'm particularly interested in the "look and > feel" of the interface for Mailman. The current interface is pretty good, > certainly better than most I've used. But it could use some improvement. > With that in mind, I've made a mockup page for the General Options page. > For those who are interested, and especially those who actually work on > the HTML for the interface, please take a look at > www.Dionysia.org/temp/mailman/ and see what you think. > Thanks. > --Dan > ________________________________________________________________________ > Dionysos@Dionysia.org Daniel G. Delaney > www.Dionysia.org/~dionysos/ > PGP Public Key: /~dionysos/pgp.html > > > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers > From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Jul 27 22:28:32 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 27 Jul 1999 17:28:32 -0400 (EDT) Subject: [Mailman-Developers] Face lift for User Interface References: Message-ID: <14238.9344.118190.260231@anthem.cnri.reston.va.us> >>>>> "CJK" == Corbett J Klempay writes: CJK> I just took a look at the mock-up...I agree. The mockup has CJK> a more refined, 'clean' look...thumbs up! (but as Dan said, CJK> the existing interface puts most competitors to shame) I saw a few of Dan's early attempts at the redesign, and this one (mockup3) is by far the best. Dan, I really like what you've done! If other people agree, let's look at getting these changes into Mailman post 1.0. -Barry From claw@varesearch.com Wed Jul 28 03:56:50 1999 From: claw@varesearch.com (J C Lawrence) Date: Tue, 27 Jul 1999 19:56:50 -0700 Subject: [Mailman-Developers] Face lift for User Interface In-Reply-To: Message from "Dan Delaney" of "Tue, 27 Jul 1999 16:59:33 EDT." Message-ID: On Tue, 27 Jul 1999 16:59:33 -0400 Dan Delaney wrote: > www.Dionysia.org/temp/mailman/ I like. -- J C Lawrence Home: claw@kanga.nu ---------(*) Linux/IA64 - Work: claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ... From petrilli@amber.org Wed Jul 28 04:29:00 1999 From: petrilli@amber.org (Christopher Petrilli) Date: Tue, 27 Jul 1999 23:29:00 -0400 Subject: [Mailman-Developers] Face lift for User Interface In-Reply-To: ; from Dan Delaney on Tue, Jul 27, 1999 at 04:59:33PM -0400 References: Message-ID: <19990727232900.A18815@amber.org> On Tue, Jul 27, 1999 at 04:59:33PM -0400, Dan Delaney wrote: > Hi all. > Being a graphic designer I'm particularly interested in the "look and > feel" of the interface for Mailman. The current interface is pretty good, > certainly better than most I've used. But it could use some improvement. > With that in mind, I've made a mockup page for the General Options page. > For those who are interested, and especially those who actually work on > the HTML for the interface, please take a look at > www.Dionysia.org/temp/mailman/ and see what you think. I would make only one major recommendations... drop all the style information out of the tags, and put it in a style sheet. Most of the stuff you're doing, especially colors would be better that way. Then you could actually ship 3-4 style sheets with different colors on them to people :-) Also, it reduces the amount of code in the page A LOT. Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright From cherub@azrael.dyn.cheapnet.net Wed Jul 28 07:18:04 1999 From: cherub@azrael.dyn.cheapnet.net (Steven Hazel) Date: Wed, 28 Jul 1999 01:18:04 -0500 (CDT) Subject: [Mailman-Developers] message board functionality? Message-ID: wwwthreads, a web-based threaded message board software, formerly released under the GPL, is now being released under a non-free license by the original author. I'm the administrator of wwwthreads for a user community, and we've decided to stick with free software. I suggested to the GNU project that I fork the code and work on extending and improving the capabilies of wwwthreads with the aim of inclusion in GNU. After a bit of discussion with RMS, I'm thinking that perhaps the best thing to do is to work on GNU Mailman to make it capable of doing what wwwthreads does. Many of the extensions I was planning for wwwthreads (for example, integration with email and optionalization of the web interface) are already done in Mailman, and I think that maybe Mailman could benefit from some of the additional functionality I am proposing. Besides which, I'd really like to be able to deal with all of my email in one place, rather than having to zoom off to some web site for a portion of it. I think a lot of web-based-forum users feel the same way. So I'm writing this email to find out what you think -- is this possible? Is it a good idea? My current minimum list of features needed to make GNU Mailman useable as a replacement for wwwthreads (with the web-based part fully optional) is as follows: - web logins for user accounts - user option to not actually receive mail from lists (for those who want to read lists purely on the web) - web interface for posting to mailing lists - web interface for administrator and moderator functions - web appearance configurability on both an administrator and user level - program to convert wwwthreads databases to Mailman configurations Of course, further features would follow those, based on what users say when they've switched from other forum software. I expect that the web frontend would benefit greatly. Your comments are appriciated. -Steven From root@theporch.com Wed Jul 28 11:27:18 1999 From: root@theporch.com (Phillip Porch) Date: Wed, 28 Jul 1999 05:27:18 -0500 (CDT) Subject: [Mailman-Developers] Face lift for User Interface In-Reply-To: Message-ID: I like the new look also. Add my vote to the Yes side please. -- Phillip P. Porch NIC:PP1573 finger for http://www.theporch.com UTM - 16 514548E 3994397N PGP key From adamj@shadowrun.html.com Wed Jul 28 12:01:13 1999 From: adamj@shadowrun.html.com (Adam J) Date: Wed, 28 Jul 1999 05:01:13 -0600 Subject: [Mailman-Developers] Face lift for User Interface In-Reply-To: <14238.9344.118190.260231@anthem.cnri.reston.va.us> References: Message-ID: <4.2.0.58.19990728045618.00a67bd0@shadowrun.html.com> At 17:28 7/27/99 -0400, Barry A. Warsaw wrote: > CJK> I just took a look at the mock-up...I agree. The mockup has > CJK> a more refined, 'clean' look...thumbs up! (but as Dan said, > CJK> the existing interface puts most competitors to shame) > >I saw a few of Dan's early attempts at the redesign, and this one >(mockup3) is by far the best. Dan, I really like what you've done! >If other people agree, let's look at getting these changes into >Mailman post 1.0. I definitely agree. The new design is much cleaner and looks much more professional. Adam < http://shadowrun.html.com/tss / adamj@shadowrun.html.com / ICQ# 2350330 > From John@list.org Wed Jul 28 12:07:11 1999 From: John@list.org (John Viega) Date: Wed, 28 Jul 1999 04:07:11 -0700 Subject: [Mailman-Developers] message board functionality? In-Reply-To: ; from Steven Hazel on Wed, Jul 28, 1999 at 01:18:04AM -0500 References: Message-ID: <19990728040711.E25427@viega.org> Steven, Yes, I like the idea. Some comments: "user option to not actually receive mail from lists"... for lists with archiving, you can already just go and read the archive. I know a lot of people who do this on real lists. You'd just have to change the link to say, "visit the list in forum format" or something like that. It does sound like Mailman meets many of your requirements already, but not all of them. I'd love to see this stuff get included. Please do work on it. John On Wed, Jul 28, 1999 at 01:18:04AM -0500, Steven Hazel wrote: > > wwwthreads, a web-based threaded message board software, formerly released > under the GPL, is now being released under a non-free license by the original > author. I'm the administrator of wwwthreads for a user community, and we've > decided to stick with free software. I suggested to the GNU project that I > fork the code and work on extending and improving the capabilies of > wwwthreads with the aim of inclusion in GNU. After a bit of discussion with > RMS, I'm thinking that perhaps the best thing to do is to work on GNU Mailman > to make it capable of doing what wwwthreads does. Many of the extensions I > was planning for wwwthreads (for example, integration with email and > optionalization of the web interface) are already done in Mailman, and I think > that maybe Mailman could benefit from some of the additional functionality I > am proposing. Besides which, I'd really like to be able to deal with all of > my email in one place, rather than having to zoom off to some web site for > a portion of it. I think a lot of web-based-forum users feel the same way. > > So I'm writing this email to find out what you think -- is this possible? > Is it a good idea? > > My current minimum list of features needed to make GNU Mailman useable as a > replacement for wwwthreads (with the web-based part fully optional) is as > follows: > > - web logins for user accounts > - user option to not actually receive mail from lists (for those who want > to read lists purely on the web) > - web interface for posting to mailing lists > - web interface for administrator and moderator functions > - web appearance configurability on both an administrator and user level > - program to convert wwwthreads databases to Mailman configurations > > Of course, further features would follow those, based on what users say when > they've switched from other forum software. I expect that the web frontend > would benefit greatly. > > Your comments are appriciated. > > -Steven > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From Nigel.Metheringham@vdata.co.uk Wed Jul 28 12:45:30 1999 From: Nigel.Metheringham@vdata.co.uk (Nigel Metheringham) Date: Wed, 28 Jul 1999 12:45:30 +0100 Subject: [Mailman-Developers] Face lift for User Interface In-Reply-To: Message from Adam J of "Wed, 28 Jul 1999 05:01:13 MDT." <4.2.0.58.19990728045618.00a67bd0@shadowrun.html.com> Message-ID: I also like the mockup interface, and would like the idea of making large chunks of this template-able - ie colour selection etc. At the risk of this becoming a general wish-list as well, I would also like finer control of some of the current information emitted by the mailman web interface. For example I have just changed the owner information for one of my lists so that it is delivered direct to my work mail account, and also has a mailbox suffix on it to enable it to be sorted automatically. This makes the address long, ugly, and I intended it for use by the stuff forwarded by mailman. However this now appears on the bottom of all the web pages (... list run by...). I don't appear to be able to remove that without dropping the tag from the pages, which is more extensive a change than I want. So finer control of these elements would also be advantageous. Nigel. -- [ Nigel Metheringham Nigel.Metheringham@VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] From klm@digicool.com Wed Jul 28 16:06:50 1999 From: klm@digicool.com (Ken Manheimer) Date: Wed, 28 Jul 1999 11:06:50 -0400 Subject: [Mailman-Developers] RE: Mailman-Developers digest, Vol 1 #328 - 6 msgs Message-ID: <613145F79272D211914B0020AFF640191D1C3C@gandalf.digicool.com> > From: "Dan Delaney" > To: > Date: Tue, 27 Jul 1999 16:59:33 -0400 > charset="iso-8859-1" > Subject: [Mailman-Developers] Face lift for User Interface > > Hi all. > Being a graphic designer I'm particularly interested in the "look and > feel" of the interface for Mailman. The current interface is pretty good, > certainly better than most I've used. But it could use some improvement. > With that in mind, I've made a mockup page for the General Options page. > For those who are interested, and especially those who actually work on > the HTML for the interface, please take a look at > www.Dionysia.org/temp/mailman/ and see what you think. I agree with everyone's admiration for your changes. I have one reservation, however - i much prefer the existing arrangement, if not necessarily the appearance, of the activity index at the top of the page. I think the regular matrix you use is too regular - i'd prefer the links to the configuration options pages to be more clearly separate from the "other" activities. I think having them in two separate columns, as we currently do, is not a bad arrangement - though i can see how it can be incongruous with everything else being arranged in tables. I also have a logistical reservation about the 70-character-wide text entry boxes at the bottom. One thing we've been thinking about for improving navigation through mailman, in general, is use of a sidebar and a "top"bar. This would use up some of the real estate needed for hard-wrapped, full width text entry boxes. (We've also been thinking about how we would make mailman "play nicely" with the existing style of a host site, another potential real-estate loss, but this is getting pretty hypothetical.) I just mention this to enter it into the picture... (BTW, i guess i'm primarily responsible for the existing layout of many of the mailman pages - though really, i refined/reworked to greater and lesser degrees what i originally got from john viega, and based some of my changes on contributions, particularly from robin friedrich. And i have to admit to a possibly stubborn liking of the "cumbersome white lines", which nicely delineate the options, to my eye. That said, i think the only real reservation i have is the one concerning the activity index at the top, and would be happy to go with all your other changes - thanks!!) Ken Manheimer klm@digicool.com From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Jul 28 16:22:18 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 28 Jul 1999 11:22:18 -0400 (EDT) Subject: [Mailman-Developers] Face lift for User Interface References: <19990727232900.A18815@amber.org> Message-ID: <14239.8234.795188.606005@anthem.cnri.reston.va.us> >>>>> "CP" == Christopher Petrilli writes: CP> I would make only one major recommendations... drop all the CP> style information out of the tags, and put it in a style CP> sheet. Most of the stuff you're doing, especially colors CP> would be better that way. Then you could actually ship 3-4 CP> style sheets with different colors on them to people :-) Also, CP> it reduces the amount of code in the page A LOT. Don't forget though, that we have to support older browsers. I think there are list admins with users still using e.g. NS 3. This stuff must work for them too. -Barry From petrilli@amber.org Wed Jul 28 16:32:51 1999 From: petrilli@amber.org (Christopher Petrilli) Date: Wed, 28 Jul 1999 11:32:51 -0400 Subject: [Mailman-Developers] Face lift for User Interface In-Reply-To: <14239.8234.795188.606005@anthem.cnri.reston.va.us>; from Barry A. Warsaw on Wed, Jul 28, 1999 at 11:22:18AM -0400 References: <19990727232900.A18815@amber.org> <14239.8234.795188.606005@anthem.cnri.reston.va.us> Message-ID: <19990728113251.A21085@amber.org> On Wed, Jul 28, 1999 at 11:22:18AM -0400, Barry A. Warsaw wrote: > >>>>> "CP" == Christopher Petrilli writes: > > CP> I would make only one major recommendations... drop all the > CP> style information out of the tags, and put it in a style > CP> sheet. Most of the stuff you're doing, especially colors > CP> would be better that way. Then you could actually ship 3-4 > CP> style sheets with different colors on them to people :-) Also, > CP> it reduces the amount of code in the page A LOT. > > Don't forget though, that we have to support older browsers. I think > there are list admins with users still using e.g. NS 3. This stuff > must work for them too. If you know how to use style-sheets, it's not a problem. You would get a gradual degredation, where colors would disappear, and maybe somesmall formatting details, but it gains you a lot of flexibility in formatting, and makes it easier for people to change how things look to suit their own site. Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright From Dionysos@Dionysia.org Wed Jul 28 17:18:57 1999 From: Dionysos@Dionysia.org (Dan Delaney) Date: Wed, 28 Jul 1999 12:18:57 -0400 Subject: [Mailman-Developers] Face lift for User Interface In-Reply-To: <14239.8234.795188.606005@anthem.cnri.reston.va.us> Message-ID: > -----Original Message----- > From: Barry A. Warsaw > >>>>> "CP" == Christopher Petrilli writes: > CP> I would make only one major recommendations... drop all the > CP> style information out of the tags, and put it in a style > CP> sheet. Most of the stuff you're doing, especially colors > CP> would be better that way. Then you could actually ship 3-4 > CP> style sheets with different colors on them to people :-) Also, > CP> it reduces the amount of code in the page A LOT. > > Don't forget though, that we have to support older browsers. I think > there are list admins with users still using e.g. NS 3. This stuff > must work for them too. That's correct. And even though (as someone else said) the pages would still work on older browsers if the style sheets are done correctly, there is still one major stumbling block to style sheets: the fact that they are not implimented completely correctly in ANY browser. I've found several problems with the way IE5 implements style sheets, and Netscrape's style sheet support is worthless. Nonetheless, I'll set up a second mockup using style sheets and see how it works out. I'll let you all know when it's ready. As far as making it so that it is easy to change the colors to match your site, there are two options. Style sheets is certainly a good way to do that. But the other option is to have option variables set for the colors and have the "COLOR=" parts of the HTMl file generated by the Python code which can insert the contents of the color preferences variables. --Dan ________________________________________________________________________ Dionysos@Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html From petrilli@amber.org Wed Jul 28 17:39:47 1999 From: petrilli@amber.org (Christopher Petrilli) Date: Wed, 28 Jul 1999 12:39:47 -0400 Subject: [Mailman-Developers] Face lift for User Interface In-Reply-To: ; from Dan Delaney on Wed, Jul 28, 1999 at 12:18:57PM -0400 References: <14239.8234.795188.606005@anthem.cnri.reston.va.us> Message-ID: <19990728123947.B21085@amber.org> On Wed, Jul 28, 1999 at 12:18:57PM -0400, Dan Delaney wrote: > That's correct. And even though (as someone else said) the pages would still > work on older browsers if the style sheets are done correctly, there is > still one major stumbling block to style sheets: the fact that they are not > implimented completely correctly in ANY browser. I've found several problems > with the way IE5 implements style sheets, and Netscrape's style sheet > support is worthless. Nonetheless, I'll set up a second mockup using style > sheets and see how it works out. I'll let you all know when it's ready. Well, colors work fine across all browsers that I've been able to test with. More advanced features aren't consistent, but some things that I've not had any real problems with: * Colors * Font size, especially relative (never use absolute) * Faces * Alignment (generally, except when nested) Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright From Harald.Meland@usit.uio.no Wed Jul 28 18:51:42 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 28 Jul 1999 19:51:42 +0200 Subject: [Mailman-Developers] RE: Mailman-Developers digest, Vol 1 #328 - 6 msgs In-Reply-To: Ken Manheimer's message of "Wed, 28 Jul 1999 11:06:50 -0400" References: <613145F79272D211914B0020AFF640191D1C3C@gandalf.digicool.com> Message-ID: [Ken Manheimer] > I agree with everyone's admiration for your changes. Yeah, even _I_ like'em :) > I have one reservation, however - i much prefer the existing > arrangement, if not necessarily the appearance, of the activity > index at the top of the page. I think the regular matrix you use is > too regular - i'd prefer the links to the configuration options > pages to be more clearly separate from the "other" activities. Like, in a separate frame, maybe? That's what I've been thinking, anyway... However, the frame-full UI should be optional. For a frame-less UI, I agree with Ken. > I think having them in two separate columns, as we currently do, is > not a bad arrangement - though i can see how it can be incongruous > with everything else being arranged in tables. Umm, I'm definitely _not_ a graphic designer (by far), but wouldn't a borderless table with one row of two columns, where each column contains a bordered/coloured table corresponding to the "columns" we have now, work nicely? -- Harald From cherub@azrael.dyn.cheapnet.net Thu Jul 29 01:35:14 1999 From: cherub@azrael.dyn.cheapnet.net (Steven Hazel) Date: Wed, 28 Jul 1999 19:35:14 -0500 (CDT) Subject: [Mailman-Developers] message board functionality? In-Reply-To: <19990728040711.E25427@viega.org> (message from John Viega on Wed, 28 Jul 1999 04:07:11 -0700) References: <19990728040711.E25427@viega.org> Message-ID: "user option to not actually receive mail from lists"... for lists with archiving, you can already just go and read the archive. I know a lot of people who do this on real lists. You'd just have to change the link to say, "visit the list in forum format" or something like that. Well, I was thinking that it might be a good idea to have some sort of user account system. This is a functionality which might be objectionable in a mailing list manager, but I'm not sure, since it would have some benefits as well. The idea is that rather than simply subscribing to a mailing list, users would create an account -- complete with username and password -- with Mailman. Perhaps the accounts should be per-list or perhaps a single account could subscribe to a set of lists. The account would include information about one or more addresses to which mail should be sent. At that point, for the ordinary mailing list user, everything is the same. For users who want to make exclusive use of the web interface, though, their username and password would be required at least to post under their username and maybe sometimes for read access (for private lists). One possibility this opens up is that posts could (optionally, of course) be listed under usernames for those who want anonymity, or with usernames as well as email addresses. One nice thing about that is that if someone has a subscription to a mailing list and switches email addresses, they can just tell Mailman that the new address belongs to them, and posts from that address could be recognized and given their username. From there, things like prefered email addresses for replies to posts regardless of the origin of the post are possible, which would sometimes be nice. I know I'd like to be able to post to certain mailing lists from my work email account and have replies uniformly show up at my regular email address. I'm wondering what your take on user accounts will be. It's important functionality for a web-based forum, but seems sort of tangental to mailing list management, though it does have some advantages. Perhaps they should be optional, or perhaps they don't belong in a mailing list manager at all and should be handled in a wrapper of some sort. My thought is that they should be optional, and turning them on could also turn on a great deal of web-based funtionality. -Steven From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Jul 29 15:55:48 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 29 Jul 1999 10:55:48 -0400 (EDT) Subject: [Mailman-Developers] message board functionality? References: <19990728040711.E25427@viega.org> Message-ID: <14240.27508.634165.859250@anthem.cnri.reston.va.us> >>>>> "SH" == Steven Hazel writes: SH> I'm wondering what your take on user accounts will be. It's SH> important functionality for a web-based forum, but seems sort SH> of tangental to mailing list management, though it does have SH> some advantages. Perhaps they should be optional, or perhaps SH> they don't belong in a mailing list manager at all and should SH> be handled in a wrapper of some sort. My thought is that they SH> should be optional, and turning them on could also turn on a SH> great deal of web-based funtionality. I actually believe user accounts are essential, but perhaps that's because of my unique relationship with the python.org lists. I agree with everything you've said. The biggest problem that I have is remembering all the dang passwords, both user and admin passwords, that I have to use every day. So I would go one step further; I would let the site administrator designate which user accounts can have admin privileges for which lists, so they'd only have to remember one password to administer any list of theirs. Users should also be able to manage all their lists on one screen. Say they're going on vacation. One button could allow them to disable all their accounts on the site, and another would enable them upon their return. It's interesting that user accounts are so important for message boarding (a feature that I think would be cool to add to Mailman), because I've been seriously considering this to better support existing functionality. The question in my mind is whether to homebrew all this support, or to leverage off of Zope, which I think already has much of this functionality. -Barry From widmaster@yahoo.com Thu Jul 29 16:16:45 1999 From: widmaster@yahoo.com (Romain GRIFFITHS) Date: Thu, 29 Jul 1999 08:16:45 -0700 (PDT) Subject: [Mailman-Developers] French Templates Message-ID: <19990729151645.15396.rocketmail@web601.yahoomail.com> We did the translation of the templates to french. We need to correct them a bit but it is ok _____________________________________________________________ Do You Yahoo!? Free instant messaging and more at http://messenger.yahoo.com From Dionysos@Dionysia.org Thu Jul 29 16:49:09 1999 From: Dionysos@Dionysia.org (Dan Delaney) Date: Thu, 29 Jul 1999 11:49:09 -0400 Subject: [Mailman-Developers] message board functionality? In-Reply-To: <14240.27508.634165.859250@anthem.cnri.reston.va.us> Message-ID: From: Barry A. Warsaw > they'd only have to remember one password to administer any > list of theirs. > Users should also be able to manage all their lists on one screen. > Say they're going on vacation. One button could allow them to disable > all their accounts on the site, and another would enable them upon > their return. That would be FANTASTIC! I run a bunch of email lists for members of an organization. Each person is on several lists. It would be great if they could just have one screen which could change their preferences for all of the lists they are on. Even to change the email address that the lists send to, and to specify alternate email addresses that they might be sending from (home and work, for instance). They should also, however, still be able to set separate preferences for each list. What would be great also, if it is set up this way, is to have a SITE ADMIN account, so that the person who runs mailman can have one password to be able to get into anything. On my sight, for instance, I have a lot of mailing lists for which other people are disignated as the administrators. Well, what happens when one of the admins forgets his password to one of the lists? It would be great if I, as the SITE admin, had an overall password which would allow me to go into any of the lists to fix them if the admins don't know how. --Dan ________________________________________________________________________ Dionysos@Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html From Dionysos@Dionysia.org Thu Jul 29 16:58:05 1999 From: Dionysos@Dionysia.org (Dan Delaney) Date: Thu, 29 Jul 1999 11:58:05 -0400 Subject: [Mailman-Developers] Face lift for User Interface In-Reply-To: <19990728123947.B21085@amber.org> Message-ID: From: Christopher Petrilli > Well, colors work fine across all browsers that I've been able to test > with. More advanced features aren't consistent, but some things that > I've not had any real problems with: > * Colors Well, everything works great in these new CSS mockups except for one thing. NETSCRAPE DOESN'T SET THE COLORS FOR THE BODY TAG! Yes. I'm using Netscrape 4.5 and when I specify a style sheet like "BODY { background-color: #000000; color: #FFFFFF }", Netscrape doesn't set the page background to black and text to white. I don't know whether or not MSIE does because my copy of MSIE5 bombs as soon as it is launched (it's running on WinNT, what do you expect! :-), so could someone please check it out (CSS mockup 3 is the one that should have a black background for the page) with MSIE (versions 3, 4, and 5) and let me know what it does? Anyway, go check out the new CSS mockups at www.Dionysia.org/temp/mailman/ and let me know what you think. > * Font size, especially relative (never use absolute) I always specify type size in ems, which is the ideal relative type size measurment unit. --Dan ________________________________________________________________________ Dionysos@Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html From Dionysos@Dionysia.org Thu Jul 29 18:27:33 1999 From: Dionysos@Dionysia.org (Dan Delaney) Date: Thu, 29 Jul 1999 13:27:33 -0400 (EDT) Subject: [Mailman-Developers] Re: Subject Cleanup Routine Message-ID: From: Harald Meland > So, if I send a mail with subject > Subject: Administrivia: [foo] will be changed to [bar] > Mailman should change it to > Subject: [foo] Administrivia: will be changed to [bar] > > ? I don't think messing with the subject prefix to that extent is a > good idea. First, how often are you really gonna put the list's prefix in the subject of a message to the list? Not very often. Maybe once in the lifetime of the list, if that often? Second, even if you do need to refer to the list name in the subject, you could just use quotes instead of brackets, as in: Subject: [foo] Administrivia: "foo" will be changing to "bar" I don't think that's really that big a deal. > Regarding stripping of consecutive "Re:" and "Fwd:" > strings -- you'd still have problems with the nationalized versions of > these ("SV:", "AD:", etc.) that some MUA vendors in their infinite > wisdom have implemented That's a good point. Maybe on the options page there could be a list of "subject tags" to strip from the subjects, instead of having them hard coded in the program. > I think this "problem" should be solved in the user's MUA > configuration (if the user wants the subjects mangled) and/or in the > archiver thread generator. Unfortunately the MUAs out there do a crappy job of this. Look at how many messages you get with things like "Re: Fwd: RE:" in the subject. I get a lot, and it's awefully annoying. Anyway. What would be nice would be a radio button option in the General Options to choose between the existing routine, which simply checks to see if the Prefix is already present in the subject, and a the more aggressive subject cleanup routine. Here, by the way, is a new copy of the routine which takes into account those aweful NUMBERED reply tags (as in "Re[2]:"): --------------------------------------------------------------------------- # Prepend the subject_prefix to the subject line. subj = msg.getheader('subject') prefix = self.subject_prefix # If there's no subject, give it one if not subj: msg.SetHeader('Subject', '%s(no subject)' % prefix) else: # Delete all occurances of the prefix from the subject if prefix: subj = re.sub(re.escape(self.subject_prefix), '', subj) # Check to see if the message is a reply or forward prefix2 = '' if re.search('^fwd*[0-9\[\]]*: |\(fwd\)', subj, re.I): prefix2 = 'Fwd: ' if re.match('re[0-9\[\]]*: ', subj, re.I): prefix2 = 'Re: ' # Clean up all that 're:' and 'fwd: ' garbage subj = re.sub('[rR][eE][0-9\[\]]*: | *\(*[fF][wW][dD]*[0-9\[\]\)]*:* *', '', subj) # Set the new subject line in place msg.SetHeader('Subject', '%s%s%s' % (prefix, prefix2, subj)) --------------------------------------------------------------------------- -- Dan ________________________________________________________________________ Dionysos@Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html From hebble@ncsa.uiuc.edu Thu Jul 29 18:27:29 1999 From: hebble@ncsa.uiuc.edu (Paul Hebble) Date: Thu, 29 Jul 1999 12:27:29 -0500 (CDT) Subject: [Mailman-Developers] message board functionality? In-Reply-To: Message-ID: On Thu, 29 Jul 1999, Dan Delaney wrote: > What would be great also, if it is set up this way, is to have a SITE ADMIN > account, so that the person who runs mailman can have one password to be > able to get into anything. On my sight, for instance, I have a lot of > mailing lists for which other people are disignated as the administrators. > Well, what happens when one of the admins forgets his password to one of the > lists? It would be great if I, as the SITE admin, had an overall password > which would allow me to go into any of the lists to fix them if the admins > don't know how. Err, isn't this already implimented? Try using your site admin passwd to get into list admin pages. -- Paul Hebble From Dionysos@Dionysia.org Thu Jul 29 18:30:49 1999 From: Dionysos@Dionysia.org (Dan Delaney) Date: Thu, 29 Jul 1999 13:30:49 -0400 Subject: [Mailman-Developers] message board functionality? In-Reply-To: Message-ID: > -----Original Message----- > From: Paul Hebble [mailto:hebble@ncsa.uiuc.edu] > Err, isn't this already implimented? Try using your site admin passwd to > get into list admin pages. Hmmm. Maybe so. I don't remember there being an overall site admin password. If so, kindly disregard that last paragraph ;=) --Dan ________________________________________________________________________ Dionysos@Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html From hebble@ncsa.uiuc.edu Thu Jul 29 18:36:32 1999 From: hebble@ncsa.uiuc.edu (Paul Hebble) Date: Thu, 29 Jul 1999 12:36:32 -0500 (CDT) Subject: [Mailman-Developers] message board functionality? In-Reply-To: Message-ID: On Thu, 29 Jul 1999, Dan Delaney wrote: > Hmmm. Maybe so. I don't remember there being an overall site admin password. > If so, kindly disregard that last paragraph ;=) Yeah, that's what $prefix/bin/mmsitepass does. -- Paul From johnr@eecs.berkeley.edu Thu Jul 29 20:02:30 1999 From: johnr@eecs.berkeley.edu (John Reekie) Date: Thu, 29 Jul 1999 12:02:30 -0700 Subject: [Mailman-Developers] message board functionality? In-Reply-To: <14240.27508.634165.859250@anthem.cnri.reston.va.us> Message-ID: <000201bed9f4$e9043fd0$723e2080@bean.eecs.berkeley.edu> > The biggest problem that I have is remembering all the dang passwords, > both user and admin passwords, that I have to use every day. So I > would go one step further; I would let the site administrator > designate which user accounts can have admin privileges for which > lists, so they'd only have to remember one password to administer any > list of theirs. User accounts are a great idea, but I would like to suggest that it be done so that websites that _already have_ user accounts can integrate mailman easily. Sites with accounts are popping up like mushrooms after the rain :) and it would be awesome if mailman had an interface that allowed them to "wrap" mailman in their existing setup. Of course, my motivation for this request is entirely selfish :-) To make this more concrete, this is the kind of stuff I do now to make mailman appear to be an integrated part of an existing site with user accounts: * Manufacture a password * Generate a query string with the password * Call apache via http and get the headers * Extract the cookie * Generate another query string with the user data * Call apache back with the cookie and the query string * Get the HTML back and strip out everything but the body * Munge the body to change URLs. * Plonk what's left into my own auto-generated HTML and send it back to the browser. Amazingly enough, this actually works. The reason for doing it this way was so I didn't have to modify MailMan (apart from about ten lines commented out). And of course I don't want users who are already logged in to enter any passwords or accept any more cookies. Anyway, if this sounds like it's worth at least discussing I am more than happy to help figure out how to go about it and volunteer to contribute a PHP script as an example of MailMan integration (the rest of my site is written in PHP). Thanks! JohnR From Paul Hebble Thu Jul 29 20:13:14 1999 From: Paul Hebble (Paul Hebble) Date: Thu, 29 Jul 1999 14:13:14 -0500 (CDT) Subject: [Mailman-Developers] Configurable Archiving Proposal Message-ID: Hi all, I want to set up Mailman to support other archiving methods, more cleanly than subscribing a procmailrc to a list. I know a few other people are interested in this as well. I would like to add a per-list configuration option to each list's config.db which tells Mailman a command line to run to archive a message. Is this any more complicated than adding a variable to the MailList class and adding a few lines to Archiver/Archiver.py? What do other users and developers think of this idea? Is it dangerous to allow a list adminstrator to execute arbitrary commands? If so, how else could this be done? -- Paul From Dionysos@Dionysia.org Thu Jul 29 20:27:29 1999 From: Dionysos@Dionysia.org (Dan Delaney) Date: Thu, 29 Jul 1999 15:27:29 -0400 Subject: [Mailman-Developers] message board functionality? In-Reply-To: <000201bed9f4$e9043fd0$723e2080@bean.eecs.berkeley.edu> Message-ID: From: John Reekie > I would like to suggest > that it be done so that websites that _already have_ user accounts > can integrate mailman easily. > I don't want users who are > already logged in to enter any passwords or accept any more > cookies. I'm in the same boat as John on this one. Consider an Intranet situation. The user has already logged into an Intranet on which he is subscribed to several mailing lists. He should not have to enter another password to configure his lists, he should just be able to click on a link and do it. Purhaps a good way to facilitate this would be to publish a clear specification for how all of the data is stored in the config.db files for lists so that if you already have an Intranet application set up you can just add in a little code to change the Mailman list data yourself. For instance, I already have a screen which allows the Intranet users to changes their password and personal information, including their email address. It'd be great if, when they change their email address, I could just add code into my PHP program which would automatically change their email address on all of the lists to which they are subscribed. --Dan ________________________________________________________________________ Dionysos@Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Jul 29 22:58:39 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 29 Jul 1999 17:58:39 -0400 (EDT) Subject: [Mailman-Developers] internationalization of Mailman References: <19990726162117.22806.rocketmail@web601.yahoomail.com> Message-ID: <14240.52879.986015.20651@anthem.cnri.reston.va.us> >>>>> "RG" == Romain GRIFFITHS writes: RG> Where can i find the framework to implement i8n ? There really is no comprehensive framework for supporting I18N in Mailman 1.0, but I would really like to put together a task force for supporting this in the next release. -Barry From bwarsaw@python.org Thu Jul 29 23:23:22 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Thu, 29 Jul 1999 18:23:22 -0400 (EDT) Subject: [Mailman-Developers] message board functionality? References: <14240.27508.634165.859250@anthem.cnri.reston.va.us> <000201bed9f4$e9043fd0$723e2080@bean.eecs.berkeley.edu> Message-ID: <14240.54362.921170.841818@anthem.cnri.reston.va.us> >>>>> "JR" == John Reekie writes: JR> User accounts are a great idea, but I would like to suggest JR> that it be done so that websites that _already have_ user JR> accounts can integrate mailman easily. Sites with accounts are JR> popping up like mushrooms after the rain :) and it would be JR> awesome if mailman had an interface that allowed them to JR> "wrap" mailman in their existing setup. So it sounds like there are a couple of issues here. One is making Mailman's web interface customizable so that you can make it look like it's an integrated part of the site. It sounds like you go to a lot of work to make this happen. I have some thoughts on this based on the ht2html scripts[1] I wrote, but I'm not sure if they're general or flexible enough. Then again, maybe using style sheets would get us close enough. Second, it sounds like you want to perhaps have a Mailman hook for authenticating users. Would it be enough to design an API that Mailman would call, given an email address (future: login name) and a password, and ask if they matched? This way, you could write a little Python glue code to consult any password database available. -Barry [1] http://www.python.org/~bwarsaw/software/pyware.html From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Jul 29 23:26:03 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 29 Jul 1999 18:26:03 -0400 (EDT) Subject: [Mailman-Developers] message board functionality? References: <000201bed9f4$e9043fd0$723e2080@bean.eecs.berkeley.edu> Message-ID: <14240.54523.53233.90128@anthem.cnri.reston.va.us> >>>>> "DD" == Dan Delaney writes: DD> Purhaps a good way to facilitate this would be to publish a DD> clear specification for how all of the data is stored in the DD> config.db files for lists so that if you already have an DD> Intranet application set up you can just add in a little code DD> to change the Mailman list data yourself. This wouldn't be hard to do, and you might not even need to know the format for the config.db file. You could probably write a small script (using bin/sync_members, etc.) that does the modification for you. In fact, I wrote sync_members to make it easy to synchronize PSA member addresses with our external database. Writing a script for hacking a user's password wouldn't be hard. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Jul 29 23:28:58 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 29 Jul 1999 18:28:58 -0400 (EDT) Subject: [Mailman-Developers] RE: Mailman-Developers digest, Vol 1 #328 - 6 msgs References: <613145F79272D211914B0020AFF640191D1C3C@gandalf.digicool.com> Message-ID: <14240.54698.306259.682268@anthem.cnri.reston.va.us> >>>>> "KM" == Ken Manheimer writes: KM> I think the regular matrix you use is too regular - i'd prefer KM> the links to the configuration options pages to be more KM> clearly separate from the "other" activities. I think having KM> them in two separate columns, as we currently do, is not a bad KM> arrangement I agree. Dan, would it be difficult to simply separate columns 1&2 from column 3? -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Jul 29 23:31:29 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 29 Jul 1999 18:31:29 -0400 (EDT) Subject: [Mailman-Developers] RE: Mailman-Developers digest, Vol 1 #328 - 6 msgs References: <613145F79272D211914B0020AFF640191D1C3C@gandalf.digicool.com> Message-ID: <14240.54849.147230.336426@anthem.cnri.reston.va.us> >>>>> "HM" == Harald Meland writes: HM> Like, in a separate frame, maybe? That's what I've been HM> thinking, anyway... HM> However, the frame-full UI should be optional. For a HM> frame-less UI, I agree with Ken. Harald, I hope you're not advocating using HTML s! I absolutely detest those things :). I think we can get all the benefits of frames without the headaches by using an arrangement similar to www.python.org and www.jpython.org (and not-coincidentally www.python.org/~bwarsaw :) I'm hoping the sidebar idea will be useful for eliminating the HTML dead-ends we currently have. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Jul 29 23:46:33 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 29 Jul 1999 18:46:33 -0400 (EDT) Subject: [Mailman-Developers] Re: Subject Cleanup Routine References: Message-ID: <14240.55753.592871.296391@anthem.cnri.reston.va.us> >>>>> "DD" == Dan Delaney writes: DD> Unfortunately the MUAs out there do a crappy job of this. Look DD> at how many messages you get with things like "Re: Fwd: RE:" DD> in the subject. I get a lot, and it's awefully annoying. I agree, but trying to work around every f*cked up MUA (let alone MTA, let alone Web browser, let alone OS) will keep us all very busy for a very long time! Okay, maybe I'm being extreme... :) DD> Anyway. What would be nice would be a radio button option in DD> the General Options to choose between the existing routine, DD> which simply checks to see if the Prefix is already present in DD> the subject, and a the more aggressive subject cleanup DD> routine. I'm very leary about adding even more configuration options to the Web interface. I'd like to /simplify/ the interfaces as much as possible. That's the beauty of having the source though, isn't it? :) -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Jul 29 23:51:13 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 29 Jul 1999 18:51:13 -0400 (EDT) Subject: [Mailman-Developers] Configurable Archiving Proposal References: Message-ID: <14240.56033.996260.137896@anthem.cnri.reston.va.us> >>>>> "PH" == Paul Hebble writes: PH> I want to set up Mailman to support other archiving methods, PH> more cleanly than subscribing a procmailrc to a list. I know PH> a few other people are interested in this as well. PH> I would like to add a per-list configuration option to each PH> list's config.db which tells Mailman a command line to run to PH> archive a message. Is this any more complicated than adding a PH> variable to the MailList class and adding a few lines to PH> Archiver/Archiver.py? PH> What do other users and developers think of this idea? Is it PH> dangerous to allow a list adminstrator to execute arbitrary PH> commands? If so, how else could this be done? Is it that important to allow individual lists to have different archiving mechanisms? Dave Cinege posted[1] a message to mailman-users explaining how he hooks MHonArc to Mailman and I'm playing with the approach right now (if I can actually get perl to build :). -Barry [1] http://www.python.org/pipermail/mailman-users/1999-July/001726.html From lindsey@ncsa.uiuc.edu Fri Jul 30 00:07:57 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Thu, 29 Jul 1999 18:07:57 -0500 (CDT) Subject: [Mailman-Developers] Configurable Archiving Proposal In-Reply-To: <14240.56033.996260.137896@anthem.cnri.reston.va.us> from "Barry A. Warsaw" at Jul 29, 99 06:51:13 pm Message-ID: <199907292307.SAA06604@ferret.ncsa.uiuc.edu> > Is it that important to allow individual lists to have different > archiving mechanisms? I don't think so, although it might be useful to use different archiving mechanisms for internal vs. external. Actually I might be to blame for this -- Paul asked me about it and I may have misunderstood his question. > Dave Cinege posted[1] a message to mailman-users explaining how he > hooks MHonArc to Mailman and I'm playing with the approach right now > (if I can actually get perl to build :). It's an icky approach, though... Like he mentions, it's pre-filtering based *and* requires admin permissions to modify anything. If it has to be hacked, I prefer to subscribe a known alias or account to the list, then have that call a .procmailrc file (which can call other files writeable by the Web group, etc.) What we're trying to do is generalize Mailman's archiver enough so that you can drop any binary into pipermail's place. Chris From bwarsaw@python.org Fri Jul 30 00:17:22 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Thu, 29 Jul 1999 19:17:22 -0400 (EDT) Subject: [Mailman-Developers] Configurable Archiving Proposal References: <14240.56033.996260.137896@anthem.cnri.reston.va.us> <199907292307.SAA06604@ferret.ncsa.uiuc.edu> Message-ID: <14240.57602.943388.662500@anthem.cnri.reston.va.us> >>>>> "CL" == Christopher Lindsey writes: CL> I don't think so, although it might be useful to use different CL> archiving mechanisms for internal vs. external. In that case, we might be able to add a Default.py variable to control this. CL> It's an icky approach, though... Like he mentions, it's CL> pre-filtering based *and* requires admin permissions to modify CL> anything. If it has to be hacked, I prefer to subscribe a CL> known alias or account to the list, then have that call a CL> .procmailrc file (which can call other files writeable by the CL> Web group, etc.) CL> What we're trying to do is generalize Mailman's archiver CL> enough so that you can drop any binary into pipermail's place. A laudable goal. BTW, I just converted my first mbox to HTML using MHonArc. There are some things I don't like (where are the by-author and by-date archives? Can I split my months and give an overview similar to Pipermail? Perhaps I can and haven't read enough of the manual...) -Barry From lindsey@ncsa.uiuc.edu Fri Jul 30 00:26:18 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Thu, 29 Jul 1999 18:26:18 -0500 (CDT) Subject: [Mailman-Developers] Configurable Archiving Proposal In-Reply-To: <14240.57602.943388.662500@anthem.cnri.reston.va.us> from "Barry A. Warsaw" at Jul 29, 99 07:17:22 pm Message-ID: <199907292326.SAA06725@ferret.ncsa.uiuc.edu> > BTW, I just converted my first mbox to HTML using MHonArc. There are > some things I don't like (where are the by-author and by-date > archives? Can I split my months and give an overview similar to > Pipermail? Perhaps I can and haven't read enough of the manual...) MHonArc won't split by month (it expects you to do this beforehand), but you can create author/by-date archives using rc files. I usually pre-process with procmail to do the splitting (and create an archive of the actual Berkeley-style mbox in case I need to recreate the archives, etc.) Take a look at http://www.mallorn.com/lists/ for lists in action, and http://www.mallorn.com/~lindsey/mhonarc/ for the rc files that make the definitions that you're looking for. They're old though -- our newer ones are site-specific based on local patches. Chris From petrilli@amber.org Fri Jul 30 00:55:24 1999 From: petrilli@amber.org (Christopher Petrilli) Date: Thu, 29 Jul 1999 19:55:24 -0400 Subject: [Mailman-Developers] Face lift for User Interface In-Reply-To: ; from Dan Delaney on Thu, Jul 29, 1999 at 11:58:05AM -0400 References: <19990728123947.B21085@amber.org> Message-ID: <19990729195524.A1656@amber.org> On Thu, Jul 29, 1999 at 11:58:05AM -0400, Dan Delaney wrote: > From: Christopher Petrilli > > Well, colors work fine across all browsers that I've been able to test > > with. More advanced features aren't consistent, but some things that > > I've not had any real problems with: > > * Colors > > Well, everything works great in these new CSS mockups except for one thing. > NETSCRAPE DOESN'T SET THE COLORS FOR THE BODY TAG! Yes. I'm using Netscrape > 4.5 and when I specify a style sheet like "BODY { background-color: #000000; > color: #FFFFFF }", Netscrape doesn't set the page background to black and > text to white. I don't know whether or not MSIE does because my copy of > MSIE5 bombs as soon as it is launched (it's running on WinNT, what do you > expect! :-), so could someone please check it out (CSS mockup 3 is the one > that should have a black background for the page) with MSIE (versions 3, 4, > and 5) and let me know what it does? Well, I forgot about this, IE behaves properly in this case... but that's definately a bummer... I just set the body tag manually. > Anyway, go check out the new CSS mockups at www.Dionysia.org/temp/mailman/ > and let me know what you think. Looks good, and loads faster for me. > > * Font size, especially relative (never use absolute) > > I always specify type size in ems, which is the ideal relative type size > measurment unit. Um, this breaks on *NIX because tehy have rather antiquated ideas about fonts. I get this constantly from Linux people "whine whine, your fonts are too small"... I have to set them to like 18pt before they quit whining, so I just quitsetting ANYTHING in absolute. Um, setting font size in "ems" is a riot, BTW, since the definition of an em depends on the font you're in, no? :-) Try using percentages. Spacing is defined in ems, not fonts. Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright From u.wisser@luna-park.de Fri Jul 30 08:35:02 1999 From: u.wisser@luna-park.de (Ulrich Wisser) Date: Fri, 30 Jul 1999 09:35:02 +0200 Subject: [Mailman-Developers] internationalization of Mailman References: <19990726162117.22806.rocketmail@web601.yahoomail.com> <14240.52879.986015.20651@anthem.cnri.reston.va.us> Message-ID: <37A155A6.35AC987F@luna-park.de> Hello, > There really is no comprehensive framework for supporting I18N in > Mailman 1.0, but I would really like to put together a task force for > supporting this in the next release. I'd like to be in that TF. I18N is really needed at my site. BTW I have another feature request: MODERATOR-WEB-INTRFACE How abount a moderator web-interface? The normal admin interface is much to "technical" for the moderators at my site. They just need to subscribe/unsubscribe, change users and authorize posts to the list. They should not have any options to change the webpages the listinfo... So long Ulli -- ----------------- Die Website Effizienzer ------------------ luna-park Bravo Sanchez, Vollmert, Wisser GbR Ulrich Wisser mailto:u.wisser@luna-park.de Alter Schlachthof, Immenburgstr. 20 Tel +49-228-9654055 D-53121 Bonn Fax +49-228-9654057 ------------------http://www.luna-park.de ------------------ From bwarsaw@python.org Fri Jul 30 15:45:56 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Fri, 30 Jul 1999 10:45:56 -0400 (EDT) Subject: [Mailman-Developers] internationalization of Mailman References: <19990726162117.22806.rocketmail@web601.yahoomail.com> <14240.52879.986015.20651@anthem.cnri.reston.va.us> <37A155A6.35AC987F@luna-park.de> Message-ID: <14241.47780.867382.82846@anthem.cnri.reston.va.us> >>>>> "UW" == Ulrich Wisser writes: UW> BTW I have another feature request: MODERATOR-WEB-INTRFACE UW> How abount a moderator web-interface? The normal admin UW> interface is much to "technical" for the moderators at my UW> site. They just need to subscribe/unsubscribe, change users UW> and authorize posts to the list. They should not have any UW> options to change the webpages the listinfo... I agree. Moderator and admin should be two separate roles. -Barry