From Gergely Madarasz Tue Feb 2 10:52:58 1999 From: Gergely Madarasz (Gergely Madarasz) Date: Tue, 2 Feb 1999 11:52:58 +0100 (MET) Subject: [Mailman-Developers] Returned mail: unknown mailer error 1 (fwd) 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. --LAB01661.917951806/mlf.linux.rulez.org Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hello! Since I upgraded my linux kernel to 2.0.36 with the secure linux patch, I get the following error (the posts get delivered though). Any ideas how to fix this ? Greg ---------- Forwarded message ---------- Date: Tue, 2 Feb 1999 11:36:46 +0100 From: Mail Delivery Subsystem To: test-admin@mlf.linux.rulez.org Subject: Returned mail: unknown mailer error 1 The original message was received at Tue, 2 Feb 1999 11:36:39 +0100 from darmol.elte.hu [157.181.3.1] ----- The following addresses had permanent fatal errors ----- |"/var/lib/mailman/mail/wrapper post test" (expanded from: ) ----- Transcript of session follows ----- Traceback (innermost last): File "/var/lib/mailman/scripts/post", line 65, in ? current_list.Post(msg) File "/usr/lib/mailman/Mailman/MailList.py", line 1166, in Post self.Save() File "/usr/lib/mailman/Mailman/MailList.py", line 683, in Save file = aside_new(fname, fname_last, reopen=1) File "/usr/lib/mailman/Mailman/MailList.py", line 1211, in aside_new os.link(old_name, new_name) os.error: (1, 'Operation not permitted') 554 |"/var/lib/mailman/mail/wrapper post test"... unknown mailer error 1 --LAB01661.917951806/mlf.linux.rulez.org-- From gorgo@caesar.elte.hu Tue Feb 2 11:45:06 1999 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Tue, 2 Feb 1999 12:45:06 +0100 (MET) Subject: [Mailman-Developers] Returned mail: unknown mailer error 1 (fwd) In-Reply-To: Message-ID: On Tue, 2 Feb 1999, Gergely Madarasz wrote: > Hello! > > Since I upgraded my linux kernel to 2.0.36 with the secure linux patch, I > get the following error (the posts get delivered though). > Any ideas how to fix this ? Don't bother, I had to turn off the hardlink attack check, now it should work :/ -- 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 sheber@mwci.net Tue Feb 2 18:42:43 1999 From: sheber@mwci.net (Sean Heber) Date: Tue, 2 Feb 1999 12:42:43 -0600 Subject: [Mailman-Developers] Drool... Message-ID: <004301be4edb$d2281880$05172dc6@sean_heber.mcgraw-hill.com> Ok, I just got Mailman installed and working. That was easy. I just created a list. That was easy. I just managed a list. That was easy. I just have this sudden urge to send all of you developers LOTS AND LOTS of money!!! Mailman is INSANE! I am in love, I think. You guys (and gals?) totaly ROCK! If I had lots of money, you can be sure that I would have sent you all a truck load. rm -r majordomo THANKS SO MUCH!! You made my day! l8r Sean ---- Like games? http://www.legions.com/ From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Feb 2 18:55:50 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 2 Feb 1999 13:55:50 -0500 (EST) Subject: [Mailman-Developers] Drool... References: <004301be4edb$d2281880$05172dc6@sean_heber.mcgraw-hill.com> Message-ID: <14007.18998.750060.760331@anthem.cnri.reston.va.us> >>>>> "SH" == Sean Heber writes: SH> Ok, I just got Mailman installed and working. SH> That was easy. SH> I just created a list. SH> That was easy. SH> I just managed a list. SH> That was easy. Excellent! SH> I just have this sudden urge to send all of you developers SH> LOTS AND LOTS of money!!! SH> Mailman is INSANE! I am in love, I think. You guys (and SH> gals?) totaly ROCK! If I had lots of money, you can be sure SH> that I would have sent you all a truck load. Oh darn, you were just foolin'! And I was hoping you were serious so I could spend some, er, "real" time hacking on Mailman :-) SH> rm -r majordomo SH> THANKS SO MUCH!! You made my day! We've got a long TODO list, but I'm glad you like what you see so far. -Barry, who is way behind on Mailman email :-( From gstein@lyra.org Wed Feb 3 12:22:15 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 03 Feb 1999 04:22:15 -0800 Subject: [Mailman-Developers] password-less unsubscribe Message-ID: <36B83F77.4DABB7DD@lyra.org> Here is another request for a password-less unsubscribe... A friend is running a mailing list. It is generally composed of morons (not my friend, tho :-). Anyhow... these guys cannot for the life of them figure out how to unsubscribe. They do the email thing and it spits back about the password. Of course, these guys have no idea how to GET to their options page, hit the button, and have a password mailed to them. So they're stuck. I strongly vote for the "let them unsubscribe, and send a notice" theory. thx -g -- Greg Stein, http://www.lyra.org/ From tomas@euronetics.se Wed Feb 3 12:43:52 1999 From: tomas@euronetics.se (Tomas Fasth) Date: Wed, 03 Feb 1999 13:43:52 +0100 Subject: [Mailman-Developers] removing entries from aliases References: <014201be4d15$b6fdf060$0e45fea9@fred> Message-ID: <36B84488.3EBA911C@euronetics.se> Stu Ekins wrote: > I agree. Wouldn't it be a better idea to have a second aliases file that > only mailman can modify, then have an alternative version of newaliases that > concatenates the standard /etc/aliases and the mailman aliases together, > before processing. Most MTAs, including sendmail (exim is my personal favorite), can handle multiple alias files. As for sendmail you have to modify sendmail.cf like (version 8.8 and above): O AliasFile=/etc/aliases,/home/mailman/aliases The command newaliases, which updates the sendmail alias databases, automatically recognizes the new configuration with multiple alias files. I do use a separate mailman alias file myself, although with exim as MTA. The configuration looks like this (in /etc/exim.conf): mailman_aliases: driver = aliasfile domains = list.twinspot.net file = /home/mailman/aliases search_type = lsearch user = mailman group = mailman By the way, exim does not use newaliases for aliases updates. regards, Tomas From gstein@lyra.org Wed Feb 3 12:44:44 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 03 Feb 1999 04:44:44 -0800 Subject: [Mailman-Developers] bug in "mail me my password" Message-ID: <36B844BC.2B6FCED@lyra.org> When I went to a user's option page and hit their button, it barfed at me saying "not a member!" I believe it is related to upper-case values in the user's email address. This is with 1.0b6. -g -- Greg Stein, http://www.lyra.org/ From tomas@euronetics.se Wed Feb 3 12:48:23 1999 From: tomas@euronetics.se (Tomas Fasth) Date: Wed, 03 Feb 1999 13:48:23 +0100 Subject: [Mailman-Developers] password-less unsubscribe References: <36B83F77.4DABB7DD@lyra.org> Message-ID: <36B84597.19DA4158@euronetics.se> Greg Stein wrote: > I strongly vote for the "let them unsubscribe, and send a notice" > theory. Better yet, make it work like when subscribing, delay the execution, sending a mail to the adress in question with a key. If the key is not returned in a reply the subscription stay intact. Tomas From gstein@lyra.org Wed Feb 3 12:51:15 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 03 Feb 1999 04:51:15 -0800 Subject: [Mailman-Developers] password-less unsubscribe References: <36B83F77.4DABB7DD@lyra.org> <36B84597.19DA4158@euronetics.se> Message-ID: <36B84643.715B653F@lyra.org> Tomas Fasth wrote: > > Greg Stein wrote: > > > I strongly vote for the "let them unsubscribe, and send a notice" > > theory. > > Better yet, make it work like when subscribing, delay the execution, > sending a mail to the adress in question with a key. If the key is not > returned in a reply the subscription stay intact. That's a possibility, but for this list... remember: they're idiots. If they were accidentally/maliciously unsubscribed, then they can always resubscribe. Really... how often does somebody maliciously unsubscribe somebody? I have to imagine it is quite rare. I'd rather take the safe side and let them get off the list as easy as possible. I'd actually prefer a confirmation-less subscription, too, and have something in the subscribe acknowledgement say "if you were subscribed in error, then hit URL to unsubscribe" -g -- Greg Stein, http://www.lyra.org/ From tomas@euronetics.se Wed Feb 3 13:45:29 1999 From: tomas@euronetics.se (Tomas Fasth) Date: Wed, 03 Feb 1999 14:45:29 +0100 Subject: [Mailman-Developers] password-less unsubscribe References: <36B83F77.4DABB7DD@lyra.org> <36B84597.19DA4158@euronetics.se> <36B84643.715B653F@lyra.org> Message-ID: <36B852F9.A696C29@euronetics.se> Greg Stein wrote: > That's a possibility, but for this list... remember: they're idiots. I wonder how did they get on the list in the first place if they are such morons? Can this be a situation were users are added to a list against their will and then get angry because they can not get off the list fast enough? If so, tough luck, it's the list owner's own fault. The list owner should be responsible to remove the subscribers by his/her own hand. My personal opinion is that the design of Mailman as well as other list managing software should not promote unsolicited subscription/unsubscription. > If they were accidentally/maliciously unsubscribed, then they can always > resubscribe. That is what a list owner usually want to avoid. Unnecessary exposure to accidental/malicious subscription/unsubscription is not an option, in my humble opinion. It only adds to the level of irritation and work load. > Really... how often does somebody maliciously unsubscribe somebody? I > have to imagine it is quite rare. I'd rather take the safe side and let > them get off the list as easy as possible. Sure, it's rare because there are measures taken against it. The only "safe" side is to require subscribers to follow a procedure that oppress malicious behavior. > I'd actually prefer a confirmation-less subscription, too, and have > something in the subscribe acknowledgement say "if you were subscribed > in error, then hit URL to unsubscribe" I don't share your opinion. As a Mailman administrator, I'm glad the confirmation mechanism is there as a small but effective safety precaution. Besides, if the world is full of idiots like you describe, that kind of acknowledgement would not do much help. Tomas From roy@endeavor.med.nyu.edu Wed Feb 3 16:10:03 1999 From: roy@endeavor.med.nyu.edu (Roy Smith) Date: Wed, 03 Feb 1999 11:10:03 -0500 Subject: [Mailman-Developers] password-less unsubscribe In-Reply-To: <36B84597.19DA4158@euronetics.se> Message-ID: <122771.3127029003@mc-as01-p53.med.nyu.edu> The problem with this is that: 1) Somebody subscribes with address user@foo.com 2) They switch ISPs and become user@bar.com 3) They now want to unsubscribe user@foo.com and subscribe user@bar.com. If a confirmation request is mailed to user@foo.com, you loose because user@foo.com is probably no longer a valid address. --On Wed, Feb 3, 1999 1:48 PM +0100 Tomas Fasth wrote: > Better yet, make it work like when subscribing, delay the execution, > sending a mail to the adress in question with a key. If the key is not > returned in a reply the subscription stay intact. Roy Smith New York University School of Medicine 550 First Avenue, New York, NY 10016 From tomas@euronetics.se Wed Feb 3 16:51:41 1999 From: tomas@euronetics.se (Tomas Fasth) Date: Wed, 03 Feb 1999 17:51:41 +0100 Subject: [Mailman-Developers] password-less unsubscribe References: <122771.3127029003@mc-as01-p53.med.nyu.edu> Message-ID: <36B87E9D.E5BC748B@euronetics.se> Roy Smith wrote: > > The problem with this is that: > > 1) Somebody subscribes with address user@foo.com > > 2) They switch ISPs and become user@bar.com > > 3) They now want to unsubscribe user@foo.com and subscribe user@bar.com. > > If a confirmation request is mailed to user@foo.com, you loose because > user@foo.com is probably no longer a valid address. That scenario is a problem for the subscriber, no doubt about it. Since the email address essentially represents the identity of the subscriber, a change of email address and therefore identity is problematic if you at the same time in general want to maintain a certain level of integrity. Providing a personal password is one way to deal with this dilemma. Another is to contact the list owner and persuade her/him to make the change. But I do not recommend to completely remove from mailman the minimal requirement of proving your identity by email address or password. Tomas From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Feb 3 17:44:08 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 3 Feb 1999 12:44:08 -0500 (EST) Subject: [Mailman-Developers] Digesting bug Message-ID: <14008.35560.599266.639507@anthem.cnri.reston.va.us> I'm slammed for time, but I want to get this bug report into the loop (we really need Jitterbug or some such!). Anyway, if someone switches from digest mode to regular delivery, they need to receive at least one more digest, otherwise they will lose mail. Or they need to receive the digest up to the point of their delivery mode switch. This just happened me. I toggled on regular delivery of jpython-interest just before the digests were sent out today, so I lost all email since yesterday. :-( -Barry From petrilli@amber.org Wed Feb 3 17:59:32 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Wed, 3 Feb 1999 12:59:32 -0500 Subject: [Mailman-Developers] Digesting bug In-Reply-To: <14008.35560.599266.639507@anthem.cnri.reston.va.us>; from Barry A. Warsaw on Wed, Feb 03, 1999 at 12:44:08PM -0500 References: <14008.35560.599266.639507@anthem.cnri.reston.va.us> Message-ID: <19990203125932.50487@amber.org> On Wed, Feb 03, 1999 at 12:44:08PM -0500, Barry A. Warsaw wrote: > > Anyway, if someone switches from digest mode to regular delivery, they > need to receive at least one more digest, otherwise they will lose > mail. Or they need to receive the digest up to the point of their > delivery mode switch. > > This just happened me. I toggled on regular delivery of > jpython-interest just before the digests were sent out today, so I > lost all email since yesterday. :-( > I think the best way to handle this would be to just shove out a copy of the CURRENT digest when the user modifies their setting, no? No readon to wait until the digest goes out LATER, just run the digest-send w/1 recipient. Chris -- | Christopher Petrilli | petrilli@amber.org From bwarsaw@python.org Wed Feb 3 18:00:31 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Wed, 3 Feb 1999 13:00:31 -0500 (EST) Subject: [Mailman-Developers] Digesting bug References: <14008.35560.599266.639507@anthem.cnri.reston.va.us> <19990203125932.50487@amber.org> Message-ID: <14008.36543.695779.894540@anthem.cnri.reston.va.us> >>>>> "CGP" == Christopher G Petrilli writes: CGP> I think the best way to handle this would be to just shove CGP> out a copy of the CURRENT digest when the user modifies their CGP> setting, no? No readon to wait until the digest goes out CGP> LATER, just run the digest-send w/1 recipient. Agreed. From rocon@pivot.net Fri Feb 5 13:56:31 1999 From: rocon@pivot.net (Robert OConnor) Date: Fri, 5 Feb 1999 08:56:31 -0500 Subject: [Mailman-Developers] Unsubscribed WITHOUT my permission Message-ID: <00a301be510f$59a99d80$0201a8c0@hawkeye.bob.oc> Twice in February I have been unsubscribed from zope@zope.org mail list that is running: --- Mailman v 1.0b8. pre-GNU beta release I went and checked my options and found: http://www.zope.org/mailman/subscribe/zope *-- Disable mail delivery Turn this on if you want mail to not be delivered to you for a little while. On *-- Ok, _maybe_ my busy mail server bounces mail on occasion or maybe the mail got stuck somewhere in the icloud....I had assumed that bounce mail makes a few attempts before failure. My mail server at my ISP: pivot.net has continued to work fine although I understand that it is busy. I have no problems with this on other lists. The MailMan "to do" list shows these issues relevant to my problem: Bugs "Stale" addresses don't update properly when new bounces come in (stale means we had some bounces, but delivery to that address started working again before we booted them from the list) Bounce handling Add more patterns for bounce handling Send mail to people that are being removed w/o their knowledge (even though they're likely not to get it). ***Hey, I AM likely to get it*** I am writing as a USER, not a list maintainer. ***I strongly encourage you to send mail if you disable "my" settings automatically. Questions: How many times does MailMan mail "Bounce" before you disable it? A few tries should be made... Maybe the retries should be delayed and made at some interval such as 20 or 30 minutes. From rocon@pivot.net Fri Feb 5 14:06:34 1999 From: rocon@pivot.net (Robert OConnor) Date: Fri, 5 Feb 1999 09:06:34 -0500 Subject: [Mailman-Developers] Domain Mail forwarding problem Message-ID: <00ac01be5110$bfa76da0$0201a8c0@hawkeye.bob.oc> I first subscribed to zope@zope.org mail list that is running: --- Mailman v 1.0b8. pre-GNU beta release I attempted to subscribe using my domain and forwarding mail to my ISP email address Mail FromDomain: bob@rocnet.com Is forwarded to my ISP POP email: rocon@pivot.net This does not work with MailMan. Or perhaps only partially works. I cannot see "posts you send to the list? " even though this option is on. I understand from others that MailMan does not support this because it somehow prevents spammers from accessing the list. How about an OPTION that I specifically check that sez: "Allow forwarded Mail?: Yes/No and if necessary, a place to enter both email addresses. I use my domain in another way that helps me filter my mail. If I subscribe to the zope mail list, I subscribe as zope@rocnet.com (Zope being the list I subscribe to and rocnet my domain that forwards everything... Thank you. Keep up the good work. -bobo connor From sylvainb@uniconseil.com Fri Feb 5 16:22:48 1999 From: sylvainb@uniconseil.com (Sylvain Bolduc) Date: Fri, 5 Feb 1999 11:22:48 -0500 Subject: [Mailman-Developers] MailMan 1.0b7 Message-ID: <001d01be5123$c529aaa0$989b2fce@sly.uniconseil.com> This is a multi-part message in MIME format. ------=_NextPart_000_001E_01BE50F9.DC53A2A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkknbSBhIHN5c3RlbSBhZG1pbmlzdHJhdGlvbiBvZiB0aGUgVW5pY29uc2VpbCBN YWlsIFNlcnZlci4NCg0KUmVjZW50bHksIGkndmUgdHJpZWQgdG8gdXNlL2luc3RhbGwgTWFpbE1h biAxLjBiNyBvdmVyIExpbnV4IFJFREhBVCA1LjIuDQoNCkJ1dCBTaW5jZSB5ZXN0ZXJkYXksIGkn bSBnZXR0aW5nIGFsb3Qgb2YgdGhvc2VzIGVycm9ycy4NCkkgQ2FuJ3QgZmluZCBhIHdheSB0byBm aXggdGhlIHByb2JsZW0uDQoNCkRvIHlvdSB0aGluayBpIG5lZWQgdG8gdXBncmFkZSB0byAxLjBi OCA/DQoNCg0KLS0tLS0tLQ0KDQpXZSdyZSBzb3JyeSwgd2UgaGl0IGEgYnVnIQ0KDQpJZiB5b3Ug d291bGQgbGlrZSB0byBoZWxwIHVzIGlkZW50aWZ5IHRoZSBwcm9ibGVtLCBwbGVhc2UgZW1haWwg YSBjb3B5IG9mIHRoaXMgcGFnZSB0byB0aGUgd2VibWFzdGVyIGZvciB0aGlzIHNpdGUgd2l0aCBh IGRlc2NyaXB0aW9uIG9mIHdoYXQgaGFwcGVuZWQuDQpUaGFua3MhIA0KDQpUcmFjZWJhY2s6DQoN Cg0KVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQogIEZpbGUgIi9ob21lL21haWxtYW4vc2Ny aXB0cy9kcml2ZXIiLCBsaW5lIDEwMiwgaW4gcnVuX21haW4NCiBtYWluKCkNCg0KICBGaWxlICIv aG9tZS9tYWlsbWFuL01haWxtYW4vQ2dpL2FkbWluZGIucHkiLCBsaW5lIDEyNCwgaW4gbWFpbg0K ICAgIEhhbmRsZVJlcXVlc3RzKGRvYykNCg0KICBGaWxlICIvaG9tZS9tYWlsbWFuL01haWxtYW4v Q2dpL2FkbWluZGIucHkiLCBsaW5lIDIxMSwgaW4gSGFuZGxlUmVxdWVzdHMNCiAgICBsaXN0Lkhh bmRsZVJlcXVlc3QocmVxdWVzdCwgdikNCg0KICBGaWxlICIvaG9tZS9tYWlsbWFuL01haWxtYW4v TGlzdEFkbWluLnB5IiwgbGluZSAxMjIsIGluIEhhbmRsZVJlcXVlc3QNCiAgICBzZWxmLkhhbmRs ZVBvc3RSZXF1ZXN0KHJlcXVlc3RfZGF0YVsyOl0sIHZhbHVlLCBjb21tZW50KQ0KDQogIEZpbGUg Ii9ob21lL21haWxtYW4vTWFpbG1hbi9MaXN0QWRtaW4ucHkiLCBsaW5lIDEzMSwgaW4gSGFuZGxl UG9zdFJlcXVlc3QNCiAgICBzZWxmLlBvc3QobXNnLCAxKQ0KDQogIEZpbGUgIi9ob21lL21haWxt YW4vTWFpbG1hbi9NYWlsTGlzdC5weSIsIGxpbmUgMTE1OCwgaW4gUG9zdA0KICAgIHNlbGYuRGVs aXZlclRvTGlzdChtc2csIHJlY2lwaWVudHMsDQoNCiAgRmlsZSAiL2hvbWUvbWFpbG1hbi9NYWls bWFuL0RlbGl2ZXJlci5weSIsIGxpbmUgMTcyLCBpbiBEZWxpdmVyVG9MaXN0DQogICAgc3RhdHVz ID0gY21kcHJvYy5jbG9zZSgpDQpJT0Vycm9yOiAoMTAsICdObyBjaGlsZCBwcm9jZXNzZXMnKQ0K DQoNCg0KDQoNCkVudmlyb25tZW50IHZhcmlhYmxlczoNCg0KIFZhcmlhYmxlDQogICAgICAgICAg ICAgICAgICAgICAgVmFsdWUNCiBIVFRQX0FDQ0VQVF9FTkNPRElORyANCiAgICAgICAgICAgICAg ICAgICAgICBnemlwIA0KIFJFTU9URV9IT1NUIA0KICAgICAgICAgICAgICAgICAgICAgIHNseS51 bmljb25zZWlsLmNvbSANCiBNQUlMIA0KICAgICAgICAgICAgICAgICAgICAgIC92YXIvc3Bvb2wv bWFpbC9yb290IA0KIENPTlRFTlRfVFlQRSANCiAgICAgICAgICAgICAgICAgICAgICBhcHBsaWNh dGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQgDQogSFRUUF9DT09LSUUgDQogICAgICAgICAgICAg ICAgICAgICAgaW1wZXJpYWwtYWRtaW49LTIwNjQ4MjY1Nzc7IHNvbHV0aW9uZXQtYWRtaW49LTQz NTMwNTc2MDsgZGlyZWN0aW9uLWFkbWluPTEyODM0ODQ5OTQ7DQogICAgICAgICAgICAgICAgICAg ICAgaW5mb2dyb3VwZS1hZG1pbj0yMTAzNjM0NjQwIA0KIFdOX1JPT1QgDQogICAgICAgICAgICAg ICAgICAgICAgL3d3dy9odGRvY3MgDQogSFRUUF9BQ0NFUFRfTEFOR1VBR0UgDQogICAgICAgICAg ICAgICAgICAgICAgZW4gDQogSE9TVE5BTUUgDQogICAgICAgICAgICAgICAgICAgICAgcG9zdGVs LnVuaWNvbnNlaWwuY29tIA0KIFVSTF9TQ0hFTUUgDQogICAgICAgICAgICAgICAgICAgICAgaHR0 cCANCiBHQVRFV0FZX0lOVEVSRkFDRSANCiAgICAgICAgICAgICAgICAgICAgICBDR0kvMS4xIA0K IEhUVFBfQUNDRVBUIA0KICAgICAgICAgICAgICAgICAgICAgIGltYWdlL2dpZiwgaW1hZ2UveC14 Yml0bWFwLCBpbWFnZS9qcGVnLCBpbWFnZS9wanBlZywgaW1hZ2UvcG5nLCAqLyogDQogXyANCiAg ICAgICAgICAgICAgICAgICAgICAvd3d3L2h0ZG9jcy9tYWlsbWFuL2FkbWluZGIgDQogRU5WIA0K ICAgICAgICAgICAgICAgICAgICAgIC9yb290Ly5iYXNocmMgDQogSFRUUF9IT1NUIA0KICAgICAg ICAgICAgICAgICAgICAgIHBvc3RlbC51bmljb25zZWlsLmNvbTo4MCANCiBIT1NUVFlQRSANCiAg ICAgICAgICAgICAgICAgICAgICBpMzg2IA0KIFNDUklQVF9GSUxFTkFNRSANCiAgICAgICAgICAg ICAgICAgICAgICAvd3d3L2h0ZG9jcy9tYWlsbWFuL2FkbWluZGIgDQogUFlUSE9OUEFUSCANCiAg ICAgICAgICAgICAgICAgICAgICAvaG9tZS9tYWlsbWFuIA0KIFBBVEggDQogICAgICAgICAgICAg ICAgICAgICAgL3Vzci9iaW46L2JpbjovdXNyL3NiaW46L3NiaW46L3Vzci9YMTFSNi9iaW52dDEw MDovdXNyL1gxMVI2L2Jpbjovcm9vdC9iaW4gDQogVVNFUk5BTUUgDQogICAgICAgICAgICAgICAg ICAgICAgcm9vdCANCiBET0NVTUVOVF9ST09UIA0KICAgICAgICAgICAgICAgICAgICAgIC93d3cv aHRkb2NzIA0KIEhJU1RGSUxFU0laRSANCiAgICAgICAgICAgICAgICAgICAgICAxMDAwIA0KIEhU VFBfUE9TVF9GSUxFIA0KICAgICAgICAgICAgICAgICAgICAgIC90bXAvd25fdG1wNjU1MzQvV05w b3N0LTM2YmIwYjZmLTQxNmQtMCANCiBXTl9ESVJfUEFUSCANCiAgICAgICAgICAgICAgICAgICAg ICAvd3d3L2h0ZG9jcy9tYWlsbWFuIA0KIE9TVFlQRSANCiAgICAgICAgICAgICAgICAgICAgICBM aW51eCANCiBTRVJWRVJfUE9SVCANCiAgICAgICAgICAgICAgICAgICAgICAxMTgwMSANCiBIVFRQ X1VTRVJfQUdFTlQgDQogICAgICAgICAgICAgICAgICAgICAgTW96aWxsYS80LjUgW2VuXSAoV2lu OTg7IFUpIA0KIHZ0MTAwIA0KICAgICAgICAgICAgICAgICAgICAgIC9iaW4vYmFzaCANCiBTSExW TCANCiAgICAgICAgICAgICAgICAgICAgICAyIA0KIFJFTU9URV9BRERSIA0KICAgICAgICAgICAg ICAgICAgICAgIDIwNi40Ny4xNTUuMTUyIA0KIFNFUlZFUl9OQU1FIA0KICAgICAgICAgICAgICAg ICAgICAgIHBvc3RlbC51bmljb25zZWlsLmNvbSANCiBTSEVMTCANCiAgICAgICAgICAgICAgICAg ICAgICAvYmluL2Jhc2ggDQogVEVSTSANCiAgICAgICAgICAgICAgICAgICAgICB2dDEwMCANCiBI VFRQX0FDQ0VQVF9DSEFSU0VUIA0KICAgICAgICAgICAgICAgICAgICAgIGlzby04ODU5LTEsKix1 dGYtOCANCiBDT05URU5UX0xFTkdUSCANCiAgICAgICAgICAgICAgICAgICAgICAzNyANCiBIT01F IA0KICAgICAgICAgICAgICAgICAgICAgIC9yb290IA0KIFNFUlZFUl9QUk9UT0NPTCANCiAgICAg ICAgICAgICAgICAgICAgICBIVFRQLzEuMCANCiBQQVRIX0lORk8gDQogICAgICAgICAgICAgICAg ICAgICAgL2RpcmVjdGlvbiANCiBMT0dOQU1FIA0KICAgICAgICAgICAgICAgICAgICAgIHJvb3Qg DQogUkVRVUVTVF9NRVRIT0QgDQogICAgICAgICAgICAgICAgICAgICAgUE9TVCANCiBQQVRIX1RS QU5TTEFURUQgDQogICAgICAgICAgICAgICAgICAgICAgL3d3dy9odGRvY3MvZGlyZWN0aW9uIA0K IFNDUklQVF9OQU1FIA0KICAgICAgICAgICAgICAgICAgICAgIC9tYWlsbWFuL2FkbWluZGIgDQog U0VSVkVSX1NPRlRXQVJFIA0KICAgICAgICAgICAgICAgICAgICAgIFdOLzIuMS41IA0KIFVTRVIg DQogICAgICAgICAgICAgICAgICAgICAgcm9vdCANCiBIVFRQX1JFRkVSRVIgDQogICAgICAgICAg ICAgICAgICAgICAgaHR0cDovL3Bvc3RlbC51bmljb25zZWlsLmNvbTo4MC9tYWlsbWFuL2FkbWlu ZGIvZGlyZWN0aW9uIA0KIEhJU1RTSVpFIA0KICAgICAgICAgICAgICAgICAgICAgIDEwMDAgDQog UkVNT1RFX1BPUlQgDQogICAgICAgICAgICAgICAgICAgICAgMjA5MyANCg0KLS0tLS0NCg0KQmVz dCBSZWdhcmRzIQ0KDQoNCg0KDQoNClN5bHZhaW4gQm9sZHVjDQpTb2x1dGlvTkVUDQpVbmUgZmls aWFsZSBkdSBHcm91cGUgVW5pY29uc2VpbCBpbmMuDQoxODAxLCBNY0dpbGwgQ29sbGVnZSwgc3Vp dGUgMTAxMA0KTW9udHJlYWwgKFF1ZWJlYykgSDNBIDJONA0KDQpUZWw6ICg1MTQpIDg0MC0xMTU4 IHBvc3RlIDM1MQ0KRmF4OiAoNTE0KSA4NDAtMTE2Ng0Kc3lsdmFpbmJAdW5pY29uc2VpbC5jb20N Cmh0dHA6Ly93d3cudW5pY29uc2VpbC5jb20gDQoNCg0K ------=_NextPart_000_001E_01BE50F9.DC53A2A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD48 SEVBRD4NCjxNRVRBIGNvbnRlbnQ9JyJNU0hUTUwgNS4wMC4wOTEwLjEzMDkiJyBuYW1lPUdFTkVS QVRPUj4NCjxNRVRBIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIiBodHRw LWVxdWl2PUNvbnRlbnQtVHlwZT48L0hFQUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElW PjxTUEFOIGNsYXNzPTMxMDE5MTcxNi0wNTAyMTk5OT48Rk9OVCBzaXplPTI+SGVsbG8sPC9GT05U PjwvU1BBTj48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTMxMDE5 MTcxNi0wNTAyMTk5OT48Rk9OVCBzaXplPTI+SSdtIGEgc3lzdGVtIGFkbWluaXN0cmF0aW9uIG9m IA0KdGhlIFVuaWNvbnNlaWwgTWFpbCBTZXJ2ZXIuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTMxMDE5MTcxNi0wNTAyMTk5OT48Rk9OVCBz aXplPTI+UmVjZW50bHksIGkndmUgdHJpZWQgdG8gDQp1c2UvaW5zdGFsbCBNYWlsTWFuIDEuMGI3 IG92ZXIgTGludXggUkVESEFUIDUuMi48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MzEwMTkxNzE2LTA1MDIxOTk5PjxGT05UIHNpemU9Mj5C dXQgU2luY2UgeWVzdGVyZGF5LCBpJ20gDQpnZXR0aW5nIGFsb3Qgb2YgdGhvc2VzIGVycm9ycy48 L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0zMTAxOTE3MTYtMDUwMjE5OTk+ PEZPTlQgc2l6ZT0yPkkgQ2FuJ3QgZmluZCBhIHdheSB0byBmaXggdGhlIA0KcHJvYmxlbS48L0ZP TlQ+PC9TUEFOPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MzEw MTkxNzE2LTA1MDIxOTk5PjxGT05UIHNpemU9Mj5EbyB5b3UgdGhpbmsgaSBuZWVkIHRvIHVwZ3Jh ZGUgDQp0byAxLjBiOCA/PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0zMTAxOTE3MTYtMDUwMjE5OTk+PEZP TlQgc2l6ZT0yPi0tLS0tLS08L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0xPldlJ3JlIHNvcnJ5LCB3ZSBoaXQgYSBidWchPC9GT05UPjwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0xPklmIHlvdSB3b3VsZCBsaWtl IHRvIGhlbHAgdXMgaWRlbnRpZnkgdGhlIHByb2JsZW0sIHBsZWFzZSANCmVtYWlsIGEgY29weSBv ZiB0aGlzIHBhZ2UgdG8gdGhlIHdlYm1hc3RlciBmb3IgdGhpcyBzaXRlIHdpdGggYSBkZXNjcmlw dGlvbiBvZiANCndoYXQgaGFwcGVuZWQuPEJSPlRoYW5rcyEgPC9GT05UPjwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0xPlRyYWNlYmFjazo8L0ZPTlQ+PC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTE+PEJSPlRyYWNlYmFjayAoaW5uZXJt b3N0IGxhc3QpOjxCUj4gIEZpbGUgDQomcXVvdDsvaG9tZS9tYWlsbWFuL3NjcmlwdHMvZHJpdmVy JnF1b3Q7LCBsaW5lIDEwMiwgaW4gcnVuX21haW48QlI+IDwvRk9OVD48Rk9OVCANCnNpemU9MT5t YWluKCk8QlI+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTE+ICBGaWxlICZxdW90Oy9o b21lL21haWxtYW4vTWFpbG1hbi9DZ2kvYWRtaW5kYi5weSZxdW90OywgbGluZSANCjEyNCwgaW4g bWFpbjxCUj4gICAgSGFuZGxlUmVxdWVzdHMoZG9jKTxCUj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIHNpemU9MT4gIEZpbGUgJnF1b3Q7L2hvbWUvbWFpbG1hbi9NYWlsbWFuL0NnaS9hZG1pbmRi LnB5JnF1b3Q7LCBsaW5lIA0KMjExLCBpbiBIYW5kbGVSZXF1ZXN0czxCUj4gICAgbGlzdC5IYW5k bGVSZXF1ZXN0KHJlcXVlc3QsIHYpPEJSPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0x PiAgRmlsZSAmcXVvdDsvaG9tZS9tYWlsbWFuL01haWxtYW4vTGlzdEFkbWluLnB5JnF1b3Q7LCBs aW5lIA0KMTIyLCBpbiBIYW5kbGVSZXF1ZXN0PEJSPiAgICBzZWxmLkhhbmRsZVBvc3RSZXF1ZXN0 KHJlcXVlc3RfZGF0YVsyOl0sIHZhbHVlLCANCmNvbW1lbnQpPEJSPjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0xPiAgRmlsZSAmcXVvdDsvaG9tZS9tYWlsbWFuL01haWxtYW4vTGlzdEFk bWluLnB5JnF1b3Q7LCBsaW5lIA0KMTMxLCBpbiBIYW5kbGVQb3N0UmVxdWVzdDxCUj4gICAgc2Vs Zi5Qb3N0KG1zZywgMSk8QlI+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTE+ICBGaWxl ICZxdW90Oy9ob21lL21haWxtYW4vTWFpbG1hbi9NYWlsTGlzdC5weSZxdW90OywgbGluZSANCjEx NTgsIGluIFBvc3Q8QlI+ICAgIHNlbGYuRGVsaXZlclRvTGlzdChtc2csIHJlY2lwaWVudHMsPEJS PjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0xPiAgRmlsZSAmcXVvdDsvaG9tZS9tYWls bWFuL01haWxtYW4vRGVsaXZlcmVyLnB5JnF1b3Q7LCBsaW5lIA0KMTcyLCBpbiBEZWxpdmVyVG9M aXN0PEJSPiAgICBzdGF0dXMgPSBjbWRwcm9jLmNsb3NlKCk8QlI+SU9FcnJvcjogKDEwLCAnTm8g Y2hpbGQgDQpwcm9jZXNzZXMnKTwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTE+RW52aXJvbm1lbnQgdmFyaWFibGVzOjwv Rk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48Rk9OVCBz aXplPTE+IFZhcmlhYmxlPEJSPiAgICAgICAgICAgICAgICAgICAgICBWYWx1ZTxCUj4gDQpIVFRQ X0FDQ0VQVF9FTkNPRElORyA8QlI+ICAgICAgICAgICAgICAgICAgICAgIGd6aXAgPEJSPiBSRU1P VEVfSE9TVCA8QlI+ICAgICAgICANCiAgICAgICAgICAgICAgc2x5LnVuaWNvbnNlaWwuY29tIDxC Uj4gTUFJTCA8QlI+ICAgICAgICAgICAgICAgICAgICAgIA0KL3Zhci9zcG9vbC9tYWlsL3Jvb3Qg PEJSPiBDT05URU5UX1RZUEUgPEJSPiAgICAgICAgICAgICAgICAgICAgICANCmFwcGxpY2F0aW9u L3gtd3d3LWZvcm0tdXJsZW5jb2RlZCA8QlI+IEhUVFBfQ09PS0lFIDxCUj4gICAgICAgICAgICAg ICAgICAgICAgDQppbXBlcmlhbC1hZG1pbj0tMjA2NDgyNjU3Nzsgc29sdXRpb25ldC1hZG1pbj0t NDM1MzA1NzYwOyANCmRpcmVjdGlvbi1hZG1pbj0xMjgzNDg0OTk0OzxCUj4gICAgICAgICAgICAg ICAgICAgICAgaW5mb2dyb3VwZS1hZG1pbj0yMTAzNjM0NjQwIA0KPEJSPiBXTl9ST09UIDxCUj4g ICAgICAgICAgICAgICAgICAgICAgL3d3dy9odGRvY3MgPEJSPiBIVFRQX0FDQ0VQVF9MQU5HVUFH RSANCjxCUj4gICAgICAgICAgICAgICAgICAgICAgZW4gPEJSPiBIT1NUTkFNRSA8QlI+ICAgICAg ICAgICAgICAgICAgICAgIA0KcG9zdGVsLnVuaWNvbnNlaWwuY29tIDxCUj4gVVJMX1NDSEVNRSA8 QlI+ICAgICAgICAgICAgICAgICAgICAgIGh0dHAgPEJSPiANCkdBVEVXQVlfSU5URVJGQUNFIDxC Uj4gICAgICAgICAgICAgICAgICAgICAgQ0dJLzEuMSA8QlI+IEhUVFBfQUNDRVBUIDxCUj4gICAg ICAgIA0KICAgICAgICAgICAgICBpbWFnZS9naWYsIGltYWdlL3gteGJpdG1hcCwgaW1hZ2UvanBl ZywgaW1hZ2UvcGpwZWcsIGltYWdlL3BuZywgDQoqLyogPEJSPiBfIDxCUj4gICAgICAgICAgICAg ICAgICAgICAgL3d3dy9odGRvY3MvbWFpbG1hbi9hZG1pbmRiIDxCUj4gRU5WIDxCUj4gICANCiAg ICAgICAgICAgICAgICAgICAvcm9vdC8uYmFzaHJjIDxCUj4gSFRUUF9IT1NUIDxCUj4gICAgICAg ICAgICAgICAgICAgICAgDQpwb3N0ZWwudW5pY29uc2VpbC5jb206ODAgPEJSPiBIT1NUVFlQRSA8 QlI+ICAgICAgICAgICAgICAgICAgICAgIGkzODYgPEJSPiANClNDUklQVF9GSUxFTkFNRSA8QlI+ ICAgICAgICAgICAgICAgICAgICAgIC93d3cvaHRkb2NzL21haWxtYW4vYWRtaW5kYiA8QlI+IA0K UFlUSE9OUEFUSCA8QlI+ICAgICAgICAgICAgICAgICAgICAgIC9ob21lL21haWxtYW4gPEJSPiBQ QVRIIDxCUj4gICAgICAgICAgICAgICAgDQogICAgICAvdXNyL2JpbjovYmluOi91c3Ivc2Jpbjov c2JpbjovdXNyL1gxMVI2L2JpbnZ0MTAwOi91c3IvWDExUjYvYmluOi9yb290L2JpbiANCjxCUj4g VVNFUk5BTUUgPEJSPiAgICAgICAgICAgICAgICAgICAgICByb290IDxCUj4gRE9DVU1FTlRfUk9P VCA8QlI+ICAgICAgICAgICAgIA0KICAgICAgICAgL3d3dy9odGRvY3MgPEJSPiBISVNURklMRVNJ WkUgPEJSPiAgICAgICAgICAgICAgICAgICAgICAxMDAwIDxCUj4gDQpIVFRQX1BPU1RfRklMRSA8 QlI+ICAgICAgICAgICAgICAgICAgICAgIC90bXAvd25fdG1wNjU1MzQvV05wb3N0LTM2YmIwYjZm LTQxNmQtMCANCjxCUj4gV05fRElSX1BBVEggPEJSPiAgICAgICAgICAgICAgICAgICAgICAvd3d3 L2h0ZG9jcy9tYWlsbWFuIDxCUj4gT1NUWVBFIDxCUj4gIA0KICAgICAgICAgICAgICAgICAgICBM aW51eCA8QlI+IFNFUlZFUl9QT1JUIDxCUj4gICAgICAgICAgICAgICAgICAgICAgMTE4MDEgPEJS PiANCkhUVFBfVVNFUl9BR0VOVCA8QlI+ICAgICAgICAgICAgICAgICAgICAgIE1vemlsbGEvNC41 IFtlbl0gKFdpbjk4OyBVKSA8QlI+IHZ0MTAwIA0KPEJSPiAgICAgICAgICAgICAgICAgICAgICAv YmluL2Jhc2ggPEJSPiBTSExWTCA8QlI+ICAgICAgICAgICAgICAgICAgICAgIDIgPEJSPiANClJF TU9URV9BRERSIDxCUj4gICAgICAgICAgICAgICAgICAgICAgMjA2LjQ3LjE1NS4xNTIgPEJSPiBT RVJWRVJfTkFNRSA8QlI+ICAgICAgIA0KICAgICAgICAgICAgICAgcG9zdGVsLnVuaWNvbnNlaWwu Y29tIDxCUj4gU0hFTEwgPEJSPiAgICAgICAgICAgICAgICAgICAgICANCi9iaW4vYmFzaCA8QlI+ IFRFUk0gPEJSPiAgICAgICAgICAgICAgICAgICAgICB2dDEwMCA8QlI+IEhUVFBfQUNDRVBUX0NI QVJTRVQgDQo8QlI+ICAgICAgICAgICAgICAgICAgICAgIGlzby04ODU5LTEsKix1dGYtOCA8QlI+ IENPTlRFTlRfTEVOR1RIIDxCUj4gICAgICAgICAgICANCiAgICAgICAgICAzNyA8QlI+IEhPTUUg PEJSPiAgICAgICAgICAgICAgICAgICAgICAvcm9vdCA8QlI+IFNFUlZFUl9QUk9UT0NPTCA8QlI+ IA0KICAgICAgICAgICAgICAgICAgICAgSFRUUC8xLjAgPEJSPiBQQVRIX0lORk8gPEJSPiAgICAg ICAgICAgICAgICAgICAgICANCi9kaXJlY3Rpb24gPEJSPiBMT0dOQU1FIDxCUj4gICAgICAgICAg ICAgICAgICAgICAgcm9vdCA8QlI+IFJFUVVFU1RfTUVUSE9EIDxCUj4gIA0KICAgICAgICAgICAg ICAgICAgICBQT1NUIDxCUj4gUEFUSF9UUkFOU0xBVEVEIDxCUj4gICAgICAgICAgICAgICAgICAg ICAgDQovd3d3L2h0ZG9jcy9kaXJlY3Rpb24gPEJSPiBTQ1JJUFRfTkFNRSA8QlI+ICAgICAgICAg ICAgICAgICAgICAgIA0KL21haWxtYW4vYWRtaW5kYiA8QlI+IFNFUlZFUl9TT0ZUV0FSRSA8QlI+ ICAgICAgICAgICAgICAgICAgICAgIFdOLzIuMS41IDxCUj4gDQpVU0VSIDxCUj4gICAgICAgICAg ICAgICAgICAgICAgcm9vdCA8QlI+IEhUVFBfUkVGRVJFUiA8QlI+ICAgICAgICAgICAgICAgICAg ICAgIA0KPEEgDQpocmVmPSJodHRwOi8vcG9zdGVsLnVuaWNvbnNlaWwuY29tOjExODAxLyI+aHR0 cDovL3Bvc3RlbC51bmljb25zZWlsLmNvbTo4MC88L0E+bWFpbG1hbi9hZG1pbmRiL2RpcmVjdGlv biANCjxCUj4gSElTVFNJWkUgPEJSPiAgICAgICAgICAgICAgICAgICAgICAxMDAwIDxCUj4gUkVN T1RFX1BPUlQgPEJSPiAgICAgICAgICAgICAgIA0KICAgICAgIDIwOTM8L0ZPTlQ+IDwvRk9OVD48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTMxMDE5MTcxNi0wNTAy MTk5OT48Rk9OVCBzaXplPTI+LS0tLS08L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MzEwMTkxNzE2LTA1MDIxOTk5PjxGT05UIHNpemU9Mj5C ZXN0IA0KUmVnYXJkcyE8L0ZPTlQ+PC9TUEFOPjwvRElWPjxCUj48QlI+PEJSPjxCUj4NCjxQPjxG T05UIHNpemU9Mj5TeWx2YWluIEJvbGR1YzxCUj5Tb2x1dGlvTkVUPEJSPlVuZSBmaWxpYWxlIGR1 IEdyb3VwZSBVbmljb25zZWlsIA0KaW5jLjxCUj4xODAxLCBNY0dpbGwgQ29sbGVnZSwgc3VpdGUg MTAxMDxCUj5Nb250cmVhbCAoUXVlYmVjKSBIM0EgDQoyTjQ8QlI+PEJSPlRlbDogKDUxNCkgODQw LTExNTggcG9zdGUgMzUxPEJSPkZheDogKDUxNCkgODQwLTExNjY8QlI+PEEgDQpocmVmPSJtYWls dG86c3lsdmFpbmJAdW5pY29uc2VpbC5jb20iPnN5bHZhaW5iQHVuaWNvbnNlaWwuY29tPC9BPjxC Uj48QSANCmhyZWY9Imh0dHA6Ly93d3cudW5pY29uc2VpbC5jb20iIHRhcmdldD1fYmxhbms+aHR0 cDovL3d3dy51bmljb25zZWlsLmNvbTwvQT4gDQo8L0ZPTlQ+PC9QPg0KPERJVj4mbmJzcDs8L0RJ Vj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_001E_01BE50F9.DC53A2A0-- From Harald.Meland@usit.uio.no Fri Feb 5 17:43:26 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 05 Feb 1999 18:43:26 +0100 Subject: [Mailman-Developers] member-sets composed of member-sets for other Mailman-lists Message-ID: Hi, I am more and more frequently getting reqests for mailing lists that reach the union of members of other mailing lists (all these mailing lists are Mailman controlled). The Mailman concept of umbrella lists doesn't quite cut it, as I find it a hack to solve a specific case -- i.e. it is not general enough. Besides, how can you (safely) set up an umbrella list to have any message inserted into some level of the hierarchy only generate _one_ request for moderator approval? Various heuristics based on looking at mail headers isn't reqally my idea of a "Good, Clean Solution" :) Thus, my request: Could Mailman accept some special syntax member address (being invalid in the SMTP sense) for including all members of another Mailman list (under the same Mailman installation) into this list? I.e., if the list "all-students" has this member list: some.supervisor@some-faculty.my.domain another.non.student@administration.my.domain [students-spring-1998] [students-fall-1998] , then the union of the regular addresses on the "all-students" list and the (recursively) expanded member list of the included lists ("students-spring-1998" and "students-fall-1998") is the real member list of the "all-students" list. Adding these "include other list" addresses should only be possible via the admin web interface (i.e. not possible via the regular "I want to subscribe" user web interface). The whole issue with where to send the password reminders and such would go away -- send out password reminders to members subscribed via lists that are configured to do so (and users wouldn't even have a separate password, let alone separate subscription options for lists they are indirectly subscribed to. I consider this coarse granularity a feature, YMMV). It would also be nice if there was some provision for regulating which administrators were allowed to include what other lists into their own lists -- e.g., a first approximation could be: If the intersection of the sets of administrators of the including and the included lists is the empty set, disallow inclusion. Such "privileges control" will, of course, be easier to implement as administrators get their own Mailman object (to be worked on after 1.0 is finally out the door). So, what do y'all think? -- Harald From rocon@pivot.net Fri Feb 5 14:41:03 1999 From: rocon@pivot.net (Robert OConnor) Date: Fri, 5 Feb 1999 09:41:03 -0500 Subject: [Mailman-Developers] Feature Request: unsubscribe from list mail Message-ID: <00da01be5116$072ef1c0$0201a8c0@hawkeye.bob.oc> I subscribe to a lot of lists and ***all too often*** see messages such as: unsubscribe or please unsubscribe me from this list. or how do I unsubscribe NEAT FEATURE REQUEST Before messages of this type are sent to the list of hundreds of others, How about a routine that scans ONLY the first line of the body looking for the word unsubscribe (Upper & Lower case) This message would NOT be posted but quoted back to the sender with the standard "Reply to this message to confirm your canceled subscription" I struggle my self when unsubscribing because I have misplaced, deleted or archived the first list "save this message" especially on long running lists. -bobo connor From jerrya@fastrans.net Sat Feb 6 17:12:53 1999 From: jerrya@fastrans.net (Jerry Adlersfluegel) Date: Sat, 6 Feb 1999 11:12:53 -0600 (CST) Subject: [Mailman-Developers] subscribers being ignored Message-ID: I sent this to -users and haven't heard back from anyone, so I'll try here. My setup: Linux 2.0.32 sendmail 8.9.2 (was 8.8.7 until this morning) mailman 1.0b8 I have a single list with 77 subscribers. I am hosting the list through a modem, and it is great. The improvements since b5 are such that delivery time has improved from over 4 minutes for a typical message to about 1:30. Everyone is happy with the list. Except for a couple people that don't receive any of the traffic. I added a couple subscribers over a week ago and they are not getting any of the messages. They did receive their subscription reminders. I have unsubscribed them and then re-added them (it is a closed list) and it didn't help. Their profiles are the same as anyone else, but they just don't get any of the mail. The only thing I can think of is that the ones that are shut out are all on AOL. There are 22 regular subscribers on AOL, and I noticed how the mail gets batched together. Is it possible that there is a limit to how many recipients my sendmail is seeing? In my case a single message gets sent for all the AOL recipients, of which there are only 19 on the recipient list. Is there a way I can control how this works? The only reason I can even think that is the problem is that the most recently added users are the ones that aren't getting the traffic. Thanks for any ideas. -- Jerry Adlersfluegel From klm@digicool.com Sat Feb 6 22:52:15 1999 From: klm@digicool.com (Ken Manheimer) Date: Sat, 6 Feb 1999 17:52:15 -0500 Subject: [Mailman-Developers] Feature Request: unsubscribe from list mail Message-ID: <199902062252.RAA03409@albert.digicool.com> Bobo connor wrote: > I subscribe to a lot of lists and > ***all too often*** > see messages such as: > > unsubscribe > or > please unsubscribe me from this list. > or > how do I unsubscribe > > NEAT FEATURE REQUEST > > Before messages of this type are sent > to the list of hundreds of others, How about > a routine that scans ONLY the > first line of the body looking for > the word unsubscribe (Upper & Lower case) > > This message would NOT be posted but quoted > back to the sender with the standard > "Reply to this message to confirm > your canceled subscription" > > I struggle my self when unsubscribing because > I have misplaced, deleted or archived the > first list "save this message" especially on long running > lists. Ironically, your message was held for administrator approval due to the "unsubscribe" in the subject and first few lines of the message - mailman has an administivia detector (that could perhaps use more tuning). I did approve it, and would have liked if the approval message offered me the option to note just this in the approval, but no such luck. (I would have commented about this, but my company's connection to the internet is currently suffering non-cooperation from the phone company, so i'm hardly connected.) The approach you suggest of soliciting confirmation for suspect administrivia messages sounds like one good way to improve the situation - are you thinking about implementing it? If anyone is, it'd be good to discuss it on the list first. My thought is that it would be good to generalize the confirmation mechanism mailman already has so it can be used by the administrator at their discretion, eg from the admindb approval page... Briefly, Ken klm@digicool.com From Harald.Meland@usit.uio.no Sun Feb 7 14:28:43 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 07 Feb 1999 15:28:43 +0100 Subject: [Mailman-Developers] subscribers being ignored In-Reply-To: Jerry Adlersfluegel's message of "Sat, 6 Feb 1999 11:12:53 -0600 (CST)" References: Message-ID: [Jerry Adlersfluegel] > I added a couple subscribers over a week ago and they are not getting any > of the messages. They did receive their subscription reminders. > > I have unsubscribed them and then re-added them (it is a closed list) and > it didn't help. Their profiles are the same as anyone else, but they just > don't get any of the mail. > > The only thing I can think of is that the ones that are shut out are all > on AOL. There are 22 regular subscribers on AOL, and I noticed how the > mail gets batched together. Is it possible that there is a limit to how > many recipients my sendmail is seeing? There is no such restriction that I know of in Mailman, but I believe you can configure Sendmail to put a ceiling on how many RCPT To:s you can have for one single message. I don't have my bat book here (nor am I very familiar with Sendmail configuration in general), so I don't know what specific config settings you should have a look at. As Mailman tries to batch addresses together by domain when it does deliveries, having a too restrictive Sendmail configuration could indeed be your problem. [ IIRC, the most recent draft of the upcoming RFC821-replacement says to allow _at least_ 100 RCPT To:s for any message -- so your apparent ceiling of 20 would be a bit low. ] If no one else fills me in on the sendmail config details, I'll try checking my bat book on Monday (or when I get the chance) and report any relevant findings. > The only reason I can even think that is the problem is that the most > recently added users are the ones that aren't getting the traffic. Hmmm... I don't think that Mailman keeps track of _when_ the various members of a list was added, or even the order in which this happens -- they are all kept in the same dict (or "hash", if you prefer), so there needn't be any relation between the time of subscribing and what addresses gets "denied" by your sendmail config. -- Harald From claw@kanga.nu Mon Feb 8 04:39:10 1999 From: claw@kanga.nu (J C Lawrence) Date: Sun, 07 Feb 1999 20:39:10 -0800 Subject: [Mailman-Developers] Moderation comment interface change In-Reply-To: Message from George Hartz of "Tue, 12 Jan 1999 16:53:46 GMT." <369B7E1A.B3A5F822@blowtorch.com> Message-ID: Suggested changes for MailMan 1.0b8: 1) Add email command to add a given subscriber address to the "Addresses of members accepted for posting to this list without implicit approval requirement..." and extend this feature to (optionally) send a message to the given subscriber denoting that they are now on the "posters" list. 2) Currently when when you reject a post to a moderated list you can also enter a one line explanation to be sent back to the original poster. Often I reject a post for multiple reasons, such as lines longer than 80 columns, missing attributions on quoted text, signature too long, etc. Any reason not to change the input fields from a single line to a multi-line text area? 3) Ability to explicitly turn off RFC 1153 digests (I want MIME only). 4) Ability to define a separate Reply-To address to be applied to digests only (in my case I point it to a null address -- I don't want users replying to digests). 5) MH-style archive folders, split out by archive period, instead of mbox'es (message separation semantics with mbox are not guaranteed). Comments? -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From Harald.Meland@usit.uio.no Mon Feb 8 11:54:14 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 08 Feb 1999 12:54:14 +0100 Subject: [Mailman-Developers] subscribers being ignored In-Reply-To: Harald Meland's message of "07 Feb 1999 15:28:43 +0100" References: Message-ID: [Harald Meland] > [Jerry Adlersfluegel] > > > Is it possible that there is a limit to how many recipients my > > sendmail is seeing? > > If no one else fills me in on the sendmail config details, I'll try > checking my bat book on Monday (or when I get the chance) and report > any relevant findings. Bat book checked and found outdated, so I checked Dejanews, and from hints found there I got this: From the sendmail-8.9.0 cf/README file: : +--------------------------------+ : | TWEAKING CONFIGURATION OPTIONS | : +--------------------------------+ : [...] : M4 Variable Name Configuration Description & [Default] : ================ ============= ======================= : confMAX_RCPTS_PER_MESSAGE MaxRecipientsPerMessage : [infinite] If set, allow no more than : the specified number of recipients in : an SMTP envelope. Further recipients : receive a 452 error code (i.e., they : are deferred for the next delivery : attempt). If you're running some sendmail version earlier than 8.9.0, I'd guess you could emulate this new option with some fancy stuff in e.g. the check_rcpt ruleset (but I'm not a sendmail guru, so don't take my word for it). Could you "grep MaxRecipientsPerMessage sendmail.cf" and let us know if my guess is anywhere near the solution to the problem, so that Mailman can include hints on checking this sendmail setting for other users with similar problems? -- Harald From Harald.Meland@usit.uio.no Mon Feb 8 12:08:05 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 08 Feb 1999 13:08:05 +0100 Subject: [Mailman-Developers] Moderation comment interface change In-Reply-To: J C Lawrence's message of "Sun, 07 Feb 1999 20:39:10 -0800" References: Message-ID: [J C Lawrence] > 5) MH-style archive folders, split out by archive period, instead of > mbox'es (message separation semantics with mbox are not guaranteed). While MH-style archive folders could be a nice feature, I don't think your comment on the message separation semantics of mbox folders is entirely correct. Sendmail (and compatible MTAs) actually _quote_ any lines beginning with "From " in the message body when delivering locally to avoid breaking the message separators. [ I've heard rumours that Postfix doesn't put any "From " quasi-header in pipe-delivered messages at all (while it does add "Delivered-To:" headers containing the envelope recipient (and use these headers to kill forwarding loops -- this may actually be a clue to the problems people have getting Mailman and Postfix working together)). If this indeed is the case, then there would (from Postfix' point of view) be no need to quote any "From " lines in the body of the message, either -- and this could break the message separation semantics of Mailman's mbox-style folders. Whether the proper fix is for Mailman to quote any "From " lines on it's own, or switch to using some other folder format, is at this time unclear to me. ] -- Harald From jerrya@fastrans.net Mon Feb 8 14:41:50 1999 From: jerrya@fastrans.net (Jerry Adlersfluegel) Date: Mon, 08 Feb 1999 08:41:50 -0600 Subject: [Mailman-Developers] subscribers being ignored References: Message-ID: <36BEF7AE.EA1B8631@fastrans.net> Harald Meland wrote: > If you're running some sendmail version earlier than 8.9.0, I'd guess > you could emulate this new option with some fancy stuff in e.g. the > check_rcpt ruleset (but I'm not a sendmail guru, so don't take my word > for it). I'm not one either, of course. I found the same thing you did. Since I was at 8.8.7 I decided to upgrade. I installed 8.9.2, and nothing changed. > > Could you "grep MaxRecipientsPerMessage sendmail.cf" and let us know > if my guess is anywhere near the solution to the problem, so that > Mailman can include hints on checking this sendmail setting for other > users with similar problems? Here's what is in my sendmail.cf. This means it is set to default, which is infinite, right? $ grep MaxRecipientsPerMessage /etc/sendmail.cf #O MaxRecipientsPerMessage=100 How can I see exactly who a message is being (or was) sent to by mailman? That could help me figure out where the problem may be. Thanks! From Harald.Meland@usit.uio.no Mon Feb 8 16:14:09 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 08 Feb 1999 17:14:09 +0100 Subject: [Mailman-Developers] subscribers being ignored In-Reply-To: Jerry Adlersfluegel's message of "Mon, 08 Feb 1999 08:41:50 -0600" References: <36BEF7AE.EA1B8631@fastrans.net> Message-ID: [Jerry Adlersfluegel] > How can I see exactly who a message is being (or was) sent to by > mailman? Sendmail should be logging this, I think. Have a look in your syslog. Barring that, I guess you could instrument Mailman like this: Open ~mailman/Mailman/Utils.py in your favorite editor. Look for this piece of code, in the TrySMTPDelivery() function: try: conn = smtplib.SMTP(mm_cfg.SMTPHOST) # Do the EHLO/HELO manually so we can check for DSN support Just under the "conn = ..." line, insert conn.set_debuglevel(1) to enable debugging. Save the file, and send a message to the problematic list. Debugging output (i.e. a transcript of the entire SMTP dialogue) should now be in ~mailman/logs/error. Remember to remove the debugging line again afterwards. -- Harald From claw@under.engr.sgi.com Mon Feb 8 18:55:55 1999 From: claw@under.engr.sgi.com (J C Lawrence) Date: Mon, 08 Feb 1999 10:55:55 -0800 Subject: [Mailman-Developers] Moderation comment interface change In-Reply-To: Message from Harald Meland of "08 Feb 1999 13:08:05 +0100." Message-ID: <199902081855.KAA75863@under.engr.sgi.com> On 08 Feb 1999 13:08:05 +0100 Harald Meland wrote: > [J C Lawrence] >> 5) MH-style archive folders, split out by archive period, instead >> of mbox'es (message separation semantics with mbox are not >> guaranteed). > While MH-style archive folders could be a nice feature, I don't > think your comment on the message separation semantics of mbox > folders is entirely correct. A brief perusal of the MHonArc list's archives and the regular problems members have with message separators with MHonArc seems to suggest otherwise. The lack of an absolute standard (eg BNF diagram in a recognised RFC) for mbox format really doesn't help. <> -- J C Lawrence Internet: claw@kanga.nu (Contractor) Internet: coder@kanga.nu ---------(*) Internet: claw@under.engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From petrilli@amber.org Mon Feb 8 19:17:08 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Mon, 8 Feb 1999 14:17:08 -0500 Subject: [Mailman-Developers] Moderation comment interface change In-Reply-To: <199902081855.KAA75863@under.engr.sgi.com>; from J C Lawrence on Mon, Feb 08, 1999 at 10:55:55AM -0800 References: <199902081855.KAA75863@under.engr.sgi.com> Message-ID: <19990208141708.04980@amber.org> On Mon, Feb 08, 1999 at 10:55:55AM -0800, J C Lawrence wrote: > > A brief perusal of the MHonArc list's archives and the regular > problems members have with message separators with MHonArc seems to > suggest otherwise. The lack of an absolute standard (eg BNF diagram > in a recognised RFC) for mbox format really doesn't help. Well, the other option is PMDF style (4 0x001 characters at the beginning of the line). THe big problem with using MH-style is that it can become a HUGE HUGE HUGE disk hog... what I have looked into is shoving the whole thing into MySQL :-) One table per list, which would let you do some really nice queries against it... this would let you move to a more dynamic page generation, rather than a static one, which would allow users to customize their page generation. Perhaps we need to start a list-archiver project seperate from mailman? Chris -- | Christopher Petrilli | petrilli@amber.org From claw@under.engr.sgi.com Mon Feb 8 19:24:18 1999 From: claw@under.engr.sgi.com (J C Lawrence) Date: Mon, 08 Feb 1999 11:24:18 -0800 Subject: [Mailman-Developers] Moderation comment interface change In-Reply-To: Message from "Christopher G. Petrilli" of "Mon, 08 Feb 1999 14:17:08 EST." <19990208141708.04980@amber.org> Message-ID: <199902081924.LAA75671@under.engr.sgi.com> On Mon, 8 Feb 1999 14:17:08 -0500 Christopher G Petrilli wrote: > On Mon, Feb 08, 1999 at 10:55:55AM -0800, J C Lawrence wrote: >> A brief perusal of the MHonArc list's archives and the regular >> problems members have with message separators with MHonArc seems >> to suggest otherwise. The lack of an absolute standard (eg BNF >> diagram in a recognised RFC) for mbox format really doesn't help. > Well, the other option is PMDF style (4 0x001 characters at the > beginning of the line). True, tho its been quite a while since I've run into that one. > THe big problem with using MH-style is that it can become a HUGE > HUGE HUGE disk hog... I have a little over a million and a half messages in MH folders right now, and yes, they chew disk space. Disk however is cheap. > what I have looked into is shoving the whole thing into MySQL :-) Not a bad idea, especially if batched with a set of export tools to spit mbox/MH/etc for legacy interfaces. > One table per list, which would let you do some really nice > queries against it... this would let you move to a more dynamic > page generation, rather than a static one, which would allow users > to customize their page generation. Problems are two fold: Need a MHonArc analogue that will run against MySQL. Need a decent search tool (I use WebGlimpse, but HT://Dig isn't too bad) that will run against the results. > Perhaps we need to start a list-archiver project seperate from > mailman? I'd say so. -- J C Lawrence Internet: claw@kanga.nu (Contractor) Internet: coder@kanga.nu ---------(*) Internet: claw@under.engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From petrilli@amber.org Mon Feb 8 19:41:55 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Mon, 8 Feb 1999 14:41:55 -0500 Subject: [Mailman-Developers] Moderation comment interface change In-Reply-To: <199902081924.LAA75671@under.engr.sgi.com>; from J C Lawrence on Mon, Feb 08, 1999 at 11:24:18AM -0800 References: <199902081924.LAA75671@under.engr.sgi.com> Message-ID: <19990208144155.44235@amber.org> On Mon, Feb 08, 1999 at 11:24:18AM -0800, J C Lawrence wrote: > > > Well, the other option is PMDF style (4 0x001 characters at the > > beginning of the line). > > True, tho its been quite a while since I've run into that one. Oh you'd be amazed how often I run into it... MMDF/PMDF live :-) Perhaps we want to use BABYL? :-) Actually, it's not a bad format, probably better than all the others, and well "documented" in elisp. > > THe big problem with using MH-style is that it can become a HUGE > > HUGE HUGE disk hog... > > I have a little over a million and a half messages in MH folders > right now, and yes, they chew disk space. Disk however is cheap. Cheap yes, but still, I don't know that I want to waste it like this unless there's no other solution. > > what I have looked into is shoving the whole thing into MySQL :-) > > Not a bad idea, especially if batched with a set of export tools to > spit mbox/MH/etc for legacy interfaces. Oh definately, I'm trying to cobble up something right now that can take mbox format and shove them in with some intellegence... hope to post it later today. > > One table per list, which would let you do some really nice > > queries against it... this would let you move to a more dynamic > > page generation, rather than a static one, which would allow users > > to customize their page generation. > > Problems are two fold: > > Need a MHonArc analogue that will run against MySQL. You mean a user interface? :-) Of course... > Need a decent search tool (I use WebGlimpse, but HT://Dig isn't > too bad) that will run against the results. THis is the second problem... I've been thinking about it... I don't know of any text-indexer (ie inverted indeces) that is designed to be programatically driven, rather than stand-alone... I want something that can do all it's indexing, but be driven from the unified interface, not from some secondary interface... know what I mean? > > Perhaps we need to start a list-archiver project seperate from > > mailman? > > I'd say so. > Barry? EtAl? Chris -- | Christopher Petrilli | petrilli@amber.org From jerrya@fastrans.net Mon Feb 8 21:12:25 1999 From: jerrya@fastrans.net (Jerry Adlersfluegel) Date: Mon, 08 Feb 1999 15:12:25 -0600 Subject: [Mailman-Developers] subscribers being ignored References: <36BEF7AE.EA1B8631@fastrans.net> Message-ID: <36BF5339.F892EEE5@fastrans.net> Harald Meland wrote: > > [Jerry Adlersfluegel] > > > How can I see exactly who a message is being (or was) sent to by > > mailman? > > Sendmail should be logging this, I think. Have a look in your syslog. I didn't see anything like that there. > > Barring that, I guess you could instrument Mailman like this: > > Open ~mailman/Mailman/Utils.py in your favorite editor. Look for this > piece of code, in the TrySMTPDelivery() function: > > try: > conn = smtplib.SMTP(mm_cfg.SMTPHOST) > # Do the EHLO/HELO manually so we can check for DSN support > > Just under the "conn = ..." line, insert > > conn.set_debuglevel(1) > > to enable debugging. Save the file, and send a message to the > problematic list. Debugging output (i.e. a transcript of the entire > SMTP dialogue) should now be in ~mailman/logs/error. Remember to > remove the debugging line again afterwards. Ok, I put that in there, and debugging shows up in other places, but not in that error log. Anyway, I had changed one of the user's settings to digest, so he would at least get the list messages. Then when I was going to do the above test, I changed him back to regular to see what happened, when he showed up in the recipient list. I did the same for another user that was being ignored, (change to digest and back to regular) and now he is getting mail too. I don't know what was going on there, but it appeared to be reproducible. Earlier, I had removed and re-added them to the list, but that did nothing. Thanks for the help, Harald. I don't think that was a solution, but I appreciate your efforts. Jerry A. From claw@under.engr.sgi.com Mon Feb 8 23:38:19 1999 From: claw@under.engr.sgi.com (J C Lawrence) Date: Mon, 08 Feb 1999 15:38:19 -0800 Subject: [Mailman-Developers] Moderation comment interface change In-Reply-To: Message from "Christopher G. Petrilli" of "Mon, 08 Feb 1999 14:41:55 EST." <19990208144155.44235@amber.org> Message-ID: <199902082338.PAA77950@under.engr.sgi.com> On Mon, 8 Feb 1999 14:41:55 -0500 Christopher G Petrilli wrote: > On Mon, Feb 08, 1999 at 11:24:18AM -0800, J C Lawrence wrote: >>> Well, the other option is PMDF style (4 0x001 characters at the >>> beginning of the line). >> >> True, tho its been quite a while since I've run into that one. > Oh you'd be amazed how often I run into it... MMDF/PMDF live :-) I'll make no comment on elisp based MUA's. > Actually, it's not a bad format, probably better than all the > others, and well "documented" in elisp. True, and that'a a major strength. >>> THe big problem with using MH-style is that it can become a >>> HUGE HUGE HUGE disk hog... >> >> I have a little over a million and a half messages in MH folders >> right now, and yes, they chew disk space. Disk however is cheap. > Cheap yes, but still, I don't know that I want to waste it like > this unless there's no other solution. This is why you have options, such as the _option_ to save MH folders. >> Need a MHonArc analogue that will run against MySQL. > You mean a user interface? :-) Of course... There are multiple possible definitions of UI in that sentence. I see two main approaches: A patch to MHonArc to read from MySQL A MHonArc analogue that will dynamically generate pages at request time from a MySQL database. The first is the easiest and has all the prior art behind it. The second is the nominally "better" approach but is a significant engineering efffort. >> Need a decent search tool (I use WebGlimpse, but HT://Dig isn't >> too bad) that will run against the results. > THis is the second problem... I've been thinking about it... I > don't know of any text-indexer (ie inverted indeces) that is > designed to be programatically driven, rather than > stand-alone... Agreed. > I want something that can do all it's indexing, but be driven from > the unified interface, not from some secondary interface... know > what I mean? Yup. Need something that will index the DB contents and derive appropriate URLs for the data found, rather than running thru the presentation_interface/web server to access the data and bind them to URLs. Its a genericy vs effort issue. Good search tools are not trivial. -- J C Lawrence Internet: claw@kanga.nu (Contractor) Internet: coder@kanga.nu ---------(*) Internet: claw@under.engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From petrilli@amber.org Tue Feb 9 00:49:09 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Mon, 8 Feb 1999 19:49:09 -0500 Subject: [Mailman-Developers] Moderation comment interface change In-Reply-To: <199902082338.PAA77950@under.engr.sgi.com>; from J C Lawrence on Mon, Feb 08, 1999 at 03:38:19PM -0800 References: <199902082338.PAA77950@under.engr.sgi.com> Message-ID: <19990208194909.04359@amber.org> On Mon, Feb 08, 1999 at 03:38:19PM -0800, J C Lawrence wrote: > On Mon, 8 Feb 1999 14:41:55 -0500 > Christopher G Petrilli wrote: > > > [I make a comment about BABYL] > > Actually, it's not a bad format, probably better than all the > > others, and well "documented" in elisp. > > True, and that'a a major strength. Yup, and I've never had a problem with it not finding the message start/end correctly. I suspect it's about as bulletproof as any non-database/singel-file solution can be! > >> I have a little over a million and a half messages in MH folders > >> right now, and yes, they chew disk space. Disk however is cheap. > > > Cheap yes, but still, I don't know that I want to waste it like > > this unless there's no other solution. > > This is why you have options, such as the _option_ to save MH > folders. Ok, this I can see... that would be helpful, and shouldn't be that hard to arrange, honestly... we've talked several times about having an "archive filter" that does something in a black box, but it's important to the main mailing list manager. > >> Need a MHonArc analogue that will run against MySQL. > > > You mean a user interface? :-) Of course... > > There are multiple possible definitions of UI in that sentence. > I see two main approaches: > > A patch to MHonArc to read from MySQL Ick, but that's just me... I have allergic reactions to all things related to Perl.. but that's just me. I just took a look at MHonArc, and it's not bad, honestly... thoguh the interface needs a lot of work. > A MHonArc analogue that will dynamically generate pages at request > time from a MySQL database. This is more what I have in mind... I have the following goals, personally, when I'm thining through this. * NO static HTML pages, everything is dynamically generated (Zpublisher?) * Full-text query of messages * Intellegent MIME handling (MHonArc gets this almost right) * Moderator "commenting" of messages (more on this later) * Intellegent queries based on header information > The first is the easiest and has all the prior art behind it. The > second is the nominally "better" approach but is a significant > engineering efffort. Well, I'm not sure how much it is.. .the full-text is the hard part, but that's mostly because of the problem I outlined below... I do know Digital Creations has an inverted text indexer, just not sure of the license status of it... supposedly it's BLINDINGLY fast... They said some comment about 1M record databse being searched in under 1 second. > > I want something that can do all it's indexing, but be driven from > > the unified interface, not from some secondary interface... know > > what I mean? > > Yup. Need something that will index the DB contents and derive > appropriate URLs for the data found, rather than running thru the > presentation_interface/web server to access the data and bind them > to URLs. THere's the rub... one of the problems i've had doing threading of archives has been the fact that a few mail systems don't insert Message-Id: correctly or consistently. BAH! EVIL BASTARDS! :-) This is what I would use to indentify things in the database (the primary key). > Its a genericy vs effort issue. Good search tools are not trivial. No, though they seem to be reinvented constantly :-) Hehehe... I wonder how good the API to WAIS is. Chris -- | Christopher Petrilli | petrilli@amber.org From claw@under.engr.sgi.com Tue Feb 9 01:28:35 1999 From: claw@under.engr.sgi.com (J C Lawrence) Date: Mon, 08 Feb 1999 17:28:35 -0800 Subject: [Mailman-Developers] Moderation comment interface change In-Reply-To: Message from "Christopher G. Petrilli" of "Mon, 08 Feb 1999 19:49:09 EST." <19990208194909.04359@amber.org> Message-ID: <199902090128.RAA78140@under.engr.sgi.com> On Mon, 8 Feb 1999 19:49:09 -0500 Christopher G Petrilli wrote: > On Mon, Feb 08, 1999 at 03:38:19PM -0800, J C Lawrence wrote: >> On Mon, 8 Feb 1999 14:41:55 -0500 Christopher G >> Petrilli wrote: >>> Actually, it's not a bad format, probably better than all the >>> others, and well "documented" in elisp. >> >> True, and that'a a major strength. > > Yup, and I've never had a problem with it not finding the message > start/end correctly. I suspect it's about as bulletproof as any > non-database/singel-file solution can be! Quite. FWLIW FIDO used a not-dissimilar format. >> This is why you have options, such as the _option_ to save MH >> folders. > Ok, this I can see... that would be helpful, and shouldn't be that > hard to arrange, honestly... we've talked several times about > having an "archive filter" that does something in a black box, but > it's important to the main mailing list manager. Aye. I'm tempted to hack it in myself but I don't really have a feel for the flow of the base design of MailMan right now (and my Python skills are a little rusty). >>>> Need a MHonArc analogue that will run against MySQL. >>> >>> You mean a user interface? :-) Of course... >> >> I see two main approaches: >> >> A patch to MHonArc to read from MySQL > > Ick, but that's just me... I have allergic reactions to all things > related to Perl.. but that's just me. Ditto. > I just took a look at MHonArc, and it's not bad, > honestly... thoguh the interface needs a lot of work. It works and it works well. It delivers well proven and well known results for hundreds of thousands of messages a day. While I may quibble about the design and implementation of the product (it has great big hoary wary fugly bits), there's not a whole lot I can argue with the job it does (I use it here across a half dozen lists and a couple hundred thousand archives posts). >> A MHonArc analogue that will dynamically generate pages at >> request time from a MySQL database. > This is more what I have in mind... Its also a significant engineering effort with a _long_ test and burn in period behind it. This is human-sourced data with Microsoft seasoning: Expect to spend 90% of your time figuring out how to handle 3% of the weird exceptions. It is also of course the "One True Way". I just don't think its really worth the effort right now. > I have the following goals, personally, when I'm thining through > this. > * NO static HTML pages, everything is dynamically generated > (Zpublisher?) * Full-text query of messages * Intellegent MIME > handling (MHonArc gets this almost right) * Moderator "commenting" > of messages (more on this later) * Intellegent queries based on > header information I'm currently playing about with having MHonArc generate pages which contain a PHP3 blob referencing a DB entry which contains web-browser annotations and list-owner comments (cf PHP's own annotated manual). It looks like a workable idea that could actually be fairly useful. >> The first is the easiest and has all the prior art behind it. >> The second is the nominally "better" approach but is a >> significant engineering efffort. > Well, I'm not sure how much it is... MHonArc has taken a whole lot of time to get where it is today, and that's not for lack of effort or much due to bad design principles in the early efforts. Its mostly due to the fact that its a nasty nut to crack. >> Yup. Need something that will index the DB contents and derive >> appropriate URLs for the data found, rather than running thru the >> presentation_interface/web server to access the data and bind >> them to URLs. > THere's the rub... one of the problems i've had doing threading of > archives has been the fact that a few mail systems don't insert > Message-Id: correctly or consistently. BAH! EVIL BASTARDS! :-) Quite. I approve of MHonArc's approach: silently ignore duplicate and missing MessageID's. A slightly better approach would be to pseudo-generate MessageID's for messages which miss them (say a simple hash function of the message body), and then only ignore duplicate hashes, but its a very small gain for a very small impact problem. -- J C Lawrence Internet: claw@kanga.nu (Contractor) Internet: coder@kanga.nu ---------(*) Internet: claw@under.engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From petrilli@amber.org Tue Feb 9 01:43:13 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Mon, 8 Feb 1999 20:43:13 -0500 Subject: [Mailman-Developers] Moderation comment interface change In-Reply-To: <199902090128.RAA78140@under.engr.sgi.com>; from J C Lawrence on Mon, Feb 08, 1999 at 05:28:35PM -0800 References: <199902090128.RAA78140@under.engr.sgi.com> Message-ID: <19990208204313.05795@amber.org> On Mon, Feb 08, 1999 at 05:28:35PM -0800, J C Lawrence wrote: > > [discussion of BABYL] > > Yup, and I've never had a problem with it not finding the message > > start/end correctly. I suspect it's about as bulletproof as any > > non-database/singel-file solution can be! > > Quite. FWLIW FIDO used a not-dissimilar format. So this might be one format to talk to---I need to look at extending Python's built in libraries to support this format on top of the existing ones... though it does need more features, it'd at least have the basics. > > Ok, this I can see... that would be helpful, and shouldn't be that > > hard to arrange, honestly... we've talked several times about > > having an "archive filter" that does something in a black box, but > > it's important to the main mailing list manager. > > Aye. I'm tempted to hack it in myself but I don't really have a > feel for the flow of the base design of MailMan right now (and my > Python skills are a little rusty). I've got the Python stuff pretty well in hand, but it's the flow of Mailman that makes my brain hurt :-) I've not really tried to understand it yet, since I've been hacking up the parser for Zope for a while... and after looking at a parser for a couple weeks, the rest just looks too foofooie :-) > Its also a significant engineering effort with a _long_ test and > burn in period behind it. This is human-sourced data with Microsoft > seasoning: Expect to spend 90% of your time figuring out how to > handle 3% of the weird exceptions. Well, if you keep the features to a minimum it's easier :-) Part of the problem SOME software companies have with debugging is that they add new features during teh debug cycle, and add features nobody uses---so of course nobody breaks them, until they do something to totally unrelated :-) > I'm currently playing about with having MHonArc generate pages which > contain a PHP3 blob referencing a DB entry which contains > web-browser annotations and list-owner comments (cf PHP's own > annotated manual). It looks like a workable idea that could > actually be fairly useful. My fear of such solutions is that it becomes more and more complex to debug sshould it break... but that's just me, and only me. > Quite. I approve of MHonArc's approach: silently ignore duplicate > and missing MessageID's. A slightly better approach would be to > pseudo-generate MessageID's for messages which miss them (say a > simple hash function of the message body), and then only ignore > duplicate hashes, but its a very small gain for a very small impact > problem. This is a difficult issue, and I don't agree with "silently ignoring" anything... always note it in the archives... that's my problem with editable archives... then again I just got done dealing with evidentiary problems with security audit trails :-) Chris -- | Christopher Petrilli | petrilli@amber.org From bence@intercom.hu Tue Feb 9 10:52:37 1999 From: bence@intercom.hu (Hermann Benedek) Date: Tue, 9 Feb 1999 11:52:37 +0100 Subject: [Mailman-Developers] What happened? Message-ID: The list received a lot of messages like this: (sorry about the big header, but perhaps it contains some useful information) **************************************************************************** ***8 From Harald.Meland@usit.uio.no Tue Feb 9 12:43:33 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 09 Feb 1999 13:43:33 +0100 Subject: [Mailman-Developers] subscribers being ignored In-Reply-To: Jerry Adlersfluegel's message of "Mon, 08 Feb 1999 15:12:25 -0600" References: <36BEF7AE.EA1B8631@fastrans.net> <36BF5339.F892EEE5@fastrans.net> Message-ID: [Jerry Adlersfluegel] > Harald Meland wrote: > > Just under the "conn = ..." line, insert > > > > conn.set_debuglevel(1) > > > > to enable debugging. Save the file, and send a message to the > > problematic list. Debugging output (i.e. a transcript of the entire > > SMTP dialogue) should now be in ~mailman/logs/error. Remember to > > remove the debugging line again afterwards. > > Ok, I put that in there, and debugging shows up in other places, but not > in that error log. OK, so I might have guessed wrong about the location of the resulting log file :) > Anyway, I had changed one of the user's settings to digest, so he would > at least get the list messages. Then when I was going to do the above > test, I changed him back to regular to see what happened, when he showed > up in the recipient list. I did the same for another user that was being > ignored, (change to digest and back to regular) and now he is getting > mail too. I don't know what was going on there, but it appeared to be > reproducible. Earlier, I had removed and re-added them to the list, but > that did nothing. Odd -- Internally, changing to digest only moves the address from the `members' dict to the `digest_members' dict, and reversing the change reverses the move. > Thanks for the help, Harald. I don't think that was a solution, but > I appreciate your efforts. If this really is unrelated to your MTA, then the output of the following commands might prove helpful in debugging (should you encounter the problem again): $ cd ~mailman $ python Python 1.5.1 (#1, Oct 9 1998, 15:23:54) [C] on sunos5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from Mailman import MailList >>> import pprint >>> list = MailList.MailList("PROBLEM_LIST_NAME", lock=0) >>> pprint.pprint(list.__dict__) Substitute the name of the problematic list name for PROBLEM_LIST_NAME. -- Harald From Harald.Meland@usit.uio.no Tue Feb 9 19:51:20 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 09 Feb 1999 20:51:20 +0100 Subject: [Mailman-Developers] What happened? In-Reply-To: Hermann Benedek's message of "Tue, 9 Feb 1999 11:52:37 +0100" References: Message-ID: [Hermann Benedek] > The list received a lot of messages like this: [...] > Received: from MAILQUEUE by UZEM_1 (Mercury 1.21); 9 Feb 99 10:20:35 GMT+1 > From: "Cseh Miklos" As I couldn't find any hints in the original message that should have spurred any DSN (Delivery Status Notification), are you sure it's not the guys sending the replies that are at fault? I have on occasion encountered mail setups/clients that send me "delivery status notification" _regardless_ of whether I want it or not (and I don't :). Sometimes this is something that users have turned on themselves, and sometimes it's turned on for all users by the local admin (presumably because "it sounded neat"). What suprises me, though, is that the notifications are sent to the _list_ address, which only appeared in the "To:" header of the original message. Granted, I would not at all be surprised if such broken setups _also_ didn't care whether or not Reply-To: was set (which it apparently doesn't)... but sending delivery notification to the To: address? That's a new one to me. BTW, I thought DSN was something that was propagated through optional flags to certain SMTP commands, and not in the message (body or headers) itself -- cf RFC1891. Thus Mailman would essentially strip any DSN requests from a message before delivering a copy of it to the list members (because the envelope of the Mailman-originating message is _completely_ new, and not influenced by the original envelope in any way). > What is this? I'm filtering the "RCPT:" e-mails now.... If I'm guessing right, you'll either have to do some pretty aggressive filtering, or convince those of your members who send "I have now read your mail" messages to *stop* doing so (or at least don't send them to the To: header address). If none of these "solutions" work, there is one final (and very tempting, if I may say so :) option: Simply unsubscribe the offending members until they learn to behave. Good luck, -- Harald From gstein@lyra.org Wed Feb 10 01:01:01 1999 From: gstein@lyra.org (Greg Stein) Date: Tue, 09 Feb 1999 17:01:01 -0800 Subject: [Mailman-Developers] [Fwd: Re: [Mailman-Users] Messages silently disappearing] Message-ID: <36C0DA4D.34B58873@lyra.org> Screwed up privs seems to happen a lot. Sure, maybe the person installed improperly. But if it is simply permissions, then it should be easily rectifiable. Wasn't there a script or something to check the permissions? I couldn't find it. Would be nice to have one. Regardless, I might recommend a web page or other document that has a detailed listing of owner/group/privs for the relevant directories and files. thx -g Wes Morriston wrote: > > I did as you suggested. All the directories in /home/mailman are now > owned by mailman and all have the g+s setting. I took the +s off of > /usr/bin/python. The result? Messages silently disappear as before. > Put the +s back on python, and they don't disappear. > > Something clearly has the wrong ownership and/or permissions, but I just > don't know what! > > Frustrated, > > Wes > > Christopher Lindsey wrote: > > > > > drwxrwsr-x 2 root mailman 512 Feb 9 17:37 data > > > > > > That is exactly how mailman installed itself. (I was root when I did > > > the install.) > > > > Yes, I had the same problem. > > > > > I then did a > > > > > > chown -R mailman . > > > > > > in /home/mailman. > > > > This will probably unset the g+s setting on all directories. You > > need to set it back: > > > > cd ~mailman > > chown -R mailman.mailman . > > find . -type d -exec chmod g+s {} \; > > > > > The following, I discovered, does cause the messages to be delivered. > > > > > > chmod +s /usr/bin/python > > > > > > I hope it is not too dangerous to run python as root. > > > > Ummm, I would undo that. > > > > Chris > > > > ------------------------------------------------------ > > Mailman-Users maillist - Mailman-Users@python.org > > http://www.python.org/mailman/listinfo/mailman-users > > ------------------------------------------------------ > Mailman-Users maillist - Mailman-Users@python.org > http://www.python.org/mailman/listinfo/mailman-users -- Greg Stein, http://www.lyra.org/ From dan@feld.cvut.cz Wed Feb 10 12:46:38 1999 From: dan@feld.cvut.cz (Dan Ohnesorg, admin of POWER) Date: Wed, 10 Feb 1999 13:46:38 +0100 Subject: [Mailman-Developers] What happened? In-Reply-To: References: Hermann Benedek's message of "Tue, 9 Feb 1999 11:52:37 +0100" Message-ID: <199902101247.NAA26988@poli.feld.cvut.cz> On 9 Feb 99, at 20:51, Harald Meland wrote: > > Received: from MAILQUEUE by UZEM_1 (Mercury 1.21); 9 Feb 99 10:20:35 > > GMT+1 From: "Cseh Miklos" Mercury requires errors-to: headers for returnig messages to postmaster. BTW 1.21 is quite old and buggy. Currently exists 1.44 > > What is this? I'm filtering the "RCPT:" e-mails now.... Best is to use my patch, which filters headers in messages on mailman listserv and removes requests for reading a confirmation. It solves problem with pmail and microsoft clietnts. I will send this patch later. It is better to remove this request from message then filter returned confirmations. 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 ________________________________________ Ne zihadla, ale med prinesl vcelam slavu. From gstein@lyra.org Wed Feb 10 13:08:11 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 10 Feb 1999 05:08:11 -0800 Subject: [Mailman-Developers] make update Message-ID: <36C184BA.3A683F1F@lyra.org> I updated a 1.0b6 install to 1.0b8. Seems to have worked fine (great job!). The upgrade script issued some "errors" though, which it really shouldn't have. Specifically, here is a snapshot: Updating mailing list: p2c-dev - updating old private mbox file looks like you have a really recent CVS installation... you're either one brave soul, or you already ran me - updating old public mbox file looks like you have a really recent CVS installation... you're either one brave soul, or you already ran me I never used a CVS snapshot. Looking at the code, I believe it doesn't recognize the fact that this came from 1.0b6 (i.e. recent versions) and just assumed it was a CVS version. Anyhow: it could throw somebody off if they weren't expecting it, so I'd recommend some kind of change -- alter the text, suppress it, etc. thx -g -- Greg Stein, http://www.lyra.org/ From Fred L. Drake, Jr." --b0glBXVDs2 Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit I don't know if this would be interesting to you guys... -Fred --b0glBXVDs2 Content-Type: message/rfc822 Content-Description: forwarded message Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart content-length: 2631 Return-Path: Received: from cnri.reston.va.us by weyr.cnri.reston.va.us (SMI-8.6/SMI-SVR4) id VAA29902; Tue, 9 Feb 1999 21:15:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by cnri.reston.va.us (8.9.1a/8.9.1) with ESMTP id VAA15676; Tue, 9 Feb 1999 21:15:08 -0500 (EST) Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id RAA00102 for ietf-123-outbound.10@ietf.org; Tue, 9 Feb 1999 17:15:01 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA00074 for ; Tue, 9 Feb 1999 17:12:49 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id OAA00684; Tue, 9 Feb 1999 14:12:49 -0800 (PST) Message-Id: <199902092212.OAA00684@boreas.isi.edu> From: RFC Editor To: IETF-Announce:;@ietf.org Cc: rfc-ed@ISI.EDU Subject: BCP 30, RFC 2505 on Anti-Spam Recommendations Date: Tue, 09 Feb 1999 14:12:49 -0800 --NextPart A new Request for Comments is now available in online RFC libraries. BCP 30: RFC 2505: Title: Anti-Spam Recommendations for SMTP MTAs Author(s): G. Lindberg Status: Best Current Practice Date: February 1999 Mailbox: lindberg@cdg.chalmers.se Pages: 24 Characters: 53597 Updates/Obsoletes/See Also: None I-D Tag: draft-lindberg-anti-spam-mta-08.txt URL: ftp://ftp.isi.edu/in-notes/rfc2505.txt This memo gives a number of implementation recommendations for SMTP, MTAs (Mail Transfer Agents, e.g. sendmail) to make them more capable of reducing the impact of spam. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <990209141051.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2505 --OtherAccess Content-Type: Message/External-body; name="rfc2505.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <990209141051.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- --b0glBXVDs2-- From liam@numenet.com Wed Feb 10 22:52:37 1999 From: liam@numenet.com (Liam Kirsher) Date: Wed, 10 Feb 1999 14:52:37 -0800 Subject: [Mailman-Developers] Possible bug in 1.0b8 Message-ID: <36C20DB4.9D6D4471@numenet.com> Hi, I don't know Python, so it's a little hard to tell what's going on. I think this is an undocumented feature, however. We changed the cgi name from mailman to newsletter, and so the url was incorrect. This caused the login process to fail because the url was incorrect. I found the problelm in Cgi/admindb.py, line 116 the reference to /mailman/admindb/ was a problem. I think the "mailman" part should be gotten from the DEFAULT_URL, perhaps? I just inserted what it needed to be ("newsletter"), but you might want to fix it for the future releases. Liam -- <-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-> Liam Kirsher VOICE: 415-456-6822 Numenet, Inc. FAX: 415-453-7876 775 E. Blithedale Ave. #176 EMAIL: liam@numenet.com Mill Valley, CA 94941 PGP: http://www.numenet.com/~liam/pgp_public_key.txt From Benjamin B. Thomas" Has anyone noticed that the last archived message to the mailman-checkins list (http://www.python.org/pipermail/mailman-checkins/) is from November? (BTW: The project looks really nice! I'm considering switching over from my current majordomo + (wilma/glimpse) + custom hacked news2mail<->mail2news gateway when I get through with some other other pressing projects.) Cheers, benjy 1975 Cahaba Valley Road (205) 988-5925 Indian Springs, AL 35124 benjy@alum.mit.edu From gstein@lyra.org Thu Feb 11 00:00:19 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 10 Feb 1999 16:00:19 -0800 Subject: [Mailman-Developers] [Fwd: Re: [Mailman-Users] NameError : recipients] Message-ID: <36C21D93.7245446@lyra.org> Greg Stein wrote: > > Scott A. McIntyre wrote: > > > > Thanks to Harald, I figured out my WANTED vs GOT and ended up letting > > mailman run with the GID it GOT and that seems to be much closer to > > being happy. However, now, whenever I post, I get the following in the > > error log: > > > > Feb 10 14:48:56 1999 post: Traceback (innermost last): > > post: File "/usr/people/mailman/scripts/post", line 65, in ? > > post: current_list.Post(msg) > > post: File "/usr/people/mailman/Mailman/MailList.py", line 1143, in > > Post > > post: recipients.remove(members) > > post: NameError : recipients > > This is a bug in Mailman 1.0b8. It has incorrect code for processing > "Don't Receive Own Posts". Turn that off, and it should work okay. I moved a block of lines in MailList.py down below the construction of the recipients list. It also appeared there was a bug in there that attempted to remove "members" rather than "sender". The final code looks like: # Try to get the address the list thinks this sender is sender = self.FindUser(msg.GetSender()) if sender: if self.GetUserOption(sender, mm_cfg.DontReceiveOwnPosts): dont_send_to_sender = 1 if self.GetUserOption(sender, mm_cfg.AcknowlegePosts): ack_post = 1 # Deliver the mail. members = self.GetDeliveryMembers() recipients = [] for m in members: if not self.GetUserOption(m, mm_cfg.DisableDelivery): recipients.append(m) if dont_send_to_sender: try: recipients.remove(sender) # # sender not in list (case sensitive username problem?) # except ValueError: self.LogMsg("error", "couldn't remove %s from recipient list: %s", sender, str(members)) self.LogMsg("post", "post to %s from %s size=%d", self._internal_name, msg.GetSender(), len(msg.body)) Cheers, -g -- Greg Stein, http://www.lyra.org/ From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Feb 11 15:47:48 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 11 Feb 1999 10:47:48 -0500 (EST) Subject: [Mailman-Developers] Stale mailman-checkins archive References: <199902102324.RAA19721@mail.indiansprings.org> Message-ID: <14018.64420.132327.818689@anthem.cnri.reston.va.us> >>>>> "BBT" == Benjamin B Thomas writes: BBT> Has anyone noticed that the last archived message to the BBT> mailman-checkins list BBT> (http://www.python.org/pipermail/mailman-checkins/) is from BBT> November? Yes, we deliberately turned off the archives to conserve disk space. All that information is available via CVS anyway. BBT> (BTW: The project looks really nice! I'm considering BBT> switching over from my current majordomo + (wilma/glimpse) + BBT> custom hacked news2mail<->mail2news gateway when I get BBT> through with some other other pressing projects.) Excellent! -Barry From lindsey@ncsa.uiuc.edu Fri Feb 12 04:08:05 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Thu, 11 Feb 1999 22:08:05 -0600 (CST) Subject: [Mailman-Developers] Problems with '+' addressing Message-ID: <199902120408.WAA24173@ferret.ncsa.uiuc.edu> I have several people subscribing to my lists with plus addressing (i.e. lindsey+mhonarc@ncsa.uiuc.edu (in fact, I'm subscribed to this list in the same way)). This breaks the "Restrict Posting to List Members" option for these accounts... What I'm trying to do is check for the existence of a '+' in each address in the list of subscribers, and if present, trim it and everything to the right off before checking for a match. Unfortunately, it appears that FindMatchingAddresses (called from MailList.FindUser) is just passed a dictionary of list members. Implementing the kind of check that I'd like would significantly slow down checking for matches because it couldn't just use the poster's address as a key anymore. So what's the best way to do this? Do a foreach on each key and check for a match? Like I said, it's slower, but it sure opens up a lot of possibilities. You could then do things like add regular expressions to the list of accepted posters... /.*\.example\.com/ would allow postings from anyone in a given domain (not something I would recommend), /george@example\.(org|com|net)/ would pull three lines together into one, etc. Not terribly useful, but what if you were to incorporate '+' addressing checks through regexes too then? Create a macro like :USER: and :DOMAIN: that would be used in the regex (colons are used since they can't be part of an address according to RFC 822)... Then you would have a regex like /:USER:\+[^@]*@:DOMAIN:/ :USER: and :DOMAIN: would be derived from the current poster, and each entry within the list of subscribers would be compared against the resulting regular expression (one at a time). I think that something like the '+' addressing check would be best served internally within Mailman (via a checkbox or whatever), but once the engine is in place it's a lot more extensible. Comments? I'm willing to mess with this (although I can't guarantee any great speed -- I just started messing with Python a couple of days ago). Chris From gstein@lyra.org Fri Feb 12 20:00:39 1999 From: gstein@lyra.org (Greg Stein) Date: Fri, 12 Feb 1999 12:00:39 -0800 Subject: [Mailman-Developers] change request: admin password changing Message-ID: <36C48867.3E677BDF@lyra.org> small change request: remove that dang password-change dialog from every screen I don't see a need to have it on *every* screen. It seems awfully redundant, and just ends up cluttering the other screens. -g -- Greg Stein, http://www.lyra.org/ From liam@numenet.com Tue Feb 16 23:54:48 1999 From: liam@numenet.com (Liam Kirsher) Date: Tue, 16 Feb 1999 15:54:48 -0800 Subject: [Mailman-Developers] Help with run_queue problem? Message-ID: <36CA0548.2BE4746@numenet.com> Hi, Can anyone help with this? I'm getting the following error when run_queue is executed, whether by cron or from the command line. Everything else seems to be working fine. Thanks in advance, Liam ------------------------------------------------------ Your "cron" job on ns1 /usr/local/bin/python /usr/local/etc/mailman/cron/run_queue produced the following output: Traceback (innermost last): File "/usr/local/etc/mailman/cron/run_queue", line 31, in ? OutgoingQueue.processQueue() File "/usr/local/etc/mailman/Mailman/OutgoingQueue.py", line 119, in processQu eue recip,sender,text = marshal.load(f) EOFError: EOF read where object expected -- <-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-> Liam Kirsher VOICE: 415-456-6822 Numenet, Inc. FAX: 415-453-7876 775 E. Blithedale Ave. #176 EMAIL: liam@numenet.com Mill Valley, CA 94941 PGP: http://www.numenet.com/~liam/pgp_public_key.txt From ayu1@nycap.rr.com Fri Feb 19 04:00:15 1999 From: ayu1@nycap.rr.com (Alex Yu) Date: Thu, 18 Feb 1999 23:00:15 -0500 Subject: [Mailman-Developers] Can anyone get MailMan running under Kernel w/ secure_linux patched? Message-ID: <36CCE1CF.12E53BD9@nycap.rr.com> Hello, I have problem w/ Mailman under Kernel 3.0.36 w/ secure_linux (ftp://ftp.false.com/pub/secure). I compiled the kernel with these options, Non-executable user stack area Restricted links in /tmp Restricted pipes in /tmp Restricted /proc So when I tried to update options on the web, I got error message as listed below. Can anyone fix? ---[START]------[START]---Bug in Mailman version 1.0b8 Traceback: Traceback (innermost last): File "/usr/local/mailman/scripts/driver", line 112, in run_main main() File "/usr/local/mailman/Mailman/Cgi/admin.py", line 170, in main ChangeOptions(lst, category, cgi_data, doc) File "/usr/local/mailman/Mailman/Cgi/admin.py", line 849, in ChangeOptions lst.Save() File "/usr/local/mailman/Mailman/MailList.py", line 683, in Save file = aside_new(fname, fname_last, reopen=1) File "/usr/local/mailman/Mailman/MailList.py", line 1211, in aside_new os.link(old_name, new_name) OSError: [Errno 1] Operation not permitted ---[end]--- -- best regards, alex.Yu From prew@prew2.matav.hu Fri Feb 19 14:10:50 1999 From: prew@prew2.matav.hu (Csanaki Csaba) Date: Fri, 19 Feb 1999 15:10:50 +0100 Subject: [Mailman-Developers] MailMan Bug :( Message-ID: <36CD70E9.38576EA9@mail.matav.hu> Bug in Mailman version 1.0b8 We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (innermost last): File "/home/mailman/scripts/driver", line 85, in run_main logger = StampedLogger('error', File "/home/mailman/Mailman/Logging/StampedLogger.py", line 48, in __init__ Logger.__init__(self, category, nofail, immediate) File "/home/mailman/Mailman/Logging/Logger.py", line 40, in __init__ self.__get_f() File "/home/mailman/Mailman/Logging/Logger.py", line 63, in __get_f reraise() File "/home/mailman/Mailman/Logging/Logger.py", line 55, in __get_f f = self.__fp = open(self.__filename, 'a+') IOError: (13, 'Permission denied') ---- I installed mailman, but this don't work :( Prew --------------------------------------------------- mailto:prew@prew2.matav.hu http://prew2.matav.hu ICQ:6384302 From stu@ekins.net Fri Feb 19 16:52:56 1999 From: stu@ekins.net (Stu Ekins) Date: Fri, 19 Feb 1999 16:52:56 -0000 Subject: [Mailman-Developers] MailMan Bug :( In-Reply-To: <36CD70E9.38576EA9@mail.matav.hu> Message-ID: <001301be5c28$4d2e9be0$6701a8c0@lisa98.ekins.net> > Bug in Mailman version 1.0b8 > > We're sorry, we hit a bug! ~ > IOError: (13, 'Permission denied') > > ---- > > I installed mailman, but this don't work :( > Well, I think the permission denied gives it away a little. Make sure you've got the permissions on all your /home/mailman (or wherever) files correct, according to the installation guide (don't rely on make install). Pay particular attention to the log directory. Stu. From vic@vgg.sci.uma.es Fri Feb 19 17:06:25 1999 From: vic@vgg.sci.uma.es (Victoriano Giralt) Date: Fri, 19 Feb 1999 18:06:25 +0100 (MET) Subject: [Mailman-Developers] MailMan Bug :( In-Reply-To: <36CD70E9.38576EA9@mail.matav.hu> Message-ID: On Fri, 19 Feb 1999, Csanaki Csaba wrote: > Bug in Mailman version 1.0b8 Not really ;) > > > File "/home/mailman/Mailman/Logging/Logger.py", line 55, in __get_f > f = self.__fp = open(self.__filename, 'a+') > IOError: (13, 'Permission denied') Check the ownership of the mailman files, they should have the same group as mailman does, and the directories should have the group setuid set (rws). The group is the same as the wrappers' -- Victoriano Giralt Systems Programmer Central Computing Facility University of Málaga SPAIN From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Feb 19 20:09:26 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 19 Feb 1999 15:09:26 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] Messages silently disappearing References: Message-ID: <14029.50422.195466.277100@anthem.cnri.reston.va.us> --H+5YPag/8T Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Thanks to Wes Morriston for giving me access to his Linux machine, I have diagnosed the problem he and Edward Marshall were having. I don't have a better solution than the one Wes came up with, so I'm posting this followup here to see if anybody has any ideas. The problem in a nutshell: on some Linux boxes, the effective group id is not preserved across a popen() call. Here's essentially the chain when a message is posted to a list: 1. The mail wrapper is invoked by the MDA. Mailman's wrapper is a setgid C program, that should change the egid to `mailman', then exec scripts/post. 2. scripts/post also has egid `mailman' and it goes about the business of checking that the message can be posted. Eventually, it is going to popen() scripts/deliver and start pumping it data. scripts/deliver in turn popens scripts/contact_transport, but it doesn't matter because by then the damage is done. Now, on both my Solaris 2.6 box and my RH5.1 box, scripts/deliver will inherit the egid of the invoking process, i.e. gid `mailman'. So by setting ~mailman/data to be g+w and group owned by mailman, everything's cool. However on Wes' SuSE machine, scripts/deliver runs with its egid reset to the real gid. This breaks mailman because the real gid isn't `mailman' and thus the process does not have permission to write into the ~mailman/data directory. Because the process is owned by daemon, Wes' solution of chown'ing ~mailman/data to daemon got this working again. I'm at a loss as to what the right solution is. Wes', while it works, doesn't seem ultimately right. But I have no idea how to force the egid of scripts/deliver to `mailman'. I don't believe you can have setgid scripts on Linux (I tried this, and no it did not work). Another solution would be to wrap scripts/deliver and probably scripts/contact_transport in C setgid wrappers, but that seems like a PITA. Is there some Linux option that we can exploit to allow this? Does anybody else have any better ideas? I am attaching a tarball of code that you can use to test whether your machine has the problem. To run this, compile wrapper.c, then chgrp it to some other group and chmod it to g+s. Also make sure wrapper-2.py is executable. Now run wrapper. If you see that wrapper, wrapper-1 and wrapper-2 all have the same egid, then you're okay. If wrapper-2 reverts to the real gid, then you'll get nailed by this. I'm guessing that because Stevens [APitUE] suggests that what we're doing may open up a security hole, some versions of Linux disallow this by reverting the egid on a popen(). -Barry --H+5YPag/8T Content-Type: application/octet-stream Content-Disposition: attachment; filename="linux.tgz" Content-Transfer-Encoding: base64 H4sIAEvEzTYAA+1WW2vbMBTOs36FllFsj8T3CyTrnjbGoGww2FPbB8dRYjFHMrKdS0v++45k J2nStJQRb9Dme7DkT0c6Rz76jpxRVi2tTquwbd+OogBa27XDULZOFNiy3aADfOh5vmv7HvCO GwRhJ2g3rBpVUcYCXI4WsSjixZN2TNBn11Hb8LebOnWYbSFT+V+IOM+JMJNWfNiODen1n8y/ H7lN/r3ICRyZf9+3wa6VaA7wxvP/nrIkq8YEfyzKMeVm+glRVuJZTJluoHuEAUkaiw84FtP5 9S2+xPfdfFWmnHV7uLs5OPkK3r7/urpaD9UUuQZ82LIqhkgRuQBqom8mDPDPr98+X+KLcQ9/ aXo3csUpKad0rBuqR1TXOFiCLElC2dQ0za5Re6s9QWhyaJ7ruwBl0I0RnWC9NjRwva+Hi/7g eQEBNLYSZElL3WmItXoKUlaCYXuI1gj978ydBnv677uQyNP7kPp/rv57obur/26g9K/GTx/K Y7x1/b/DVlUIa0SZRdgc18pBdJZzARJeFZsuLxBSYsHa9rQcU7GGL7DOC3Mn5Pql0TJapDQj 2BkoQcHpIyBbcGPK8sNMQeKxJHXjetB3bjfCZbxUtoOtOkdg+XtXFh4GpfWU7ZFoRyuivRLd ngr7938b6n/B/e9Fu/tfjTt+6Hpn/f8DvEjozt8IfZKDsoHKeU6YrlkpnxGr+cpWIRLr8dUD ytUWmpxqLgQtia6lJMv4DdvjJoLPDqhtoIrf/g6AQZLxAqoJgiJS04NjRQM2yDjr3xHB1b3f 2J6LxRlnnPGK8Qf44J9cABIAAA== --H+5YPag/8T-- From Harald.Meland@usit.uio.no Fri Feb 19 21:29:16 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 19 Feb 1999 22:29:16 +0100 Subject: [Mailman-Developers] Re: [Mailman-Users] Messages silently disappearing In-Reply-To: "Barry A. Warsaw"'s message of "Fri, 19 Feb 1999 15:09:26 -0500 (EST)" References: <14029.50422.195466.277100@anthem.cnri.reston.va.us> Message-ID: [Barry A. Warsaw] > Thanks to Wes Morriston for giving me access to his Linux machine, I > have diagnosed the problem he and Edward Marshall were having. I > don't have a better solution than the one Wes came up with, so I'm > posting this followup here to see if anybody has any ideas. > > The problem in a nutshell: on some Linux boxes, the effective group id > is not preserved across a popen() call. [...] > I'm at a loss as to what the right solution is. I can't really see that there is any viable[1] alternative to putting setregid(getegid(), -1); somewhere in common.c:run_script() [wrapped with appropriate autoconfisms, of course]. As long as there are systems not preserving the effective GID when they ought to (IMHO), we'll have to hope that using the real GID will work better. And, I don't think that setting the real GID to the effective GID will cause trouble on other systems. [1] Starting everything via setgid C wrappers isn't viable (to me). Forcing (possibly non-privileged) Mailman users to chgrp their directories to groups they very likely aren't members of isn't viable (for them). -- Harald From gorgo@caesar.elte.hu Fri Feb 19 22:11:33 1999 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Fri, 19 Feb 1999 23:11:33 +0100 (MET) Subject: [Mailman-Developers] Can anyone get MailMan running under Kernel w/ secure_linux patched? In-Reply-To: <36CCE1CF.12E53BD9@nycap.rr.com> Message-ID: On Thu, 18 Feb 1999, Alex Yu wrote: > Hello, > > I have problem w/ Mailman under Kernel 3.0.36 w/ secure_linux > (ftp://ftp.false.com/pub/secure). I compiled the kernel with these > options, > > Non-executable user stack area > Restricted links in /tmp > Restricted pipes in /tmp > Restricted /proc > > So when I tried to update options on the web, I got error message as > listed below. I dont know if this can be solved in mailman. I commented out the restricted hardlink part in the kernel (restricted links in /tmp does not only restrict links in /tmp, but hardlinks in non +t directories) -- 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 bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Feb 19 22:37:24 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 19 Feb 1999 17:37:24 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] Messages silently disappearing References: <14029.50422.195466.277100@anthem.cnri.reston.va.us> <14027.25437.930489.27167@anthem.cnri.reston.va.us> <36CB83E3.C7B5BD4F@stripe.colorado.edu> Message-ID: <14029.59300.63271.948377@anthem.cnri.reston.va.us> >>>>> "HM" == Harald Meland writes: HM> I can't really see that there is any viable[1] alternative to HM> putting HM> setregid(getegid(), -1); HM> somewhere in common.c:run_script() [wrapped with appropriate HM> autoconfisms, of course]. HM> As long as there are systems not preserving the effective GID HM> when they ought to (IMHO), we'll have to hope that using the HM> real GID will work better. And, I don't think that setting HM> the real GID to the effective GID will cause trouble on other HM> systems. Thanks Harald, this sounds reasonable. I'm not sure what to do if autoconf detects that the system is missing a setregid() though. Right now it just doesn't get called. I suppose I'll also document all this in the FAQ. I tested this on Wes' machine with my example code, and it looks at least like the popen() process is getting the necessary gid. I did not test it with a live Mailman setup. Folks (especially Wes and Edward, and anybody else who was noticing these problems), could you please wait for my next check-in and then grab the CVS snapshot. Reset the ownership on ~mailman/data and do a re-install to see if my changes fix your problems. If you can't access the CVS repository, let me know and I'll do a beta9 release. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Feb 19 23:10:42 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 19 Feb 1999 18:10:42 -0500 (EST) Subject: [Mailman-Developers] Can anyone get MailMan running under Kernel w/ secure_linux patched? References: <36CCE1CF.12E53BD9@nycap.rr.com> Message-ID: <14029.61298.414934.744@anthem.cnri.reston.va.us> >>>>> "GM" == Gergely Madarasz writes: GM> I dont know if this can be solved in mailman. I commented out GM> the restricted hardlink part in the kernel (restricted links GM> in /tmp does not only restrict links in /tmp, but hardlinks in GM> non +t directories) Thanks. I've added this, and the popen() problem to the new FAQ.LINUX file. See the CVS snapshot. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Feb 19 23:17:31 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 19 Feb 1999 18:17:31 -0500 (EST) Subject: [Mailman-Developers] MailMan Bug :( References: <36CD70E9.38576EA9@mail.matav.hu> Message-ID: <14029.61707.620834.663210@anthem.cnri.reston.va.us> >>>>> "CC" == Csanaki Csaba <prew@mail.matav.hu> writes: CC> Bug in Mailman version 1.0b8 Did you do a fresh install, or were you upgrading from some previous version? Did the permission checks that Stu and Victoriano suggested turn up antyhing? I ask because the configure script is supposed to ensure that ~mailman has the right permissions (including g+s on the directory). On a fresh install, that should guarantee the right permissions on all the subsequent files, as long as you also follow all the installation instructions. If this isn't working we need to write more sanity checks. -Barry From stu@ekins.net Sat Feb 20 11:01:32 1999 From: stu@ekins.net (Stu Ekins) Date: Sat, 20 Feb 1999 11:01:32 -0000 Subject: [Mailman-Developers] Test Results (was Messages silently disappearing) In-Reply-To: <14029.50422.195466.277100@anthem.cnri.reston.va.us> Message-ID: <000501be5cc0$60e5c620$6701a8c0@lisa98.ekins.net> OK, taking Barry's code, here's what I came up with: [stu@super linux]$ ls -al total 11 drwxrwxr-x 2 stu stu 1024 Feb 20 10:56 . drwxr-xr-x 13 stu stu 2048 Feb 20 10:52 .. -rwxrwsr-x 1 stu mailman 4553 Feb 20 10:55 wrapper -rwxrwxr-x 1 stu stu 242 Feb 19 20:05 wrapper-2.py -rw-rw-r-- 1 stu stu 314 Feb 19 19:41 wrapper.c -rwxrwxr-x 1 stu stu 265 Feb 20 10:55 wrapper.py [stu@super linux]$ ./wrapper wrapper: RGID= 500, EGID= 527 wrapper-1: RGID= 500, EGID= 527 wrapper-2: RGID= 500, EGID= 527 wrapper-2: hello wrapper-2: from wrapper-2: wrapper-1 wrapper-2: bye [stu@super linux]$ This is using a stable Linux 2.0.34 kernel on RedHat 5.0. Any help? From gorgo@caesar.elte.hu Sun Feb 21 00:04:38 1999 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Sun, 21 Feb 1999 01:04:38 +0100 (MET) Subject: [Mailman-Developers] mailman error Message-ID: Hello! What does this mean ? Feb 21 00:47:29 1999 mailcmd: Traceback (innermost last): mailcmd: File "/var/lib/mailman/scripts/mailcmd", line 52, in ? mailcmd: list.ParseMailCommands() mailcmd: File "/usr/lib/mailman/Mailman/MailCommandHandler.py", line 86, in ParseMailCommands mailcmd: sender = string.lower(mail.GetSender()) mailcmd: File "/usr/lib/mailman/Mailman/Message.py", line 122, in GetSender mailcmd: return string.lower(mail_address) mailcmd: TypeError : read-only buffer, None The mail command that triggered this message was a simple subscribe request... with a bad From: header, though From: Claudio Granatiero <@.> Btw wouldn't it be nice if these tracebacks printed out the values of the variables, too ? :) -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From jeffh@streek.com Sun Feb 21 04:02:26 1999 From: jeffh@streek.com (Jeff Hahn) Date: Sat, 20 Feb 1999 22:02:26 -0600 Subject: [Mailman-Developers] CVS Tree???? - What happened to the Cgi directory??? Message-ID: <002701be5d4e$fe50e820$1e0a5ad1@SINGSING.STREEK.COM> went to update my local copy No Cgi directory? Therefore empty cgi-bin directory after installation Any ideas? -Jeff From julian7@kva.hu Sun Feb 21 16:07:22 1999 From: julian7@kva.hu (Balazs Nagy) Date: Sun, 21 Feb 1999 17:07:22 +0100 (CET) Subject: [Mailman-Developers] (no subject) Message-ID: Hiyas, There any ideas about mail archive handling by email? I mean sending FAQ and other files automatically or the possibility of getting them. Regards: Balazs -- #!/usr/bin/perl -export-a-crypto-system-sig -http://dcs.ex.ac.uk/~aba/rsa print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0 [Christian tismer is having problems migrating a bunch of maillists to the new version, specifically because of the skew in customized (and even non-customized!) list web page templates. It brings up what i think is a substantial question about the template mechanism. I want to put the issue out there, see what the prevailing wisdom is. Details below...] -------- Original Message -------- Subject: Re: [Mailman-Users] Upgrade script for old databases? Date: Sun, 21 Feb 1999 10:19:46 -0500 From: Ken Manheimer Organization: Digital Creations, Inc. To: Christian Tismer CC: bwarsaw@python.org, klm@digicool.com Christian wrote: > Exactly. But extraction is not so much my problem, it is much more > how to move to all the new structures and layouts without getting > my customers involved. Ah - the customized-per-list listinfo template, for instance. I'm afraid you're right - the way that mailman provides for customization is not at all amenable to reconciling with new site templates. It's doubly bad because each list gets its own copy of the site templates when the list is created, so it gets locked in even when the list administrator doesn't tailor their templates from the site standard. Fixing this latter would not be hard, but it still wouldn't address the issue of tracking refinements in the site standard when the list has a divergent version. I imagine the solution there is to allow list managers only parameterized customization of their templates - something that dtml would make easier - but that, itself, is a tricky track. Sigh. > At least that, and if possible some more. I can write this myself, > and was just hoping that somebody had done so already. The HTML > is a different story... Sorry - i certainly haven't thought of a general solution, so i hadn't implemented anything... > My problem is that I have [a bunch of]u lists which are used by > my customers on starship.skyport.net, and I want to avoid > masses of conversation and support, when I try to move this to > mailman 1.0b7 or such. > The situation is even worse, since some changed the html > layouts a little, and the new layout is very different, also > the attribute names of the inserted variables have changed. > That's quite a lot of work, and if somebody had done so already, > I could use it as a starter and put more automation in, > but my time is so limited. > > I have a real migration problem here... > > Hmm. A mailinglist is a structure. Our (my) problem is that the > structure is no clean structure, but contains implementation > details. If there were another level of abstraction, like, say, > an XML DTD which defines what a Mailing list is, I could > do the move much easier. > > Sigh - I fear I have to do it by hand. Sorry - i agree that it's a problem. In fact, my inclination is to think that the freedom that list-customizable templates offers is not worth the migration issues that it presents. (I do know that some customizability is important - for instance, someone using mailman at cnri needed to simplify the listinfo page to basically just be a subscription page, without the archive and roster links, so offering parameters to turn off sections would probably be the right way to head. Something that worries me about this is that we've already established the current setup as the precedent, but i'm wondering whether it's worth rethinking. Christian, i'd like to bring the mailman cabal in on the issue - would it be ok if i forwarded this message to them? Ken From claw@kanga.nu Mon Feb 22 01:54:56 1999 From: claw@kanga.nu (J C Lawrence) Date: Sun, 21 Feb 1999 17:54:56 -0800 Subject: [Mailman-Developers] [Fwd: Re: [Mailman-Users] Upgrade script for old databases?] In-Reply-To: Message from Ken Manheimer of "Sun, 21 Feb 1999 13:25:39 EST." <36D04FA3.B89B8B4C@digicool.com> Message-ID: On Sun, 21 Feb 1999 13:25:39 -0500 Ken Manheimer wrote: > [Christian tismer is having problems migrating a bunch of maillists > to the new version, specifically because of the skew in customized > (and even non-customized!) list web page templates. It brings up > what i think is a substantial question about the template mechanism. > I want to put the issue out there, see what the prevailing wisdom > is. Details below...] I share his concerns, and am running into a few similar problems with clients I'm deploying MailMan at. Further, while the template structure is useful, the ability to define complex nodes for the templates is not wonderful. eg When the HTML for the list introductory description (that gets inserted into the listinfo page) is non-trivial, is is an absolute bitch to edit and correct in the provided form. Getting http://www.kanga.nu/lists/listinfo/mud-dev/ to look right took almost an hour. It still isn't quite right, but I've given up trying to fix the last niggles figuring its "good enough". Note: The only editing I did on the template was on the archives section as I don't use pipermail. All the rest is via the template expansion. -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From jeffh@streek.com Mon Feb 22 08:30:17 1999 From: jeffh@streek.com (Jeff Hahn) Date: Mon, 22 Feb 1999 02:30:17 -0600 (CST) Subject: [Mailman-Developers] CVS Tree???? - FIXED (I think) In-Reply-To: <002701be5d4e$fe50e820$1e0a5ad1@SINGSING.STREEK.COM> Message-ID: On Sat, 20 Feb 1999, Jeff Hahn wrote: > went to update my local copy > > No Cgi directory? > > Therefore empty cgi-bin directory after installation > Upon further examination, the wrapper programs failed to compile under RedHat Linux 5.2 The problem section in common.c is: #ifdef HAVE_SETREGID status = setregid(getegid(), -1); if (status) fatal(logident, "%s", strerror(errno)); #endif /* HAVE_SETREGID */ compile fails with logident undefined. "logident" is defined in both mail-wrapper.c and cgi-wrapper.c a statement "extern const char* logident;" added to common.h seemed to fix the problem. Could someone check this fix (I've just started playing with Mailman and have ZERO familiarity with the source), and if correct, check it into the CVS tree? Thanks, Jeff From Harald.Meland@usit.uio.no Mon Feb 22 17:45:46 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 22 Feb 1999 18:45:46 +0100 Subject: [Mailman-Developers] Possible bug in 1.0b8 In-Reply-To: Liam Kirsher's message of "Wed, 10 Feb 1999 14:52:37 -0800" References: <36C20DB4.9D6D4471@numenet.com> Message-ID: [Liam Kirsher] > I found the problelm in > > Cgi/admindb.py, line 116 > > the reference to /mailman/admindb/ was a problem. > I think the "mailman" part should be gotten from the DEFAULT_URL, > perhaps? I don't think that DEFAULT_URL has anything to do with this problem -- the fix is rather related to not depending on the not-really-standard (I think) REQUEST_URI environment variable. Please bear in mind that this is the first time I'm trying to do any CGI-related programming at all, but I still _think_ this patch is good (from reading the CGI/1.1 spec, and testing quickly that it doesn't break my web interface). Index: Mailman/Utils.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Utils.py,v retrieving revision 1.62 diff -u -r1.62 Utils.py --- Utils.py 1999/01/14 04:07:28 1.62 +++ Utils.py 1999/02/22 17:16:37 @@ -664,3 +664,20 @@ reraise(IOError, e) finally: os.umask(ou) + +def CGIpath(env): + """Return the full virtual path this CGI script was invoked with. + + Newer web servers seems to supply this info in the REQUEST_URI + environment variable -- which isn't part of the CGI/1.1 spec. + Thus, if REQUEST_URI isn't available, we concatenate SCRIPT_NAME + and PATH_INFO, both of which are part of CGI/1.1. If that fails, + too, fall back to a hardcoded common case. + + """ + if env.has_key("REQUEST_URI"): + return env["REQUEST_URI"] + elif env.has_key("SCRIPT_NAME") and env.has_key("PATH_INFO"): + return (env["SCRIPT_NAME"] + env["PATH_INFO"]) + else: + return ('/mailman/admin/' + list_name) Index: Mailman/Cgi/admin.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Cgi/admin.py,v retrieving revision 1.31 diff -u -r1.31 admin.py --- admin.py 1999/01/09 05:57:17 1.31 +++ admin.py 1999/02/22 17:16:38 @@ -123,8 +123,7 @@ text = Utils.maketext( 'admlogin.txt', {"listname": list_name, - "path" : os.environ.get("REQUEST_URI", - '/mailman/admin/' + list_name), + "path" : Utils.CGIpath(os.environ), "message" : message, }) print text Index: Mailman/Cgi/admindb.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Cgi/admindb.py,v retrieving revision 1.9 diff -u -r1.9 admindb.py --- admindb.py 1999/01/09 06:22:44 1.9 +++ admindb.py 1999/02/22 17:16:38 @@ -112,8 +112,7 @@ text = Utils.maketext( 'admlogin.txt', {'listname': list_name, - 'path' : os.environ.get('REQUEST_URI', - '/mailman/admindb/' + list_name), + 'path' : Utils.CGIpath(os.environ), 'message' : message, }) print text -- Harald From Harald.Meland@usit.uio.no Wed Feb 24 20:30:45 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 24 Feb 1999 21:30:45 +0100 Subject: [Mailman-Developers] Possible bug in 1.0b8 In-Reply-To: Harald Meland's message of "22 Feb 1999 18:45:46 +0100" References: <36C20DB4.9D6D4471@numenet.com> Message-ID: [Harald Meland] > Please bear in mind that this is the first time I'm trying to do any > CGI-related programming at all, but I still _think_ this patch is good > (from reading the CGI/1.1 spec, and testing quickly that it doesn't > break my web interface). I was slightly wrong about the patch being perfectly good -- the Utils.CGIpath() function would, if both of the "proper" methods for getting at the path failed, fall back to ("/mailman/admin/" + list_name), regardless of which CGI script called it. This would, obviously, be wrong if called from e.g. "admindb". It could also be argued that referencing the (hopefully defined) global variable list_name from CGIpath() is unnecessarily risky. Below is a patch (against current CVS) which fixes these problems by operating in a manner very similar to os.environ.get(), i.e. letting the caller supply the complete fallback value. [ I'm not really sure that putting a pretty special-purpose function like CGIpath() into the generic Utils module is the Right Thing -- but I couldn't see anywhere else where it would fit better. ] Index: Mailman/Utils.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Utils.py,v retrieving revision 1.62 diff -u -r1.62 Utils.py --- Utils.py 1999/01/14 04:07:28 1.62 +++ Utils.py 1999/02/24 20:26:00 @@ -664,3 +664,22 @@ reraise(IOError, e) finally: os.umask(ou) + +def CGIpath(env, fallback=None): + """Return the full virtual path this CGI script was invoked with. + + Newer web servers seems to supply this info in the REQUEST_URI + environment variable -- which isn't part of the CGI/1.1 spec. + Thus, if REQUEST_URI isn't available, we concatenate SCRIPT_NAME + and PATH_INFO, both of which are part of CGI/1.1. + + Optional second argument `fallback' (default `None') is returned if + both of the above methods fail. + + """ + if env.has_key("REQUEST_URI"): + return env["REQUEST_URI"] + elif env.has_key("SCRIPT_NAME") and env.has_key("PATH_INFO"): + return (env["SCRIPT_NAME"] + env["PATH_INFO"]) + else: + return fallback Index: Mailman/Cgi/admin.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Cgi/admin.py,v retrieving revision 1.31 diff -u -r1.31 admin.py --- admin.py 1999/01/09 05:57:17 1.31 +++ admin.py 1999/02/24 20:26:01 @@ -123,8 +123,8 @@ text = Utils.maketext( 'admlogin.txt', {"listname": list_name, - "path" : os.environ.get("REQUEST_URI", - '/mailman/admin/' + list_name), + "path" : Utils.CGIpath(os.environ, + '/mailman/admin/' + list_name), "message" : message, }) print text Index: Mailman/Cgi/admindb.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Cgi/admindb.py,v retrieving revision 1.9 diff -u -r1.9 admindb.py --- admindb.py 1999/01/09 06:22:44 1.9 +++ admindb.py 1999/02/24 20:26:01 @@ -112,8 +112,8 @@ text = Utils.maketext( 'admlogin.txt', {'listname': list_name, - 'path' : os.environ.get('REQUEST_URI', - '/mailman/admindb/' + list_name), + 'path' : Utils.CGIpath(os.environ, + '/mailman/admindb/' + list_name), 'message' : message, }) print text -- Harald From gstein@lyra.org Wed Feb 24 22:05:18 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 24 Feb 1999 14:05:18 -0800 Subject: [Mailman-Developers] [Fwd: Re: [Mailman-Users] Strange Problem.] Message-ID: <36D4779E.BC8785@lyra.org> Harald Meland wrote: > > [Michael Quigley] > > > ----- The following addresses had permanent fatal errors ----- > > "|/d0/mailman/mail/wrapper post webmaster" > > (expanded from: webmaster@goingv.com) > > > > ----- Transcript of session follows ----- > > 554 "|/d0/mailman/mail/wrapper post webmaster"... unknown mailer error 1 > > This indicates that the "wrapper" binary or something exec()d by it, > exit()ed with a status 1 (indicating that something failed). > > The first thing to suspect is that "wrapper" is being run under the > wrong gid. If that is the case, it tries logging this to syslog. The > fix is either to reconfigure mailman with the "--with-mail-gid" option > (and then rebuild and reinstall), or else configure your MTA to run > the pipe under the correct gid. This brings up an interesting idea: have the wrapper use different exit codes based on why it punted. That way, a simple examination of the maillog will tell you what happened. Cheers, -g -- Greg Stein, http://www.lyra.org/ From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Feb 27 17:53:50 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 27 Feb 1999 12:53:50 -0500 (EST) Subject: [Mailman-Developers] mailman error References: Message-ID: <14040.12590.97788.762445@anthem.cnri.reston.va.us> >>>>> "GM" == Gergely Madarasz writes: GM> Hello! GM> What does this mean ? GM> Feb 21 00:47:29 1999 mailcmd: Traceback (innermost last): GM> mailcmd: File "/var/lib/mailman/scripts/mailcmd", line 52, in GM> ? mailcmd: list.ParseMailCommands() mailcmd: File GM> "/usr/lib/mailman/Mailman/MailCommandHandler.py", line 86, in GM> ParseMailCommands mailcmd: sender = GM> string.lower(mail.GetSender()) mailcmd: File GM> "/usr/lib/mailman/Mailman/Message.py", line 122, in GetSender GM> mailcmd: return string.lower(mail_address) mailcmd: TypeError GM> : read-only buffer, None GM> The mail command that triggered this message was a simple GM> subscribe request... with a bad From: header, though From: GM> Claudio Granatiero <@.> Subscribing this type of address should no longer be allowed. GM> Btw wouldn't it be nice if these tracebacks printed out the GM> values of the variables, too ? :) Well... In general, Guido discourages printing variable values in tracebacks raised from builtin-functions, because all sorts of problems can occur (recursive loops, errors in reprs). What you see here is the next best thing: the *type* of the variable is printed. More often than not, a variable is None when you don't expect it to be, as in the case above. The type of None is so printing the type is usually all the information you need to figure out the problem! -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Feb 27 17:58:43 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 27 Feb 1999 12:58:43 -0500 (EST) Subject: [Mailman-Developers] [Fwd: Re: [Mailman-Users] Upgrade script for old databases?] References: <36D04FA3.B89B8B4C@digicool.com> Message-ID: <14040.12883.500649.8224@anthem.cnri.reston.va.us> >>>>> "JCL" == J C Lawrence writes: JCL> I share his concerns, and am running into a few similar JCL> problems with clients I'm deploying MailMan at. Further, JCL> while the template structure is useful, the ability to define JCL> complex nodes for the templates is not wonderful. JCL> eg When the HTML for the list introductory description JCL> (that gets inserted into the listinfo page) is non-trivial, JCL> is is an absolute bitch to edit and correct in the provided JCL> form. I agree completely. I think there's a lot we could improve here, although it'll naturally be after 1.0. This might include revision control, higher level selection of template parts (e.g. checkboxes to include certain sections), etc. I don't have any bright ideas though. I've taken to never removing anything from the HTML. I just comment stuff out all over the place. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Feb 27 19:28:29 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 27 Feb 1999 14:28:29 -0500 (EST) Subject: [Mailman-Developers] [Fwd: Re: [Mailman-Users] Strange Problem.] References: <36D4779E.BC8785@lyra.org> Message-ID: <14040.18269.508474.913998@anthem.cnri.reston.va.us> >>>>> "GS" == Greg Stein writes: GS> This brings up an interesting idea: have the wrapper use GS> different exit codes based on why it punted. That way, a GS> simple examination of the maillog will tell you what happened. Good suggestion Greg. #define GID_MISMATCH 2 #define SETREGID_FAILURE 3 #define EXECVE_FAILURE 4 #define MAIL_USAGE_ERROR 5 #define MAIL_ILLEGAL_COMMAND 6 -Barry From cklempay@chimera.acm.jhu.edu Sun Feb 28 07:42:02 1999 From: cklempay@chimera.acm.jhu.edu (Corbett J. Klempay) Date: Sun, 28 Feb 1999 02:42:02 -0500 (EST) Subject: [Mailman-Developers] msnbc mailman mention Message-ID: Hey, did you guys notice this MSNBC article mentioning Mailman? Big league! :) http://www.msnbc.com/news/244979.asp ------------------------------------------------------------------------------ Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Work like you don't need the money, love like it's never going to hurt, and dance like no one is watching..." ------------------------------------------------------------------------------ From ayu1@nycap.rr.com Sun Feb 28 08:07:05 1999 From: ayu1@nycap.rr.com (Alex Yu) Date: Sun, 28 Feb 1999 03:07:05 -0500 Subject: [Mailman-Developers] msnbc mailman mention In-Reply-To: Message-ID: <4.1.19990228030613.0094e9c0@pop1.rpi.edu> At 02:42 AM 1999/2/28 -0500, Corbett J. Klempay wrote: >Hey, did you guys notice this MSNBC article mentioning Mailman? Big >http://www.msnbc.com/news/244979.asp Guest what, even Microsoft coders are using Linux + Xwin + emacs + egcs compiler to do their work. It is true!!! Linux owns! Alex From Gergely Madarasz Tue Feb 2 10:52:58 1999 From: Gergely Madarasz (Gergely Madarasz) Date: Tue, 2 Feb 1999 11:52:58 +0100 (MET) Subject: [Mailman-Developers] Returned mail: unknown mailer error 1 (fwd) 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. --LAB01661.917951806/mlf.linux.rulez.org Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hello! Since I upgraded my linux kernel to 2.0.36 with the secure linux patch, I get the following error (the posts get delivered though). Any ideas how to fix this ? Greg ---------- Forwarded message ---------- Date: Tue, 2 Feb 1999 11:36:46 +0100 From: Mail Delivery Subsystem To: test-admin@mlf.linux.rulez.org Subject: Returned mail: unknown mailer error 1 The original message was received at Tue, 2 Feb 1999 11:36:39 +0100 from darmol.elte.hu [157.181.3.1] ----- The following addresses had permanent fatal errors ----- |"/var/lib/mailman/mail/wrapper post test" (expanded from: ) ----- Transcript of session follows ----- Traceback (innermost last): File "/var/lib/mailman/scripts/post", line 65, in ? current_list.Post(msg) File "/usr/lib/mailman/Mailman/MailList.py", line 1166, in Post self.Save() File "/usr/lib/mailman/Mailman/MailList.py", line 683, in Save file = aside_new(fname, fname_last, reopen=1) File "/usr/lib/mailman/Mailman/MailList.py", line 1211, in aside_new os.link(old_name, new_name) os.error: (1, 'Operation not permitted') 554 |"/var/lib/mailman/mail/wrapper post test"... unknown mailer error 1 --LAB01661.917951806/mlf.linux.rulez.org-- From gorgo@caesar.elte.hu Tue Feb 2 11:45:06 1999 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Tue, 2 Feb 1999 12:45:06 +0100 (MET) Subject: [Mailman-Developers] Returned mail: unknown mailer error 1 (fwd) In-Reply-To: Message-ID: On Tue, 2 Feb 1999, Gergely Madarasz wrote: > Hello! > > Since I upgraded my linux kernel to 2.0.36 with the secure linux patch, I > get the following error (the posts get delivered though). > Any ideas how to fix this ? Don't bother, I had to turn off the hardlink attack check, now it should work :/ -- 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 sheber@mwci.net Tue Feb 2 18:42:43 1999 From: sheber@mwci.net (Sean Heber) Date: Tue, 2 Feb 1999 12:42:43 -0600 Subject: [Mailman-Developers] Drool... Message-ID: <004301be4edb$d2281880$05172dc6@sean_heber.mcgraw-hill.com> Ok, I just got Mailman installed and working. That was easy. I just created a list. That was easy. I just managed a list. That was easy. I just have this sudden urge to send all of you developers LOTS AND LOTS of money!!! Mailman is INSANE! I am in love, I think. You guys (and gals?) totaly ROCK! If I had lots of money, you can be sure that I would have sent you all a truck load. rm -r majordomo THANKS SO MUCH!! You made my day! l8r Sean ---- Like games? http://www.legions.com/ From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Feb 2 18:55:50 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 2 Feb 1999 13:55:50 -0500 (EST) Subject: [Mailman-Developers] Drool... References: <004301be4edb$d2281880$05172dc6@sean_heber.mcgraw-hill.com> Message-ID: <14007.18998.750060.760331@anthem.cnri.reston.va.us> >>>>> "SH" == Sean Heber writes: SH> Ok, I just got Mailman installed and working. SH> That was easy. SH> I just created a list. SH> That was easy. SH> I just managed a list. SH> That was easy. Excellent! SH> I just have this sudden urge to send all of you developers SH> LOTS AND LOTS of money!!! SH> Mailman is INSANE! I am in love, I think. You guys (and SH> gals?) totaly ROCK! If I had lots of money, you can be sure SH> that I would have sent you all a truck load. Oh darn, you were just foolin'! And I was hoping you were serious so I could spend some, er, "real" time hacking on Mailman :-) SH> rm -r majordomo SH> THANKS SO MUCH!! You made my day! We've got a long TODO list, but I'm glad you like what you see so far. -Barry, who is way behind on Mailman email :-( From gstein@lyra.org Wed Feb 3 12:22:15 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 03 Feb 1999 04:22:15 -0800 Subject: [Mailman-Developers] password-less unsubscribe Message-ID: <36B83F77.4DABB7DD@lyra.org> Here is another request for a password-less unsubscribe... A friend is running a mailing list. It is generally composed of morons (not my friend, tho :-). Anyhow... these guys cannot for the life of them figure out how to unsubscribe. They do the email thing and it spits back about the password. Of course, these guys have no idea how to GET to their options page, hit the button, and have a password mailed to them. So they're stuck. I strongly vote for the "let them unsubscribe, and send a notice" theory. thx -g -- Greg Stein, http://www.lyra.org/ From tomas@euronetics.se Wed Feb 3 12:43:52 1999 From: tomas@euronetics.se (Tomas Fasth) Date: Wed, 03 Feb 1999 13:43:52 +0100 Subject: [Mailman-Developers] removing entries from aliases References: <014201be4d15$b6fdf060$0e45fea9@fred> Message-ID: <36B84488.3EBA911C@euronetics.se> Stu Ekins wrote: > I agree. Wouldn't it be a better idea to have a second aliases file that > only mailman can modify, then have an alternative version of newaliases that > concatenates the standard /etc/aliases and the mailman aliases together, > before processing. Most MTAs, including sendmail (exim is my personal favorite), can handle multiple alias files. As for sendmail you have to modify sendmail.cf like (version 8.8 and above): O AliasFile=/etc/aliases,/home/mailman/aliases The command newaliases, which updates the sendmail alias databases, automatically recognizes the new configuration with multiple alias files. I do use a separate mailman alias file myself, although with exim as MTA. The configuration looks like this (in /etc/exim.conf): mailman_aliases: driver = aliasfile domains = list.twinspot.net file = /home/mailman/aliases search_type = lsearch user = mailman group = mailman By the way, exim does not use newaliases for aliases updates. regards, Tomas From gstein@lyra.org Wed Feb 3 12:44:44 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 03 Feb 1999 04:44:44 -0800 Subject: [Mailman-Developers] bug in "mail me my password" Message-ID: <36B844BC.2B6FCED@lyra.org> When I went to a user's option page and hit their button, it barfed at me saying "not a member!" I believe it is related to upper-case values in the user's email address. This is with 1.0b6. -g -- Greg Stein, http://www.lyra.org/ From tomas@euronetics.se Wed Feb 3 12:48:23 1999 From: tomas@euronetics.se (Tomas Fasth) Date: Wed, 03 Feb 1999 13:48:23 +0100 Subject: [Mailman-Developers] password-less unsubscribe References: <36B83F77.4DABB7DD@lyra.org> Message-ID: <36B84597.19DA4158@euronetics.se> Greg Stein wrote: > I strongly vote for the "let them unsubscribe, and send a notice" > theory. Better yet, make it work like when subscribing, delay the execution, sending a mail to the adress in question with a key. If the key is not returned in a reply the subscription stay intact. Tomas From gstein@lyra.org Wed Feb 3 12:51:15 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 03 Feb 1999 04:51:15 -0800 Subject: [Mailman-Developers] password-less unsubscribe References: <36B83F77.4DABB7DD@lyra.org> <36B84597.19DA4158@euronetics.se> Message-ID: <36B84643.715B653F@lyra.org> Tomas Fasth wrote: > > Greg Stein wrote: > > > I strongly vote for the "let them unsubscribe, and send a notice" > > theory. > > Better yet, make it work like when subscribing, delay the execution, > sending a mail to the adress in question with a key. If the key is not > returned in a reply the subscription stay intact. That's a possibility, but for this list... remember: they're idiots. If they were accidentally/maliciously unsubscribed, then they can always resubscribe. Really... how often does somebody maliciously unsubscribe somebody? I have to imagine it is quite rare. I'd rather take the safe side and let them get off the list as easy as possible. I'd actually prefer a confirmation-less subscription, too, and have something in the subscribe acknowledgement say "if you were subscribed in error, then hit URL to unsubscribe" -g -- Greg Stein, http://www.lyra.org/ From tomas@euronetics.se Wed Feb 3 13:45:29 1999 From: tomas@euronetics.se (Tomas Fasth) Date: Wed, 03 Feb 1999 14:45:29 +0100 Subject: [Mailman-Developers] password-less unsubscribe References: <36B83F77.4DABB7DD@lyra.org> <36B84597.19DA4158@euronetics.se> <36B84643.715B653F@lyra.org> Message-ID: <36B852F9.A696C29@euronetics.se> Greg Stein wrote: > That's a possibility, but for this list... remember: they're idiots. I wonder how did they get on the list in the first place if they are such morons? Can this be a situation were users are added to a list against their will and then get angry because they can not get off the list fast enough? If so, tough luck, it's the list owner's own fault. The list owner should be responsible to remove the subscribers by his/her own hand. My personal opinion is that the design of Mailman as well as other list managing software should not promote unsolicited subscription/unsubscription. > If they were accidentally/maliciously unsubscribed, then they can always > resubscribe. That is what a list owner usually want to avoid. Unnecessary exposure to accidental/malicious subscription/unsubscription is not an option, in my humble opinion. It only adds to the level of irritation and work load. > Really... how often does somebody maliciously unsubscribe somebody? I > have to imagine it is quite rare. I'd rather take the safe side and let > them get off the list as easy as possible. Sure, it's rare because there are measures taken against it. The only "safe" side is to require subscribers to follow a procedure that oppress malicious behavior. > I'd actually prefer a confirmation-less subscription, too, and have > something in the subscribe acknowledgement say "if you were subscribed > in error, then hit URL to unsubscribe" I don't share your opinion. As a Mailman administrator, I'm glad the confirmation mechanism is there as a small but effective safety precaution. Besides, if the world is full of idiots like you describe, that kind of acknowledgement would not do much help. Tomas From roy@endeavor.med.nyu.edu Wed Feb 3 16:10:03 1999 From: roy@endeavor.med.nyu.edu (Roy Smith) Date: Wed, 03 Feb 1999 11:10:03 -0500 Subject: [Mailman-Developers] password-less unsubscribe In-Reply-To: <36B84597.19DA4158@euronetics.se> Message-ID: <122771.3127029003@mc-as01-p53.med.nyu.edu> The problem with this is that: 1) Somebody subscribes with address user@foo.com 2) They switch ISPs and become user@bar.com 3) They now want to unsubscribe user@foo.com and subscribe user@bar.com. If a confirmation request is mailed to user@foo.com, you loose because user@foo.com is probably no longer a valid address. --On Wed, Feb 3, 1999 1:48 PM +0100 Tomas Fasth wrote: > Better yet, make it work like when subscribing, delay the execution, > sending a mail to the adress in question with a key. If the key is not > returned in a reply the subscription stay intact. Roy Smith New York University School of Medicine 550 First Avenue, New York, NY 10016 From tomas@euronetics.se Wed Feb 3 16:51:41 1999 From: tomas@euronetics.se (Tomas Fasth) Date: Wed, 03 Feb 1999 17:51:41 +0100 Subject: [Mailman-Developers] password-less unsubscribe References: <122771.3127029003@mc-as01-p53.med.nyu.edu> Message-ID: <36B87E9D.E5BC748B@euronetics.se> Roy Smith wrote: > > The problem with this is that: > > 1) Somebody subscribes with address user@foo.com > > 2) They switch ISPs and become user@bar.com > > 3) They now want to unsubscribe user@foo.com and subscribe user@bar.com. > > If a confirmation request is mailed to user@foo.com, you loose because > user@foo.com is probably no longer a valid address. That scenario is a problem for the subscriber, no doubt about it. Since the email address essentially represents the identity of the subscriber, a change of email address and therefore identity is problematic if you at the same time in general want to maintain a certain level of integrity. Providing a personal password is one way to deal with this dilemma. Another is to contact the list owner and persuade her/him to make the change. But I do not recommend to completely remove from mailman the minimal requirement of proving your identity by email address or password. Tomas From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Feb 3 17:44:08 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 3 Feb 1999 12:44:08 -0500 (EST) Subject: [Mailman-Developers] Digesting bug Message-ID: <14008.35560.599266.639507@anthem.cnri.reston.va.us> I'm slammed for time, but I want to get this bug report into the loop (we really need Jitterbug or some such!). Anyway, if someone switches from digest mode to regular delivery, they need to receive at least one more digest, otherwise they will lose mail. Or they need to receive the digest up to the point of their delivery mode switch. This just happened me. I toggled on regular delivery of jpython-interest just before the digests were sent out today, so I lost all email since yesterday. :-( -Barry From petrilli@amber.org Wed Feb 3 17:59:32 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Wed, 3 Feb 1999 12:59:32 -0500 Subject: [Mailman-Developers] Digesting bug In-Reply-To: <14008.35560.599266.639507@anthem.cnri.reston.va.us>; from Barry A. Warsaw on Wed, Feb 03, 1999 at 12:44:08PM -0500 References: <14008.35560.599266.639507@anthem.cnri.reston.va.us> Message-ID: <19990203125932.50487@amber.org> On Wed, Feb 03, 1999 at 12:44:08PM -0500, Barry A. Warsaw wrote: > > Anyway, if someone switches from digest mode to regular delivery, they > need to receive at least one more digest, otherwise they will lose > mail. Or they need to receive the digest up to the point of their > delivery mode switch. > > This just happened me. I toggled on regular delivery of > jpython-interest just before the digests were sent out today, so I > lost all email since yesterday. :-( > I think the best way to handle this would be to just shove out a copy of the CURRENT digest when the user modifies their setting, no? No readon to wait until the digest goes out LATER, just run the digest-send w/1 recipient. Chris -- | Christopher Petrilli | petrilli@amber.org From bwarsaw@python.org Wed Feb 3 18:00:31 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Wed, 3 Feb 1999 13:00:31 -0500 (EST) Subject: [Mailman-Developers] Digesting bug References: <14008.35560.599266.639507@anthem.cnri.reston.va.us> <19990203125932.50487@amber.org> Message-ID: <14008.36543.695779.894540@anthem.cnri.reston.va.us> >>>>> "CGP" == Christopher G Petrilli writes: CGP> I think the best way to handle this would be to just shove CGP> out a copy of the CURRENT digest when the user modifies their CGP> setting, no? No readon to wait until the digest goes out CGP> LATER, just run the digest-send w/1 recipient. Agreed. From rocon@pivot.net Fri Feb 5 13:56:31 1999 From: rocon@pivot.net (Robert OConnor) Date: Fri, 5 Feb 1999 08:56:31 -0500 Subject: [Mailman-Developers] Unsubscribed WITHOUT my permission Message-ID: <00a301be510f$59a99d80$0201a8c0@hawkeye.bob.oc> Twice in February I have been unsubscribed from zope@zope.org mail list that is running: --- Mailman v 1.0b8. pre-GNU beta release I went and checked my options and found: http://www.zope.org/mailman/subscribe/zope *-- Disable mail delivery Turn this on if you want mail to not be delivered to you for a little while. On *-- Ok, _maybe_ my busy mail server bounces mail on occasion or maybe the mail got stuck somewhere in the icloud....I had assumed that bounce mail makes a few attempts before failure. My mail server at my ISP: pivot.net has continued to work fine although I understand that it is busy. I have no problems with this on other lists. The MailMan "to do" list shows these issues relevant to my problem: Bugs "Stale" addresses don't update properly when new bounces come in (stale means we had some bounces, but delivery to that address started working again before we booted them from the list) Bounce handling Add more patterns for bounce handling Send mail to people that are being removed w/o their knowledge (even though they're likely not to get it). ***Hey, I AM likely to get it*** I am writing as a USER, not a list maintainer. ***I strongly encourage you to send mail if you disable "my" settings automatically. Questions: How many times does MailMan mail "Bounce" before you disable it? A few tries should be made... Maybe the retries should be delayed and made at some interval such as 20 or 30 minutes. From rocon@pivot.net Fri Feb 5 14:06:34 1999 From: rocon@pivot.net (Robert OConnor) Date: Fri, 5 Feb 1999 09:06:34 -0500 Subject: [Mailman-Developers] Domain Mail forwarding problem Message-ID: <00ac01be5110$bfa76da0$0201a8c0@hawkeye.bob.oc> I first subscribed to zope@zope.org mail list that is running: --- Mailman v 1.0b8. pre-GNU beta release I attempted to subscribe using my domain and forwarding mail to my ISP email address Mail FromDomain: bob@rocnet.com Is forwarded to my ISP POP email: rocon@pivot.net This does not work with MailMan. Or perhaps only partially works. I cannot see "posts you send to the list? " even though this option is on. I understand from others that MailMan does not support this because it somehow prevents spammers from accessing the list. How about an OPTION that I specifically check that sez: "Allow forwarded Mail?: Yes/No and if necessary, a place to enter both email addresses. I use my domain in another way that helps me filter my mail. If I subscribe to the zope mail list, I subscribe as zope@rocnet.com (Zope being the list I subscribe to and rocnet my domain that forwards everything... Thank you. Keep up the good work. -bobo connor From sylvainb@uniconseil.com Fri Feb 5 16:22:48 1999 From: sylvainb@uniconseil.com (Sylvain Bolduc) Date: Fri, 5 Feb 1999 11:22:48 -0500 Subject: [Mailman-Developers] MailMan 1.0b7 Message-ID: <001d01be5123$c529aaa0$989b2fce@sly.uniconseil.com> This is a multi-part message in MIME format. ------=_NextPart_000_001E_01BE50F9.DC53A2A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkknbSBhIHN5c3RlbSBhZG1pbmlzdHJhdGlvbiBvZiB0aGUgVW5pY29uc2VpbCBN YWlsIFNlcnZlci4NCg0KUmVjZW50bHksIGkndmUgdHJpZWQgdG8gdXNlL2luc3RhbGwgTWFpbE1h biAxLjBiNyBvdmVyIExpbnV4IFJFREhBVCA1LjIuDQoNCkJ1dCBTaW5jZSB5ZXN0ZXJkYXksIGkn bSBnZXR0aW5nIGFsb3Qgb2YgdGhvc2VzIGVycm9ycy4NCkkgQ2FuJ3QgZmluZCBhIHdheSB0byBm aXggdGhlIHByb2JsZW0uDQoNCkRvIHlvdSB0aGluayBpIG5lZWQgdG8gdXBncmFkZSB0byAxLjBi OCA/DQoNCg0KLS0tLS0tLQ0KDQpXZSdyZSBzb3JyeSwgd2UgaGl0IGEgYnVnIQ0KDQpJZiB5b3Ug d291bGQgbGlrZSB0byBoZWxwIHVzIGlkZW50aWZ5IHRoZSBwcm9ibGVtLCBwbGVhc2UgZW1haWwg YSBjb3B5IG9mIHRoaXMgcGFnZSB0byB0aGUgd2VibWFzdGVyIGZvciB0aGlzIHNpdGUgd2l0aCBh IGRlc2NyaXB0aW9uIG9mIHdoYXQgaGFwcGVuZWQuDQpUaGFua3MhIA0KDQpUcmFjZWJhY2s6DQoN Cg0KVHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6DQogIEZpbGUgIi9ob21lL21haWxtYW4vc2Ny aXB0cy9kcml2ZXIiLCBsaW5lIDEwMiwgaW4gcnVuX21haW4NCiBtYWluKCkNCg0KICBGaWxlICIv aG9tZS9tYWlsbWFuL01haWxtYW4vQ2dpL2FkbWluZGIucHkiLCBsaW5lIDEyNCwgaW4gbWFpbg0K ICAgIEhhbmRsZVJlcXVlc3RzKGRvYykNCg0KICBGaWxlICIvaG9tZS9tYWlsbWFuL01haWxtYW4v Q2dpL2FkbWluZGIucHkiLCBsaW5lIDIxMSwgaW4gSGFuZGxlUmVxdWVzdHMNCiAgICBsaXN0Lkhh bmRsZVJlcXVlc3QocmVxdWVzdCwgdikNCg0KICBGaWxlICIvaG9tZS9tYWlsbWFuL01haWxtYW4v TGlzdEFkbWluLnB5IiwgbGluZSAxMjIsIGluIEhhbmRsZVJlcXVlc3QNCiAgICBzZWxmLkhhbmRs ZVBvc3RSZXF1ZXN0KHJlcXVlc3RfZGF0YVsyOl0sIHZhbHVlLCBjb21tZW50KQ0KDQogIEZpbGUg Ii9ob21lL21haWxtYW4vTWFpbG1hbi9MaXN0QWRtaW4ucHkiLCBsaW5lIDEzMSwgaW4gSGFuZGxl UG9zdFJlcXVlc3QNCiAgICBzZWxmLlBvc3QobXNnLCAxKQ0KDQogIEZpbGUgIi9ob21lL21haWxt YW4vTWFpbG1hbi9NYWlsTGlzdC5weSIsIGxpbmUgMTE1OCwgaW4gUG9zdA0KICAgIHNlbGYuRGVs aXZlclRvTGlzdChtc2csIHJlY2lwaWVudHMsDQoNCiAgRmlsZSAiL2hvbWUvbWFpbG1hbi9NYWls bWFuL0RlbGl2ZXJlci5weSIsIGxpbmUgMTcyLCBpbiBEZWxpdmVyVG9MaXN0DQogICAgc3RhdHVz ID0gY21kcHJvYy5jbG9zZSgpDQpJT0Vycm9yOiAoMTAsICdObyBjaGlsZCBwcm9jZXNzZXMnKQ0K DQoNCg0KDQoNCkVudmlyb25tZW50IHZhcmlhYmxlczoNCg0KIFZhcmlhYmxlDQogICAgICAgICAg ICAgICAgICAgICAgVmFsdWUNCiBIVFRQX0FDQ0VQVF9FTkNPRElORyANCiAgICAgICAgICAgICAg ICAgICAgICBnemlwIA0KIFJFTU9URV9IT1NUIA0KICAgICAgICAgICAgICAgICAgICAgIHNseS51 bmljb25zZWlsLmNvbSANCiBNQUlMIA0KICAgICAgICAgICAgICAgICAgICAgIC92YXIvc3Bvb2wv bWFpbC9yb290IA0KIENPTlRFTlRfVFlQRSANCiAgICAgICAgICAgICAgICAgICAgICBhcHBsaWNh dGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQgDQogSFRUUF9DT09LSUUgDQogICAgICAgICAgICAg ICAgICAgICAgaW1wZXJpYWwtYWRtaW49LTIwNjQ4MjY1Nzc7IHNvbHV0aW9uZXQtYWRtaW49LTQz NTMwNTc2MDsgZGlyZWN0aW9uLWFkbWluPTEyODM0ODQ5OTQ7DQogICAgICAgICAgICAgICAgICAg ICAgaW5mb2dyb3VwZS1hZG1pbj0yMTAzNjM0NjQwIA0KIFdOX1JPT1QgDQogICAgICAgICAgICAg ICAgICAgICAgL3d3dy9odGRvY3MgDQogSFRUUF9BQ0NFUFRfTEFOR1VBR0UgDQogICAgICAgICAg ICAgICAgICAgICAgZW4gDQogSE9TVE5BTUUgDQogICAgICAgICAgICAgICAgICAgICAgcG9zdGVs LnVuaWNvbnNlaWwuY29tIA0KIFVSTF9TQ0hFTUUgDQogICAgICAgICAgICAgICAgICAgICAgaHR0 cCANCiBHQVRFV0FZX0lOVEVSRkFDRSANCiAgICAgICAgICAgICAgICAgICAgICBDR0kvMS4xIA0K IEhUVFBfQUNDRVBUIA0KICAgICAgICAgICAgICAgICAgICAgIGltYWdlL2dpZiwgaW1hZ2UveC14 Yml0bWFwLCBpbWFnZS9qcGVnLCBpbWFnZS9wanBlZywgaW1hZ2UvcG5nLCAqLyogDQogXyANCiAg ICAgICAgICAgICAgICAgICAgICAvd3d3L2h0ZG9jcy9tYWlsbWFuL2FkbWluZGIgDQogRU5WIA0K ICAgICAgICAgICAgICAgICAgICAgIC9yb290Ly5iYXNocmMgDQogSFRUUF9IT1NUIA0KICAgICAg ICAgICAgICAgICAgICAgIHBvc3RlbC51bmljb25zZWlsLmNvbTo4MCANCiBIT1NUVFlQRSANCiAg ICAgICAgICAgICAgICAgICAgICBpMzg2IA0KIFNDUklQVF9GSUxFTkFNRSANCiAgICAgICAgICAg ICAgICAgICAgICAvd3d3L2h0ZG9jcy9tYWlsbWFuL2FkbWluZGIgDQogUFlUSE9OUEFUSCANCiAg ICAgICAgICAgICAgICAgICAgICAvaG9tZS9tYWlsbWFuIA0KIFBBVEggDQogICAgICAgICAgICAg ICAgICAgICAgL3Vzci9iaW46L2JpbjovdXNyL3NiaW46L3NiaW46L3Vzci9YMTFSNi9iaW52dDEw MDovdXNyL1gxMVI2L2Jpbjovcm9vdC9iaW4gDQogVVNFUk5BTUUgDQogICAgICAgICAgICAgICAg ICAgICAgcm9vdCANCiBET0NVTUVOVF9ST09UIA0KICAgICAgICAgICAgICAgICAgICAgIC93d3cv aHRkb2NzIA0KIEhJU1RGSUxFU0laRSANCiAgICAgICAgICAgICAgICAgICAgICAxMDAwIA0KIEhU VFBfUE9TVF9GSUxFIA0KICAgICAgICAgICAgICAgICAgICAgIC90bXAvd25fdG1wNjU1MzQvV05w b3N0LTM2YmIwYjZmLTQxNmQtMCANCiBXTl9ESVJfUEFUSCANCiAgICAgICAgICAgICAgICAgICAg ICAvd3d3L2h0ZG9jcy9tYWlsbWFuIA0KIE9TVFlQRSANCiAgICAgICAgICAgICAgICAgICAgICBM aW51eCANCiBTRVJWRVJfUE9SVCANCiAgICAgICAgICAgICAgICAgICAgICAxMTgwMSANCiBIVFRQ X1VTRVJfQUdFTlQgDQogICAgICAgICAgICAgICAgICAgICAgTW96aWxsYS80LjUgW2VuXSAoV2lu OTg7IFUpIA0KIHZ0MTAwIA0KICAgICAgICAgICAgICAgICAgICAgIC9iaW4vYmFzaCANCiBTSExW TCANCiAgICAgICAgICAgICAgICAgICAgICAyIA0KIFJFTU9URV9BRERSIA0KICAgICAgICAgICAg ICAgICAgICAgIDIwNi40Ny4xNTUuMTUyIA0KIFNFUlZFUl9OQU1FIA0KICAgICAgICAgICAgICAg ICAgICAgIHBvc3RlbC51bmljb25zZWlsLmNvbSANCiBTSEVMTCANCiAgICAgICAgICAgICAgICAg ICAgICAvYmluL2Jhc2ggDQogVEVSTSANCiAgICAgICAgICAgICAgICAgICAgICB2dDEwMCANCiBI VFRQX0FDQ0VQVF9DSEFSU0VUIA0KICAgICAgICAgICAgICAgICAgICAgIGlzby04ODU5LTEsKix1 dGYtOCANCiBDT05URU5UX0xFTkdUSCANCiAgICAgICAgICAgICAgICAgICAgICAzNyANCiBIT01F IA0KICAgICAgICAgICAgICAgICAgICAgIC9yb290IA0KIFNFUlZFUl9QUk9UT0NPTCANCiAgICAg ICAgICAgICAgICAgICAgICBIVFRQLzEuMCANCiBQQVRIX0lORk8gDQogICAgICAgICAgICAgICAg ICAgICAgL2RpcmVjdGlvbiANCiBMT0dOQU1FIA0KICAgICAgICAgICAgICAgICAgICAgIHJvb3Qg DQogUkVRVUVTVF9NRVRIT0QgDQogICAgICAgICAgICAgICAgICAgICAgUE9TVCANCiBQQVRIX1RS QU5TTEFURUQgDQogICAgICAgICAgICAgICAgICAgICAgL3d3dy9odGRvY3MvZGlyZWN0aW9uIA0K IFNDUklQVF9OQU1FIA0KICAgICAgICAgICAgICAgICAgICAgIC9tYWlsbWFuL2FkbWluZGIgDQog U0VSVkVSX1NPRlRXQVJFIA0KICAgICAgICAgICAgICAgICAgICAgIFdOLzIuMS41IA0KIFVTRVIg DQogICAgICAgICAgICAgICAgICAgICAgcm9vdCANCiBIVFRQX1JFRkVSRVIgDQogICAgICAgICAg ICAgICAgICAgICAgaHR0cDovL3Bvc3RlbC51bmljb25zZWlsLmNvbTo4MC9tYWlsbWFuL2FkbWlu ZGIvZGlyZWN0aW9uIA0KIEhJU1RTSVpFIA0KICAgICAgICAgICAgICAgICAgICAgIDEwMDAgDQog UkVNT1RFX1BPUlQgDQogICAgICAgICAgICAgICAgICAgICAgMjA5MyANCg0KLS0tLS0NCg0KQmVz dCBSZWdhcmRzIQ0KDQoNCg0KDQoNClN5bHZhaW4gQm9sZHVjDQpTb2x1dGlvTkVUDQpVbmUgZmls aWFsZSBkdSBHcm91cGUgVW5pY29uc2VpbCBpbmMuDQoxODAxLCBNY0dpbGwgQ29sbGVnZSwgc3Vp dGUgMTAxMA0KTW9udHJlYWwgKFF1ZWJlYykgSDNBIDJONA0KDQpUZWw6ICg1MTQpIDg0MC0xMTU4 IHBvc3RlIDM1MQ0KRmF4OiAoNTE0KSA4NDAtMTE2Ng0Kc3lsdmFpbmJAdW5pY29uc2VpbC5jb20N Cmh0dHA6Ly93d3cudW5pY29uc2VpbC5jb20gDQoNCg0K ------=_NextPart_000_001E_01BE50F9.DC53A2A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD48 SEVBRD4NCjxNRVRBIGNvbnRlbnQ9JyJNU0hUTUwgNS4wMC4wOTEwLjEzMDkiJyBuYW1lPUdFTkVS QVRPUj4NCjxNRVRBIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIiBodHRw LWVxdWl2PUNvbnRlbnQtVHlwZT48L0hFQUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElW PjxTUEFOIGNsYXNzPTMxMDE5MTcxNi0wNTAyMTk5OT48Rk9OVCBzaXplPTI+SGVsbG8sPC9GT05U PjwvU1BBTj48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTMxMDE5 MTcxNi0wNTAyMTk5OT48Rk9OVCBzaXplPTI+SSdtIGEgc3lzdGVtIGFkbWluaXN0cmF0aW9uIG9m IA0KdGhlIFVuaWNvbnNlaWwgTWFpbCBTZXJ2ZXIuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTMxMDE5MTcxNi0wNTAyMTk5OT48Rk9OVCBz aXplPTI+UmVjZW50bHksIGkndmUgdHJpZWQgdG8gDQp1c2UvaW5zdGFsbCBNYWlsTWFuIDEuMGI3 IG92ZXIgTGludXggUkVESEFUIDUuMi48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MzEwMTkxNzE2LTA1MDIxOTk5PjxGT05UIHNpemU9Mj5C dXQgU2luY2UgeWVzdGVyZGF5LCBpJ20gDQpnZXR0aW5nIGFsb3Qgb2YgdGhvc2VzIGVycm9ycy48 L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0zMTAxOTE3MTYtMDUwMjE5OTk+ PEZPTlQgc2l6ZT0yPkkgQ2FuJ3QgZmluZCBhIHdheSB0byBmaXggdGhlIA0KcHJvYmxlbS48L0ZP TlQ+PC9TUEFOPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MzEw MTkxNzE2LTA1MDIxOTk5PjxGT05UIHNpemU9Mj5EbyB5b3UgdGhpbmsgaSBuZWVkIHRvIHVwZ3Jh ZGUgDQp0byAxLjBiOCA/PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0zMTAxOTE3MTYtMDUwMjE5OTk+PEZP TlQgc2l6ZT0yPi0tLS0tLS08L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0xPldlJ3JlIHNvcnJ5LCB3ZSBoaXQgYSBidWchPC9GT05UPjwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0xPklmIHlvdSB3b3VsZCBsaWtl IHRvIGhlbHAgdXMgaWRlbnRpZnkgdGhlIHByb2JsZW0sIHBsZWFzZSANCmVtYWlsIGEgY29weSBv ZiB0aGlzIHBhZ2UgdG8gdGhlIHdlYm1hc3RlciBmb3IgdGhpcyBzaXRlIHdpdGggYSBkZXNjcmlw dGlvbiBvZiANCndoYXQgaGFwcGVuZWQuPEJSPlRoYW5rcyEgPC9GT05UPjwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0xPlRyYWNlYmFjazo8L0ZPTlQ+PC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTE+PEJSPlRyYWNlYmFjayAoaW5uZXJt b3N0IGxhc3QpOjxCUj4gIEZpbGUgDQomcXVvdDsvaG9tZS9tYWlsbWFuL3NjcmlwdHMvZHJpdmVy JnF1b3Q7LCBsaW5lIDEwMiwgaW4gcnVuX21haW48QlI+IDwvRk9OVD48Rk9OVCANCnNpemU9MT5t YWluKCk8QlI+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTE+ICBGaWxlICZxdW90Oy9o b21lL21haWxtYW4vTWFpbG1hbi9DZ2kvYWRtaW5kYi5weSZxdW90OywgbGluZSANCjEyNCwgaW4g bWFpbjxCUj4gICAgSGFuZGxlUmVxdWVzdHMoZG9jKTxCUj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIHNpemU9MT4gIEZpbGUgJnF1b3Q7L2hvbWUvbWFpbG1hbi9NYWlsbWFuL0NnaS9hZG1pbmRi LnB5JnF1b3Q7LCBsaW5lIA0KMjExLCBpbiBIYW5kbGVSZXF1ZXN0czxCUj4gICAgbGlzdC5IYW5k bGVSZXF1ZXN0KHJlcXVlc3QsIHYpPEJSPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0x PiAgRmlsZSAmcXVvdDsvaG9tZS9tYWlsbWFuL01haWxtYW4vTGlzdEFkbWluLnB5JnF1b3Q7LCBs aW5lIA0KMTIyLCBpbiBIYW5kbGVSZXF1ZXN0PEJSPiAgICBzZWxmLkhhbmRsZVBvc3RSZXF1ZXN0 KHJlcXVlc3RfZGF0YVsyOl0sIHZhbHVlLCANCmNvbW1lbnQpPEJSPjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0xPiAgRmlsZSAmcXVvdDsvaG9tZS9tYWlsbWFuL01haWxtYW4vTGlzdEFk bWluLnB5JnF1b3Q7LCBsaW5lIA0KMTMxLCBpbiBIYW5kbGVQb3N0UmVxdWVzdDxCUj4gICAgc2Vs Zi5Qb3N0KG1zZywgMSk8QlI+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTE+ICBGaWxl ICZxdW90Oy9ob21lL21haWxtYW4vTWFpbG1hbi9NYWlsTGlzdC5weSZxdW90OywgbGluZSANCjEx NTgsIGluIFBvc3Q8QlI+ICAgIHNlbGYuRGVsaXZlclRvTGlzdChtc2csIHJlY2lwaWVudHMsPEJS PjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0xPiAgRmlsZSAmcXVvdDsvaG9tZS9tYWls bWFuL01haWxtYW4vRGVsaXZlcmVyLnB5JnF1b3Q7LCBsaW5lIA0KMTcyLCBpbiBEZWxpdmVyVG9M aXN0PEJSPiAgICBzdGF0dXMgPSBjbWRwcm9jLmNsb3NlKCk8QlI+SU9FcnJvcjogKDEwLCAnTm8g Y2hpbGQgDQpwcm9jZXNzZXMnKTwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTE+RW52aXJvbm1lbnQgdmFyaWFibGVzOjwv Rk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48Rk9OVCBz aXplPTE+IFZhcmlhYmxlPEJSPiAgICAgICAgICAgICAgICAgICAgICBWYWx1ZTxCUj4gDQpIVFRQ X0FDQ0VQVF9FTkNPRElORyA8QlI+ICAgICAgICAgICAgICAgICAgICAgIGd6aXAgPEJSPiBSRU1P VEVfSE9TVCA8QlI+ICAgICAgICANCiAgICAgICAgICAgICAgc2x5LnVuaWNvbnNlaWwuY29tIDxC Uj4gTUFJTCA8QlI+ICAgICAgICAgICAgICAgICAgICAgIA0KL3Zhci9zcG9vbC9tYWlsL3Jvb3Qg PEJSPiBDT05URU5UX1RZUEUgPEJSPiAgICAgICAgICAgICAgICAgICAgICANCmFwcGxpY2F0aW9u L3gtd3d3LWZvcm0tdXJsZW5jb2RlZCA8QlI+IEhUVFBfQ09PS0lFIDxCUj4gICAgICAgICAgICAg ICAgICAgICAgDQppbXBlcmlhbC1hZG1pbj0tMjA2NDgyNjU3Nzsgc29sdXRpb25ldC1hZG1pbj0t NDM1MzA1NzYwOyANCmRpcmVjdGlvbi1hZG1pbj0xMjgzNDg0OTk0OzxCUj4gICAgICAgICAgICAg ICAgICAgICAgaW5mb2dyb3VwZS1hZG1pbj0yMTAzNjM0NjQwIA0KPEJSPiBXTl9ST09UIDxCUj4g ICAgICAgICAgICAgICAgICAgICAgL3d3dy9odGRvY3MgPEJSPiBIVFRQX0FDQ0VQVF9MQU5HVUFH RSANCjxCUj4gICAgICAgICAgICAgICAgICAgICAgZW4gPEJSPiBIT1NUTkFNRSA8QlI+ICAgICAg ICAgICAgICAgICAgICAgIA0KcG9zdGVsLnVuaWNvbnNlaWwuY29tIDxCUj4gVVJMX1NDSEVNRSA8 QlI+ICAgICAgICAgICAgICAgICAgICAgIGh0dHAgPEJSPiANCkdBVEVXQVlfSU5URVJGQUNFIDxC Uj4gICAgICAgICAgICAgICAgICAgICAgQ0dJLzEuMSA8QlI+IEhUVFBfQUNDRVBUIDxCUj4gICAg ICAgIA0KICAgICAgICAgICAgICBpbWFnZS9naWYsIGltYWdlL3gteGJpdG1hcCwgaW1hZ2UvanBl ZywgaW1hZ2UvcGpwZWcsIGltYWdlL3BuZywgDQoqLyogPEJSPiBfIDxCUj4gICAgICAgICAgICAg ICAgICAgICAgL3d3dy9odGRvY3MvbWFpbG1hbi9hZG1pbmRiIDxCUj4gRU5WIDxCUj4gICANCiAg ICAgICAgICAgICAgICAgICAvcm9vdC8uYmFzaHJjIDxCUj4gSFRUUF9IT1NUIDxCUj4gICAgICAg ICAgICAgICAgICAgICAgDQpwb3N0ZWwudW5pY29uc2VpbC5jb206ODAgPEJSPiBIT1NUVFlQRSA8 QlI+ICAgICAgICAgICAgICAgICAgICAgIGkzODYgPEJSPiANClNDUklQVF9GSUxFTkFNRSA8QlI+ ICAgICAgICAgICAgICAgICAgICAgIC93d3cvaHRkb2NzL21haWxtYW4vYWRtaW5kYiA8QlI+IA0K UFlUSE9OUEFUSCA8QlI+ICAgICAgICAgICAgICAgICAgICAgIC9ob21lL21haWxtYW4gPEJSPiBQ QVRIIDxCUj4gICAgICAgICAgICAgICAgDQogICAgICAvdXNyL2JpbjovYmluOi91c3Ivc2Jpbjov c2JpbjovdXNyL1gxMVI2L2JpbnZ0MTAwOi91c3IvWDExUjYvYmluOi9yb290L2JpbiANCjxCUj4g VVNFUk5BTUUgPEJSPiAgICAgICAgICAgICAgICAgICAgICByb290IDxCUj4gRE9DVU1FTlRfUk9P VCA8QlI+ICAgICAgICAgICAgIA0KICAgICAgICAgL3d3dy9odGRvY3MgPEJSPiBISVNURklMRVNJ WkUgPEJSPiAgICAgICAgICAgICAgICAgICAgICAxMDAwIDxCUj4gDQpIVFRQX1BPU1RfRklMRSA8 QlI+ICAgICAgICAgICAgICAgICAgICAgIC90bXAvd25fdG1wNjU1MzQvV05wb3N0LTM2YmIwYjZm LTQxNmQtMCANCjxCUj4gV05fRElSX1BBVEggPEJSPiAgICAgICAgICAgICAgICAgICAgICAvd3d3 L2h0ZG9jcy9tYWlsbWFuIDxCUj4gT1NUWVBFIDxCUj4gIA0KICAgICAgICAgICAgICAgICAgICBM aW51eCA8QlI+IFNFUlZFUl9QT1JUIDxCUj4gICAgICAgICAgICAgICAgICAgICAgMTE4MDEgPEJS PiANCkhUVFBfVVNFUl9BR0VOVCA8QlI+ICAgICAgICAgICAgICAgICAgICAgIE1vemlsbGEvNC41 IFtlbl0gKFdpbjk4OyBVKSA8QlI+IHZ0MTAwIA0KPEJSPiAgICAgICAgICAgICAgICAgICAgICAv YmluL2Jhc2ggPEJSPiBTSExWTCA8QlI+ICAgICAgICAgICAgICAgICAgICAgIDIgPEJSPiANClJF TU9URV9BRERSIDxCUj4gICAgICAgICAgICAgICAgICAgICAgMjA2LjQ3LjE1NS4xNTIgPEJSPiBT RVJWRVJfTkFNRSA8QlI+ICAgICAgIA0KICAgICAgICAgICAgICAgcG9zdGVsLnVuaWNvbnNlaWwu Y29tIDxCUj4gU0hFTEwgPEJSPiAgICAgICAgICAgICAgICAgICAgICANCi9iaW4vYmFzaCA8QlI+ IFRFUk0gPEJSPiAgICAgICAgICAgICAgICAgICAgICB2dDEwMCA8QlI+IEhUVFBfQUNDRVBUX0NI QVJTRVQgDQo8QlI+ICAgICAgICAgICAgICAgICAgICAgIGlzby04ODU5LTEsKix1dGYtOCA8QlI+ IENPTlRFTlRfTEVOR1RIIDxCUj4gICAgICAgICAgICANCiAgICAgICAgICAzNyA8QlI+IEhPTUUg PEJSPiAgICAgICAgICAgICAgICAgICAgICAvcm9vdCA8QlI+IFNFUlZFUl9QUk9UT0NPTCA8QlI+ IA0KICAgICAgICAgICAgICAgICAgICAgSFRUUC8xLjAgPEJSPiBQQVRIX0lORk8gPEJSPiAgICAg ICAgICAgICAgICAgICAgICANCi9kaXJlY3Rpb24gPEJSPiBMT0dOQU1FIDxCUj4gICAgICAgICAg ICAgICAgICAgICAgcm9vdCA8QlI+IFJFUVVFU1RfTUVUSE9EIDxCUj4gIA0KICAgICAgICAgICAg ICAgICAgICBQT1NUIDxCUj4gUEFUSF9UUkFOU0xBVEVEIDxCUj4gICAgICAgICAgICAgICAgICAg ICAgDQovd3d3L2h0ZG9jcy9kaXJlY3Rpb24gPEJSPiBTQ1JJUFRfTkFNRSA8QlI+ICAgICAgICAg ICAgICAgICAgICAgIA0KL21haWxtYW4vYWRtaW5kYiA8QlI+IFNFUlZFUl9TT0ZUV0FSRSA8QlI+ ICAgICAgICAgICAgICAgICAgICAgIFdOLzIuMS41IDxCUj4gDQpVU0VSIDxCUj4gICAgICAgICAg ICAgICAgICAgICAgcm9vdCA8QlI+IEhUVFBfUkVGRVJFUiA8QlI+ICAgICAgICAgICAgICAgICAg ICAgIA0KPEEgDQpocmVmPSJodHRwOi8vcG9zdGVsLnVuaWNvbnNlaWwuY29tOjExODAxLyI+aHR0 cDovL3Bvc3RlbC51bmljb25zZWlsLmNvbTo4MC88L0E+bWFpbG1hbi9hZG1pbmRiL2RpcmVjdGlv biANCjxCUj4gSElTVFNJWkUgPEJSPiAgICAgICAgICAgICAgICAgICAgICAxMDAwIDxCUj4gUkVN T1RFX1BPUlQgPEJSPiAgICAgICAgICAgICAgIA0KICAgICAgIDIwOTM8L0ZPTlQ+IDwvRk9OVD48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTMxMDE5MTcxNi0wNTAy MTk5OT48Rk9OVCBzaXplPTI+LS0tLS08L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MzEwMTkxNzE2LTA1MDIxOTk5PjxGT05UIHNpemU9Mj5C ZXN0IA0KUmVnYXJkcyE8L0ZPTlQ+PC9TUEFOPjwvRElWPjxCUj48QlI+PEJSPjxCUj4NCjxQPjxG T05UIHNpemU9Mj5TeWx2YWluIEJvbGR1YzxCUj5Tb2x1dGlvTkVUPEJSPlVuZSBmaWxpYWxlIGR1 IEdyb3VwZSBVbmljb25zZWlsIA0KaW5jLjxCUj4xODAxLCBNY0dpbGwgQ29sbGVnZSwgc3VpdGUg MTAxMDxCUj5Nb250cmVhbCAoUXVlYmVjKSBIM0EgDQoyTjQ8QlI+PEJSPlRlbDogKDUxNCkgODQw LTExNTggcG9zdGUgMzUxPEJSPkZheDogKDUxNCkgODQwLTExNjY8QlI+PEEgDQpocmVmPSJtYWls dG86c3lsdmFpbmJAdW5pY29uc2VpbC5jb20iPnN5bHZhaW5iQHVuaWNvbnNlaWwuY29tPC9BPjxC Uj48QSANCmhyZWY9Imh0dHA6Ly93d3cudW5pY29uc2VpbC5jb20iIHRhcmdldD1fYmxhbms+aHR0 cDovL3d3dy51bmljb25zZWlsLmNvbTwvQT4gDQo8L0ZPTlQ+PC9QPg0KPERJVj4mbmJzcDs8L0RJ Vj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_001E_01BE50F9.DC53A2A0-- From Harald.Meland@usit.uio.no Fri Feb 5 17:43:26 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 05 Feb 1999 18:43:26 +0100 Subject: [Mailman-Developers] member-sets composed of member-sets for other Mailman-lists Message-ID: Hi, I am more and more frequently getting reqests for mailing lists that reach the union of members of other mailing lists (all these mailing lists are Mailman controlled). The Mailman concept of umbrella lists doesn't quite cut it, as I find it a hack to solve a specific case -- i.e. it is not general enough. Besides, how can you (safely) set up an umbrella list to have any message inserted into some level of the hierarchy only generate _one_ request for moderator approval? Various heuristics based on looking at mail headers isn't reqally my idea of a "Good, Clean Solution" :) Thus, my request: Could Mailman accept some special syntax member address (being invalid in the SMTP sense) for including all members of another Mailman list (under the same Mailman installation) into this list? I.e., if the list "all-students" has this member list: some.supervisor@some-faculty.my.domain another.non.student@administration.my.domain [students-spring-1998] [students-fall-1998] , then the union of the regular addresses on the "all-students" list and the (recursively) expanded member list of the included lists ("students-spring-1998" and "students-fall-1998") is the real member list of the "all-students" list. Adding these "include other list" addresses should only be possible via the admin web interface (i.e. not possible via the regular "I want to subscribe" user web interface). The whole issue with where to send the password reminders and such would go away -- send out password reminders to members subscribed via lists that are configured to do so (and users wouldn't even have a separate password, let alone separate subscription options for lists they are indirectly subscribed to. I consider this coarse granularity a feature, YMMV). It would also be nice if there was some provision for regulating which administrators were allowed to include what other lists into their own lists -- e.g., a first approximation could be: If the intersection of the sets of administrators of the including and the included lists is the empty set, disallow inclusion. Such "privileges control" will, of course, be easier to implement as administrators get their own Mailman object (to be worked on after 1.0 is finally out the door). So, what do y'all think? -- Harald From rocon@pivot.net Fri Feb 5 14:41:03 1999 From: rocon@pivot.net (Robert OConnor) Date: Fri, 5 Feb 1999 09:41:03 -0500 Subject: [Mailman-Developers] Feature Request: unsubscribe from list mail Message-ID: <00da01be5116$072ef1c0$0201a8c0@hawkeye.bob.oc> I subscribe to a lot of lists and ***all too often*** see messages such as: unsubscribe or please unsubscribe me from this list. or how do I unsubscribe NEAT FEATURE REQUEST Before messages of this type are sent to the list of hundreds of others, How about a routine that scans ONLY the first line of the body looking for the word unsubscribe (Upper & Lower case) This message would NOT be posted but quoted back to the sender with the standard "Reply to this message to confirm your canceled subscription" I struggle my self when unsubscribing because I have misplaced, deleted or archived the first list "save this message" especially on long running lists. -bobo connor From jerrya@fastrans.net Sat Feb 6 17:12:53 1999 From: jerrya@fastrans.net (Jerry Adlersfluegel) Date: Sat, 6 Feb 1999 11:12:53 -0600 (CST) Subject: [Mailman-Developers] subscribers being ignored Message-ID: I sent this to -users and haven't heard back from anyone, so I'll try here. My setup: Linux 2.0.32 sendmail 8.9.2 (was 8.8.7 until this morning) mailman 1.0b8 I have a single list with 77 subscribers. I am hosting the list through a modem, and it is great. The improvements since b5 are such that delivery time has improved from over 4 minutes for a typical message to about 1:30. Everyone is happy with the list. Except for a couple people that don't receive any of the traffic. I added a couple subscribers over a week ago and they are not getting any of the messages. They did receive their subscription reminders. I have unsubscribed them and then re-added them (it is a closed list) and it didn't help. Their profiles are the same as anyone else, but they just don't get any of the mail. The only thing I can think of is that the ones that are shut out are all on AOL. There are 22 regular subscribers on AOL, and I noticed how the mail gets batched together. Is it possible that there is a limit to how many recipients my sendmail is seeing? In my case a single message gets sent for all the AOL recipients, of which there are only 19 on the recipient list. Is there a way I can control how this works? The only reason I can even think that is the problem is that the most recently added users are the ones that aren't getting the traffic. Thanks for any ideas. -- Jerry Adlersfluegel From klm@digicool.com Sat Feb 6 22:52:15 1999 From: klm@digicool.com (Ken Manheimer) Date: Sat, 6 Feb 1999 17:52:15 -0500 Subject: [Mailman-Developers] Feature Request: unsubscribe from list mail Message-ID: <199902062252.RAA03409@albert.digicool.com> Bobo connor wrote: > I subscribe to a lot of lists and > ***all too often*** > see messages such as: > > unsubscribe > or > please unsubscribe me from this list. > or > how do I unsubscribe > > NEAT FEATURE REQUEST > > Before messages of this type are sent > to the list of hundreds of others, How about > a routine that scans ONLY the > first line of the body looking for > the word unsubscribe (Upper & Lower case) > > This message would NOT be posted but quoted > back to the sender with the standard > "Reply to this message to confirm > your canceled subscription" > > I struggle my self when unsubscribing because > I have misplaced, deleted or archived the > first list "save this message" especially on long running > lists. Ironically, your message was held for administrator approval due to the "unsubscribe" in the subject and first few lines of the message - mailman has an administivia detector (that could perhaps use more tuning). I did approve it, and would have liked if the approval message offered me the option to note just this in the approval, but no such luck. (I would have commented about this, but my company's connection to the internet is currently suffering non-cooperation from the phone company, so i'm hardly connected.) The approach you suggest of soliciting confirmation for suspect administrivia messages sounds like one good way to improve the situation - are you thinking about implementing it? If anyone is, it'd be good to discuss it on the list first. My thought is that it would be good to generalize the confirmation mechanism mailman already has so it can be used by the administrator at their discretion, eg from the admindb approval page... Briefly, Ken klm@digicool.com From Harald.Meland@usit.uio.no Sun Feb 7 14:28:43 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 07 Feb 1999 15:28:43 +0100 Subject: [Mailman-Developers] subscribers being ignored In-Reply-To: Jerry Adlersfluegel's message of "Sat, 6 Feb 1999 11:12:53 -0600 (CST)" References: Message-ID: [Jerry Adlersfluegel] > I added a couple subscribers over a week ago and they are not getting any > of the messages. They did receive their subscription reminders. > > I have unsubscribed them and then re-added them (it is a closed list) and > it didn't help. Their profiles are the same as anyone else, but they just > don't get any of the mail. > > The only thing I can think of is that the ones that are shut out are all > on AOL. There are 22 regular subscribers on AOL, and I noticed how the > mail gets batched together. Is it possible that there is a limit to how > many recipients my sendmail is seeing? There is no such restriction that I know of in Mailman, but I believe you can configure Sendmail to put a ceiling on how many RCPT To:s you can have for one single message. I don't have my bat book here (nor am I very familiar with Sendmail configuration in general), so I don't know what specific config settings you should have a look at. As Mailman tries to batch addresses together by domain when it does deliveries, having a too restrictive Sendmail configuration could indeed be your problem. [ IIRC, the most recent draft of the upcoming RFC821-replacement says to allow _at least_ 100 RCPT To:s for any message -- so your apparent ceiling of 20 would be a bit low. ] If no one else fills me in on the sendmail config details, I'll try checking my bat book on Monday (or when I get the chance) and report any relevant findings. > The only reason I can even think that is the problem is that the most > recently added users are the ones that aren't getting the traffic. Hmmm... I don't think that Mailman keeps track of _when_ the various members of a list was added, or even the order in which this happens -- they are all kept in the same dict (or "hash", if you prefer), so there needn't be any relation between the time of subscribing and what addresses gets "denied" by your sendmail config. -- Harald From claw@kanga.nu Mon Feb 8 04:39:10 1999 From: claw@kanga.nu (J C Lawrence) Date: Sun, 07 Feb 1999 20:39:10 -0800 Subject: [Mailman-Developers] Moderation comment interface change In-Reply-To: Message from George Hartz of "Tue, 12 Jan 1999 16:53:46 GMT." <369B7E1A.B3A5F822@blowtorch.com> Message-ID: Suggested changes for MailMan 1.0b8: 1) Add email command to add a given subscriber address to the "Addresses of members accepted for posting to this list without implicit approval requirement..." and extend this feature to (optionally) send a message to the given subscriber denoting that they are now on the "posters" list. 2) Currently when when you reject a post to a moderated list you can also enter a one line explanation to be sent back to the original poster. Often I reject a post for multiple reasons, such as lines longer than 80 columns, missing attributions on quoted text, signature too long, etc. Any reason not to change the input fields from a single line to a multi-line text area? 3) Ability to explicitly turn off RFC 1153 digests (I want MIME only). 4) Ability to define a separate Reply-To address to be applied to digests only (in my case I point it to a null address -- I don't want users replying to digests). 5) MH-style archive folders, split out by archive period, instead of mbox'es (message separation semantics with mbox are not guaranteed). Comments? -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From Harald.Meland@usit.uio.no Mon Feb 8 11:54:14 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 08 Feb 1999 12:54:14 +0100 Subject: [Mailman-Developers] subscribers being ignored In-Reply-To: Harald Meland's message of "07 Feb 1999 15:28:43 +0100" References: Message-ID: [Harald Meland] > [Jerry Adlersfluegel] > > > Is it possible that there is a limit to how many recipients my > > sendmail is seeing? > > If no one else fills me in on the sendmail config details, I'll try > checking my bat book on Monday (or when I get the chance) and report > any relevant findings. Bat book checked and found outdated, so I checked Dejanews, and from hints found there I got this: From the sendmail-8.9.0 cf/README file: : +--------------------------------+ : | TWEAKING CONFIGURATION OPTIONS | : +--------------------------------+ : [...] : M4 Variable Name Configuration Description & [Default] : ================ ============= ======================= : confMAX_RCPTS_PER_MESSAGE MaxRecipientsPerMessage : [infinite] If set, allow no more than : the specified number of recipients in : an SMTP envelope. Further recipients : receive a 452 error code (i.e., they : are deferred for the next delivery : attempt). If you're running some sendmail version earlier than 8.9.0, I'd guess you could emulate this new option with some fancy stuff in e.g. the check_rcpt ruleset (but I'm not a sendmail guru, so don't take my word for it). Could you "grep MaxRecipientsPerMessage sendmail.cf" and let us know if my guess is anywhere near the solution to the problem, so that Mailman can include hints on checking this sendmail setting for other users with similar problems? -- Harald From Harald.Meland@usit.uio.no Mon Feb 8 12:08:05 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 08 Feb 1999 13:08:05 +0100 Subject: [Mailman-Developers] Moderation comment interface change In-Reply-To: J C Lawrence's message of "Sun, 07 Feb 1999 20:39:10 -0800" References: Message-ID: [J C Lawrence] > 5) MH-style archive folders, split out by archive period, instead of > mbox'es (message separation semantics with mbox are not guaranteed). While MH-style archive folders could be a nice feature, I don't think your comment on the message separation semantics of mbox folders is entirely correct. Sendmail (and compatible MTAs) actually _quote_ any lines beginning with "From " in the message body when delivering locally to avoid breaking the message separators. [ I've heard rumours that Postfix doesn't put any "From " quasi-header in pipe-delivered messages at all (while it does add "Delivered-To:" headers containing the envelope recipient (and use these headers to kill forwarding loops -- this may actually be a clue to the problems people have getting Mailman and Postfix working together)). If this indeed is the case, then there would (from Postfix' point of view) be no need to quote any "From " lines in the body of the message, either -- and this could break the message separation semantics of Mailman's mbox-style folders. Whether the proper fix is for Mailman to quote any "From " lines on it's own, or switch to using some other folder format, is at this time unclear to me. ] -- Harald From jerrya@fastrans.net Mon Feb 8 14:41:50 1999 From: jerrya@fastrans.net (Jerry Adlersfluegel) Date: Mon, 08 Feb 1999 08:41:50 -0600 Subject: [Mailman-Developers] subscribers being ignored References: Message-ID: <36BEF7AE.EA1B8631@fastrans.net> Harald Meland wrote: > If you're running some sendmail version earlier than 8.9.0, I'd guess > you could emulate this new option with some fancy stuff in e.g. the > check_rcpt ruleset (but I'm not a sendmail guru, so don't take my word > for it). I'm not one either, of course. I found the same thing you did. Since I was at 8.8.7 I decided to upgrade. I installed 8.9.2, and nothing changed. > > Could you "grep MaxRecipientsPerMessage sendmail.cf" and let us know > if my guess is anywhere near the solution to the problem, so that > Mailman can include hints on checking this sendmail setting for other > users with similar problems? Here's what is in my sendmail.cf. This means it is set to default, which is infinite, right? $ grep MaxRecipientsPerMessage /etc/sendmail.cf #O MaxRecipientsPerMessage=100 How can I see exactly who a message is being (or was) sent to by mailman? That could help me figure out where the problem may be. Thanks! From Harald.Meland@usit.uio.no Mon Feb 8 16:14:09 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 08 Feb 1999 17:14:09 +0100 Subject: [Mailman-Developers] subscribers being ignored In-Reply-To: Jerry Adlersfluegel's message of "Mon, 08 Feb 1999 08:41:50 -0600" References: <36BEF7AE.EA1B8631@fastrans.net> Message-ID: [Jerry Adlersfluegel] > How can I see exactly who a message is being (or was) sent to by > mailman? Sendmail should be logging this, I think. Have a look in your syslog. Barring that, I guess you could instrument Mailman like this: Open ~mailman/Mailman/Utils.py in your favorite editor. Look for this piece of code, in the TrySMTPDelivery() function: try: conn = smtplib.SMTP(mm_cfg.SMTPHOST) # Do the EHLO/HELO manually so we can check for DSN support Just under the "conn = ..." line, insert conn.set_debuglevel(1) to enable debugging. Save the file, and send a message to the problematic list. Debugging output (i.e. a transcript of the entire SMTP dialogue) should now be in ~mailman/logs/error. Remember to remove the debugging line again afterwards. -- Harald From claw@under.engr.sgi.com Mon Feb 8 18:55:55 1999 From: claw@under.engr.sgi.com (J C Lawrence) Date: Mon, 08 Feb 1999 10:55:55 -0800 Subject: [Mailman-Developers] Moderation comment interface change In-Reply-To: Message from Harald Meland of "08 Feb 1999 13:08:05 +0100." Message-ID: <199902081855.KAA75863@under.engr.sgi.com> On 08 Feb 1999 13:08:05 +0100 Harald Meland wrote: > [J C Lawrence] >> 5) MH-style archive folders, split out by archive period, instead >> of mbox'es (message separation semantics with mbox are not >> guaranteed). > While MH-style archive folders could be a nice feature, I don't > think your comment on the message separation semantics of mbox > folders is entirely correct. A brief perusal of the MHonArc list's archives and the regular problems members have with message separators with MHonArc seems to suggest otherwise. The lack of an absolute standard (eg BNF diagram in a recognised RFC) for mbox format really doesn't help. <> -- J C Lawrence Internet: claw@kanga.nu (Contractor) Internet: coder@kanga.nu ---------(*) Internet: claw@under.engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From petrilli@amber.org Mon Feb 8 19:17:08 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Mon, 8 Feb 1999 14:17:08 -0500 Subject: [Mailman-Developers] Moderation comment interface change In-Reply-To: <199902081855.KAA75863@under.engr.sgi.com>; from J C Lawrence on Mon, Feb 08, 1999 at 10:55:55AM -0800 References: <199902081855.KAA75863@under.engr.sgi.com> Message-ID: <19990208141708.04980@amber.org> On Mon, Feb 08, 1999 at 10:55:55AM -0800, J C Lawrence wrote: > > A brief perusal of the MHonArc list's archives and the regular > problems members have with message separators with MHonArc seems to > suggest otherwise. The lack of an absolute standard (eg BNF diagram > in a recognised RFC) for mbox format really doesn't help. Well, the other option is PMDF style (4 0x001 characters at the beginning of the line). THe big problem with using MH-style is that it can become a HUGE HUGE HUGE disk hog... what I have looked into is shoving the whole thing into MySQL :-) One table per list, which would let you do some really nice queries against it... this would let you move to a more dynamic page generation, rather than a static one, which would allow users to customize their page generation. Perhaps we need to start a list-archiver project seperate from mailman? Chris -- | Christopher Petrilli | petrilli@amber.org From claw@under.engr.sgi.com Mon Feb 8 19:24:18 1999 From: claw@under.engr.sgi.com (J C Lawrence) Date: Mon, 08 Feb 1999 11:24:18 -0800 Subject: [Mailman-Developers] Moderation comment interface change In-Reply-To: Message from "Christopher G. Petrilli" of "Mon, 08 Feb 1999 14:17:08 EST." <19990208141708.04980@amber.org> Message-ID: <199902081924.LAA75671@under.engr.sgi.com> On Mon, 8 Feb 1999 14:17:08 -0500 Christopher G Petrilli wrote: > On Mon, Feb 08, 1999 at 10:55:55AM -0800, J C Lawrence wrote: >> A brief perusal of the MHonArc list's archives and the regular >> problems members have with message separators with MHonArc seems >> to suggest otherwise. The lack of an absolute standard (eg BNF >> diagram in a recognised RFC) for mbox format really doesn't help. > Well, the other option is PMDF style (4 0x001 characters at the > beginning of the line). True, tho its been quite a while since I've run into that one. > THe big problem with using MH-style is that it can become a HUGE > HUGE HUGE disk hog... I have a little over a million and a half messages in MH folders right now, and yes, they chew disk space. Disk however is cheap. > what I have looked into is shoving the whole thing into MySQL :-) Not a bad idea, especially if batched with a set of export tools to spit mbox/MH/etc for legacy interfaces. > One table per list, which would let you do some really nice > queries against it... this would let you move to a more dynamic > page generation, rather than a static one, which would allow users > to customize their page generation. Problems are two fold: Need a MHonArc analogue that will run against MySQL. Need a decent search tool (I use WebGlimpse, but HT://Dig isn't too bad) that will run against the results. > Perhaps we need to start a list-archiver project seperate from > mailman? I'd say so. -- J C Lawrence Internet: claw@kanga.nu (Contractor) Internet: coder@kanga.nu ---------(*) Internet: claw@under.engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From petrilli@amber.org Mon Feb 8 19:41:55 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Mon, 8 Feb 1999 14:41:55 -0500 Subject: [Mailman-Developers] Moderation comment interface change In-Reply-To: <199902081924.LAA75671@under.engr.sgi.com>; from J C Lawrence on Mon, Feb 08, 1999 at 11:24:18AM -0800 References: <199902081924.LAA75671@under.engr.sgi.com> Message-ID: <19990208144155.44235@amber.org> On Mon, Feb 08, 1999 at 11:24:18AM -0800, J C Lawrence wrote: > > > Well, the other option is PMDF style (4 0x001 characters at the > > beginning of the line). > > True, tho its been quite a while since I've run into that one. Oh you'd be amazed how often I run into it... MMDF/PMDF live :-) Perhaps we want to use BABYL? :-) Actually, it's not a bad format, probably better than all the others, and well "documented" in elisp. > > THe big problem with using MH-style is that it can become a HUGE > > HUGE HUGE disk hog... > > I have a little over a million and a half messages in MH folders > right now, and yes, they chew disk space. Disk however is cheap. Cheap yes, but still, I don't know that I want to waste it like this unless there's no other solution. > > what I have looked into is shoving the whole thing into MySQL :-) > > Not a bad idea, especially if batched with a set of export tools to > spit mbox/MH/etc for legacy interfaces. Oh definately, I'm trying to cobble up something right now that can take mbox format and shove them in with some intellegence... hope to post it later today. > > One table per list, which would let you do some really nice > > queries against it... this would let you move to a more dynamic > > page generation, rather than a static one, which would allow users > > to customize their page generation. > > Problems are two fold: > > Need a MHonArc analogue that will run against MySQL. You mean a user interface? :-) Of course... > Need a decent search tool (I use WebGlimpse, but HT://Dig isn't > too bad) that will run against the results. THis is the second problem... I've been thinking about it... I don't know of any text-indexer (ie inverted indeces) that is designed to be programatically driven, rather than stand-alone... I want something that can do all it's indexing, but be driven from the unified interface, not from some secondary interface... know what I mean? > > Perhaps we need to start a list-archiver project seperate from > > mailman? > > I'd say so. > Barry? EtAl? Chris -- | Christopher Petrilli | petrilli@amber.org From jerrya@fastrans.net Mon Feb 8 21:12:25 1999 From: jerrya@fastrans.net (Jerry Adlersfluegel) Date: Mon, 08 Feb 1999 15:12:25 -0600 Subject: [Mailman-Developers] subscribers being ignored References: <36BEF7AE.EA1B8631@fastrans.net> Message-ID: <36BF5339.F892EEE5@fastrans.net> Harald Meland wrote: > > [Jerry Adlersfluegel] > > > How can I see exactly who a message is being (or was) sent to by > > mailman? > > Sendmail should be logging this, I think. Have a look in your syslog. I didn't see anything like that there. > > Barring that, I guess you could instrument Mailman like this: > > Open ~mailman/Mailman/Utils.py in your favorite editor. Look for this > piece of code, in the TrySMTPDelivery() function: > > try: > conn = smtplib.SMTP(mm_cfg.SMTPHOST) > # Do the EHLO/HELO manually so we can check for DSN support > > Just under the "conn = ..." line, insert > > conn.set_debuglevel(1) > > to enable debugging. Save the file, and send a message to the > problematic list. Debugging output (i.e. a transcript of the entire > SMTP dialogue) should now be in ~mailman/logs/error. Remember to > remove the debugging line again afterwards. Ok, I put that in there, and debugging shows up in other places, but not in that error log. Anyway, I had changed one of the user's settings to digest, so he would at least get the list messages. Then when I was going to do the above test, I changed him back to regular to see what happened, when he showed up in the recipient list. I did the same for another user that was being ignored, (change to digest and back to regular) and now he is getting mail too. I don't know what was going on there, but it appeared to be reproducible. Earlier, I had removed and re-added them to the list, but that did nothing. Thanks for the help, Harald. I don't think that was a solution, but I appreciate your efforts. Jerry A. From claw@under.engr.sgi.com Mon Feb 8 23:38:19 1999 From: claw@under.engr.sgi.com (J C Lawrence) Date: Mon, 08 Feb 1999 15:38:19 -0800 Subject: [Mailman-Developers] Moderation comment interface change In-Reply-To: Message from "Christopher G. Petrilli" of "Mon, 08 Feb 1999 14:41:55 EST." <19990208144155.44235@amber.org> Message-ID: <199902082338.PAA77950@under.engr.sgi.com> On Mon, 8 Feb 1999 14:41:55 -0500 Christopher G Petrilli wrote: > On Mon, Feb 08, 1999 at 11:24:18AM -0800, J C Lawrence wrote: >>> Well, the other option is PMDF style (4 0x001 characters at the >>> beginning of the line). >> >> True, tho its been quite a while since I've run into that one. > Oh you'd be amazed how often I run into it... MMDF/PMDF live :-) I'll make no comment on elisp based MUA's. > Actually, it's not a bad format, probably better than all the > others, and well "documented" in elisp. True, and that'a a major strength. >>> THe big problem with using MH-style is that it can become a >>> HUGE HUGE HUGE disk hog... >> >> I have a little over a million and a half messages in MH folders >> right now, and yes, they chew disk space. Disk however is cheap. > Cheap yes, but still, I don't know that I want to waste it like > this unless there's no other solution. This is why you have options, such as the _option_ to save MH folders. >> Need a MHonArc analogue that will run against MySQL. > You mean a user interface? :-) Of course... There are multiple possible definitions of UI in that sentence. I see two main approaches: A patch to MHonArc to read from MySQL A MHonArc analogue that will dynamically generate pages at request time from a MySQL database. The first is the easiest and has all the prior art behind it. The second is the nominally "better" approach but is a significant engineering efffort. >> Need a decent search tool (I use WebGlimpse, but HT://Dig isn't >> too bad) that will run against the results. > THis is the second problem... I've been thinking about it... I > don't know of any text-indexer (ie inverted indeces) that is > designed to be programatically driven, rather than > stand-alone... Agreed. > I want something that can do all it's indexing, but be driven from > the unified interface, not from some secondary interface... know > what I mean? Yup. Need something that will index the DB contents and derive appropriate URLs for the data found, rather than running thru the presentation_interface/web server to access the data and bind them to URLs. Its a genericy vs effort issue. Good search tools are not trivial. -- J C Lawrence Internet: claw@kanga.nu (Contractor) Internet: coder@kanga.nu ---------(*) Internet: claw@under.engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From petrilli@amber.org Tue Feb 9 00:49:09 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Mon, 8 Feb 1999 19:49:09 -0500 Subject: [Mailman-Developers] Moderation comment interface change In-Reply-To: <199902082338.PAA77950@under.engr.sgi.com>; from J C Lawrence on Mon, Feb 08, 1999 at 03:38:19PM -0800 References: <199902082338.PAA77950@under.engr.sgi.com> Message-ID: <19990208194909.04359@amber.org> On Mon, Feb 08, 1999 at 03:38:19PM -0800, J C Lawrence wrote: > On Mon, 8 Feb 1999 14:41:55 -0500 > Christopher G Petrilli wrote: > > > [I make a comment about BABYL] > > Actually, it's not a bad format, probably better than all the > > others, and well "documented" in elisp. > > True, and that'a a major strength. Yup, and I've never had a problem with it not finding the message start/end correctly. I suspect it's about as bulletproof as any non-database/singel-file solution can be! > >> I have a little over a million and a half messages in MH folders > >> right now, and yes, they chew disk space. Disk however is cheap. > > > Cheap yes, but still, I don't know that I want to waste it like > > this unless there's no other solution. > > This is why you have options, such as the _option_ to save MH > folders. Ok, this I can see... that would be helpful, and shouldn't be that hard to arrange, honestly... we've talked several times about having an "archive filter" that does something in a black box, but it's important to the main mailing list manager. > >> Need a MHonArc analogue that will run against MySQL. > > > You mean a user interface? :-) Of course... > > There are multiple possible definitions of UI in that sentence. > I see two main approaches: > > A patch to MHonArc to read from MySQL Ick, but that's just me... I have allergic reactions to all things related to Perl.. but that's just me. I just took a look at MHonArc, and it's not bad, honestly... thoguh the interface needs a lot of work. > A MHonArc analogue that will dynamically generate pages at request > time from a MySQL database. This is more what I have in mind... I have the following goals, personally, when I'm thining through this. * NO static HTML pages, everything is dynamically generated (Zpublisher?) * Full-text query of messages * Intellegent MIME handling (MHonArc gets this almost right) * Moderator "commenting" of messages (more on this later) * Intellegent queries based on header information > The first is the easiest and has all the prior art behind it. The > second is the nominally "better" approach but is a significant > engineering efffort. Well, I'm not sure how much it is.. .the full-text is the hard part, but that's mostly because of the problem I outlined below... I do know Digital Creations has an inverted text indexer, just not sure of the license status of it... supposedly it's BLINDINGLY fast... They said some comment about 1M record databse being searched in under 1 second. > > I want something that can do all it's indexing, but be driven from > > the unified interface, not from some secondary interface... know > > what I mean? > > Yup. Need something that will index the DB contents and derive > appropriate URLs for the data found, rather than running thru the > presentation_interface/web server to access the data and bind them > to URLs. THere's the rub... one of the problems i've had doing threading of archives has been the fact that a few mail systems don't insert Message-Id: correctly or consistently. BAH! EVIL BASTARDS! :-) This is what I would use to indentify things in the database (the primary key). > Its a genericy vs effort issue. Good search tools are not trivial. No, though they seem to be reinvented constantly :-) Hehehe... I wonder how good the API to WAIS is. Chris -- | Christopher Petrilli | petrilli@amber.org From claw@under.engr.sgi.com Tue Feb 9 01:28:35 1999 From: claw@under.engr.sgi.com (J C Lawrence) Date: Mon, 08 Feb 1999 17:28:35 -0800 Subject: [Mailman-Developers] Moderation comment interface change In-Reply-To: Message from "Christopher G. Petrilli" of "Mon, 08 Feb 1999 19:49:09 EST." <19990208194909.04359@amber.org> Message-ID: <199902090128.RAA78140@under.engr.sgi.com> On Mon, 8 Feb 1999 19:49:09 -0500 Christopher G Petrilli wrote: > On Mon, Feb 08, 1999 at 03:38:19PM -0800, J C Lawrence wrote: >> On Mon, 8 Feb 1999 14:41:55 -0500 Christopher G >> Petrilli wrote: >>> Actually, it's not a bad format, probably better than all the >>> others, and well "documented" in elisp. >> >> True, and that'a a major strength. > > Yup, and I've never had a problem with it not finding the message > start/end correctly. I suspect it's about as bulletproof as any > non-database/singel-file solution can be! Quite. FWLIW FIDO used a not-dissimilar format. >> This is why you have options, such as the _option_ to save MH >> folders. > Ok, this I can see... that would be helpful, and shouldn't be that > hard to arrange, honestly... we've talked several times about > having an "archive filter" that does something in a black box, but > it's important to the main mailing list manager. Aye. I'm tempted to hack it in myself but I don't really have a feel for the flow of the base design of MailMan right now (and my Python skills are a little rusty). >>>> Need a MHonArc analogue that will run against MySQL. >>> >>> You mean a user interface? :-) Of course... >> >> I see two main approaches: >> >> A patch to MHonArc to read from MySQL > > Ick, but that's just me... I have allergic reactions to all things > related to Perl.. but that's just me. Ditto. > I just took a look at MHonArc, and it's not bad, > honestly... thoguh the interface needs a lot of work. It works and it works well. It delivers well proven and well known results for hundreds of thousands of messages a day. While I may quibble about the design and implementation of the product (it has great big hoary wary fugly bits), there's not a whole lot I can argue with the job it does (I use it here across a half dozen lists and a couple hundred thousand archives posts). >> A MHonArc analogue that will dynamically generate pages at >> request time from a MySQL database. > This is more what I have in mind... Its also a significant engineering effort with a _long_ test and burn in period behind it. This is human-sourced data with Microsoft seasoning: Expect to spend 90% of your time figuring out how to handle 3% of the weird exceptions. It is also of course the "One True Way". I just don't think its really worth the effort right now. > I have the following goals, personally, when I'm thining through > this. > * NO static HTML pages, everything is dynamically generated > (Zpublisher?) * Full-text query of messages * Intellegent MIME > handling (MHonArc gets this almost right) * Moderator "commenting" > of messages (more on this later) * Intellegent queries based on > header information I'm currently playing about with having MHonArc generate pages which contain a PHP3 blob referencing a DB entry which contains web-browser annotations and list-owner comments (cf PHP's own annotated manual). It looks like a workable idea that could actually be fairly useful. >> The first is the easiest and has all the prior art behind it. >> The second is the nominally "better" approach but is a >> significant engineering efffort. > Well, I'm not sure how much it is... MHonArc has taken a whole lot of time to get where it is today, and that's not for lack of effort or much due to bad design principles in the early efforts. Its mostly due to the fact that its a nasty nut to crack. >> Yup. Need something that will index the DB contents and derive >> appropriate URLs for the data found, rather than running thru the >> presentation_interface/web server to access the data and bind >> them to URLs. > THere's the rub... one of the problems i've had doing threading of > archives has been the fact that a few mail systems don't insert > Message-Id: correctly or consistently. BAH! EVIL BASTARDS! :-) Quite. I approve of MHonArc's approach: silently ignore duplicate and missing MessageID's. A slightly better approach would be to pseudo-generate MessageID's for messages which miss them (say a simple hash function of the message body), and then only ignore duplicate hashes, but its a very small gain for a very small impact problem. -- J C Lawrence Internet: claw@kanga.nu (Contractor) Internet: coder@kanga.nu ---------(*) Internet: claw@under.engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From petrilli@amber.org Tue Feb 9 01:43:13 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Mon, 8 Feb 1999 20:43:13 -0500 Subject: [Mailman-Developers] Moderation comment interface change In-Reply-To: <199902090128.RAA78140@under.engr.sgi.com>; from J C Lawrence on Mon, Feb 08, 1999 at 05:28:35PM -0800 References: <199902090128.RAA78140@under.engr.sgi.com> Message-ID: <19990208204313.05795@amber.org> On Mon, Feb 08, 1999 at 05:28:35PM -0800, J C Lawrence wrote: > > [discussion of BABYL] > > Yup, and I've never had a problem with it not finding the message > > start/end correctly. I suspect it's about as bulletproof as any > > non-database/singel-file solution can be! > > Quite. FWLIW FIDO used a not-dissimilar format. So this might be one format to talk to---I need to look at extending Python's built in libraries to support this format on top of the existing ones... though it does need more features, it'd at least have the basics. > > Ok, this I can see... that would be helpful, and shouldn't be that > > hard to arrange, honestly... we've talked several times about > > having an "archive filter" that does something in a black box, but > > it's important to the main mailing list manager. > > Aye. I'm tempted to hack it in myself but I don't really have a > feel for the flow of the base design of MailMan right now (and my > Python skills are a little rusty). I've got the Python stuff pretty well in hand, but it's the flow of Mailman that makes my brain hurt :-) I've not really tried to understand it yet, since I've been hacking up the parser for Zope for a while... and after looking at a parser for a couple weeks, the rest just looks too foofooie :-) > Its also a significant engineering effort with a _long_ test and > burn in period behind it. This is human-sourced data with Microsoft > seasoning: Expect to spend 90% of your time figuring out how to > handle 3% of the weird exceptions. Well, if you keep the features to a minimum it's easier :-) Part of the problem SOME software companies have with debugging is that they add new features during teh debug cycle, and add features nobody uses---so of course nobody breaks them, until they do something to totally unrelated :-) > I'm currently playing about with having MHonArc generate pages which > contain a PHP3 blob referencing a DB entry which contains > web-browser annotations and list-owner comments (cf PHP's own > annotated manual). It looks like a workable idea that could > actually be fairly useful. My fear of such solutions is that it becomes more and more complex to debug sshould it break... but that's just me, and only me. > Quite. I approve of MHonArc's approach: silently ignore duplicate > and missing MessageID's. A slightly better approach would be to > pseudo-generate MessageID's for messages which miss them (say a > simple hash function of the message body), and then only ignore > duplicate hashes, but its a very small gain for a very small impact > problem. This is a difficult issue, and I don't agree with "silently ignoring" anything... always note it in the archives... that's my problem with editable archives... then again I just got done dealing with evidentiary problems with security audit trails :-) Chris -- | Christopher Petrilli | petrilli@amber.org From bence@intercom.hu Tue Feb 9 10:52:37 1999 From: bence@intercom.hu (Hermann Benedek) Date: Tue, 9 Feb 1999 11:52:37 +0100 Subject: [Mailman-Developers] What happened? Message-ID: The list received a lot of messages like this: (sorry about the big header, but perhaps it contains some useful information) **************************************************************************** ***8 From Harald.Meland@usit.uio.no Tue Feb 9 12:43:33 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 09 Feb 1999 13:43:33 +0100 Subject: [Mailman-Developers] subscribers being ignored In-Reply-To: Jerry Adlersfluegel's message of "Mon, 08 Feb 1999 15:12:25 -0600" References: <36BEF7AE.EA1B8631@fastrans.net> <36BF5339.F892EEE5@fastrans.net> Message-ID: [Jerry Adlersfluegel] > Harald Meland wrote: > > Just under the "conn = ..." line, insert > > > > conn.set_debuglevel(1) > > > > to enable debugging. Save the file, and send a message to the > > problematic list. Debugging output (i.e. a transcript of the entire > > SMTP dialogue) should now be in ~mailman/logs/error. Remember to > > remove the debugging line again afterwards. > > Ok, I put that in there, and debugging shows up in other places, but not > in that error log. OK, so I might have guessed wrong about the location of the resulting log file :) > Anyway, I had changed one of the user's settings to digest, so he would > at least get the list messages. Then when I was going to do the above > test, I changed him back to regular to see what happened, when he showed > up in the recipient list. I did the same for another user that was being > ignored, (change to digest and back to regular) and now he is getting > mail too. I don't know what was going on there, but it appeared to be > reproducible. Earlier, I had removed and re-added them to the list, but > that did nothing. Odd -- Internally, changing to digest only moves the address from the `members' dict to the `digest_members' dict, and reversing the change reverses the move. > Thanks for the help, Harald. I don't think that was a solution, but > I appreciate your efforts. If this really is unrelated to your MTA, then the output of the following commands might prove helpful in debugging (should you encounter the problem again): $ cd ~mailman $ python Python 1.5.1 (#1, Oct 9 1998, 15:23:54) [C] on sunos5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from Mailman import MailList >>> import pprint >>> list = MailList.MailList("PROBLEM_LIST_NAME", lock=0) >>> pprint.pprint(list.__dict__) Substitute the name of the problematic list name for PROBLEM_LIST_NAME. -- Harald From Harald.Meland@usit.uio.no Tue Feb 9 19:51:20 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 09 Feb 1999 20:51:20 +0100 Subject: [Mailman-Developers] What happened? In-Reply-To: Hermann Benedek's message of "Tue, 9 Feb 1999 11:52:37 +0100" References: Message-ID: [Hermann Benedek] > The list received a lot of messages like this: [...] > Received: from MAILQUEUE by UZEM_1 (Mercury 1.21); 9 Feb 99 10:20:35 GMT+1 > From: "Cseh Miklos" As I couldn't find any hints in the original message that should have spurred any DSN (Delivery Status Notification), are you sure it's not the guys sending the replies that are at fault? I have on occasion encountered mail setups/clients that send me "delivery status notification" _regardless_ of whether I want it or not (and I don't :). Sometimes this is something that users have turned on themselves, and sometimes it's turned on for all users by the local admin (presumably because "it sounded neat"). What suprises me, though, is that the notifications are sent to the _list_ address, which only appeared in the "To:" header of the original message. Granted, I would not at all be surprised if such broken setups _also_ didn't care whether or not Reply-To: was set (which it apparently doesn't)... but sending delivery notification to the To: address? That's a new one to me. BTW, I thought DSN was something that was propagated through optional flags to certain SMTP commands, and not in the message (body or headers) itself -- cf RFC1891. Thus Mailman would essentially strip any DSN requests from a message before delivering a copy of it to the list members (because the envelope of the Mailman-originating message is _completely_ new, and not influenced by the original envelope in any way). > What is this? I'm filtering the "RCPT:" e-mails now.... If I'm guessing right, you'll either have to do some pretty aggressive filtering, or convince those of your members who send "I have now read your mail" messages to *stop* doing so (or at least don't send them to the To: header address). If none of these "solutions" work, there is one final (and very tempting, if I may say so :) option: Simply unsubscribe the offending members until they learn to behave. Good luck, -- Harald From gstein@lyra.org Wed Feb 10 01:01:01 1999 From: gstein@lyra.org (Greg Stein) Date: Tue, 09 Feb 1999 17:01:01 -0800 Subject: [Mailman-Developers] [Fwd: Re: [Mailman-Users] Messages silently disappearing] Message-ID: <36C0DA4D.34B58873@lyra.org> Screwed up privs seems to happen a lot. Sure, maybe the person installed improperly. But if it is simply permissions, then it should be easily rectifiable. Wasn't there a script or something to check the permissions? I couldn't find it. Would be nice to have one. Regardless, I might recommend a web page or other document that has a detailed listing of owner/group/privs for the relevant directories and files. thx -g Wes Morriston wrote: > > I did as you suggested. All the directories in /home/mailman are now > owned by mailman and all have the g+s setting. I took the +s off of > /usr/bin/python. The result? Messages silently disappear as before. > Put the +s back on python, and they don't disappear. > > Something clearly has the wrong ownership and/or permissions, but I just > don't know what! > > Frustrated, > > Wes > > Christopher Lindsey wrote: > > > > > drwxrwsr-x 2 root mailman 512 Feb 9 17:37 data > > > > > > That is exactly how mailman installed itself. (I was root when I did > > > the install.) > > > > Yes, I had the same problem. > > > > > I then did a > > > > > > chown -R mailman . > > > > > > in /home/mailman. > > > > This will probably unset the g+s setting on all directories. You > > need to set it back: > > > > cd ~mailman > > chown -R mailman.mailman . > > find . -type d -exec chmod g+s {} \; > > > > > The following, I discovered, does cause the messages to be delivered. > > > > > > chmod +s /usr/bin/python > > > > > > I hope it is not too dangerous to run python as root. > > > > Ummm, I would undo that. > > > > Chris > > > > ------------------------------------------------------ > > Mailman-Users maillist - Mailman-Users@python.org > > http://www.python.org/mailman/listinfo/mailman-users > > ------------------------------------------------------ > Mailman-Users maillist - Mailman-Users@python.org > http://www.python.org/mailman/listinfo/mailman-users -- Greg Stein, http://www.lyra.org/ From dan@feld.cvut.cz Wed Feb 10 12:46:38 1999 From: dan@feld.cvut.cz (Dan Ohnesorg, admin of POWER) Date: Wed, 10 Feb 1999 13:46:38 +0100 Subject: [Mailman-Developers] What happened? In-Reply-To: References: Hermann Benedek's message of "Tue, 9 Feb 1999 11:52:37 +0100" Message-ID: <199902101247.NAA26988@poli.feld.cvut.cz> On 9 Feb 99, at 20:51, Harald Meland wrote: > > Received: from MAILQUEUE by UZEM_1 (Mercury 1.21); 9 Feb 99 10:20:35 > > GMT+1 From: "Cseh Miklos" Mercury requires errors-to: headers for returnig messages to postmaster. BTW 1.21 is quite old and buggy. Currently exists 1.44 > > What is this? I'm filtering the "RCPT:" e-mails now.... Best is to use my patch, which filters headers in messages on mailman listserv and removes requests for reading a confirmation. It solves problem with pmail and microsoft clietnts. I will send this patch later. It is better to remove this request from message then filter returned confirmations. 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 ________________________________________ Ne zihadla, ale med prinesl vcelam slavu. From gstein@lyra.org Wed Feb 10 13:08:11 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 10 Feb 1999 05:08:11 -0800 Subject: [Mailman-Developers] make update Message-ID: <36C184BA.3A683F1F@lyra.org> I updated a 1.0b6 install to 1.0b8. Seems to have worked fine (great job!). The upgrade script issued some "errors" though, which it really shouldn't have. Specifically, here is a snapshot: Updating mailing list: p2c-dev - updating old private mbox file looks like you have a really recent CVS installation... you're either one brave soul, or you already ran me - updating old public mbox file looks like you have a really recent CVS installation... you're either one brave soul, or you already ran me I never used a CVS snapshot. Looking at the code, I believe it doesn't recognize the fact that this came from 1.0b6 (i.e. recent versions) and just assumed it was a CVS version. Anyhow: it could throw somebody off if they weren't expecting it, so I'd recommend some kind of change -- alter the text, suppress it, etc. thx -g -- Greg Stein, http://www.lyra.org/ From Fred L. Drake, Jr." --b0glBXVDs2 Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit I don't know if this would be interesting to you guys... -Fred --b0glBXVDs2 Content-Type: message/rfc822 Content-Description: forwarded message Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart content-length: 2631 Return-Path: Received: from cnri.reston.va.us by weyr.cnri.reston.va.us (SMI-8.6/SMI-SVR4) id VAA29902; Tue, 9 Feb 1999 21:15:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by cnri.reston.va.us (8.9.1a/8.9.1) with ESMTP id VAA15676; Tue, 9 Feb 1999 21:15:08 -0500 (EST) Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id RAA00102 for ietf-123-outbound.10@ietf.org; Tue, 9 Feb 1999 17:15:01 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA00074 for ; Tue, 9 Feb 1999 17:12:49 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id OAA00684; Tue, 9 Feb 1999 14:12:49 -0800 (PST) Message-Id: <199902092212.OAA00684@boreas.isi.edu> From: RFC Editor To: IETF-Announce:;@ietf.org Cc: rfc-ed@ISI.EDU Subject: BCP 30, RFC 2505 on Anti-Spam Recommendations Date: Tue, 09 Feb 1999 14:12:49 -0800 --NextPart A new Request for Comments is now available in online RFC libraries. BCP 30: RFC 2505: Title: Anti-Spam Recommendations for SMTP MTAs Author(s): G. Lindberg Status: Best Current Practice Date: February 1999 Mailbox: lindberg@cdg.chalmers.se Pages: 24 Characters: 53597 Updates/Obsoletes/See Also: None I-D Tag: draft-lindberg-anti-spam-mta-08.txt URL: ftp://ftp.isi.edu/in-notes/rfc2505.txt This memo gives a number of implementation recommendations for SMTP, MTAs (Mail Transfer Agents, e.g. sendmail) to make them more capable of reducing the impact of spam. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <990209141051.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2505 --OtherAccess Content-Type: Message/External-body; name="rfc2505.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <990209141051.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- --b0glBXVDs2-- From liam@numenet.com Wed Feb 10 22:52:37 1999 From: liam@numenet.com (Liam Kirsher) Date: Wed, 10 Feb 1999 14:52:37 -0800 Subject: [Mailman-Developers] Possible bug in 1.0b8 Message-ID: <36C20DB4.9D6D4471@numenet.com> Hi, I don't know Python, so it's a little hard to tell what's going on. I think this is an undocumented feature, however. We changed the cgi name from mailman to newsletter, and so the url was incorrect. This caused the login process to fail because the url was incorrect. I found the problelm in Cgi/admindb.py, line 116 the reference to /mailman/admindb/ was a problem. I think the "mailman" part should be gotten from the DEFAULT_URL, perhaps? I just inserted what it needed to be ("newsletter"), but you might want to fix it for the future releases. Liam -- <-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-> Liam Kirsher VOICE: 415-456-6822 Numenet, Inc. FAX: 415-453-7876 775 E. Blithedale Ave. #176 EMAIL: liam@numenet.com Mill Valley, CA 94941 PGP: http://www.numenet.com/~liam/pgp_public_key.txt From Benjamin B. Thomas" Has anyone noticed that the last archived message to the mailman-checkins list (http://www.python.org/pipermail/mailman-checkins/) is from November? (BTW: The project looks really nice! I'm considering switching over from my current majordomo + (wilma/glimpse) + custom hacked news2mail<->mail2news gateway when I get through with some other other pressing projects.) Cheers, benjy 1975 Cahaba Valley Road (205) 988-5925 Indian Springs, AL 35124 benjy@alum.mit.edu From gstein@lyra.org Thu Feb 11 00:00:19 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 10 Feb 1999 16:00:19 -0800 Subject: [Mailman-Developers] [Fwd: Re: [Mailman-Users] NameError : recipients] Message-ID: <36C21D93.7245446@lyra.org> Greg Stein wrote: > > Scott A. McIntyre wrote: > > > > Thanks to Harald, I figured out my WANTED vs GOT and ended up letting > > mailman run with the GID it GOT and that seems to be much closer to > > being happy. However, now, whenever I post, I get the following in the > > error log: > > > > Feb 10 14:48:56 1999 post: Traceback (innermost last): > > post: File "/usr/people/mailman/scripts/post", line 65, in ? > > post: current_list.Post(msg) > > post: File "/usr/people/mailman/Mailman/MailList.py", line 1143, in > > Post > > post: recipients.remove(members) > > post: NameError : recipients > > This is a bug in Mailman 1.0b8. It has incorrect code for processing > "Don't Receive Own Posts". Turn that off, and it should work okay. I moved a block of lines in MailList.py down below the construction of the recipients list. It also appeared there was a bug in there that attempted to remove "members" rather than "sender". The final code looks like: # Try to get the address the list thinks this sender is sender = self.FindUser(msg.GetSender()) if sender: if self.GetUserOption(sender, mm_cfg.DontReceiveOwnPosts): dont_send_to_sender = 1 if self.GetUserOption(sender, mm_cfg.AcknowlegePosts): ack_post = 1 # Deliver the mail. members = self.GetDeliveryMembers() recipients = [] for m in members: if not self.GetUserOption(m, mm_cfg.DisableDelivery): recipients.append(m) if dont_send_to_sender: try: recipients.remove(sender) # # sender not in list (case sensitive username problem?) # except ValueError: self.LogMsg("error", "couldn't remove %s from recipient list: %s", sender, str(members)) self.LogMsg("post", "post to %s from %s size=%d", self._internal_name, msg.GetSender(), len(msg.body)) Cheers, -g -- Greg Stein, http://www.lyra.org/ From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Feb 11 15:47:48 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 11 Feb 1999 10:47:48 -0500 (EST) Subject: [Mailman-Developers] Stale mailman-checkins archive References: <199902102324.RAA19721@mail.indiansprings.org> Message-ID: <14018.64420.132327.818689@anthem.cnri.reston.va.us> >>>>> "BBT" == Benjamin B Thomas writes: BBT> Has anyone noticed that the last archived message to the BBT> mailman-checkins list BBT> (http://www.python.org/pipermail/mailman-checkins/) is from BBT> November? Yes, we deliberately turned off the archives to conserve disk space. All that information is available via CVS anyway. BBT> (BTW: The project looks really nice! I'm considering BBT> switching over from my current majordomo + (wilma/glimpse) + BBT> custom hacked news2mail<->mail2news gateway when I get BBT> through with some other other pressing projects.) Excellent! -Barry From lindsey@ncsa.uiuc.edu Fri Feb 12 04:08:05 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Thu, 11 Feb 1999 22:08:05 -0600 (CST) Subject: [Mailman-Developers] Problems with '+' addressing Message-ID: <199902120408.WAA24173@ferret.ncsa.uiuc.edu> I have several people subscribing to my lists with plus addressing (i.e. lindsey+mhonarc@ncsa.uiuc.edu (in fact, I'm subscribed to this list in the same way)). This breaks the "Restrict Posting to List Members" option for these accounts... What I'm trying to do is check for the existence of a '+' in each address in the list of subscribers, and if present, trim it and everything to the right off before checking for a match. Unfortunately, it appears that FindMatchingAddresses (called from MailList.FindUser) is just passed a dictionary of list members. Implementing the kind of check that I'd like would significantly slow down checking for matches because it couldn't just use the poster's address as a key anymore. So what's the best way to do this? Do a foreach on each key and check for a match? Like I said, it's slower, but it sure opens up a lot of possibilities. You could then do things like add regular expressions to the list of accepted posters... /.*\.example\.com/ would allow postings from anyone in a given domain (not something I would recommend), /george@example\.(org|com|net)/ would pull three lines together into one, etc. Not terribly useful, but what if you were to incorporate '+' addressing checks through regexes too then? Create a macro like :USER: and :DOMAIN: that would be used in the regex (colons are used since they can't be part of an address according to RFC 822)... Then you would have a regex like /:USER:\+[^@]*@:DOMAIN:/ :USER: and :DOMAIN: would be derived from the current poster, and each entry within the list of subscribers would be compared against the resulting regular expression (one at a time). I think that something like the '+' addressing check would be best served internally within Mailman (via a checkbox or whatever), but once the engine is in place it's a lot more extensible. Comments? I'm willing to mess with this (although I can't guarantee any great speed -- I just started messing with Python a couple of days ago). Chris From gstein@lyra.org Fri Feb 12 20:00:39 1999 From: gstein@lyra.org (Greg Stein) Date: Fri, 12 Feb 1999 12:00:39 -0800 Subject: [Mailman-Developers] change request: admin password changing Message-ID: <36C48867.3E677BDF@lyra.org> small change request: remove that dang password-change dialog from every screen I don't see a need to have it on *every* screen. It seems awfully redundant, and just ends up cluttering the other screens. -g -- Greg Stein, http://www.lyra.org/ From liam@numenet.com Tue Feb 16 23:54:48 1999 From: liam@numenet.com (Liam Kirsher) Date: Tue, 16 Feb 1999 15:54:48 -0800 Subject: [Mailman-Developers] Help with run_queue problem? Message-ID: <36CA0548.2BE4746@numenet.com> Hi, Can anyone help with this? I'm getting the following error when run_queue is executed, whether by cron or from the command line. Everything else seems to be working fine. Thanks in advance, Liam ------------------------------------------------------ Your "cron" job on ns1 /usr/local/bin/python /usr/local/etc/mailman/cron/run_queue produced the following output: Traceback (innermost last): File "/usr/local/etc/mailman/cron/run_queue", line 31, in ? OutgoingQueue.processQueue() File "/usr/local/etc/mailman/Mailman/OutgoingQueue.py", line 119, in processQu eue recip,sender,text = marshal.load(f) EOFError: EOF read where object expected -- <-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-> Liam Kirsher VOICE: 415-456-6822 Numenet, Inc. FAX: 415-453-7876 775 E. Blithedale Ave. #176 EMAIL: liam@numenet.com Mill Valley, CA 94941 PGP: http://www.numenet.com/~liam/pgp_public_key.txt From ayu1@nycap.rr.com Fri Feb 19 04:00:15 1999 From: ayu1@nycap.rr.com (Alex Yu) Date: Thu, 18 Feb 1999 23:00:15 -0500 Subject: [Mailman-Developers] Can anyone get MailMan running under Kernel w/ secure_linux patched? Message-ID: <36CCE1CF.12E53BD9@nycap.rr.com> Hello, I have problem w/ Mailman under Kernel 3.0.36 w/ secure_linux (ftp://ftp.false.com/pub/secure). I compiled the kernel with these options, Non-executable user stack area Restricted links in /tmp Restricted pipes in /tmp Restricted /proc So when I tried to update options on the web, I got error message as listed below. Can anyone fix? ---[START]------[START]---Bug in Mailman version 1.0b8 Traceback: Traceback (innermost last): File "/usr/local/mailman/scripts/driver", line 112, in run_main main() File "/usr/local/mailman/Mailman/Cgi/admin.py", line 170, in main ChangeOptions(lst, category, cgi_data, doc) File "/usr/local/mailman/Mailman/Cgi/admin.py", line 849, in ChangeOptions lst.Save() File "/usr/local/mailman/Mailman/MailList.py", line 683, in Save file = aside_new(fname, fname_last, reopen=1) File "/usr/local/mailman/Mailman/MailList.py", line 1211, in aside_new os.link(old_name, new_name) OSError: [Errno 1] Operation not permitted ---[end]--- -- best regards, alex.Yu From prew@prew2.matav.hu Fri Feb 19 14:10:50 1999 From: prew@prew2.matav.hu (Csanaki Csaba) Date: Fri, 19 Feb 1999 15:10:50 +0100 Subject: [Mailman-Developers] MailMan Bug :( Message-ID: <36CD70E9.38576EA9@mail.matav.hu> Bug in Mailman version 1.0b8 We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (innermost last): File "/home/mailman/scripts/driver", line 85, in run_main logger = StampedLogger('error', File "/home/mailman/Mailman/Logging/StampedLogger.py", line 48, in __init__ Logger.__init__(self, category, nofail, immediate) File "/home/mailman/Mailman/Logging/Logger.py", line 40, in __init__ self.__get_f() File "/home/mailman/Mailman/Logging/Logger.py", line 63, in __get_f reraise() File "/home/mailman/Mailman/Logging/Logger.py", line 55, in __get_f f = self.__fp = open(self.__filename, 'a+') IOError: (13, 'Permission denied') ---- I installed mailman, but this don't work :( Prew --------------------------------------------------- mailto:prew@prew2.matav.hu http://prew2.matav.hu ICQ:6384302 From stu@ekins.net Fri Feb 19 16:52:56 1999 From: stu@ekins.net (Stu Ekins) Date: Fri, 19 Feb 1999 16:52:56 -0000 Subject: [Mailman-Developers] MailMan Bug :( In-Reply-To: <36CD70E9.38576EA9@mail.matav.hu> Message-ID: <001301be5c28$4d2e9be0$6701a8c0@lisa98.ekins.net> > Bug in Mailman version 1.0b8 > > We're sorry, we hit a bug! ~ > IOError: (13, 'Permission denied') > > ---- > > I installed mailman, but this don't work :( > Well, I think the permission denied gives it away a little. Make sure you've got the permissions on all your /home/mailman (or wherever) files correct, according to the installation guide (don't rely on make install). Pay particular attention to the log directory. Stu. From vic@vgg.sci.uma.es Fri Feb 19 17:06:25 1999 From: vic@vgg.sci.uma.es (Victoriano Giralt) Date: Fri, 19 Feb 1999 18:06:25 +0100 (MET) Subject: [Mailman-Developers] MailMan Bug :( In-Reply-To: <36CD70E9.38576EA9@mail.matav.hu> Message-ID: On Fri, 19 Feb 1999, Csanaki Csaba wrote: > Bug in Mailman version 1.0b8 Not really ;) > > > File "/home/mailman/Mailman/Logging/Logger.py", line 55, in __get_f > f = self.__fp = open(self.__filename, 'a+') > IOError: (13, 'Permission denied') Check the ownership of the mailman files, they should have the same group as mailman does, and the directories should have the group setuid set (rws). The group is the same as the wrappers' -- Victoriano Giralt Systems Programmer Central Computing Facility University of Málaga SPAIN From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Feb 19 20:09:26 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 19 Feb 1999 15:09:26 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] Messages silently disappearing References: Message-ID: <14029.50422.195466.277100@anthem.cnri.reston.va.us> --H+5YPag/8T Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Thanks to Wes Morriston for giving me access to his Linux machine, I have diagnosed the problem he and Edward Marshall were having. I don't have a better solution than the one Wes came up with, so I'm posting this followup here to see if anybody has any ideas. The problem in a nutshell: on some Linux boxes, the effective group id is not preserved across a popen() call. Here's essentially the chain when a message is posted to a list: 1. The mail wrapper is invoked by the MDA. Mailman's wrapper is a setgid C program, that should change the egid to `mailman', then exec scripts/post. 2. scripts/post also has egid `mailman' and it goes about the business of checking that the message can be posted. Eventually, it is going to popen() scripts/deliver and start pumping it data. scripts/deliver in turn popens scripts/contact_transport, but it doesn't matter because by then the damage is done. Now, on both my Solaris 2.6 box and my RH5.1 box, scripts/deliver will inherit the egid of the invoking process, i.e. gid `mailman'. So by setting ~mailman/data to be g+w and group owned by mailman, everything's cool. However on Wes' SuSE machine, scripts/deliver runs with its egid reset to the real gid. This breaks mailman because the real gid isn't `mailman' and thus the process does not have permission to write into the ~mailman/data directory. Because the process is owned by daemon, Wes' solution of chown'ing ~mailman/data to daemon got this working again. I'm at a loss as to what the right solution is. Wes', while it works, doesn't seem ultimately right. But I have no idea how to force the egid of scripts/deliver to `mailman'. I don't believe you can have setgid scripts on Linux (I tried this, and no it did not work). Another solution would be to wrap scripts/deliver and probably scripts/contact_transport in C setgid wrappers, but that seems like a PITA. Is there some Linux option that we can exploit to allow this? Does anybody else have any better ideas? I am attaching a tarball of code that you can use to test whether your machine has the problem. To run this, compile wrapper.c, then chgrp it to some other group and chmod it to g+s. Also make sure wrapper-2.py is executable. Now run wrapper. If you see that wrapper, wrapper-1 and wrapper-2 all have the same egid, then you're okay. If wrapper-2 reverts to the real gid, then you'll get nailed by this. I'm guessing that because Stevens [APitUE] suggests that what we're doing may open up a security hole, some versions of Linux disallow this by reverting the egid on a popen(). -Barry --H+5YPag/8T Content-Type: application/octet-stream Content-Disposition: attachment; filename="linux.tgz" Content-Transfer-Encoding: base64 H4sIAEvEzTYAA+1WW2vbMBTOs36FllFsj8T3CyTrnjbGoGww2FPbB8dRYjFHMrKdS0v++45k J2nStJQRb9Dme7DkT0c6Rz76jpxRVi2tTquwbd+OogBa27XDULZOFNiy3aADfOh5vmv7HvCO GwRhJ2g3rBpVUcYCXI4WsSjixZN2TNBn11Hb8LebOnWYbSFT+V+IOM+JMJNWfNiODen1n8y/ H7lN/r3ICRyZf9+3wa6VaA7wxvP/nrIkq8YEfyzKMeVm+glRVuJZTJluoHuEAUkaiw84FtP5 9S2+xPfdfFWmnHV7uLs5OPkK3r7/urpaD9UUuQZ82LIqhkgRuQBqom8mDPDPr98+X+KLcQ9/ aXo3csUpKad0rBuqR1TXOFiCLElC2dQ0za5Re6s9QWhyaJ7ruwBl0I0RnWC9NjRwva+Hi/7g eQEBNLYSZElL3WmItXoKUlaCYXuI1gj978ydBnv677uQyNP7kPp/rv57obur/26g9K/GTx/K Y7x1/b/DVlUIa0SZRdgc18pBdJZzARJeFZsuLxBSYsHa9rQcU7GGL7DOC3Mn5Pql0TJapDQj 2BkoQcHpIyBbcGPK8sNMQeKxJHXjetB3bjfCZbxUtoOtOkdg+XtXFh4GpfWU7ZFoRyuivRLd ngr7938b6n/B/e9Fu/tfjTt+6Hpn/f8DvEjozt8IfZKDsoHKeU6YrlkpnxGr+cpWIRLr8dUD ytUWmpxqLgQtia6lJMv4DdvjJoLPDqhtoIrf/g6AQZLxAqoJgiJS04NjRQM2yDjr3xHB1b3f 2J6LxRlnnPGK8Qf44J9cABIAAA== --H+5YPag/8T-- From Harald.Meland@usit.uio.no Fri Feb 19 21:29:16 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 19 Feb 1999 22:29:16 +0100 Subject: [Mailman-Developers] Re: [Mailman-Users] Messages silently disappearing In-Reply-To: "Barry A. Warsaw"'s message of "Fri, 19 Feb 1999 15:09:26 -0500 (EST)" References: <14029.50422.195466.277100@anthem.cnri.reston.va.us> Message-ID: [Barry A. Warsaw] > Thanks to Wes Morriston for giving me access to his Linux machine, I > have diagnosed the problem he and Edward Marshall were having. I > don't have a better solution than the one Wes came up with, so I'm > posting this followup here to see if anybody has any ideas. > > The problem in a nutshell: on some Linux boxes, the effective group id > is not preserved across a popen() call. [...] > I'm at a loss as to what the right solution is. I can't really see that there is any viable[1] alternative to putting setregid(getegid(), -1); somewhere in common.c:run_script() [wrapped with appropriate autoconfisms, of course]. As long as there are systems not preserving the effective GID when they ought to (IMHO), we'll have to hope that using the real GID will work better. And, I don't think that setting the real GID to the effective GID will cause trouble on other systems. [1] Starting everything via setgid C wrappers isn't viable (to me). Forcing (possibly non-privileged) Mailman users to chgrp their directories to groups they very likely aren't members of isn't viable (for them). -- Harald From gorgo@caesar.elte.hu Fri Feb 19 22:11:33 1999 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Fri, 19 Feb 1999 23:11:33 +0100 (MET) Subject: [Mailman-Developers] Can anyone get MailMan running under Kernel w/ secure_linux patched? In-Reply-To: <36CCE1CF.12E53BD9@nycap.rr.com> Message-ID: On Thu, 18 Feb 1999, Alex Yu wrote: > Hello, > > I have problem w/ Mailman under Kernel 3.0.36 w/ secure_linux > (ftp://ftp.false.com/pub/secure). I compiled the kernel with these > options, > > Non-executable user stack area > Restricted links in /tmp > Restricted pipes in /tmp > Restricted /proc > > So when I tried to update options on the web, I got error message as > listed below. I dont know if this can be solved in mailman. I commented out the restricted hardlink part in the kernel (restricted links in /tmp does not only restrict links in /tmp, but hardlinks in non +t directories) -- 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 bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Feb 19 22:37:24 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 19 Feb 1999 17:37:24 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] Messages silently disappearing References: <14029.50422.195466.277100@anthem.cnri.reston.va.us> <14027.25437.930489.27167@anthem.cnri.reston.va.us> <36CB83E3.C7B5BD4F@stripe.colorado.edu> Message-ID: <14029.59300.63271.948377@anthem.cnri.reston.va.us> >>>>> "HM" == Harald Meland writes: HM> I can't really see that there is any viable[1] alternative to HM> putting HM> setregid(getegid(), -1); HM> somewhere in common.c:run_script() [wrapped with appropriate HM> autoconfisms, of course]. HM> As long as there are systems not preserving the effective GID HM> when they ought to (IMHO), we'll have to hope that using the HM> real GID will work better. And, I don't think that setting HM> the real GID to the effective GID will cause trouble on other HM> systems. Thanks Harald, this sounds reasonable. I'm not sure what to do if autoconf detects that the system is missing a setregid() though. Right now it just doesn't get called. I suppose I'll also document all this in the FAQ. I tested this on Wes' machine with my example code, and it looks at least like the popen() process is getting the necessary gid. I did not test it with a live Mailman setup. Folks (especially Wes and Edward, and anybody else who was noticing these problems), could you please wait for my next check-in and then grab the CVS snapshot. Reset the ownership on ~mailman/data and do a re-install to see if my changes fix your problems. If you can't access the CVS repository, let me know and I'll do a beta9 release. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Feb 19 23:10:42 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 19 Feb 1999 18:10:42 -0500 (EST) Subject: [Mailman-Developers] Can anyone get MailMan running under Kernel w/ secure_linux patched? References: <36CCE1CF.12E53BD9@nycap.rr.com> Message-ID: <14029.61298.414934.744@anthem.cnri.reston.va.us> >>>>> "GM" == Gergely Madarasz writes: GM> I dont know if this can be solved in mailman. I commented out GM> the restricted hardlink part in the kernel (restricted links GM> in /tmp does not only restrict links in /tmp, but hardlinks in GM> non +t directories) Thanks. I've added this, and the popen() problem to the new FAQ.LINUX file. See the CVS snapshot. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Feb 19 23:17:31 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 19 Feb 1999 18:17:31 -0500 (EST) Subject: [Mailman-Developers] MailMan Bug :( References: <36CD70E9.38576EA9@mail.matav.hu> Message-ID: <14029.61707.620834.663210@anthem.cnri.reston.va.us> >>>>> "CC" == Csanaki Csaba <prew@mail.matav.hu> writes: CC> Bug in Mailman version 1.0b8 Did you do a fresh install, or were you upgrading from some previous version? Did the permission checks that Stu and Victoriano suggested turn up antyhing? I ask because the configure script is supposed to ensure that ~mailman has the right permissions (including g+s on the directory). On a fresh install, that should guarantee the right permissions on all the subsequent files, as long as you also follow all the installation instructions. If this isn't working we need to write more sanity checks. -Barry From stu@ekins.net Sat Feb 20 11:01:32 1999 From: stu@ekins.net (Stu Ekins) Date: Sat, 20 Feb 1999 11:01:32 -0000 Subject: [Mailman-Developers] Test Results (was Messages silently disappearing) In-Reply-To: <14029.50422.195466.277100@anthem.cnri.reston.va.us> Message-ID: <000501be5cc0$60e5c620$6701a8c0@lisa98.ekins.net> OK, taking Barry's code, here's what I came up with: [stu@super linux]$ ls -al total 11 drwxrwxr-x 2 stu stu 1024 Feb 20 10:56 . drwxr-xr-x 13 stu stu 2048 Feb 20 10:52 .. -rwxrwsr-x 1 stu mailman 4553 Feb 20 10:55 wrapper -rwxrwxr-x 1 stu stu 242 Feb 19 20:05 wrapper-2.py -rw-rw-r-- 1 stu stu 314 Feb 19 19:41 wrapper.c -rwxrwxr-x 1 stu stu 265 Feb 20 10:55 wrapper.py [stu@super linux]$ ./wrapper wrapper: RGID= 500, EGID= 527 wrapper-1: RGID= 500, EGID= 527 wrapper-2: RGID= 500, EGID= 527 wrapper-2: hello wrapper-2: from wrapper-2: wrapper-1 wrapper-2: bye [stu@super linux]$ This is using a stable Linux 2.0.34 kernel on RedHat 5.0. Any help? From gorgo@caesar.elte.hu Sun Feb 21 00:04:38 1999 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Sun, 21 Feb 1999 01:04:38 +0100 (MET) Subject: [Mailman-Developers] mailman error Message-ID: Hello! What does this mean ? Feb 21 00:47:29 1999 mailcmd: Traceback (innermost last): mailcmd: File "/var/lib/mailman/scripts/mailcmd", line 52, in ? mailcmd: list.ParseMailCommands() mailcmd: File "/usr/lib/mailman/Mailman/MailCommandHandler.py", line 86, in ParseMailCommands mailcmd: sender = string.lower(mail.GetSender()) mailcmd: File "/usr/lib/mailman/Mailman/Message.py", line 122, in GetSender mailcmd: return string.lower(mail_address) mailcmd: TypeError : read-only buffer, None The mail command that triggered this message was a simple subscribe request... with a bad From: header, though From: Claudio Granatiero <@.> Btw wouldn't it be nice if these tracebacks printed out the values of the variables, too ? :) -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From jeffh@streek.com Sun Feb 21 04:02:26 1999 From: jeffh@streek.com (Jeff Hahn) Date: Sat, 20 Feb 1999 22:02:26 -0600 Subject: [Mailman-Developers] CVS Tree???? - What happened to the Cgi directory??? Message-ID: <002701be5d4e$fe50e820$1e0a5ad1@SINGSING.STREEK.COM> went to update my local copy No Cgi directory? Therefore empty cgi-bin directory after installation Any ideas? -Jeff From julian7@kva.hu Sun Feb 21 16:07:22 1999 From: julian7@kva.hu (Balazs Nagy) Date: Sun, 21 Feb 1999 17:07:22 +0100 (CET) Subject: [Mailman-Developers] (no subject) Message-ID: Hiyas, There any ideas about mail archive handling by email? I mean sending FAQ and other files automatically or the possibility of getting them. Regards: Balazs -- #!/usr/bin/perl -export-a-crypto-system-sig -http://dcs.ex.ac.uk/~aba/rsa print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0 [Christian tismer is having problems migrating a bunch of maillists to the new version, specifically because of the skew in customized (and even non-customized!) list web page templates. It brings up what i think is a substantial question about the template mechanism. I want to put the issue out there, see what the prevailing wisdom is. Details below...] -------- Original Message -------- Subject: Re: [Mailman-Users] Upgrade script for old databases? Date: Sun, 21 Feb 1999 10:19:46 -0500 From: Ken Manheimer Organization: Digital Creations, Inc. To: Christian Tismer CC: bwarsaw@python.org, klm@digicool.com Christian wrote: > Exactly. But extraction is not so much my problem, it is much more > how to move to all the new structures and layouts without getting > my customers involved. Ah - the customized-per-list listinfo template, for instance. I'm afraid you're right - the way that mailman provides for customization is not at all amenable to reconciling with new site templates. It's doubly bad because each list gets its own copy of the site templates when the list is created, so it gets locked in even when the list administrator doesn't tailor their templates from the site standard. Fixing this latter would not be hard, but it still wouldn't address the issue of tracking refinements in the site standard when the list has a divergent version. I imagine the solution there is to allow list managers only parameterized customization of their templates - something that dtml would make easier - but that, itself, is a tricky track. Sigh. > At least that, and if possible some more. I can write this myself, > and was just hoping that somebody had done so already. The HTML > is a different story... Sorry - i certainly haven't thought of a general solution, so i hadn't implemented anything... > My problem is that I have [a bunch of]u lists which are used by > my customers on starship.skyport.net, and I want to avoid > masses of conversation and support, when I try to move this to > mailman 1.0b7 or such. > The situation is even worse, since some changed the html > layouts a little, and the new layout is very different, also > the attribute names of the inserted variables have changed. > That's quite a lot of work, and if somebody had done so already, > I could use it as a starter and put more automation in, > but my time is so limited. > > I have a real migration problem here... > > Hmm. A mailinglist is a structure. Our (my) problem is that the > structure is no clean structure, but contains implementation > details. If there were another level of abstraction, like, say, > an XML DTD which defines what a Mailing list is, I could > do the move much easier. > > Sigh - I fear I have to do it by hand. Sorry - i agree that it's a problem. In fact, my inclination is to think that the freedom that list-customizable templates offers is not worth the migration issues that it presents. (I do know that some customizability is important - for instance, someone using mailman at cnri needed to simplify the listinfo page to basically just be a subscription page, without the archive and roster links, so offering parameters to turn off sections would probably be the right way to head. Something that worries me about this is that we've already established the current setup as the precedent, but i'm wondering whether it's worth rethinking. Christian, i'd like to bring the mailman cabal in on the issue - would it be ok if i forwarded this message to them? Ken From claw@kanga.nu Mon Feb 22 01:54:56 1999 From: claw@kanga.nu (J C Lawrence) Date: Sun, 21 Feb 1999 17:54:56 -0800 Subject: [Mailman-Developers] [Fwd: Re: [Mailman-Users] Upgrade script for old databases?] In-Reply-To: Message from Ken Manheimer of "Sun, 21 Feb 1999 13:25:39 EST." <36D04FA3.B89B8B4C@digicool.com> Message-ID: On Sun, 21 Feb 1999 13:25:39 -0500 Ken Manheimer wrote: > [Christian tismer is having problems migrating a bunch of maillists > to the new version, specifically because of the skew in customized > (and even non-customized!) list web page templates. It brings up > what i think is a substantial question about the template mechanism. > I want to put the issue out there, see what the prevailing wisdom > is. Details below...] I share his concerns, and am running into a few similar problems with clients I'm deploying MailMan at. Further, while the template structure is useful, the ability to define complex nodes for the templates is not wonderful. eg When the HTML for the list introductory description (that gets inserted into the listinfo page) is non-trivial, is is an absolute bitch to edit and correct in the provided form. Getting http://www.kanga.nu/lists/listinfo/mud-dev/ to look right took almost an hour. It still isn't quite right, but I've given up trying to fix the last niggles figuring its "good enough". Note: The only editing I did on the template was on the archives section as I don't use pipermail. All the rest is via the template expansion. -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From jeffh@streek.com Mon Feb 22 08:30:17 1999 From: jeffh@streek.com (Jeff Hahn) Date: Mon, 22 Feb 1999 02:30:17 -0600 (CST) Subject: [Mailman-Developers] CVS Tree???? - FIXED (I think) In-Reply-To: <002701be5d4e$fe50e820$1e0a5ad1@SINGSING.STREEK.COM> Message-ID: On Sat, 20 Feb 1999, Jeff Hahn wrote: > went to update my local copy > > No Cgi directory? > > Therefore empty cgi-bin directory after installation > Upon further examination, the wrapper programs failed to compile under RedHat Linux 5.2 The problem section in common.c is: #ifdef HAVE_SETREGID status = setregid(getegid(), -1); if (status) fatal(logident, "%s", strerror(errno)); #endif /* HAVE_SETREGID */ compile fails with logident undefined. "logident" is defined in both mail-wrapper.c and cgi-wrapper.c a statement "extern const char* logident;" added to common.h seemed to fix the problem. Could someone check this fix (I've just started playing with Mailman and have ZERO familiarity with the source), and if correct, check it into the CVS tree? Thanks, Jeff From Harald.Meland@usit.uio.no Mon Feb 22 17:45:46 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 22 Feb 1999 18:45:46 +0100 Subject: [Mailman-Developers] Possible bug in 1.0b8 In-Reply-To: Liam Kirsher's message of "Wed, 10 Feb 1999 14:52:37 -0800" References: <36C20DB4.9D6D4471@numenet.com> Message-ID: [Liam Kirsher] > I found the problelm in > > Cgi/admindb.py, line 116 > > the reference to /mailman/admindb/ was a problem. > I think the "mailman" part should be gotten from the DEFAULT_URL, > perhaps? I don't think that DEFAULT_URL has anything to do with this problem -- the fix is rather related to not depending on the not-really-standard (I think) REQUEST_URI environment variable. Please bear in mind that this is the first time I'm trying to do any CGI-related programming at all, but I still _think_ this patch is good (from reading the CGI/1.1 spec, and testing quickly that it doesn't break my web interface). Index: Mailman/Utils.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Utils.py,v retrieving revision 1.62 diff -u -r1.62 Utils.py --- Utils.py 1999/01/14 04:07:28 1.62 +++ Utils.py 1999/02/22 17:16:37 @@ -664,3 +664,20 @@ reraise(IOError, e) finally: os.umask(ou) + +def CGIpath(env): + """Return the full virtual path this CGI script was invoked with. + + Newer web servers seems to supply this info in the REQUEST_URI + environment variable -- which isn't part of the CGI/1.1 spec. + Thus, if REQUEST_URI isn't available, we concatenate SCRIPT_NAME + and PATH_INFO, both of which are part of CGI/1.1. If that fails, + too, fall back to a hardcoded common case. + + """ + if env.has_key("REQUEST_URI"): + return env["REQUEST_URI"] + elif env.has_key("SCRIPT_NAME") and env.has_key("PATH_INFO"): + return (env["SCRIPT_NAME"] + env["PATH_INFO"]) + else: + return ('/mailman/admin/' + list_name) Index: Mailman/Cgi/admin.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Cgi/admin.py,v retrieving revision 1.31 diff -u -r1.31 admin.py --- admin.py 1999/01/09 05:57:17 1.31 +++ admin.py 1999/02/22 17:16:38 @@ -123,8 +123,7 @@ text = Utils.maketext( 'admlogin.txt', {"listname": list_name, - "path" : os.environ.get("REQUEST_URI", - '/mailman/admin/' + list_name), + "path" : Utils.CGIpath(os.environ), "message" : message, }) print text Index: Mailman/Cgi/admindb.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Cgi/admindb.py,v retrieving revision 1.9 diff -u -r1.9 admindb.py --- admindb.py 1999/01/09 06:22:44 1.9 +++ admindb.py 1999/02/22 17:16:38 @@ -112,8 +112,7 @@ text = Utils.maketext( 'admlogin.txt', {'listname': list_name, - 'path' : os.environ.get('REQUEST_URI', - '/mailman/admindb/' + list_name), + 'path' : Utils.CGIpath(os.environ), 'message' : message, }) print text -- Harald From Harald.Meland@usit.uio.no Wed Feb 24 20:30:45 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 24 Feb 1999 21:30:45 +0100 Subject: [Mailman-Developers] Possible bug in 1.0b8 In-Reply-To: Harald Meland's message of "22 Feb 1999 18:45:46 +0100" References: <36C20DB4.9D6D4471@numenet.com> Message-ID: [Harald Meland] > Please bear in mind that this is the first time I'm trying to do any > CGI-related programming at all, but I still _think_ this patch is good > (from reading the CGI/1.1 spec, and testing quickly that it doesn't > break my web interface). I was slightly wrong about the patch being perfectly good -- the Utils.CGIpath() function would, if both of the "proper" methods for getting at the path failed, fall back to ("/mailman/admin/" + list_name), regardless of which CGI script called it. This would, obviously, be wrong if called from e.g. "admindb". It could also be argued that referencing the (hopefully defined) global variable list_name from CGIpath() is unnecessarily risky. Below is a patch (against current CVS) which fixes these problems by operating in a manner very similar to os.environ.get(), i.e. letting the caller supply the complete fallback value. [ I'm not really sure that putting a pretty special-purpose function like CGIpath() into the generic Utils module is the Right Thing -- but I couldn't see anywhere else where it would fit better. ] Index: Mailman/Utils.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Utils.py,v retrieving revision 1.62 diff -u -r1.62 Utils.py --- Utils.py 1999/01/14 04:07:28 1.62 +++ Utils.py 1999/02/24 20:26:00 @@ -664,3 +664,22 @@ reraise(IOError, e) finally: os.umask(ou) + +def CGIpath(env, fallback=None): + """Return the full virtual path this CGI script was invoked with. + + Newer web servers seems to supply this info in the REQUEST_URI + environment variable -- which isn't part of the CGI/1.1 spec. + Thus, if REQUEST_URI isn't available, we concatenate SCRIPT_NAME + and PATH_INFO, both of which are part of CGI/1.1. + + Optional second argument `fallback' (default `None') is returned if + both of the above methods fail. + + """ + if env.has_key("REQUEST_URI"): + return env["REQUEST_URI"] + elif env.has_key("SCRIPT_NAME") and env.has_key("PATH_INFO"): + return (env["SCRIPT_NAME"] + env["PATH_INFO"]) + else: + return fallback Index: Mailman/Cgi/admin.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Cgi/admin.py,v retrieving revision 1.31 diff -u -r1.31 admin.py --- admin.py 1999/01/09 05:57:17 1.31 +++ admin.py 1999/02/24 20:26:01 @@ -123,8 +123,8 @@ text = Utils.maketext( 'admlogin.txt', {"listname": list_name, - "path" : os.environ.get("REQUEST_URI", - '/mailman/admin/' + list_name), + "path" : Utils.CGIpath(os.environ, + '/mailman/admin/' + list_name), "message" : message, }) print text Index: Mailman/Cgi/admindb.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Cgi/admindb.py,v retrieving revision 1.9 diff -u -r1.9 admindb.py --- admindb.py 1999/01/09 06:22:44 1.9 +++ admindb.py 1999/02/24 20:26:01 @@ -112,8 +112,8 @@ text = Utils.maketext( 'admlogin.txt', {'listname': list_name, - 'path' : os.environ.get('REQUEST_URI', - '/mailman/admindb/' + list_name), + 'path' : Utils.CGIpath(os.environ, + '/mailman/admindb/' + list_name), 'message' : message, }) print text -- Harald From gstein@lyra.org Wed Feb 24 22:05:18 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 24 Feb 1999 14:05:18 -0800 Subject: [Mailman-Developers] [Fwd: Re: [Mailman-Users] Strange Problem.] Message-ID: <36D4779E.BC8785@lyra.org> Harald Meland wrote: > > [Michael Quigley] > > > ----- The following addresses had permanent fatal errors ----- > > "|/d0/mailman/mail/wrapper post webmaster" > > (expanded from: webmaster@goingv.com) > > > > ----- Transcript of session follows ----- > > 554 "|/d0/mailman/mail/wrapper post webmaster"... unknown mailer error 1 > > This indicates that the "wrapper" binary or something exec()d by it, > exit()ed with a status 1 (indicating that something failed). > > The first thing to suspect is that "wrapper" is being run under the > wrong gid. If that is the case, it tries logging this to syslog. The > fix is either to reconfigure mailman with the "--with-mail-gid" option > (and then rebuild and reinstall), or else configure your MTA to run > the pipe under the correct gid. This brings up an interesting idea: have the wrapper use different exit codes based on why it punted. That way, a simple examination of the maillog will tell you what happened. Cheers, -g -- Greg Stein, http://www.lyra.org/ From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Feb 27 17:53:50 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 27 Feb 1999 12:53:50 -0500 (EST) Subject: [Mailman-Developers] mailman error References: Message-ID: <14040.12590.97788.762445@anthem.cnri.reston.va.us> >>>>> "GM" == Gergely Madarasz writes: GM> Hello! GM> What does this mean ? GM> Feb 21 00:47:29 1999 mailcmd: Traceback (innermost last): GM> mailcmd: File "/var/lib/mailman/scripts/mailcmd", line 52, in GM> ? mailcmd: list.ParseMailCommands() mailcmd: File GM> "/usr/lib/mailman/Mailman/MailCommandHandler.py", line 86, in GM> ParseMailCommands mailcmd: sender = GM> string.lower(mail.GetSender()) mailcmd: File GM> "/usr/lib/mailman/Mailman/Message.py", line 122, in GetSender GM> mailcmd: return string.lower(mail_address) mailcmd: TypeError GM> : read-only buffer, None GM> The mail command that triggered this message was a simple GM> subscribe request... with a bad From: header, though From: GM> Claudio Granatiero <@.> Subscribing this type of address should no longer be allowed. GM> Btw wouldn't it be nice if these tracebacks printed out the GM> values of the variables, too ? :) Well... In general, Guido discourages printing variable values in tracebacks raised from builtin-functions, because all sorts of problems can occur (recursive loops, errors in reprs). What you see here is the next best thing: the *type* of the variable is printed. More often than not, a variable is None when you don't expect it to be, as in the case above. The type of None is so printing the type is usually all the information you need to figure out the problem! -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Feb 27 17:58:43 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 27 Feb 1999 12:58:43 -0500 (EST) Subject: [Mailman-Developers] [Fwd: Re: [Mailman-Users] Upgrade script for old databases?] References: <36D04FA3.B89B8B4C@digicool.com> Message-ID: <14040.12883.500649.8224@anthem.cnri.reston.va.us> >>>>> "JCL" == J C Lawrence writes: JCL> I share his concerns, and am running into a few similar JCL> problems with clients I'm deploying MailMan at. Further, JCL> while the template structure is useful, the ability to define JCL> complex nodes for the templates is not wonderful. JCL> eg When the HTML for the list introductory description JCL> (that gets inserted into the listinfo page) is non-trivial, JCL> is is an absolute bitch to edit and correct in the provided JCL> form. I agree completely. I think there's a lot we could improve here, although it'll naturally be after 1.0. This might include revision control, higher level selection of template parts (e.g. checkboxes to include certain sections), etc. I don't have any bright ideas though. I've taken to never removing anything from the HTML. I just comment stuff out all over the place. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Feb 27 19:28:29 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 27 Feb 1999 14:28:29 -0500 (EST) Subject: [Mailman-Developers] [Fwd: Re: [Mailman-Users] Strange Problem.] References: <36D4779E.BC8785@lyra.org> Message-ID: <14040.18269.508474.913998@anthem.cnri.reston.va.us> >>>>> "GS" == Greg Stein writes: GS> This brings up an interesting idea: have the wrapper use GS> different exit codes based on why it punted. That way, a GS> simple examination of the maillog will tell you what happened. Good suggestion Greg. #define GID_MISMATCH 2 #define SETREGID_FAILURE 3 #define EXECVE_FAILURE 4 #define MAIL_USAGE_ERROR 5 #define MAIL_ILLEGAL_COMMAND 6 -Barry From cklempay@chimera.acm.jhu.edu Sun Feb 28 07:42:02 1999 From: cklempay@chimera.acm.jhu.edu (Corbett J. Klempay) Date: Sun, 28 Feb 1999 02:42:02 -0500 (EST) Subject: [Mailman-Developers] msnbc mailman mention Message-ID: Hey, did you guys notice this MSNBC article mentioning Mailman? Big league! :) http://www.msnbc.com/news/244979.asp ------------------------------------------------------------------------------ Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Work like you don't need the money, love like it's never going to hurt, and dance like no one is watching..." ------------------------------------------------------------------------------ From ayu1@nycap.rr.com Sun Feb 28 08:07:05 1999 From: ayu1@nycap.rr.com (Alex Yu) Date: Sun, 28 Feb 1999 03:07:05 -0500 Subject: [Mailman-Developers] msnbc mailman mention In-Reply-To: Message-ID: <4.1.19990228030613.0094e9c0@pop1.rpi.edu> At 02:42 AM 1999/2/28 -0500, Corbett J. Klempay wrote: >Hey, did you guys notice this MSNBC article mentioning Mailman? Big >http://www.msnbc.com/news/244979.asp Guest what, even Microsoft coders are using Linux + Xwin + emacs + egcs compiler to do their work. It is true!!! Linux owns! Alex