From tismer@appliedbiometrics.com Mon Mar 1 17:22:04 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Mon, 01 Mar 1999 18:22:04 +0100 Subject: [Mailman-Developers] [Fwd: Re: [Mailman-Users] Upgrade script for old databases?] References: <36D04FA3.B89B8B4C@digicool.com> <14040.12883.500649.8224@anthem.cnri.reston.va.us> Message-ID: <36DACCBC.BE890949@appliedbiometrics.com> Hi Friends... ... *blush* (gulp) just FYI: I kinda "solved" my problem today, unfortunately. I happened to use the "rmlist" script from Mailman 0.95 without parameters. Then, I realized that this removed *all* mailing lists of starship.skyport.net in a single sweep. Dead, done, no more archives, oh well. I will be able to rebuild the python-de archive from my local mailboxes, but my customers will be unhappy... So, I no longer have a migration problem :-( :-) :-/ !-[ ciao - chris.dead.letter "Barry A. Warsaw" wrote: > > >>>>> "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 > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home From bwarsaw@python.org Mon Mar 1 17:33:32 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Mon, 1 Mar 1999 12:33:32 -0500 (EST) Subject: [Mailman-Developers] [Fwd: Re: [Mailman-Users] Upgrade script for old databases?] References: <36D04FA3.B89B8B4C@digicool.com> <14040.12883.500649.8224@anthem.cnri.reston.va.us> <36DACCBC.BE890949@appliedbiometrics.com> Message-ID: <14042.53100.697046.865758@anthem.cnri.reston.va.us> >>>>> "CT" == Christian Tismer writes: CT> I happened to use the "rmlist" script from Mailman 0.95 CT> without parameters. Then, I realized that this removed *all* CT> mailing lists of starship.skyport.net in a single sweep. Gack! Well, at least this particular bug is fixed in Mailman 1.0b9 (going out today). Small consolation... -Barry From bwarsaw@python.org Mon Mar 1 19:02:02 1999 From: bwarsaw@python.org (bwarsaw@python.org) Date: Mon, 1 Mar 1999 14:02:02 -0500 (EST) Subject: [Mailman-Developers] [ANNOUNCE] Mailman 1.0b9 Message-ID: <14042.58410.557890.269150@anthem.cnri.reston.va.us> Folks, I've just uploaded Mailman 1.0b9 to www.list.org. I hope this solves the worst of the Linux problems and fixes most other outstanding bugs. I know there will be at least one more beta, hopefully by this weekend. I have three other minor buglets to fix and I think Ken has a couple of outstanding checkins to make. But I'd like b10 to be the last beta. It's time to get 1.0 out the door (I know I've said this before -- this time I mean it :-). I'd also like to welcome Harald Meland to the Mailman Cabal. John and I met Harald in Boston at the LISA conference last December and liked him a lot. He'll make a great addition to the team. Please check out the contributed logo designs to! We have some nice entries by Heidi, Alexander and Dragon. I'd like to choose one for the final release, so please email me directly with your choice (please DO NOT spam the list with your votes). Enjoy, and let me know if I missed anything. -Barry From gorgo@caesar.elte.hu Mon Mar 1 20:15:17 1999 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Mon, 1 Mar 1999 21:15:17 +0100 (MET) Subject: [Mailman-Developers] [ANNOUNCE] Mailman 1.0b9 In-Reply-To: <14042.58410.557890.269150@anthem.cnri.reston.va.us> Message-ID: On Mon, 1 Mar 1999 bwarsaw@python.org wrote: > I've just uploaded Mailman 1.0b9 to www.list.org. I hope this solves > the worst of the Linux problems and fixes most other outstanding > bugs. Ugh... this means I was _fast_ ;) I just happened to find 1.0b9 an hour ago on the website, and managed to upload the debian package before this announcement hit the lists :)) -- 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) Mon Mar 1 20:12:55 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 1 Mar 1999 15:12:55 -0500 (EST) Subject: [Mailman-Developers] [ANNOUNCE] Mailman 1.0b9 References: <14042.58410.557890.269150@anthem.cnri.reston.va.us> Message-ID: <14042.62663.748607.866882@anthem.cnri.reston.va.us> >>>>> "GM" == Gergely Madarasz writes: GM> Ugh... this means I was _fast_ ;) I just happened to find GM> 1.0b9 an hour ago on the website, and managed to upload the GM> debian package before this announcement hit the lists :)) Faster than Python.org at least :-) -Barry From starback@ling.uu.se Mon Mar 1 23:04:17 1999 From: starback@ling.uu.se (Per Starback) Date: 02 Mar 1999 00:04:17 +0100 Subject: [Mailman-Developers] Re: [Mailman-Users] [ANNOUNCE] Mailman 1.0b9 In-Reply-To: bwarsaw@python.org's message of "Mon, 1 Mar 1999 14:02:02 -0500 (EST)" References: <14042.58410.557890.269150@anthem.cnri.reston.va.us> Message-ID: Barry wrote: > But I'd like b10 to be the last beta. It's time to get 1.0 out the > door (I know I've said this before -- this time I mean it :-). That sounds good! As a very new user of Mailman I can say that the beta version number was one thing that made me hesitant about using Mailman when I recently looked around wondering what MLM I should switch to. (I'm finally leaving SmartList after several years.) > Enjoy, and let me know if I missed anything. It's always nice to have the NEWS file or something like that in announcements of new versions so you can decide if you want to upgrade without having to fetch and unpack the whole thing: # Differences between 1.0b8 and 1.0b9 # # - New bin scripts: clone_member, list_members, add_members (a # consolidation of convertlist and populate_new_list which have been # removed). # # - Two new readmes have been added: README.LINUX and README.QMAIL # # - New configure option --with-cgi-ext which can be used if your Web # server requires extensions on CGI scripts. The extension must # include a dot (e.g. --with-cgi-ext=".cgi"). # # - Many bug fixes, including the setgid problem that was causing mail # to be lost on some versions of Linux. Hm, --with-cgi-ext was in 1.0b8 too. At least it's mentioned in the INSTALL there, but I didn't use it. Wish list: * Add Mail-Followup-To header. (I've done that for myself, but I would appreciate not having to do it again, as well as I'd like to see more use of this useful although nonstandard header.) * Possibility for individual list members to say if they want a Subject line [tag] or not. That would mean that there would have to be two versions of each message, but I think that would be worth it as the [tag]/no tag preference is more about the preferences (and mail situation) of individual list members that about the preferences of the list itself or its maintainer. I would never add a tag like that on my lists per default, but if users who want it could get it explicitly that would be nice. * A line at the Membership Management page where you set default attributes for new users in the same way that you can change attributes for the existing users. This more general feature would be instead of the Which delivery mode is the default for new users? and When receiving digests, which format is default? questions on the Digest-member options page. I think I would like to set "hide" by default, and anyway I think it's better for the future to have one general way of setting the default instead of having to add new list options sometimes when new membership options are made. I'm sorry if my wish list consists of things that have been beaten to death here. Being a list manager myself I should know better than to jump in on a list without lurking for some time first. :-) -- Per Starback "Life is but a gamble! Let flipism chart your ramble!" From roger@infomed.sld.cu Tue Mar 2 00:42:06 1999 From: roger@infomed.sld.cu (=?iso-8859-1?Q?Roger_Pe=F1a_Escobio?=) Date: Mon, 1 Mar 1999 19:42:06 -0500 Subject: [Mailman-Developers] Hi i new in this list and with mailman Message-ID: <01be6445$7fa4a450$1c7001c4@ntserver.sld.cu> This is a multi-part message in MIME format. ------=_NextPart_000_012C_01BE641B.96CE9C50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi to all mailman user and developers :-) how i say in the subject i new with mailman, and i like it :-)) but = there are some things unwanted, first of all , the suid in all subdirs = and in the exe files (not the cgi-bin files), the other things is the = permisions , i dont understant why 775 for all subdirs and not only for = : logs, locks, lists, data, archives , the others just 750 except cgi-bin = (755) . well, i did some changes in source, change the permisions and fix the = alias_wrapper so i can edit a aliases files (/etc/mailman/aliases) and = run sendmail -bi . All looks fine :-)=20 i worked on version b8 i just unload the new version sorry for my english, is not so good=20 Roger ------=_NextPart_000_012C_01BE641B.96CE9C50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Hi to all mailman user and developers = :-)
how i=20 say in the subject i new with mailman, and i like it :-)) but there are = some=20 things unwanted, first of all , the suid in all subdirs and in the exe = files=20 (not the cgi-bin files), the other things is the permisions , i dont = understant=20 why 775 for all subdirs and not only for :
logs,=20 locks, lists, data, archives , the others just 750 except cgi-bin (755)=20 .
 
well,=20 i did some changes in source, change the permisions and fix the = alias_wrapper so=20 i can edit a aliases files (/etc/mailman/aliases) and run sendmail -bi . = All=20 looks fine :-)
i worked on = version b8 i=20 just unload the new version
 
sorry for = my english, is=20 not so good
Roger
------=_NextPart_000_012C_01BE641B.96CE9C50-- From ayu1@nycap.rr.com Tue Mar 2 02:58:47 1999 From: ayu1@nycap.rr.com (Alex Yu) Date: Mon, 01 Mar 1999 21:58:47 -0500 Subject: [Mailman-Developers] Hi i new in this list and with mailman In-Reply-To: <01be6445$7fa4a450$1c7001c4@ntserver.sld.cu> Message-ID: <4.1.19990301215802.00984ba0@pop1.rpi.edu> At 07:42 PM 1999/3/1 -0500, Roger Peņa Escobio wrote: > > how i say in the subject i new with mailman, and i like it :-)) but there are > some things unwanted, first of all , the suid in all subdirs and in the exe > files (not the cgi-bin files), the other things is the permisions , i dont > understant why 775 for all subdirs and not Please DO NOT use send HTML or RICH TEXT email. Most of us are using like *pine* or *elm* to read our emails and it does not support it! Alex From julian7@kva.hu Tue Mar 2 10:36:10 1999 From: julian7@kva.hu (Balazs Nagy) Date: Tue, 2 Mar 1999 11:36:10 +0100 (CET) Subject: [Mailman-Developers] Re: [Mailman-Users] [ANNOUNCE] Mailman 1.0b9 In-Reply-To: Message-ID: On 2 Mar 1999, Per Starback wrote: > Barry wrote: > > > But I'd like b10 to be the last beta. It's time to get 1.0 out the > > That sounds good! As a very new user of Mailman I can say that the > beta version number was one thing that made me hesitant about using > Mailman when I recently looked around wondering what MLM I should > switch to. (I'm finally leaving SmartList after several years.) Well, ezmlm works great - at least at the mailing part of the issue. Mailman works a lot slower but it has more features (except of archive commands). BTW it would be nice if we put an archiving method to Mailman but I don't know which way would be the best. > Hm, --with-cgi-ext was in 1.0b8 too. At least it's mentioned in the > INSTALL there, but I didn't use it. Nope. It was in the INSTALL file but no one put it in until now. > * Possibility for individual list members to say if they want > a Subject line [tag] or not. That would mean that there would have > to be two versions of each message, but I think that would be worth > it as the [tag]/no tag preference is more about the preferences > (and mail situation) of individual list members that about the > preferences of the list itself or its maintainer. I would never > add a tag like that on my lists per default, but if users who want > it could get it explicitly that would be nice. It's not a good idea because this adds more latency and complexity. I think four to eighteen bytes won't hurt anyone if they know who is the sysadmin. -- Regards: Kevin (Balazs) From jeffh@streek.com Tue Mar 2 17:48:26 1999 From: jeffh@streek.com (Jeff Hahn) Date: Tue, 2 Mar 1999 11:48:26 -0600 Subject: [Mailman-Developers] bounce processing question and idea for future enhancements... Message-ID: <00b101be64d4$dfcab240$1e0a5ad1@SINGSING.STREEK.COM> Bounce processing question... Since some of the big email domains (hotmail, aol, etc.) are known to "burp" and deny existence of perfectly valid users, I'd like to handle all returns as bounces and not remove people automatically on the first "user unknown" message. I assume the way to handle it is to change "REMOVE" to "BOUNCE" in the lines like the following in bouncer.py (regex.compile('.*%s: User unknown.*' % email_regexp), REMOVE), Any comments? Any better way to do it? Idea for future enhancements... This is the big one. Does anyone besides me have a desire to see Mailman support Listserv style "topics"? Where topics are extracted from the message subject and list messages are sent to a subset of the list that "subscribes" to that particular topic? I have a very pressing need for this feature. I'm leaving procmail/smartlist because of this and was intending to "roll my own" MLM when I came across MailMan. MailMan supplies a huge portion of the framework with all the nice bells and whistles, so I've decided to start with it. If there is additional interest, I'll try to get rolling on this within the "official" channels. If anyone is interested in collaborating on this that would be great. I certainly haven't been involved with MailMan long at all and don't have any background about the various design choices that were made along the way. Feedback on this would be GREATLY appreciated. -Jeff From bryner@uiuc.edu Wed Mar 3 03:45:28 1999 From: bryner@uiuc.edu (Brian Ryner) Date: Tue, 02 Mar 1999 21:45:28 -0600 Subject: [Mailman-Developers] Bug in password lookup, and possible fix Message-ID: <36DCB058.AC6B1507@uiuc.edu> Hi- I posted this to mailman-users but figured I might get a better response here. There's a bug that can come up when you mass subscribe users. The script does not lowercase the email addresses when they are mass-subscribed. This causes problems for just about everything, including password lookup, because when you type the email address to go to the options page, it uses a lowercased version of it. Then, since the password is stored with an uppercased version of the address, it can't find it. If users subscribe themselves, their email address gets lowercased and spaces get removed. Therefore, I'd suggest applying this same behavior to the mass subscribe feature. Thanks. -Brian Ryner bryner@uiuc.edu From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Mar 3 04:21:23 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 2 Mar 1999 23:21:23 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] Possible Fix for password lookup bug References: <36DCB058.AC6B1507@uiuc.edu> <36DC7BE7.A91A3991@uiuc.edu> Message-ID: <14044.47299.742348.971101@anthem.cnri.reston.va.us> >>>>> "BR" == Brian Ryner writes: BR> There's a bug that can come up when you mass subscribe users. BR> The script does not lowercase the email addresses when they BR> are mass-subscribed. This causes problems for just about BR> everything, including password lookup, because when you type BR> the email address to go to the options page, it uses a BR> lowercased version of it. Then, since the password is stored BR> with an uppercased version of the address, it can't find it. BR> If users subscribe themselves, their email address gets BR> lowercased and spaces get removed. Therefore, I'd suggest BR> applying this same behavior to the mass subscribe feature. What version of Mailman are you using? The policy is this: the user name part of the email address is case-preserving because RFC 822 says it must be. However for the Web side of the world, email addresses are lower cased. This means if I subscribe BWARSAW@python.org, email will always be delivered to BWARSAW@python.org, but my options will be at .../bwarsaw__at__python.org This has all been verified to work in Mailman 1.0b9. -Barry From lindsey@ncsa.uiuc.edu Wed Mar 3 06:08:41 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Wed, 3 Mar 1999 00:08:41 -0600 (CST) Subject: [Mailman-Developers] Re: [Mailman-Users] Possible Fix for password lookup bug In-Reply-To: <14044.47299.742348.971101@anthem.cnri.reston.va.us> from "Barry A. Warsaw" at Mar 2, 99 11:21:23 pm Message-ID: <199903030608.AAA32535@ferret.ncsa.uiuc.edu> > What version of Mailman are you using? The policy is this: the user > name part of the email address is case-preserving because RFC 822 says > it must be. However for the Web side of the world, email addresses > are lower cased. This means if I subscribe BWARSAW@python.org, email > will always be delivered to BWARSAW@python.org, but my options will be > at .../bwarsaw__at__python.org > > This has all been verified to work in Mailman 1.0b9. I just tested it with a system upgraded from 1.0b8 to 1.0b9, and it doesn't appear to have worked... Here's what I did: o Create a file called /tmp/doit that contains the (fictitious) address MARShall351@mallorn.com o as user mailman, run '$prefix/bin/add_members -n /tmp/doit -w n test2' o Go to the Web page at http://www.mallorn.com/mailman/options/test2/marshall351@mallorn.com and email my password to myself It comes back with a blank page that says "Your password entry has not been found. The list administrator is being notified." I also get an email message back (well, I created a temporary alias that made it non-fictitious for a while) that says: Mailman noticed in .MailUserPassword() that: User: 'marshall351@mallorn.com' List: test2 lacks a password. Please notify the Mailman system manager at this site! If I try to access the options page with a case sensitive address, such as http://www.mallorn.com/mailman/options/test2/MARShall351@mallorn.com the script comes back and says test2: No such member 'MARShall351@mallorn.com' So what the original poster was saying is that email addresses that have uppercase characters in them are not assigned passwords (I've tried it via the Web page and via the commandline script, with and without notification). Another odd thing that I've noticed is that addresses with uppercase characters in them are always set to MIME instead of plain... I really think that the case changes should be thought over again. Even though the local domain might not differentiate between upper and lower case, what would happen if JOEbob@example.com and joebob@example.com both decided to subscribe to a list (assuming that example.com differentiated between the two for purposes of local delivery)? Chris From bryner@uiuc.edu Wed Mar 3 06:23:53 1999 From: bryner@uiuc.edu (Brian Ryner) Date: Wed, 03 Mar 1999 00:23:53 -0600 Subject: [Mailman-Developers] Re: [Mailman-Users] Possible Fix for password lookup bug References: <199903030608.AAA32535@ferret.ncsa.uiuc.edu> Message-ID: <36DCD579.328BE248@uiuc.edu> Christopher Lindsey wrote: > > So what the original poster was saying is that email addresses that > have uppercase characters in them are not assigned passwords (I've > tried it via the Web page and via the commandline script, with and > without notification). Another odd thing that I've noticed is Is it that they aren't assigned passwords, or it can't find the password once it's assigned (because of case conversions elsewhere)? I don't know how to check this. Anyone know? -Brian Ryner bryner@uiuc.edu From lindsey@ncsa.uiuc.edu Wed Mar 3 06:29:24 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Wed, 3 Mar 1999 00:29:24 -0600 (CST) Subject: [Mailman-Developers] Re: [Mailman-Users] Possible Fix for password In-Reply-To: <36DCD579.328BE248@uiuc.edu> from "Brian Ryner" at Mar 3, 99 00:23:53 am Message-ID: <199903030629.AAA32653@ferret.ncsa.uiuc.edu> > Is it that they aren't assigned passwords, or it can't find the password > once it's assigned (because of case conversions elsewhere)? I don't > know how to check this. Anyone know? The password *is* being assigned, but it can't find it later. If I do a strings $prefix/lists/test2/config.db | less and search for the username with uppercase characters, it comes up with a password on the next line... It's functionally the same as not having a password, though. :) Chris P.S. This should probably move to mailman-developers instead of crossing both lists, so we should probably only reply there... From bwarsaw@python.org Wed Mar 3 15:09:59 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Wed, 3 Mar 1999 10:09:59 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] Re: [Mailman-Developers] Re: [Mailman-Users] Possible Fix for password lookup bug References: <14044.47299.742348.971101@anthem.cnri.reston.va.us> <199903030608.AAA32535@ferret.ncsa.uiuc.edu> Message-ID: <14045.20679.885894.920839@anthem.cnri.reston.va.us> >>>>> "CL" == Christopher Lindsey writes: CL> So what the original poster was saying is that email addresses CL> that have uppercase characters in them are not assigned CL> passwords (I've tried it via the Web page and via the CL> commandline script, with and without notification). Another CL> odd thing that I've noticed is that addresses with uppercase CL> characters in them are always set to MIME instead of plain... Verified. Thanks for the recipe, it was crucial to me finding the bug. Unfortunately, I don't have time just now to fix it, but it shouldn't be difficult. The problem is that addrs in the password dictionary are kept case-preserved, but the match is done lower-cased. CL> I really think that the case changes should be thought over CL> again. Even though the local domain might not differentiate CL> between upper and lower case, what would happen if CL> JOEbob@example.com and joebob@example.com both decided to CL> subscribe to a list (assuming that example.com differentiated CL> between the two for purposes of local delivery)? The second one ought to be refused as already subscribed. And the reason all this extra cruft was put in place was because there really are some domains that differentiate based on the case of the username part. Thus in these domains, if I subscribed with BWARSAW@crufty.com, but Mailman insisted on sending the mail to bwarsaw@crufty.com, it would bounce. -Barry From emarshal@logic.net Wed Mar 3 15:45:59 1999 From: emarshal@logic.net (Edward S. Marshall) Date: Wed, 3 Mar 1999 09:45:59 -0600 (CST) Subject: [Mailman-Developers] Re: [Mailman-Users] Re: [Mailman-Developers] Re: [Mailman-Users] Possible Fix for password lookup bug Possible Fix for password lookup bug In-Reply-To: <14045.20679.885894.920839@anthem.cnri.reston.va.us> Message-ID: On Wed, 3 Mar 1999, Barry A. Warsaw wrote: > The second one ought to be refused as already subscribed. I humbly disagree. > And the reason all this extra cruft was put in place was because there > really are some domains that differentiate based on the case of the > username part. Which is explicitly allowed by RFC 822. Why should Mailman care about case of the LHS at -all-? Why not leave it completely untouched? Or at least have an option to leave it alone, and remain RFC-compliant. (Yes, I'm picking nits here, but people tend to discard standards too often these days. RFC 822 might be full of contradictions, but it's quite clear about preserving the case of the LHS of the address.) -- Edward S. Marshall [ What goes up, must come down. ] http://www.logic.net/~emarshal/ [ Ask any system administrator. ] Linux labyrinth 2.2.2-pre2 #2 Sun Feb 14 15:24:09 CST 1999 i586 unknown 9:40am up 16 days, 10:16, 3 users, load average: 0.16, 0.09, 0.03 From tismer@appliedbiometrics.com Wed Mar 3 15:52:54 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Wed, 03 Mar 1999 16:52:54 +0100 Subject: [Mailman-Developers] Install clarification Message-ID: <36DD5AD6.66210472@appliedbiometrics.com> Howdy, after my hazzards with MM0.95, I'm installing MM1.0b9 from scratch on the old Starship. I'm trying to follow the INSTALL notes exactly. After % cd $prefix % chgrp mailman . % chmod a+rx,g+s . I went into the source dir and called ./configure . It complained as so: checking permissions on /home/mailman... configure: error: ***** Installation directory /home/mailman is not configured properly! ***** Permissions should be at least 0775: /home/mailman Can it be that the chmod should better read like "chmod a+rx,g+ws ." ? After doing so, configure was happy. ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home From Harald.Meland@usit.uio.no Wed Mar 3 16:20:09 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 03 Mar 1999 17:20:09 +0100 Subject: [Mailman-Developers] change request: admin password changing References: <36C48867.3E677BDF@lyra.org> Message-ID: [Greg Stein] > 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. I agree. I think that the change of admin password stuff belongs on the "General options" page, and not on _all_ the pages. However, I'm undecided in the matter of making this (site) configurable. Would anyone object if I just put in a hardcoded condition on 'category == "general"' around the call to FormatPasswordStuff() in Mailman.Cgi.admin.FormatConfiguration()? -- Harald From Harald.Meland@usit.uio.no Wed Mar 3 16:36:07 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 03 Mar 1999 17:36:07 +0100 Subject: [Mailman-Developers] Help with run_queue problem? In-Reply-To: Liam Kirsher's message of "Tue, 16 Feb 1999 15:54:48 -0800" References: <36CA0548.2BE4746@numenet.com> Message-ID: [Liam Kirsher] > 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 Sorry for taking a _long_ time to respond, but it appears that your outgoing queue files have been corrupted in some way. I guess Mailman should handle corrupted spool files more elegantly. Is there any wisdom about on what the appropriate action to take in this case would be? Would logging "Corrupted queue file such-and-such removed from queue" (and removing the file from the queue :) suffice? Or should the corrupted queue file be removed from the queue, but stored elsewhere for later investigation of what caused the corruption etc.? Should anyone (list owner, mailman-owner) get email on these incidents? Which of these options, if any, should be (site) configurable? Or should some other "solution" be implemented? While we're on the subject, what about the list config info -- should this be automatically recovered from config.db.last when config.db is corrupt? -- Harald From tismer@appliedbiometrics.com Wed Mar 3 16:37:58 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Wed, 03 Mar 1999 17:37:58 +0100 Subject: [Mailman-Developers] Install clarification References: <36DD5AD6.66210472@appliedbiometrics.com> Message-ID: <36DD6566.19183363@appliedbiometrics.com> Another small problem: newlist has been changed somewhere between 1.0b7 and 1.0b9 in the wrong way, and the change has obviously not been tested! ###before (1.0b7): import sys, os, string import time import getpass import paths # path hacking from Mailman import MailList from Mailman import Utils from Mailman import mm_cfg from Mailman.Crypt import crypt ###After (1.0b9): import sys, os, string import time try: import getpass except ImportError: # we must be in Python 1.5, which didn't have the getpass module from Mailman.pythonlib import getpass import paths # path hacking from Mailman import MailList from Mailman import Utils from Mailman import mm_cfg from Mailman.Crypt import crypt The "import pahs" must go *before* the try..except ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home From bryner@uiuc.edu Wed Mar 3 17:13:00 1999 From: bryner@uiuc.edu (Brian Ryner) Date: Wed, 03 Mar 1999 11:13:00 -0600 Subject: [Mailman-Developers] Re: [Mailman-Users] Re: [Mailman-Developers] Re: [Mailman-Users]Possible Fix for password lookup bug Fix for password lookup bug References: Message-ID: <36DD6D9C.B86B1B44@uiuc.edu> "Edward S. Marshall" wrote: > > On Wed, 3 Mar 1999, Barry A. Warsaw wrote: > > The second one ought to be refused as already subscribed. > > I humbly disagree. > Hm, I'm not so sure about that. Allowing users to subscribe different capitalizations of their address (and hence receive the mail multiple times) seems like it's asking for a lot of mixups with novice users. From mailman-developers@python.org Wed Mar 3 17:33:42 1999 From: mailman-developers@python.org (Harald Meland) Date: 03 Mar 1999 18:33:42 +0100 Subject: [Mailman-Developers] Re: [Mailman-Users] [ANNOUNCE] Mailman 1.0b9 In-Reply-To: Per Starback's message of "02 Mar 1999 00:04:17 +0100" References: <14042.58410.557890.269150@anthem.cnri.reston.va.us> Message-ID: [Per Starback] > Wish list: > > * Add Mail-Followup-To header. (I've done that for myself, but > I would appreciate not having to do it again, as well as I'd like > to see more use of this useful although nonstandard header.) As this (currently) is a non-standard header, I wouldn't feel good about putting explicit support for it into Mailman. However, a more general "Add this header (standard or not) (if it doesn't exist already) to all messages to this list" might be good. But not for 1.0, methinks. > * Possibility for individual list members to say if they want > a Subject line [tag] or not. That would mean that there would have > to be two versions of each message, but I think that would be worth > it as the [tag]/no tag preference is more about the preferences > (and mail situation) of individual list members that about the > preferences of the list itself or its maintainer. I would never > add a tag like that on my lists per default, but if users who want > it could get it explicitly that would be nice. For users it is always good to make _all_ the bells and whistles configurable. However, Mailman has to find a balance between user configurability and how efficient list delivery should be. This means we have to make sure that making something user configurable won't make list delivery unbearably inefficient for any Mailman installation. Once we start going down the road of deciding which options should be made user configurable and which aren't really worth it, it is *very* easy to get lost. There are lots of other good candidates for user configurable options concerning outgoing list messages: Adding a Reply-To: header, including the list footer, including the list header, and of course VERP. The added complexity of Mailman code this would need is also an issue. So, what I'm trying to say, is: Yes, this would be nice to have for some installations -- but don't hold your breath :) > * A line at the Membership Management page where you set default > attributes for new users in the same way that you can change > attributes for the existing users. This more general feature > would be instead of the > > Which delivery mode is the default for new users? > and > When receiving digests, which format is default? > > questions on the Digest-member options page. Yes, this would be nice. I'll try looking into it. > I think I would like to set "hide" by default, If you're talking of changing the Mailman default setting, that would be an incompatible change -- and those suck. Thanks a lot for your suggestions on how can be Mailman improved -- and do keep 'em coming! -- Harald From bryner@uiuc.edu Wed Mar 3 17:36:26 1999 From: bryner@uiuc.edu (Brian Ryner) Date: Wed, 03 Mar 1999 11:36:26 -0600 Subject: [Mailman-Developers] nomail setting not always working Message-ID: <36DD731A.45419CC3@uiuc.edu> Hi- Yesterday I sent a message to a mailing list I'd set up, and got several bounces (as I expected). I have mailman set to disable the users and notify me, which it did. Today I sent another message, and got more bounces from the same people! which means it tried to deliver to them again. The second message I received said "subscription not disabled- user not found" (or something similar). I tried reproducing this on a test list and was unable to. Looking at the bounce messages I do notice a subtle difference between them. These are both for bounces from the same email address: 1st bounce message: ... The original message was received at Tue, 2 Mar 1999 09:52:08 -0600 from localhost [127.0.0.1] ... 2nd bounce message: ... The original message was received at Wed, 3 Mar 1999 10:21:37 -0600 from nobody@localhost [127.0.0.1] ... Note that the first message has no username and the second has nobody@localhost. Does anyone know what would cause this?? Python 1.51, Slackware 3.2. Thanks. -Brian Ryner bryner@uiuc.edu From Harald.Meland@usit.uio.no Wed Mar 3 17:49:04 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 03 Mar 1999 18:49:04 +0100 Subject: [Mailman-Developers] Hi i new in this list and with mailman In-Reply-To: Roger Peņa Escobio's message of "Mon, 1 Mar 1999 19:42:06 -0500" References: <01be6445$7fa4a450$1c7001c4@ntserver.sld.cu> Message-ID: [Roger Peņa Escobio] > Hi to all mailman user and developers :-) Hi! > how i say in the subject i new with mailman, and i like it :-)) but > there are some things unwanted, first of all , the suid in all > subdirs and in the exe files (not the cgi-bin files), Umm, nothing in Mailman is setUID. Mailmans permissions scheme revolves around setGID (to allow non-privileged users to use Mailman, even though this requires some cooperation with the sysadm in many cases). When mailman receives mail (via some alias-file pipe from your local MTA (in most cases)), it checks that the gid of the spawned pipe is running under some compiled in (real) gid, and then setgid()s to it's own (effective) gid to allow Mailman to operate. A similar scheme is used for changes done via the web interface. > the other things is the permisions , i dont understant why 775 for > all subdirs and not only for : logs, locks, lists, data, archives , > the others just 750 except cgi-bin (755) . Probably because using _one_ set of permission for all dirs Works (TM) :) Seriously: You're probably right, and I think Mailman could be set up with more restrictive permissions. This should be fixed, but hasn't really been a top priority as it's not really a bug (and possibly could be a cause of breakage for someone with ... "exotic" configurations that Were Working Before They Upgraded (TM) :). I'd like to address this after 1.0 is out the door. -- Harald From lindsey@ncsa.uiuc.edu Wed Mar 3 17:51:34 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Wed, 3 Mar 1999 11:51:34 -0600 (CST) Subject: [Mailman-Developers] Re: [Mailman-Users] Re: [Mailman-Developers] Re: [Mailman-Users]Possible In-Reply-To: <36DD6D9C.B86B1B44@uiuc.edu> from "Brian Ryner" at Mar 3, 99 11:13:00 am Message-ID: <199903031751.LAA03544@ferret.ncsa.uiuc.edu> > > On Wed, 3 Mar 1999, Barry A. Warsaw wrote: > > > The second one ought to be refused as already subscribed. > > > > I humbly disagree. > > > Hm, I'm not so sure about that. Allowing users to subscribe different > capitalizations of their address (and hence receive the mail multiple > times) seems like it's asking for a lot of mixups with novice users. Yeah, but you can't always protect users against themselves, especially when doing so has the potential to prevent users from signing on to a list altogether. I have seen systems that had the multiple accounts belonging to different people but could only be differentiated by case. I admit that it's not the brightest thing to do, but sites do it because it's allowed by RFC 822. We can't just ignore the RFCs because it's convenient -- that just seems to "Redmondian"... Maybe the right thing to do is offer the administrator a choice on a per list basis. Chris From bryner@uiuc.edu Wed Mar 3 18:18:53 1999 From: bryner@uiuc.edu (Brian Ryner) Date: Wed, 03 Mar 1999 12:18:53 -0600 Subject: [Mailman-Developers] the case issue References: <199903031751.LAA03544@ferret.ncsa.uiuc.edu> Message-ID: <36DD7D0D.68AA59F0@uiuc.edu> (Shortening the subject a lot) :) How about this. If the email address you try to subscribe matches case-insensitively an email that's already subscribed, it tells you so and asks for confirmation. A similar thing could happen when you go into the options page- if there is more than one address that could be it, it gives you a choice to be sure. Christopher Lindsey wrote: > > Yeah, but you can't always protect users against themselves, especially > when doing so has the potential to prevent users from signing on to > a list altogether. I have seen systems that had the multiple accounts > belonging to different people but could only be differentiated by case. > I admit that it's not the brightest thing to do, but sites do it > because it's allowed by RFC 822. We can't just ignore the RFCs because > it's convenient -- that just seems to "Redmondian"... > > Maybe the right thing to do is offer the administrator a choice > on a per list basis. > > Chris From Harald.Meland@usit.uio.no Wed Mar 3 18:55:23 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 03 Mar 1999 19:55:23 +0100 Subject: [Mailman-Developers] bounce processing question and idea for future enhancements... In-Reply-To: Jeff Hahn's message of "Tue, 2 Mar 1999 11:48:26 -0600" References: <00b101be64d4$dfcab240$1e0a5ad1@SINGSING.STREEK.COM> Message-ID: [Jeff Hahn] > Bounce processing question... > > Since some of the big email domains (hotmail, aol, etc.) are known to > "burp" and deny existence of perfectly valid users, I'd like to handle all > returns as bounces and not remove people automatically on the first "user > unknown" message. I assume the way to handle it is to change "REMOVE" to > "BOUNCE" in the lines like the following in bouncer.py > > (regex.compile('.*%s: User unknown.*' % email_regexp), REMOVE), > > Any comments? Any better way to do it? Nope, none apart from the obvious "This is a very sad situation" :( If you're happy with Mailman "disabling" failed addresses (as opposed to removing them), you can tweak the `automatic_bounce_action' list config option accordingly from "Bounce Options". > Idea for future enhancements... > > This is the big one. Does anyone besides me have a desire to see Mailman > support Listserv style "topics"? Where topics are extracted from the > message subject and list messages are sent to a subset of the list that > "subscribes" to that particular topic? I don't know ListServ -- what is the motivation for implementing something like this? Wouldn't a separate mailing list for each "topic" and appropriate crossposting do the same? Should there be topic-specific archives, or should the archive be topic-insensitive? To be frank, this whole idea seems rather hackish to me, though I might feel better about it if you explain _why_ you have a need for it. Of course, if this, for some reason that eludes me at the moment, is a nice feature to have in an MLM, we'd like to have it in Mailman :) -- Harald From gstein@lyra.org Wed Mar 3 19:12:25 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 03 Mar 1999 11:12:25 -0800 Subject: [Mailman-Developers] change request: admin password changing References: <36C48867.3E677BDF@lyra.org> Message-ID: <36DD8999.7E966AAD@lyra.org> Harald Meland wrote: > > [Greg Stein] > > > 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. > > I agree. I think that the change of admin password stuff belongs on > the "General options" page, and not on _all_ the pages. > > However, I'm undecided in the matter of making this (site) > configurable. IMO, making that configurable would simply be insane. Too much configurability is simply confusing to the user. Especially if the configuration brings them no actual benefits. In this case, what admin is going to say "wow. I'd be so much happier if I had that screen on *every* page. I just use it ALL the time." None. > Would anyone object if I just put in a hardcoded condition on > 'category == "general"' around the call to FormatPasswordStuff() in > Mailman.Cgi.admin.FormatConfiguration()? Seems like the simplest solution. If there is a template or something you can change instead, I'd point there. -g -- Greg Stein, http://www.lyra.org/ From petrilli@amber.org Wed Mar 3 19:16:15 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Wed, 3 Mar 1999 14:16:15 -0500 Subject: [Mailman-Developers] bounce processing question and idea for future enhancements... In-Reply-To: ; from Harald Meland on Wed, Mar 03, 1999 at 07:55:23PM +0100 References: <00b101be64d4$dfcab240$1e0a5ad1@SINGSING.STREEK.COM> Message-ID: <19990303141615.29328@amber.org> On Wed, Mar 03, 1999 at 07:55:23PM +0100, Harald Meland wrote: > > This is the big one. Does anyone besides me have a desire to see Mailman > > support Listserv style "topics"? Where topics are extracted from the > > message subject and list messages are sent to a subset of the list that > > "subscribes" to that particular topic? > > I don't know ListServ -- what is the motivation for implementing > something like this? Wouldn't a separate mailing list for each > "topic" and appropriate crossposting do the same? Should there be > topic-specific archives, or should the archive be topic-insensitive? Well, I've run a few dozen LISTSERV installations, and I've never found a use for it, honestly. :-) NOW, it was amazingly valuable back in the days of BITNET (where LISTSERV originated), and the only use I can see for it today is basically this: A company has an "announcement" list, this list is subscribed to by everyone interested, but there might be a couple of "topics": * Stuff of interest to everyone * New doodad announcements * New widget announcements * Celebrations of people being fired who deserved it :-) One might argue that it's cleaner to have a single "announcement" list and multiple "topics," but I'm not sure I've seen this being used anywhere of late. Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright From gstein@lyra.org Wed Mar 3 19:34:20 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 03 Mar 1999 11:34:20 -0800 Subject: [Mailman-Developers] Configurability (was Re: [ANNOUNCE] Mailman 1.0b9) References: <14042.58410.557890.269150@anthem.cnri.reston.va.us> Message-ID: <36DD8EBC.706CD856@lyra.org> Harald Meland wrote: > ... > For users it is always good to make _all_ the bells and whistles > configurable. However, Mailman has to find a balance between user > configurability and how efficient list delivery should be. I strongly disagree with the blanket statement that it is "always good". > This means we have to make sure that making something user > configurable won't make list delivery unbearably inefficient for any >... > The added complexity of Mailman code this would need is also an issue. Inefficiencies in list delivery are only a *small* piece of the problem. If you make something too configurable, then it becomes unapproachable. It is simply not useful any more because there are too many knobs to turn. One of John's big reasons for starting Mailman was to make a clean and simple mailing list manager. Part of this was simply a reaction against the complex Perl code in Majordomo, but John also wanted something easy for mere mortals to run. You really should not keep dropping knobs onto Mailman. Look at the problem with the settings for "who can post to this list". LOTS of people have problems with getting that set up right. The problem? Too many knobs. "What do I set to do X?" is what happens. IMO, your real task is to *reduce* the knobs, not add more. You should figure out how to automatically figure some out, or how to combine them, or simply drop them for lack of utility. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Wed Mar 3 19:39:32 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 03 Mar 1999 11:39:32 -0800 Subject: [Mailman-Developers] Re: Possible Fix for password lookup bug References: Message-ID: <36DD8FF4.454E5F4B@lyra.org> Hey Logic, Edward S. Marshall wrote: > ... > > And the reason all this extra cruft was put in place was because there > > really are some domains that differentiate based on the case of the > > username part. > > Which is explicitly allowed by RFC 822. Why should Mailman care about case > of the LHS at -all-? Why not leave it completely untouched? Or at least > have an option to leave it alone, and remain RFC-compliant. > > (Yes, I'm picking nits here, but people tend to discard standards too > often these days. RFC 822 might be full of contradictions, but it's quite > clear about preserving the case of the LHS of the address.) I believe you misunderstand. When Mailman *delivers* mail, it uses the original case of the address that was entered. It goes to great lengths to preserve that case. Within web- and email-based operation of a user's settings, however, it is performed case-insensitively. This occurs outside of mail delivery and the SMTP protocol, so it is a "legal" design choice. If you'd like, you can argue the design choice, but I'll warn you now to not try it :-). Cheers, -g -- Greg Stein, http://www.lyra.org/ From John@list.org Wed Mar 3 19:42:24 1999 From: John@list.org (John Viega) Date: Wed, 3 Mar 1999 11:42:24 -0800 Subject: [Mailman-Developers] Configurability (was Re: [ANNOUNCE] Mailman 1.0b9) In-Reply-To: <36DD8EBC.706CD856@lyra.org>; from Greg Stein on Wed, Mar 03, 1999 at 11:34:20AM -0800 References: <14042.58410.557890.269150@anthem.cnri.reston.va.us> <36DD8EBC.706CD856@lyra.org> Message-ID: <19990303114224.G8165@viega.org> Well, my philosophy on the matter is to keep the common tasks easy and the expert tasks possible. So I think there should be a basic section, and an advanced section, where there'd be some overlap. For example, in the basic section, you could just say, "give me a moderated list", but the fine grained control is available at the expert level. I don't really mind catering to everyone as long as we focus on catering to the novice, since that's most people who will be administrating or using a list... John On Wed, Mar 03, 1999 at 11:34:20AM -0800, Greg Stein wrote: > Harald Meland wrote: > > ... > > For users it is always good to make _all_ the bells and whistles > > configurable. However, Mailman has to find a balance between user > > configurability and how efficient list delivery should be. > > I strongly disagree with the blanket statement that it is "always good". > > > This means we have to make sure that making something user > > configurable won't make list delivery unbearably inefficient for any > >... > > The added complexity of Mailman code this would need is also an issue. > > Inefficiencies in list delivery are only a *small* piece of the problem. > > If you make something too configurable, then it becomes unapproachable. > It is simply not useful any more because there are too many knobs to > turn. > > One of John's big reasons for starting Mailman was to make a clean and > simple mailing list manager. Part of this was simply a reaction against > the complex Perl code in Majordomo, but John also wanted something easy > for mere mortals to run. > > You really should not keep dropping knobs onto Mailman. Look at the > problem with the settings for "who can post to this list". LOTS of > people have problems with getting that set up right. The problem? Too > many knobs. "What do I set to do X?" is what happens. > > IMO, your real task is to *reduce* the knobs, not add more. You should > figure out how to automatically figure some out, or how to combine them, > or simply drop them for lack of utility. > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From gstein@lyra.org Wed Mar 3 19:50:33 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 03 Mar 1999 11:50:33 -0800 Subject: [Mailman-Developers] Configurability (was Re: [ANNOUNCE] Mailman 1.0b9) References: <14042.58410.557890.269150@anthem.cnri.reston.va.us> <36DD8EBC.706CD856@lyra.org> <19990303114224.G8165@viega.org> Message-ID: <36DD9289.2DF47F24@lyra.org> John Viega wrote: > > Well, my philosophy on the matter is to keep the common tasks easy and > the expert tasks possible. So I think there should be a basic > section, and an advanced section, where there'd be some overlap. For > example, in the basic section, you could just say, "give me a > moderated list", but the fine grained control is available at the > expert level. I don't really mind catering to everyone as long as we > focus on catering to the novice, since that's most people who will be > administrating or using a list... This is good only to a point. Many people still feel the need to review all the options to ensure they have it set properly. Pushing stuff off to an "Advanced" area requires explicit doc to ensure that people can comfortably ignore those options. For example, you couldn't just shift some of the current admin options to a new screen labeled "Advanced." People will just walk right down the list of screens and hit the Advanced and they would effectively have all those knobs available. Anyways, this seems to be getting more into UI design, than breadth of configuration. I still believe in my original point of reducing the number of knobs, not blindly adding to them under some notion that it helps the user. Your refinement works for me as long as the Advanced stuff isn't too readily available (thereby rendering them "not available" for most intents and purposes). Cheers, -g -- Greg Stein, http://www.lyra.org/ From lindsey@ncsa.uiuc.edu Wed Mar 3 20:00:37 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Wed, 3 Mar 1999 14:00:37 -0600 (CST) Subject: [Mailman-Developers] Re: Possible Fix for password lookup bug In-Reply-To: <36DD8FF4.454E5F4B@lyra.org> from "Greg Stein" at Mar 3, 99 11:39:32 am Message-ID: <199903032000.OAA04401@ferret.ncsa.uiuc.edu> > I believe you misunderstand. > > When Mailman *delivers* mail, it uses the original case of the address > that was entered. It goes to great lengths to preserve that case. > > Within web- and email-based operation of a user's settings, however, it > is performed case-insensitively. This occurs outside of mail delivery > and the SMTP protocol, so it is a "legal" design choice. > > If you'd like, you can argue the design choice, but I'll warn you now to > not try it :-). Can Mailman at least be changed so that the membership listing reflects the original case? Even dumping the list membership with $prefix/bin/list_members converts everything to lowercase, making it useless if the list is moving to a site that runs something like majordomo. Chris From gstein@lyra.org Wed Mar 3 20:02:44 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 03 Mar 1999 12:02:44 -0800 Subject: [Mailman-Developers] Re: Possible Fix for password lookup bug References: <199903032000.OAA04401@ferret.ncsa.uiuc.edu> Message-ID: <36DD9564.3CA9DDF9@lyra.org> Christopher Lindsey wrote: >... > Can Mailman at least be changed so that the membership listing reflects > the original case? Even dumping the list membership with > $prefix/bin/list_members converts everything to lowercase, making > it useless if the list is moving to a site that runs something > like majordomo. I'm not the right "To:" recipient here... :-) I'm just a poor sucker who uses it rather than somebody who can truly fix problems :-) Check out the --preserve (-p) switch to list_members. It case-preserves the output. Cheers, -g p.s. seems like somebody else has a time machine around here... Barry, have you been borrowing Guido's again? :-) -- Greg Stein, http://www.lyra.org/ From roy@endeavor.med.nyu.edu Wed Mar 3 20:23:56 1999 From: roy@endeavor.med.nyu.edu (Roy Smith) Date: Wed, 03 Mar 1999 15:23:56 -0500 Subject: [Mailman-Developers] Configurability (was Re: [ANNOUNCE] Mailman 1.0b9) In-Reply-To: <36DD8EBC.706CD856@lyra.org> Message-ID: <1637799.3129463436@qwerky.med.nyu.edu> I agree 300%. Once something has a zillion different options, it just becomes too complicated to get your head around and understand. Often, it's not obvious which options are trivial (i.e. set the color the text in the title bar) and which are important (i.e. specify the hostname of the mail server). Also, the more options you have, the more unexpected combinations there are. "I never thought anybody would be stupid enough to set their text color to red, their background color to red, and their highlight color to red, all at the same time!" It also makes it harder for help desk people to provide useful help. Anybody who has ever done help desk duty knows how frustrating it is to talk to somebody on the phone and tell them to "click the xyz button in the upper left hand corner of the window" only to have the user say there is no such button, and the problem turns out that they've simply reconfigured their client so much that the button is now somewhere else. --On Wed, Mar 3, 1999 11:34 AM -0800 Greg Stein wrote: > If you make something too configurable, then it becomes unapproachable. > It is simply not useful any more because there are too many knobs to > turn. Roy Smith New York University School of Medicine 550 First Avenue, New York, NY 10016 From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Mar 3 20:33:21 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 3 Mar 1999 15:33:21 -0500 (EST) Subject: [Mailman-Developers] Configurability (was Re: [ANNOUNCE] Mailman 1.0b9) References: <14042.58410.557890.269150@anthem.cnri.reston.va.us> <36DD8EBC.706CD856@lyra.org> <19990303114224.G8165@viega.org> <36DD9289.2DF47F24@lyra.org> Message-ID: <14045.40081.721646.988552@anthem.cnri.reston.va.us> >>>>> "GS" == Greg Stein writes: GS> Anyways, this seems to be getting more into UI design, than GS> breadth of configuration. Yeah, there's really only so much you can do with Web forms anyway. Gawd they suck for UI. GS> I still believe in my original point of reducing the number of GS> knobs, not blindly adding to them under some notion that it GS> helps the user. Your refinement works for me as long as the GS> Advanced stuff isn't too readily available (thereby rendering GS> them "not available" for most intents and purposes). I agree (especially for the mythical 1.0 :-). Besides, I claim that the Python code for Mailman is vastly more approachable than the Perl code for Majordomo. Individual site admins are always free to hack the code. Our job is not necessarily to support every wish or request under the sun. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Mar 3 20:35:59 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 3 Mar 1999 15:35:59 -0500 (EST) Subject: [Mailman-Developers] Re: Possible Fix for password lookup bug References: <199903032000.OAA04401@ferret.ncsa.uiuc.edu> <36DD9564.3CA9DDF9@lyra.org> Message-ID: <14045.40239.564186.680304@anthem.cnri.reston.va.us> >>>>> "GS" == Greg Stein writes: GS> p.s. seems like somebody else has a time machine around GS> here... Barry, have you been borrowing Guido's again? :-) Hey, he's on vacation. What he doesn't know won't hurt me... um, him. -Barry From lindsey@ncsa.uiuc.edu Wed Mar 3 21:15:25 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Wed, 3 Mar 1999 15:15:25 -0600 (CST) Subject: [Mailman-Developers] Re: Possible Fix for password lookup bug In-Reply-To: <36DD9564.3CA9DDF9@lyra.org> from "Greg Stein" at Mar 3, 99 12:02:44 pm Message-ID: <199903032115.PAA04843@ferret.ncsa.uiuc.edu> > I'm not the right "To:" recipient here... :-) I'm just a poor sucker > who uses it rather than somebody who can truly fix problems :-) > > Check out the --preserve (-p) switch to list_members. It case-preserves > the output. Oops. Sorry. I'm really embarassed. I got too caught up in the moment... It *would* be nice to have the Web page display the subscribers in a case sensitive format, just for continuity's sake. But it's a lot less minor now that I realize my gaffe with regard to list_members. :) Here's another feature request, though... From the membership page it would be very nice to be able to click on a subscriber's name, then have it take me to a page for that user's specific settings. Options would include generation of a new password, changing the password to one chosen by the admin, renaming this address to a new address (such as when a user switches ISPs), etc. Chris From neves@inf.puc-rio.br Wed Mar 3 23:06:41 1999 From: neves@inf.puc-rio.br (Paulo Eduardo Neves) Date: Wed, 03 Mar 1999 20:06:41 -0300 Subject: [Mailman-Developers] Mailman in SunWorld online Message-ID: <36DDC081.95B3C697@inf.puc-rio.br> Take a look at: http://www.sunworld.com/swol-03-1999/swol-03-mailtools.html?0302a -- Paulo Eduardo Neves PUC-Rio de Janeiro Pager: Central: 292-4499 cod. 213 99 64 ou use a URL: http://www.learn.fplf.org.br/neves/mensagempager.html From claw@kanga.nu Thu Mar 4 04:15:22 1999 From: claw@kanga.nu (J C Lawrence) Date: Wed, 03 Mar 1999 20:15:22 -0800 Subject: [Mailman-Developers] Re: [Mailman-Users] Re: [Mailman-Developers] Re: [Mailman-Users]Possible Fix for password lookup bug Fix for password lookup bug In-Reply-To: Message from Brian Ryner of "Wed, 03 Mar 1999 11:13:00 CST." <36DD6D9C.B86B1B44@uiuc.edu> Message-ID: On Wed, 03 Mar 1999 11:13:00 -0600 Brian Ryner wrote: > Hm, I'm not so sure about that. Allowing users to subscribe > different capitalizations of their address (and hence receive the > mail multiple times) seems like it's asking for a lot of mixups with > novice users. Do two things: 1) Send a warning notice to the list owner. 2) Send a notice of a possible duplicate to the subscriber. For #2 don't quote the other address that is being subscribed, just state the fact of. This would be on the confirmation message or on the ack message for unconfirmed subscriptions. -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From claw@kanga.nu Thu Mar 4 05:12:51 1999 From: claw@kanga.nu (J C Lawrence) Date: Wed, 03 Mar 1999 21:12:51 -0800 Subject: [Mailman-Developers] Re: [Mailman-Users] [ANNOUNCE] Mailman 1.0b9 In-Reply-To: Message from Harald Meland of "03 Mar 1999 18:33:42 +0100." Message-ID: On 03 Mar 1999 18:33:42 +0100 Harald Meland wrote: > As this (currently) is a non-standard header, I wouldn't feel good > about putting explicit support for it into Mailman. However, a more > general "Add this header (standard or not) (if it doesn't exist > already) to all messages to this list" might be good. But not for > 1.0, methinks. This has my vote, as well as a set of pages to configure MailMan's defaults for all other lists. *THAT* would be incredibly useful especially for corporate sites (I'm trying to roll out MailMan at VA Research). Note: The default business should work as follows: All list config are either "default" or deviations from default. Ergo, if a list is configured and MailMan's defaults are later changed, the following would happen: -- if the value is the same as the prior default, change the value to the new default. -- if the value was changed from the prior default, leave it at its current setting. > There are lots of other good candidates for user configurable > options concerning outgoing list messages: Adding a Reply-To: > header, including the list footer, including the list header, and of > course VERP. I'd love an option to support only MIME digests and to turn off support for RFC (forget number) digests. I'd also love an option to set a Reply-To specific to digests and different from the list config for individual messages (I set it to a Please.Do.Not.Reply.to.Digests.Burst.Instead@whereever). Version 1.x stuff. -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From claw@kanga.nu Thu Mar 4 05:18:26 1999 From: claw@kanga.nu (J C Lawrence) Date: Wed, 03 Mar 1999 21:18:26 -0800 Subject: [Mailman-Developers] bounce processing question and idea for future enhancements... In-Reply-To: Message from Harald Meland of "03 Mar 1999 19:55:23 +0100." Message-ID: On 03 Mar 1999 19:55:23 +0100 Harald Meland wrote: > [Jeff Hahn] >> This is the big one. Does anyone besides me have a desire to see >> Mailman support Listserv style "topics"? Where topics are >> extracted from the message subject and list messages are sent to a >> subset of the list that "subscribes" to that particular topic? > I don't know ListServ -- what is the motivation for implementing > something like this? Wouldn't a separate mailing list for each > "topic" and appropriate crossposting do the same? Should there be > topic-specific archives, or should the archive be topic-insensitive? > To be frank, this whole idea seems rather hackish to me, though I > might feel better about it if you explain _why_ you have a need for > it. A long long time ago in a computing universe utterly unrelated to Linux (or MS for that matter) I used list software which allowed users to define patterns (lists of keywords and simple wildcards) with the result that they would only be sent messages which matched the defined expressions __plus__ (and this was the cool bit) N messages in that thread after a match (where N was of course configurable. Further useful intelligence had the list send M further posts of threads if the subscriber posted to that thread (overriding pattern matching). This allowed filtering at the server end, and was incredibly useful for high traffic lists (err, "forums" in that context). -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From claw@kanga.nu Thu Mar 4 05:26:50 1999 From: claw@kanga.nu (J C Lawrence) Date: Wed, 03 Mar 1999 21:26:50 -0800 Subject: [Mailman-Developers] Configurability (was Re: [ANNOUNCE] Mailman 1.0b9) In-Reply-To: Message from Greg Stein of "Wed, 03 Mar 1999 11:34:20 PST." <36DD8EBC.706CD856@lyra.org> Message-ID: On Wed, 03 Mar 1999 11:34:20 -0800 Greg Stein wrote: > You really should not keep dropping knobs onto Mailman. Look at the > problem with the settings for "who can post to this list". LOTS of > people have problems with getting that set up right. The problem? > Too many knobs. "What do I set to do X?" is what happens. The fault there is not in the feature set. The fault is in the design of the feature set. I've been there. You can do it in simple ways (simpler than the current method) that communicate clearly and are obvious to neophyte users: Who can subscribe? (Anyone, moderator approved) Who can post? (Anyone, only subscribers, only nominated subscribers) What happens to unsubscribed posts? (silently deleted, held for approval, bounced beck to sender with defined message). You then need to make posting rights (ie bypassing moderation) an attribute of the user account, modifiable only by the list owner (the current list of approved addresses, which is not maintained against accounts or unsubscriptions sucks). > IMO, your real task is to *reduce* the knobs, not add more. You > should figure out how to automatically figure some out, or how to > combine them, or simply drop them for lack of utility. Quite. Presentation is also key. -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From claw@kanga.nu Thu Mar 4 05:34:30 1999 From: claw@kanga.nu (J C Lawrence) Date: Wed, 03 Mar 1999 21:34:30 -0800 Subject: [Mailman-Developers] Configurability (was Re: [ANNOUNCE] Mailman 1.0b9) In-Reply-To: Message from John Viega of "Wed, 03 Mar 1999 11:42:24 PST." <19990303114224.G8165@viega.org> Message-ID: On Wed, 3 Mar 1999 11:42:24 -0800 John Viega wrote: > Well, my philosophy on the matter is to keep the common tasks easy > and the expert tasks possible. So I think there should be a basic > section, and an advanced section, where there'd be some overlap. > For example, in the basic section, you could just say, "give me a > moderated list", but the fine grained control is available at the > expert level. I don't really mind catering to everyone as long as > we focus on catering to the novice, since that's most people who > will be administrating or using a list... Specifically: VA Research has a need for a list server that presents only the following options upon list creation (web preferred): Name of list. Reply-To option. Open/closed subscription option. Subscribers only from specified domain text field. Bounces go to MailMan owner or list owner option. Support digests option. The actual need is for someone in HR, a computer illiterate someone who just understands typewriters, to be able to create a list on demand which central IS can then do the background management for (bounces etc) but is otherwise default configured and obvious. They *really* like MailMan. They just need a severely dumbed down interface to list creation for it. -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From jeffh@streek.com Thu Mar 4 05:56:13 1999 From: jeffh@streek.com (Jeff Hahn) Date: Wed, 3 Mar 1999 23:56:13 -0600 Subject: [Mailman-Developers] TOPICS (was bounce processing question and idea for future enhancements...) In-Reply-To: Message-ID: <000001be6603$b5d19960$1e0a5ad1@SINGSING.STREEK.COM> Thanks to Harald and Chris for their input... Listserv topics work like this: Messages sent to the list include one or more keywords (topics) in the subject. There is a defined set of topics for the list. Subscribers can choose to receive messages for individual topics. When the MLM receives a message, it extracts the topics from the subject. To deliver a message, the MLM intersects the set of topics in the message with the set of topics that a given subscriber has chosen (to use set terminology). If the intersection is non-empty, that subscriber gets the message, otherwise not. there is usually an "ADMIN" topic that is sent to ALL listmember and has restricted posting. Subscribers can choose whether or not to "subscribe to New topics automatically", so that when topics are added, the member list can be updated. Messages without a valid topic are optionally rejected. Here is my actually situation: I run a set of mailing lists for mostly inexperienced users. There is a great deal of overlap amongst the lists. The lists are very active. Up to 250,000 deliveries per week to about 500 total subscribers. 100 or more messages per day to members of all the lists are not uncommon. These lists all concern the Bloodhound dog breed. There are people interested in showing bloodhounds. There are people interested in using bloodhounds to trail people. There are people interested in breeding bloodhounds. There are people interested in rescuing bloodhounds from animal shelters. there is a certain amount of "chat" going on as well. Many people are interested in most of the topics, but usually have one or two that they're not interested in. The show people may not be interested in trailing. The breeders aren't interested in rescue. The rescue people aren't interested in showing. There is a group of people not interested in the chat. You get the idea. There are currently 4 lists and given the experience level of most of the users, admin is a nightmare. People send message to the wrong list. They unsubscribe from the wrong list. They can't figure out why they're still getting individual messages when they've set one of the lists to digest. When they've got something they think is really important, they send it to all 4 lists, "just to make sure" and 85% of the people get 4 copies of the message. There is enough "political turmoil" that certain people really don't want to receive certain topics. I'd be happy if the digests and archives were all inclusive (all topics). Topics would allow just one list to admin, one set of bounces to deal with, one "I want to get the digest", etc. This would give my subscribers a "finer granularity" in controlling the content they wish to receive, without making me administer a dozen lists. I've move a number of my "less difficult" lists away from procmail/smartlist to Mailman and am very happy. But the headaches of dealing with this group of lists is what sent me on the search for a new MLM. I've tried to approach this problem from a number of different angles and this idea is the only one that seems promising. I'm open to suggestions! If anyone has a less complex way to deal with this I'd love it. -Jeff From tismer@appliedbiometrics.com Thu Mar 4 14:05:12 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Thu, 04 Mar 1999 15:05:12 +0100 Subject: [Mailman-Developers] Setup prob: abs/rel CGI url Message-ID: <36DE9318.59C0C8D8@appliedbiometrics.com> Hi Mailman developers, I've set up Mailman 1.0b9 for starship.skyport.net exactly as the INSTALL file said. It is working so far, with one exception: When I try to use the admin page for my test list, I first get the password dialog, as usual. After entering the password, Mailman complains that the list "mailman" is nonexistent. Reason: The CGI of the password dialog contains a relative CGI URL: test Administrative Authentication
which causes the URL to pile up to http://starship.skyport.net/mailman/admin/mailman/admin/test and leads to the message that a list "mailman" indeed does not exist. :-) I think I have checked everything against the 1.0b7 installation on python.net and couldnot find any difference whcih mght cause this. The only real difference is that skyport.net still runs an early Python 1.5 version. Please help, I cannot find the bug. Can it be due to Python 1.5 ? cheers - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home From tismer@appliedbiometrics.com Thu Mar 4 14:46:41 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Thu, 04 Mar 1999 15:46:41 +0100 Subject: [Mailman-Developers] MM1.0b9 Bug! (was: Setup prob: abs/rel CGI url) References: <36DE9318.59C0C8D8@appliedbiometrics.com> Message-ID: <36DE9CD1.60544B41@appliedbiometrics.com> Hi Barry et al, I found it - Mailman 1.0b9 has a bug in admin.py . Line 121 ff: if not is_auth: defaulturi = 'mailman/admin%s/%s' % (mm_cfg.CGIEXT, list_name) print "Content-type: text/html\n\n" text = Utils.maketext( 'admlogin.txt', {"listname": list_name, "path" : os.environ.get("REQUEST_URI", defaulturi), "message" : message, }) print text return defaulturi is *wrong*, it needs a slash in front. How comes that nobody complained yet? This means that no user has used the admin pages since he upgraded to 1.0b9 !?! ciao - chris Christian Tismer wrote: > > Hi Mailman developers, > > I've set up Mailman 1.0b9 for starship.skyport.net exactly > as the INSTALL file said. It is working so far, with one exception: > > When I try to use the admin page for my test list, I first get > the password dialog, as usual. > After entering the password, Mailman complains that the list > "mailman" is nonexistent. > Reason: > The CGI of the password dialog contains a relative CGI URL: > > > test Administrative Authentication > ACTION="mailman/admin/test"> > > which causes the URL to pile up to > http://starship.skyport.net/mailman/admin/mailman/admin/test > > and leads to the message that a list "mailman" indeed > does not exist. :-) > > I think I have checked everything against the 1.0b7 installation > on python.net and couldnot find any difference whcih mght cause > this. > The only real difference is that skyport.net still runs an early > Python 1.5 version. > > Please help, I cannot find the bug. Can it be due to Python 1.5 ? > > cheers - chris > > -- > Christian Tismer :^) > Applied Biometrics GmbH : Have a break! Take a ride on Python's > Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net > 10553 Berlin : PGP key -> http://wwwkeys.pgp.net > PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF > we're tired of banana software - shipped green, ripens at home > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home From Harald.Meland@usit.uio.no Thu Mar 4 17:25:56 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 04 Mar 1999 18:25:56 +0100 Subject: [Mailman-Developers] Configurability (was Re: [ANNOUNCE] Mailman 1.0b9) In-Reply-To: Greg Stein's message of "Wed, 03 Mar 1999 11:34:20 -0800" References: <14042.58410.557890.269150@anthem.cnri.reston.va.us> <36DD8EBC.706CD856@lyra.org> Message-ID: [Greg Stein] > Harald Meland wrote: > > ... > > For users it is always good to make _all_ the bells and whistles > > configurable. However, Mailman has to find a balance between user > > configurability and how efficient list delivery should be. > > I strongly disagree with the blanket statement that it is "always good". Sorry, I phrased that rather badly -- what I meant to propagate, was that there's always _some_ user that wants more configurability. If Mailman should cater to any and all of these wishes, it would be a) inefficient and b) (as you point out) a terrible mess. Sorry about the confusion. > You really should not keep dropping knobs onto Mailman. ... unless there is a real need for them, I presume? > Look at the problem with the settings for "who can post to this > list". LOTS of people have problems with getting that set up > right. The problem? Too many knobs. Well, the "too many knobs" issue of "who can post" is (at least in part) caused by the "rather finegrained control" many list admins want over who can post. So, the problem is not merely to reduce the number of buttons, but to do so while _keeping needed functionality_. -- Harald From Harald.Meland@usit.uio.no Thu Mar 4 18:08:34 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 04 Mar 1999 19:08:34 +0100 Subject: [Mailman-Developers] TOPICS (was bounce processing question and idea for future enhancements...) In-Reply-To: Jeff Hahn's message of "Wed, 3 Mar 1999 23:56:13 -0600" References: <000001be6603$b5d19960$1e0a5ad1@SINGSING.STREEK.COM> Message-ID: [Jeff Hahn] > Listserv topics work like this: > > Messages sent to the list include one or more keywords (topics) in the > subject. There is a defined set of topics for the list. Subscribers can > choose to receive messages for individual topics. > > When the MLM receives a message, it extracts the topics from the subject. > To deliver a message, the MLM intersects the set of topics in the message > with the set of topics that a given subscriber has chosen (to use set > terminology). If the intersection is non-empty, that subscriber gets the > message, otherwise not. > > there is usually an "ADMIN" topic that is sent to ALL listmember and has > restricted posting. Subscribers can choose whether or not to "subscribe to > New topics automatically", so that when topics are added, the member list > can be updated. > > Messages without a valid topic are optionally rejected. My feelings on this are rather mixed: While I can see the use something like this would have when your users are inexperienced, I'm still not sure that I would be able to tell it apart from some featuritis-infected hack :) Anyhow, I guess that implementing this would be a lot easier (and cleaner) if every list member had some "user objects" -- and that is planned for after 1.0. So I guess we'll think about it all until we have the infrastructure to implement it on top of in place. -- Harald From Harald.Meland@usit.uio.no Thu Mar 4 18:21:19 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 04 Mar 1999 19:21:19 +0100 Subject: [Mailman-Developers] MM1.0b9 Bug! (was: Setup prob: abs/rel CGI url) In-Reply-To: Christian Tismer's message of "Thu, 04 Mar 1999 15:46:41 +0100" References: <36DE9318.59C0C8D8@appliedbiometrics.com> <36DE9CD1.60544B41@appliedbiometrics.com> Message-ID: [Christian Tismer] > Hi Barry et al, > > I found it - Mailman 1.0b9 has a bug in admin.py . Which was fixed _days_ ago in CVS :-) > defaulturi = 'mailman/admin%s/%s' % (mm_cfg.CGIEXT, [...] > "path" : os.environ.get("REQUEST_URI", defaulturi), [...] > defaulturi is *wrong*, it needs a slash in front. > > How comes that nobody complained yet? If your web server provides CGI scripts with an REQUEST_URI environment variable, the fallback value of `defaulturi' won't be used. This has been further refined in the current CVS version -- first try REQUEST_URI (which isn't part of the CGI/1.1 spec), then try concatenation of SCRIPT_NAME and PATH_INFO (both of which _are_ part of CGI/1.1), then fall back on the (corrected) defaulturi. -- Harald From tismer@appliedbiometrics.com Thu Mar 4 18:40:13 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Thu, 04 Mar 1999 19:40:13 +0100 Subject: [Mailman-Developers] MM1.0b9 Bug! (was: Setup prob: abs/rel CGI url) References: <36DE9318.59C0C8D8@appliedbiometrics.com> <36DE9CD1.60544B41@appliedbiometrics.com> Message-ID: <36DED38D.34DE263F@appliedbiometrics.com> Harald Meland wrote: > > [Christian Tismer] > > > Hi Barry et al, > > > > I found it - Mailman 1.0b9 has a bug in admin.py . > > Which was fixed _days_ ago in CVS :-) That's great. An average user will step into this trap, since 1.0b9 is the current version. If one always has to check CVS, it makes no sense to publish the zip file at all. I have to say: 10.b9 was published without proper testing. ... > > How comes that nobody complained yet? > > If your web server provides CGI scripts with an REQUEST_URI > environment variable, the fallback value of `defaulturi' won't be > used. I see. I was just hit since my Apache isn't the latest version. Anyway, the "/mailman/anything" strings are a little spread around in the sources. In my opinion, it would be safer to keep them in a central place (Defaults.py maybe) and just use references. ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home From Harald.Meland@usit.uio.no Thu Mar 4 22:49:27 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 04 Mar 1999 23:49:27 +0100 Subject: [Mailman-Developers] Install clarification In-Reply-To: Christian Tismer's message of "Wed, 03 Mar 1999 16:52:54 +0100" References: <36DD5AD6.66210472@appliedbiometrics.com> Message-ID: [Christian Tismer] > Can it be that the chmod should better read like > "chmod a+rx,g+ws ." ? It can, indeed. Fixed and checked in. > newlist has been changed somewhere between 1.0b7 and 1.0b9 > in the wrong way, and the change has obviously not been > tested! [...] > The "import paths" must go *before* the try..except True -- fixed and checked in. Thanks a lot for the feedback! -- Harald From neves@inf.puc-rio.br Fri Mar 5 01:30:45 1999 From: neves@inf.puc-rio.br (Paulo Eduardo Neves) Date: Thu, 04 Mar 1999 22:30:45 -0300 Subject: [Mailman-Developers] Re: TOPICS References: <000001be6603$b5d19960$1e0a5ad1@SINGSING.STREEK.COM> Message-ID: <36DF33C5.48788862@inf.puc-rio.br> Harald Meland wrote: > Anyhow, I guess that implementing this would be a lot easier (and > cleaner) if every list member had some "user objects" -- and that is > planned for after 1.0. So I guess we'll think about it all until we > have the infrastructure to implement it on top of in place. I've read in the TO-DO list about User profiles, is it the same of user object? Could you explain the idea behind it? I believe it would solve well a problem I have. I have an announcement list where I send messages about a lot of topics. Not all topics are of interest of all subscribers (i.e. Joe doesn't want to know about events in other state). It looks like user profiles (or Topics) would solve this problem. regards, -- Paulo Eduardo Neves PUC-Rio de Janeiro Pager: Central: 292-4499 cod. 213 99 64 ou use a URL: http://www.learn.fplf.org.br/neves/mensagempager.html From paz@apriori.net Fri Mar 5 02:31:55 1999 From: paz@apriori.net (paz) Date: Thu, 4 Mar 1999 21:31:55 -0500 (EST) Subject: [Mailman-Developers] Does anyone else see these? Message-ID: I've gotten two admin messages to mailman-owner from a mailman list I run on apriori.net (Hummers - a humor list). (begin included text) =================================== Received: from gw.apriori.net (localhost.apriori.net [127.0.0.1]) by apriori.net (8.8.8/8.8.8) with ESMTP id CAA29989 for ; Thu, 4 Mar 1999 02:08:34 -0500 (EST) (envelope-from mailman-owner@apriori.net) Received: from gw.apriori.net (localhost.apriori.net [127.0.0.1]) by apriori.net (8.8.8/8.8.8) with ESMTP id CAA29979 for ; Thu, 4 Mar 1999 02:08:30 -0500 (EST) (envelope-from mailman-owner@apriori.net) Date: Thu, 4 Mar 1999 02:08:30 -0500 (EST) Message-Id: <199903040708.CAA29979@apriori.net> From: mailman-owner@apriori.net Subject: Hummers member redscares@spamcom.net bouncing - NOT disabled To: hummers-admin@apriori.net Errors-To: mailman-owner@apriori.net MIME-version: 1.0 Content-type: multipart/mixed; boundary="192.168.51.99.1.29976.920531310.496.13704" X-Mailman-Version: 1.0b8 Precedence: bulk List-Id: Humor email list. Parts/attachments: 1 Shown 16 lines Text 2 Shown 61 lines Text ---------------------------------------- Content-type: text/plain; charset=us-ascii This is a Mailman mailing list bounce action notice: List: Hummers Member: redscares@spamcom.net Action: Subscription not disabled. Reason: Excessive or fatal bounces. BUT: User not found. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman-owner@apriori.net. [ Part 2: "Attached Text" ] This is a MIME-encapsulated message --CAA24772.920531258/camel8.mindspring.com The original message was received at Thu, 4 Mar 1999 02:07:37 -0500 (EST) from mx10.mindspring.com [207.69.200.126] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- 550 ... Host unknown (Name server: spamcom.net: host not found) --CAA24772.920531258/camel8.mindspring.com Content-Type: message/delivery-status Reporting-MTA: dns; camel8.mindspring.com Received-From-MTA: DNS; mx10.mindspring.com Arrival-Date: Thu, 4 Mar 1999 02:07:37 -0500 (EST) Final-Recipient: RFC822; redscares@spamcom.net Action: failed Status: 5.1.2 Remote-MTA: DNS; spamcom.net Last-Attempt-Date: Thu, 4 Mar 1999 02:07:38 -0500 (EST) --CAA24772.920531258/camel8.mindspring.com Content-Type: text/rfc822-headers Return-Path: Received: from mx10.mindspring.com (mx10.mindspring.com [207.69.200.126]) by camel8.mindspring.com (8.8.5/8.8.5) with SMTP id CAA01606 for ; Thu, 4 Mar 1999 02:07:37 -0500 (EST) From: hummers-admin@apriori.net X-MindSpring-Loop: t-eaton@mindspring.com Received: from apriori.net ([209.192.153.107]) by mx10.mindspring.com (Mindspring Mail Service) with ESMTP id rdsc9m.i37.37kbi3u for ; Thu, 4 Mar 1999 02:07:34 -0500 (EST) Received: from gw.apriori.net (localhost.apriori.net [127.0.0.1]) by apriori.net (8.8.8/8.8.8) with ESMTP id CAA29959; Thu, 4 Mar 1999 02:08:03 -0500 (EST) (envelope-from hummers-admin@apriori.net) Received: from localhost (jokes-in@localhost) by apriori.net (8.8.8/8.8.8) with SMTP id CAA29933 for ; Thu, 4 Mar 1999 02:07:52 -0500 (EST) (envelope-from jokes-in@apriori.net) Date: Thu, 4 Mar 1999 02:07:51 -0500 (EST) To: hummers@apriori.net Subject: [Hummers] The Short List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hummers-admin@apriori.net Errors-To: hummers-admin@apriori.net X-Mailman-Version: 1.0b8 Precedence: bulk List-Id: Humor email list. X-BeenThere: hummers@apriori.net --CAA24772.920531258/camel8.mindspring.com-- ========================================== (end included text) redscares@spamcom.net (obviously) is not a subscriber of list Hummers, yet the message seems to think he is. Therefore I can't delete from the subscriber list one who isn't subscribed... In the line: X-MindSpring-Loop: t-eaton@mindspring.com user t-eaton@mindspring.com IS a subscriber, however. Does anyone know what's going on with this? cheers - -- Philip. philip zimmermann paz@apriori.net www.apriori.net ayer, ma usa From lindsey@ncsa.uiuc.edu Fri Mar 5 07:17:53 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Fri, 5 Mar 1999 01:17:53 -0600 (CST) Subject: [Mailman-Developers] Does anyone else see these? In-Reply-To: from "paz" at Mar 4, 99 09:31:55 pm Message-ID: <199903050717.BAA14803@ferret.ncsa.uiuc.edu> > I've gotten two admin messages to mailman-owner from a mailman list I run > on apriori.net (Hummers - a humor list). This isn't a Mailman issue, it's an issue with the recepients email configuration. He's forwarding the message on from t-eaton@mindspring.com to redscares@spamcom.net while preserving the original envelope address. This is A Bad Thing because mail is being bounced back to mailman-owner@apriori.net instead of to the person who set up the forwarding. This is one example why one usually shouldn't preserve the envelope sender when forwarding mail. > redscares@spamcom.net (obviously) is not a subscriber of list Hummers, > yet the message seems to think he is. Therefore I can't delete from > the subscriber list one who isn't subscribed... > > In the line: > > X-MindSpring-Loop: t-eaton@mindspring.com > > user t-eaton@mindspring.com IS a subscriber, however. Yes, fortunately mindspring.com put in that header for you. In your case you can also tell for whom the mail was intended by looking at the Received: headers, but that's not always true (I believe sendmail takes out the recepient name if more than one address is being delivered to in the same SMTP transaction. That also means that you wouldn't be able to narrow down the address without manually probing all accounts at that domain). Perhaps Mailman could add (yet another) header indicating the targetted recepient to help with this type of situation? Maybe X-Mailman-Recepient? Or it could be wrapped it into another header like X-BeenThere... Chris From Harald.Meland@usit.uio.no Fri Mar 5 17:35:36 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 05 Mar 1999 18:35:36 +0100 Subject: [Mailman-Developers] Re: TOPICS In-Reply-To: Paulo Eduardo Neves's message of "Thu, 04 Mar 1999 22:30:45 -0300" References: <000001be6603$b5d19960$1e0a5ad1@SINGSING.STREEK.COM> <36DF33C5.48788862@inf.puc-rio.br> Message-ID: [Paulo Eduardo Neves] > Harald Meland wrote: > > Anyhow, I guess that implementing this would be a lot easier (and > > cleaner) if every list member had some "user objects" -- and that is > > planned for after 1.0. So I guess we'll think about it all until we > > have the infrastructure to implement it on top of in place. > > I've read in the TO-DO list about User profiles, is it the same of user > object? Not quite, but they're not unrelated, either. > Could you explain the idea behind it? Well, the motivation I have for implementing "user objects", is that I don't want one particular user that is subscribed to several Mailman mailing lists (on the same Mailman installation) to have to remember one password per list. If Mailman had an installation-wide database of all members subscribed to any of the lists, and each list had "pointers" pointing to specific user objects in this database (meaning that the users corresponding to the pointed-to objects are members of the pointing-from list), the user password could be kept in the user object instead of with each list. You'd also get a lot of other benefits from this, of course: * User objects could know about the different mail aliases belonging to one user (meaning that Mailman would know that `hmeland@usit.uio.no' and `harald.meland@usit.uio.no' were really the same user, which is very handy for "restrict posting privilege to list members") * Admins are users as well -- thus their _single_ admin password, which would work for all the lists they admin, could be stored in a (special) user object. Lists with multiple admins wouldn't need their admins to share the single list password anymore. * If some person changes email address, update the person's user object -- and all the mailing lists the person is a member of automatically goes to the new address. Ditto for disabling delivery when going on vacation etc. Having separate settings for different lists should of course remain possible. ... just to mention a few things. None of this is set in stone, of course -- these are just some ideas I have, nothing has actually been implemented. "Member profiles", I think, means that you each user can organize their subscriptions into hierarchies (within their user object) -- thus, any changes made to the root node in the hierarchy gets inherited by all your subscriptions. Example: * Root node | * Python mailing lists | * "Mailman-users" subscription options * "Mailman-developers" subscription options * Work-related mailing lists | * "postmaster" subscription options * "hostmaster" subscription options * "webmaster" subscription options Your local mail system has recently been upgraded to support addresses of the form `username+suffix@example.com', signifying that mail to this address goes directly into your IMAP folder called `suffix'. You want to use separate mail addresses for the python lists and the work-related lists -- so you enter each of these "member profiles" and update them, and the changes propagate down the tree to the different lists. Voila :) > I believe it would solve well a problem I have. I have an announcement > list where I send messages about a lot of topics. Not all topics are of > interest of all subscribers (i.e. Joe doesn't want to know about events > in other state). > > It looks like user profiles (or Topics) would solve this problem. Topics are not the same as member profiles. The (hypothetic) user "Topics" setting are meant to signify what subset of messages you want to receive from a topic-enabled Mailman list, while member profiles are for specifying defaults for subsets of your list subscriptions (regardless of whether the subscribed-to lists are topic-enabled or not). I was merely stating that for implementing topics, one needs to keep so much user-specific information (on what topics are deemed interesting) in Mailman, that keeping off implementing it until _after_ the introduction of user objects (which will provide a handy mechanism for storing user-specific information) would seem like a smart move. -- Harald From Harald.Meland@usit.uio.no Fri Mar 5 17:52:57 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 05 Mar 1999 18:52:57 +0100 Subject: [Mailman-Developers] MM1.0b9 Bug! (was: Setup prob: abs/rel CGI url) In-Reply-To: Christian Tismer's message of "Thu, 04 Mar 1999 19:40:13 +0100" References: <36DE9318.59C0C8D8@appliedbiometrics.com> <36DE9CD1.60544B41@appliedbiometrics.com> <36DED38D.34DE263F@appliedbiometrics.com> Message-ID: [Christian Tismer] > Harald Meland wrote: > > > > [Christian Tismer] > > > > > Hi Barry et al, > > > > > > I found it - Mailman 1.0b9 has a bug in admin.py . > > > > Which was fixed _days_ ago in CVS :-) > > That's great. > An average user will step into this trap, since 1.0b9 is the > current version. If one always has to check CVS, it makes > no sense to publish the zip file at all. On the contrary. Releasing betas are _part of_ testing new software. Please understand that I'm not saying that I don't appreciate you tracking down bugs in Mailman betas -- because I do, really -- but I thought it appropriate to respond and say that you could get a better fix for your problem from CVS. > I have to say: 10.b9 was published without proper testing. That depends on what you mean by "proper testing". If "proper testing" means compiling with all available of the hordes of different compilers available on lots and lots of OSes with all combinations of "configure" options, and then doing test runs of all parts of Mailman with all combinations of web servers, MTAs, Python releases, and whatnot, there is _no way_ we will get 1.0 out before the end of the century. The core developers _do_ typically check that changes they make appear to work right before they check them in -- but occasionally a bug slips through. > Anyway, the "/mailman/anything" strings are a little spread > around in the sources. In my opinion, it would be safer to > keep them in a central place (Defaults.py maybe) and just > use references. If you have a closer look at the places where /mailman/foobar are "spread around", I think you will see that they are usually fallbacks that are only used when the appropriate ways of getting at stuff doesn't work -- in particular, see the mm_cfg.py variables `DEFAULT_URL' and `PRIVATE_ARCHIVE_URL'. In the cases where /mailman/foobar are used as hardcoded values without any defaults, that is very likely a bug which should be fixed. Cheers, -- Harald From claw@kanga.nu Fri Mar 5 18:19:54 1999 From: claw@kanga.nu (J C Lawrence) Date: Fri, 05 Mar 1999 10:19:54 -0800 Subject: [Mailman-Developers] Does anyone else see these? In-Reply-To: Message from Christopher Lindsey of "Fri, 05 Mar 1999 01:17:53 CST." <199903050717.BAA14803@ferret.ncsa.uiuc.edu> Message-ID: On Fri, 5 Mar 1999 01:17:53 -0600 (CST) Christopher Lindsey wrote: > Perhaps Mailman could add (yet another) header indicating the > targetted recepient to help with this type of situation? Maybe > X-Mailman-Recepient? Or it could be wrapped it into another header > like X-BeenThere... One technique I used for my own list software (now defunct) was that every N'th message to each subscriber was sent individually with custom headers giving the subscription address, list name etc. All the other sends (the rest of N) were sent as per normal with 100 RCPT TO's per message. Then, instead of attempting to parse bounce formats, instead I merely looked for these custom headers in the bouce returns and tracked that way. In this way, by rotating the N thru the subscriber base so that on any one particular posting only 1/N'th of the subscribers were sent individual messages I could minimise mail load on the system and have an guaranteed accurate tracking system for who was *really* bouncing when there forwards inbetween. -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From tismer@appliedbiometrics.com Fri Mar 5 19:45:18 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Fri, 05 Mar 1999 20:45:18 +0100 Subject: [Mailman-Developers] MM1.0b9 Bug! (was: Setup prob: abs/rel CGI url) References: <36DE9318.59C0C8D8@appliedbiometrics.com> <36DE9CD1.60544B41@appliedbiometrics.com> <36DED38D.34DE263F@appliedbiometrics.com> Message-ID: <36E0344E.47E7C3E3@appliedbiometrics.com> Harald Meland wrote: > > [Christian Tismer] > > > Harald Meland wrote: > > > > > > [Christian Tismer] > > > > > > > Hi Barry et al, > > > > > > > > I found it - Mailman 1.0b9 has a bug in admin.py . > > > > > > Which was fixed _days_ ago in CVS :-) > > > > That's great. > > An average user will step into this trap, since 1.0b9 is the > > current version. If one always has to check CVS, it makes > > no sense to publish the zip file at all. > > On the contrary. Releasing betas are _part of_ testing new software. > > Please understand that I'm not saying that I don't appreciate you > tracking down bugs in Mailman betas -- because I do, really -- but I > thought it appropriate to respond and say that you could get a better > fix for your problem from CVS. I had been using 1.0b7 with success. 1.0b9 introduced a bug which caused me some trouble, and I wasn't sure where to look: Did it depend of the slightly different machine, the older Python version, or mailman? > > I have to say: 10.b9 was published without proper testing. > > That depends on what you mean by "proper testing". If "proper > testing" means compiling with all available of the hordes of different > compilers available on lots and lots of OSes with all combinations of > "configure" options, and then doing test runs of all parts of Mailman > with all combinations of web servers, MTAs, Python releases, and > whatnot, there is _no way_ we will get 1.0 out before the end of the > century. I am just saying that the changes, which affected my config unfortunately, were not tested against a machine which would use them. Besides that, I have seen some changes to some scripts which were obviously wrong and made it into the next release. Example: A number of scripts have this path hack (bin/newlist for instance), and for an older Python 1.5, a try..execpt for getpass was introduced. Nice idea, but doing this before the "import path" makes no sense, since Mailman.pythonlib isn't available before that import. I think, changes like this make it into the dist too quickly. Polite speaking is "without proper testing", my company would yell "thoughtless" at me. :c) > The core developers _do_ typically check that changes they make appear > to work right before they check them in -- but occasionally a bug > slips through. Well, you say that bug was fixed, see CVS. This means, someone fixed a bug, put it into CVS, and knew that this bug is in the b9 zip file, but... did I miss something, or was there a note on the download page that one might need a patch to get it running? I didn't want to do testing, but get the latest "stable" version and assumed that was 1.0b9 . Instead, I spent hours of figuring out known things, although I was in trouble (had just lost my old installation and needed a new one ASAP for customers). > > Anyway, the "/mailman/anything" strings are a little spread > > around in the sources. In my opinion, it would be safer to > > keep them in a central place (Defaults.py maybe) and just > > use references. > > If you have a closer look at the places where /mailman/foobar are > "spread around", I think you will see that they are usually fallbacks > that are only used when the appropriate ways of getting at stuff > doesn't work -- in particular, see the mm_cfg.py variables > `DEFAULT_URL' and `PRIVATE_ARCHIVE_URL'. Right, there are just a few places. Anyway I think it would be cleaner to remove every repetition of a fallback, default or whatever into one central place. This was not meant as crisicism, just a hint. If, for instance, the "/mailman/admin" etc. fallbacks were in one place, a typo from future changes would either not occour, or show up in a more obvious way. Be assured, I like Mailman and used it from the first days. I'm also telling everybody to use it. At the same time, whenever I want to install it, I get into some trouble. Usually I can help myself, but what about other users who just want to follow the instructions and run it? I think it would be better for MM's public acceptance if there was always a version known to be used in many installations. It would not have all new features, but also not the new bugs. In other words: If the latest beta needed a bug fix, why don't we mark it as problematic and go back to, say, 1.0b7? cheers - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home From klm@digicool.com Fri Mar 5 20:14:10 1999 From: klm@digicool.com (Ken Manheimer) Date: Fri, 5 Mar 1999 15:14:10 -0500 Subject: [Mailman-Developers] Does anyone else see these? Message-ID: <613145F79272D211914B0020AFF640190BED82@GANDALF> On Fri, 5 Mar 1999 01:17:53 -0600 (CST), Christoper Lindsey wrote: > Previously, paz@apriori.net wrote: > > I've gotten two admin messages to mailman-owner from a mailman list I run > > on apriori.net (Hummers - a humor list). > > This isn't a Mailman issue, it's an issue with the recipients email > configuration. He's forwarding the message on from t-eaton@mindspring.com > to redscares@spamcom.net while preserving the original envelope > address. This is A Bad Thing because mail is being bounced back > to mailman-owner@apriori.net instead of to the person who set up the > forwarding. This is one example why one usually shouldn't preserve the > envelope sender when forwarding mail. Good call. > > [...] > Perhaps Mailman could add (yet another) header indicating the > targetted recepient to help with this type of situation? Maybe > X-Mailman-Recepient? Or it could be wrapped it into another header > like X-BeenThere... Unfortunately, this conflicts with the way mailman delivers stuff. It batches up posts to groups of people - typically five bunches. This means that deliveries aren't to any one individual recipient. Using these batches is bound to be quicker than making an individual send for each person (particularly when the MTA implements smart batching to sites, which mailman tries to support by grouping messages bound for the same domain), so it's unlikely we'd want to defeat this feature for the traceability - though there _are_ significant places where traceability would be helpful... Ken klm@digicool.com From roger@infomed.sld.cu Fri Mar 5 20:46:13 1999 From: roger@infomed.sld.cu (=?iso-8859-1?Q?Roger_Pe=F1a_Escobio?=) Date: Fri, 5 Mar 1999 15:46:13 -0500 Subject: [Mailman-Developers] to edit de alias file Message-ID: <01be6749$355b6c10$1c7001c4@ntserver.sld.cu> Hi I was looking the alias_wrapper file in src/ subdir , trying to fix it , because the creation of a new list is, I think, incomplete if we can't edit an aliases file automatically, I found only one thing, the line 87 > execlp(SENDMAIL_CMD, SENDMAIL_CMD,"-bi"); need another argument, NULL, that is , the line should be > execlp(SENDMAIL_CMD, SENDMAIL_CMD,"-bi", NULL); and that's all, you can edit your aliases files if you have the right permission for write in it, my choice is /etc/mailman/aliases (/etc/mailman/) with write permission for group mailman , and woks fine. also I include a rmaliases for delete one list from de alias file, if anybody like it e-mail me please . I think that this feature should be in the release that's why I submit this msg. to this list, may be the developers are interested in things like this one. Roger From bkc@murkworks.com Mon Mar 8 00:29:51 1999 From: bkc@murkworks.com (Brad Clements) Date: Sun, 7 Mar 1999 20:29:51 -0400 Subject: [Mailman-Developers] MailList "base is not a class object" error Message-ID: <199903080123.UAA06834@anvil.murkworks.com> Hi, I'm porting Mailman 1.0b9 to Win32 (Python 1.5.2b2).  When running newlist.py, I get an error on line 50 of MailList.py, base is not a class object on the definition of MailList. However if I "hand import", it seems to load ok. Anyone try mailman on 1.5.2b2 yet? Any suggestions? Thanks Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937 From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Mar 9 04:24:31 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 8 Mar 1999 23:24:31 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] [ANNOUNCE] Mailman 1.0b9 References: <14042.58410.557890.269150@anthem.cnri.reston.va.us> Message-ID: <14052.41599.185573.703300@anthem.cnri.reston.va.us> >>>>> "HM" == Harald Meland writes: HM> However, a more general "Add this header (standard or not) (if HM> it doesn't exist already) to all messages to this list" might HM> be good. But not for 1.0, methinks. I agree with both points! We'll have to think about the best way to present this on the admin pages. Anyway, I've added this to the TODO file. From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Mar 9 05:02:30 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 9 Mar 1999 00:02:30 -0500 (EST) Subject: [Mailman-Developers] bounce processing question and idea for future enhancements... References: <00b101be64d4$dfcab240$1e0a5ad1@SINGSING.STREEK.COM> Message-ID: <14052.43878.793141.253201@anthem.cnri.reston.va.us> >>>>> "JH" == Jeff Hahn writes: JH> Bounce processing question... JH> Since some of the big email domains (hotmail, aol, JH> etc.) are known to "burp" and deny existence of perfectly JH> valid users, I'd like to handle all returns as bounces and not JH> remove people automatically on the first "user unknown" JH> message. I assume the way to handle it is to change "REMOVE" JH> to "BOUNCE" in the lines like the following in bouncer.py JH> (regex.compile('.*%s: User unknown.*' % email_regexp), JH> REMOVE), JH> Any comments? Any better way to do it? We've talked about changing bounce handling so that all bounces of any kind are handled similarly. They'd have a threshold over which the action would occur. By default, the address would be disabled, and then some future attempts would be made to contact the user. If they can't be reached after N number of attempts, maybe they'd be removed. That way if a user is temporarily unavailable (for whatever reason), they wouldn't get immediately nixed, and they'd have an opportunity later to re-enable themselves. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Mar 9 05:26:10 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 9 Mar 1999 00:26:10 -0500 (EST) Subject: [Mailman-Developers] Re: Possible Fix for password lookup bug References: <36DD9564.3CA9DDF9@lyra.org> <199903032115.PAA04843@ferret.ncsa.uiuc.edu> Message-ID: <14052.45298.866709.284744@anthem.cnri.reston.va.us> >>>>> "CL" == Christopher Lindsey writes: CL> It *would* be nice to have the Web page display the CL> subscribers in a case sensitive format, just for continuity's CL> sake. But it's a lot less minor now that I realize my gaffe CL> with regard to list_members. :) What I have done is to include the case-preserved address in the individual user options page, if it isn't all lowercased. I'll have to think about using the case-preserved address in the membership management page. CL> Here's another feature request, though... From the membership CL> page it would be very nice to be able to click on a CL> subscriber's name, then have it take me to a page for that CL> user's specific settings. Options would include generation of CL> a new password, changing the password to one chosen by the CL> admin, renaming this address to a new address (such as when a CL> user switches ISPs), etc. Good idea. Post 1.0. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Mar 9 05:28:54 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 9 Mar 1999 00:28:54 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] Possible Fix for password References: <36DCD579.328BE248@uiuc.edu> <199903030629.AAA32653@ferret.ncsa.uiuc.edu> Message-ID: <14052.45462.986079.493885@anthem.cnri.reston.va.us> >>>>> "CL" == Christopher Lindsey writes: CL> The password *is* being assigned, but it can't find it later. CL> If I do a CL> strings $prefix/lists/test2/config.db | less CL> and search for the username with uppercase characters, it CL> comes up with a password on the next line... BTW, because config.db is a Python marshal, you can get at the real objects by doing the following (kind of gross) from $prefix: % python >>> import marshal >>> d = marshal.load(open('lists/mylist/config.db')) Now `d' is a dictionary which you can poke at to find all kinds of useful information. A little less gross is % python >>> from Mailman.MailList import MailList >>> m = MailList('mylist', lock=0) Now you can access attributes on m that are equivalent to the keys in d above. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Mar 9 05:38:37 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 9 Mar 1999 00:38:37 -0500 (EST) Subject: [Mailman-Developers] change request: admin password changing References: <36C48867.3E677BDF@lyra.org> Message-ID: <14052.46045.212106.75993@anthem.cnri.reston.va.us> >>>>> "HM" == Harald Meland writes: HM> I agree. I think that the change of admin password stuff HM> belongs on the "General options" page, and not on _all_ the HM> pages. Agreed. HM> However, I'm undecided in the matter of making this (site) HM> configurable. I agree with Greg on this :-) HM> Would anyone object if I just put in a hardcoded condition on HM> 'category == "general"' around the call to HM> FormatPasswordStuff() in HM> Mailman.Cgi.admin.FormatConfiguration()? Perfect. I beat you to the check-in though :-) Thanks Harald. -Barry From claw@varesearch.com Tue Mar 9 05:50:11 1999 From: claw@varesearch.com (J C Lawrence) Date: Mon, 08 Mar 1999 21:50:11 -0800 Subject: [Mailman-Developers] Proposal for funded custom work on MailMan Message-ID: VA Research is potentially interested in using MailMan for a number of internal and external activities, but would need a couple extensions to the current beta: 1) We need to be able to distinguish between "internal" and "external" lists. An internal list would refuse all subscriptions and posts from addresses which didn't match a given pattern (eg only messages originating from *@*varesearch.com can subscribe/post). External lists would be without such controls. 2) As discussed here previously, an ultra-simplified list-creation and administration interface suitable for giving to a computer illiterate HR person to create mailing lists on demand. We are potentially willing to fund one or more of the MailMan developers making these changes for us as long as the resultant changes are folded into the MailMan base release at some future date, and the changes are released under the GPL. I understand the concerns about folding such changes into the production version so close to 1.0 release, holding off on the patches till post-1.0 would be utterly acceptable. If one of the mailman developers is interested in discussing this with me, please email me at claw@varesearch.com and we'll see what we can work out. -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Mar 9 18:58:28 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 9 Mar 1999 13:58:28 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] posting restrictions still confusing to me (or not References: <36E42B56.AF30FB25@appliedbiometrics.com> <199903082118.PAA05965@ferret.ncsa.uiuc.edu> Message-ID: <14053.28500.957849.730251@anthem.cnri.reston.va.us> About posting that are held for approval even thought they seem to be coming from a list member when member_posting_only is set to true... Here's what I'm seeing. I put the following in Mailman/MailList.py inside the Post() method: sys.stderr.write('envsend: %s, sender: %s\n' % (msg.GetEnvelopeSender(), msg.GetSender())) This will write the envelope sender and `header' sender to logs/error, which you can tail as you send messages to the list. For me, envelope sender is always None, so the test falls through to msg.GetSender(), which is taken from my spoofable From: header. Back in November, Scott added the use of GetEnvelopeSender() before GetSender() because he'd been hit by a spam getting through that should have been held for approval, but IIRC, Scott's also been backing away from using the envelope sender in some situations. Maybe Scott is able to elaborate. rfc822.py gets the envelope sender as the unixfrom attribute on the message object. This it gets from the "From " line in the message. I don't understand why you're getting something different from me (I'm using sendmail 8.9.something). Anyway, here's what I propose. I'll add a variable to Defaults.py/mm_cfg.py called, say APPROVE_WITH_ENVELOPE_SENDER which will be set to true by default. You set it to false and Mailman will only use the sender. I'll add info to the FAQ and such explaining that this is easier to spoof, but may work around problems where the envelope sender isn't getting set correctly. If anybody can debug this further, I'd appreciate it. -Barry From ayu1@nycap.rr.com Tue Mar 9 22:00:53 1999 From: ayu1@nycap.rr.com (Alex Yu) Date: Tue, 09 Mar 1999 17:00:53 -0500 Subject: [Mailman-Developers] Error Message - Crontab In-Reply-To: <14053.28500.957849.730251@anthem.cnri.reston.va.us> References: <36E42B56.AF30FB25@appliedbiometrics.com> <199903082118.PAA05965@ferret.ncsa.uiuc.edu> Message-ID: <4.1.19990309165932.009943e0@pop1.rpi.edu> Hello, This is the error crontab message I got. Would someone help me out? Mailman was running very in past one month. Suddently I just got this message. I am running beta 9. Subject: Cron /usr/bin/python /usr/local/mailman/cron/run_queue X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: : shell-init: could not get current directory: Alex From ayu1@nycap.rr.com Tue Mar 9 22:06:11 1999 From: ayu1@nycap.rr.com (Alex Yu) Date: Tue, 09 Mar 1999 17:06:11 -0500 Subject: [Mailman-Developers] Error Message - Crontab In-Reply-To: <4.1.19990309165932.009943e0@pop1.rpi.edu> References: <14053.28500.957849.730251@anthem.cnri.reston.va.us> <36E42B56.AF30FB25@appliedbiometrics.com> <199903082118.PAA05965@ferret.ncsa.uiuc.edu> Message-ID: <4.1.19990309170529.009b4830@pop1.rpi.edu> Hello, Actually I tried to su as mailman, I got the following bad message. [/usr/local] # su - mailman shell-init: could not get current directory: job-working-directory: could not get current directory: job-working-directory: could not get current directory: job-working-directory: could not get current directory: job-working-directory: could not get current directory: job-working-directory: could not get current directory: Any1 knows how to fix it? Alex From bwarsaw@python.org Tue Mar 9 22:09:44 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Tue, 9 Mar 1999 17:09:44 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] Error Message - Crontab References: <14053.28500.957849.730251@anthem.cnri.reston.va.us> <36E42B56.AF30FB25@appliedbiometrics.com> <199903082118.PAA05965@ferret.ncsa.uiuc.edu> <4.1.19990309170529.009b4830@pop1.rpi.edu> Message-ID: <14053.39976.20535.683604@anthem.cnri.reston.va.us> Check the permissions on ~mailman. Did they get messed up some how? From ayu1@nycap.rr.com Tue Mar 9 22:31:33 1999 From: ayu1@nycap.rr.com (Alex Yu) Date: Tue, 09 Mar 1999 17:31:33 -0500 Subject: [Mailman-Developers] Re: [Mailman-Users] Error Message - Crontab In-Reply-To: <4.1.19990309170529.009b4830@pop1.rpi.edu> References: <4.1.19990309165932.009943e0@pop1.rpi.edu> <14053.28500.957849.730251@anthem.cnri.reston.va.us> <36E42B56.AF30FB25@appliedbiometrics.com> <199903082118.PAA05965@ferret.ncsa.uiuc.edu> Message-ID: <4.1.19990309173036.009b1750@pop1.rpi.edu> At 05:06 PM 1999/3/9 -0500, Alex Yu wrote: >Actually I tried to su as mailman, I got the following bad message. >[/usr/local] # su - mailman Sorry, I just fixed the problem. I found out that you can't have umkas 711 on /usr/bin, /usr/sbin, /usr/local/bin and /usr/local/sbin. Thanks. Alex From tismer@appliedbiometrics.com Tue Mar 9 22:44:42 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Tue, 09 Mar 1999 23:44:42 +0100 Subject: [Mailman-Developers] fork() problem and popen2.py test Message-ID: <36E5A45A.C4B81609@appliedbiometrics.com> Hi, again I had lots of trouble with Mailman on starship.skyport.net . Mailman was unable to deliver messages, but didn't tell it. The reason turned out to be dependent wether Python 1.5 (the early version, of course) was made with threads or not. The threaded version had a bad effect on sys.stdin after an os.fork(). sys.stdin was a "bad file number" in the child process. Maybe these are known things, but there are some issues: To Guido: the popen2.py program does a very good job in its self test procedure. Why is this not included in the standard test suite? Also, after "make clean" and a new "configure", the problem did not vanish. I did after a "make distclean". To the Mailmen: It was quite hard to track this error down through the mailman scripts. Finally, I ended up if I made the deliver fork temporarily into a do-nothing. The "deliver" script does a number of forks. I does no proper checking if the forks work (under Linux, btw., fork never returns ENOMEM, so the check isn't safe yet). Deliverer.py also trusts the os.popen very much. In my situation, the error logging was quite random, in three of about 200 tests I got a "broken pipe" message in the log, in the other cases, there was just nothing. It seems to be a race condition which forked process dies first, - I'm not sure. Anyway, sys.stdin is read without error checking in the deliver script. I think, some more checks are necessary to guarantee that failing deliveries get noticed. The combination of a) threaded Python1.5 behavior and b) too much trust from Mailman caused me a desperate error search. Took me 8 hours to nail it down. I thought I should tell this, to avoid similar effects for others. cheers - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Mar 9 23:23:43 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 9 Mar 1999 18:23:43 -0500 (EST) Subject: [Mailman-Developers] MailList "base is not a class object" error References: <199903080123.UAA06834@anvil.murkworks.com> Message-ID: <14053.44415.630380.674106@anthem.cnri.reston.va.us> >>>>> "BC" == Brad Clements writes: BC> I'm porting Mailman 1.0b9 to Win32 (Python 1.5.2b2).  When BC> running newlist.py, I get an error on line 50 of MailList.py, BC> base is not a class object on the definition of MailList. BC> However if I "hand import", it seems to load ok. BC> Anyone try mailman on 1.5.2b2 yet? Well, I've run Mailman on the current CVS snapshot, no problem -- but on Unix of course. I suspect that the problem has more to do with running it on Windows. I don't know of anyone who's done that yet, although the error message you're getting is kind of strange. -Barry From bryner@uiuc.edu Wed Mar 10 01:15:34 1999 From: bryner@uiuc.edu (Brian Ryner) Date: Tue, 09 Mar 1999 19:15:34 -0600 Subject: [Mailman-Developers] "User 0 lacks a password" Message-ID: <36E5C7B5.6DB046A9@uiuc.edu> Hi- Ok, I got this error from the list: Mailman noticed in .MailUserPassword() that: User: 0 List: mhs-alumni lacks a password. Please notify the Mailman system manager at this site! Now, there is no user with email address "0" (you probably guessed that). I don't know how to further track down what caused this. Ideas anyone? This is from CVS just after the update which fixed the capital letters/password issue (soon after the checkin at 1:55 CST on March 5). Thanks! -Brian Ryner bryner@uiuc.edu From grin@tolna.net Wed Mar 10 01:51:53 1999 From: grin@tolna.net (Peter Gervai) Date: Wed, 10 Mar 1999 02:51:53 +0100 Subject: [Mailman-Developers] upgraded to b9, .../lists/* permission is faulty Message-ID: <19990310025153.V9075@mail.tolna.net> Hello, After upgrading from b7 to b9 (make install, make upgrade) almost everything seemed to work. At the first admin move it turned out that somehow the list directories (.../lists/* dirs) lost their www-uid owner and got mailman owner somehow. This is bad, since cgi can't rename (/move) db files that way. Maybe ought to be fixed. (chown'ing back to www those dirs solved the problem.) regards, grin ps: disclaimer as always: could have been my fault. pps: it's still magic who should own what. :) From claw@kanga.nu Wed Mar 10 02:48:37 1999 From: claw@kanga.nu (J C Lawrence) Date: Tue, 09 Mar 1999 18:48:37 -0800 Subject: [Mailman-Developers] Error Message - Crontab In-Reply-To: Message from Alex Yu of "Tue, 09 Mar 1999 17:06:11 EST." <4.1.19990309170529.009b4830@pop1.rpi.edu> Message-ID: On Tue, 09 Mar 1999 17:06:11 -0500 Alex Yu wrote: > Hello, Actually I tried to su as mailman, I got the following bad > message. > [/usr/local] # su - mailman shell-init: could not get current > directory: job-working-directory: could not get current directory: > job-working-directory: could not get current directory: > job-working-directory: could not get current directory: > job-working-directory: could not get current directory: > job-working-directory: could not get current directory: > Any1 knows how to fix it? Your current directory, the one you issue the `su` command from, must be readable by the user ID you are changing to. -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From lindsey@ncsa.uiuc.edu Wed Mar 10 03:45:36 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Tue, 9 Mar 1999 21:45:36 -0600 (CST) Subject: [Mailman-Developers] Request for minor feature Message-ID: <199903100345.VAA08252@ferret.ncsa.uiuc.edu> Tonight I've been struggling with the "convert the URL used in mailman to something else" scenario. Specifically, I'm moving everything to https://secure.domain.com/ from http://www.domain.com/ I couldn't figure out why things weren't working until I finally stumbled across the web_page_url stuff in the code. Since I had commented it all out in the Web pages (I didn't want the list admins mucking with the URL), I had totally forgotten about them. :) Anyhow, I'm wondering if it would be considered acceptable behavior for mailman to leave web_page_url blank UNLESS overridden by a value. Looking at the code for GetAbsoluteScriptURL, it looks like a blank value will default to DEFAULT_URL, which seems like the right thing to do. So, when a new list is created can it just leave web_page_url blank? As far as I can tell, this should do the trick (against the current CVS tree): *** Mailman/MailList.py Tue Mar 9 21:31:20 1999 --- Mailman/MailList.py.bak Tue Mar 9 21:31:01 1999 *************** *** 224,230 **** self.advertised = mm_cfg.DEFAULT_LIST_ADVERTISED self.max_num_recipients = mm_cfg.DEFAULT_MAX_NUM_RECIPIENTS self.max_message_size = mm_cfg.DEFAULT_MAX_MESSAGE_SIZE ! self.web_page_url = mm_cfg.DEFAULT_URL self.owner = [admin] self.reply_goes_to_list = mm_cfg.DEFAULT_REPLY_GOES_TO_LIST self.posters = [] --- 224,230 ---- self.advertised = mm_cfg.DEFAULT_LIST_ADVERTISED self.max_num_recipients = mm_cfg.DEFAULT_MAX_NUM_RECIPIENTS self.max_message_size = mm_cfg.DEFAULT_MAX_MESSAGE_SIZE ! self.web_page_url = '' self.owner = [admin] self.reply_goes_to_list = mm_cfg.DEFAULT_REPLY_GOES_TO_LIST self.posters = [] Chris P.S. If this is changed, perhaps the same should be done for host_name? The other alternative that I see is creating a global list changing mechanism; it would change EVERY list's value of variable 'n' if the listname matched a certain regex. This would be very cool in the post-1.0 era... Comments? From sjp@buzzsaw.net Wed Mar 10 03:49:08 1999 From: sjp@buzzsaw.net (Steve Phillips) Date: Tue, 9 Mar 1999 21:49:08 -0600 (EST) Subject: [Mailman-Developers] Cron /usr/bin/python /home/m/mailman/cron/gate_news (fwd) (fwd) Message-ID: Help! My mailbox is filling up with these error messages. I just upgraded from beta6 to beta9. ---------- Forwarded message ---------- Date: Tue, 9 Mar 1999 21:20:02 -0600 From: root (Cron Daemon) To: mailman Subject: Cron /usr/bin/python /home/m/mailman/cron/gate_news Exception NotLockedError in ignored From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Mar 10 14:58:22 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 10 Mar 1999 09:58:22 -0500 (EST) Subject: [Mailman-Developers] "User 0 lacks a password" References: <36E5C7B5.6DB046A9@uiuc.edu> Message-ID: <14054.34958.860556.543753@anthem.cnri.reston.va.us> >>>>> "BR" == Brian Ryner writes: BR> Now, there is no user with email address "0" (you probably BR> guessed that). I don't know how to further track down what BR> caused this. Ideas anyone? This is from CVS just after the BR> update which fixed the capital letters/password issue (soon BR> after the checkin at 1:55 CST on March 5). Try doing an update. There was a bug in my checkin which is now fixed. -Barry From wfrank@syskonnect.de Thu Mar 11 14:42:02 1999 From: wfrank@syskonnect.de (Werner Frank) Date: Thu, 11 Mar 1999 15:42:02 +0100 (MET) Subject: [Mailman-Developers] change in admin.py for Solaris 2.5.1 and Netscape Fasttrack 2.1 Server Message-ID: <199903111442.PAA13880@docu.skd.de> Hello, while trying to run mailman-1.0b9 on Solaris 2.5.1 together with a Netscape Fasttrack Server 2.1 I had to make the following change in $prefix/Mailman/Cgi/admin.py: I changed line 129 from "path" : os.environ.get("REQUEST_URI", defaulturi), to "path" : '/' + os.environ.get("REQUEST_URI", defaulturi), The result is that in the Web Page for the Administrative Authentication where you enter the password of the list administrator, the HTML code now reads: instead of Obviously the Fasttrack Server must be told that this is an absolute path otherwise the following URL will be set to something like http://server/mailman/admin/mailman/admin/mailmantest which can't be treated correctly. May be it's not the best solution but now it works. werner frank wfrank@syskonnect.de From wfrank@syskonnect.de Thu Mar 11 16:49:55 1999 From: wfrank@syskonnect.de (Werner Frank) Date: Thu, 11 Mar 1999 17:49:55 +0100 (MET) Subject: [Mailman-Developers] more problems with Solaris/Fasttrack Message-ID: <199903111649.RAA14020@docu.skd.de> Hello, I get more and more desperate: When adding a user via the "Membership Management" the user is added however trannsmission of the web page runs into timeout and the site is closed with a bold "OK" and a message stating "An error has occured." Any idea/hint what's going wrong ? TIA, wfrank@syskonnect.de Solaris 2.5.1, mailman-1.0b9, Netscape Fasttrack v2.1, Sendmail 8.8.5/8.6.12 From James Strickland Thu Mar 11 18:52:47 1999 From: James Strickland (James Strickland) Date: Thu, 11 Mar 1999 10:52:47 -0800 (PST) Subject: [Mailman-Developers] Re: [Mailman-Users] Inlining MIME attachments on Mailman web archives In-Reply-To: <87hfrsb1h1.fsf@vega.law.miami.edu> 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. --0-872916835-921175844=:27847 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: On 11 Mar 1999, Michael Alan Dorman wrote: > Unfortunately, a discussion from a month back reveals that pipermail > doesn't have the capability, and no one has at present stepped up to > bat to implement it. There was some talk of making it easier to use > other archiving tools (like hypermail or mhonarc), but I don't know if > this is going to go forward. > > Which is unfortunate since as far as I can tell, it's the one wart on > an otherwise stunningly good program. I'd "step up to the bat" if only I had more time. I'm attaching something which reads a message on stdin, prints out the header and (for demo purposes) some decoded stuff from the header, then proceeds to decode the message, storing attachments (if any) as separate files. Note that it doesn't handle attachments recursively (it should - there are some mailers which send multipart/alternative parts, so the only text/plain part is buried two levels down). It also doesn't handle broken mailers like elm which send a Content-type of "text"! Anyways, the main message has the first plain text part, plus references to the attachments. btw: as a stopgap measure you can simply have a link to a script which would print out Content-type: message/rfc822 Netscape (and maybe other browsers) knows what to do with a Content-type: message/rfc822; it handles displaying attachments and parsing the header and everything. The downside, of course, is that you can't add anything else like links to the next message. Hopefully this should serve as a good starting point. One of the great things about Python is that it comes standard with all these wonderful libraries! -- James Strickland Perforce Software --0-872916835-921175844=:27847 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="samplemimedecoder.py" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: IyEvdXNyL2xvY2FsL2Jpbi9weXRob24NCiMgUmVhZCBtZXNzYWdlIGZyb20g c3RkaW4sIGRlY29kZSBNSU1FIGF0dGFjaG1lbnRzIChpZiBhbnkpLCB3cml0 ZSByZXN1bHQNCiMgYXMgbiBwYXJ0cywgbj49MQ0KIyoqKioqKioqKioqKioq KnlldCB0byBkbzogcmVjb2duaXplIHV1ZW5jb2RlIGluIGJvZHkgb2YgbWVz c2FnZS4NCiMqKioqKnNpbXBseSByZWNvZ25pemUgIl5iZWdpbiBbMC03XXsz fSAiIGFuZCBzcGl0IG91dCB0byBmaWxlIHVudGlsICJeZW5kIg0KIyoqKioq dGhlbiBydW4gdXUuZGVjb2RlKCkNCg0KaW1wb3J0IHN5cywgb3MsIG1pbWV0 b29scywgbXVsdGlmaWxlDQpkZXN0X2Rpcj0nL3RtcCcgIyoqKmZvciB0ZXN0 aW5nDQoNCg0KZGVmIGNvcHkoaW5wdXQsb3V0cHV0LHByZXBlbmQ9JycpOg0K ICAnJydDb3B5IGlucHV0IHRvIG91dHB1dCB1c2luZyByZWFkbGluZSgpLCBv cHRpb25hbGx5IHByZXBlbmRpbmcgYSBzdHJpbmcNCiAgdG8gZWFjaCBsaW5l LiAgTm90ZSB0aGF0IG11bHRpZmlsZSByZXF1aXJlcyB1c2luZyByZWFkbGlu ZSgpIScnJw0KDQogIHdoaWxlIDE6DQogICAgbGluZSA9IGlucHV0LnJlYWRs aW5lKCkNCiAgICBpZiBub3QgbGluZTogYnJlYWsNCiAgICBvdXRwdXQud3Jp dGUocHJlcGVuZCtsaW5lKQ0KDQoNCmRlZiBzdG9yZV9tZXNzYWdlKCk6DQog IA0KICAjIGluaXRpYWxpemUgaW5wdXQgKHN0ZGluKSBhbmQgb3V0cHV0IChm b3Igbm93IHN0ZG91dCkNCiAgbWFpbm91dHB1dCA9IHN5cy5zdGRvdXQNCiAg aW5wdXQgID0gbXVsdGlmaWxlLk11bHRpRmlsZShzeXMuc3RkaW4pDQogIG1h aW4gICA9IG1pbWV0b29scy5NZXNzYWdlKGlucHV0LDApICMgcmVhZHMgdGhl IG1haWwgaGVhZGVyDQogIA0KIyAgIyBwcmludCBvdXQgdGhlIG9yaWdpbmFs IGhlYWRlciBsaW5lcyB2ZXJiYXRpbQ0KIyAgZm9yIGxpbmUgaW4gbWFpbi5o ZWFkZXJzOg0KIyAgICBwcmludCBsaW5lICMgZWFjaCBsaW5lIGlzIGFscmVh ZHkgdGVybWluYXRlZCB3aXRoIFxuDQoNCiAgIyBwcmludCBvdXQgaGVhZGVy DQogIGZvciBmaWVsZCBpbiBtYWluLmtleXMoKToNCiAgICBwcmludCAnJXM6 ICVzJyAlIChmaWVsZCxtYWluW2ZpZWxkXSkNCg0KICAjIC0gZGVjb2RlZCBu YW1lIGFuZCBlbWFpbCBhZGRyZXNzDQogIG5hbWUsZW1haWwgPSBtYWluLmdl dGFkZHIoJ2Zyb20nKQ0KICBwcmludCAnTmFtZTogJXNcbicgJSBuYW1lDQog IHByaW50ICdFbWFpbDogJXNcbicgJSBlbWFpbA0KICANCiAgIyAtIGRlY29k ZWQgdGltZXN0YW1wIC0+IHRpbWV6b25lIGFuZCBVVEMgdGltZXN0YW1wDQog IGRhdGVwbHVzdHogPSBtYWluLmdldGRhdGVfdHooJ2RhdGUnKQ0KDQogIGlm IGRhdGVwbHVzdHo6ICMgdmFsaWQgZGF0ZSBwYXJzZWQNCiAgICB0em9mZnNl dCA9IGRhdGVwbHVzdHpbLTFdDQogICAgaWYgbm90IHR6b2Zmc2V0OiB0em9m ZnNldD0wDQogICAgaW1wb3J0IHRpbWUsIHJmYzgyMiAjIGp1c3QgdG8gZG8g dGhlIGNvbnZlcnNpb24gdG8gVVRDDQogICAgc2Vjc3NpbmNlMTk3MHV0YyA9 IHJmYzgyMi5ta3RpbWVfdHooZGF0ZXBsdXN0eikNCiAgICB1dGMgPSB0aW1l LmdtdGltZShzZWNzc2luY2UxOTcwdXRjKQ0KICAgIHByaW50ICd0em9mZnNl dDogJWRcbicgJSB0em9mZnNldCAjIGFkZCB0byBVVEMgdG8gZ2V0IGxvY2Fs IGZvciBzZW5kZXINCiAgICBwcmludCAndXRjOiAlMDRkLyUwMmQvJTAyZCAl MDJkOiUwMmQ6JTAyZFxuJyAlIHV0Y1s6Nl0NCiAgZWxzZToNCiAgICBwcmlu dCAnSW52YWxpZCBkYXRlIGZvcm1hdCEnDQoNCg0KICAjIERlYWwgd2l0aCBN SU1FIGVuY29kaW5nLCBpZiBhcHBsaWNhYmxlLg0KICAjIFJGQzIwNDYgc2F5 cyAnVGhlIENvbnRlbnQtVHlwZSBmaWVsZCBmb3IgbXVsdGlwYXJ0IGVudGl0 aWVzDQogICMgcmVxdWlyZXMgb25lIHBhcmFtZXRlciwgImJvdW5kYXJ5Ii4n ICBJIGRvbid0IGJvdGhlciB0byBjaGVjaw0KICAjIHRoYXQgdGhlIENvbnRl bnQtVHlwZSBtYXRjaGVzLCBiZWNhdXNlIHRoZSBvYmplY3RpdmUgaGVyZSBp cw0KICAjIHRvIHN0b3JlIHRoZSB0aGluZywgbm90IHRvIGNvbXBsYWluIGFi b3V0IGJyb2tlbiBtYWlsZXJzLg0KICANCiAgYXR0YWNobWVudHMgPSBbXQ0K ICBib3VuZGFyeSA9IG1haW4uZ2V0cGFyYW0oJ2JvdW5kYXJ5JykNCiAgDQog IGlmIG5vdCBib3VuZGFyeTogIyBzaW5nbGUgcGFydCBtZXNzYWdlDQogIA0K ICAgIGNvcHkoaW5wdXQsbWFpbm91dHB1dCwnXHQnKTsNCiAgDQogIGVsc2U6 ICMgbXVsdGlwYXJ0IG1lc3NhZ2UNCiAgDQogICAgIyBtYWtlIGEgZGlyZWN0 b3J5IHRvIHN0b3JlIHRoZSBwYXJ0cw0KICAgIG1lc3NhZ2VfbnVtYmVyID0g NDIgIyoqKiphc3NpZ24gYSB1bmlxdWUgaWRlbnRpZmllcg0KICAgIHRyeTog b3MubWtkaXIoJyVzLyVkJyAlIChkZXN0X2RpcixtZXNzYWdlX251bWJlcikp DQogICAgZXhjZXB0OiBwYXNzICMgd2UgZG9uJ3QgY2FyZSBpZiBpdCdzIGFs cmVhZHkgdGhlcmUNCg0KICAgICMgc2tpcCB0byB0aGUgc3RhcnQgb2YgdGhl IGZpcnN0IHBhcnQNCiAgICBpbnB1dC5wdXNoKGJvdW5kYXJ5KQ0KICAgIHdo aWxlIGlucHV0LnJlYWRsaW5lKCk6IHBhc3MgIyB0aHJvdyBhd2F5IGxpbmVz IGJlZm9yZSBmaXJzdCBib3VuZGFyeSBsaW5lDQogICAgaW5wdXQubmV4dCgp ICMgc2tpcCBvdmVyIGJvdW5kYXJ5DQogIA0KICAgIHBhcnQgPSAxDQogICAg Zm91bmRwbGFpbnRleHQ9MA0KICANCiAgICB3aGlsZSAxOg0KICAgICAgIyBy ZWFkIGhlYWRlciBmb3IgdGhpcyBwYXJ0DQogICAgICBzdWJtID0gbWltZXRv b2xzLk1lc3NhZ2UoaW5wdXQsMCkNCiAgICAgIHR5cGUgPSBzdWJtLmdldHR5 cGUoKQ0KDQogICAgICAjIElmIGl0J3MgdGhlIGZpcnN0IHBsYWluIHRleHQg cGFydCwgc3RvcmUgaXQgYXMgcGFydCBvZiB0aGUgZGVmYXVsdCBtc2cNCiAg ICAgICMgKHNvIHRoYXQgaXQncyBpbmRleGVkIGFuZCBzZWxmLWNvbnRhaW5l ZCkNCiAgICAgICMgT3RoZXJ3aXNlIGRlY29kZSB0aGUgcGFydCBhbmQgc3Rv cmUgaXQgaW4gYW4gYXBwcm9wcmlhdGVseSBuYW1lZCBmaWxlDQogICAgICBp ZiAobm90IGZvdW5kcGxhaW50ZXh0KSBhbmQgdHlwZSA9PSAndGV4dC9wbGFp bic6DQogICAgICAgIGZvdW5kcGxhaW50ZXh0PTENCiAgICAgICAgY29weShp bnB1dCxtYWlub3V0cHV0LCdcdCcpDQogICAgICBlbHNlOg0KICAgICAgICBu YW1lID0gc3VibS5nZXRwYXJhbSgnbmFtZScpDQogICAgICAgIGlmIG5vdCBu YW1lOiBuYW1lID0gInBhcnQiK3JlcHIocGFydCkNCiAgICAgICAgbmFtZSA9 ICclZC8lcycgJSAobWVzc2FnZV9udW1iZXIsbmFtZSkNCiAgICAgICAgYXR0 YWNobWVudHMuYXBwZW5kKCAodHlwZSxuYW1lKSApDQogICAgICAgIG91dHB1 dCA9IG9wZW4oZGVzdF9kaXIrJy8nK25hbWUsJ3cnKQ0KICAgICAgICBlbmNv ZGluZyA9IHN1Ym0uZ2V0ZW5jb2RpbmcoKQ0KICAgICAgICBpZiBlbmNvZGlu ZyA9PSAnYmFzZTY0JyBvciBlbmNvZGluZyA9PSAncXVvdGVkLXByaW50YWJs ZScgb3IgZW5jb2RpbmcgPT0gJ3V1ZW5jb2RlJzoNCiAgICAgICAgICBtaW1l dG9vbHMuZGVjb2RlKGlucHV0LG91dHB1dCxlbmNvZGluZykNCiAgICAgICAg ZWxzZTogIyBjb3B5IGlucHV0IHRvIG91dHB1dCB1c2luZyByZWFkbGluZSgp IC1tdWx0aWZpbGUgcmVxdWlyZXMgcmVhZGxpbmUoKSENCiAgICAgICAgICBj b3B5KGlucHV0LG91dHB1dCkNCiAgDQogICAgICAjIGdvIHRvIHRoZSBuZXh0 IHBhcnQNCiAgICAgIGlmIG5vdCBpbnB1dC5uZXh0KCk6IGJyZWFrDQogICAg ICBwYXJ0ID0gcGFydCArIDENCiAgDQogICAgIyB3cml0ZSBvdXQgaW5mb3Jt YXRpb24gZ2F0aGVyZWQgYWJvdXQgdGhlIGF0dGFjaG1lbnRzDQogICAgaWYg YXR0YWNobWVudHM6IG1haW5vdXRwdXQud3JpdGUoJ0F0dGFjaG1lbnRzOlxu JykNCiAgICBmb3IgdHlwZSxuYW1lIGluIGF0dGFjaG1lbnRzOg0KICAgICAg bWFpbm91dHB1dC53cml0ZSgnXHQlczolc1xuJyAlICh0eXBlLG5hbWUpKQ0K ICBtYWlub3V0cHV0LmNsb3NlKCkNCg0KDQojIEV4ZWN1dGlvbiBzdGFydHMg aGVyZQ0KdHJ5Og0KICBzdG9yZV9tZXNzYWdlKCkNCmV4Y2VwdDoNCiAgIyoq KipuZWVkIHRvIGltcHJvdmUgdGhpcywgb2J2aW91c2x5Li4uDQogIHByaW50 ICdzb21ldGhpbmcgd2VudCBob3JyaWJseSB3cm9uZyAtIHNlbmQgZW1haWwg dG8gamFtZXMgYml0Y2hpbmcgYWJvdXQgaXQnDQo= --0-872916835-921175844=:27847-- From bryner@uiuc.edu Fri Mar 12 23:53:02 1999 From: bryner@uiuc.edu (Brian Ryner) Date: Fri, 12 Mar 1999 17:53:02 -0600 Subject: [Mailman-Developers] Bounce suggestion Message-ID: <36E9A8DE.EDCE9055@uiuc.edu> Hi- I recently manually unsubscribed several dead addresses from a list, and got a bounce message to the admin address for every single one, telling me that the "You have been unsubscribed..." notice couldn't be delivered. Any way this could be disabled? Thanks. -Brian Ryner bryner@uiuc.edu From lindsey@ncsa.uiuc.edu Sat Mar 13 22:14:04 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Sat, 13 Mar 1999 16:14:04 -0600 (CST) Subject: [Mailman-Developers] Multiple admins in 'newlist?' Message-ID: <199903132214.QAA04113@ferret.ncsa.uiuc.edu> I was having a bear of a time figuring out how to get multiple admins specified when creating a new list. I may be missing something obvious here, but I ended up patching newlist to allow multiple addresses delimited by spaces (I know, it's not the right thing to do in case of quoted-string addresses, but until that's fixed throughout all of Mailman this will do). Undoubtedly the notification could be lumped together into the same SMTP transaction, but I don't see it being a problem given how often this will be run (and one could argue that admin notification for a new list should be sent individually to track failures in cases where the admin forwards without rewriting the envelope, since their mail is much more important to be able to debug than users (but I'm just saying that to cover my butt)). (NOTE: I'm not a Mailman developer, and this is not an official patch. Harald et al, should I be sending these to the list, or just to you folks?) Chris P.P.S. This is against the current CVS tree as of the timestamp on the diff. ---------------------------------------------------------------------- *** /home/staff/lindsey/cvs/mailman/bin/newlist Tue Mar 9 21:26:12 1999 --- bin/newlist Sat Mar 13 15:53:49 1999 *************** *** 29,34 **** --- 29,35 ---- Note that list-names are forced to lowercase. """ + from string import * import sys, os, string import time import paths # path hacking *************** *** 74,81 **** if len(argv) > 2: owner_mail = argv[2] else: ! owner_mail = raw_input( ! "Enter the email of the person running the list: ") if len(argv) > 3: list_pw = argv[3] else: --- 75,85 ---- if len(argv) > 2: owner_mail = argv[2] else: ! owner_mail = joinfields (split (raw_input( ! "Enter the email of the person running the list: "), ! ' '), '\n') ! ! if len(argv) > 3: list_pw = argv[3] else: *************** *** 132,138 **** 'requestaddr' : "%s-request@%s" % (list_name, newlist.host_name), 'hostname' : newlist.host_name, }) ! newlist.SendTextToUser(subject="Your new mailing list", recipient=owner_mail, sender='mailman-owner@%s' % newlist.host_name, text=text) --- 136,143 ---- 'requestaddr' : "%s-request@%s" % (list_name, newlist.host_name), 'hostname' : newlist.host_name, }) ! for admin in splitfields(owner_mail, '\n'): ! newlist.SendTextToUser(subject="Your new mailing list", recipient=owner_mail, sender='mailman-owner@%s' % newlist.host_name, text=text) From lindsey@ncsa.uiuc.edu Sat Mar 13 22:37:14 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Sat, 13 Mar 1999 16:37:14 -0600 (CST) Subject: [Mailman-Developers] Multiple admins in 'newlist?' In-Reply-To: <199903132214.QAA04113@ferret.ncsa.uiuc.edu> from "Christopher Lindsey" at Mar 13, 99 04:14:04 pm Message-ID: <199903132237.QAA04223@ferret.ncsa.uiuc.edu> Ack! This should be > text=text) > --- 136,143 ---- > 'requestaddr' : "%s-request@%s" % (list_name, newlist.host_name), > 'hostname' : newlist.host_name, > }) > ! for admin in splitfields(owner_mail, '\n'): > ! newlist.SendTextToUser(subject="Your new mailing list", > ! recipient=admin, > sender='mailman-owner@%s' % newlist.host_name, > text=text) Note the line that says 'recipient=admin'... Chris From sjmudd@bitmailer.net Sun Mar 14 14:19:06 1999 From: sjmudd@bitmailer.net (Simon J Mudd) Date: Sun, 14 Mar 1999 15:19:06 +0100 (MET) Subject: [Mailman-Developers] postfix and mailman (referring to previous posts about vmailer) Message-ID: I've just starting looking at mailman, and notice that it talks about vmailer. For various reasons vmailer had to have its name change, and is now called postfix. Consequently the information in the INSTALL file which talks about vmailer should be modified to talk about postfix and the commands mentioned should be changed too. Substitute vmailer with postfix and mkalias with postalias, the mail.cf configuration file for postfix is normally in /etc/postfix/ and further info about this MTA can be found in www.postfix.org I'm not subscribed to this list, so please CC: any replies to my email address above. Thanks and regards, Simon -- Simon J Mudd, Madrid SPAIN Tel: +34-91-408 4878 email: sjmudd@bitmailer.net [short messages - from radio hams only] ----> ea4els@ea4els.ampr.org From lindsey@ncsa.uiuc.edu Mon Mar 15 16:41:40 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Mon, 15 Mar 1999 10:41:40 -0600 (CST) Subject: [Mailman-Developers] Ignore my patches Message-ID: <199903151641.KAA15187@ferret.ncsa.uiuc.edu> . I think in the future I'll forward my patches and ideas to Barry and let him tell me what I'm missing... If only Python were more intuitive... :) The problem with the first patch (leaving the base URL empty) is that it breaks footers on every message sent out that refers to that URL. Although I think that if no URL is specified, the footers should use the default... The problem with my second patch (allowing multiple admins from newlist) is that the mailto: link breaks on all admin pages. Chris From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Mon Mar 15 16:49:31 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 15 Mar 1999 11:49:31 -0500 (EST) Subject: [Mailman-Developers] Ignore my patches References: <199903151641.KAA15187@ferret.ncsa.uiuc.edu> Message-ID: <14061.14875.226296.413558@anthem.cnri.reston.va.us> >>>>> "CL" == Christopher Lindsey writes: CL> . I think in the future I'll forward my patches and CL> ideas to Barry and let him tell me what I'm missing... If CL> only Python were more intuitive... :) Please understand that I only hack Mailman in my `copious spare time', which means I may not be very responsive at times. I generally try to batch up my Mailman list readings and deal with them at least once a week. Please do *not* send stuff directly to me though. First, it usually breaks my autofoldering (meaning there's a good chance the message will just get buried). Also, there are 4 other core maintainers, so they don't see the messages sent only to me. mailman-developers@python.org is still the best place to send stuff. Thanks, -Barry From petrilli@amber.org Mon Mar 15 17:46:01 1999 From: petrilli@amber.org (Christopher Petrilli) Date: Mon, 15 Mar 1999 12:46:01 -0500 Subject: [Mailman-Developers] Stand-alone Mailman Message-ID: <19990315124601.C13106@amber.org> Gang, So I've been tossing this idea over in my head... what do you think of using a derivitive of CGIHTTPServer.py to drive Mailman so that one could have an "out of hte box" solution... now not everyone WANTS this, but in the Zope world, we've found that for evaluation, the lower the entry-point requirement the better. Thoughts? Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright From bkc@murkworks.com Mon Mar 15 16:47:15 1999 From: bkc@murkworks.com (Brad Clements) Date: Mon, 15 Mar 1999 12:47:15 -0400 Subject: [Mailman-Developers] Stand-alone Mailman In-Reply-To: <19990315124601.C13106@amber.org> Message-ID: <199903151740.MAA20784@anvil.murkworks.com> On 15 Mar 99, at 12:46, Christopher Petrilli wrote: > So I've been tossing this idea over in my head... what do you think of > using a derivitive of CGIHTTPServer.py to drive Mailman so that one could > have an "out of hte box" solution... now not everyone WANTS this, but in > the Zope world, we've found that for evaluation, the lower the entry-point > requirement the better. > > Thoughts? Yes, I want this. In fact, I'm trying to get Mailman working on Win32, but running into a strange error importing MailList.py about "base not a class object" on MailList itself. Anyway, the eventual idea is to embed mailman in a win32 application (along with Zope, Confera and NotMail) and glue all these apps together in some way. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937 From sbolduc@uni-global.com Tue Mar 16 17:00:31 1999 From: sbolduc@uni-global.com (Sylvain Bolduc) Date: Tue, 16 Mar 1999 12:00:31 -0500 Subject: [Mailman-Developers] MailMan Bug since 1.0b7 Message-ID: <000801be6fce$8015a1c0$989b2fce@sly.uniconseil.com> This is a multi-part message in MIME format. ------=_NextPart_000_0009_01BE6FA4.973F99C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SSdtIGdldHRpbmcgdGhhdCBidWcgd2hlbiBpJ20gYXBwcm92aW5nIGEgbWVzc2FnZSBzaW5jZSBN YWlsTWFuIHYxLjAgYjcuDQoNCklzIHRoZXJlIGFueSB3YXkgdG8gZml4IHRoYXQgPw0KDQoNCmFk bWluOiBbLS0tLS0gTWFpbG1hbiBWZXJzaW9uOiAxLjBiOSAtLS0tLV0NCmFkbWluOiBbLS0tLS0g VHJhY2ViYWNrIC0tLS0tLV0NCmFkbWluOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCmFk bWluOiAgIEZpbGUgIi9ob21lL21haWxtYW4vc2NyaXB0cy9kcml2ZXIiLCBsaW5lIDExMiwgaW4g cnVuX21haW4NCmFkbWluOiAgICAgbWFpbigpDQphZG1pbjogICBGaWxlICIvaG9tZS9tYWlsbWFu L01haWxtYW4vQ2dpL2FkbWluZGIucHkiLCBsaW5lIDEyNCwgaW4gbWFpbg0KYWRtaW46ICAgICBI YW5kbGVSZXF1ZXN0cyhkb2MpDQphZG1pbjogICBGaWxlICIvaG9tZS9tYWlsbWFuL01haWxtYW4v Q2dpL2FkbWluZGIucHkiLCBsaW5lIDIxNCwgaW4gSGFuZGxlUmVxdWVzdHMNCmFkbWluOiAgICAg bGlzdC5IYW5kbGVSZXF1ZXN0KHJlcXVlc3QsIHYpDQphZG1pbjogICBGaWxlICIvaG9tZS9tYWls bWFuL01haWxtYW4vTGlzdEFkbWluLnB5IiwgbGluZSAxMjIsIGluIEhhbmRsZVJlcXVlc3QNCmFk bWluOiAgICAgc2VsZi5IYW5kbGVQb3N0UmVxdWVzdChyZXF1ZXN0X2RhdGFbMjpdLCB2YWx1ZSwg Y29tbWVudCkNCmFkbWluOiAgIEZpbGUgIi9ob21lL21haWxtYW4vTWFpbG1hbi9MaXN0QWRtaW4u cHkiLCBsaW5lIDEzMSwgaW4gSGFuZGxlUG9zdFJlcXVlc3QNCmFkbWluOiAgICAgc2VsZi5Qb3N0 KG1zZywgMSkNCmFkbWluOiAgIEZpbGUgIi9ob21lL21haWxtYW4vTWFpbG1hbi9NYWlsTGlzdC5w eSIsIGxpbmUgMTE2MCwgaW4gUG9zdA0KYWRtaW46ICAgICBzZWxmLkRlbGl2ZXJUb0xpc3QobXNn LCByZWNpcGllbnRzLA0KYWRtaW46ICAgRmlsZSAiL2hvbWUvbWFpbG1hbi9NYWlsbWFuL0RlbGl2 ZXJlci5weSIsIGxpbmUgMTczLCBpbiBEZWxpdmVyVG9MaXN0DQphZG1pbjogICAgIHN0YXR1cyA9 IGNtZHByb2MuY2xvc2UoKQ0KYWRtaW46IElPRXJyb3I6ICgxMCwgJ05vIGNoaWxkIHByb2Nlc3Nl cycpDQoNCmFkbWluOiBbLS0tLS0gRW52aXJvbm1lbnQgVmFyaWFibGVzIC0tLS0tXQ0KYWRtaW46 ICBIVFRQX0FDQ0VQVF9FTkNPRElORzogZ3ppcA0KYWRtaW46ICBNQUlMOiAvdmFyL3Nwb29sL21h aWwvcm9vdA0KYWRtaW46ICBDT05URU5UX1RZUEU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJs ZW5jb2RlDQphZG1pbjogIFdOX1JPT1Q6IC93d3cvaHRkb2NzDQphZG1pbjogIEhUVFBfQUNDRVBU X0xBTkdVQUdFOiBlbg0KYWRtaW46ICBVUkxfU0NIRU1FOiBodHRwDQphZG1pbjogIEdBVEVXQVlf SU5URVJGQUNFOiBDR0kvMS4xDQphZG1pbjogIEhUVFBfQUNDRVBUOiBpbWFnZS9naWYsIGltYWdl L3gteGJpdG1hcCwgaW1hZ2UvanBlZywgaW1hZ2UvcGpwZWcsIGltYWdlL3BuZywgKi8qDQphZG1p bjogIF86IC93d3cvaHRkb2NzL21haWxtYW4vYWRtaW5kYg0KYWRtaW46ICBFTlY6IC9yb290Ly5i YXNocmMNCmFkbWluOiAgSE9TVFRZUEU6IGkzODYNCmFkbWluOiAgU0NSSVBUX0ZJTEVOQU1FOiAv d3d3L2h0ZG9jcy9tYWlsbWFuL2FkbWluZGINCmFkbWluOiAgUFlUSE9OUEFUSDogL2hvbWUvbWFp bG1hbg0KYWRtaW46ICBQQVRIOiAvdXNyL2JpbjovYmluOi91c3Ivc2Jpbjovc2JpbjovdXNyL1gx MVI2L2JpbnZ0MTAwOi91c3IvWDExUjYvYmluOi9yb290L2Jpbg0KYWRtaW46ICBVU0VSTkFNRTog cm9vdA0KYWRtaW46ICBET0NVTUVOVF9ST09UOiAvd3d3L2h0ZG9jcw0KYWRtaW46ICBISVNURklM RVNJWkU6IDEwMDANCmFkbWluOiAgSFRUUF9QT1NUX0ZJTEU6IC90bXAvd25fdG1wNjU1MzQvV05w b3N0LTM2ZWU4ZDI2LTY0M2QtMA0KYWRtaW46ICBXTl9ESVJfUEFUSDogL3d3dy9odGRvY3MvbWFp bG1hbg0KYWRtaW46ICBPU1RZUEU6IExpbnV4DQoNCg0KVGhhbmsgWW91IQ0KDQoNCg0KDQoNCg0K U3lsdmFpbiBCb2xkdWMNClVuaUdsb2JhbA0KMTgwMSwgTWNHaWxsIENvbGxlZ2UsIHN1aXRlIDEw MTANCk1vbnRyZWFsIChRdWViZWMpIEgzQSAyTjQNCg0KVGVsOiAoNTE0KSA4NDAtMTE1OCBwb3N0 ZSAzNTENCkZheDogKDUxNCkgODQwLTExNjYNCnNib2xkdWNAdW5pLWdsb2JhbC5jb20NCmh0dHA6 Ly93d3cudW5pLWdsb2JhbC5jb20gDQoNCg0K ------=_NextPart_000_0009_01BE6FA4.973F99C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD48 SEVBRD4NCjxNRVRBIGNvbnRlbnQ9JyJNU0hUTUwgNS4wMC4wOTEwLjEzMDkiJyBuYW1lPUdFTkVS QVRPUj4NCjxNRVRBIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIiBodHRw LWVxdWl2PUNvbnRlbnQtVHlwZT48L0hFQUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElW PjxTUEFOIGNsYXNzPTIwMDExNTIxNi0xNjAzMTk5OT48Rk9OVCBzaXplPTI+SSdtIGdldHRpbmcg dGhhdCBidWcgd2hlbiBpJ20gDQphcHByb3ZpbmcgYSBtZXNzYWdlIHNpbmNlIE1haWxNYW4gdjEu MCBiNy48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4g Y2xhc3M9MjAwMTE1MjE2LTE2MDMxOTk5PjxGT05UIHNpemU9Mj5JcyB0aGVyZSBhbnkgd2F5IHRv IGZpeCB0aGF0IA0KPzwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+YWRt aW46IFstLS0tLSBNYWlsbWFuIFZlcnNpb246IDEuMGI5IC0tLS0tXTxCUj5hZG1pbjogWy0tLS0t IA0KVHJhY2ViYWNrIC0tLS0tLV08QlI+YWRtaW46IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3Qp OjxCUj5hZG1pbjogICBGaWxlIA0KJnF1b3Q7L2hvbWUvbWFpbG1hbi9zY3JpcHRzL2RyaXZlciZx dW90OywgbGluZSAxMTIsIGluIHJ1bl9tYWluPEJSPmFkbWluOiAgICAgDQptYWluKCk8QlI+YWRt aW46ICAgRmlsZSAmcXVvdDsvaG9tZS9tYWlsbWFuL01haWxtYW4vQ2dpL2FkbWluZGIucHkmcXVv dDssIGxpbmUgDQoxMjQsIGluIG1haW48QlI+YWRtaW46ICAgICBIYW5kbGVSZXF1ZXN0cyhkb2Mp PEJSPmFkbWluOiAgIEZpbGUgDQomcXVvdDsvaG9tZS9tYWlsbWFuL01haWxtYW4vQ2dpL2FkbWlu ZGIucHkmcXVvdDssIGxpbmUgMjE0LCBpbiANCkhhbmRsZVJlcXVlc3RzPEJSPmFkbWluOiAgICAg bGlzdC5IYW5kbGVSZXF1ZXN0KHJlcXVlc3QsIHYpPEJSPmFkbWluOiAgIEZpbGUgDQomcXVvdDsv aG9tZS9tYWlsbWFuL01haWxtYW4vTGlzdEFkbWluLnB5JnF1b3Q7LCBsaW5lIDEyMiwgaW4gDQpI YW5kbGVSZXF1ZXN0PEJSPmFkbWluOiAgICAgc2VsZi5IYW5kbGVQb3N0UmVxdWVzdChyZXF1ZXN0 X2RhdGFbMjpdLCB2YWx1ZSwgDQpjb21tZW50KTxCUj5hZG1pbjogICBGaWxlICZxdW90Oy9ob21l L21haWxtYW4vTWFpbG1hbi9MaXN0QWRtaW4ucHkmcXVvdDssIGxpbmUgDQoxMzEsIGluIEhhbmRs ZVBvc3RSZXF1ZXN0PEJSPmFkbWluOiAgICAgc2VsZi5Qb3N0KG1zZywgMSk8QlI+YWRtaW46ICAg RmlsZSANCiZxdW90Oy9ob21lL21haWxtYW4vTWFpbG1hbi9NYWlsTGlzdC5weSZxdW90OywgbGlu ZSAxMTYwLCBpbiBQb3N0PEJSPmFkbWluOiAgICAgDQpzZWxmLkRlbGl2ZXJUb0xpc3QobXNnLCBy ZWNpcGllbnRzLDxCUj5hZG1pbjogICBGaWxlIA0KJnF1b3Q7L2hvbWUvbWFpbG1hbi9NYWlsbWFu L0RlbGl2ZXJlci5weSZxdW90OywgbGluZSAxNzMsIGluIA0KRGVsaXZlclRvTGlzdDxCUj5hZG1p bjogICAgIHN0YXR1cyA9IGNtZHByb2MuY2xvc2UoKTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPmFkbWluOiBJT0Vycm9yOiAoMTAsICdObyBjaGlsZCBwcm9jZXNzZXMnKTxCUj48L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5hZG1pbjogWy0tLS0tIEVudmlyb25tZW50IFZh cmlhYmxlcyAtLS0tLV08QlI+YWRtaW46ICANCkhUVFBfQUNDRVBUX0VOQ09ESU5HOiBnemlwPEJS PmFkbWluOiAgTUFJTDogL3Zhci9zcG9vbC9tYWlsL3Jvb3Q8QlI+YWRtaW46ICANCkNPTlRFTlRf VFlQRTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGU8QlI+YWRtaW46ICBXTl9ST09U OiANCi93d3cvaHRkb2NzPEJSPmFkbWluOiAgSFRUUF9BQ0NFUFRfTEFOR1VBR0U6IGVuPEJSPmFk bWluOiAgVVJMX1NDSEVNRTogDQpodHRwPEJSPmFkbWluOiAgR0FURVdBWV9JTlRFUkZBQ0U6IENH SS8xLjE8QlI+YWRtaW46ICBIVFRQX0FDQ0VQVDogaW1hZ2UvZ2lmLCANCmltYWdlL3gteGJpdG1h cCwgaW1hZ2UvanBlZywgaW1hZ2UvcGpwZWcsIGltYWdlL3BuZywgKi8qPEJSPmFkbWluOiAgXzog DQovd3d3L2h0ZG9jcy9tYWlsbWFuL2FkbWluZGI8QlI+YWRtaW46ICBFTlY6IC9yb290Ly5iYXNo cmM8QlI+YWRtaW46ICBIT1NUVFlQRTogDQppMzg2PEJSPmFkbWluOiAgU0NSSVBUX0ZJTEVOQU1F OiAvd3d3L2h0ZG9jcy9tYWlsbWFuL2FkbWluZGI8QlI+YWRtaW46ICANClBZVEhPTlBBVEg6IC9o b21lL21haWxtYW48QlI+YWRtaW46ICBQQVRIOiANCi91c3IvYmluOi9iaW46L3Vzci9zYmluOi9z YmluOi91c3IvWDExUjYvYmludnQxMDA6L3Vzci9YMTFSNi9iaW46L3Jvb3QvYmluPEJSPmFkbWlu OiANCiBVU0VSTkFNRTogcm9vdDxCUj5hZG1pbjogIERPQ1VNRU5UX1JPT1Q6IC93d3cvaHRkb2Nz PEJSPmFkbWluOiAgSElTVEZJTEVTSVpFOiANCjEwMDA8QlI+YWRtaW46ICBIVFRQX1BPU1RfRklM RTogDQovdG1wL3duX3RtcDY1NTM0L1dOcG9zdC0zNmVlOGQyNi02NDNkLTA8QlI+YWRtaW46ICBX Tl9ESVJfUEFUSDogDQovd3d3L2h0ZG9jcy9tYWlsbWFuPEJSPmFkbWluOiAgT1NUWVBFOiBMaW51 eDxCUj48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ PFNQQU4gY2xhc3M9MjAwMTE1MjE2LTE2MDMxOTk5PlRoYW5rIA0KWW91ITwvU1BBTj48QlI+PC9G T05UPjxTUEFOIA0KY2xhc3M9MjAwMTE1MjE2LTE2MDMxOTk5PjwvU1BBTj48L0RJVj48QlI+PEJS PjxCUj48QlI+DQo8UD48Rk9OVCBzaXplPTI+U3lsdmFpbiBCb2xkdWM8QlI+VW5pR2xvYmFsPEJS PjE4MDEsIE1jR2lsbCBDb2xsZWdlLCBzdWl0ZSANCjEwMTA8QlI+TW9udHJlYWwgKFF1ZWJlYykg SDNBIDJONDxCUj48QlI+VGVsOiAoNTE0KSA4NDAtMTE1OCBwb3N0ZSAzNTE8QlI+RmF4OiANCig1 MTQpIDg0MC0xMTY2PEJSPjxBIA0KaHJlZj0ibWFpbHRvOnNib2xkdWNAdW5pLWdsb2JhbC5jb20i PnNib2xkdWNAdW5pLWdsb2JhbC5jb208L0E+PEJSPjxBIA0KaHJlZj0iaHR0cDovL3d3dy51bmkt Z2xvYmFsLmNvbSIgdGFyZ2V0PV9ibGFuaz5odHRwOi8vd3d3LnVuaS1nbG9iYWwuY29tPC9BPiAN CjwvRk9OVD48L1A+DQo8RElWPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0009_01BE6FA4.973F99C0-- From roger@infomed.sld.cu Wed Mar 17 19:47:55 1999 From: roger@infomed.sld.cu (=?iso-8859-1?Q?Roger_Pe=F1a_Escobio?=) Date: Wed, 17 Mar 1999 14:47:55 -0500 Subject: [Mailman-Developers] Automatically update aliases again (fix alias wrapper) Message-ID: <01be70af$0dc27cb0$1c7001c4@ntserver.sld.cu> hello to mailman developers :-) i was posted few weeks ago two messages, both about the subject of this messages but nobody was interesting on that. Today while i was looking on "The Mailman TODO list" web page i look that this problems are unsolved yet , if anybody are interesting in how can fix it , this is my e-mail, roger@infomed.sld.cu , please e-mailme . Also i have a c programs for edit the aliases file when the admin remove a list. Good luck Roger From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Mar 20 05:07:13 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 20 Mar 1999 00:07:13 -0500 (EST) Subject: [Mailman-Developers] Jitterbug for Mailman Message-ID: <14067.11521.211373.182229@anthem.cnri.reston.va.us> Hey folks, sorry I've been so unresponsive lately. Anyway, I have installed Jitterbug on python.org for managing bug reports on Mailman. Hopefully this will work better than trying to use my inbox :-). If Jitterbug works out well, I plan on creating interfaces for other python.org projects. To check out the Jitterbug reporting interface for Mailman, please see http://www.python.org/mailman-bugs Let me know if you have any problems. -Barry From bruce@hams.com Sat Mar 20 20:28:09 1999 From: bruce@hams.com (bruce@hams.com) Date: 20 Mar 1999 20:28:09 -0000 Subject: [Mailman-Developers] Submission for Mailman's "contrib" directory Message-ID: <19990320202809.12043.qmail@hams.com> Hi, The following script interfaces a qmail virtual domain to Mailman without the use of any aliases. That makes it a lot easier to add new lists. Could you place it in a "contrib" directory in the Mailman distribution? Thanks Bruce Perens --- cut here --- #! /usr/bin/python # Configuration variables - Change these for your site if necessary. MailmanHome = "/home/mailman"; # Mailman home directory. MailmanOwner = "postmaster@localhost"; # Postmaster and abuse mail recepient. # End of configuration variables. # qmail-to-mailman.py # # Interface mailman to a qmail virtual domain. Does not require the creation # of _any_ aliases to connect lists to your mail system. # # Bruce Perens, bruce@perens.com, March 1999. # This is free software under the GNU General Public License. # # This script is meant to be called from ~mailman/.qmail-default . It catches # all mail to a virtual domain, in my case "lists.hams.com". It looks at the # recepient for each mail message and decides if the mail is addressed to a # valid list or not, and bounces the message with a helpful suggestion if it's # not addressed to a list. It decides if it is a posting, a list command, or # mail to the list administrator, by checking for the -admin, -owner, and # -request addresses. It will recognize a list as soon as the list is created, # there is no need to add _any_ aliases for any list. It recognizes mail to # postmaster, mailman-owner, abuse, mailer-daemon, root, and owner, and # routes those mails to MailmanOwner as defined in the configuration # variables, above. # # INSTALLATION: # # Install this file as ~mailman/qmail-to-mailman.py # # To configure a virtual domain to connect to mailman, create these files: # # ~mailman/.qmail-default # |/usr/bin/python /home/mailman/mail-in.py # # /var/qmail/control/virtualdomains: # DOMAIN.COM:mailman # # Replace DOMAIN.COM above with the name of the domain to be connected to # Mailman. Note that _all_ mail to that domain will go to Mailman, so you # don't want to put the name of your main domain here. In my case, I created # lists.hams.com for Mailman, and I use hams.com as my regular domain. # # After you edit /var/qmail/control/virtualdomains, kill and restart qmail. # import sys, os, re, string; def main(): os.nice(5); # Handle mailing lists at non-interactive priority. os.chdir(MailmanHome + "/lists"); try: local = os.environ["LOCAL"]; except: # This might happen if we're not using qmail. sys.stderr.write("LOCAL not set in environment?\n"); sys.exit(100); local = re.sub("^mailman-","",local); names = ("root", "postmaster", "mailer-daemon", "mailman-owner", "owner", "abuse"); for i in names: if i == local: os.execv("/var/qmail/bin/qmail-inject" ,("/var/qmail/bin/qmail-inject", MailmanOwner)); sys.exit(0); type = "post"; types = (("-admin$", "mailowner"), ("-owner$", "mailowner"), ("-request$", "mailcmd")); for i in types: if re.search(i[0],local): type = i[1]; local = re.sub(i[0],"",local); if os.path.exists(local): os.execv(MailmanHome + "/mail/wrapper" ,(MailmanHome + "/mail/wrapper", type, local)); else: bounce(); sys.exit(111); def bounce(): bounce_message = """\ TO ACCESS THE MAILING LIST SYSTEM: Start your web browser on http://%s/ That web page will help you subscribe or unsubscribe, and will give you directions on how to post to each mailing list.\n"""; sys.stderr.write(bounce_message % (os.environ["HOST"])); sys.exit(100); try: sys.exit(main()); except SystemExit, argument: sys.exit(argument); except Exception, argument: info = sys.exc_info(); trace = info[2]; sys.stderr.write("%s %s\n" % (sys.exc_type, argument)); sys.stderr.write("Line %d\n" % (trace.tb_lineno)); sys.exit(111); # Soft failure, try again later. --- cut here --- From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Mar 20 22:27:58 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 20 Mar 1999 17:27:58 -0500 (EST) Subject: [Mailman-Developers] Submission for Mailman's "contrib" directory References: <19990320202809.12043.qmail@hams.com> Message-ID: <14068.8430.433170.304453@anthem.cnri.reston.va.us> bruce> The following script interfaces a qmail virtual domain to bruce> Mailman without the use of any aliases. That makes it a lot bruce> easier to add new lists. Could you place it in a "contrib" bruce> directory in the Mailman distribution? Thanks Bruce, I've added this to the (new) contrib directory. I made some stylistic changes: - "#! /usr/bin/env python" is the recommended #! for Python - Removed all those unnecessary semi-colons at the ends of the lines (I know, a hard habit to break :-) - Reformated for 4-space and untabified I would also suggest rewriting the big comment near the top of the file as a docstring, but then you'd have to move this to before the setting of the config variables, and I wasn't sure if you wanted to do this. -Barry From julian7@kva.hu Sun Mar 21 09:25:13 1999 From: julian7@kva.hu (Balazs Nagy) Date: Sun, 21 Mar 1999 10:25:13 +0100 (CET) Subject: [Mailman-Developers] Submission for Mailman's "contrib" directory In-Reply-To: <19990320202809.12043.qmail@hams.com> Message-ID: On 20 Mar 1999 bruce@hams.com wrote: > Hi, > > The following script interfaces a qmail virtual domain to Mailman without the > use of any aliases. That makes it a lot easier to add new lists. Could you > place it in a "contrib" directory in the Mailman distribution? I think it could be combined with an aliasing (put +listname:.... line to /var/qmail/users/assign) command. This way it could be in src/ and not contrib/. I'll try it at home. -- Regards: Kevin (Balazs) From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Mon Mar 22 23:34:27 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 22 Mar 1999 18:34:27 -0500 (EST) Subject: [Mailman-Developers] New Mailing List Message-ID: <14070.54147.17042.254891@anthem.cnri.reston.va.us> There have been a number of requests to start an announce-only list for Mailman. I've now done this http://www.python.org/mailman/listinfo/mailman-announce The function of the lists are now better explained on the www.list.org site. Let me know if you have any problems. -Barry From roger@infomed.sld.cu Tue Mar 23 02:27:13 1999 From: roger@infomed.sld.cu (=?iso-8859-1?Q?Roger_Pe=F1a_Escobio?=) Date: Mon, 22 Mar 1999 21:27:13 -0500 Subject: [Mailman-Developers] patch to fix the alias-wrapper.c Message-ID: <01be74d4$a9981e00$1c7001c4@ntserver.sld.cu> This is a multi-part message in MIME format. ------=_NextPart_000_008C_01BE74AA.C0C21600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by infomed.sld.cu id VAA09237 Hi... few days ago we discuses about aliases file, well... this my patch of mailman-1.0b9 to fix alias-wrapper, also fix newlist. this patch also changes the rmlist file, including an rmaliases programs (rmalias-wrapper.c, this programs edit the aliases file when you eliminat= e a list ). Of course, you are free to apply the patch or not, but if will do it look inside first, see what it will do and if you agree, =A1=A1 great !!! lets= do it :-) this line are for the brave souls :-) who like apply the patch 1-move the patch to the source dir , for example , /usr/local/src if mail= man source is in /usr/local/src/mailman-1.0b9 2-rename the alias-wrapper.c source to addalias-wrapper.c , it is, mv ./mailman-1.0b9/src/alias-wrapper.c ./mailman-1.0b9/src/addalias-wrapper.= c 3-exec the command : patch -p0 < mailman-1.0b9-patch-r.patch 4- if you dont get any estrange line or question every thing was fine, if not ...... check if you really have the mailman-1.0b9 version or if you a= re in the correct dir. 5- everything is ok ? great, now put the rmalias-wrapper.c into the src d= ir, it is ./mailman-1.0b9/src/ 6-now you have to check some "little" thing, first of all , my aliases fi= le for mailman is /etc/mailman/aliases, you can change that editing the addalias-wrapper.c and rmalias-wrapper.c, is really simple, take a look, = I dont know if mailman user can edit the /etc/aliases file ( I think he can= t) but in the other way I prefer to have two aliases file one for system ali= as and another for mailman alias, if I convince you about two alias, you wil= l have to change your sendmail.cf and create the /etc/mailman/ dir : 6.1-creating the /etc/mailman/ dir : #mkdir /etc/mailman ; chgrp mail= man /etc/mailman ; chmod 755 /etc/mailman 6.2-changing the sendmail.cf: do this really depend on your OS , in RedHat you have to do this: cd /usr/lib/sendmail-cf/cf/ edit your *.mc , if you never do this before ( if you have th= e sendmail.cf from distribution) your *.mc is redhat.mc, put this line define(`ALIAS_FILE',`/etc/aliases,/etc/mailman/aliases') exec the command : #m4 ../m4/cf.m4 redhat.mc > myhost.cf make a copy of your old sendmail.cf : #cp /etc/sendmail.cf /etc/sendmail.cf.old copy the new *.cf file to /etc/sendmail.cf: #cp myhost.cf /etc/sendmail.cf restart sendmail: #/etc/rc.d/init.d/sendmail restart and thats all !!!! are you still with me ???? :-) 6.3-check if you have /var/tmp dir , addalias-wrapper.c and rmalias-wrapper.c need it temporally, redhat already have but other OS do= nt 7-the only thing that rest is run autoconf INSIDE mailman source , it is = : #cd /usr/local/mailman-1.0b9 ; autoconf that is for make configure from configure.in 8-well, if you do all above you really have my mailman ready to install, = so install it :-)) a final words.... maybe you think something like this "should I do all th= is thing instead of edit the aliases file manually?? are you crazy!!!" but = you only need to do this only once, and then when you create or eliminate a l= ist all will be do automatically. well a hope that this patch help someone . Roger ------=_NextPart_000_008C_01BE74AA.C0C21600 Content-Type: application/octet-stream; name="rmalias-wrapper.c" Content-Disposition: attachment; filename="rmalias-wrapper.c" Content-Transfer-Encoding: base64 LyogYWxpYXMtd3JhcHBlci5jIC0tLSB3cmFwcGVyIHRvIGFsbG93IHRoZSBtYWlsbWFuIHVzZXIg dG8gbW9kaWZ5IHRoZSBhbGlhc2VzCiAqIGRhdGFiYXNlLgogKgogKiBDb3B5cmlnaHQgKEMpIDE5 OTggYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLgogKgogKiBUaGlzIHByb2dy YW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCiAqIG1v ZGlmeSBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNl CiAqIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIg dmVyc2lvbiAyCiAqIG9mIHRoZSBMaWNlbnNlLCBvciAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRl ciB2ZXJzaW9uLgogKiAKICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3Bl IHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCiAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0 aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCiAqIE1FUkNIQU5UQUJJTElUWSBvciBG SVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKICogR05VIEdlbmVyYWwg UHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KICogCiAqIFlvdSBzaG91bGQgaGF2ZSBy ZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCiAqIGFsb25n IHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlIAog KiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UgLSBTdWl0ZSAzMzAsIEJvc3Rvbiwg TUEgMDIxMTEtMTMwNywgVVNBLgogKi8KCiNpbmNsdWRlIDxzdGRpby5oPgojaW5jbHVkZSA8c3Rk bGliLmg+CgovKiBwYXNzZWQgaW4gZnJvbSBjb25maWd1cmUgc2NyaXB0ICovCmNvbnN0IGludCAg TEVHQUxfUEFSRU5UX1VJRCA9IEFMSUFTX1VJRDsgICAvKiBtYWlsbWFuJ3MgVUlEICovCmNvbnN0 IGludCAgTEVHQUxfUEFSRU5UX0dJRCA9IEFMSUFTX0dJRDsgICAgLyogbWFpbCdzIEdJRCAqLwoK CmNvbnN0IGNoYXIqIFNFTkRNQUlMX0NNRCA9ICIvdXNyL3NiaW4vc2VuZG1haWwiOwpjb25zdCBj aGFyKiBBTElBU19GSUxFICAgPSAiL2V0Yy9tYWlsbWFuL2FsaWFzZXMiOwpjb25zdCBjaGFyKiBB TElBU19GSUxFX1RNUCAgID0gIi92YXIvdG1wL21haWxtYW5BbGlhc2VzIjsKY29uc3QgY2hhciog V1JBUFBFUiAgICAgID0gIi9ob21lL21haWxtYW4vbWFpbC93cmFwcGVyIjsKCmNoYXIgbGluZWEx WzEwMjRdOyAKY2hhciBsaW5lYVsxMDI0XTsKaW50IGk9MDsKCi8qIAoqKiBpcyB0aGUgcGFyZW50 IHByb2Nlc3MgYWxsb3dlZCB0byBjYWxsIHVzPwoqLwppbnQKTGVnYWxDYWxsZXIoKSAKewoJLyog Y29tcGFyZSB0byBvdXIgcGFyZW50J3MgdWlkICovCglpZiAoTEVHQUxfUEFSRU5UX1VJRCAhPSBn ZXR1aWQoKSkgewoJCXByaW50ZigiR09UIFVJRCAlZC5cbiIsIGdldHVpZCgpKTsKCQlyZXR1cm4g MDsKCX0KCWlmIChMRUdBTF9QQVJFTlRfR0lEICE9IGdldGdpZCgpKSB7CgkJcHJpbnRmKCJHT1Qg R0lEICVkLlxuIiwgZ2V0Z2lkKCkpOwoJCXJldHVybiAwOwoJfQoJcmV0dXJuIDE7Cn0KCgp2b2lk ClJtTGlzdEFsaWFzZXMoY2hhciAqbGlzdCkKewoJRklMRSAqZjsKCUZJTEUgKmFsaWFzdG1wOwoJ aW50ICBlcnIgPSAwOwoJCglzcHJpbnRmKGxpbmVhMSwiIyMgJXMgbWFpbGluZyBsaXN0OiIsbGlz dCk7CglmPWZvcGVuKEFMSUFTX0ZJTEUgLCJyIik7Cglmc2VlayhmLDAsU0VFS19TRVQpOwoJaWYg KGYgPT0gTlVMTCkgewoJCWVyciA9IDE7CgkJZiA9IHN0ZGVycjsKCQlmcHJpbnRmKGYsICJcblxu KioqKioqKioqKipFUlJPUiEhISEqKioqKioqKioqKlxuIik7CgkJZnByaW50ZihmLCAiQ291bGQg bm90IHdyaXRlIHRvIHRoZSBhbGlhc2VzIGZpbGUuXG4iKTsKCQlmcHJpbnRmKGYsICJQbGVhc2Ug YmVjb21lIHJvb3QsIGFkZCB0aGUgbGluZXMgYmVsb3cgdG9cbiIpOwoJCWZwcmludGYoZiwgInRo YXQgZmlsZSwgYW5kIHRoZW4gcnVuIHRoZSBjb21tYW5kOlxuIik7CgkJZnByaW50ZihmLCAiJXMg LWJpXG4iLCBTRU5ETUFJTF9DTUQpOwoJICAgIH1lbHNlewoJICAgIAlwcmludGYoIkVkaXRpbmcg YWxpYXMgZGF0YWJhc2UuLi4uXG4iICk7CgkJYWxpYXN0bXA9Zm9wZW4oQUxJQVNfRklMRV9UTVAs InciKTsKCQlpZiAoYWxpYXN0bXAgPT0gTlVMTCkgewoJCSAgICBwcmludGYoIlxuXG4qKioqKioq KioqKkVSUk9SISEhISoqKioqKioqKioqXG4iKTsKCQkgICAgcHJpbnRmKCJDb3VsZCBub3Qgd3Jp dGUgdG8gdGhlIHRtcCBhbGlhc2VzIGZpbGUuXG4iKTsKCQkgICAgZXJyID0gMTsKCQkgICAgYWxp YXN0bXAgPSBzdGRlcnI7CgkJIH0gICAKCQl3aGlsZSggKCBmZ2V0cyhsaW5lYSwxMDI0LGYpKSAh PSBOVUxMICl7CgkJICAgIGlmICggIXN0cm5jbXAobGluZWEsIGxpbmVhMSwgc3RybGVuKGxpbmVh MSkpICl7CgkJCXByaW50ZigiZWxpbWluYW5kbyBsYSBsaXN0YS4uLlxuIiApOwoJCQlmb3IoaT0x OyBpPD0xMDsgaSsrKXsKCQkJICAgIGZnZXRzKGxpbmVhLDEwMjQsZik7CgkJCSAgICB9OwoJCSAg ICAgIH0KCQkgICAgZnByaW50ZihhbGlhc3RtcCxsaW5lYSk7CgkJIH07CgkJZmNsb3NlKGFsaWFz dG1wKTsKCQlmY2xvc2UoZik7CgkJc3lzdGVtKCJjcCAvdmFyL3RtcC9tYWlsbWFuQWxpYXNlcyAv ZXRjL21haWxtYW4vYWxpYXNlcyIpOyAKCQlwcmludGYoIlJlYnVpbGRpbmcgYWxpYXMgZGF0YWJh c2UuLi5cbiIpOwoJCWV4ZWNscChTRU5ETUFJTF9DTUQsIFNFTkRNQUlMX0NNRCwgIi1iaSIsIE5V TEwpOwoJICAgIH0gICAgCn0KCgppbnQKbWFpbihpbnQgYXJnYywgY2hhciAqKmFyZ3YsIGNoYXIg KiplbnYpIAp7CgljaGFyICAqY29tbWFuZDsKCWludCAgIGk7CgoJaWYgKGFyZ2MgIT0gMikgewoJ CXByaW50ZigiVXNhZ2U6ICVzIFtsaXN0LW5hbWVdXG4iLCBhcmd2WzBdKTsKCQlleGl0KDApOwoJ fQoJaWYgKExlZ2FsQ2FsbGVyKCkpIHsKCQlzZXR1aWQoZ2V0ZXVpZCgpKTsKCQlSbUxpc3RBbGlh c2VzKGFyZ3ZbMV0pOwoJfQoJZWxzZSB7CgkJcHJpbnRmKCJJbGxlZ2FsIGNhbGxlciFcbiIpOwoJ CXJldHVybiAxOwoJfQoJcmV0dXJuIDA7Cn0KCgoMCi8qCiAqIExvY2FsIFZhcmlhYmxlczoKICog Yy1maWxlLXN0eWxlOiAicHl0aG9uIgogKiBFbmQ6CiAqLwo= ------=_NextPart_000_008C_01BE74AA.C0C21600 Content-Type: application/octet-stream; name="mailman-1.0b9-patch-r.patch" Content-Disposition: attachment; filename="mailman-1.0b9-patch-r.patch" Content-Transfer-Encoding: base64 ZGlmZiAtTmF1ciAuL21haWxtYW4tMS4wYjkvTWFrZWZpbGUuaW4gLi9tYWlsbWFuLTEuMGI5cC9N YWtlZmlsZS5pbgotLS0gLi9tYWlsbWFuLTEuMGI5L01ha2VmaWxlLmluCVRodSBKYW4gMTQgMjM6 MjA6NTcgMTk5OQorKysgLi9tYWlsbWFuLTEuMGI5cC9NYWtlZmlsZS5pbglTdW4gTWFyIDIxIDIy OjQxOjQ3IDE5OTkKQEAgLTM1LDYgKzM1LDcgQEAKIERFRlM9CQlAREVGU0AKIAogTUFJTE1BTl9V SUQ9CUBNQUlMTUFOX1VJREAKK01BSUxNQU5fR0lEPQlATUFJTE1BTl9HSURACiAKICMgQ3VzdG9t aXphYmxlIGJ1dCBub3Qgc2V0IGJ5IGNvbmZpZ3VyZQogCkBAIC03OCw2ICs3OSw3IEBACiAJICAg IGlmIHRlc3QgISAtZCAkJGRpcjsgdGhlbiBcCiAJCWVjaG8gIkNyZWF0aW5nIGRpcmVjdG9yeSBo aWVyYXJjaHkgJCRkaXIiOyBcCiAJCS4vbWtpbnN0YWxsZGlycyAkJGRpcjsgXAorCQljaG93biAk KE1BSUxNQU5fVUlEKTokKE1BSUxNQU5fR0lEKSAkJGRpcjsgXAogCQljaG1vZCAkKERJUk1PREUp ICQkZGlyOyBcCiAJCWNobW9kIGcrcyAkJGRpcjsgXAogCSAgICBlbHNlIHRydWU7IFwKQEAgLTkx LDYgKzkzLDcgQEAKIAkgICAgaWYgdGVzdCAhIC1kICQkZGlyOyB0aGVuIFwKIAkJZWNobyAiQ3Jl YXRpbmcgZGlyZWN0b3J5IGhpZXJhcmNoeSAkJGRpciI7IFwKIAkJLi9ta2luc3RhbGxkaXJzICQk ZGlyOyBcCisJCWNob3duICQoTUFJTE1BTl9VSUQpOiQoTUFJTE1BTl9HSUQpICQkZGlyOyBcCiAJ CWNobW9kICQoRElSTU9ERSkgJCRkaXI7IFwKIAkJY2htb2QgZytzICQkZGlyOyBcCiAJICAgIGVs c2UgdHJ1ZTsgXApAQCAtMTAxLDkgKzEwNCwxMCBAQAogCSAgICAoY2QgJCRkOyAkKE1BS0UpIGlu c3RhbGwpOyBcCiAJZG9uZQogCSQoUFlUSE9OKSAtYyAnaW1wb3J0IGNvbXBpbGVhbGw7IGNvbXBp bGVhbGwuY29tcGlsZV9kaXIoIiQocHJlZml4KSIpJworCWNob3duIC1SICQoTUFJTE1BTl9VSUQp OiQoTUFJTE1BTl9HSUQpICQocHJlZml4KS8qCiAJQGVjaG8gIioqKioqIgogCUBlY2hvICIqKioq KiBJZiB5b3UgYXJlIGluc3RhbGxpbmcgb3ZlciBhbiBvbGQgaW5zdGFsbGF0aW9uLCBwbGVhc2Ui Ci0JQGVjaG8gIioqKioqIHJ1biBcIm1ha2UgdXBkYXRlXCIuICBTZWUgdGhlIFVQR1JBRElORyBm aWxlIGZvciBkZXRhaWxzLiIKKwlAZWNobyAiKioqKiogcnVuIFwibWFrZSB1cGRhdGVcIiBsaWtl IG1haWxtYW4gdXNlci4gIFNlZSB0aGUgVVBHUkFESU5HIGZpbGUgZm9yIGRldGFpbHMuIgogCUBl Y2hvICIqKioqKiIKIAogI2ZpbmlzaDoKZGlmZiAtTmF1ciAuL21haWxtYW4tMS4wYjkvYmluL25l d2xpc3QgLi9tYWlsbWFuLTEuMGI5cC9iaW4vbmV3bGlzdAotLS0gLi9tYWlsbWFuLTEuMGI5L2Jp bi9uZXdsaXN0CVNhdCBGZWIgMjcgMTM6MDU6NDMgMTk5OQorKysgLi9tYWlsbWFuLTEuMGI5cC9i aW4vbmV3bGlzdAlNb24gTWFyICAxIDIxOjIzOjEyIDE5OTkKQEAgLTkyLDcgKzkyLDcgQEAKICAg ICBmaW5hbGx5OgogICAgICAgICBvcy51bWFzayhvbGRtYXNrKQogCi0gICAgIyMjb3Muc3lzdGVt KCclcyAlcycgJSAoQUREQUxJQVNFU19DTUQsIGxpc3RfbmFtZSkpCisgICAgCiAgICAgcHJpbnQg JycnCiBFbnRyeSBmb3IgYWxpYXNlcyBmaWxlOgogCkBAIC0xMTgsNiArMTE4LDcgQEAKIAlwcmlu dCAoIkhpdCBlbnRlciB0byBjb250aW51ZSB3aXRoICVzIG93bmVyIG5vdGlmaWNhdGlvbi4uLiIK IAkgICAgICAgJSBsaXN0X25hbWUpLAogCXN5cy5zdGRpbi5yZWFkbGluZSgpCisgICAgb3Muc3lz dGVtKCclcyAlcycgJSAoQUREQUxJQVNFU19DTUQsIGxpc3RfbmFtZSkpCiAgICAgc2VuZG5vdGlj ZShuZXdsaXN0LCBsaXN0X25hbWUsIG93bmVyX21haWwsIGxpc3RfcHcpCiAgICAgbmV3bGlzdC5V bmxvY2soKQogCmRpZmYgLU5hdXIgLi9tYWlsbWFuLTEuMGI5L2Jpbi9ybWxpc3QgLi9tYWlsbWFu LTEuMGI5cC9iaW4vcm1saXN0Ci0tLSAuL21haWxtYW4tMS4wYjkvYmluL3JtbGlzdAlNb24gRmVi ICAxIDE2OjU3OjU4IDE5OTkKKysrIC4vbWFpbG1hbi0xLjBiOXAvYmluL3JtbGlzdAlTdW4gTWFy IDIxIDIyOjA1OjI0IDE5OTkKQEAgLTk1LDYgKzk1LDcgQEAKICAgICBmb3IgZGlydG1wbCwgbXNn IGluIFJFTU9WQUJMRVM6CiAgICAgICAgIGRpciA9IG9zLnBhdGguam9pbihwYXRocy5wcmVmaXgs IGRpcnRtcGwgJSBsaXN0bmFtZSkKICAgICAgICAgcmVtb3ZlX2l0KGxpc3RuYW1lLCBkaXIsIG1z ZykKKwlvcy5zeXN0ZW0ocm1hbGlhc2VzIGxpc3RuYW1lKQogCiAMCiBpZiBfX25hbWVfXyA9PSAn X19tYWluX18nOgpkaWZmIC1OYXVyIC4vbWFpbG1hbi0xLjBiOS9jb25maWd1cmUuaW4gLi9tYWls bWFuLTEuMGI5cC9jb25maWd1cmUuaW4KLS0tIC4vbWFpbG1hbi0xLjBiOS9jb25maWd1cmUuaW4J U2F0IEZlYiAyNyAxOToyNDoyMSAxOTk5CisrKyAuL21haWxtYW4tMS4wYjlwL2NvbmZpZ3VyZS5p bglGcmkgTWFyICA1IDE2OjI3OjUzIDE5OTkKQEAgLTE3LDcgKzE3LDcgQEAKIGRubCBQcm9jZXNz IHRoaXMgZmlsZSB3aXRoIGF1dG9jb25mIHRvIHByb2R1Y2UgYSBjb25maWd1cmUgc2NyaXB0Lgog QUNfUkVWSVNJT04oJFJldmlzaW9uOiAxLjMxICQpCiBBQ19QUkVSRVEoMi4wKQotQUNfSU5JVChz cmMvYWxpYXMtd3JhcHBlci5jKQorQUNfSU5JVChzcmMvYWRkYWxpYXMtd3JhcHBlci5jKQogCiAK ICMgL2hvbWUvbWFpbG1hbiBpcyB0aGUgZGVmYXVsdCBpbnN0YWxsYXRpb24gZGlyZWN0b3J5CkBA IC0xNDgsMTAgKzE0OCwxMCBAQAogZm9yIHVzZXIgaW4gc3RyaW5nLnNwbGl0KCIkMiIpOgogICAg IHRyeToKICAgICAgICAgdHJ5OgotCSAgICB1aWQgPSBwd2QuZ2V0cHd1aWQoaW50KHVzZXIpKVsw XQorCSAgICB1aWQgPSBwd2QuZ2V0cHd1aWQoaW50KHVzZXIpKVsyXQogCSAgICBicmVhawogCWV4 Y2VwdCBWYWx1ZUVycm9yOgotCSAgICB1aWQgPSBwd2QuZ2V0cHduYW0odXNlcilbMF0KKwkgICAg dWlkID0gcHdkLmdldHB3bmFtKHVzZXIpWzJdCiAJICAgIGJyZWFrCiAgICAgZXhjZXB0IEtleUVy cm9yOgogICAgICAgICB1aWQgPSAnJwpAQCAtMjkyLDkgKzI5MiwxMCBAQAogKioqKiogZG9jdW1l bnRhdGlvbiwgYW5kIHRoZSBJTlNUQUxMIGZpbGUgZm9yIGRldGFpbHNdKQogZmkKIAotCi0jTU1f RklORF9VU0VSX0lEKEFMSUFTX1VJRCwgbWFpbG1hbiwgYWxpYXNfd3JhcHBlcikKLSNNTV9GSU5E X0dST1VQX0lEKEFMSUFTX0dJRCwgbWFpbCwgYWxpYXNfd3JhcHBlcikKK0FDX01TR19DSEVDS0lO Ryhmb3IgYWxpYXMgd3JhcHBlciBVSUQpCitNTV9GSU5EX1VTRVJfSUQoQUxJQVNfVUlELCBtYWls bWFuLCBhbGlhc193cmFwcGVyKQorQUNfTVNHX0NIRUNLSU5HKGZvciBhbGlhcyB3cmFwcGVyIEdJ RCkKK01NX0ZJTkRfR1JPVVBfSUQoQUxJQVNfR0lELCBtYWlsbWFuLCBhbGlhc193cmFwcGVyKQog CiAjIENoZWNrIGZvciBDR0kgZXh0ZW5zaW9ucywgcmVxdWlyZWQgYnkgc29tZSBXZWIgc2VydmVy cwogQUNfU1VCU1QoQ0dJRVhUKQpkaWZmIC1OYXVyIC4vbWFpbG1hbi0xLjBiOS9taXNjL01ha2Vm aWxlLmluIC4vbWFpbG1hbi0xLjBiOXAvbWlzYy9NYWtlZmlsZS5pbgotLS0gLi9tYWlsbWFuLTEu MGI5L21pc2MvTWFrZWZpbGUuaW4JVGh1IEphbiAxNCAyMzoyMjowMSAxOTk5CisrKyAuL21haWxt YW4tMS4wYjlwL21pc2MvTWFrZWZpbGUuaW4JU3VuIE1hciAyMSAyMzoxNDoxNiAxOTk5CkBAIC02 NSw4ICs2NSw4IEBACiAJICAgIGRpcj0kKHByZWZpeCkvJCRkOyBcCiAJICAgICQoSU5TVEFMTCkg LW0gJChGSUxFTU9ERSkgcGF0aHMucHkgJCRkaXI7IFwKIAlkb25lCi0JJChJTlNUQUxMKSAtbSAk KERBVEFNT0RFKSBwZW5kaW5nX3N1YnNjcmlwdGlvbnMuZGIgJChwcmVmaXgpL2RhdGEKLQorCSQo SU5TVEFMTCkgLW0gJChEQVRBTU9ERSkgcGVuZGluZ19zdWJzY3JpcHRpb25zLmRiICQoREFUQURJ UikKKwkKIGZpbmlzaDoKIAogY2xlYW46CmRpZmYgLU5hdXIgLi9tYWlsbWFuLTEuMGI5L3NyYy9N YWtlZmlsZS5pbiAuL21haWxtYW4tMS4wYjlwL3NyYy9NYWtlZmlsZS5pbgotLS0gLi9tYWlsbWFu LTEuMGI5L3NyYy9NYWtlZmlsZS5pbglTYXQgRmViIDI3IDE5OjMwOjIxIDE5OTkKKysrIC4vbWFp bG1hbi0xLjBiOXAvc3JjL01ha2VmaWxlLmluCVN1biBNYXIgMjEgMjM6NTE6NDIgMTk5OQpAQCAt MzYsMTUgKzM2LDE2IEBACiAjIFVJRHMgYW5kIEdJRHMKIE1BSUxfR0lEPSAgICAgIAlATUFJTF9H SURACiBDR0lfR0lEPQlAQ0dJX0dJREAKLSNBTElBU19VSUQ9CUBBTElBU19VSURACi0jQUxJQVNf R0lEPQlAQUxJQVNfR0lEQAorQUxJQVNfVUlEPQlAQUxJQVNfVUlEQAorQUxJQVNfR0lEPQlAQUxJ QVNfR0lEQAogTUFJTE1BTl9VSUQ9CUBNQUlMTUFOX1VJREAKK01BSUxNQU5fR0lEPQlATUFJTE1B Tl9HSURACiAKICMgQ3VzdG9taXphYmxlIGJ1dCBub3Qgc2V0IGJ5IGNvbmZpZ3VyZQogT1BUPQkJ QE9QVEAKIENGTEFHUz0JCSQoT1BUKSAkKERFRlMpCiBDR0lESVI9IAkkKGV4ZWNfcHJlZml4KS9j Z2ktYmluCi1DR0lFWFQ9CQlAQ0dJRVhUQAorQ0dJRVhUPQkJQENHSUVYVEAJCQogTUFJTERJUj0J JChleGVjX3ByZWZpeCkvbWFpbAogCiBTSEVMTD0JCS9iaW4vc2gKQEAgLTUzLDggKzU0LDggQEAK IAogQ0dJX0ZMQUdTPQktRENHSV9HSUQ9JChDR0lfR0lEKQogCi0jQUxJQVNfRkxBR1M9CS1EQUxJ QVNfVUlEPSQoQUxJQVNfVUlEKSBcCi0jCQktREFMSUFTX0dJRD0kKEFMSUFTX0dJRCkKK0FMSUFT X0ZMQUdTPQktREFMSUFTX1VJRD0kKEFMSUFTX1VJRCkgXAorCQktREFMSUFTX0dJRD0kKEFMSUFT X0dJRCkKIAogSEVMUEZVTD0JLURIRUxQRlVMCiAKQEAgLTc3LDI0ICs3OCwyOCBAQAogCiBNQUlM X1BST0dTPSB3cmFwcGVyCiAKLSNBTElBU19QUk9HUz0gYWRkYWxpYXNlcworQUREQUxJQVNfUFJP R1M9IGFkZGFsaWFzZXMKK1JNQUxJQVNfUFJPR1M9IHJtYWxpYXNlcworQUxJQVNfUFJPR1M9IHJt YWxpYXNlcyBhZGRhbGlhc2VzCiAKIFNVSURfQ0dJX1BST0dTPSBwcml2YXRlCiAKIFNVSURfTUFJ TF9QUk9HUz0KIAotUFJPR1JBTVM9ICQoQ0dJX1BST0dTKSAkKE1BSUxfUFJPR1MpICQoQUxJQVNf UFJPR1MpCitQUk9HUkFNUz0gJChDR0lfUFJPR1MpICQoTUFJTF9QUk9HUykgJChBRERBTElBU19Q Uk9HUykgJChSTUFMSUFTX1BST0dTKQogCiAKICMgUnVsZXMKIAogYWxsOiAkKFBST0dSQU1TKQog Ci13cmFwcGVyOiAkKHNyY2RpcikvbWFpbC13cmFwcGVyLmMgY29tbW9uLm8KKyQoTUFJTF9QUk9H Uyk6ICQoc3JjZGlyKS9tYWlsLXdyYXBwZXIuYyBjb21tb24ubwogCSQoQ0MpIC1JLiAkKE1BSUxf RkxBR1MpICQoQ0ZMQUdTKSBjb21tb24ubyAtbyAkQCAkKHNyY2RpcikvbWFpbC13cmFwcGVyLmMK IAotI2FkZGFsaWFzZXM6ICQoc3JjZGlyKS9hbGlhcy13cmFwcGVyLmMgY29tbW9uLm8KLSMJJChD QykgLUkuICQoQUxJQVNfRkxBR1MpICQoQ0ZMQUdTKSAtbyAkQCAkKHNyY2RpcikvYWxpYXMtd3Jh cHBlci5jCiskKEFEREFMSUFTX1BST0dTKTogJChzcmNkaXIpL2FkZGFsaWFzLXdyYXBwZXIuYyBj b21tb24ubworCSQoQ0MpIC1JLiAkKEFMSUFTX0ZMQUdTKSAkKENGTEFHUykgLW8gJEAgJChzcmNk aXIpL2FkZGFsaWFzLXdyYXBwZXIuYworJChSTUFMSUFTX1BST0dTKTogJChzcmNkaXIpL3JtYWxp YXMtd3JhcHBlci5jIGNvbW1vbi5vCisJJChDQykgLUkuICQoQUxJQVNfRkxBR1MpICQoQ0ZMQUdT KSAtbyAkQCAkKHNyY2Rpcikvcm1hbGlhcy13cmFwcGVyLmMKIAogJChDR0lfUFJPR1MpOiAkKHNy Y2RpcikvY2dpLXdyYXBwZXIuYyBjb21tb24ubwogCSQoQ0MpIC1EU0NSSVBUPSJcIiRAXCIiIC1J LiAkKENHSV9GTEFHUykgJChDRkxBR1MpIGNvbW1vbi5vIC1vICRAICQoc3JjZGlyKS9jZ2ktd3Jh cHBlci5jCkBAIC0xMDcsMTcgKzExMiwyMCBAQAogCWRvIFwKIAkgICAgZXhlPSQoQ0dJRElSKS8k JGYkKENHSUVYVCk7IFwKIAkgICAgJChJTlNUQUxMX1BST0dSQU0pICQkZiAkJGV4ZTsgXAorCSAg ICBjaG93biAkKE1BSUxNQU5fVUlEKTokKE1BSUxNQU5fR0lEKSAkKENHSURJUikvJCRmOyBcCiAJ ICAgIGNobW9kIGcrcyAkJGV4ZTsgXAogCWRvbmUKIAlmb3IgZiBpbiAkKE1BSUxfUFJPR1MpOyBc CiAJZG8gXAogCSAgICAkKElOU1RBTExfUFJPR1JBTSkgJCRmICQoTUFJTERJUik7IFwKKwkgICAg Y2hvd24gJChNQUlMTUFOX1VJRCk6JChNQUlMTUFOX0dJRCkgJChNQUlMRElSKS8kJGY7IFwKIAkg ICAgY2htb2QgZytzICQoTUFJTERJUikvJCRmOyBcCiAJZG9uZQotIwlAZm9yIGYgaW4gJChBTElB U19QUk9HUyk7IFwKLSMJZG8gXAotIwkgICAgJChJTlNUQUxMX1BST0dSQU0pICQkZiAkKGJpbmRp cikgOyBcCi0jCWRvbmUKKwlAZm9yIGYgaW4gJChBTElBU19QUk9HUyk7IFwKKwlkbyBcCisJICAg ICQoSU5TVEFMTF9QUk9HUkFNKSAkJGYgJChiaW5kaXIpIDsgXAorCSAgICBjaG93biAkKEFMSUFT X1VJRCk6JChBTElBU19HSUQpICQoYmluZGlyKS8kJGY7IFwKKwlkb25lCiAKIGZpbmlzaDoKIAkt Zm9yIGYgaW4gJChTVUlEX0NHSV9QUk9HUyk7IFwKZGlmZiAtTmF1ciAuL21haWxtYW4tMS4wYjkv c3JjL2FkZGFsaWFzLXdyYXBwZXIuYyAuL21haWxtYW4tMS4wYjlwL3NyYy9hZGRhbGlhcy13cmFw cGVyLmMKLS0tIC4vbWFpbG1hbi0xLjBiOS9zcmMvYWRkYWxpYXMtd3JhcHBlci5jCVR1ZSBNYXkg MjYgMTQ6NDI6MzggMTk5OAorKysgLi9tYWlsbWFuLTEuMGI5cC9zcmMvYWRkYWxpYXMtd3JhcHBl ci5jCU1vbiBNYXIgMjIgMDA6MDA6NDMgMTk5OQpAQCAtMTgsMTUgKzE4LDI0IEBACiAgKiBGb3Vu ZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UgLSBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEgMDIx MTEtMTMwNywgVVNBLgogICovCiAKKwogI2luY2x1ZGUgPHN0ZGlvLmg+CisjaW5jbHVkZSA8dGlt ZS5oPgogCisvKiAjZGVmaW5lIExFR0FMX1BBUkVOVF9VSUQgTUFJTE1BTl9VSUQ7CisjZGVmaW5l IExFR0FMX1BBUkVOVF9HSUQgTUFJTE1BTl9HSUQ7Ki8KIC8qIHBhc3NlZCBpbiBmcm9tIGNvbmZp Z3VyZSBzY3JpcHQgKi8KLWNvbnN0IGludCAgTEVHQUxfUEFSRU5UX1VJRCA9IEFMSUFTX1VJRDsg ICAgIC8qIG1haWxtYW4ncyBVSUQgKi8KLWNvbnN0IGludCAgTEVHQUxfUEFSRU5UX0dJRCA9IEFM SUFTX0dJRDsgICAgIC8qIG1haWwncyBHSUQgKi8KK2NvbnN0IGludCAgTEVHQUxfUEFSRU5UX1VJ RCA9IEFMSUFTX1VJRDsgICAvKiBtYWlsbWFuJ3MgVUlEICovCitjb25zdCBpbnQgIExFR0FMX1BB UkVOVF9HSUQgPSBBTElBU19HSUQ7ICAgIC8qIG1haWwncyBHSUQgKi8KKworCiAKIGNvbnN0IGNo YXIqIFNFTkRNQUlMX0NNRCA9ICIvdXNyL3NiaW4vc2VuZG1haWwiOwotY29uc3QgY2hhciogQUxJ QVNfRklMRSAgID0gIi9ldGMvYWxpYXNlcyI7Ci1jb25zdCBjaGFyKiBXUkFQUEVSICAgICAgPSAi L2hvbWUvbWFpbG1hbi9tYWlsbWFuL21haWwvd3JhcHBlciI7Citjb25zdCBjaGFyKiBBTElBU19G SUxFICAgPSAiL2V0Yy9tYWlsbWFuL2FsaWFzZXMiOworY29uc3QgY2hhciogV1JBUFBFUiAgICAg ID0gIi9ob21lL21haWxtYW4vbWFpbC93cmFwcGVyIjsKKworCisKIAogLyogCiAqKiBpcyB0aGUg cGFyZW50IHByb2Nlc3MgYWxsb3dlZCB0byBjYWxsIHVzPwpAQCAtNTIsMzIgKzYxLDMzIEBACiB7 CiAJRklMRSAqZjsKIAlpbnQgIGVyciA9IDA7Ci0KKwl0aW1lX3Qgc2VjczsKKwl0aW1lKCAmc2Vj cyApOwogCWYgPSBmb3BlbihBTElBU19GSUxFICwiYSsiKTsKIAlpZiAoZiA9PSBOVUxMKSB7CiAJ CWVyciA9IDE7CiAJCWYgPSBzdGRlcnI7CiAJCWZwcmludGYoZiwgIlxuXG4qKioqKioqKioqKkVS Uk9SISEhISoqKioqKioqKioqXG4iKTsKLQkJZnByaW50ZihmLCAiQ291bGQgbm90IHdyaXRlIHRv IHRoZSAvZXRjL2FsaWFzZXMgZmlsZS5cbiIpOworCQlmcHJpbnRmKGYsICJDb3VsZCBub3Qgd3Jp dGUgdG8gdGhlIGFsaWFzZXMgZmlsZS5cbiIpOwogCQlmcHJpbnRmKGYsICJQbGVhc2UgYmVjb21l IHJvb3QsIGFkZCB0aGUgbGluZXMgYmVsb3cgdG9cbiIpOwogCQlmcHJpbnRmKGYsICJ0aGF0IGZp bGUsIGFuZCB0aGVuIHJ1biB0aGUgY29tbWFuZDpcbiIpOwogCQlmcHJpbnRmKGYsICIlcyAtYmlc biIsIFNFTkRNQUlMX0NNRCk7CiAJfQogCi0JZnByaW50ZihmLCAiXG5cbiMtLSAlcyAtLSBtYWls aW5nIGxpc3QgYWxpYXNlczpcbiIsIGxpc3QpOwotCWZwcmludGYoZiwgIiVzOiBcdHxcIiVzIHBv c3QgJXNcIlxuIiwgbGlzdCwgV1JBUFBFUiwgbGlzdCk7CisJZnByaW50ZihmLCAiIyMgJXMgbWFp bGluZyBsaXN0OlxuIiwgbGlzdCk7CisJZnByaW50ZihmLCAiIyMgY3JlYXRlZCBieSBtYWlsbWFu IG9uOiAlcyIsIGN0aW1lKCZzZWNzKSk7CisJZnByaW50ZihmLCAiJXM6IFx0XHR8XCIlcyBwb3N0 ICVzXCJcbiIsIGxpc3QsIFdSQVBQRVIsIGxpc3QpOwogCWZwcmludGYoZiwgIiVzLWFkbWluOiBc dHxcIiVzIG1haWxvd25lciAlc1wiXG4iLCBsaXN0LCBXUkFQUEVSLCBsaXN0KTsKIAlmcHJpbnRm KGYsICIlcy1yZXF1ZXN0OiBcdHxcIiVzIG1haWxjbWQgJXNcIlxuIiwgbGlzdCwgV1JBUFBFUiwg bGlzdCk7Ci0JZnByaW50ZihmLCAiIyBJIHRoaW5rIHdlIGRvbid0IHdhbnQgdGhpcyBvbmUuLi5c biIpOwotCWZwcmludGYoZiwgIml0J2xsIGNoYW5nZSB0aGUgdW5peCBmcm9tIGxpbmUuLi5cbiIp OwotCWZwcmludGYoZiwgIiNvd25lci0lczogXHQlcy1hZG1pblxuIiwgbGlzdCwgbGlzdCk7Ci0J ZnByaW50ZihmLCAiIyVzLW93bmVyOiBcdCVzLWFkbWluXG4iLCBsaXN0LCBsaXN0KTsKLQlmcHJp bnRmKGYsICJcbiIpOworCWZwcmludGYoZiwgIm93bmVyLSVzOiBcdCVzLWFkbWluXG4iLCBsaXN0 LCBsaXN0KTsKKwlmcHJpbnRmKGYsICIlcy1vd25lcjogXHQlcy1hZG1pblxuIiwgbGlzdCwgbGlz dCk7CisJZnByaW50ZihmLCAiXG5cblxuIik7CiAJZmNsb3NlKGYpOwogCiAJaWYgKCFlcnIpIHsK IAkJcHJpbnRmKCJSZWJ1aWxkaW5nIGFsaWFzIGRhdGFiYXNlLi4uXG4iKTsKLQkJZXhlY2xwKFNF TkRNQUlMX0NNRCwgU0VORE1BSUxfQ01ELCAiLWJpIik7CisJCWV4ZWNscChTRU5ETUFJTF9DTUQs IFNFTkRNQUlMX0NNRCwgIi1iaSIsIE5VTEwpOworCQkKIAl9CiB9CiAK ------=_NextPart_000_008C_01BE74AA.C0C21600-- From Harald.Meland@usit.uio.no Wed Mar 24 23:34:14 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 25 Mar 1999 00:34:14 +0100 Subject: [Mailman-Developers] Does anyone else see these? In-Reply-To: J C Lawrence's message of "Fri, 05 Mar 1999 10:19:54 -0800" References: Message-ID: [J C Lawrence] > On Fri, 5 Mar 1999 01:17:53 -0600 (CST) > Christopher Lindsey wrote: > > > Perhaps Mailman could add (yet another) header indicating the > > targetted recepient to help with this type of situation? Maybe > > X-Mailman-Recepient? Or it could be wrapped it into another header > > like X-BeenThere... > > One technique I used for my own list software (now defunct) was that > every N'th message to each subscriber was sent individually with > custom headers giving the subscription address, list name etc. At one time I heard a rumour that someone was to implement VERP[1] support in Mailman -- and I even imagined to have heard that the implementation would do VERP on only every Nth posting to keep down list latency. It would be a post-1.0 thing, of course -- but was I merely dreaming all this, or are actually anyone putting any work into this? If no-one are, then someone should be :-) [1] Variable Envelope Return Paths, see for further description. -- Harald From Harald.Meland@usit.uio.no Wed Mar 24 23:53:38 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 25 Mar 1999 00:53:38 +0100 Subject: [Mailman-Developers] MM1.0b9 Bug! (was: Setup prob: abs/rel CGI url) In-Reply-To: Christian Tismer's message of "Fri, 05 Mar 1999 20:45:18 +0100" References: <36DE9318.59C0C8D8@appliedbiometrics.com> <36DE9CD1.60544B41@appliedbiometrics.com> <36DED38D.34DE263F@appliedbiometrics.com> <36E0344E.47E7C3E3@appliedbiometrics.com> Message-ID: [Christian Tismer] > I think it would be better for MM's public acceptance if there was > always a version known to be used in many installations. I, OTOH, don't think that'd solve anything much. The very reason for releasing Betas is to get rid of bugs. The intention is that each new Beta should have fewer bugs than any of the previous ones. Of course, due to human nature and Murphy's Law, whenever someone tries to fix a bug there is a non-zero probability that something else gets broken. > It would not have all new features, but also not the new bugs. Unless you trade away the Good of getting old bugs fixed, you can't avoid the Bad of maybe introducing new bugs. > In other words: If the latest beta needed a bug fix, why don't we > mark it as problematic and go back to, say, 1.0b7? IMHO, this might be a viable plan if we were talking about stable releases. We're not. We're talking about Beta releases. Cheers, -- Harald From claw@varesearch.com Thu Mar 25 00:21:38 1999 From: claw@varesearch.com (J C Lawrence) Date: Wed, 24 Mar 1999 16:21:38 -0800 Subject: [Mailman-Developers] Does anyone else see these? In-Reply-To: Message from Harald Meland of "25 Mar 1999 00:34:14 +0100." Message-ID: On 25 Mar 1999 00:34:14 +0100 Harald Meland wrote: > At one time I heard a rumour that someone was to implement VERP[1] > support in Mailman -- and I even imagined to have heard that the > implementation would do VERP on only every Nth posting to keep > down list latency. I implemented something like this for a home-grown list server, and chattered about that design on this list. I'm not aware of anyone buying into the idea, and I've been far too busy with Linux/Merced to do more than wanly wish for it. -- J C Lawrence Internet: claw@kanga.nu ---------(*) Internet: claw@varesearch.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From jeffh@streek.com Thu Mar 25 16:24:45 1999 From: jeffh@streek.com (Jeff Hahn) Date: Thu, 25 Mar 1999 10:24:45 -0600 Subject: [Mailman-Developers] bulk add users "issues" Message-ID: <001201be76db$feab30e0$1e0a5ad1@SINGSING.STREEK.COM> couple of issues: 1. I've also run into a problem I believe I remember reading about on this list. add_members seg faults at about 500 users added in a run. I've got the dumpfile, but since I don't have python compiled with debugging, not sure it's of any value to anyone. (RH 5.2, Python 1.5.1, latest CVS of Mailman) 2. When bulk adding members (either thru the web page or add_members) the digest type appears to be random (not the default digest mode as defined for the list) I've scanned thru the source, but I don't see anything "obvious", but I've probably overlooked something easy. -Jeff From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Mar 26 16:46:13 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 26 Mar 1999 11:46:13 -0500 (EST) Subject: [Mailman-Developers] Mailman 1.0b10 Message-ID: <14075.47573.821308.819354@anthem.cnri.reston.va.us> Hi everyone, I'm releasing Mailman 1.0b10 today; hopefully we'll have more luck with this than b9. I need to concentrate on other things for a while, now that python.org seems to be smoothly running this version. Unless there are showstopper bugs, I would like this version to be 1.0 final, so please do bang on it a lot. If you do find bugs, it would be great if you can enter them into the Jitterbug database. See http://www.python.org/mailman-bugs I know there's a lot y'all would like to see done. Weighed against the slippage in when I thought 1.0 final would be out, I think we have to just be happy with what we've got for now, get it out the door, and then begin working on improvements. Like John said at LISA: "all mailing list managers suck, ours just sucks less" ... hopefully :-) Go to www.list.org to pick up the current tarball. Note that the old ftp URL won't work anymore. BE SURE TO READ THE `UPGRADING' FILE FOR IMPORTANT INFORMATION. There's still time to vote on the logo. Voting is closed whenever I do the first release candidate (no date set, but SOON). My priority for the next release will be to craft the Web pages for gnu.org, clean up documentation, and get things ready for the mass of new adopters (yeah!). I can't guarantee that I'll be hacking any code unless there's severe breakage in this tarball. Enjoy, and thanks everyone, -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Mar 26 16:48:12 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 26 Mar 1999 11:48:12 -0500 (EST) Subject: [Mailman-Developers] Mailman 1.0b10 References: <14075.47573.821308.819354@anthem.cnri.reston.va.us> Message-ID: <14075.47692.844754.75868@anthem.cnri.reston.va.us> Oops, here's the NEWS file entries for 1.0b10. 1.0b10 - New script bin/sync_members which can be used to synchronize a list's membership against a flat (e.g. sendmail :include: style) file. - bin/add_members and bin/remove_members now accept addresses on the command line with `-' as the value for the -d and -n options. - Added variable USE_ENVELOPE_SENDER to Defaults.py for site-wide configuration of address matching scheme. With this variable set to true, the envelope sender (e.g. Unix "From_" header) is used to match addresses, otherwise the From: header is used. Envelope sender matching seems not to work on many systems. This variable is currently defaulted to 1, but may change to 0 for the final release. - Reorganization of the membership management admin page. Also member addresses are linked to their options page. Only the `General' category has the admin password change form. - Major reorganization of email command handling and responses. `notmetoo' is the preferred email command instead of `norcv', although the latter is still accepted as an argument. If more than 5 errors are found in the message, command processing is halted. - User options page now shows the user their case-preserved subscribed address as well. - The usual assortment of bug fixes. From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Mon Mar 29 18:45:42 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 29 Mar 1999 13:45:42 -0500 (EST) Subject: [Mailman-Developers] 1.0b10 Message-ID: <14079.51798.702519.838718@anthem.cnri.reston.va.us> Folks, please don't upgrade to 1.0b10 just yet. I think there's still a problem with address matching and case preservation. I have a fix and am going to do a bunch of testing, /and/ hopefully get some sanity checking from Ken on a few things. Once I get this fixed, I will release 1.0b11. Note that this should be unrelated to the problem that Clark is having. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Mar 30 03:15:49 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 29 Mar 1999 22:15:49 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] mailman, postifx, and bsdos3 References: <4.1.19990329120242.038f50b0@10.0.0.1> Message-ID: <14080.16869.597516.622115@anthem.cnri.reston.va.us> >>>>> "GME" == George M Ellenburg writes: GME> At the request of some of my customers, I've recently GME> installed mailman on BSD 3.1, with Postfix beta-19990317-pl02 GME> as the transport. GME> Frankly, I'm a little confused with regards to the install GME> instructions. Was wondering if anyone can provide some GME> elightenment. GME> I'm getting the following error when trying to create a test list: | sundial:~/bin $ whoami | mailman | sundial:~/bin $ ./newlist | Enter the name of the list: test | Enter the email of the person running the list: gme@caffeine.sundial.net | Initial test password: testpassword | Traceback (innermost last): | File "./newlist", line 141, in ? | raise SystemExit(main(sys.argv)) | File "./newlist", line 91, in main | newlist.Create(list_name, owner_mail, pw) | File "/u1/mailman/Mailman/MailList.py", line 658, in Create | self.Lock() | File "/u1/mailman/Mailman/MailList.py", line 1213, in Lock | self._lock_file.lock('w|', 1) | File "/usr/local/lib/python1.5/posixfile.py", line 190, in lock | flock = fcntl.fcntl(self._file_.fileno(), cmd, flock) | IOError: (22, 'Invalid argument') | sundial:~/bin $ I'm Cc'ing the Mailman developers and Guido on this message, because I suspect there's a problem with your Python on your operating system (BSD 3.1). For some reason lock() method on the posixfile object is failing. This method eventually calls down to fcntl() and the `|' modifier translates to F_SETLKW. fcntl(2) says that this could fail and return EINVAL (i.e. errno 22) as described in my Solaris manpage: EINVAL The cmd argument is invalid; or the cmd argu- ment is F_DUPFD and arg is negative or greater than or equal to OPEN_MAX; or the cmd argument is F_GETLK, F_GETLK64, F_SETLK, F_SETLK64, F_SETLKW, or F_SETLKW64 and the data pointed to by arg is not valid; or fildes refers to a file that does not support locking. I've never seen this happen before, at least in the context of Mailman, so that's why I'm suspecting your OS, of which I have no experience. What does your sys.platform say? Maybe someone else has some idea about why this is failing. -Barry From guido@CNRI.Reston.VA.US Tue Mar 30 03:35:01 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 29 Mar 1999 22:35:01 -0500 Subject: [Mailman-Developers] Re: [Mailman-Users] mailman, postifx, and bsdos3 In-Reply-To: Your message of "Mon, 29 Mar 1999 22:15:49 EST." <14080.16869.597516.622115@anthem.cnri.reston.va.us> References: <4.1.19990329120242.038f50b0@10.0.0.1> <14080.16869.597516.622115@anthem.cnri.reston.va.us> Message-ID: <199903300335.WAA02768@eric.cnri.reston.va.us> The mention of posixfile, fcntl and BSD made me remember something. There's some very non-portable code that constructs the fcntl call. The CVS archives have a version of posixfile.py that is newer than that in the Python 1.5.2b2 release, and the CVS log comment says: | According to Jeffrey Honig, bsd/os 2.0 - 4.0 should be added to the | list (of bsd variants that have a different lock structure). Here's the patch: Index: posixfile.py =================================================================== RCS file: /projects/cvsroot/python/dist/src/Lib/posixfile.py,v retrieving revision 1.10 retrieving revision 1.11 diff -c -r1.10 -r1.11 *** posixfile.py 1998/03/26 21:12:38 1.10 --- posixfile.py 1999/02/23 04:14:32 1.11 *************** *** 177,183 **** # Hack by davem@magnet.com to get locking to go on freebsd; # additions for AIX by Vladimir.Marangozov@imag.fr import sys, os ! if sys.platform in ('netbsd1', 'freebsd2', 'freebsd3'): flock = struct.pack('lxxxxlxxxxlhh', \ l_start, l_len, os.getpid(), l_type, l_whence) elif sys.platform in ['aix3', 'aix4']: --- 177,185 ---- # Hack by davem@magnet.com to get locking to go on freebsd; # additions for AIX by Vladimir.Marangozov@imag.fr import sys, os ! if sys.platform in ('netbsd1', ! 'freebsd2', 'freebsd3', ! 'bsdos2', 'bsdos3', 'bsdos4'): flock = struct.pack('lxxxxlxxxxlhh', \ l_start, l_len, os.getpid(), l_type, l_whence) elif sys.platform in ['aix3', 'aix4']: *************** *** 190,196 **** flock = fcntl.fcntl(self._file_.fileno(), cmd, flock) if '?' in how: ! if sys.platform in ('netbsd1', 'freebsd2', 'freebsd3'): l_start, l_len, l_pid, l_type, l_whence = \ struct.unpack('lxxxxlxxxxlhh', flock) elif sys.platform in ['aix3', 'aix4']: --- 192,200 ---- flock = fcntl.fcntl(self._file_.fileno(), cmd, flock) if '?' in how: ! if sys.platform in ('netbsd1', ! 'freebsd2', 'freebsd3', ! 'bsdos2', 'bsdos3', 'bsdos4'): l_start, l_len, l_pid, l_type, l_whence = \ struct.unpack('lxxxxlxxxxlhh', flock) elif sys.platform in ['aix3', 'aix4']: --Guido van Rossum (home page: http://www.python.org/~guido/) From nbecker@fred.net Tue Mar 30 18:37:19 1999 From: nbecker@fred.net (nbecker@fred.net) Date: 30 Mar 1999 13:37:19 -0500 Subject: [Mailman-Developers] exim - Failure to exec script- gid question Message-ID: I'm using mailman-1.0b10 + exim-2.10. Mar 30 13:10:08 nbeckerpc Mailman mail-wrapper: Failure to exec script. WANTED gid 12, GOT gid 99. (Reconfigure to take 99?) I can reconfigure mailman or exim to set the gid, but why is it needed at all? Since wrapper is sgid, why does it care what gid was used to invoke it? Just additional security check? From Gergely Madarasz Wed Mar 31 08:50:14 1999 From: Gergely Madarasz (Gergely Madarasz) Date: Wed, 31 Mar 1999 10:50:14 +0200 (METDST) Subject: [Mailman-Developers] problems with who ? Message-ID: I'm running mailman 1.0b10 This is all I get from a who request. ---------- Forwarded message ---------- Date: Wed, 31 Mar 1999 10:48:22 +0200 From: linux-flame-request@mlf.linux.rulez.org To: gorgo@caesar.elte.hu Subject: Mailman results for linux-flame ***** who Digest Members: anovak@nap-szam.hu atom@sophia.jpte.hu b-b0mb@freemail.c3.hu ba... Non-Digest Members: a7803268@unet.univie.ac.at a_linux@freemail.c3.hu acsosz@mail.da... From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Mar 31 16:41:13 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 31 Mar 1999 11:41:13 -0500 (EST) Subject: [Mailman-Developers] problems with who ? References: Message-ID: <14082.20521.113988.624234@anthem.cnri.reston.va.us> >>>>> "GM" == Gergely Madarasz writes: GM> I'm running mailman 1.0b10 GM> This is all I get from a who request. Simple fix attached. Thanks, -Barry -------------------- snip snip -------------------- Index: MailCommandHandler.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/MailCommandHandler.py,v retrieving revision 1.43 retrieving revision 1.44 diff -c -r1.43 -r1.44 *** MailCommandHandler.py 1999/03/24 19:15:51 1.43 --- MailCommandHandler.py 1999/03/31 16:32:32 1.44 *************** *** 448,460 **** self.AddToResponse(string.join(map(AddTab, filter(NotHidden, digestmembers)), ! "\n")) if len(members): self.AddToResponse("Non-Digest Members:") members.sort() self.AddToResponse(string.join(map(AddTab, filter(NotHidden, members)), ! "\n")) def ProcessUnsubscribeCmd(self, args, cmd, mail): if not len(args): --- 448,460 ---- self.AddToResponse(string.join(map(AddTab, filter(NotHidden, digestmembers)), ! "\n"), trunc=0) if len(members): self.AddToResponse("Non-Digest Members:") members.sort() self.AddToResponse(string.join(map(AddTab, filter(NotHidden, members)), ! "\n"), trunc=0) def ProcessUnsubscribeCmd(self, args, cmd, mail): if not len(args): From lindsey@ncsa.uiuc.edu Wed Mar 31 21:36:33 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Wed, 31 Mar 1999 15:36:33 -0600 (CST) Subject: [Mailman-Developers] mailman and AFS? Message-ID: <199903312136.PAA02853@ferret.ncsa.uiuc.edu> Well, I'm about to try doing some funky stuff that's going to require source changes, etc. But before I jump into it, I've got some questions. I want to setup mailman here at NCSA and gradually start phasing out majordomo. Here's the current set up: 4 mail servers NFS-RAID sharing mail spools, procmail recipes, etc. AFS (this is a common filesystem everywhere) 8 round-robined Web servers (DocumentRoot served from AFS) Because AFS is the only available common filesystem for both the mail servers and the Web servers, I'll need to setup mailman there. Now for the tricky part. AFS doesn't use standard UNIX permissions, but instead depends on ACLs (ours uses Kerberos V for authentication). To be able to write into the AFS space, any program or shell must have a valid AFS token. I can do this by creating a "keytab" file; basically, that randomizes the password but lets me use it in shell scripts, etc. I just need to kinit against this file, do my operations, then do a kdestroy. Now for my questions: o where should I put these calls? I'm guessing that they should be in wrapper, but do I also need to put it into every binary in $prefix/cgi-bin? It appears that way... o am I going to run into any locking issues with multiple email and Web servers, or does mailman handle this? If so, how? AFS (like NFS) often has problems with flock() or fcntl() locking (so dot-locking is the preferred method). o does mailman actually do any permissions checking on files or directories? These checks would fail in AFS Any pointers and/or answers would be appreciated. Thanks, Chris From tismer@appliedbiometrics.com Mon Mar 1 17:22:04 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Mon, 01 Mar 1999 18:22:04 +0100 Subject: [Mailman-Developers] [Fwd: Re: [Mailman-Users] Upgrade script for old databases?] References: <36D04FA3.B89B8B4C@digicool.com> <14040.12883.500649.8224@anthem.cnri.reston.va.us> Message-ID: <36DACCBC.BE890949@appliedbiometrics.com> Hi Friends... ... *blush* (gulp) just FYI: I kinda "solved" my problem today, unfortunately. I happened to use the "rmlist" script from Mailman 0.95 without parameters. Then, I realized that this removed *all* mailing lists of starship.skyport.net in a single sweep. Dead, done, no more archives, oh well. I will be able to rebuild the python-de archive from my local mailboxes, but my customers will be unhappy... So, I no longer have a migration problem :-( :-) :-/ !-[ ciao - chris.dead.letter "Barry A. Warsaw" wrote: > > >>>>> "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 > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home From bwarsaw@python.org Mon Mar 1 17:33:32 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Mon, 1 Mar 1999 12:33:32 -0500 (EST) Subject: [Mailman-Developers] [Fwd: Re: [Mailman-Users] Upgrade script for old databases?] References: <36D04FA3.B89B8B4C@digicool.com> <14040.12883.500649.8224@anthem.cnri.reston.va.us> <36DACCBC.BE890949@appliedbiometrics.com> Message-ID: <14042.53100.697046.865758@anthem.cnri.reston.va.us> >>>>> "CT" == Christian Tismer writes: CT> I happened to use the "rmlist" script from Mailman 0.95 CT> without parameters. Then, I realized that this removed *all* CT> mailing lists of starship.skyport.net in a single sweep. Gack! Well, at least this particular bug is fixed in Mailman 1.0b9 (going out today). Small consolation... -Barry From bwarsaw@python.org Mon Mar 1 19:02:02 1999 From: bwarsaw@python.org (bwarsaw@python.org) Date: Mon, 1 Mar 1999 14:02:02 -0500 (EST) Subject: [Mailman-Developers] [ANNOUNCE] Mailman 1.0b9 Message-ID: <14042.58410.557890.269150@anthem.cnri.reston.va.us> Folks, I've just uploaded Mailman 1.0b9 to www.list.org. I hope this solves the worst of the Linux problems and fixes most other outstanding bugs. I know there will be at least one more beta, hopefully by this weekend. I have three other minor buglets to fix and I think Ken has a couple of outstanding checkins to make. But I'd like b10 to be the last beta. It's time to get 1.0 out the door (I know I've said this before -- this time I mean it :-). I'd also like to welcome Harald Meland to the Mailman Cabal. John and I met Harald in Boston at the LISA conference last December and liked him a lot. He'll make a great addition to the team. Please check out the contributed logo designs to! We have some nice entries by Heidi, Alexander and Dragon. I'd like to choose one for the final release, so please email me directly with your choice (please DO NOT spam the list with your votes). Enjoy, and let me know if I missed anything. -Barry From gorgo@caesar.elte.hu Mon Mar 1 20:15:17 1999 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Mon, 1 Mar 1999 21:15:17 +0100 (MET) Subject: [Mailman-Developers] [ANNOUNCE] Mailman 1.0b9 In-Reply-To: <14042.58410.557890.269150@anthem.cnri.reston.va.us> Message-ID: On Mon, 1 Mar 1999 bwarsaw@python.org wrote: > I've just uploaded Mailman 1.0b9 to www.list.org. I hope this solves > the worst of the Linux problems and fixes most other outstanding > bugs. Ugh... this means I was _fast_ ;) I just happened to find 1.0b9 an hour ago on the website, and managed to upload the debian package before this announcement hit the lists :)) -- 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) Mon Mar 1 20:12:55 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 1 Mar 1999 15:12:55 -0500 (EST) Subject: [Mailman-Developers] [ANNOUNCE] Mailman 1.0b9 References: <14042.58410.557890.269150@anthem.cnri.reston.va.us> Message-ID: <14042.62663.748607.866882@anthem.cnri.reston.va.us> >>>>> "GM" == Gergely Madarasz writes: GM> Ugh... this means I was _fast_ ;) I just happened to find GM> 1.0b9 an hour ago on the website, and managed to upload the GM> debian package before this announcement hit the lists :)) Faster than Python.org at least :-) -Barry From starback@ling.uu.se Mon Mar 1 23:04:17 1999 From: starback@ling.uu.se (Per Starback) Date: 02 Mar 1999 00:04:17 +0100 Subject: [Mailman-Developers] Re: [Mailman-Users] [ANNOUNCE] Mailman 1.0b9 In-Reply-To: bwarsaw@python.org's message of "Mon, 1 Mar 1999 14:02:02 -0500 (EST)" References: <14042.58410.557890.269150@anthem.cnri.reston.va.us> Message-ID: Barry wrote: > But I'd like b10 to be the last beta. It's time to get 1.0 out the > door (I know I've said this before -- this time I mean it :-). That sounds good! As a very new user of Mailman I can say that the beta version number was one thing that made me hesitant about using Mailman when I recently looked around wondering what MLM I should switch to. (I'm finally leaving SmartList after several years.) > Enjoy, and let me know if I missed anything. It's always nice to have the NEWS file or something like that in announcements of new versions so you can decide if you want to upgrade without having to fetch and unpack the whole thing: # Differences between 1.0b8 and 1.0b9 # # - New bin scripts: clone_member, list_members, add_members (a # consolidation of convertlist and populate_new_list which have been # removed). # # - Two new readmes have been added: README.LINUX and README.QMAIL # # - New configure option --with-cgi-ext which can be used if your Web # server requires extensions on CGI scripts. The extension must # include a dot (e.g. --with-cgi-ext=".cgi"). # # - Many bug fixes, including the setgid problem that was causing mail # to be lost on some versions of Linux. Hm, --with-cgi-ext was in 1.0b8 too. At least it's mentioned in the INSTALL there, but I didn't use it. Wish list: * Add Mail-Followup-To header. (I've done that for myself, but I would appreciate not having to do it again, as well as I'd like to see more use of this useful although nonstandard header.) * Possibility for individual list members to say if they want a Subject line [tag] or not. That would mean that there would have to be two versions of each message, but I think that would be worth it as the [tag]/no tag preference is more about the preferences (and mail situation) of individual list members that about the preferences of the list itself or its maintainer. I would never add a tag like that on my lists per default, but if users who want it could get it explicitly that would be nice. * A line at the Membership Management page where you set default attributes for new users in the same way that you can change attributes for the existing users. This more general feature would be instead of the Which delivery mode is the default for new users? and When receiving digests, which format is default? questions on the Digest-member options page. I think I would like to set "hide" by default, and anyway I think it's better for the future to have one general way of setting the default instead of having to add new list options sometimes when new membership options are made. I'm sorry if my wish list consists of things that have been beaten to death here. Being a list manager myself I should know better than to jump in on a list without lurking for some time first. :-) -- Per Starback "Life is but a gamble! Let flipism chart your ramble!" From roger@infomed.sld.cu Tue Mar 2 00:42:06 1999 From: roger@infomed.sld.cu (=?iso-8859-1?Q?Roger_Pe=F1a_Escobio?=) Date: Mon, 1 Mar 1999 19:42:06 -0500 Subject: [Mailman-Developers] Hi i new in this list and with mailman Message-ID: <01be6445$7fa4a450$1c7001c4@ntserver.sld.cu> This is a multi-part message in MIME format. ------=_NextPart_000_012C_01BE641B.96CE9C50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi to all mailman user and developers :-) how i say in the subject i new with mailman, and i like it :-)) but = there are some things unwanted, first of all , the suid in all subdirs = and in the exe files (not the cgi-bin files), the other things is the = permisions , i dont understant why 775 for all subdirs and not only for = : logs, locks, lists, data, archives , the others just 750 except cgi-bin = (755) . well, i did some changes in source, change the permisions and fix the = alias_wrapper so i can edit a aliases files (/etc/mailman/aliases) and = run sendmail -bi . All looks fine :-)=20 i worked on version b8 i just unload the new version sorry for my english, is not so good=20 Roger ------=_NextPart_000_012C_01BE641B.96CE9C50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Hi to all mailman user and developers = :-)
how i=20 say in the subject i new with mailman, and i like it :-)) but there are = some=20 things unwanted, first of all , the suid in all subdirs and in the exe = files=20 (not the cgi-bin files), the other things is the permisions , i dont = understant=20 why 775 for all subdirs and not only for :
logs,=20 locks, lists, data, archives , the others just 750 except cgi-bin (755)=20 .
 
well,=20 i did some changes in source, change the permisions and fix the = alias_wrapper so=20 i can edit a aliases files (/etc/mailman/aliases) and run sendmail -bi . = All=20 looks fine :-)
i worked on = version b8 i=20 just unload the new version
 
sorry for = my english, is=20 not so good
Roger
------=_NextPart_000_012C_01BE641B.96CE9C50-- From ayu1@nycap.rr.com Tue Mar 2 02:58:47 1999 From: ayu1@nycap.rr.com (Alex Yu) Date: Mon, 01 Mar 1999 21:58:47 -0500 Subject: [Mailman-Developers] Hi i new in this list and with mailman In-Reply-To: <01be6445$7fa4a450$1c7001c4@ntserver.sld.cu> Message-ID: <4.1.19990301215802.00984ba0@pop1.rpi.edu> At 07:42 PM 1999/3/1 -0500, Roger Peņa Escobio wrote: > > how i say in the subject i new with mailman, and i like it :-)) but there are > some things unwanted, first of all , the suid in all subdirs and in the exe > files (not the cgi-bin files), the other things is the permisions , i dont > understant why 775 for all subdirs and not Please DO NOT use send HTML or RICH TEXT email. Most of us are using like *pine* or *elm* to read our emails and it does not support it! Alex From julian7@kva.hu Tue Mar 2 10:36:10 1999 From: julian7@kva.hu (Balazs Nagy) Date: Tue, 2 Mar 1999 11:36:10 +0100 (CET) Subject: [Mailman-Developers] Re: [Mailman-Users] [ANNOUNCE] Mailman 1.0b9 In-Reply-To: Message-ID: On 2 Mar 1999, Per Starback wrote: > Barry wrote: > > > But I'd like b10 to be the last beta. It's time to get 1.0 out the > > That sounds good! As a very new user of Mailman I can say that the > beta version number was one thing that made me hesitant about using > Mailman when I recently looked around wondering what MLM I should > switch to. (I'm finally leaving SmartList after several years.) Well, ezmlm works great - at least at the mailing part of the issue. Mailman works a lot slower but it has more features (except of archive commands). BTW it would be nice if we put an archiving method to Mailman but I don't know which way would be the best. > Hm, --with-cgi-ext was in 1.0b8 too. At least it's mentioned in the > INSTALL there, but I didn't use it. Nope. It was in the INSTALL file but no one put it in until now. > * Possibility for individual list members to say if they want > a Subject line [tag] or not. That would mean that there would have > to be two versions of each message, but I think that would be worth > it as the [tag]/no tag preference is more about the preferences > (and mail situation) of individual list members that about the > preferences of the list itself or its maintainer. I would never > add a tag like that on my lists per default, but if users who want > it could get it explicitly that would be nice. It's not a good idea because this adds more latency and complexity. I think four to eighteen bytes won't hurt anyone if they know who is the sysadmin. -- Regards: Kevin (Balazs) From jeffh@streek.com Tue Mar 2 17:48:26 1999 From: jeffh@streek.com (Jeff Hahn) Date: Tue, 2 Mar 1999 11:48:26 -0600 Subject: [Mailman-Developers] bounce processing question and idea for future enhancements... Message-ID: <00b101be64d4$dfcab240$1e0a5ad1@SINGSING.STREEK.COM> Bounce processing question... Since some of the big email domains (hotmail, aol, etc.) are known to "burp" and deny existence of perfectly valid users, I'd like to handle all returns as bounces and not remove people automatically on the first "user unknown" message. I assume the way to handle it is to change "REMOVE" to "BOUNCE" in the lines like the following in bouncer.py (regex.compile('.*%s: User unknown.*' % email_regexp), REMOVE), Any comments? Any better way to do it? Idea for future enhancements... This is the big one. Does anyone besides me have a desire to see Mailman support Listserv style "topics"? Where topics are extracted from the message subject and list messages are sent to a subset of the list that "subscribes" to that particular topic? I have a very pressing need for this feature. I'm leaving procmail/smartlist because of this and was intending to "roll my own" MLM when I came across MailMan. MailMan supplies a huge portion of the framework with all the nice bells and whistles, so I've decided to start with it. If there is additional interest, I'll try to get rolling on this within the "official" channels. If anyone is interested in collaborating on this that would be great. I certainly haven't been involved with MailMan long at all and don't have any background about the various design choices that were made along the way. Feedback on this would be GREATLY appreciated. -Jeff From bryner@uiuc.edu Wed Mar 3 03:45:28 1999 From: bryner@uiuc.edu (Brian Ryner) Date: Tue, 02 Mar 1999 21:45:28 -0600 Subject: [Mailman-Developers] Bug in password lookup, and possible fix Message-ID: <36DCB058.AC6B1507@uiuc.edu> Hi- I posted this to mailman-users but figured I might get a better response here. There's a bug that can come up when you mass subscribe users. The script does not lowercase the email addresses when they are mass-subscribed. This causes problems for just about everything, including password lookup, because when you type the email address to go to the options page, it uses a lowercased version of it. Then, since the password is stored with an uppercased version of the address, it can't find it. If users subscribe themselves, their email address gets lowercased and spaces get removed. Therefore, I'd suggest applying this same behavior to the mass subscribe feature. Thanks. -Brian Ryner bryner@uiuc.edu From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Mar 3 04:21:23 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 2 Mar 1999 23:21:23 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] Possible Fix for password lookup bug References: <36DCB058.AC6B1507@uiuc.edu> <36DC7BE7.A91A3991@uiuc.edu> Message-ID: <14044.47299.742348.971101@anthem.cnri.reston.va.us> >>>>> "BR" == Brian Ryner writes: BR> There's a bug that can come up when you mass subscribe users. BR> The script does not lowercase the email addresses when they BR> are mass-subscribed. This causes problems for just about BR> everything, including password lookup, because when you type BR> the email address to go to the options page, it uses a BR> lowercased version of it. Then, since the password is stored BR> with an uppercased version of the address, it can't find it. BR> If users subscribe themselves, their email address gets BR> lowercased and spaces get removed. Therefore, I'd suggest BR> applying this same behavior to the mass subscribe feature. What version of Mailman are you using? The policy is this: the user name part of the email address is case-preserving because RFC 822 says it must be. However for the Web side of the world, email addresses are lower cased. This means if I subscribe BWARSAW@python.org, email will always be delivered to BWARSAW@python.org, but my options will be at .../bwarsaw__at__python.org This has all been verified to work in Mailman 1.0b9. -Barry From lindsey@ncsa.uiuc.edu Wed Mar 3 06:08:41 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Wed, 3 Mar 1999 00:08:41 -0600 (CST) Subject: [Mailman-Developers] Re: [Mailman-Users] Possible Fix for password lookup bug In-Reply-To: <14044.47299.742348.971101@anthem.cnri.reston.va.us> from "Barry A. Warsaw" at Mar 2, 99 11:21:23 pm Message-ID: <199903030608.AAA32535@ferret.ncsa.uiuc.edu> > What version of Mailman are you using? The policy is this: the user > name part of the email address is case-preserving because RFC 822 says > it must be. However for the Web side of the world, email addresses > are lower cased. This means if I subscribe BWARSAW@python.org, email > will always be delivered to BWARSAW@python.org, but my options will be > at .../bwarsaw__at__python.org > > This has all been verified to work in Mailman 1.0b9. I just tested it with a system upgraded from 1.0b8 to 1.0b9, and it doesn't appear to have worked... Here's what I did: o Create a file called /tmp/doit that contains the (fictitious) address MARShall351@mallorn.com o as user mailman, run '$prefix/bin/add_members -n /tmp/doit -w n test2' o Go to the Web page at http://www.mallorn.com/mailman/options/test2/marshall351@mallorn.com and email my password to myself It comes back with a blank page that says "Your password entry has not been found. The list administrator is being notified." I also get an email message back (well, I created a temporary alias that made it non-fictitious for a while) that says: Mailman noticed in .MailUserPassword() that: User: 'marshall351@mallorn.com' List: test2 lacks a password. Please notify the Mailman system manager at this site! If I try to access the options page with a case sensitive address, such as http://www.mallorn.com/mailman/options/test2/MARShall351@mallorn.com the script comes back and says test2: No such member 'MARShall351@mallorn.com' So what the original poster was saying is that email addresses that have uppercase characters in them are not assigned passwords (I've tried it via the Web page and via the commandline script, with and without notification). Another odd thing that I've noticed is that addresses with uppercase characters in them are always set to MIME instead of plain... I really think that the case changes should be thought over again. Even though the local domain might not differentiate between upper and lower case, what would happen if JOEbob@example.com and joebob@example.com both decided to subscribe to a list (assuming that example.com differentiated between the two for purposes of local delivery)? Chris From bryner@uiuc.edu Wed Mar 3 06:23:53 1999 From: bryner@uiuc.edu (Brian Ryner) Date: Wed, 03 Mar 1999 00:23:53 -0600 Subject: [Mailman-Developers] Re: [Mailman-Users] Possible Fix for password lookup bug References: <199903030608.AAA32535@ferret.ncsa.uiuc.edu> Message-ID: <36DCD579.328BE248@uiuc.edu> Christopher Lindsey wrote: > > So what the original poster was saying is that email addresses that > have uppercase characters in them are not assigned passwords (I've > tried it via the Web page and via the commandline script, with and > without notification). Another odd thing that I've noticed is Is it that they aren't assigned passwords, or it can't find the password once it's assigned (because of case conversions elsewhere)? I don't know how to check this. Anyone know? -Brian Ryner bryner@uiuc.edu From lindsey@ncsa.uiuc.edu Wed Mar 3 06:29:24 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Wed, 3 Mar 1999 00:29:24 -0600 (CST) Subject: [Mailman-Developers] Re: [Mailman-Users] Possible Fix for password In-Reply-To: <36DCD579.328BE248@uiuc.edu> from "Brian Ryner" at Mar 3, 99 00:23:53 am Message-ID: <199903030629.AAA32653@ferret.ncsa.uiuc.edu> > Is it that they aren't assigned passwords, or it can't find the password > once it's assigned (because of case conversions elsewhere)? I don't > know how to check this. Anyone know? The password *is* being assigned, but it can't find it later. If I do a strings $prefix/lists/test2/config.db | less and search for the username with uppercase characters, it comes up with a password on the next line... It's functionally the same as not having a password, though. :) Chris P.S. This should probably move to mailman-developers instead of crossing both lists, so we should probably only reply there... From bwarsaw@python.org Wed Mar 3 15:09:59 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Wed, 3 Mar 1999 10:09:59 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] Re: [Mailman-Developers] Re: [Mailman-Users] Possible Fix for password lookup bug References: <14044.47299.742348.971101@anthem.cnri.reston.va.us> <199903030608.AAA32535@ferret.ncsa.uiuc.edu> Message-ID: <14045.20679.885894.920839@anthem.cnri.reston.va.us> >>>>> "CL" == Christopher Lindsey writes: CL> So what the original poster was saying is that email addresses CL> that have uppercase characters in them are not assigned CL> passwords (I've tried it via the Web page and via the CL> commandline script, with and without notification). Another CL> odd thing that I've noticed is that addresses with uppercase CL> characters in them are always set to MIME instead of plain... Verified. Thanks for the recipe, it was crucial to me finding the bug. Unfortunately, I don't have time just now to fix it, but it shouldn't be difficult. The problem is that addrs in the password dictionary are kept case-preserved, but the match is done lower-cased. CL> I really think that the case changes should be thought over CL> again. Even though the local domain might not differentiate CL> between upper and lower case, what would happen if CL> JOEbob@example.com and joebob@example.com both decided to CL> subscribe to a list (assuming that example.com differentiated CL> between the two for purposes of local delivery)? The second one ought to be refused as already subscribed. And the reason all this extra cruft was put in place was because there really are some domains that differentiate based on the case of the username part. Thus in these domains, if I subscribed with BWARSAW@crufty.com, but Mailman insisted on sending the mail to bwarsaw@crufty.com, it would bounce. -Barry From emarshal@logic.net Wed Mar 3 15:45:59 1999 From: emarshal@logic.net (Edward S. Marshall) Date: Wed, 3 Mar 1999 09:45:59 -0600 (CST) Subject: [Mailman-Developers] Re: [Mailman-Users] Re: [Mailman-Developers] Re: [Mailman-Users] Possible Fix for password lookup bug Possible Fix for password lookup bug In-Reply-To: <14045.20679.885894.920839@anthem.cnri.reston.va.us> Message-ID: On Wed, 3 Mar 1999, Barry A. Warsaw wrote: > The second one ought to be refused as already subscribed. I humbly disagree. > And the reason all this extra cruft was put in place was because there > really are some domains that differentiate based on the case of the > username part. Which is explicitly allowed by RFC 822. Why should Mailman care about case of the LHS at -all-? Why not leave it completely untouched? Or at least have an option to leave it alone, and remain RFC-compliant. (Yes, I'm picking nits here, but people tend to discard standards too often these days. RFC 822 might be full of contradictions, but it's quite clear about preserving the case of the LHS of the address.) -- Edward S. Marshall [ What goes up, must come down. ] http://www.logic.net/~emarshal/ [ Ask any system administrator. ] Linux labyrinth 2.2.2-pre2 #2 Sun Feb 14 15:24:09 CST 1999 i586 unknown 9:40am up 16 days, 10:16, 3 users, load average: 0.16, 0.09, 0.03 From tismer@appliedbiometrics.com Wed Mar 3 15:52:54 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Wed, 03 Mar 1999 16:52:54 +0100 Subject: [Mailman-Developers] Install clarification Message-ID: <36DD5AD6.66210472@appliedbiometrics.com> Howdy, after my hazzards with MM0.95, I'm installing MM1.0b9 from scratch on the old Starship. I'm trying to follow the INSTALL notes exactly. After % cd $prefix % chgrp mailman . % chmod a+rx,g+s . I went into the source dir and called ./configure . It complained as so: checking permissions on /home/mailman... configure: error: ***** Installation directory /home/mailman is not configured properly! ***** Permissions should be at least 0775: /home/mailman Can it be that the chmod should better read like "chmod a+rx,g+ws ." ? After doing so, configure was happy. ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home From Harald.Meland@usit.uio.no Wed Mar 3 16:20:09 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 03 Mar 1999 17:20:09 +0100 Subject: [Mailman-Developers] change request: admin password changing References: <36C48867.3E677BDF@lyra.org> Message-ID: [Greg Stein] > 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. I agree. I think that the change of admin password stuff belongs on the "General options" page, and not on _all_ the pages. However, I'm undecided in the matter of making this (site) configurable. Would anyone object if I just put in a hardcoded condition on 'category == "general"' around the call to FormatPasswordStuff() in Mailman.Cgi.admin.FormatConfiguration()? -- Harald From Harald.Meland@usit.uio.no Wed Mar 3 16:36:07 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 03 Mar 1999 17:36:07 +0100 Subject: [Mailman-Developers] Help with run_queue problem? In-Reply-To: Liam Kirsher's message of "Tue, 16 Feb 1999 15:54:48 -0800" References: <36CA0548.2BE4746@numenet.com> Message-ID: [Liam Kirsher] > 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 Sorry for taking a _long_ time to respond, but it appears that your outgoing queue files have been corrupted in some way. I guess Mailman should handle corrupted spool files more elegantly. Is there any wisdom about on what the appropriate action to take in this case would be? Would logging "Corrupted queue file such-and-such removed from queue" (and removing the file from the queue :) suffice? Or should the corrupted queue file be removed from the queue, but stored elsewhere for later investigation of what caused the corruption etc.? Should anyone (list owner, mailman-owner) get email on these incidents? Which of these options, if any, should be (site) configurable? Or should some other "solution" be implemented? While we're on the subject, what about the list config info -- should this be automatically recovered from config.db.last when config.db is corrupt? -- Harald From tismer@appliedbiometrics.com Wed Mar 3 16:37:58 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Wed, 03 Mar 1999 17:37:58 +0100 Subject: [Mailman-Developers] Install clarification References: <36DD5AD6.66210472@appliedbiometrics.com> Message-ID: <36DD6566.19183363@appliedbiometrics.com> Another small problem: newlist has been changed somewhere between 1.0b7 and 1.0b9 in the wrong way, and the change has obviously not been tested! ###before (1.0b7): import sys, os, string import time import getpass import paths # path hacking from Mailman import MailList from Mailman import Utils from Mailman import mm_cfg from Mailman.Crypt import crypt ###After (1.0b9): import sys, os, string import time try: import getpass except ImportError: # we must be in Python 1.5, which didn't have the getpass module from Mailman.pythonlib import getpass import paths # path hacking from Mailman import MailList from Mailman import Utils from Mailman import mm_cfg from Mailman.Crypt import crypt The "import pahs" must go *before* the try..except ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home From bryner@uiuc.edu Wed Mar 3 17:13:00 1999 From: bryner@uiuc.edu (Brian Ryner) Date: Wed, 03 Mar 1999 11:13:00 -0600 Subject: [Mailman-Developers] Re: [Mailman-Users] Re: [Mailman-Developers] Re: [Mailman-Users]Possible Fix for password lookup bug Fix for password lookup bug References: Message-ID: <36DD6D9C.B86B1B44@uiuc.edu> "Edward S. Marshall" wrote: > > On Wed, 3 Mar 1999, Barry A. Warsaw wrote: > > The second one ought to be refused as already subscribed. > > I humbly disagree. > Hm, I'm not so sure about that. Allowing users to subscribe different capitalizations of their address (and hence receive the mail multiple times) seems like it's asking for a lot of mixups with novice users. From mailman-developers@python.org Wed Mar 3 17:33:42 1999 From: mailman-developers@python.org (Harald Meland) Date: 03 Mar 1999 18:33:42 +0100 Subject: [Mailman-Developers] Re: [Mailman-Users] [ANNOUNCE] Mailman 1.0b9 In-Reply-To: Per Starback's message of "02 Mar 1999 00:04:17 +0100" References: <14042.58410.557890.269150@anthem.cnri.reston.va.us> Message-ID: [Per Starback] > Wish list: > > * Add Mail-Followup-To header. (I've done that for myself, but > I would appreciate not having to do it again, as well as I'd like > to see more use of this useful although nonstandard header.) As this (currently) is a non-standard header, I wouldn't feel good about putting explicit support for it into Mailman. However, a more general "Add this header (standard or not) (if it doesn't exist already) to all messages to this list" might be good. But not for 1.0, methinks. > * Possibility for individual list members to say if they want > a Subject line [tag] or not. That would mean that there would have > to be two versions of each message, but I think that would be worth > it as the [tag]/no tag preference is more about the preferences > (and mail situation) of individual list members that about the > preferences of the list itself or its maintainer. I would never > add a tag like that on my lists per default, but if users who want > it could get it explicitly that would be nice. For users it is always good to make _all_ the bells and whistles configurable. However, Mailman has to find a balance between user configurability and how efficient list delivery should be. This means we have to make sure that making something user configurable won't make list delivery unbearably inefficient for any Mailman installation. Once we start going down the road of deciding which options should be made user configurable and which aren't really worth it, it is *very* easy to get lost. There are lots of other good candidates for user configurable options concerning outgoing list messages: Adding a Reply-To: header, including the list footer, including the list header, and of course VERP. The added complexity of Mailman code this would need is also an issue. So, what I'm trying to say, is: Yes, this would be nice to have for some installations -- but don't hold your breath :) > * A line at the Membership Management page where you set default > attributes for new users in the same way that you can change > attributes for the existing users. This more general feature > would be instead of the > > Which delivery mode is the default for new users? > and > When receiving digests, which format is default? > > questions on the Digest-member options page. Yes, this would be nice. I'll try looking into it. > I think I would like to set "hide" by default, If you're talking of changing the Mailman default setting, that would be an incompatible change -- and those suck. Thanks a lot for your suggestions on how can be Mailman improved -- and do keep 'em coming! -- Harald From bryner@uiuc.edu Wed Mar 3 17:36:26 1999 From: bryner@uiuc.edu (Brian Ryner) Date: Wed, 03 Mar 1999 11:36:26 -0600 Subject: [Mailman-Developers] nomail setting not always working Message-ID: <36DD731A.45419CC3@uiuc.edu> Hi- Yesterday I sent a message to a mailing list I'd set up, and got several bounces (as I expected). I have mailman set to disable the users and notify me, which it did. Today I sent another message, and got more bounces from the same people! which means it tried to deliver to them again. The second message I received said "subscription not disabled- user not found" (or something similar). I tried reproducing this on a test list and was unable to. Looking at the bounce messages I do notice a subtle difference between them. These are both for bounces from the same email address: 1st bounce message: ... The original message was received at Tue, 2 Mar 1999 09:52:08 -0600 from localhost [127.0.0.1] ... 2nd bounce message: ... The original message was received at Wed, 3 Mar 1999 10:21:37 -0600 from nobody@localhost [127.0.0.1] ... Note that the first message has no username and the second has nobody@localhost. Does anyone know what would cause this?? Python 1.51, Slackware 3.2. Thanks. -Brian Ryner bryner@uiuc.edu From Harald.Meland@usit.uio.no Wed Mar 3 17:49:04 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 03 Mar 1999 18:49:04 +0100 Subject: [Mailman-Developers] Hi i new in this list and with mailman In-Reply-To: Roger Peņa Escobio's message of "Mon, 1 Mar 1999 19:42:06 -0500" References: <01be6445$7fa4a450$1c7001c4@ntserver.sld.cu> Message-ID: [Roger Peņa Escobio] > Hi to all mailman user and developers :-) Hi! > how i say in the subject i new with mailman, and i like it :-)) but > there are some things unwanted, first of all , the suid in all > subdirs and in the exe files (not the cgi-bin files), Umm, nothing in Mailman is setUID. Mailmans permissions scheme revolves around setGID (to allow non-privileged users to use Mailman, even though this requires some cooperation with the sysadm in many cases). When mailman receives mail (via some alias-file pipe from your local MTA (in most cases)), it checks that the gid of the spawned pipe is running under some compiled in (real) gid, and then setgid()s to it's own (effective) gid to allow Mailman to operate. A similar scheme is used for changes done via the web interface. > the other things is the permisions , i dont understant why 775 for > all subdirs and not only for : logs, locks, lists, data, archives , > the others just 750 except cgi-bin (755) . Probably because using _one_ set of permission for all dirs Works (TM) :) Seriously: You're probably right, and I think Mailman could be set up with more restrictive permissions. This should be fixed, but hasn't really been a top priority as it's not really a bug (and possibly could be a cause of breakage for someone with ... "exotic" configurations that Were Working Before They Upgraded (TM) :). I'd like to address this after 1.0 is out the door. -- Harald From lindsey@ncsa.uiuc.edu Wed Mar 3 17:51:34 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Wed, 3 Mar 1999 11:51:34 -0600 (CST) Subject: [Mailman-Developers] Re: [Mailman-Users] Re: [Mailman-Developers] Re: [Mailman-Users]Possible In-Reply-To: <36DD6D9C.B86B1B44@uiuc.edu> from "Brian Ryner" at Mar 3, 99 11:13:00 am Message-ID: <199903031751.LAA03544@ferret.ncsa.uiuc.edu> > > On Wed, 3 Mar 1999, Barry A. Warsaw wrote: > > > The second one ought to be refused as already subscribed. > > > > I humbly disagree. > > > Hm, I'm not so sure about that. Allowing users to subscribe different > capitalizations of their address (and hence receive the mail multiple > times) seems like it's asking for a lot of mixups with novice users. Yeah, but you can't always protect users against themselves, especially when doing so has the potential to prevent users from signing on to a list altogether. I have seen systems that had the multiple accounts belonging to different people but could only be differentiated by case. I admit that it's not the brightest thing to do, but sites do it because it's allowed by RFC 822. We can't just ignore the RFCs because it's convenient -- that just seems to "Redmondian"... Maybe the right thing to do is offer the administrator a choice on a per list basis. Chris From bryner@uiuc.edu Wed Mar 3 18:18:53 1999 From: bryner@uiuc.edu (Brian Ryner) Date: Wed, 03 Mar 1999 12:18:53 -0600 Subject: [Mailman-Developers] the case issue References: <199903031751.LAA03544@ferret.ncsa.uiuc.edu> Message-ID: <36DD7D0D.68AA59F0@uiuc.edu> (Shortening the subject a lot) :) How about this. If the email address you try to subscribe matches case-insensitively an email that's already subscribed, it tells you so and asks for confirmation. A similar thing could happen when you go into the options page- if there is more than one address that could be it, it gives you a choice to be sure. Christopher Lindsey wrote: > > Yeah, but you can't always protect users against themselves, especially > when doing so has the potential to prevent users from signing on to > a list altogether. I have seen systems that had the multiple accounts > belonging to different people but could only be differentiated by case. > I admit that it's not the brightest thing to do, but sites do it > because it's allowed by RFC 822. We can't just ignore the RFCs because > it's convenient -- that just seems to "Redmondian"... > > Maybe the right thing to do is offer the administrator a choice > on a per list basis. > > Chris From Harald.Meland@usit.uio.no Wed Mar 3 18:55:23 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 03 Mar 1999 19:55:23 +0100 Subject: [Mailman-Developers] bounce processing question and idea for future enhancements... In-Reply-To: Jeff Hahn's message of "Tue, 2 Mar 1999 11:48:26 -0600" References: <00b101be64d4$dfcab240$1e0a5ad1@SINGSING.STREEK.COM> Message-ID: [Jeff Hahn] > Bounce processing question... > > Since some of the big email domains (hotmail, aol, etc.) are known to > "burp" and deny existence of perfectly valid users, I'd like to handle all > returns as bounces and not remove people automatically on the first "user > unknown" message. I assume the way to handle it is to change "REMOVE" to > "BOUNCE" in the lines like the following in bouncer.py > > (regex.compile('.*%s: User unknown.*' % email_regexp), REMOVE), > > Any comments? Any better way to do it? Nope, none apart from the obvious "This is a very sad situation" :( If you're happy with Mailman "disabling" failed addresses (as opposed to removing them), you can tweak the `automatic_bounce_action' list config option accordingly from "Bounce Options". > Idea for future enhancements... > > This is the big one. Does anyone besides me have a desire to see Mailman > support Listserv style "topics"? Where topics are extracted from the > message subject and list messages are sent to a subset of the list that > "subscribes" to that particular topic? I don't know ListServ -- what is the motivation for implementing something like this? Wouldn't a separate mailing list for each "topic" and appropriate crossposting do the same? Should there be topic-specific archives, or should the archive be topic-insensitive? To be frank, this whole idea seems rather hackish to me, though I might feel better about it if you explain _why_ you have a need for it. Of course, if this, for some reason that eludes me at the moment, is a nice feature to have in an MLM, we'd like to have it in Mailman :) -- Harald From gstein@lyra.org Wed Mar 3 19:12:25 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 03 Mar 1999 11:12:25 -0800 Subject: [Mailman-Developers] change request: admin password changing References: <36C48867.3E677BDF@lyra.org> Message-ID: <36DD8999.7E966AAD@lyra.org> Harald Meland wrote: > > [Greg Stein] > > > 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. > > I agree. I think that the change of admin password stuff belongs on > the "General options" page, and not on _all_ the pages. > > However, I'm undecided in the matter of making this (site) > configurable. IMO, making that configurable would simply be insane. Too much configurability is simply confusing to the user. Especially if the configuration brings them no actual benefits. In this case, what admin is going to say "wow. I'd be so much happier if I had that screen on *every* page. I just use it ALL the time." None. > Would anyone object if I just put in a hardcoded condition on > 'category == "general"' around the call to FormatPasswordStuff() in > Mailman.Cgi.admin.FormatConfiguration()? Seems like the simplest solution. If there is a template or something you can change instead, I'd point there. -g -- Greg Stein, http://www.lyra.org/ From petrilli@amber.org Wed Mar 3 19:16:15 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Wed, 3 Mar 1999 14:16:15 -0500 Subject: [Mailman-Developers] bounce processing question and idea for future enhancements... In-Reply-To: ; from Harald Meland on Wed, Mar 03, 1999 at 07:55:23PM +0100 References: <00b101be64d4$dfcab240$1e0a5ad1@SINGSING.STREEK.COM> Message-ID: <19990303141615.29328@amber.org> On Wed, Mar 03, 1999 at 07:55:23PM +0100, Harald Meland wrote: > > This is the big one. Does anyone besides me have a desire to see Mailman > > support Listserv style "topics"? Where topics are extracted from the > > message subject and list messages are sent to a subset of the list that > > "subscribes" to that particular topic? > > I don't know ListServ -- what is the motivation for implementing > something like this? Wouldn't a separate mailing list for each > "topic" and appropriate crossposting do the same? Should there be > topic-specific archives, or should the archive be topic-insensitive? Well, I've run a few dozen LISTSERV installations, and I've never found a use for it, honestly. :-) NOW, it was amazingly valuable back in the days of BITNET (where LISTSERV originated), and the only use I can see for it today is basically this: A company has an "announcement" list, this list is subscribed to by everyone interested, but there might be a couple of "topics": * Stuff of interest to everyone * New doodad announcements * New widget announcements * Celebrations of people being fired who deserved it :-) One might argue that it's cleaner to have a single "announcement" list and multiple "topics," but I'm not sure I've seen this being used anywhere of late. Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright From gstein@lyra.org Wed Mar 3 19:34:20 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 03 Mar 1999 11:34:20 -0800 Subject: [Mailman-Developers] Configurability (was Re: [ANNOUNCE] Mailman 1.0b9) References: <14042.58410.557890.269150@anthem.cnri.reston.va.us> Message-ID: <36DD8EBC.706CD856@lyra.org> Harald Meland wrote: > ... > For users it is always good to make _all_ the bells and whistles > configurable. However, Mailman has to find a balance between user > configurability and how efficient list delivery should be. I strongly disagree with the blanket statement that it is "always good". > This means we have to make sure that making something user > configurable won't make list delivery unbearably inefficient for any >... > The added complexity of Mailman code this would need is also an issue. Inefficiencies in list delivery are only a *small* piece of the problem. If you make something too configurable, then it becomes unapproachable. It is simply not useful any more because there are too many knobs to turn. One of John's big reasons for starting Mailman was to make a clean and simple mailing list manager. Part of this was simply a reaction against the complex Perl code in Majordomo, but John also wanted something easy for mere mortals to run. You really should not keep dropping knobs onto Mailman. Look at the problem with the settings for "who can post to this list". LOTS of people have problems with getting that set up right. The problem? Too many knobs. "What do I set to do X?" is what happens. IMO, your real task is to *reduce* the knobs, not add more. You should figure out how to automatically figure some out, or how to combine them, or simply drop them for lack of utility. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Wed Mar 3 19:39:32 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 03 Mar 1999 11:39:32 -0800 Subject: [Mailman-Developers] Re: Possible Fix for password lookup bug References: Message-ID: <36DD8FF4.454E5F4B@lyra.org> Hey Logic, Edward S. Marshall wrote: > ... > > And the reason all this extra cruft was put in place was because there > > really are some domains that differentiate based on the case of the > > username part. > > Which is explicitly allowed by RFC 822. Why should Mailman care about case > of the LHS at -all-? Why not leave it completely untouched? Or at least > have an option to leave it alone, and remain RFC-compliant. > > (Yes, I'm picking nits here, but people tend to discard standards too > often these days. RFC 822 might be full of contradictions, but it's quite > clear about preserving the case of the LHS of the address.) I believe you misunderstand. When Mailman *delivers* mail, it uses the original case of the address that was entered. It goes to great lengths to preserve that case. Within web- and email-based operation of a user's settings, however, it is performed case-insensitively. This occurs outside of mail delivery and the SMTP protocol, so it is a "legal" design choice. If you'd like, you can argue the design choice, but I'll warn you now to not try it :-). Cheers, -g -- Greg Stein, http://www.lyra.org/ From John@list.org Wed Mar 3 19:42:24 1999 From: John@list.org (John Viega) Date: Wed, 3 Mar 1999 11:42:24 -0800 Subject: [Mailman-Developers] Configurability (was Re: [ANNOUNCE] Mailman 1.0b9) In-Reply-To: <36DD8EBC.706CD856@lyra.org>; from Greg Stein on Wed, Mar 03, 1999 at 11:34:20AM -0800 References: <14042.58410.557890.269150@anthem.cnri.reston.va.us> <36DD8EBC.706CD856@lyra.org> Message-ID: <19990303114224.G8165@viega.org> Well, my philosophy on the matter is to keep the common tasks easy and the expert tasks possible. So I think there should be a basic section, and an advanced section, where there'd be some overlap. For example, in the basic section, you could just say, "give me a moderated list", but the fine grained control is available at the expert level. I don't really mind catering to everyone as long as we focus on catering to the novice, since that's most people who will be administrating or using a list... John On Wed, Mar 03, 1999 at 11:34:20AM -0800, Greg Stein wrote: > Harald Meland wrote: > > ... > > For users it is always good to make _all_ the bells and whistles > > configurable. However, Mailman has to find a balance between user > > configurability and how efficient list delivery should be. > > I strongly disagree with the blanket statement that it is "always good". > > > This means we have to make sure that making something user > > configurable won't make list delivery unbearably inefficient for any > >... > > The added complexity of Mailman code this would need is also an issue. > > Inefficiencies in list delivery are only a *small* piece of the problem. > > If you make something too configurable, then it becomes unapproachable. > It is simply not useful any more because there are too many knobs to > turn. > > One of John's big reasons for starting Mailman was to make a clean and > simple mailing list manager. Part of this was simply a reaction against > the complex Perl code in Majordomo, but John also wanted something easy > for mere mortals to run. > > You really should not keep dropping knobs onto Mailman. Look at the > problem with the settings for "who can post to this list". LOTS of > people have problems with getting that set up right. The problem? Too > many knobs. "What do I set to do X?" is what happens. > > IMO, your real task is to *reduce* the knobs, not add more. You should > figure out how to automatically figure some out, or how to combine them, > or simply drop them for lack of utility. > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From gstein@lyra.org Wed Mar 3 19:50:33 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 03 Mar 1999 11:50:33 -0800 Subject: [Mailman-Developers] Configurability (was Re: [ANNOUNCE] Mailman 1.0b9) References: <14042.58410.557890.269150@anthem.cnri.reston.va.us> <36DD8EBC.706CD856@lyra.org> <19990303114224.G8165@viega.org> Message-ID: <36DD9289.2DF47F24@lyra.org> John Viega wrote: > > Well, my philosophy on the matter is to keep the common tasks easy and > the expert tasks possible. So I think there should be a basic > section, and an advanced section, where there'd be some overlap. For > example, in the basic section, you could just say, "give me a > moderated list", but the fine grained control is available at the > expert level. I don't really mind catering to everyone as long as we > focus on catering to the novice, since that's most people who will be > administrating or using a list... This is good only to a point. Many people still feel the need to review all the options to ensure they have it set properly. Pushing stuff off to an "Advanced" area requires explicit doc to ensure that people can comfortably ignore those options. For example, you couldn't just shift some of the current admin options to a new screen labeled "Advanced." People will just walk right down the list of screens and hit the Advanced and they would effectively have all those knobs available. Anyways, this seems to be getting more into UI design, than breadth of configuration. I still believe in my original point of reducing the number of knobs, not blindly adding to them under some notion that it helps the user. Your refinement works for me as long as the Advanced stuff isn't too readily available (thereby rendering them "not available" for most intents and purposes). Cheers, -g -- Greg Stein, http://www.lyra.org/ From lindsey@ncsa.uiuc.edu Wed Mar 3 20:00:37 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Wed, 3 Mar 1999 14:00:37 -0600 (CST) Subject: [Mailman-Developers] Re: Possible Fix for password lookup bug In-Reply-To: <36DD8FF4.454E5F4B@lyra.org> from "Greg Stein" at Mar 3, 99 11:39:32 am Message-ID: <199903032000.OAA04401@ferret.ncsa.uiuc.edu> > I believe you misunderstand. > > When Mailman *delivers* mail, it uses the original case of the address > that was entered. It goes to great lengths to preserve that case. > > Within web- and email-based operation of a user's settings, however, it > is performed case-insensitively. This occurs outside of mail delivery > and the SMTP protocol, so it is a "legal" design choice. > > If you'd like, you can argue the design choice, but I'll warn you now to > not try it :-). Can Mailman at least be changed so that the membership listing reflects the original case? Even dumping the list membership with $prefix/bin/list_members converts everything to lowercase, making it useless if the list is moving to a site that runs something like majordomo. Chris From gstein@lyra.org Wed Mar 3 20:02:44 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 03 Mar 1999 12:02:44 -0800 Subject: [Mailman-Developers] Re: Possible Fix for password lookup bug References: <199903032000.OAA04401@ferret.ncsa.uiuc.edu> Message-ID: <36DD9564.3CA9DDF9@lyra.org> Christopher Lindsey wrote: >... > Can Mailman at least be changed so that the membership listing reflects > the original case? Even dumping the list membership with > $prefix/bin/list_members converts everything to lowercase, making > it useless if the list is moving to a site that runs something > like majordomo. I'm not the right "To:" recipient here... :-) I'm just a poor sucker who uses it rather than somebody who can truly fix problems :-) Check out the --preserve (-p) switch to list_members. It case-preserves the output. Cheers, -g p.s. seems like somebody else has a time machine around here... Barry, have you been borrowing Guido's again? :-) -- Greg Stein, http://www.lyra.org/ From roy@endeavor.med.nyu.edu Wed Mar 3 20:23:56 1999 From: roy@endeavor.med.nyu.edu (Roy Smith) Date: Wed, 03 Mar 1999 15:23:56 -0500 Subject: [Mailman-Developers] Configurability (was Re: [ANNOUNCE] Mailman 1.0b9) In-Reply-To: <36DD8EBC.706CD856@lyra.org> Message-ID: <1637799.3129463436@qwerky.med.nyu.edu> I agree 300%. Once something has a zillion different options, it just becomes too complicated to get your head around and understand. Often, it's not obvious which options are trivial (i.e. set the color the text in the title bar) and which are important (i.e. specify the hostname of the mail server). Also, the more options you have, the more unexpected combinations there are. "I never thought anybody would be stupid enough to set their text color to red, their background color to red, and their highlight color to red, all at the same time!" It also makes it harder for help desk people to provide useful help. Anybody who has ever done help desk duty knows how frustrating it is to talk to somebody on the phone and tell them to "click the xyz button in the upper left hand corner of the window" only to have the user say there is no such button, and the problem turns out that they've simply reconfigured their client so much that the button is now somewhere else. --On Wed, Mar 3, 1999 11:34 AM -0800 Greg Stein wrote: > If you make something too configurable, then it becomes unapproachable. > It is simply not useful any more because there are too many knobs to > turn. Roy Smith New York University School of Medicine 550 First Avenue, New York, NY 10016 From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Mar 3 20:33:21 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 3 Mar 1999 15:33:21 -0500 (EST) Subject: [Mailman-Developers] Configurability (was Re: [ANNOUNCE] Mailman 1.0b9) References: <14042.58410.557890.269150@anthem.cnri.reston.va.us> <36DD8EBC.706CD856@lyra.org> <19990303114224.G8165@viega.org> <36DD9289.2DF47F24@lyra.org> Message-ID: <14045.40081.721646.988552@anthem.cnri.reston.va.us> >>>>> "GS" == Greg Stein writes: GS> Anyways, this seems to be getting more into UI design, than GS> breadth of configuration. Yeah, there's really only so much you can do with Web forms anyway. Gawd they suck for UI. GS> I still believe in my original point of reducing the number of GS> knobs, not blindly adding to them under some notion that it GS> helps the user. Your refinement works for me as long as the GS> Advanced stuff isn't too readily available (thereby rendering GS> them "not available" for most intents and purposes). I agree (especially for the mythical 1.0 :-). Besides, I claim that the Python code for Mailman is vastly more approachable than the Perl code for Majordomo. Individual site admins are always free to hack the code. Our job is not necessarily to support every wish or request under the sun. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Mar 3 20:35:59 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 3 Mar 1999 15:35:59 -0500 (EST) Subject: [Mailman-Developers] Re: Possible Fix for password lookup bug References: <199903032000.OAA04401@ferret.ncsa.uiuc.edu> <36DD9564.3CA9DDF9@lyra.org> Message-ID: <14045.40239.564186.680304@anthem.cnri.reston.va.us> >>>>> "GS" == Greg Stein writes: GS> p.s. seems like somebody else has a time machine around GS> here... Barry, have you been borrowing Guido's again? :-) Hey, he's on vacation. What he doesn't know won't hurt me... um, him. -Barry From lindsey@ncsa.uiuc.edu Wed Mar 3 21:15:25 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Wed, 3 Mar 1999 15:15:25 -0600 (CST) Subject: [Mailman-Developers] Re: Possible Fix for password lookup bug In-Reply-To: <36DD9564.3CA9DDF9@lyra.org> from "Greg Stein" at Mar 3, 99 12:02:44 pm Message-ID: <199903032115.PAA04843@ferret.ncsa.uiuc.edu> > I'm not the right "To:" recipient here... :-) I'm just a poor sucker > who uses it rather than somebody who can truly fix problems :-) > > Check out the --preserve (-p) switch to list_members. It case-preserves > the output. Oops. Sorry. I'm really embarassed. I got too caught up in the moment... It *would* be nice to have the Web page display the subscribers in a case sensitive format, just for continuity's sake. But it's a lot less minor now that I realize my gaffe with regard to list_members. :) Here's another feature request, though... From the membership page it would be very nice to be able to click on a subscriber's name, then have it take me to a page for that user's specific settings. Options would include generation of a new password, changing the password to one chosen by the admin, renaming this address to a new address (such as when a user switches ISPs), etc. Chris From neves@inf.puc-rio.br Wed Mar 3 23:06:41 1999 From: neves@inf.puc-rio.br (Paulo Eduardo Neves) Date: Wed, 03 Mar 1999 20:06:41 -0300 Subject: [Mailman-Developers] Mailman in SunWorld online Message-ID: <36DDC081.95B3C697@inf.puc-rio.br> Take a look at: http://www.sunworld.com/swol-03-1999/swol-03-mailtools.html?0302a -- Paulo Eduardo Neves PUC-Rio de Janeiro Pager: Central: 292-4499 cod. 213 99 64 ou use a URL: http://www.learn.fplf.org.br/neves/mensagempager.html From claw@kanga.nu Thu Mar 4 04:15:22 1999 From: claw@kanga.nu (J C Lawrence) Date: Wed, 03 Mar 1999 20:15:22 -0800 Subject: [Mailman-Developers] Re: [Mailman-Users] Re: [Mailman-Developers] Re: [Mailman-Users]Possible Fix for password lookup bug Fix for password lookup bug In-Reply-To: Message from Brian Ryner of "Wed, 03 Mar 1999 11:13:00 CST." <36DD6D9C.B86B1B44@uiuc.edu> Message-ID: On Wed, 03 Mar 1999 11:13:00 -0600 Brian Ryner wrote: > Hm, I'm not so sure about that. Allowing users to subscribe > different capitalizations of their address (and hence receive the > mail multiple times) seems like it's asking for a lot of mixups with > novice users. Do two things: 1) Send a warning notice to the list owner. 2) Send a notice of a possible duplicate to the subscriber. For #2 don't quote the other address that is being subscribed, just state the fact of. This would be on the confirmation message or on the ack message for unconfirmed subscriptions. -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From claw@kanga.nu Thu Mar 4 05:12:51 1999 From: claw@kanga.nu (J C Lawrence) Date: Wed, 03 Mar 1999 21:12:51 -0800 Subject: [Mailman-Developers] Re: [Mailman-Users] [ANNOUNCE] Mailman 1.0b9 In-Reply-To: Message from Harald Meland of "03 Mar 1999 18:33:42 +0100." Message-ID: On 03 Mar 1999 18:33:42 +0100 Harald Meland wrote: > As this (currently) is a non-standard header, I wouldn't feel good > about putting explicit support for it into Mailman. However, a more > general "Add this header (standard or not) (if it doesn't exist > already) to all messages to this list" might be good. But not for > 1.0, methinks. This has my vote, as well as a set of pages to configure MailMan's defaults for all other lists. *THAT* would be incredibly useful especially for corporate sites (I'm trying to roll out MailMan at VA Research). Note: The default business should work as follows: All list config are either "default" or deviations from default. Ergo, if a list is configured and MailMan's defaults are later changed, the following would happen: -- if the value is the same as the prior default, change the value to the new default. -- if the value was changed from the prior default, leave it at its current setting. > There are lots of other good candidates for user configurable > options concerning outgoing list messages: Adding a Reply-To: > header, including the list footer, including the list header, and of > course VERP. I'd love an option to support only MIME digests and to turn off support for RFC (forget number) digests. I'd also love an option to set a Reply-To specific to digests and different from the list config for individual messages (I set it to a Please.Do.Not.Reply.to.Digests.Burst.Instead@whereever). Version 1.x stuff. -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From claw@kanga.nu Thu Mar 4 05:18:26 1999 From: claw@kanga.nu (J C Lawrence) Date: Wed, 03 Mar 1999 21:18:26 -0800 Subject: [Mailman-Developers] bounce processing question and idea for future enhancements... In-Reply-To: Message from Harald Meland of "03 Mar 1999 19:55:23 +0100." Message-ID: On 03 Mar 1999 19:55:23 +0100 Harald Meland wrote: > [Jeff Hahn] >> This is the big one. Does anyone besides me have a desire to see >> Mailman support Listserv style "topics"? Where topics are >> extracted from the message subject and list messages are sent to a >> subset of the list that "subscribes" to that particular topic? > I don't know ListServ -- what is the motivation for implementing > something like this? Wouldn't a separate mailing list for each > "topic" and appropriate crossposting do the same? Should there be > topic-specific archives, or should the archive be topic-insensitive? > To be frank, this whole idea seems rather hackish to me, though I > might feel better about it if you explain _why_ you have a need for > it. A long long time ago in a computing universe utterly unrelated to Linux (or MS for that matter) I used list software which allowed users to define patterns (lists of keywords and simple wildcards) with the result that they would only be sent messages which matched the defined expressions __plus__ (and this was the cool bit) N messages in that thread after a match (where N was of course configurable. Further useful intelligence had the list send M further posts of threads if the subscriber posted to that thread (overriding pattern matching). This allowed filtering at the server end, and was incredibly useful for high traffic lists (err, "forums" in that context). -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From claw@kanga.nu Thu Mar 4 05:26:50 1999 From: claw@kanga.nu (J C Lawrence) Date: Wed, 03 Mar 1999 21:26:50 -0800 Subject: [Mailman-Developers] Configurability (was Re: [ANNOUNCE] Mailman 1.0b9) In-Reply-To: Message from Greg Stein of "Wed, 03 Mar 1999 11:34:20 PST." <36DD8EBC.706CD856@lyra.org> Message-ID: On Wed, 03 Mar 1999 11:34:20 -0800 Greg Stein wrote: > You really should not keep dropping knobs onto Mailman. Look at the > problem with the settings for "who can post to this list". LOTS of > people have problems with getting that set up right. The problem? > Too many knobs. "What do I set to do X?" is what happens. The fault there is not in the feature set. The fault is in the design of the feature set. I've been there. You can do it in simple ways (simpler than the current method) that communicate clearly and are obvious to neophyte users: Who can subscribe? (Anyone, moderator approved) Who can post? (Anyone, only subscribers, only nominated subscribers) What happens to unsubscribed posts? (silently deleted, held for approval, bounced beck to sender with defined message). You then need to make posting rights (ie bypassing moderation) an attribute of the user account, modifiable only by the list owner (the current list of approved addresses, which is not maintained against accounts or unsubscriptions sucks). > IMO, your real task is to *reduce* the knobs, not add more. You > should figure out how to automatically figure some out, or how to > combine them, or simply drop them for lack of utility. Quite. Presentation is also key. -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From claw@kanga.nu Thu Mar 4 05:34:30 1999 From: claw@kanga.nu (J C Lawrence) Date: Wed, 03 Mar 1999 21:34:30 -0800 Subject: [Mailman-Developers] Configurability (was Re: [ANNOUNCE] Mailman 1.0b9) In-Reply-To: Message from John Viega of "Wed, 03 Mar 1999 11:42:24 PST." <19990303114224.G8165@viega.org> Message-ID: On Wed, 3 Mar 1999 11:42:24 -0800 John Viega wrote: > Well, my philosophy on the matter is to keep the common tasks easy > and the expert tasks possible. So I think there should be a basic > section, and an advanced section, where there'd be some overlap. > For example, in the basic section, you could just say, "give me a > moderated list", but the fine grained control is available at the > expert level. I don't really mind catering to everyone as long as > we focus on catering to the novice, since that's most people who > will be administrating or using a list... Specifically: VA Research has a need for a list server that presents only the following options upon list creation (web preferred): Name of list. Reply-To option. Open/closed subscription option. Subscribers only from specified domain text field. Bounces go to MailMan owner or list owner option. Support digests option. The actual need is for someone in HR, a computer illiterate someone who just understands typewriters, to be able to create a list on demand which central IS can then do the background management for (bounces etc) but is otherwise default configured and obvious. They *really* like MailMan. They just need a severely dumbed down interface to list creation for it. -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From jeffh@streek.com Thu Mar 4 05:56:13 1999 From: jeffh@streek.com (Jeff Hahn) Date: Wed, 3 Mar 1999 23:56:13 -0600 Subject: [Mailman-Developers] TOPICS (was bounce processing question and idea for future enhancements...) In-Reply-To: Message-ID: <000001be6603$b5d19960$1e0a5ad1@SINGSING.STREEK.COM> Thanks to Harald and Chris for their input... Listserv topics work like this: Messages sent to the list include one or more keywords (topics) in the subject. There is a defined set of topics for the list. Subscribers can choose to receive messages for individual topics. When the MLM receives a message, it extracts the topics from the subject. To deliver a message, the MLM intersects the set of topics in the message with the set of topics that a given subscriber has chosen (to use set terminology). If the intersection is non-empty, that subscriber gets the message, otherwise not. there is usually an "ADMIN" topic that is sent to ALL listmember and has restricted posting. Subscribers can choose whether or not to "subscribe to New topics automatically", so that when topics are added, the member list can be updated. Messages without a valid topic are optionally rejected. Here is my actually situation: I run a set of mailing lists for mostly inexperienced users. There is a great deal of overlap amongst the lists. The lists are very active. Up to 250,000 deliveries per week to about 500 total subscribers. 100 or more messages per day to members of all the lists are not uncommon. These lists all concern the Bloodhound dog breed. There are people interested in showing bloodhounds. There are people interested in using bloodhounds to trail people. There are people interested in breeding bloodhounds. There are people interested in rescuing bloodhounds from animal shelters. there is a certain amount of "chat" going on as well. Many people are interested in most of the topics, but usually have one or two that they're not interested in. The show people may not be interested in trailing. The breeders aren't interested in rescue. The rescue people aren't interested in showing. There is a group of people not interested in the chat. You get the idea. There are currently 4 lists and given the experience level of most of the users, admin is a nightmare. People send message to the wrong list. They unsubscribe from the wrong list. They can't figure out why they're still getting individual messages when they've set one of the lists to digest. When they've got something they think is really important, they send it to all 4 lists, "just to make sure" and 85% of the people get 4 copies of the message. There is enough "political turmoil" that certain people really don't want to receive certain topics. I'd be happy if the digests and archives were all inclusive (all topics). Topics would allow just one list to admin, one set of bounces to deal with, one "I want to get the digest", etc. This would give my subscribers a "finer granularity" in controlling the content they wish to receive, without making me administer a dozen lists. I've move a number of my "less difficult" lists away from procmail/smartlist to Mailman and am very happy. But the headaches of dealing with this group of lists is what sent me on the search for a new MLM. I've tried to approach this problem from a number of different angles and this idea is the only one that seems promising. I'm open to suggestions! If anyone has a less complex way to deal with this I'd love it. -Jeff From tismer@appliedbiometrics.com Thu Mar 4 14:05:12 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Thu, 04 Mar 1999 15:05:12 +0100 Subject: [Mailman-Developers] Setup prob: abs/rel CGI url Message-ID: <36DE9318.59C0C8D8@appliedbiometrics.com> Hi Mailman developers, I've set up Mailman 1.0b9 for starship.skyport.net exactly as the INSTALL file said. It is working so far, with one exception: When I try to use the admin page for my test list, I first get the password dialog, as usual. After entering the password, Mailman complains that the list "mailman" is nonexistent. Reason: The CGI of the password dialog contains a relative CGI URL: test Administrative Authentication which causes the URL to pile up to http://starship.skyport.net/mailman/admin/mailman/admin/test and leads to the message that a list "mailman" indeed does not exist. :-) I think I have checked everything against the 1.0b7 installation on python.net and couldnot find any difference whcih mght cause this. The only real difference is that skyport.net still runs an early Python 1.5 version. Please help, I cannot find the bug. Can it be due to Python 1.5 ? cheers - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home From tismer@appliedbiometrics.com Thu Mar 4 14:46:41 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Thu, 04 Mar 1999 15:46:41 +0100 Subject: [Mailman-Developers] MM1.0b9 Bug! (was: Setup prob: abs/rel CGI url) References: <36DE9318.59C0C8D8@appliedbiometrics.com> Message-ID: <36DE9CD1.60544B41@appliedbiometrics.com> Hi Barry et al, I found it - Mailman 1.0b9 has a bug in admin.py . Line 121 ff: if not is_auth: defaulturi = 'mailman/admin%s/%s' % (mm_cfg.CGIEXT, list_name) print "Content-type: text/html\n\n" text = Utils.maketext( 'admlogin.txt', {"listname": list_name, "path" : os.environ.get("REQUEST_URI", defaulturi), "message" : message, }) print text return defaulturi is *wrong*, it needs a slash in front. How comes that nobody complained yet? This means that no user has used the admin pages since he upgraded to 1.0b9 !?! ciao - chris Christian Tismer wrote: > > Hi Mailman developers, > > I've set up Mailman 1.0b9 for starship.skyport.net exactly > as the INSTALL file said. It is working so far, with one exception: > > When I try to use the admin page for my test list, I first get > the password dialog, as usual. > After entering the password, Mailman complains that the list > "mailman" is nonexistent. > Reason: > The CGI of the password dialog contains a relative CGI URL: > > > test Administrative Authentication > ACTION="mailman/admin/test"> > > which causes the URL to pile up to > http://starship.skyport.net/mailman/admin/mailman/admin/test > > and leads to the message that a list "mailman" indeed > does not exist. :-) > > I think I have checked everything against the 1.0b7 installation > on python.net and couldnot find any difference whcih mght cause > this. > The only real difference is that skyport.net still runs an early > Python 1.5 version. > > Please help, I cannot find the bug. Can it be due to Python 1.5 ? > > cheers - chris > > -- > Christian Tismer :^) > Applied Biometrics GmbH : Have a break! Take a ride on Python's > Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net > 10553 Berlin : PGP key -> http://wwwkeys.pgp.net > PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF > we're tired of banana software - shipped green, ripens at home > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home From Harald.Meland@usit.uio.no Thu Mar 4 17:25:56 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 04 Mar 1999 18:25:56 +0100 Subject: [Mailman-Developers] Configurability (was Re: [ANNOUNCE] Mailman 1.0b9) In-Reply-To: Greg Stein's message of "Wed, 03 Mar 1999 11:34:20 -0800" References: <14042.58410.557890.269150@anthem.cnri.reston.va.us> <36DD8EBC.706CD856@lyra.org> Message-ID: [Greg Stein] > Harald Meland wrote: > > ... > > For users it is always good to make _all_ the bells and whistles > > configurable. However, Mailman has to find a balance between user > > configurability and how efficient list delivery should be. > > I strongly disagree with the blanket statement that it is "always good". Sorry, I phrased that rather badly -- what I meant to propagate, was that there's always _some_ user that wants more configurability. If Mailman should cater to any and all of these wishes, it would be a) inefficient and b) (as you point out) a terrible mess. Sorry about the confusion. > You really should not keep dropping knobs onto Mailman. ... unless there is a real need for them, I presume? > Look at the problem with the settings for "who can post to this > list". LOTS of people have problems with getting that set up > right. The problem? Too many knobs. Well, the "too many knobs" issue of "who can post" is (at least in part) caused by the "rather finegrained control" many list admins want over who can post. So, the problem is not merely to reduce the number of buttons, but to do so while _keeping needed functionality_. -- Harald From Harald.Meland@usit.uio.no Thu Mar 4 18:08:34 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 04 Mar 1999 19:08:34 +0100 Subject: [Mailman-Developers] TOPICS (was bounce processing question and idea for future enhancements...) In-Reply-To: Jeff Hahn's message of "Wed, 3 Mar 1999 23:56:13 -0600" References: <000001be6603$b5d19960$1e0a5ad1@SINGSING.STREEK.COM> Message-ID: [Jeff Hahn] > Listserv topics work like this: > > Messages sent to the list include one or more keywords (topics) in the > subject. There is a defined set of topics for the list. Subscribers can > choose to receive messages for individual topics. > > When the MLM receives a message, it extracts the topics from the subject. > To deliver a message, the MLM intersects the set of topics in the message > with the set of topics that a given subscriber has chosen (to use set > terminology). If the intersection is non-empty, that subscriber gets the > message, otherwise not. > > there is usually an "ADMIN" topic that is sent to ALL listmember and has > restricted posting. Subscribers can choose whether or not to "subscribe to > New topics automatically", so that when topics are added, the member list > can be updated. > > Messages without a valid topic are optionally rejected. My feelings on this are rather mixed: While I can see the use something like this would have when your users are inexperienced, I'm still not sure that I would be able to tell it apart from some featuritis-infected hack :) Anyhow, I guess that implementing this would be a lot easier (and cleaner) if every list member had some "user objects" -- and that is planned for after 1.0. So I guess we'll think about it all until we have the infrastructure to implement it on top of in place. -- Harald From Harald.Meland@usit.uio.no Thu Mar 4 18:21:19 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 04 Mar 1999 19:21:19 +0100 Subject: [Mailman-Developers] MM1.0b9 Bug! (was: Setup prob: abs/rel CGI url) In-Reply-To: Christian Tismer's message of "Thu, 04 Mar 1999 15:46:41 +0100" References: <36DE9318.59C0C8D8@appliedbiometrics.com> <36DE9CD1.60544B41@appliedbiometrics.com> Message-ID: [Christian Tismer] > Hi Barry et al, > > I found it - Mailman 1.0b9 has a bug in admin.py . Which was fixed _days_ ago in CVS :-) > defaulturi = 'mailman/admin%s/%s' % (mm_cfg.CGIEXT, [...] > "path" : os.environ.get("REQUEST_URI", defaulturi), [...] > defaulturi is *wrong*, it needs a slash in front. > > How comes that nobody complained yet? If your web server provides CGI scripts with an REQUEST_URI environment variable, the fallback value of `defaulturi' won't be used. This has been further refined in the current CVS version -- first try REQUEST_URI (which isn't part of the CGI/1.1 spec), then try concatenation of SCRIPT_NAME and PATH_INFO (both of which _are_ part of CGI/1.1), then fall back on the (corrected) defaulturi. -- Harald From tismer@appliedbiometrics.com Thu Mar 4 18:40:13 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Thu, 04 Mar 1999 19:40:13 +0100 Subject: [Mailman-Developers] MM1.0b9 Bug! (was: Setup prob: abs/rel CGI url) References: <36DE9318.59C0C8D8@appliedbiometrics.com> <36DE9CD1.60544B41@appliedbiometrics.com> Message-ID: <36DED38D.34DE263F@appliedbiometrics.com> Harald Meland wrote: > > [Christian Tismer] > > > Hi Barry et al, > > > > I found it - Mailman 1.0b9 has a bug in admin.py . > > Which was fixed _days_ ago in CVS :-) That's great. An average user will step into this trap, since 1.0b9 is the current version. If one always has to check CVS, it makes no sense to publish the zip file at all. I have to say: 10.b9 was published without proper testing. ... > > How comes that nobody complained yet? > > If your web server provides CGI scripts with an REQUEST_URI > environment variable, the fallback value of `defaulturi' won't be > used. I see. I was just hit since my Apache isn't the latest version. Anyway, the "/mailman/anything" strings are a little spread around in the sources. In my opinion, it would be safer to keep them in a central place (Defaults.py maybe) and just use references. ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home From Harald.Meland@usit.uio.no Thu Mar 4 22:49:27 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 04 Mar 1999 23:49:27 +0100 Subject: [Mailman-Developers] Install clarification In-Reply-To: Christian Tismer's message of "Wed, 03 Mar 1999 16:52:54 +0100" References: <36DD5AD6.66210472@appliedbiometrics.com> Message-ID: [Christian Tismer] > Can it be that the chmod should better read like > "chmod a+rx,g+ws ." ? It can, indeed. Fixed and checked in. > newlist has been changed somewhere between 1.0b7 and 1.0b9 > in the wrong way, and the change has obviously not been > tested! [...] > The "import paths" must go *before* the try..except True -- fixed and checked in. Thanks a lot for the feedback! -- Harald From neves@inf.puc-rio.br Fri Mar 5 01:30:45 1999 From: neves@inf.puc-rio.br (Paulo Eduardo Neves) Date: Thu, 04 Mar 1999 22:30:45 -0300 Subject: [Mailman-Developers] Re: TOPICS References: <000001be6603$b5d19960$1e0a5ad1@SINGSING.STREEK.COM> Message-ID: <36DF33C5.48788862@inf.puc-rio.br> Harald Meland wrote: > Anyhow, I guess that implementing this would be a lot easier (and > cleaner) if every list member had some "user objects" -- and that is > planned for after 1.0. So I guess we'll think about it all until we > have the infrastructure to implement it on top of in place. I've read in the TO-DO list about User profiles, is it the same of user object? Could you explain the idea behind it? I believe it would solve well a problem I have. I have an announcement list where I send messages about a lot of topics. Not all topics are of interest of all subscribers (i.e. Joe doesn't want to know about events in other state). It looks like user profiles (or Topics) would solve this problem. regards, -- Paulo Eduardo Neves PUC-Rio de Janeiro Pager: Central: 292-4499 cod. 213 99 64 ou use a URL: http://www.learn.fplf.org.br/neves/mensagempager.html From paz@apriori.net Fri Mar 5 02:31:55 1999 From: paz@apriori.net (paz) Date: Thu, 4 Mar 1999 21:31:55 -0500 (EST) Subject: [Mailman-Developers] Does anyone else see these? Message-ID: I've gotten two admin messages to mailman-owner from a mailman list I run on apriori.net (Hummers - a humor list). (begin included text) =================================== Received: from gw.apriori.net (localhost.apriori.net [127.0.0.1]) by apriori.net (8.8.8/8.8.8) with ESMTP id CAA29989 for ; Thu, 4 Mar 1999 02:08:34 -0500 (EST) (envelope-from mailman-owner@apriori.net) Received: from gw.apriori.net (localhost.apriori.net [127.0.0.1]) by apriori.net (8.8.8/8.8.8) with ESMTP id CAA29979 for ; Thu, 4 Mar 1999 02:08:30 -0500 (EST) (envelope-from mailman-owner@apriori.net) Date: Thu, 4 Mar 1999 02:08:30 -0500 (EST) Message-Id: <199903040708.CAA29979@apriori.net> From: mailman-owner@apriori.net Subject: Hummers member redscares@spamcom.net bouncing - NOT disabled To: hummers-admin@apriori.net Errors-To: mailman-owner@apriori.net MIME-version: 1.0 Content-type: multipart/mixed; boundary="192.168.51.99.1.29976.920531310.496.13704" X-Mailman-Version: 1.0b8 Precedence: bulk List-Id: Humor email list. Parts/attachments: 1 Shown 16 lines Text 2 Shown 61 lines Text ---------------------------------------- Content-type: text/plain; charset=us-ascii This is a Mailman mailing list bounce action notice: List: Hummers Member: redscares@spamcom.net Action: Subscription not disabled. Reason: Excessive or fatal bounces. BUT: User not found. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman-owner@apriori.net. [ Part 2: "Attached Text" ] This is a MIME-encapsulated message --CAA24772.920531258/camel8.mindspring.com The original message was received at Thu, 4 Mar 1999 02:07:37 -0500 (EST) from mx10.mindspring.com [207.69.200.126] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- 550 ... Host unknown (Name server: spamcom.net: host not found) --CAA24772.920531258/camel8.mindspring.com Content-Type: message/delivery-status Reporting-MTA: dns; camel8.mindspring.com Received-From-MTA: DNS; mx10.mindspring.com Arrival-Date: Thu, 4 Mar 1999 02:07:37 -0500 (EST) Final-Recipient: RFC822; redscares@spamcom.net Action: failed Status: 5.1.2 Remote-MTA: DNS; spamcom.net Last-Attempt-Date: Thu, 4 Mar 1999 02:07:38 -0500 (EST) --CAA24772.920531258/camel8.mindspring.com Content-Type: text/rfc822-headers Return-Path: Received: from mx10.mindspring.com (mx10.mindspring.com [207.69.200.126]) by camel8.mindspring.com (8.8.5/8.8.5) with SMTP id CAA01606 for ; Thu, 4 Mar 1999 02:07:37 -0500 (EST) From: hummers-admin@apriori.net X-MindSpring-Loop: t-eaton@mindspring.com Received: from apriori.net ([209.192.153.107]) by mx10.mindspring.com (Mindspring Mail Service) with ESMTP id rdsc9m.i37.37kbi3u for ; Thu, 4 Mar 1999 02:07:34 -0500 (EST) Received: from gw.apriori.net (localhost.apriori.net [127.0.0.1]) by apriori.net (8.8.8/8.8.8) with ESMTP id CAA29959; Thu, 4 Mar 1999 02:08:03 -0500 (EST) (envelope-from hummers-admin@apriori.net) Received: from localhost (jokes-in@localhost) by apriori.net (8.8.8/8.8.8) with SMTP id CAA29933 for ; Thu, 4 Mar 1999 02:07:52 -0500 (EST) (envelope-from jokes-in@apriori.net) Date: Thu, 4 Mar 1999 02:07:51 -0500 (EST) To: hummers@apriori.net Subject: [Hummers] The Short List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hummers-admin@apriori.net Errors-To: hummers-admin@apriori.net X-Mailman-Version: 1.0b8 Precedence: bulk List-Id: Humor email list. X-BeenThere: hummers@apriori.net --CAA24772.920531258/camel8.mindspring.com-- ========================================== (end included text) redscares@spamcom.net (obviously) is not a subscriber of list Hummers, yet the message seems to think he is. Therefore I can't delete from the subscriber list one who isn't subscribed... In the line: X-MindSpring-Loop: t-eaton@mindspring.com user t-eaton@mindspring.com IS a subscriber, however. Does anyone know what's going on with this? cheers - -- Philip. philip zimmermann paz@apriori.net www.apriori.net ayer, ma usa From lindsey@ncsa.uiuc.edu Fri Mar 5 07:17:53 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Fri, 5 Mar 1999 01:17:53 -0600 (CST) Subject: [Mailman-Developers] Does anyone else see these? In-Reply-To: from "paz" at Mar 4, 99 09:31:55 pm Message-ID: <199903050717.BAA14803@ferret.ncsa.uiuc.edu> > I've gotten two admin messages to mailman-owner from a mailman list I run > on apriori.net (Hummers - a humor list). This isn't a Mailman issue, it's an issue with the recepients email configuration. He's forwarding the message on from t-eaton@mindspring.com to redscares@spamcom.net while preserving the original envelope address. This is A Bad Thing because mail is being bounced back to mailman-owner@apriori.net instead of to the person who set up the forwarding. This is one example why one usually shouldn't preserve the envelope sender when forwarding mail. > redscares@spamcom.net (obviously) is not a subscriber of list Hummers, > yet the message seems to think he is. Therefore I can't delete from > the subscriber list one who isn't subscribed... > > In the line: > > X-MindSpring-Loop: t-eaton@mindspring.com > > user t-eaton@mindspring.com IS a subscriber, however. Yes, fortunately mindspring.com put in that header for you. In your case you can also tell for whom the mail was intended by looking at the Received: headers, but that's not always true (I believe sendmail takes out the recepient name if more than one address is being delivered to in the same SMTP transaction. That also means that you wouldn't be able to narrow down the address without manually probing all accounts at that domain). Perhaps Mailman could add (yet another) header indicating the targetted recepient to help with this type of situation? Maybe X-Mailman-Recepient? Or it could be wrapped it into another header like X-BeenThere... Chris From Harald.Meland@usit.uio.no Fri Mar 5 17:35:36 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 05 Mar 1999 18:35:36 +0100 Subject: [Mailman-Developers] Re: TOPICS In-Reply-To: Paulo Eduardo Neves's message of "Thu, 04 Mar 1999 22:30:45 -0300" References: <000001be6603$b5d19960$1e0a5ad1@SINGSING.STREEK.COM> <36DF33C5.48788862@inf.puc-rio.br> Message-ID: [Paulo Eduardo Neves] > Harald Meland wrote: > > Anyhow, I guess that implementing this would be a lot easier (and > > cleaner) if every list member had some "user objects" -- and that is > > planned for after 1.0. So I guess we'll think about it all until we > > have the infrastructure to implement it on top of in place. > > I've read in the TO-DO list about User profiles, is it the same of user > object? Not quite, but they're not unrelated, either. > Could you explain the idea behind it? Well, the motivation I have for implementing "user objects", is that I don't want one particular user that is subscribed to several Mailman mailing lists (on the same Mailman installation) to have to remember one password per list. If Mailman had an installation-wide database of all members subscribed to any of the lists, and each list had "pointers" pointing to specific user objects in this database (meaning that the users corresponding to the pointed-to objects are members of the pointing-from list), the user password could be kept in the user object instead of with each list. You'd also get a lot of other benefits from this, of course: * User objects could know about the different mail aliases belonging to one user (meaning that Mailman would know that `hmeland@usit.uio.no' and `harald.meland@usit.uio.no' were really the same user, which is very handy for "restrict posting privilege to list members") * Admins are users as well -- thus their _single_ admin password, which would work for all the lists they admin, could be stored in a (special) user object. Lists with multiple admins wouldn't need their admins to share the single list password anymore. * If some person changes email address, update the person's user object -- and all the mailing lists the person is a member of automatically goes to the new address. Ditto for disabling delivery when going on vacation etc. Having separate settings for different lists should of course remain possible. ... just to mention a few things. None of this is set in stone, of course -- these are just some ideas I have, nothing has actually been implemented. "Member profiles", I think, means that you each user can organize their subscriptions into hierarchies (within their user object) -- thus, any changes made to the root node in the hierarchy gets inherited by all your subscriptions. Example: * Root node | * Python mailing lists | * "Mailman-users" subscription options * "Mailman-developers" subscription options * Work-related mailing lists | * "postmaster" subscription options * "hostmaster" subscription options * "webmaster" subscription options Your local mail system has recently been upgraded to support addresses of the form `username+suffix@example.com', signifying that mail to this address goes directly into your IMAP folder called `suffix'. You want to use separate mail addresses for the python lists and the work-related lists -- so you enter each of these "member profiles" and update them, and the changes propagate down the tree to the different lists. Voila :) > I believe it would solve well a problem I have. I have an announcement > list where I send messages about a lot of topics. Not all topics are of > interest of all subscribers (i.e. Joe doesn't want to know about events > in other state). > > It looks like user profiles (or Topics) would solve this problem. Topics are not the same as member profiles. The (hypothetic) user "Topics" setting are meant to signify what subset of messages you want to receive from a topic-enabled Mailman list, while member profiles are for specifying defaults for subsets of your list subscriptions (regardless of whether the subscribed-to lists are topic-enabled or not). I was merely stating that for implementing topics, one needs to keep so much user-specific information (on what topics are deemed interesting) in Mailman, that keeping off implementing it until _after_ the introduction of user objects (which will provide a handy mechanism for storing user-specific information) would seem like a smart move. -- Harald From Harald.Meland@usit.uio.no Fri Mar 5 17:52:57 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 05 Mar 1999 18:52:57 +0100 Subject: [Mailman-Developers] MM1.0b9 Bug! (was: Setup prob: abs/rel CGI url) In-Reply-To: Christian Tismer's message of "Thu, 04 Mar 1999 19:40:13 +0100" References: <36DE9318.59C0C8D8@appliedbiometrics.com> <36DE9CD1.60544B41@appliedbiometrics.com> <36DED38D.34DE263F@appliedbiometrics.com> Message-ID: [Christian Tismer] > Harald Meland wrote: > > > > [Christian Tismer] > > > > > Hi Barry et al, > > > > > > I found it - Mailman 1.0b9 has a bug in admin.py . > > > > Which was fixed _days_ ago in CVS :-) > > That's great. > An average user will step into this trap, since 1.0b9 is the > current version. If one always has to check CVS, it makes > no sense to publish the zip file at all. On the contrary. Releasing betas are _part of_ testing new software. Please understand that I'm not saying that I don't appreciate you tracking down bugs in Mailman betas -- because I do, really -- but I thought it appropriate to respond and say that you could get a better fix for your problem from CVS. > I have to say: 10.b9 was published without proper testing. That depends on what you mean by "proper testing". If "proper testing" means compiling with all available of the hordes of different compilers available on lots and lots of OSes with all combinations of "configure" options, and then doing test runs of all parts of Mailman with all combinations of web servers, MTAs, Python releases, and whatnot, there is _no way_ we will get 1.0 out before the end of the century. The core developers _do_ typically check that changes they make appear to work right before they check them in -- but occasionally a bug slips through. > Anyway, the "/mailman/anything" strings are a little spread > around in the sources. In my opinion, it would be safer to > keep them in a central place (Defaults.py maybe) and just > use references. If you have a closer look at the places where /mailman/foobar are "spread around", I think you will see that they are usually fallbacks that are only used when the appropriate ways of getting at stuff doesn't work -- in particular, see the mm_cfg.py variables `DEFAULT_URL' and `PRIVATE_ARCHIVE_URL'. In the cases where /mailman/foobar are used as hardcoded values without any defaults, that is very likely a bug which should be fixed. Cheers, -- Harald From claw@kanga.nu Fri Mar 5 18:19:54 1999 From: claw@kanga.nu (J C Lawrence) Date: Fri, 05 Mar 1999 10:19:54 -0800 Subject: [Mailman-Developers] Does anyone else see these? In-Reply-To: Message from Christopher Lindsey of "Fri, 05 Mar 1999 01:17:53 CST." <199903050717.BAA14803@ferret.ncsa.uiuc.edu> Message-ID: On Fri, 5 Mar 1999 01:17:53 -0600 (CST) Christopher Lindsey wrote: > Perhaps Mailman could add (yet another) header indicating the > targetted recepient to help with this type of situation? Maybe > X-Mailman-Recepient? Or it could be wrapped it into another header > like X-BeenThere... One technique I used for my own list software (now defunct) was that every N'th message to each subscriber was sent individually with custom headers giving the subscription address, list name etc. All the other sends (the rest of N) were sent as per normal with 100 RCPT TO's per message. Then, instead of attempting to parse bounce formats, instead I merely looked for these custom headers in the bouce returns and tracked that way. In this way, by rotating the N thru the subscriber base so that on any one particular posting only 1/N'th of the subscribers were sent individual messages I could minimise mail load on the system and have an guaranteed accurate tracking system for who was *really* bouncing when there forwards inbetween. -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From tismer@appliedbiometrics.com Fri Mar 5 19:45:18 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Fri, 05 Mar 1999 20:45:18 +0100 Subject: [Mailman-Developers] MM1.0b9 Bug! (was: Setup prob: abs/rel CGI url) References: <36DE9318.59C0C8D8@appliedbiometrics.com> <36DE9CD1.60544B41@appliedbiometrics.com> <36DED38D.34DE263F@appliedbiometrics.com> Message-ID: <36E0344E.47E7C3E3@appliedbiometrics.com> Harald Meland wrote: > > [Christian Tismer] > > > Harald Meland wrote: > > > > > > [Christian Tismer] > > > > > > > Hi Barry et al, > > > > > > > > I found it - Mailman 1.0b9 has a bug in admin.py . > > > > > > Which was fixed _days_ ago in CVS :-) > > > > That's great. > > An average user will step into this trap, since 1.0b9 is the > > current version. If one always has to check CVS, it makes > > no sense to publish the zip file at all. > > On the contrary. Releasing betas are _part of_ testing new software. > > Please understand that I'm not saying that I don't appreciate you > tracking down bugs in Mailman betas -- because I do, really -- but I > thought it appropriate to respond and say that you could get a better > fix for your problem from CVS. I had been using 1.0b7 with success. 1.0b9 introduced a bug which caused me some trouble, and I wasn't sure where to look: Did it depend of the slightly different machine, the older Python version, or mailman? > > I have to say: 10.b9 was published without proper testing. > > That depends on what you mean by "proper testing". If "proper > testing" means compiling with all available of the hordes of different > compilers available on lots and lots of OSes with all combinations of > "configure" options, and then doing test runs of all parts of Mailman > with all combinations of web servers, MTAs, Python releases, and > whatnot, there is _no way_ we will get 1.0 out before the end of the > century. I am just saying that the changes, which affected my config unfortunately, were not tested against a machine which would use them. Besides that, I have seen some changes to some scripts which were obviously wrong and made it into the next release. Example: A number of scripts have this path hack (bin/newlist for instance), and for an older Python 1.5, a try..execpt for getpass was introduced. Nice idea, but doing this before the "import path" makes no sense, since Mailman.pythonlib isn't available before that import. I think, changes like this make it into the dist too quickly. Polite speaking is "without proper testing", my company would yell "thoughtless" at me. :c) > The core developers _do_ typically check that changes they make appear > to work right before they check them in -- but occasionally a bug > slips through. Well, you say that bug was fixed, see CVS. This means, someone fixed a bug, put it into CVS, and knew that this bug is in the b9 zip file, but... did I miss something, or was there a note on the download page that one might need a patch to get it running? I didn't want to do testing, but get the latest "stable" version and assumed that was 1.0b9 . Instead, I spent hours of figuring out known things, although I was in trouble (had just lost my old installation and needed a new one ASAP for customers). > > Anyway, the "/mailman/anything" strings are a little spread > > around in the sources. In my opinion, it would be safer to > > keep them in a central place (Defaults.py maybe) and just > > use references. > > If you have a closer look at the places where /mailman/foobar are > "spread around", I think you will see that they are usually fallbacks > that are only used when the appropriate ways of getting at stuff > doesn't work -- in particular, see the mm_cfg.py variables > `DEFAULT_URL' and `PRIVATE_ARCHIVE_URL'. Right, there are just a few places. Anyway I think it would be cleaner to remove every repetition of a fallback, default or whatever into one central place. This was not meant as crisicism, just a hint. If, for instance, the "/mailman/admin" etc. fallbacks were in one place, a typo from future changes would either not occour, or show up in a more obvious way. Be assured, I like Mailman and used it from the first days. I'm also telling everybody to use it. At the same time, whenever I want to install it, I get into some trouble. Usually I can help myself, but what about other users who just want to follow the instructions and run it? I think it would be better for MM's public acceptance if there was always a version known to be used in many installations. It would not have all new features, but also not the new bugs. In other words: If the latest beta needed a bug fix, why don't we mark it as problematic and go back to, say, 1.0b7? cheers - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home From klm@digicool.com Fri Mar 5 20:14:10 1999 From: klm@digicool.com (Ken Manheimer) Date: Fri, 5 Mar 1999 15:14:10 -0500 Subject: [Mailman-Developers] Does anyone else see these? Message-ID: <613145F79272D211914B0020AFF640190BED82@GANDALF> On Fri, 5 Mar 1999 01:17:53 -0600 (CST), Christoper Lindsey wrote: > Previously, paz@apriori.net wrote: > > I've gotten two admin messages to mailman-owner from a mailman list I run > > on apriori.net (Hummers - a humor list). > > This isn't a Mailman issue, it's an issue with the recipients email > configuration. He's forwarding the message on from t-eaton@mindspring.com > to redscares@spamcom.net while preserving the original envelope > address. This is A Bad Thing because mail is being bounced back > to mailman-owner@apriori.net instead of to the person who set up the > forwarding. This is one example why one usually shouldn't preserve the > envelope sender when forwarding mail. Good call. > > [...] > Perhaps Mailman could add (yet another) header indicating the > targetted recepient to help with this type of situation? Maybe > X-Mailman-Recepient? Or it could be wrapped it into another header > like X-BeenThere... Unfortunately, this conflicts with the way mailman delivers stuff. It batches up posts to groups of people - typically five bunches. This means that deliveries aren't to any one individual recipient. Using these batches is bound to be quicker than making an individual send for each person (particularly when the MTA implements smart batching to sites, which mailman tries to support by grouping messages bound for the same domain), so it's unlikely we'd want to defeat this feature for the traceability - though there _are_ significant places where traceability would be helpful... Ken klm@digicool.com From roger@infomed.sld.cu Fri Mar 5 20:46:13 1999 From: roger@infomed.sld.cu (=?iso-8859-1?Q?Roger_Pe=F1a_Escobio?=) Date: Fri, 5 Mar 1999 15:46:13 -0500 Subject: [Mailman-Developers] to edit de alias file Message-ID: <01be6749$355b6c10$1c7001c4@ntserver.sld.cu> Hi I was looking the alias_wrapper file in src/ subdir , trying to fix it , because the creation of a new list is, I think, incomplete if we can't edit an aliases file automatically, I found only one thing, the line 87 > execlp(SENDMAIL_CMD, SENDMAIL_CMD,"-bi"); need another argument, NULL, that is , the line should be > execlp(SENDMAIL_CMD, SENDMAIL_CMD,"-bi", NULL); and that's all, you can edit your aliases files if you have the right permission for write in it, my choice is /etc/mailman/aliases (/etc/mailman/) with write permission for group mailman , and woks fine. also I include a rmaliases for delete one list from de alias file, if anybody like it e-mail me please . I think that this feature should be in the release that's why I submit this msg. to this list, may be the developers are interested in things like this one. Roger From bkc@murkworks.com Mon Mar 8 00:29:51 1999 From: bkc@murkworks.com (Brad Clements) Date: Sun, 7 Mar 1999 20:29:51 -0400 Subject: [Mailman-Developers] MailList "base is not a class object" error Message-ID: <199903080123.UAA06834@anvil.murkworks.com> Hi, I'm porting Mailman 1.0b9 to Win32 (Python 1.5.2b2).  When running newlist.py, I get an error on line 50 of MailList.py, base is not a class object on the definition of MailList. However if I "hand import", it seems to load ok. Anyone try mailman on 1.5.2b2 yet? Any suggestions? Thanks Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937 From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Mar 9 04:24:31 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 8 Mar 1999 23:24:31 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] [ANNOUNCE] Mailman 1.0b9 References: <14042.58410.557890.269150@anthem.cnri.reston.va.us> Message-ID: <14052.41599.185573.703300@anthem.cnri.reston.va.us> >>>>> "HM" == Harald Meland writes: HM> However, a more general "Add this header (standard or not) (if HM> it doesn't exist already) to all messages to this list" might HM> be good. But not for 1.0, methinks. I agree with both points! We'll have to think about the best way to present this on the admin pages. Anyway, I've added this to the TODO file. From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Mar 9 05:02:30 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 9 Mar 1999 00:02:30 -0500 (EST) Subject: [Mailman-Developers] bounce processing question and idea for future enhancements... References: <00b101be64d4$dfcab240$1e0a5ad1@SINGSING.STREEK.COM> Message-ID: <14052.43878.793141.253201@anthem.cnri.reston.va.us> >>>>> "JH" == Jeff Hahn writes: JH> Bounce processing question... JH> Since some of the big email domains (hotmail, aol, JH> etc.) are known to "burp" and deny existence of perfectly JH> valid users, I'd like to handle all returns as bounces and not JH> remove people automatically on the first "user unknown" JH> message. I assume the way to handle it is to change "REMOVE" JH> to "BOUNCE" in the lines like the following in bouncer.py JH> (regex.compile('.*%s: User unknown.*' % email_regexp), JH> REMOVE), JH> Any comments? Any better way to do it? We've talked about changing bounce handling so that all bounces of any kind are handled similarly. They'd have a threshold over which the action would occur. By default, the address would be disabled, and then some future attempts would be made to contact the user. If they can't be reached after N number of attempts, maybe they'd be removed. That way if a user is temporarily unavailable (for whatever reason), they wouldn't get immediately nixed, and they'd have an opportunity later to re-enable themselves. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Mar 9 05:26:10 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 9 Mar 1999 00:26:10 -0500 (EST) Subject: [Mailman-Developers] Re: Possible Fix for password lookup bug References: <36DD9564.3CA9DDF9@lyra.org> <199903032115.PAA04843@ferret.ncsa.uiuc.edu> Message-ID: <14052.45298.866709.284744@anthem.cnri.reston.va.us> >>>>> "CL" == Christopher Lindsey writes: CL> It *would* be nice to have the Web page display the CL> subscribers in a case sensitive format, just for continuity's CL> sake. But it's a lot less minor now that I realize my gaffe CL> with regard to list_members. :) What I have done is to include the case-preserved address in the individual user options page, if it isn't all lowercased. I'll have to think about using the case-preserved address in the membership management page. CL> Here's another feature request, though... From the membership CL> page it would be very nice to be able to click on a CL> subscriber's name, then have it take me to a page for that CL> user's specific settings. Options would include generation of CL> a new password, changing the password to one chosen by the CL> admin, renaming this address to a new address (such as when a CL> user switches ISPs), etc. Good idea. Post 1.0. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Mar 9 05:28:54 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 9 Mar 1999 00:28:54 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] Possible Fix for password References: <36DCD579.328BE248@uiuc.edu> <199903030629.AAA32653@ferret.ncsa.uiuc.edu> Message-ID: <14052.45462.986079.493885@anthem.cnri.reston.va.us> >>>>> "CL" == Christopher Lindsey writes: CL> The password *is* being assigned, but it can't find it later. CL> If I do a CL> strings $prefix/lists/test2/config.db | less CL> and search for the username with uppercase characters, it CL> comes up with a password on the next line... BTW, because config.db is a Python marshal, you can get at the real objects by doing the following (kind of gross) from $prefix: % python >>> import marshal >>> d = marshal.load(open('lists/mylist/config.db')) Now `d' is a dictionary which you can poke at to find all kinds of useful information. A little less gross is % python >>> from Mailman.MailList import MailList >>> m = MailList('mylist', lock=0) Now you can access attributes on m that are equivalent to the keys in d above. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Mar 9 05:38:37 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 9 Mar 1999 00:38:37 -0500 (EST) Subject: [Mailman-Developers] change request: admin password changing References: <36C48867.3E677BDF@lyra.org> Message-ID: <14052.46045.212106.75993@anthem.cnri.reston.va.us> >>>>> "HM" == Harald Meland writes: HM> I agree. I think that the change of admin password stuff HM> belongs on the "General options" page, and not on _all_ the HM> pages. Agreed. HM> However, I'm undecided in the matter of making this (site) HM> configurable. I agree with Greg on this :-) HM> Would anyone object if I just put in a hardcoded condition on HM> 'category == "general"' around the call to HM> FormatPasswordStuff() in HM> Mailman.Cgi.admin.FormatConfiguration()? Perfect. I beat you to the check-in though :-) Thanks Harald. -Barry From claw@varesearch.com Tue Mar 9 05:50:11 1999 From: claw@varesearch.com (J C Lawrence) Date: Mon, 08 Mar 1999 21:50:11 -0800 Subject: [Mailman-Developers] Proposal for funded custom work on MailMan Message-ID: VA Research is potentially interested in using MailMan for a number of internal and external activities, but would need a couple extensions to the current beta: 1) We need to be able to distinguish between "internal" and "external" lists. An internal list would refuse all subscriptions and posts from addresses which didn't match a given pattern (eg only messages originating from *@*varesearch.com can subscribe/post). External lists would be without such controls. 2) As discussed here previously, an ultra-simplified list-creation and administration interface suitable for giving to a computer illiterate HR person to create mailing lists on demand. We are potentially willing to fund one or more of the MailMan developers making these changes for us as long as the resultant changes are folded into the MailMan base release at some future date, and the changes are released under the GPL. I understand the concerns about folding such changes into the production version so close to 1.0 release, holding off on the patches till post-1.0 would be utterly acceptable. If one of the mailman developers is interested in discussing this with me, please email me at claw@varesearch.com and we'll see what we can work out. -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Mar 9 18:58:28 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 9 Mar 1999 13:58:28 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] posting restrictions still confusing to me (or not References: <36E42B56.AF30FB25@appliedbiometrics.com> <199903082118.PAA05965@ferret.ncsa.uiuc.edu> Message-ID: <14053.28500.957849.730251@anthem.cnri.reston.va.us> About posting that are held for approval even thought they seem to be coming from a list member when member_posting_only is set to true... Here's what I'm seeing. I put the following in Mailman/MailList.py inside the Post() method: sys.stderr.write('envsend: %s, sender: %s\n' % (msg.GetEnvelopeSender(), msg.GetSender())) This will write the envelope sender and `header' sender to logs/error, which you can tail as you send messages to the list. For me, envelope sender is always None, so the test falls through to msg.GetSender(), which is taken from my spoofable From: header. Back in November, Scott added the use of GetEnvelopeSender() before GetSender() because he'd been hit by a spam getting through that should have been held for approval, but IIRC, Scott's also been backing away from using the envelope sender in some situations. Maybe Scott is able to elaborate. rfc822.py gets the envelope sender as the unixfrom attribute on the message object. This it gets from the "From " line in the message. I don't understand why you're getting something different from me (I'm using sendmail 8.9.something). Anyway, here's what I propose. I'll add a variable to Defaults.py/mm_cfg.py called, say APPROVE_WITH_ENVELOPE_SENDER which will be set to true by default. You set it to false and Mailman will only use the sender. I'll add info to the FAQ and such explaining that this is easier to spoof, but may work around problems where the envelope sender isn't getting set correctly. If anybody can debug this further, I'd appreciate it. -Barry From ayu1@nycap.rr.com Tue Mar 9 22:00:53 1999 From: ayu1@nycap.rr.com (Alex Yu) Date: Tue, 09 Mar 1999 17:00:53 -0500 Subject: [Mailman-Developers] Error Message - Crontab In-Reply-To: <14053.28500.957849.730251@anthem.cnri.reston.va.us> References: <36E42B56.AF30FB25@appliedbiometrics.com> <199903082118.PAA05965@ferret.ncsa.uiuc.edu> Message-ID: <4.1.19990309165932.009943e0@pop1.rpi.edu> Hello, This is the error crontab message I got. Would someone help me out? Mailman was running very in past one month. Suddently I just got this message. I am running beta 9. Subject: Cron /usr/bin/python /usr/local/mailman/cron/run_queue X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: : shell-init: could not get current directory: Alex From ayu1@nycap.rr.com Tue Mar 9 22:06:11 1999 From: ayu1@nycap.rr.com (Alex Yu) Date: Tue, 09 Mar 1999 17:06:11 -0500 Subject: [Mailman-Developers] Error Message - Crontab In-Reply-To: <4.1.19990309165932.009943e0@pop1.rpi.edu> References: <14053.28500.957849.730251@anthem.cnri.reston.va.us> <36E42B56.AF30FB25@appliedbiometrics.com> <199903082118.PAA05965@ferret.ncsa.uiuc.edu> Message-ID: <4.1.19990309170529.009b4830@pop1.rpi.edu> Hello, Actually I tried to su as mailman, I got the following bad message. [/usr/local] # su - mailman shell-init: could not get current directory: job-working-directory: could not get current directory: job-working-directory: could not get current directory: job-working-directory: could not get current directory: job-working-directory: could not get current directory: job-working-directory: could not get current directory: Any1 knows how to fix it? Alex From bwarsaw@python.org Tue Mar 9 22:09:44 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Tue, 9 Mar 1999 17:09:44 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] Error Message - Crontab References: <14053.28500.957849.730251@anthem.cnri.reston.va.us> <36E42B56.AF30FB25@appliedbiometrics.com> <199903082118.PAA05965@ferret.ncsa.uiuc.edu> <4.1.19990309170529.009b4830@pop1.rpi.edu> Message-ID: <14053.39976.20535.683604@anthem.cnri.reston.va.us> Check the permissions on ~mailman. Did they get messed up some how? From ayu1@nycap.rr.com Tue Mar 9 22:31:33 1999 From: ayu1@nycap.rr.com (Alex Yu) Date: Tue, 09 Mar 1999 17:31:33 -0500 Subject: [Mailman-Developers] Re: [Mailman-Users] Error Message - Crontab In-Reply-To: <4.1.19990309170529.009b4830@pop1.rpi.edu> References: <4.1.19990309165932.009943e0@pop1.rpi.edu> <14053.28500.957849.730251@anthem.cnri.reston.va.us> <36E42B56.AF30FB25@appliedbiometrics.com> <199903082118.PAA05965@ferret.ncsa.uiuc.edu> Message-ID: <4.1.19990309173036.009b1750@pop1.rpi.edu> At 05:06 PM 1999/3/9 -0500, Alex Yu wrote: >Actually I tried to su as mailman, I got the following bad message. >[/usr/local] # su - mailman Sorry, I just fixed the problem. I found out that you can't have umkas 711 on /usr/bin, /usr/sbin, /usr/local/bin and /usr/local/sbin. Thanks. Alex From tismer@appliedbiometrics.com Tue Mar 9 22:44:42 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Tue, 09 Mar 1999 23:44:42 +0100 Subject: [Mailman-Developers] fork() problem and popen2.py test Message-ID: <36E5A45A.C4B81609@appliedbiometrics.com> Hi, again I had lots of trouble with Mailman on starship.skyport.net . Mailman was unable to deliver messages, but didn't tell it. The reason turned out to be dependent wether Python 1.5 (the early version, of course) was made with threads or not. The threaded version had a bad effect on sys.stdin after an os.fork(). sys.stdin was a "bad file number" in the child process. Maybe these are known things, but there are some issues: To Guido: the popen2.py program does a very good job in its self test procedure. Why is this not included in the standard test suite? Also, after "make clean" and a new "configure", the problem did not vanish. I did after a "make distclean". To the Mailmen: It was quite hard to track this error down through the mailman scripts. Finally, I ended up if I made the deliver fork temporarily into a do-nothing. The "deliver" script does a number of forks. I does no proper checking if the forks work (under Linux, btw., fork never returns ENOMEM, so the check isn't safe yet). Deliverer.py also trusts the os.popen very much. In my situation, the error logging was quite random, in three of about 200 tests I got a "broken pipe" message in the log, in the other cases, there was just nothing. It seems to be a race condition which forked process dies first, - I'm not sure. Anyway, sys.stdin is read without error checking in the deliver script. I think, some more checks are necessary to guarantee that failing deliveries get noticed. The combination of a) threaded Python1.5 behavior and b) too much trust from Mailman caused me a desperate error search. Took me 8 hours to nail it down. I thought I should tell this, to avoid similar effects for others. cheers - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Mar 9 23:23:43 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 9 Mar 1999 18:23:43 -0500 (EST) Subject: [Mailman-Developers] MailList "base is not a class object" error References: <199903080123.UAA06834@anvil.murkworks.com> Message-ID: <14053.44415.630380.674106@anthem.cnri.reston.va.us> >>>>> "BC" == Brad Clements writes: BC> I'm porting Mailman 1.0b9 to Win32 (Python 1.5.2b2).  When BC> running newlist.py, I get an error on line 50 of MailList.py, BC> base is not a class object on the definition of MailList. BC> However if I "hand import", it seems to load ok. BC> Anyone try mailman on 1.5.2b2 yet? Well, I've run Mailman on the current CVS snapshot, no problem -- but on Unix of course. I suspect that the problem has more to do with running it on Windows. I don't know of anyone who's done that yet, although the error message you're getting is kind of strange. -Barry From bryner@uiuc.edu Wed Mar 10 01:15:34 1999 From: bryner@uiuc.edu (Brian Ryner) Date: Tue, 09 Mar 1999 19:15:34 -0600 Subject: [Mailman-Developers] "User 0 lacks a password" Message-ID: <36E5C7B5.6DB046A9@uiuc.edu> Hi- Ok, I got this error from the list: Mailman noticed in .MailUserPassword() that: User: 0 List: mhs-alumni lacks a password. Please notify the Mailman system manager at this site! Now, there is no user with email address "0" (you probably guessed that). I don't know how to further track down what caused this. Ideas anyone? This is from CVS just after the update which fixed the capital letters/password issue (soon after the checkin at 1:55 CST on March 5). Thanks! -Brian Ryner bryner@uiuc.edu From grin@tolna.net Wed Mar 10 01:51:53 1999 From: grin@tolna.net (Peter Gervai) Date: Wed, 10 Mar 1999 02:51:53 +0100 Subject: [Mailman-Developers] upgraded to b9, .../lists/* permission is faulty Message-ID: <19990310025153.V9075@mail.tolna.net> Hello, After upgrading from b7 to b9 (make install, make upgrade) almost everything seemed to work. At the first admin move it turned out that somehow the list directories (.../lists/* dirs) lost their www-uid owner and got mailman owner somehow. This is bad, since cgi can't rename (/move) db files that way. Maybe ought to be fixed. (chown'ing back to www those dirs solved the problem.) regards, grin ps: disclaimer as always: could have been my fault. pps: it's still magic who should own what. :) From claw@kanga.nu Wed Mar 10 02:48:37 1999 From: claw@kanga.nu (J C Lawrence) Date: Tue, 09 Mar 1999 18:48:37 -0800 Subject: [Mailman-Developers] Error Message - Crontab In-Reply-To: Message from Alex Yu of "Tue, 09 Mar 1999 17:06:11 EST." <4.1.19990309170529.009b4830@pop1.rpi.edu> Message-ID: On Tue, 09 Mar 1999 17:06:11 -0500 Alex Yu wrote: > Hello, Actually I tried to su as mailman, I got the following bad > message. > [/usr/local] # su - mailman shell-init: could not get current > directory: job-working-directory: could not get current directory: > job-working-directory: could not get current directory: > job-working-directory: could not get current directory: > job-working-directory: could not get current directory: > job-working-directory: could not get current directory: > Any1 knows how to fix it? Your current directory, the one you issue the `su` command from, must be readable by the user ID you are changing to. -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From lindsey@ncsa.uiuc.edu Wed Mar 10 03:45:36 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Tue, 9 Mar 1999 21:45:36 -0600 (CST) Subject: [Mailman-Developers] Request for minor feature Message-ID: <199903100345.VAA08252@ferret.ncsa.uiuc.edu> Tonight I've been struggling with the "convert the URL used in mailman to something else" scenario. Specifically, I'm moving everything to https://secure.domain.com/ from http://www.domain.com/ I couldn't figure out why things weren't working until I finally stumbled across the web_page_url stuff in the code. Since I had commented it all out in the Web pages (I didn't want the list admins mucking with the URL), I had totally forgotten about them. :) Anyhow, I'm wondering if it would be considered acceptable behavior for mailman to leave web_page_url blank UNLESS overridden by a value. Looking at the code for GetAbsoluteScriptURL, it looks like a blank value will default to DEFAULT_URL, which seems like the right thing to do. So, when a new list is created can it just leave web_page_url blank? As far as I can tell, this should do the trick (against the current CVS tree): *** Mailman/MailList.py Tue Mar 9 21:31:20 1999 --- Mailman/MailList.py.bak Tue Mar 9 21:31:01 1999 *************** *** 224,230 **** self.advertised = mm_cfg.DEFAULT_LIST_ADVERTISED self.max_num_recipients = mm_cfg.DEFAULT_MAX_NUM_RECIPIENTS self.max_message_size = mm_cfg.DEFAULT_MAX_MESSAGE_SIZE ! self.web_page_url = mm_cfg.DEFAULT_URL self.owner = [admin] self.reply_goes_to_list = mm_cfg.DEFAULT_REPLY_GOES_TO_LIST self.posters = [] --- 224,230 ---- self.advertised = mm_cfg.DEFAULT_LIST_ADVERTISED self.max_num_recipients = mm_cfg.DEFAULT_MAX_NUM_RECIPIENTS self.max_message_size = mm_cfg.DEFAULT_MAX_MESSAGE_SIZE ! self.web_page_url = '' self.owner = [admin] self.reply_goes_to_list = mm_cfg.DEFAULT_REPLY_GOES_TO_LIST self.posters = [] Chris P.S. If this is changed, perhaps the same should be done for host_name? The other alternative that I see is creating a global list changing mechanism; it would change EVERY list's value of variable 'n' if the listname matched a certain regex. This would be very cool in the post-1.0 era... Comments? From sjp@buzzsaw.net Wed Mar 10 03:49:08 1999 From: sjp@buzzsaw.net (Steve Phillips) Date: Tue, 9 Mar 1999 21:49:08 -0600 (EST) Subject: [Mailman-Developers] Cron /usr/bin/python /home/m/mailman/cron/gate_news (fwd) (fwd) Message-ID: Help! My mailbox is filling up with these error messages. I just upgraded from beta6 to beta9. ---------- Forwarded message ---------- Date: Tue, 9 Mar 1999 21:20:02 -0600 From: root (Cron Daemon) To: mailman Subject: Cron /usr/bin/python /home/m/mailman/cron/gate_news Exception NotLockedError in ignored From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Mar 10 14:58:22 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 10 Mar 1999 09:58:22 -0500 (EST) Subject: [Mailman-Developers] "User 0 lacks a password" References: <36E5C7B5.6DB046A9@uiuc.edu> Message-ID: <14054.34958.860556.543753@anthem.cnri.reston.va.us> >>>>> "BR" == Brian Ryner writes: BR> Now, there is no user with email address "0" (you probably BR> guessed that). I don't know how to further track down what BR> caused this. Ideas anyone? This is from CVS just after the BR> update which fixed the capital letters/password issue (soon BR> after the checkin at 1:55 CST on March 5). Try doing an update. There was a bug in my checkin which is now fixed. -Barry From wfrank@syskonnect.de Thu Mar 11 14:42:02 1999 From: wfrank@syskonnect.de (Werner Frank) Date: Thu, 11 Mar 1999 15:42:02 +0100 (MET) Subject: [Mailman-Developers] change in admin.py for Solaris 2.5.1 and Netscape Fasttrack 2.1 Server Message-ID: <199903111442.PAA13880@docu.skd.de> Hello, while trying to run mailman-1.0b9 on Solaris 2.5.1 together with a Netscape Fasttrack Server 2.1 I had to make the following change in $prefix/Mailman/Cgi/admin.py: I changed line 129 from "path" : os.environ.get("REQUEST_URI", defaulturi), to "path" : '/' + os.environ.get("REQUEST_URI", defaulturi), The result is that in the Web Page for the Administrative Authentication where you enter the password of the list administrator, the HTML code now reads: instead of Obviously the Fasttrack Server must be told that this is an absolute path otherwise the following URL will be set to something like http://server/mailman/admin/mailman/admin/mailmantest which can't be treated correctly. May be it's not the best solution but now it works. werner frank wfrank@syskonnect.de From wfrank@syskonnect.de Thu Mar 11 16:49:55 1999 From: wfrank@syskonnect.de (Werner Frank) Date: Thu, 11 Mar 1999 17:49:55 +0100 (MET) Subject: [Mailman-Developers] more problems with Solaris/Fasttrack Message-ID: <199903111649.RAA14020@docu.skd.de> Hello, I get more and more desperate: When adding a user via the "Membership Management" the user is added however trannsmission of the web page runs into timeout and the site is closed with a bold "OK" and a message stating "An error has occured." Any idea/hint what's going wrong ? TIA, wfrank@syskonnect.de Solaris 2.5.1, mailman-1.0b9, Netscape Fasttrack v2.1, Sendmail 8.8.5/8.6.12 From James Strickland Thu Mar 11 18:52:47 1999 From: James Strickland (James Strickland) Date: Thu, 11 Mar 1999 10:52:47 -0800 (PST) Subject: [Mailman-Developers] Re: [Mailman-Users] Inlining MIME attachments on Mailman web archives In-Reply-To: <87hfrsb1h1.fsf@vega.law.miami.edu> 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. --0-872916835-921175844=:27847 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: On 11 Mar 1999, Michael Alan Dorman wrote: > Unfortunately, a discussion from a month back reveals that pipermail > doesn't have the capability, and no one has at present stepped up to > bat to implement it. There was some talk of making it easier to use > other archiving tools (like hypermail or mhonarc), but I don't know if > this is going to go forward. > > Which is unfortunate since as far as I can tell, it's the one wart on > an otherwise stunningly good program. I'd "step up to the bat" if only I had more time. I'm attaching something which reads a message on stdin, prints out the header and (for demo purposes) some decoded stuff from the header, then proceeds to decode the message, storing attachments (if any) as separate files. Note that it doesn't handle attachments recursively (it should - there are some mailers which send multipart/alternative parts, so the only text/plain part is buried two levels down). It also doesn't handle broken mailers like elm which send a Content-type of "text"! Anyways, the main message has the first plain text part, plus references to the attachments. btw: as a stopgap measure you can simply have a link to a script which would print out Content-type: message/rfc822 Netscape (and maybe other browsers) knows what to do with a Content-type: message/rfc822; it handles displaying attachments and parsing the header and everything. The downside, of course, is that you can't add anything else like links to the next message. Hopefully this should serve as a good starting point. One of the great things about Python is that it comes standard with all these wonderful libraries! -- James Strickland Perforce Software --0-872916835-921175844=:27847 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="samplemimedecoder.py" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: IyEvdXNyL2xvY2FsL2Jpbi9weXRob24NCiMgUmVhZCBtZXNzYWdlIGZyb20g c3RkaW4sIGRlY29kZSBNSU1FIGF0dGFjaG1lbnRzIChpZiBhbnkpLCB3cml0 ZSByZXN1bHQNCiMgYXMgbiBwYXJ0cywgbj49MQ0KIyoqKioqKioqKioqKioq KnlldCB0byBkbzogcmVjb2duaXplIHV1ZW5jb2RlIGluIGJvZHkgb2YgbWVz c2FnZS4NCiMqKioqKnNpbXBseSByZWNvZ25pemUgIl5iZWdpbiBbMC03XXsz fSAiIGFuZCBzcGl0IG91dCB0byBmaWxlIHVudGlsICJeZW5kIg0KIyoqKioq dGhlbiBydW4gdXUuZGVjb2RlKCkNCg0KaW1wb3J0IHN5cywgb3MsIG1pbWV0 b29scywgbXVsdGlmaWxlDQpkZXN0X2Rpcj0nL3RtcCcgIyoqKmZvciB0ZXN0 aW5nDQoNCg0KZGVmIGNvcHkoaW5wdXQsb3V0cHV0LHByZXBlbmQ9JycpOg0K ICAnJydDb3B5IGlucHV0IHRvIG91dHB1dCB1c2luZyByZWFkbGluZSgpLCBv cHRpb25hbGx5IHByZXBlbmRpbmcgYSBzdHJpbmcNCiAgdG8gZWFjaCBsaW5l LiAgTm90ZSB0aGF0IG11bHRpZmlsZSByZXF1aXJlcyB1c2luZyByZWFkbGlu ZSgpIScnJw0KDQogIHdoaWxlIDE6DQogICAgbGluZSA9IGlucHV0LnJlYWRs aW5lKCkNCiAgICBpZiBub3QgbGluZTogYnJlYWsNCiAgICBvdXRwdXQud3Jp dGUocHJlcGVuZCtsaW5lKQ0KDQoNCmRlZiBzdG9yZV9tZXNzYWdlKCk6DQog IA0KICAjIGluaXRpYWxpemUgaW5wdXQgKHN0ZGluKSBhbmQgb3V0cHV0IChm b3Igbm93IHN0ZG91dCkNCiAgbWFpbm91dHB1dCA9IHN5cy5zdGRvdXQNCiAg aW5wdXQgID0gbXVsdGlmaWxlLk11bHRpRmlsZShzeXMuc3RkaW4pDQogIG1h aW4gICA9IG1pbWV0b29scy5NZXNzYWdlKGlucHV0LDApICMgcmVhZHMgdGhl IG1haWwgaGVhZGVyDQogIA0KIyAgIyBwcmludCBvdXQgdGhlIG9yaWdpbmFs IGhlYWRlciBsaW5lcyB2ZXJiYXRpbQ0KIyAgZm9yIGxpbmUgaW4gbWFpbi5o ZWFkZXJzOg0KIyAgICBwcmludCBsaW5lICMgZWFjaCBsaW5lIGlzIGFscmVh ZHkgdGVybWluYXRlZCB3aXRoIFxuDQoNCiAgIyBwcmludCBvdXQgaGVhZGVy DQogIGZvciBmaWVsZCBpbiBtYWluLmtleXMoKToNCiAgICBwcmludCAnJXM6 ICVzJyAlIChmaWVsZCxtYWluW2ZpZWxkXSkNCg0KICAjIC0gZGVjb2RlZCBu YW1lIGFuZCBlbWFpbCBhZGRyZXNzDQogIG5hbWUsZW1haWwgPSBtYWluLmdl dGFkZHIoJ2Zyb20nKQ0KICBwcmludCAnTmFtZTogJXNcbicgJSBuYW1lDQog IHByaW50ICdFbWFpbDogJXNcbicgJSBlbWFpbA0KICANCiAgIyAtIGRlY29k ZWQgdGltZXN0YW1wIC0+IHRpbWV6b25lIGFuZCBVVEMgdGltZXN0YW1wDQog IGRhdGVwbHVzdHogPSBtYWluLmdldGRhdGVfdHooJ2RhdGUnKQ0KDQogIGlm IGRhdGVwbHVzdHo6ICMgdmFsaWQgZGF0ZSBwYXJzZWQNCiAgICB0em9mZnNl dCA9IGRhdGVwbHVzdHpbLTFdDQogICAgaWYgbm90IHR6b2Zmc2V0OiB0em9m ZnNldD0wDQogICAgaW1wb3J0IHRpbWUsIHJmYzgyMiAjIGp1c3QgdG8gZG8g dGhlIGNvbnZlcnNpb24gdG8gVVRDDQogICAgc2Vjc3NpbmNlMTk3MHV0YyA9 IHJmYzgyMi5ta3RpbWVfdHooZGF0ZXBsdXN0eikNCiAgICB1dGMgPSB0aW1l LmdtdGltZShzZWNzc2luY2UxOTcwdXRjKQ0KICAgIHByaW50ICd0em9mZnNl dDogJWRcbicgJSB0em9mZnNldCAjIGFkZCB0byBVVEMgdG8gZ2V0IGxvY2Fs IGZvciBzZW5kZXINCiAgICBwcmludCAndXRjOiAlMDRkLyUwMmQvJTAyZCAl MDJkOiUwMmQ6JTAyZFxuJyAlIHV0Y1s6Nl0NCiAgZWxzZToNCiAgICBwcmlu dCAnSW52YWxpZCBkYXRlIGZvcm1hdCEnDQoNCg0KICAjIERlYWwgd2l0aCBN SU1FIGVuY29kaW5nLCBpZiBhcHBsaWNhYmxlLg0KICAjIFJGQzIwNDYgc2F5 cyAnVGhlIENvbnRlbnQtVHlwZSBmaWVsZCBmb3IgbXVsdGlwYXJ0IGVudGl0 aWVzDQogICMgcmVxdWlyZXMgb25lIHBhcmFtZXRlciwgImJvdW5kYXJ5Ii4n ICBJIGRvbid0IGJvdGhlciB0byBjaGVjaw0KICAjIHRoYXQgdGhlIENvbnRl bnQtVHlwZSBtYXRjaGVzLCBiZWNhdXNlIHRoZSBvYmplY3RpdmUgaGVyZSBp cw0KICAjIHRvIHN0b3JlIHRoZSB0aGluZywgbm90IHRvIGNvbXBsYWluIGFi b3V0IGJyb2tlbiBtYWlsZXJzLg0KICANCiAgYXR0YWNobWVudHMgPSBbXQ0K ICBib3VuZGFyeSA9IG1haW4uZ2V0cGFyYW0oJ2JvdW5kYXJ5JykNCiAgDQog IGlmIG5vdCBib3VuZGFyeTogIyBzaW5nbGUgcGFydCBtZXNzYWdlDQogIA0K ICAgIGNvcHkoaW5wdXQsbWFpbm91dHB1dCwnXHQnKTsNCiAgDQogIGVsc2U6 ICMgbXVsdGlwYXJ0IG1lc3NhZ2UNCiAgDQogICAgIyBtYWtlIGEgZGlyZWN0 b3J5IHRvIHN0b3JlIHRoZSBwYXJ0cw0KICAgIG1lc3NhZ2VfbnVtYmVyID0g NDIgIyoqKiphc3NpZ24gYSB1bmlxdWUgaWRlbnRpZmllcg0KICAgIHRyeTog b3MubWtkaXIoJyVzLyVkJyAlIChkZXN0X2RpcixtZXNzYWdlX251bWJlcikp DQogICAgZXhjZXB0OiBwYXNzICMgd2UgZG9uJ3QgY2FyZSBpZiBpdCdzIGFs cmVhZHkgdGhlcmUNCg0KICAgICMgc2tpcCB0byB0aGUgc3RhcnQgb2YgdGhl IGZpcnN0IHBhcnQNCiAgICBpbnB1dC5wdXNoKGJvdW5kYXJ5KQ0KICAgIHdo aWxlIGlucHV0LnJlYWRsaW5lKCk6IHBhc3MgIyB0aHJvdyBhd2F5IGxpbmVz IGJlZm9yZSBmaXJzdCBib3VuZGFyeSBsaW5lDQogICAgaW5wdXQubmV4dCgp ICMgc2tpcCBvdmVyIGJvdW5kYXJ5DQogIA0KICAgIHBhcnQgPSAxDQogICAg Zm91bmRwbGFpbnRleHQ9MA0KICANCiAgICB3aGlsZSAxOg0KICAgICAgIyBy ZWFkIGhlYWRlciBmb3IgdGhpcyBwYXJ0DQogICAgICBzdWJtID0gbWltZXRv b2xzLk1lc3NhZ2UoaW5wdXQsMCkNCiAgICAgIHR5cGUgPSBzdWJtLmdldHR5 cGUoKQ0KDQogICAgICAjIElmIGl0J3MgdGhlIGZpcnN0IHBsYWluIHRleHQg cGFydCwgc3RvcmUgaXQgYXMgcGFydCBvZiB0aGUgZGVmYXVsdCBtc2cNCiAg ICAgICMgKHNvIHRoYXQgaXQncyBpbmRleGVkIGFuZCBzZWxmLWNvbnRhaW5l ZCkNCiAgICAgICMgT3RoZXJ3aXNlIGRlY29kZSB0aGUgcGFydCBhbmQgc3Rv cmUgaXQgaW4gYW4gYXBwcm9wcmlhdGVseSBuYW1lZCBmaWxlDQogICAgICBp ZiAobm90IGZvdW5kcGxhaW50ZXh0KSBhbmQgdHlwZSA9PSAndGV4dC9wbGFp bic6DQogICAgICAgIGZvdW5kcGxhaW50ZXh0PTENCiAgICAgICAgY29weShp bnB1dCxtYWlub3V0cHV0LCdcdCcpDQogICAgICBlbHNlOg0KICAgICAgICBu YW1lID0gc3VibS5nZXRwYXJhbSgnbmFtZScpDQogICAgICAgIGlmIG5vdCBu YW1lOiBuYW1lID0gInBhcnQiK3JlcHIocGFydCkNCiAgICAgICAgbmFtZSA9 ICclZC8lcycgJSAobWVzc2FnZV9udW1iZXIsbmFtZSkNCiAgICAgICAgYXR0 YWNobWVudHMuYXBwZW5kKCAodHlwZSxuYW1lKSApDQogICAgICAgIG91dHB1 dCA9IG9wZW4oZGVzdF9kaXIrJy8nK25hbWUsJ3cnKQ0KICAgICAgICBlbmNv ZGluZyA9IHN1Ym0uZ2V0ZW5jb2RpbmcoKQ0KICAgICAgICBpZiBlbmNvZGlu ZyA9PSAnYmFzZTY0JyBvciBlbmNvZGluZyA9PSAncXVvdGVkLXByaW50YWJs ZScgb3IgZW5jb2RpbmcgPT0gJ3V1ZW5jb2RlJzoNCiAgICAgICAgICBtaW1l dG9vbHMuZGVjb2RlKGlucHV0LG91dHB1dCxlbmNvZGluZykNCiAgICAgICAg ZWxzZTogIyBjb3B5IGlucHV0IHRvIG91dHB1dCB1c2luZyByZWFkbGluZSgp IC1tdWx0aWZpbGUgcmVxdWlyZXMgcmVhZGxpbmUoKSENCiAgICAgICAgICBj b3B5KGlucHV0LG91dHB1dCkNCiAgDQogICAgICAjIGdvIHRvIHRoZSBuZXh0 IHBhcnQNCiAgICAgIGlmIG5vdCBpbnB1dC5uZXh0KCk6IGJyZWFrDQogICAg ICBwYXJ0ID0gcGFydCArIDENCiAgDQogICAgIyB3cml0ZSBvdXQgaW5mb3Jt YXRpb24gZ2F0aGVyZWQgYWJvdXQgdGhlIGF0dGFjaG1lbnRzDQogICAgaWYg YXR0YWNobWVudHM6IG1haW5vdXRwdXQud3JpdGUoJ0F0dGFjaG1lbnRzOlxu JykNCiAgICBmb3IgdHlwZSxuYW1lIGluIGF0dGFjaG1lbnRzOg0KICAgICAg bWFpbm91dHB1dC53cml0ZSgnXHQlczolc1xuJyAlICh0eXBlLG5hbWUpKQ0K ICBtYWlub3V0cHV0LmNsb3NlKCkNCg0KDQojIEV4ZWN1dGlvbiBzdGFydHMg aGVyZQ0KdHJ5Og0KICBzdG9yZV9tZXNzYWdlKCkNCmV4Y2VwdDoNCiAgIyoq KipuZWVkIHRvIGltcHJvdmUgdGhpcywgb2J2aW91c2x5Li4uDQogIHByaW50 ICdzb21ldGhpbmcgd2VudCBob3JyaWJseSB3cm9uZyAtIHNlbmQgZW1haWwg dG8gamFtZXMgYml0Y2hpbmcgYWJvdXQgaXQnDQo= --0-872916835-921175844=:27847-- From bryner@uiuc.edu Fri Mar 12 23:53:02 1999 From: bryner@uiuc.edu (Brian Ryner) Date: Fri, 12 Mar 1999 17:53:02 -0600 Subject: [Mailman-Developers] Bounce suggestion Message-ID: <36E9A8DE.EDCE9055@uiuc.edu> Hi- I recently manually unsubscribed several dead addresses from a list, and got a bounce message to the admin address for every single one, telling me that the "You have been unsubscribed..." notice couldn't be delivered. Any way this could be disabled? Thanks. -Brian Ryner bryner@uiuc.edu From lindsey@ncsa.uiuc.edu Sat Mar 13 22:14:04 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Sat, 13 Mar 1999 16:14:04 -0600 (CST) Subject: [Mailman-Developers] Multiple admins in 'newlist?' Message-ID: <199903132214.QAA04113@ferret.ncsa.uiuc.edu> I was having a bear of a time figuring out how to get multiple admins specified when creating a new list. I may be missing something obvious here, but I ended up patching newlist to allow multiple addresses delimited by spaces (I know, it's not the right thing to do in case of quoted-string addresses, but until that's fixed throughout all of Mailman this will do). Undoubtedly the notification could be lumped together into the same SMTP transaction, but I don't see it being a problem given how often this will be run (and one could argue that admin notification for a new list should be sent individually to track failures in cases where the admin forwards without rewriting the envelope, since their mail is much more important to be able to debug than users (but I'm just saying that to cover my butt)). (NOTE: I'm not a Mailman developer, and this is not an official patch. Harald et al, should I be sending these to the list, or just to you folks?) Chris P.P.S. This is against the current CVS tree as of the timestamp on the diff. ---------------------------------------------------------------------- *** /home/staff/lindsey/cvs/mailman/bin/newlist Tue Mar 9 21:26:12 1999 --- bin/newlist Sat Mar 13 15:53:49 1999 *************** *** 29,34 **** --- 29,35 ---- Note that list-names are forced to lowercase. """ + from string import * import sys, os, string import time import paths # path hacking *************** *** 74,81 **** if len(argv) > 2: owner_mail = argv[2] else: ! owner_mail = raw_input( ! "Enter the email of the person running the list: ") if len(argv) > 3: list_pw = argv[3] else: --- 75,85 ---- if len(argv) > 2: owner_mail = argv[2] else: ! owner_mail = joinfields (split (raw_input( ! "Enter the email of the person running the list: "), ! ' '), '\n') ! ! if len(argv) > 3: list_pw = argv[3] else: *************** *** 132,138 **** 'requestaddr' : "%s-request@%s" % (list_name, newlist.host_name), 'hostname' : newlist.host_name, }) ! newlist.SendTextToUser(subject="Your new mailing list", recipient=owner_mail, sender='mailman-owner@%s' % newlist.host_name, text=text) --- 136,143 ---- 'requestaddr' : "%s-request@%s" % (list_name, newlist.host_name), 'hostname' : newlist.host_name, }) ! for admin in splitfields(owner_mail, '\n'): ! newlist.SendTextToUser(subject="Your new mailing list", recipient=owner_mail, sender='mailman-owner@%s' % newlist.host_name, text=text) From lindsey@ncsa.uiuc.edu Sat Mar 13 22:37:14 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Sat, 13 Mar 1999 16:37:14 -0600 (CST) Subject: [Mailman-Developers] Multiple admins in 'newlist?' In-Reply-To: <199903132214.QAA04113@ferret.ncsa.uiuc.edu> from "Christopher Lindsey" at Mar 13, 99 04:14:04 pm Message-ID: <199903132237.QAA04223@ferret.ncsa.uiuc.edu> Ack! This should be > text=text) > --- 136,143 ---- > 'requestaddr' : "%s-request@%s" % (list_name, newlist.host_name), > 'hostname' : newlist.host_name, > }) > ! for admin in splitfields(owner_mail, '\n'): > ! newlist.SendTextToUser(subject="Your new mailing list", > ! recipient=admin, > sender='mailman-owner@%s' % newlist.host_name, > text=text) Note the line that says 'recipient=admin'... Chris From sjmudd@bitmailer.net Sun Mar 14 14:19:06 1999 From: sjmudd@bitmailer.net (Simon J Mudd) Date: Sun, 14 Mar 1999 15:19:06 +0100 (MET) Subject: [Mailman-Developers] postfix and mailman (referring to previous posts about vmailer) Message-ID: I've just starting looking at mailman, and notice that it talks about vmailer. For various reasons vmailer had to have its name change, and is now called postfix. Consequently the information in the INSTALL file which talks about vmailer should be modified to talk about postfix and the commands mentioned should be changed too. Substitute vmailer with postfix and mkalias with postalias, the mail.cf configuration file for postfix is normally in /etc/postfix/ and further info about this MTA can be found in www.postfix.org I'm not subscribed to this list, so please CC: any replies to my email address above. Thanks and regards, Simon -- Simon J Mudd, Madrid SPAIN Tel: +34-91-408 4878 email: sjmudd@bitmailer.net [short messages - from radio hams only] ----> ea4els@ea4els.ampr.org From lindsey@ncsa.uiuc.edu Mon Mar 15 16:41:40 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Mon, 15 Mar 1999 10:41:40 -0600 (CST) Subject: [Mailman-Developers] Ignore my patches Message-ID: <199903151641.KAA15187@ferret.ncsa.uiuc.edu> . I think in the future I'll forward my patches and ideas to Barry and let him tell me what I'm missing... If only Python were more intuitive... :) The problem with the first patch (leaving the base URL empty) is that it breaks footers on every message sent out that refers to that URL. Although I think that if no URL is specified, the footers should use the default... The problem with my second patch (allowing multiple admins from newlist) is that the mailto: link breaks on all admin pages. Chris From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Mon Mar 15 16:49:31 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 15 Mar 1999 11:49:31 -0500 (EST) Subject: [Mailman-Developers] Ignore my patches References: <199903151641.KAA15187@ferret.ncsa.uiuc.edu> Message-ID: <14061.14875.226296.413558@anthem.cnri.reston.va.us> >>>>> "CL" == Christopher Lindsey writes: CL> . I think in the future I'll forward my patches and CL> ideas to Barry and let him tell me what I'm missing... If CL> only Python were more intuitive... :) Please understand that I only hack Mailman in my `copious spare time', which means I may not be very responsive at times. I generally try to batch up my Mailman list readings and deal with them at least once a week. Please do *not* send stuff directly to me though. First, it usually breaks my autofoldering (meaning there's a good chance the message will just get buried). Also, there are 4 other core maintainers, so they don't see the messages sent only to me. mailman-developers@python.org is still the best place to send stuff. Thanks, -Barry From petrilli@amber.org Mon Mar 15 17:46:01 1999 From: petrilli@amber.org (Christopher Petrilli) Date: Mon, 15 Mar 1999 12:46:01 -0500 Subject: [Mailman-Developers] Stand-alone Mailman Message-ID: <19990315124601.C13106@amber.org> Gang, So I've been tossing this idea over in my head... what do you think of using a derivitive of CGIHTTPServer.py to drive Mailman so that one could have an "out of hte box" solution... now not everyone WANTS this, but in the Zope world, we've found that for evaluation, the lower the entry-point requirement the better. Thoughts? Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright From bkc@murkworks.com Mon Mar 15 16:47:15 1999 From: bkc@murkworks.com (Brad Clements) Date: Mon, 15 Mar 1999 12:47:15 -0400 Subject: [Mailman-Developers] Stand-alone Mailman In-Reply-To: <19990315124601.C13106@amber.org> Message-ID: <199903151740.MAA20784@anvil.murkworks.com> On 15 Mar 99, at 12:46, Christopher Petrilli wrote: > So I've been tossing this idea over in my head... what do you think of > using a derivitive of CGIHTTPServer.py to drive Mailman so that one could > have an "out of hte box" solution... now not everyone WANTS this, but in > the Zope world, we've found that for evaluation, the lower the entry-point > requirement the better. > > Thoughts? Yes, I want this. In fact, I'm trying to get Mailman working on Win32, but running into a strange error importing MailList.py about "base not a class object" on MailList itself. Anyway, the eventual idea is to embed mailman in a win32 application (along with Zope, Confera and NotMail) and glue all these apps together in some way. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937 From sbolduc@uni-global.com Tue Mar 16 17:00:31 1999 From: sbolduc@uni-global.com (Sylvain Bolduc) Date: Tue, 16 Mar 1999 12:00:31 -0500 Subject: [Mailman-Developers] MailMan Bug since 1.0b7 Message-ID: <000801be6fce$8015a1c0$989b2fce@sly.uniconseil.com> This is a multi-part message in MIME format. ------=_NextPart_000_0009_01BE6FA4.973F99C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SSdtIGdldHRpbmcgdGhhdCBidWcgd2hlbiBpJ20gYXBwcm92aW5nIGEgbWVzc2FnZSBzaW5jZSBN YWlsTWFuIHYxLjAgYjcuDQoNCklzIHRoZXJlIGFueSB3YXkgdG8gZml4IHRoYXQgPw0KDQoNCmFk bWluOiBbLS0tLS0gTWFpbG1hbiBWZXJzaW9uOiAxLjBiOSAtLS0tLV0NCmFkbWluOiBbLS0tLS0g VHJhY2ViYWNrIC0tLS0tLV0NCmFkbWluOiBUcmFjZWJhY2sgKGlubmVybW9zdCBsYXN0KToNCmFk bWluOiAgIEZpbGUgIi9ob21lL21haWxtYW4vc2NyaXB0cy9kcml2ZXIiLCBsaW5lIDExMiwgaW4g cnVuX21haW4NCmFkbWluOiAgICAgbWFpbigpDQphZG1pbjogICBGaWxlICIvaG9tZS9tYWlsbWFu L01haWxtYW4vQ2dpL2FkbWluZGIucHkiLCBsaW5lIDEyNCwgaW4gbWFpbg0KYWRtaW46ICAgICBI YW5kbGVSZXF1ZXN0cyhkb2MpDQphZG1pbjogICBGaWxlICIvaG9tZS9tYWlsbWFuL01haWxtYW4v Q2dpL2FkbWluZGIucHkiLCBsaW5lIDIxNCwgaW4gSGFuZGxlUmVxdWVzdHMNCmFkbWluOiAgICAg bGlzdC5IYW5kbGVSZXF1ZXN0KHJlcXVlc3QsIHYpDQphZG1pbjogICBGaWxlICIvaG9tZS9tYWls bWFuL01haWxtYW4vTGlzdEFkbWluLnB5IiwgbGluZSAxMjIsIGluIEhhbmRsZVJlcXVlc3QNCmFk bWluOiAgICAgc2VsZi5IYW5kbGVQb3N0UmVxdWVzdChyZXF1ZXN0X2RhdGFbMjpdLCB2YWx1ZSwg Y29tbWVudCkNCmFkbWluOiAgIEZpbGUgIi9ob21lL21haWxtYW4vTWFpbG1hbi9MaXN0QWRtaW4u cHkiLCBsaW5lIDEzMSwgaW4gSGFuZGxlUG9zdFJlcXVlc3QNCmFkbWluOiAgICAgc2VsZi5Qb3N0 KG1zZywgMSkNCmFkbWluOiAgIEZpbGUgIi9ob21lL21haWxtYW4vTWFpbG1hbi9NYWlsTGlzdC5w eSIsIGxpbmUgMTE2MCwgaW4gUG9zdA0KYWRtaW46ICAgICBzZWxmLkRlbGl2ZXJUb0xpc3QobXNn LCByZWNpcGllbnRzLA0KYWRtaW46ICAgRmlsZSAiL2hvbWUvbWFpbG1hbi9NYWlsbWFuL0RlbGl2 ZXJlci5weSIsIGxpbmUgMTczLCBpbiBEZWxpdmVyVG9MaXN0DQphZG1pbjogICAgIHN0YXR1cyA9 IGNtZHByb2MuY2xvc2UoKQ0KYWRtaW46IElPRXJyb3I6ICgxMCwgJ05vIGNoaWxkIHByb2Nlc3Nl cycpDQoNCmFkbWluOiBbLS0tLS0gRW52aXJvbm1lbnQgVmFyaWFibGVzIC0tLS0tXQ0KYWRtaW46 ICBIVFRQX0FDQ0VQVF9FTkNPRElORzogZ3ppcA0KYWRtaW46ICBNQUlMOiAvdmFyL3Nwb29sL21h aWwvcm9vdA0KYWRtaW46ICBDT05URU5UX1RZUEU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJs ZW5jb2RlDQphZG1pbjogIFdOX1JPT1Q6IC93d3cvaHRkb2NzDQphZG1pbjogIEhUVFBfQUNDRVBU X0xBTkdVQUdFOiBlbg0KYWRtaW46ICBVUkxfU0NIRU1FOiBodHRwDQphZG1pbjogIEdBVEVXQVlf SU5URVJGQUNFOiBDR0kvMS4xDQphZG1pbjogIEhUVFBfQUNDRVBUOiBpbWFnZS9naWYsIGltYWdl L3gteGJpdG1hcCwgaW1hZ2UvanBlZywgaW1hZ2UvcGpwZWcsIGltYWdlL3BuZywgKi8qDQphZG1p bjogIF86IC93d3cvaHRkb2NzL21haWxtYW4vYWRtaW5kYg0KYWRtaW46ICBFTlY6IC9yb290Ly5i YXNocmMNCmFkbWluOiAgSE9TVFRZUEU6IGkzODYNCmFkbWluOiAgU0NSSVBUX0ZJTEVOQU1FOiAv d3d3L2h0ZG9jcy9tYWlsbWFuL2FkbWluZGINCmFkbWluOiAgUFlUSE9OUEFUSDogL2hvbWUvbWFp bG1hbg0KYWRtaW46ICBQQVRIOiAvdXNyL2JpbjovYmluOi91c3Ivc2Jpbjovc2JpbjovdXNyL1gx MVI2L2JpbnZ0MTAwOi91c3IvWDExUjYvYmluOi9yb290L2Jpbg0KYWRtaW46ICBVU0VSTkFNRTog cm9vdA0KYWRtaW46ICBET0NVTUVOVF9ST09UOiAvd3d3L2h0ZG9jcw0KYWRtaW46ICBISVNURklM RVNJWkU6IDEwMDANCmFkbWluOiAgSFRUUF9QT1NUX0ZJTEU6IC90bXAvd25fdG1wNjU1MzQvV05w b3N0LTM2ZWU4ZDI2LTY0M2QtMA0KYWRtaW46ICBXTl9ESVJfUEFUSDogL3d3dy9odGRvY3MvbWFp bG1hbg0KYWRtaW46ICBPU1RZUEU6IExpbnV4DQoNCg0KVGhhbmsgWW91IQ0KDQoNCg0KDQoNCg0K U3lsdmFpbiBCb2xkdWMNClVuaUdsb2JhbA0KMTgwMSwgTWNHaWxsIENvbGxlZ2UsIHN1aXRlIDEw MTANCk1vbnRyZWFsIChRdWViZWMpIEgzQSAyTjQNCg0KVGVsOiAoNTE0KSA4NDAtMTE1OCBwb3N0 ZSAzNTENCkZheDogKDUxNCkgODQwLTExNjYNCnNib2xkdWNAdW5pLWdsb2JhbC5jb20NCmh0dHA6 Ly93d3cudW5pLWdsb2JhbC5jb20gDQoNCg0K ------=_NextPart_000_0009_01BE6FA4.973F99C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD48 SEVBRD4NCjxNRVRBIGNvbnRlbnQ9JyJNU0hUTUwgNS4wMC4wOTEwLjEzMDkiJyBuYW1lPUdFTkVS QVRPUj4NCjxNRVRBIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIiBodHRw LWVxdWl2PUNvbnRlbnQtVHlwZT48L0hFQUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElW PjxTUEFOIGNsYXNzPTIwMDExNTIxNi0xNjAzMTk5OT48Rk9OVCBzaXplPTI+SSdtIGdldHRpbmcg dGhhdCBidWcgd2hlbiBpJ20gDQphcHByb3ZpbmcgYSBtZXNzYWdlIHNpbmNlIE1haWxNYW4gdjEu MCBiNy48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4g Y2xhc3M9MjAwMTE1MjE2LTE2MDMxOTk5PjxGT05UIHNpemU9Mj5JcyB0aGVyZSBhbnkgd2F5IHRv IGZpeCB0aGF0IA0KPzwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+YWRt aW46IFstLS0tLSBNYWlsbWFuIFZlcnNpb246IDEuMGI5IC0tLS0tXTxCUj5hZG1pbjogWy0tLS0t IA0KVHJhY2ViYWNrIC0tLS0tLV08QlI+YWRtaW46IFRyYWNlYmFjayAoaW5uZXJtb3N0IGxhc3Qp OjxCUj5hZG1pbjogICBGaWxlIA0KJnF1b3Q7L2hvbWUvbWFpbG1hbi9zY3JpcHRzL2RyaXZlciZx dW90OywgbGluZSAxMTIsIGluIHJ1bl9tYWluPEJSPmFkbWluOiAgICAgDQptYWluKCk8QlI+YWRt aW46ICAgRmlsZSAmcXVvdDsvaG9tZS9tYWlsbWFuL01haWxtYW4vQ2dpL2FkbWluZGIucHkmcXVv dDssIGxpbmUgDQoxMjQsIGluIG1haW48QlI+YWRtaW46ICAgICBIYW5kbGVSZXF1ZXN0cyhkb2Mp PEJSPmFkbWluOiAgIEZpbGUgDQomcXVvdDsvaG9tZS9tYWlsbWFuL01haWxtYW4vQ2dpL2FkbWlu ZGIucHkmcXVvdDssIGxpbmUgMjE0LCBpbiANCkhhbmRsZVJlcXVlc3RzPEJSPmFkbWluOiAgICAg bGlzdC5IYW5kbGVSZXF1ZXN0KHJlcXVlc3QsIHYpPEJSPmFkbWluOiAgIEZpbGUgDQomcXVvdDsv aG9tZS9tYWlsbWFuL01haWxtYW4vTGlzdEFkbWluLnB5JnF1b3Q7LCBsaW5lIDEyMiwgaW4gDQpI YW5kbGVSZXF1ZXN0PEJSPmFkbWluOiAgICAgc2VsZi5IYW5kbGVQb3N0UmVxdWVzdChyZXF1ZXN0 X2RhdGFbMjpdLCB2YWx1ZSwgDQpjb21tZW50KTxCUj5hZG1pbjogICBGaWxlICZxdW90Oy9ob21l L21haWxtYW4vTWFpbG1hbi9MaXN0QWRtaW4ucHkmcXVvdDssIGxpbmUgDQoxMzEsIGluIEhhbmRs ZVBvc3RSZXF1ZXN0PEJSPmFkbWluOiAgICAgc2VsZi5Qb3N0KG1zZywgMSk8QlI+YWRtaW46ICAg RmlsZSANCiZxdW90Oy9ob21lL21haWxtYW4vTWFpbG1hbi9NYWlsTGlzdC5weSZxdW90OywgbGlu ZSAxMTYwLCBpbiBQb3N0PEJSPmFkbWluOiAgICAgDQpzZWxmLkRlbGl2ZXJUb0xpc3QobXNnLCBy ZWNpcGllbnRzLDxCUj5hZG1pbjogICBGaWxlIA0KJnF1b3Q7L2hvbWUvbWFpbG1hbi9NYWlsbWFu L0RlbGl2ZXJlci5weSZxdW90OywgbGluZSAxNzMsIGluIA0KRGVsaXZlclRvTGlzdDxCUj5hZG1p bjogICAgIHN0YXR1cyA9IGNtZHByb2MuY2xvc2UoKTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPmFkbWluOiBJT0Vycm9yOiAoMTAsICdObyBjaGlsZCBwcm9jZXNzZXMnKTxCUj48L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5hZG1pbjogWy0tLS0tIEVudmlyb25tZW50IFZh cmlhYmxlcyAtLS0tLV08QlI+YWRtaW46ICANCkhUVFBfQUNDRVBUX0VOQ09ESU5HOiBnemlwPEJS PmFkbWluOiAgTUFJTDogL3Zhci9zcG9vbC9tYWlsL3Jvb3Q8QlI+YWRtaW46ICANCkNPTlRFTlRf VFlQRTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGU8QlI+YWRtaW46ICBXTl9ST09U OiANCi93d3cvaHRkb2NzPEJSPmFkbWluOiAgSFRUUF9BQ0NFUFRfTEFOR1VBR0U6IGVuPEJSPmFk bWluOiAgVVJMX1NDSEVNRTogDQpodHRwPEJSPmFkbWluOiAgR0FURVdBWV9JTlRFUkZBQ0U6IENH SS8xLjE8QlI+YWRtaW46ICBIVFRQX0FDQ0VQVDogaW1hZ2UvZ2lmLCANCmltYWdlL3gteGJpdG1h cCwgaW1hZ2UvanBlZywgaW1hZ2UvcGpwZWcsIGltYWdlL3BuZywgKi8qPEJSPmFkbWluOiAgXzog DQovd3d3L2h0ZG9jcy9tYWlsbWFuL2FkbWluZGI8QlI+YWRtaW46ICBFTlY6IC9yb290Ly5iYXNo cmM8QlI+YWRtaW46ICBIT1NUVFlQRTogDQppMzg2PEJSPmFkbWluOiAgU0NSSVBUX0ZJTEVOQU1F OiAvd3d3L2h0ZG9jcy9tYWlsbWFuL2FkbWluZGI8QlI+YWRtaW46ICANClBZVEhPTlBBVEg6IC9o b21lL21haWxtYW48QlI+YWRtaW46ICBQQVRIOiANCi91c3IvYmluOi9iaW46L3Vzci9zYmluOi9z YmluOi91c3IvWDExUjYvYmludnQxMDA6L3Vzci9YMTFSNi9iaW46L3Jvb3QvYmluPEJSPmFkbWlu OiANCiBVU0VSTkFNRTogcm9vdDxCUj5hZG1pbjogIERPQ1VNRU5UX1JPT1Q6IC93d3cvaHRkb2Nz PEJSPmFkbWluOiAgSElTVEZJTEVTSVpFOiANCjEwMDA8QlI+YWRtaW46ICBIVFRQX1BPU1RfRklM RTogDQovdG1wL3duX3RtcDY1NTM0L1dOcG9zdC0zNmVlOGQyNi02NDNkLTA8QlI+YWRtaW46ICBX Tl9ESVJfUEFUSDogDQovd3d3L2h0ZG9jcy9tYWlsbWFuPEJSPmFkbWluOiAgT1NUWVBFOiBMaW51 eDxCUj48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ PFNQQU4gY2xhc3M9MjAwMTE1MjE2LTE2MDMxOTk5PlRoYW5rIA0KWW91ITwvU1BBTj48QlI+PC9G T05UPjxTUEFOIA0KY2xhc3M9MjAwMTE1MjE2LTE2MDMxOTk5PjwvU1BBTj48L0RJVj48QlI+PEJS PjxCUj48QlI+DQo8UD48Rk9OVCBzaXplPTI+U3lsdmFpbiBCb2xkdWM8QlI+VW5pR2xvYmFsPEJS PjE4MDEsIE1jR2lsbCBDb2xsZWdlLCBzdWl0ZSANCjEwMTA8QlI+TW9udHJlYWwgKFF1ZWJlYykg SDNBIDJONDxCUj48QlI+VGVsOiAoNTE0KSA4NDAtMTE1OCBwb3N0ZSAzNTE8QlI+RmF4OiANCig1 MTQpIDg0MC0xMTY2PEJSPjxBIA0KaHJlZj0ibWFpbHRvOnNib2xkdWNAdW5pLWdsb2JhbC5jb20i PnNib2xkdWNAdW5pLWdsb2JhbC5jb208L0E+PEJSPjxBIA0KaHJlZj0iaHR0cDovL3d3dy51bmkt Z2xvYmFsLmNvbSIgdGFyZ2V0PV9ibGFuaz5odHRwOi8vd3d3LnVuaS1nbG9iYWwuY29tPC9BPiAN CjwvRk9OVD48L1A+DQo8RElWPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0009_01BE6FA4.973F99C0-- From roger@infomed.sld.cu Wed Mar 17 19:47:55 1999 From: roger@infomed.sld.cu (=?iso-8859-1?Q?Roger_Pe=F1a_Escobio?=) Date: Wed, 17 Mar 1999 14:47:55 -0500 Subject: [Mailman-Developers] Automatically update aliases again (fix alias wrapper) Message-ID: <01be70af$0dc27cb0$1c7001c4@ntserver.sld.cu> hello to mailman developers :-) i was posted few weeks ago two messages, both about the subject of this messages but nobody was interesting on that. Today while i was looking on "The Mailman TODO list" web page i look that this problems are unsolved yet , if anybody are interesting in how can fix it , this is my e-mail, roger@infomed.sld.cu , please e-mailme . Also i have a c programs for edit the aliases file when the admin remove a list. Good luck Roger From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Mar 20 05:07:13 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 20 Mar 1999 00:07:13 -0500 (EST) Subject: [Mailman-Developers] Jitterbug for Mailman Message-ID: <14067.11521.211373.182229@anthem.cnri.reston.va.us> Hey folks, sorry I've been so unresponsive lately. Anyway, I have installed Jitterbug on python.org for managing bug reports on Mailman. Hopefully this will work better than trying to use my inbox :-). If Jitterbug works out well, I plan on creating interfaces for other python.org projects. To check out the Jitterbug reporting interface for Mailman, please see http://www.python.org/mailman-bugs Let me know if you have any problems. -Barry From bruce@hams.com Sat Mar 20 20:28:09 1999 From: bruce@hams.com (bruce@hams.com) Date: 20 Mar 1999 20:28:09 -0000 Subject: [Mailman-Developers] Submission for Mailman's "contrib" directory Message-ID: <19990320202809.12043.qmail@hams.com> Hi, The following script interfaces a qmail virtual domain to Mailman without the use of any aliases. That makes it a lot easier to add new lists. Could you place it in a "contrib" directory in the Mailman distribution? Thanks Bruce Perens --- cut here --- #! /usr/bin/python # Configuration variables - Change these for your site if necessary. MailmanHome = "/home/mailman"; # Mailman home directory. MailmanOwner = "postmaster@localhost"; # Postmaster and abuse mail recepient. # End of configuration variables. # qmail-to-mailman.py # # Interface mailman to a qmail virtual domain. Does not require the creation # of _any_ aliases to connect lists to your mail system. # # Bruce Perens, bruce@perens.com, March 1999. # This is free software under the GNU General Public License. # # This script is meant to be called from ~mailman/.qmail-default . It catches # all mail to a virtual domain, in my case "lists.hams.com". It looks at the # recepient for each mail message and decides if the mail is addressed to a # valid list or not, and bounces the message with a helpful suggestion if it's # not addressed to a list. It decides if it is a posting, a list command, or # mail to the list administrator, by checking for the -admin, -owner, and # -request addresses. It will recognize a list as soon as the list is created, # there is no need to add _any_ aliases for any list. It recognizes mail to # postmaster, mailman-owner, abuse, mailer-daemon, root, and owner, and # routes those mails to MailmanOwner as defined in the configuration # variables, above. # # INSTALLATION: # # Install this file as ~mailman/qmail-to-mailman.py # # To configure a virtual domain to connect to mailman, create these files: # # ~mailman/.qmail-default # |/usr/bin/python /home/mailman/mail-in.py # # /var/qmail/control/virtualdomains: # DOMAIN.COM:mailman # # Replace DOMAIN.COM above with the name of the domain to be connected to # Mailman. Note that _all_ mail to that domain will go to Mailman, so you # don't want to put the name of your main domain here. In my case, I created # lists.hams.com for Mailman, and I use hams.com as my regular domain. # # After you edit /var/qmail/control/virtualdomains, kill and restart qmail. # import sys, os, re, string; def main(): os.nice(5); # Handle mailing lists at non-interactive priority. os.chdir(MailmanHome + "/lists"); try: local = os.environ["LOCAL"]; except: # This might happen if we're not using qmail. sys.stderr.write("LOCAL not set in environment?\n"); sys.exit(100); local = re.sub("^mailman-","",local); names = ("root", "postmaster", "mailer-daemon", "mailman-owner", "owner", "abuse"); for i in names: if i == local: os.execv("/var/qmail/bin/qmail-inject" ,("/var/qmail/bin/qmail-inject", MailmanOwner)); sys.exit(0); type = "post"; types = (("-admin$", "mailowner"), ("-owner$", "mailowner"), ("-request$", "mailcmd")); for i in types: if re.search(i[0],local): type = i[1]; local = re.sub(i[0],"",local); if os.path.exists(local): os.execv(MailmanHome + "/mail/wrapper" ,(MailmanHome + "/mail/wrapper", type, local)); else: bounce(); sys.exit(111); def bounce(): bounce_message = """\ TO ACCESS THE MAILING LIST SYSTEM: Start your web browser on http://%s/ That web page will help you subscribe or unsubscribe, and will give you directions on how to post to each mailing list.\n"""; sys.stderr.write(bounce_message % (os.environ["HOST"])); sys.exit(100); try: sys.exit(main()); except SystemExit, argument: sys.exit(argument); except Exception, argument: info = sys.exc_info(); trace = info[2]; sys.stderr.write("%s %s\n" % (sys.exc_type, argument)); sys.stderr.write("Line %d\n" % (trace.tb_lineno)); sys.exit(111); # Soft failure, try again later. --- cut here --- From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Mar 20 22:27:58 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 20 Mar 1999 17:27:58 -0500 (EST) Subject: [Mailman-Developers] Submission for Mailman's "contrib" directory References: <19990320202809.12043.qmail@hams.com> Message-ID: <14068.8430.433170.304453@anthem.cnri.reston.va.us> bruce> The following script interfaces a qmail virtual domain to bruce> Mailman without the use of any aliases. That makes it a lot bruce> easier to add new lists. Could you place it in a "contrib" bruce> directory in the Mailman distribution? Thanks Bruce, I've added this to the (new) contrib directory. I made some stylistic changes: - "#! /usr/bin/env python" is the recommended #! for Python - Removed all those unnecessary semi-colons at the ends of the lines (I know, a hard habit to break :-) - Reformated for 4-space and untabified I would also suggest rewriting the big comment near the top of the file as a docstring, but then you'd have to move this to before the setting of the config variables, and I wasn't sure if you wanted to do this. -Barry From julian7@kva.hu Sun Mar 21 09:25:13 1999 From: julian7@kva.hu (Balazs Nagy) Date: Sun, 21 Mar 1999 10:25:13 +0100 (CET) Subject: [Mailman-Developers] Submission for Mailman's "contrib" directory In-Reply-To: <19990320202809.12043.qmail@hams.com> Message-ID: On 20 Mar 1999 bruce@hams.com wrote: > Hi, > > The following script interfaces a qmail virtual domain to Mailman without the > use of any aliases. That makes it a lot easier to add new lists. Could you > place it in a "contrib" directory in the Mailman distribution? I think it could be combined with an aliasing (put +listname:.... line to /var/qmail/users/assign) command. This way it could be in src/ and not contrib/. I'll try it at home. -- Regards: Kevin (Balazs) From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Mon Mar 22 23:34:27 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 22 Mar 1999 18:34:27 -0500 (EST) Subject: [Mailman-Developers] New Mailing List Message-ID: <14070.54147.17042.254891@anthem.cnri.reston.va.us> There have been a number of requests to start an announce-only list for Mailman. I've now done this http://www.python.org/mailman/listinfo/mailman-announce The function of the lists are now better explained on the www.list.org site. Let me know if you have any problems. -Barry From roger@infomed.sld.cu Tue Mar 23 02:27:13 1999 From: roger@infomed.sld.cu (=?iso-8859-1?Q?Roger_Pe=F1a_Escobio?=) Date: Mon, 22 Mar 1999 21:27:13 -0500 Subject: [Mailman-Developers] patch to fix the alias-wrapper.c Message-ID: <01be74d4$a9981e00$1c7001c4@ntserver.sld.cu> This is a multi-part message in MIME format. ------=_NextPart_000_008C_01BE74AA.C0C21600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by infomed.sld.cu id VAA09237 Hi... few days ago we discuses about aliases file, well... this my patch of mailman-1.0b9 to fix alias-wrapper, also fix newlist. this patch also changes the rmlist file, including an rmaliases programs (rmalias-wrapper.c, this programs edit the aliases file when you eliminat= e a list ). Of course, you are free to apply the patch or not, but if will do it look inside first, see what it will do and if you agree, =A1=A1 great !!! lets= do it :-) this line are for the brave souls :-) who like apply the patch 1-move the patch to the source dir , for example , /usr/local/src if mail= man source is in /usr/local/src/mailman-1.0b9 2-rename the alias-wrapper.c source to addalias-wrapper.c , it is, mv ./mailman-1.0b9/src/alias-wrapper.c ./mailman-1.0b9/src/addalias-wrapper.= c 3-exec the command : patch -p0 < mailman-1.0b9-patch-r.patch 4- if you dont get any estrange line or question every thing was fine, if not ...... check if you really have the mailman-1.0b9 version or if you a= re in the correct dir. 5- everything is ok ? great, now put the rmalias-wrapper.c into the src d= ir, it is ./mailman-1.0b9/src/ 6-now you have to check some "little" thing, first of all , my aliases fi= le for mailman is /etc/mailman/aliases, you can change that editing the addalias-wrapper.c and rmalias-wrapper.c, is really simple, take a look, = I dont know if mailman user can edit the /etc/aliases file ( I think he can= t) but in the other way I prefer to have two aliases file one for system ali= as and another for mailman alias, if I convince you about two alias, you wil= l have to change your sendmail.cf and create the /etc/mailman/ dir : 6.1-creating the /etc/mailman/ dir : #mkdir /etc/mailman ; chgrp mail= man /etc/mailman ; chmod 755 /etc/mailman 6.2-changing the sendmail.cf: do this really depend on your OS , in RedHat you have to do this: cd /usr/lib/sendmail-cf/cf/ edit your *.mc , if you never do this before ( if you have th= e sendmail.cf from distribution) your *.mc is redhat.mc, put this line define(`ALIAS_FILE',`/etc/aliases,/etc/mailman/aliases') exec the command : #m4 ../m4/cf.m4 redhat.mc > myhost.cf make a copy of your old sendmail.cf : #cp /etc/sendmail.cf /etc/sendmail.cf.old copy the new *.cf file to /etc/sendmail.cf: #cp myhost.cf /etc/sendmail.cf restart sendmail: #/etc/rc.d/init.d/sendmail restart and thats all !!!! are you still with me ???? :-) 6.3-check if you have /var/tmp dir , addalias-wrapper.c and rmalias-wrapper.c need it temporally, redhat already have but other OS do= nt 7-the only thing that rest is run autoconf INSIDE mailman source , it is = : #cd /usr/local/mailman-1.0b9 ; autoconf that is for make configure from configure.in 8-well, if you do all above you really have my mailman ready to install, = so install it :-)) a final words.... maybe you think something like this "should I do all th= is thing instead of edit the aliases file manually?? are you crazy!!!" but = you only need to do this only once, and then when you create or eliminate a l= ist all will be do automatically. well a hope that this patch help someone . Roger ------=_NextPart_000_008C_01BE74AA.C0C21600 Content-Type: application/octet-stream; name="rmalias-wrapper.c" Content-Disposition: attachment; filename="rmalias-wrapper.c" Content-Transfer-Encoding: base64 LyogYWxpYXMtd3JhcHBlci5jIC0tLSB3cmFwcGVyIHRvIGFsbG93IHRoZSBtYWlsbWFuIHVzZXIg dG8gbW9kaWZ5IHRoZSBhbGlhc2VzCiAqIGRhdGFiYXNlLgogKgogKiBDb3B5cmlnaHQgKEMpIDE5 OTggYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLgogKgogKiBUaGlzIHByb2dy YW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCiAqIG1v ZGlmeSBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNl CiAqIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIg dmVyc2lvbiAyCiAqIG9mIHRoZSBMaWNlbnNlLCBvciAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRl ciB2ZXJzaW9uLgogKiAKICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3Bl IHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCiAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0 aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCiAqIE1FUkNIQU5UQUJJTElUWSBvciBG SVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKICogR05VIEdlbmVyYWwg UHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KICogCiAqIFlvdSBzaG91bGQgaGF2ZSBy ZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCiAqIGFsb25n IHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlIAog KiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UgLSBTdWl0ZSAzMzAsIEJvc3Rvbiwg TUEgMDIxMTEtMTMwNywgVVNBLgogKi8KCiNpbmNsdWRlIDxzdGRpby5oPgojaW5jbHVkZSA8c3Rk bGliLmg+CgovKiBwYXNzZWQgaW4gZnJvbSBjb25maWd1cmUgc2NyaXB0ICovCmNvbnN0IGludCAg TEVHQUxfUEFSRU5UX1VJRCA9IEFMSUFTX1VJRDsgICAvKiBtYWlsbWFuJ3MgVUlEICovCmNvbnN0 IGludCAgTEVHQUxfUEFSRU5UX0dJRCA9IEFMSUFTX0dJRDsgICAgLyogbWFpbCdzIEdJRCAqLwoK CmNvbnN0IGNoYXIqIFNFTkRNQUlMX0NNRCA9ICIvdXNyL3NiaW4vc2VuZG1haWwiOwpjb25zdCBj aGFyKiBBTElBU19GSUxFICAgPSAiL2V0Yy9tYWlsbWFuL2FsaWFzZXMiOwpjb25zdCBjaGFyKiBB TElBU19GSUxFX1RNUCAgID0gIi92YXIvdG1wL21haWxtYW5BbGlhc2VzIjsKY29uc3QgY2hhciog V1JBUFBFUiAgICAgID0gIi9ob21lL21haWxtYW4vbWFpbC93cmFwcGVyIjsKCmNoYXIgbGluZWEx WzEwMjRdOyAKY2hhciBsaW5lYVsxMDI0XTsKaW50IGk9MDsKCi8qIAoqKiBpcyB0aGUgcGFyZW50 IHByb2Nlc3MgYWxsb3dlZCB0byBjYWxsIHVzPwoqLwppbnQKTGVnYWxDYWxsZXIoKSAKewoJLyog Y29tcGFyZSB0byBvdXIgcGFyZW50J3MgdWlkICovCglpZiAoTEVHQUxfUEFSRU5UX1VJRCAhPSBn ZXR1aWQoKSkgewoJCXByaW50ZigiR09UIFVJRCAlZC5cbiIsIGdldHVpZCgpKTsKCQlyZXR1cm4g MDsKCX0KCWlmIChMRUdBTF9QQVJFTlRfR0lEICE9IGdldGdpZCgpKSB7CgkJcHJpbnRmKCJHT1Qg R0lEICVkLlxuIiwgZ2V0Z2lkKCkpOwoJCXJldHVybiAwOwoJfQoJcmV0dXJuIDE7Cn0KCgp2b2lk ClJtTGlzdEFsaWFzZXMoY2hhciAqbGlzdCkKewoJRklMRSAqZjsKCUZJTEUgKmFsaWFzdG1wOwoJ aW50ICBlcnIgPSAwOwoJCglzcHJpbnRmKGxpbmVhMSwiIyMgJXMgbWFpbGluZyBsaXN0OiIsbGlz dCk7CglmPWZvcGVuKEFMSUFTX0ZJTEUgLCJyIik7Cglmc2VlayhmLDAsU0VFS19TRVQpOwoJaWYg KGYgPT0gTlVMTCkgewoJCWVyciA9IDE7CgkJZiA9IHN0ZGVycjsKCQlmcHJpbnRmKGYsICJcblxu KioqKioqKioqKipFUlJPUiEhISEqKioqKioqKioqKlxuIik7CgkJZnByaW50ZihmLCAiQ291bGQg bm90IHdyaXRlIHRvIHRoZSBhbGlhc2VzIGZpbGUuXG4iKTsKCQlmcHJpbnRmKGYsICJQbGVhc2Ug YmVjb21lIHJvb3QsIGFkZCB0aGUgbGluZXMgYmVsb3cgdG9cbiIpOwoJCWZwcmludGYoZiwgInRo YXQgZmlsZSwgYW5kIHRoZW4gcnVuIHRoZSBjb21tYW5kOlxuIik7CgkJZnByaW50ZihmLCAiJXMg LWJpXG4iLCBTRU5ETUFJTF9DTUQpOwoJICAgIH1lbHNlewoJICAgIAlwcmludGYoIkVkaXRpbmcg YWxpYXMgZGF0YWJhc2UuLi4uXG4iICk7CgkJYWxpYXN0bXA9Zm9wZW4oQUxJQVNfRklMRV9UTVAs InciKTsKCQlpZiAoYWxpYXN0bXAgPT0gTlVMTCkgewoJCSAgICBwcmludGYoIlxuXG4qKioqKioq KioqKkVSUk9SISEhISoqKioqKioqKioqXG4iKTsKCQkgICAgcHJpbnRmKCJDb3VsZCBub3Qgd3Jp dGUgdG8gdGhlIHRtcCBhbGlhc2VzIGZpbGUuXG4iKTsKCQkgICAgZXJyID0gMTsKCQkgICAgYWxp YXN0bXAgPSBzdGRlcnI7CgkJIH0gICAKCQl3aGlsZSggKCBmZ2V0cyhsaW5lYSwxMDI0LGYpKSAh PSBOVUxMICl7CgkJICAgIGlmICggIXN0cm5jbXAobGluZWEsIGxpbmVhMSwgc3RybGVuKGxpbmVh MSkpICl7CgkJCXByaW50ZigiZWxpbWluYW5kbyBsYSBsaXN0YS4uLlxuIiApOwoJCQlmb3IoaT0x OyBpPD0xMDsgaSsrKXsKCQkJICAgIGZnZXRzKGxpbmVhLDEwMjQsZik7CgkJCSAgICB9OwoJCSAg ICAgIH0KCQkgICAgZnByaW50ZihhbGlhc3RtcCxsaW5lYSk7CgkJIH07CgkJZmNsb3NlKGFsaWFz dG1wKTsKCQlmY2xvc2UoZik7CgkJc3lzdGVtKCJjcCAvdmFyL3RtcC9tYWlsbWFuQWxpYXNlcyAv ZXRjL21haWxtYW4vYWxpYXNlcyIpOyAKCQlwcmludGYoIlJlYnVpbGRpbmcgYWxpYXMgZGF0YWJh c2UuLi5cbiIpOwoJCWV4ZWNscChTRU5ETUFJTF9DTUQsIFNFTkRNQUlMX0NNRCwgIi1iaSIsIE5V TEwpOwoJICAgIH0gICAgCn0KCgppbnQKbWFpbihpbnQgYXJnYywgY2hhciAqKmFyZ3YsIGNoYXIg KiplbnYpIAp7CgljaGFyICAqY29tbWFuZDsKCWludCAgIGk7CgoJaWYgKGFyZ2MgIT0gMikgewoJ CXByaW50ZigiVXNhZ2U6ICVzIFtsaXN0LW5hbWVdXG4iLCBhcmd2WzBdKTsKCQlleGl0KDApOwoJ fQoJaWYgKExlZ2FsQ2FsbGVyKCkpIHsKCQlzZXR1aWQoZ2V0ZXVpZCgpKTsKCQlSbUxpc3RBbGlh c2VzKGFyZ3ZbMV0pOwoJfQoJZWxzZSB7CgkJcHJpbnRmKCJJbGxlZ2FsIGNhbGxlciFcbiIpOwoJ CXJldHVybiAxOwoJfQoJcmV0dXJuIDA7Cn0KCgoMCi8qCiAqIExvY2FsIFZhcmlhYmxlczoKICog Yy1maWxlLXN0eWxlOiAicHl0aG9uIgogKiBFbmQ6CiAqLwo= ------=_NextPart_000_008C_01BE74AA.C0C21600 Content-Type: application/octet-stream; name="mailman-1.0b9-patch-r.patch" Content-Disposition: attachment; filename="mailman-1.0b9-patch-r.patch" Content-Transfer-Encoding: base64 ZGlmZiAtTmF1ciAuL21haWxtYW4tMS4wYjkvTWFrZWZpbGUuaW4gLi9tYWlsbWFuLTEuMGI5cC9N YWtlZmlsZS5pbgotLS0gLi9tYWlsbWFuLTEuMGI5L01ha2VmaWxlLmluCVRodSBKYW4gMTQgMjM6 MjA6NTcgMTk5OQorKysgLi9tYWlsbWFuLTEuMGI5cC9NYWtlZmlsZS5pbglTdW4gTWFyIDIxIDIy OjQxOjQ3IDE5OTkKQEAgLTM1LDYgKzM1LDcgQEAKIERFRlM9CQlAREVGU0AKIAogTUFJTE1BTl9V SUQ9CUBNQUlMTUFOX1VJREAKK01BSUxNQU5fR0lEPQlATUFJTE1BTl9HSURACiAKICMgQ3VzdG9t aXphYmxlIGJ1dCBub3Qgc2V0IGJ5IGNvbmZpZ3VyZQogCkBAIC03OCw2ICs3OSw3IEBACiAJICAg IGlmIHRlc3QgISAtZCAkJGRpcjsgdGhlbiBcCiAJCWVjaG8gIkNyZWF0aW5nIGRpcmVjdG9yeSBo aWVyYXJjaHkgJCRkaXIiOyBcCiAJCS4vbWtpbnN0YWxsZGlycyAkJGRpcjsgXAorCQljaG93biAk KE1BSUxNQU5fVUlEKTokKE1BSUxNQU5fR0lEKSAkJGRpcjsgXAogCQljaG1vZCAkKERJUk1PREUp ICQkZGlyOyBcCiAJCWNobW9kIGcrcyAkJGRpcjsgXAogCSAgICBlbHNlIHRydWU7IFwKQEAgLTkx LDYgKzkzLDcgQEAKIAkgICAgaWYgdGVzdCAhIC1kICQkZGlyOyB0aGVuIFwKIAkJZWNobyAiQ3Jl YXRpbmcgZGlyZWN0b3J5IGhpZXJhcmNoeSAkJGRpciI7IFwKIAkJLi9ta2luc3RhbGxkaXJzICQk ZGlyOyBcCisJCWNob3duICQoTUFJTE1BTl9VSUQpOiQoTUFJTE1BTl9HSUQpICQkZGlyOyBcCiAJ CWNobW9kICQoRElSTU9ERSkgJCRkaXI7IFwKIAkJY2htb2QgZytzICQkZGlyOyBcCiAJICAgIGVs c2UgdHJ1ZTsgXApAQCAtMTAxLDkgKzEwNCwxMCBAQAogCSAgICAoY2QgJCRkOyAkKE1BS0UpIGlu c3RhbGwpOyBcCiAJZG9uZQogCSQoUFlUSE9OKSAtYyAnaW1wb3J0IGNvbXBpbGVhbGw7IGNvbXBp bGVhbGwuY29tcGlsZV9kaXIoIiQocHJlZml4KSIpJworCWNob3duIC1SICQoTUFJTE1BTl9VSUQp OiQoTUFJTE1BTl9HSUQpICQocHJlZml4KS8qCiAJQGVjaG8gIioqKioqIgogCUBlY2hvICIqKioq KiBJZiB5b3UgYXJlIGluc3RhbGxpbmcgb3ZlciBhbiBvbGQgaW5zdGFsbGF0aW9uLCBwbGVhc2Ui Ci0JQGVjaG8gIioqKioqIHJ1biBcIm1ha2UgdXBkYXRlXCIuICBTZWUgdGhlIFVQR1JBRElORyBm aWxlIGZvciBkZXRhaWxzLiIKKwlAZWNobyAiKioqKiogcnVuIFwibWFrZSB1cGRhdGVcIiBsaWtl IG1haWxtYW4gdXNlci4gIFNlZSB0aGUgVVBHUkFESU5HIGZpbGUgZm9yIGRldGFpbHMuIgogCUBl Y2hvICIqKioqKiIKIAogI2ZpbmlzaDoKZGlmZiAtTmF1ciAuL21haWxtYW4tMS4wYjkvYmluL25l d2xpc3QgLi9tYWlsbWFuLTEuMGI5cC9iaW4vbmV3bGlzdAotLS0gLi9tYWlsbWFuLTEuMGI5L2Jp bi9uZXdsaXN0CVNhdCBGZWIgMjcgMTM6MDU6NDMgMTk5OQorKysgLi9tYWlsbWFuLTEuMGI5cC9i aW4vbmV3bGlzdAlNb24gTWFyICAxIDIxOjIzOjEyIDE5OTkKQEAgLTkyLDcgKzkyLDcgQEAKICAg ICBmaW5hbGx5OgogICAgICAgICBvcy51bWFzayhvbGRtYXNrKQogCi0gICAgIyMjb3Muc3lzdGVt KCclcyAlcycgJSAoQUREQUxJQVNFU19DTUQsIGxpc3RfbmFtZSkpCisgICAgCiAgICAgcHJpbnQg JycnCiBFbnRyeSBmb3IgYWxpYXNlcyBmaWxlOgogCkBAIC0xMTgsNiArMTE4LDcgQEAKIAlwcmlu dCAoIkhpdCBlbnRlciB0byBjb250aW51ZSB3aXRoICVzIG93bmVyIG5vdGlmaWNhdGlvbi4uLiIK IAkgICAgICAgJSBsaXN0X25hbWUpLAogCXN5cy5zdGRpbi5yZWFkbGluZSgpCisgICAgb3Muc3lz dGVtKCclcyAlcycgJSAoQUREQUxJQVNFU19DTUQsIGxpc3RfbmFtZSkpCiAgICAgc2VuZG5vdGlj ZShuZXdsaXN0LCBsaXN0X25hbWUsIG93bmVyX21haWwsIGxpc3RfcHcpCiAgICAgbmV3bGlzdC5V bmxvY2soKQogCmRpZmYgLU5hdXIgLi9tYWlsbWFuLTEuMGI5L2Jpbi9ybWxpc3QgLi9tYWlsbWFu LTEuMGI5cC9iaW4vcm1saXN0Ci0tLSAuL21haWxtYW4tMS4wYjkvYmluL3JtbGlzdAlNb24gRmVi ICAxIDE2OjU3OjU4IDE5OTkKKysrIC4vbWFpbG1hbi0xLjBiOXAvYmluL3JtbGlzdAlTdW4gTWFy IDIxIDIyOjA1OjI0IDE5OTkKQEAgLTk1LDYgKzk1LDcgQEAKICAgICBmb3IgZGlydG1wbCwgbXNn IGluIFJFTU9WQUJMRVM6CiAgICAgICAgIGRpciA9IG9zLnBhdGguam9pbihwYXRocy5wcmVmaXgs IGRpcnRtcGwgJSBsaXN0bmFtZSkKICAgICAgICAgcmVtb3ZlX2l0KGxpc3RuYW1lLCBkaXIsIG1z ZykKKwlvcy5zeXN0ZW0ocm1hbGlhc2VzIGxpc3RuYW1lKQogCiAMCiBpZiBfX25hbWVfXyA9PSAn X19tYWluX18nOgpkaWZmIC1OYXVyIC4vbWFpbG1hbi0xLjBiOS9jb25maWd1cmUuaW4gLi9tYWls bWFuLTEuMGI5cC9jb25maWd1cmUuaW4KLS0tIC4vbWFpbG1hbi0xLjBiOS9jb25maWd1cmUuaW4J U2F0IEZlYiAyNyAxOToyNDoyMSAxOTk5CisrKyAuL21haWxtYW4tMS4wYjlwL2NvbmZpZ3VyZS5p bglGcmkgTWFyICA1IDE2OjI3OjUzIDE5OTkKQEAgLTE3LDcgKzE3LDcgQEAKIGRubCBQcm9jZXNz IHRoaXMgZmlsZSB3aXRoIGF1dG9jb25mIHRvIHByb2R1Y2UgYSBjb25maWd1cmUgc2NyaXB0Lgog QUNfUkVWSVNJT04oJFJldmlzaW9uOiAxLjMxICQpCiBBQ19QUkVSRVEoMi4wKQotQUNfSU5JVChz cmMvYWxpYXMtd3JhcHBlci5jKQorQUNfSU5JVChzcmMvYWRkYWxpYXMtd3JhcHBlci5jKQogCiAK ICMgL2hvbWUvbWFpbG1hbiBpcyB0aGUgZGVmYXVsdCBpbnN0YWxsYXRpb24gZGlyZWN0b3J5CkBA IC0xNDgsMTAgKzE0OCwxMCBAQAogZm9yIHVzZXIgaW4gc3RyaW5nLnNwbGl0KCIkMiIpOgogICAg IHRyeToKICAgICAgICAgdHJ5OgotCSAgICB1aWQgPSBwd2QuZ2V0cHd1aWQoaW50KHVzZXIpKVsw XQorCSAgICB1aWQgPSBwd2QuZ2V0cHd1aWQoaW50KHVzZXIpKVsyXQogCSAgICBicmVhawogCWV4 Y2VwdCBWYWx1ZUVycm9yOgotCSAgICB1aWQgPSBwd2QuZ2V0cHduYW0odXNlcilbMF0KKwkgICAg dWlkID0gcHdkLmdldHB3bmFtKHVzZXIpWzJdCiAJICAgIGJyZWFrCiAgICAgZXhjZXB0IEtleUVy cm9yOgogICAgICAgICB1aWQgPSAnJwpAQCAtMjkyLDkgKzI5MiwxMCBAQAogKioqKiogZG9jdW1l bnRhdGlvbiwgYW5kIHRoZSBJTlNUQUxMIGZpbGUgZm9yIGRldGFpbHNdKQogZmkKIAotCi0jTU1f RklORF9VU0VSX0lEKEFMSUFTX1VJRCwgbWFpbG1hbiwgYWxpYXNfd3JhcHBlcikKLSNNTV9GSU5E X0dST1VQX0lEKEFMSUFTX0dJRCwgbWFpbCwgYWxpYXNfd3JhcHBlcikKK0FDX01TR19DSEVDS0lO Ryhmb3IgYWxpYXMgd3JhcHBlciBVSUQpCitNTV9GSU5EX1VTRVJfSUQoQUxJQVNfVUlELCBtYWls bWFuLCBhbGlhc193cmFwcGVyKQorQUNfTVNHX0NIRUNLSU5HKGZvciBhbGlhcyB3cmFwcGVyIEdJ RCkKK01NX0ZJTkRfR1JPVVBfSUQoQUxJQVNfR0lELCBtYWlsbWFuLCBhbGlhc193cmFwcGVyKQog CiAjIENoZWNrIGZvciBDR0kgZXh0ZW5zaW9ucywgcmVxdWlyZWQgYnkgc29tZSBXZWIgc2VydmVy cwogQUNfU1VCU1QoQ0dJRVhUKQpkaWZmIC1OYXVyIC4vbWFpbG1hbi0xLjBiOS9taXNjL01ha2Vm aWxlLmluIC4vbWFpbG1hbi0xLjBiOXAvbWlzYy9NYWtlZmlsZS5pbgotLS0gLi9tYWlsbWFuLTEu MGI5L21pc2MvTWFrZWZpbGUuaW4JVGh1IEphbiAxNCAyMzoyMjowMSAxOTk5CisrKyAuL21haWxt YW4tMS4wYjlwL21pc2MvTWFrZWZpbGUuaW4JU3VuIE1hciAyMSAyMzoxNDoxNiAxOTk5CkBAIC02 NSw4ICs2NSw4IEBACiAJICAgIGRpcj0kKHByZWZpeCkvJCRkOyBcCiAJICAgICQoSU5TVEFMTCkg LW0gJChGSUxFTU9ERSkgcGF0aHMucHkgJCRkaXI7IFwKIAlkb25lCi0JJChJTlNUQUxMKSAtbSAk KERBVEFNT0RFKSBwZW5kaW5nX3N1YnNjcmlwdGlvbnMuZGIgJChwcmVmaXgpL2RhdGEKLQorCSQo SU5TVEFMTCkgLW0gJChEQVRBTU9ERSkgcGVuZGluZ19zdWJzY3JpcHRpb25zLmRiICQoREFUQURJ UikKKwkKIGZpbmlzaDoKIAogY2xlYW46CmRpZmYgLU5hdXIgLi9tYWlsbWFuLTEuMGI5L3NyYy9N YWtlZmlsZS5pbiAuL21haWxtYW4tMS4wYjlwL3NyYy9NYWtlZmlsZS5pbgotLS0gLi9tYWlsbWFu LTEuMGI5L3NyYy9NYWtlZmlsZS5pbglTYXQgRmViIDI3IDE5OjMwOjIxIDE5OTkKKysrIC4vbWFp bG1hbi0xLjBiOXAvc3JjL01ha2VmaWxlLmluCVN1biBNYXIgMjEgMjM6NTE6NDIgMTk5OQpAQCAt MzYsMTUgKzM2LDE2IEBACiAjIFVJRHMgYW5kIEdJRHMKIE1BSUxfR0lEPSAgICAgIAlATUFJTF9H SURACiBDR0lfR0lEPQlAQ0dJX0dJREAKLSNBTElBU19VSUQ9CUBBTElBU19VSURACi0jQUxJQVNf R0lEPQlAQUxJQVNfR0lEQAorQUxJQVNfVUlEPQlAQUxJQVNfVUlEQAorQUxJQVNfR0lEPQlAQUxJ QVNfR0lEQAogTUFJTE1BTl9VSUQ9CUBNQUlMTUFOX1VJREAKK01BSUxNQU5fR0lEPQlATUFJTE1B Tl9HSURACiAKICMgQ3VzdG9taXphYmxlIGJ1dCBub3Qgc2V0IGJ5IGNvbmZpZ3VyZQogT1BUPQkJ QE9QVEAKIENGTEFHUz0JCSQoT1BUKSAkKERFRlMpCiBDR0lESVI9IAkkKGV4ZWNfcHJlZml4KS9j Z2ktYmluCi1DR0lFWFQ9CQlAQ0dJRVhUQAorQ0dJRVhUPQkJQENHSUVYVEAJCQogTUFJTERJUj0J JChleGVjX3ByZWZpeCkvbWFpbAogCiBTSEVMTD0JCS9iaW4vc2gKQEAgLTUzLDggKzU0LDggQEAK IAogQ0dJX0ZMQUdTPQktRENHSV9HSUQ9JChDR0lfR0lEKQogCi0jQUxJQVNfRkxBR1M9CS1EQUxJ QVNfVUlEPSQoQUxJQVNfVUlEKSBcCi0jCQktREFMSUFTX0dJRD0kKEFMSUFTX0dJRCkKK0FMSUFT X0ZMQUdTPQktREFMSUFTX1VJRD0kKEFMSUFTX1VJRCkgXAorCQktREFMSUFTX0dJRD0kKEFMSUFT X0dJRCkKIAogSEVMUEZVTD0JLURIRUxQRlVMCiAKQEAgLTc3LDI0ICs3OCwyOCBAQAogCiBNQUlM X1BST0dTPSB3cmFwcGVyCiAKLSNBTElBU19QUk9HUz0gYWRkYWxpYXNlcworQUREQUxJQVNfUFJP R1M9IGFkZGFsaWFzZXMKK1JNQUxJQVNfUFJPR1M9IHJtYWxpYXNlcworQUxJQVNfUFJPR1M9IHJt YWxpYXNlcyBhZGRhbGlhc2VzCiAKIFNVSURfQ0dJX1BST0dTPSBwcml2YXRlCiAKIFNVSURfTUFJ TF9QUk9HUz0KIAotUFJPR1JBTVM9ICQoQ0dJX1BST0dTKSAkKE1BSUxfUFJPR1MpICQoQUxJQVNf UFJPR1MpCitQUk9HUkFNUz0gJChDR0lfUFJPR1MpICQoTUFJTF9QUk9HUykgJChBRERBTElBU19Q Uk9HUykgJChSTUFMSUFTX1BST0dTKQogCiAKICMgUnVsZXMKIAogYWxsOiAkKFBST0dSQU1TKQog Ci13cmFwcGVyOiAkKHNyY2RpcikvbWFpbC13cmFwcGVyLmMgY29tbW9uLm8KKyQoTUFJTF9QUk9H Uyk6ICQoc3JjZGlyKS9tYWlsLXdyYXBwZXIuYyBjb21tb24ubwogCSQoQ0MpIC1JLiAkKE1BSUxf RkxBR1MpICQoQ0ZMQUdTKSBjb21tb24ubyAtbyAkQCAkKHNyY2RpcikvbWFpbC13cmFwcGVyLmMK IAotI2FkZGFsaWFzZXM6ICQoc3JjZGlyKS9hbGlhcy13cmFwcGVyLmMgY29tbW9uLm8KLSMJJChD QykgLUkuICQoQUxJQVNfRkxBR1MpICQoQ0ZMQUdTKSAtbyAkQCAkKHNyY2RpcikvYWxpYXMtd3Jh cHBlci5jCiskKEFEREFMSUFTX1BST0dTKTogJChzcmNkaXIpL2FkZGFsaWFzLXdyYXBwZXIuYyBj b21tb24ubworCSQoQ0MpIC1JLiAkKEFMSUFTX0ZMQUdTKSAkKENGTEFHUykgLW8gJEAgJChzcmNk aXIpL2FkZGFsaWFzLXdyYXBwZXIuYworJChSTUFMSUFTX1BST0dTKTogJChzcmNkaXIpL3JtYWxp YXMtd3JhcHBlci5jIGNvbW1vbi5vCisJJChDQykgLUkuICQoQUxJQVNfRkxBR1MpICQoQ0ZMQUdT KSAtbyAkQCAkKHNyY2Rpcikvcm1hbGlhcy13cmFwcGVyLmMKIAogJChDR0lfUFJPR1MpOiAkKHNy Y2RpcikvY2dpLXdyYXBwZXIuYyBjb21tb24ubwogCSQoQ0MpIC1EU0NSSVBUPSJcIiRAXCIiIC1J LiAkKENHSV9GTEFHUykgJChDRkxBR1MpIGNvbW1vbi5vIC1vICRAICQoc3JjZGlyKS9jZ2ktd3Jh cHBlci5jCkBAIC0xMDcsMTcgKzExMiwyMCBAQAogCWRvIFwKIAkgICAgZXhlPSQoQ0dJRElSKS8k JGYkKENHSUVYVCk7IFwKIAkgICAgJChJTlNUQUxMX1BST0dSQU0pICQkZiAkJGV4ZTsgXAorCSAg ICBjaG93biAkKE1BSUxNQU5fVUlEKTokKE1BSUxNQU5fR0lEKSAkKENHSURJUikvJCRmOyBcCiAJ ICAgIGNobW9kIGcrcyAkJGV4ZTsgXAogCWRvbmUKIAlmb3IgZiBpbiAkKE1BSUxfUFJPR1MpOyBc CiAJZG8gXAogCSAgICAkKElOU1RBTExfUFJPR1JBTSkgJCRmICQoTUFJTERJUik7IFwKKwkgICAg Y2hvd24gJChNQUlMTUFOX1VJRCk6JChNQUlMTUFOX0dJRCkgJChNQUlMRElSKS8kJGY7IFwKIAkg ICAgY2htb2QgZytzICQoTUFJTERJUikvJCRmOyBcCiAJZG9uZQotIwlAZm9yIGYgaW4gJChBTElB U19QUk9HUyk7IFwKLSMJZG8gXAotIwkgICAgJChJTlNUQUxMX1BST0dSQU0pICQkZiAkKGJpbmRp cikgOyBcCi0jCWRvbmUKKwlAZm9yIGYgaW4gJChBTElBU19QUk9HUyk7IFwKKwlkbyBcCisJICAg ICQoSU5TVEFMTF9QUk9HUkFNKSAkJGYgJChiaW5kaXIpIDsgXAorCSAgICBjaG93biAkKEFMSUFT X1VJRCk6JChBTElBU19HSUQpICQoYmluZGlyKS8kJGY7IFwKKwlkb25lCiAKIGZpbmlzaDoKIAkt Zm9yIGYgaW4gJChTVUlEX0NHSV9QUk9HUyk7IFwKZGlmZiAtTmF1ciAuL21haWxtYW4tMS4wYjkv c3JjL2FkZGFsaWFzLXdyYXBwZXIuYyAuL21haWxtYW4tMS4wYjlwL3NyYy9hZGRhbGlhcy13cmFw cGVyLmMKLS0tIC4vbWFpbG1hbi0xLjBiOS9zcmMvYWRkYWxpYXMtd3JhcHBlci5jCVR1ZSBNYXkg MjYgMTQ6NDI6MzggMTk5OAorKysgLi9tYWlsbWFuLTEuMGI5cC9zcmMvYWRkYWxpYXMtd3JhcHBl ci5jCU1vbiBNYXIgMjIgMDA6MDA6NDMgMTk5OQpAQCAtMTgsMTUgKzE4LDI0IEBACiAgKiBGb3Vu ZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UgLSBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEgMDIx MTEtMTMwNywgVVNBLgogICovCiAKKwogI2luY2x1ZGUgPHN0ZGlvLmg+CisjaW5jbHVkZSA8dGlt ZS5oPgogCisvKiAjZGVmaW5lIExFR0FMX1BBUkVOVF9VSUQgTUFJTE1BTl9VSUQ7CisjZGVmaW5l IExFR0FMX1BBUkVOVF9HSUQgTUFJTE1BTl9HSUQ7Ki8KIC8qIHBhc3NlZCBpbiBmcm9tIGNvbmZp Z3VyZSBzY3JpcHQgKi8KLWNvbnN0IGludCAgTEVHQUxfUEFSRU5UX1VJRCA9IEFMSUFTX1VJRDsg ICAgIC8qIG1haWxtYW4ncyBVSUQgKi8KLWNvbnN0IGludCAgTEVHQUxfUEFSRU5UX0dJRCA9IEFM SUFTX0dJRDsgICAgIC8qIG1haWwncyBHSUQgKi8KK2NvbnN0IGludCAgTEVHQUxfUEFSRU5UX1VJ RCA9IEFMSUFTX1VJRDsgICAvKiBtYWlsbWFuJ3MgVUlEICovCitjb25zdCBpbnQgIExFR0FMX1BB UkVOVF9HSUQgPSBBTElBU19HSUQ7ICAgIC8qIG1haWwncyBHSUQgKi8KKworCiAKIGNvbnN0IGNo YXIqIFNFTkRNQUlMX0NNRCA9ICIvdXNyL3NiaW4vc2VuZG1haWwiOwotY29uc3QgY2hhciogQUxJ QVNfRklMRSAgID0gIi9ldGMvYWxpYXNlcyI7Ci1jb25zdCBjaGFyKiBXUkFQUEVSICAgICAgPSAi L2hvbWUvbWFpbG1hbi9tYWlsbWFuL21haWwvd3JhcHBlciI7Citjb25zdCBjaGFyKiBBTElBU19G SUxFICAgPSAiL2V0Yy9tYWlsbWFuL2FsaWFzZXMiOworY29uc3QgY2hhciogV1JBUFBFUiAgICAg ID0gIi9ob21lL21haWxtYW4vbWFpbC93cmFwcGVyIjsKKworCisKIAogLyogCiAqKiBpcyB0aGUg cGFyZW50IHByb2Nlc3MgYWxsb3dlZCB0byBjYWxsIHVzPwpAQCAtNTIsMzIgKzYxLDMzIEBACiB7 CiAJRklMRSAqZjsKIAlpbnQgIGVyciA9IDA7Ci0KKwl0aW1lX3Qgc2VjczsKKwl0aW1lKCAmc2Vj cyApOwogCWYgPSBmb3BlbihBTElBU19GSUxFICwiYSsiKTsKIAlpZiAoZiA9PSBOVUxMKSB7CiAJ CWVyciA9IDE7CiAJCWYgPSBzdGRlcnI7CiAJCWZwcmludGYoZiwgIlxuXG4qKioqKioqKioqKkVS Uk9SISEhISoqKioqKioqKioqXG4iKTsKLQkJZnByaW50ZihmLCAiQ291bGQgbm90IHdyaXRlIHRv IHRoZSAvZXRjL2FsaWFzZXMgZmlsZS5cbiIpOworCQlmcHJpbnRmKGYsICJDb3VsZCBub3Qgd3Jp dGUgdG8gdGhlIGFsaWFzZXMgZmlsZS5cbiIpOwogCQlmcHJpbnRmKGYsICJQbGVhc2UgYmVjb21l IHJvb3QsIGFkZCB0aGUgbGluZXMgYmVsb3cgdG9cbiIpOwogCQlmcHJpbnRmKGYsICJ0aGF0IGZp bGUsIGFuZCB0aGVuIHJ1biB0aGUgY29tbWFuZDpcbiIpOwogCQlmcHJpbnRmKGYsICIlcyAtYmlc biIsIFNFTkRNQUlMX0NNRCk7CiAJfQogCi0JZnByaW50ZihmLCAiXG5cbiMtLSAlcyAtLSBtYWls aW5nIGxpc3QgYWxpYXNlczpcbiIsIGxpc3QpOwotCWZwcmludGYoZiwgIiVzOiBcdHxcIiVzIHBv c3QgJXNcIlxuIiwgbGlzdCwgV1JBUFBFUiwgbGlzdCk7CisJZnByaW50ZihmLCAiIyMgJXMgbWFp bGluZyBsaXN0OlxuIiwgbGlzdCk7CisJZnByaW50ZihmLCAiIyMgY3JlYXRlZCBieSBtYWlsbWFu IG9uOiAlcyIsIGN0aW1lKCZzZWNzKSk7CisJZnByaW50ZihmLCAiJXM6IFx0XHR8XCIlcyBwb3N0 ICVzXCJcbiIsIGxpc3QsIFdSQVBQRVIsIGxpc3QpOwogCWZwcmludGYoZiwgIiVzLWFkbWluOiBc dHxcIiVzIG1haWxvd25lciAlc1wiXG4iLCBsaXN0LCBXUkFQUEVSLCBsaXN0KTsKIAlmcHJpbnRm KGYsICIlcy1yZXF1ZXN0OiBcdHxcIiVzIG1haWxjbWQgJXNcIlxuIiwgbGlzdCwgV1JBUFBFUiwg bGlzdCk7Ci0JZnByaW50ZihmLCAiIyBJIHRoaW5rIHdlIGRvbid0IHdhbnQgdGhpcyBvbmUuLi5c biIpOwotCWZwcmludGYoZiwgIml0J2xsIGNoYW5nZSB0aGUgdW5peCBmcm9tIGxpbmUuLi5cbiIp OwotCWZwcmludGYoZiwgIiNvd25lci0lczogXHQlcy1hZG1pblxuIiwgbGlzdCwgbGlzdCk7Ci0J ZnByaW50ZihmLCAiIyVzLW93bmVyOiBcdCVzLWFkbWluXG4iLCBsaXN0LCBsaXN0KTsKLQlmcHJp bnRmKGYsICJcbiIpOworCWZwcmludGYoZiwgIm93bmVyLSVzOiBcdCVzLWFkbWluXG4iLCBsaXN0 LCBsaXN0KTsKKwlmcHJpbnRmKGYsICIlcy1vd25lcjogXHQlcy1hZG1pblxuIiwgbGlzdCwgbGlz dCk7CisJZnByaW50ZihmLCAiXG5cblxuIik7CiAJZmNsb3NlKGYpOwogCiAJaWYgKCFlcnIpIHsK IAkJcHJpbnRmKCJSZWJ1aWxkaW5nIGFsaWFzIGRhdGFiYXNlLi4uXG4iKTsKLQkJZXhlY2xwKFNF TkRNQUlMX0NNRCwgU0VORE1BSUxfQ01ELCAiLWJpIik7CisJCWV4ZWNscChTRU5ETUFJTF9DTUQs IFNFTkRNQUlMX0NNRCwgIi1iaSIsIE5VTEwpOworCQkKIAl9CiB9CiAK ------=_NextPart_000_008C_01BE74AA.C0C21600-- From Harald.Meland@usit.uio.no Wed Mar 24 23:34:14 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 25 Mar 1999 00:34:14 +0100 Subject: [Mailman-Developers] Does anyone else see these? In-Reply-To: J C Lawrence's message of "Fri, 05 Mar 1999 10:19:54 -0800" References: Message-ID: [J C Lawrence] > On Fri, 5 Mar 1999 01:17:53 -0600 (CST) > Christopher Lindsey wrote: > > > Perhaps Mailman could add (yet another) header indicating the > > targetted recepient to help with this type of situation? Maybe > > X-Mailman-Recepient? Or it could be wrapped it into another header > > like X-BeenThere... > > One technique I used for my own list software (now defunct) was that > every N'th message to each subscriber was sent individually with > custom headers giving the subscription address, list name etc. At one time I heard a rumour that someone was to implement VERP[1] support in Mailman -- and I even imagined to have heard that the implementation would do VERP on only every Nth posting to keep down list latency. It would be a post-1.0 thing, of course -- but was I merely dreaming all this, or are actually anyone putting any work into this? If no-one are, then someone should be :-) [1] Variable Envelope Return Paths, see for further description. -- Harald From Harald.Meland@usit.uio.no Wed Mar 24 23:53:38 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 25 Mar 1999 00:53:38 +0100 Subject: [Mailman-Developers] MM1.0b9 Bug! (was: Setup prob: abs/rel CGI url) In-Reply-To: Christian Tismer's message of "Fri, 05 Mar 1999 20:45:18 +0100" References: <36DE9318.59C0C8D8@appliedbiometrics.com> <36DE9CD1.60544B41@appliedbiometrics.com> <36DED38D.34DE263F@appliedbiometrics.com> <36E0344E.47E7C3E3@appliedbiometrics.com> Message-ID: [Christian Tismer] > I think it would be better for MM's public acceptance if there was > always a version known to be used in many installations. I, OTOH, don't think that'd solve anything much. The very reason for releasing Betas is to get rid of bugs. The intention is that each new Beta should have fewer bugs than any of the previous ones. Of course, due to human nature and Murphy's Law, whenever someone tries to fix a bug there is a non-zero probability that something else gets broken. > It would not have all new features, but also not the new bugs. Unless you trade away the Good of getting old bugs fixed, you can't avoid the Bad of maybe introducing new bugs. > In other words: If the latest beta needed a bug fix, why don't we > mark it as problematic and go back to, say, 1.0b7? IMHO, this might be a viable plan if we were talking about stable releases. We're not. We're talking about Beta releases. Cheers, -- Harald From claw@varesearch.com Thu Mar 25 00:21:38 1999 From: claw@varesearch.com (J C Lawrence) Date: Wed, 24 Mar 1999 16:21:38 -0800 Subject: [Mailman-Developers] Does anyone else see these? In-Reply-To: Message from Harald Meland of "25 Mar 1999 00:34:14 +0100." Message-ID: On 25 Mar 1999 00:34:14 +0100 Harald Meland wrote: > At one time I heard a rumour that someone was to implement VERP[1] > support in Mailman -- and I even imagined to have heard that the > implementation would do VERP on only every Nth posting to keep > down list latency. I implemented something like this for a home-grown list server, and chattered about that design on this list. I'm not aware of anyone buying into the idea, and I've been far too busy with Linux/Merced to do more than wanly wish for it. -- J C Lawrence Internet: claw@kanga.nu ---------(*) Internet: claw@varesearch.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From jeffh@streek.com Thu Mar 25 16:24:45 1999 From: jeffh@streek.com (Jeff Hahn) Date: Thu, 25 Mar 1999 10:24:45 -0600 Subject: [Mailman-Developers] bulk add users "issues" Message-ID: <001201be76db$feab30e0$1e0a5ad1@SINGSING.STREEK.COM> couple of issues: 1. I've also run into a problem I believe I remember reading about on this list. add_members seg faults at about 500 users added in a run. I've got the dumpfile, but since I don't have python compiled with debugging, not sure it's of any value to anyone. (RH 5.2, Python 1.5.1, latest CVS of Mailman) 2. When bulk adding members (either thru the web page or add_members) the digest type appears to be random (not the default digest mode as defined for the list) I've scanned thru the source, but I don't see anything "obvious", but I've probably overlooked something easy. -Jeff From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Mar 26 16:46:13 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 26 Mar 1999 11:46:13 -0500 (EST) Subject: [Mailman-Developers] Mailman 1.0b10 Message-ID: <14075.47573.821308.819354@anthem.cnri.reston.va.us> Hi everyone, I'm releasing Mailman 1.0b10 today; hopefully we'll have more luck with this than b9. I need to concentrate on other things for a while, now that python.org seems to be smoothly running this version. Unless there are showstopper bugs, I would like this version to be 1.0 final, so please do bang on it a lot. If you do find bugs, it would be great if you can enter them into the Jitterbug database. See http://www.python.org/mailman-bugs I know there's a lot y'all would like to see done. Weighed against the slippage in when I thought 1.0 final would be out, I think we have to just be happy with what we've got for now, get it out the door, and then begin working on improvements. Like John said at LISA: "all mailing list managers suck, ours just sucks less" ... hopefully :-) Go to www.list.org to pick up the current tarball. Note that the old ftp URL won't work anymore. BE SURE TO READ THE `UPGRADING' FILE FOR IMPORTANT INFORMATION. There's still time to vote on the logo. Voting is closed whenever I do the first release candidate (no date set, but SOON). My priority for the next release will be to craft the Web pages for gnu.org, clean up documentation, and get things ready for the mass of new adopters (yeah!). I can't guarantee that I'll be hacking any code unless there's severe breakage in this tarball. Enjoy, and thanks everyone, -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Mar 26 16:48:12 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 26 Mar 1999 11:48:12 -0500 (EST) Subject: [Mailman-Developers] Mailman 1.0b10 References: <14075.47573.821308.819354@anthem.cnri.reston.va.us> Message-ID: <14075.47692.844754.75868@anthem.cnri.reston.va.us> Oops, here's the NEWS file entries for 1.0b10. 1.0b10 - New script bin/sync_members which can be used to synchronize a list's membership against a flat (e.g. sendmail :include: style) file. - bin/add_members and bin/remove_members now accept addresses on the command line with `-' as the value for the -d and -n options. - Added variable USE_ENVELOPE_SENDER to Defaults.py for site-wide configuration of address matching scheme. With this variable set to true, the envelope sender (e.g. Unix "From_" header) is used to match addresses, otherwise the From: header is used. Envelope sender matching seems not to work on many systems. This variable is currently defaulted to 1, but may change to 0 for the final release. - Reorganization of the membership management admin page. Also member addresses are linked to their options page. Only the `General' category has the admin password change form. - Major reorganization of email command handling and responses. `notmetoo' is the preferred email command instead of `norcv', although the latter is still accepted as an argument. If more than 5 errors are found in the message, command processing is halted. - User options page now shows the user their case-preserved subscribed address as well. - The usual assortment of bug fixes. From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Mon Mar 29 18:45:42 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 29 Mar 1999 13:45:42 -0500 (EST) Subject: [Mailman-Developers] 1.0b10 Message-ID: <14079.51798.702519.838718@anthem.cnri.reston.va.us> Folks, please don't upgrade to 1.0b10 just yet. I think there's still a problem with address matching and case preservation. I have a fix and am going to do a bunch of testing, /and/ hopefully get some sanity checking from Ken on a few things. Once I get this fixed, I will release 1.0b11. Note that this should be unrelated to the problem that Clark is having. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Mar 30 03:15:49 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 29 Mar 1999 22:15:49 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] mailman, postifx, and bsdos3 References: <4.1.19990329120242.038f50b0@10.0.0.1> Message-ID: <14080.16869.597516.622115@anthem.cnri.reston.va.us> >>>>> "GME" == George M Ellenburg writes: GME> At the request of some of my customers, I've recently GME> installed mailman on BSD 3.1, with Postfix beta-19990317-pl02 GME> as the transport. GME> Frankly, I'm a little confused with regards to the install GME> instructions. Was wondering if anyone can provide some GME> elightenment. GME> I'm getting the following error when trying to create a test list: | sundial:~/bin $ whoami | mailman | sundial:~/bin $ ./newlist | Enter the name of the list: test | Enter the email of the person running the list: gme@caffeine.sundial.net | Initial test password: testpassword | Traceback (innermost last): | File "./newlist", line 141, in ? | raise SystemExit(main(sys.argv)) | File "./newlist", line 91, in main | newlist.Create(list_name, owner_mail, pw) | File "/u1/mailman/Mailman/MailList.py", line 658, in Create | self.Lock() | File "/u1/mailman/Mailman/MailList.py", line 1213, in Lock | self._lock_file.lock('w|', 1) | File "/usr/local/lib/python1.5/posixfile.py", line 190, in lock | flock = fcntl.fcntl(self._file_.fileno(), cmd, flock) | IOError: (22, 'Invalid argument') | sundial:~/bin $ I'm Cc'ing the Mailman developers and Guido on this message, because I suspect there's a problem with your Python on your operating system (BSD 3.1). For some reason lock() method on the posixfile object is failing. This method eventually calls down to fcntl() and the `|' modifier translates to F_SETLKW. fcntl(2) says that this could fail and return EINVAL (i.e. errno 22) as described in my Solaris manpage: EINVAL The cmd argument is invalid; or the cmd argu- ment is F_DUPFD and arg is negative or greater than or equal to OPEN_MAX; or the cmd argument is F_GETLK, F_GETLK64, F_SETLK, F_SETLK64, F_SETLKW, or F_SETLKW64 and the data pointed to by arg is not valid; or fildes refers to a file that does not support locking. I've never seen this happen before, at least in the context of Mailman, so that's why I'm suspecting your OS, of which I have no experience. What does your sys.platform say? Maybe someone else has some idea about why this is failing. -Barry From guido@CNRI.Reston.VA.US Tue Mar 30 03:35:01 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 29 Mar 1999 22:35:01 -0500 Subject: [Mailman-Developers] Re: [Mailman-Users] mailman, postifx, and bsdos3 In-Reply-To: Your message of "Mon, 29 Mar 1999 22:15:49 EST." <14080.16869.597516.622115@anthem.cnri.reston.va.us> References: <4.1.19990329120242.038f50b0@10.0.0.1> <14080.16869.597516.622115@anthem.cnri.reston.va.us> Message-ID: <199903300335.WAA02768@eric.cnri.reston.va.us> The mention of posixfile, fcntl and BSD made me remember something. There's some very non-portable code that constructs the fcntl call. The CVS archives have a version of posixfile.py that is newer than that in the Python 1.5.2b2 release, and the CVS log comment says: | According to Jeffrey Honig, bsd/os 2.0 - 4.0 should be added to the | list (of bsd variants that have a different lock structure). Here's the patch: Index: posixfile.py =================================================================== RCS file: /projects/cvsroot/python/dist/src/Lib/posixfile.py,v retrieving revision 1.10 retrieving revision 1.11 diff -c -r1.10 -r1.11 *** posixfile.py 1998/03/26 21:12:38 1.10 --- posixfile.py 1999/02/23 04:14:32 1.11 *************** *** 177,183 **** # Hack by davem@magnet.com to get locking to go on freebsd; # additions for AIX by Vladimir.Marangozov@imag.fr import sys, os ! if sys.platform in ('netbsd1', 'freebsd2', 'freebsd3'): flock = struct.pack('lxxxxlxxxxlhh', \ l_start, l_len, os.getpid(), l_type, l_whence) elif sys.platform in ['aix3', 'aix4']: --- 177,185 ---- # Hack by davem@magnet.com to get locking to go on freebsd; # additions for AIX by Vladimir.Marangozov@imag.fr import sys, os ! if sys.platform in ('netbsd1', ! 'freebsd2', 'freebsd3', ! 'bsdos2', 'bsdos3', 'bsdos4'): flock = struct.pack('lxxxxlxxxxlhh', \ l_start, l_len, os.getpid(), l_type, l_whence) elif sys.platform in ['aix3', 'aix4']: *************** *** 190,196 **** flock = fcntl.fcntl(self._file_.fileno(), cmd, flock) if '?' in how: ! if sys.platform in ('netbsd1', 'freebsd2', 'freebsd3'): l_start, l_len, l_pid, l_type, l_whence = \ struct.unpack('lxxxxlxxxxlhh', flock) elif sys.platform in ['aix3', 'aix4']: --- 192,200 ---- flock = fcntl.fcntl(self._file_.fileno(), cmd, flock) if '?' in how: ! if sys.platform in ('netbsd1', ! 'freebsd2', 'freebsd3', ! 'bsdos2', 'bsdos3', 'bsdos4'): l_start, l_len, l_pid, l_type, l_whence = \ struct.unpack('lxxxxlxxxxlhh', flock) elif sys.platform in ['aix3', 'aix4']: --Guido van Rossum (home page: http://www.python.org/~guido/) From nbecker@fred.net Tue Mar 30 18:37:19 1999 From: nbecker@fred.net (nbecker@fred.net) Date: 30 Mar 1999 13:37:19 -0500 Subject: [Mailman-Developers] exim - Failure to exec script- gid question Message-ID: I'm using mailman-1.0b10 + exim-2.10. Mar 30 13:10:08 nbeckerpc Mailman mail-wrapper: Failure to exec script. WANTED gid 12, GOT gid 99. (Reconfigure to take 99?) I can reconfigure mailman or exim to set the gid, but why is it needed at all? Since wrapper is sgid, why does it care what gid was used to invoke it? Just additional security check? From Gergely Madarasz Wed Mar 31 08:50:14 1999 From: Gergely Madarasz (Gergely Madarasz) Date: Wed, 31 Mar 1999 10:50:14 +0200 (METDST) Subject: [Mailman-Developers] problems with who ? Message-ID: I'm running mailman 1.0b10 This is all I get from a who request. ---------- Forwarded message ---------- Date: Wed, 31 Mar 1999 10:48:22 +0200 From: linux-flame-request@mlf.linux.rulez.org To: gorgo@caesar.elte.hu Subject: Mailman results for linux-flame ***** who Digest Members: anovak@nap-szam.hu atom@sophia.jpte.hu b-b0mb@freemail.c3.hu ba... Non-Digest Members: a7803268@unet.univie.ac.at a_linux@freemail.c3.hu acsosz@mail.da... From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Mar 31 16:41:13 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 31 Mar 1999 11:41:13 -0500 (EST) Subject: [Mailman-Developers] problems with who ? References: Message-ID: <14082.20521.113988.624234@anthem.cnri.reston.va.us> >>>>> "GM" == Gergely Madarasz writes: GM> I'm running mailman 1.0b10 GM> This is all I get from a who request. Simple fix attached. Thanks, -Barry -------------------- snip snip -------------------- Index: MailCommandHandler.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/MailCommandHandler.py,v retrieving revision 1.43 retrieving revision 1.44 diff -c -r1.43 -r1.44 *** MailCommandHandler.py 1999/03/24 19:15:51 1.43 --- MailCommandHandler.py 1999/03/31 16:32:32 1.44 *************** *** 448,460 **** self.AddToResponse(string.join(map(AddTab, filter(NotHidden, digestmembers)), ! "\n")) if len(members): self.AddToResponse("Non-Digest Members:") members.sort() self.AddToResponse(string.join(map(AddTab, filter(NotHidden, members)), ! "\n")) def ProcessUnsubscribeCmd(self, args, cmd, mail): if not len(args): --- 448,460 ---- self.AddToResponse(string.join(map(AddTab, filter(NotHidden, digestmembers)), ! "\n"), trunc=0) if len(members): self.AddToResponse("Non-Digest Members:") members.sort() self.AddToResponse(string.join(map(AddTab, filter(NotHidden, members)), ! "\n"), trunc=0) def ProcessUnsubscribeCmd(self, args, cmd, mail): if not len(args): From lindsey@ncsa.uiuc.edu Wed Mar 31 21:36:33 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Wed, 31 Mar 1999 15:36:33 -0600 (CST) Subject: [Mailman-Developers] mailman and AFS? Message-ID: <199903312136.PAA02853@ferret.ncsa.uiuc.edu> Well, I'm about to try doing some funky stuff that's going to require source changes, etc. But before I jump into it, I've got some questions. I want to setup mailman here at NCSA and gradually start phasing out majordomo. Here's the current set up: 4 mail servers NFS-RAID sharing mail spools, procmail recipes, etc. AFS (this is a common filesystem everywhere) 8 round-robined Web servers (DocumentRoot served from AFS) Because AFS is the only available common filesystem for both the mail servers and the Web servers, I'll need to setup mailman there. Now for the tricky part. AFS doesn't use standard UNIX permissions, but instead depends on ACLs (ours uses Kerberos V for authentication). To be able to write into the AFS space, any program or shell must have a valid AFS token. I can do this by creating a "keytab" file; basically, that randomizes the password but lets me use it in shell scripts, etc. I just need to kinit against this file, do my operations, then do a kdestroy. Now for my questions: o where should I put these calls? I'm guessing that they should be in wrapper, but do I also need to put it into every binary in $prefix/cgi-bin? It appears that way... o am I going to run into any locking issues with multiple email and Web servers, or does mailman handle this? If so, how? AFS (like NFS) often has problems with flock() or fcntl() locking (so dot-locking is the preferred method). o does mailman actually do any permissions checking on files or directories? These checks would fail in AFS Any pointers and/or answers would be appreciated. Thanks, Chris