From majordomo-workers-owner Thu Sep 1 20:22:16 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id UAA05987; Thu, 1 Sep 1994 20:22:16 GMT Received: from interlock.ans.net by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id NAA05963; Thu, 1 Sep 1994 13:21:29 -0700 Received: by interlock.ans.net id AA08490 (InterLock SMTP Gateway 1.1); Thu, 1 Sep 1994 16:26:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Sep 1994 16:26:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Sep 1994 16:26:30 -0400 From: Dan Simoes Message-Id: <199409012026.AA81728@foo.ans.net> Subject: broken which in 1.62 To: majordomo-users@greatcircle.com (majordomo-users) Date: Thu, 1 Sep 1994 16:26:27 -0400 (EDT) Cc: majordomo-workers@greatcircle.com (majordomo-workers) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 661 Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk [I'm copying -workers in case this is a bug] As it turns out, the which command in 1.62 is broken. If you are are on private lists and do a which, those lists are not picked up - ie, it should check to see that you are a member of the list then let you do a which, but it doesn't. The server in question only serves private lists, so it appeared that there was no which output. According to the code, a which on a private list should be possible, but only for list members. Is this in fact broken? Thanks, | Dan | -- Dan Simoes dans@ans.net Associate Programmer (914) 789-5378 Advanced Network & Services Elmsford, NY From majordomo-workers-owner Fri Sep 2 04:28:26 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id EAA09022; Fri, 2 Sep 1994 04:28:26 GMT Received: from chronos.synopsys.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id VAA09016; Thu, 1 Sep 1994 21:28:15 -0700 Received: from gaea.synopsys.com by chronos.synopsys.com with SMTP id AA01556 (5.65c/IDA-1.4.4); Thu, 1 Sep 1994 21:33:23 -0700 Received: from atropos.synopsys.com by gaea.synopsys.com with SMTP id AA19625 (5.65c/IDA-1.4.4); Thu, 1 Sep 1994 21:33:22 -0700 Received: from mango.synopsys.com (mango-backbone.synopsys.com [146.225.64.212]) by atropos.synopsys.com (8.6.9/8.6.9) with ESMTP id VAA06772; Thu, 1 Sep 1994 21:33:21 -0700 Received: (from arnold@localhost) by mango.synopsys.com (8.6.9/8.6.9) id VAA15386; Thu, 1 Sep 1994 21:33:20 -0700 Date: Thu, 1 Sep 1994 21:33:20 -0700 From: Arnold de Leon Message-Id: <199409020433.VAA15386@mango.synopsys.com> To: majordomo-users@greatcircle.com, majordomo-workers@greatcircle.com Subject: resend and approved headers Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk Enclosed are the changes that I made to resend to allow it to handle "Approved" headers better. It allows an "Approved:" header to appear early in the body. If resend sees an "Approved:" within 10 characters of the headers (newlines counted) then it accepts that. This is just a looser definition of "Approved:" being the first line of the body. After accepting an in body "Approved:" header it starts looking for more headers. If it finds what looks like a set then it uses those as headers. (As in the case of a moderator approving a posting) If does not find then it uses the headers that the message came with (as in the case of a moderator of a list posting directly). arnold -- Arnold de Leon Synopsys Inc. arnold@synopsys.com 700 E. Middlefield Road +1 415 694 4183 Mtn. View, CA 94043-4033 *** resend Thu Jun 9 12:45:16 1994 --- /remote/ncs1/src/majordomo/majordomo-1.92/resend Thu Sep 1 21:08:12 1994 *************** *** 137,155 **** open(IN, "/tmp/resend.$$.in") || die("resend: Can't open /tmp/resend.$$.tmp: $!"); do { $restart = 0; - $pre_hdr = 1; while () { if ($pre_hdr) { ! if (/^\s*$/) { # skip leading blank lines; usually only there if this is a # restart after an in-body "Approved:" line next; } else { $pre_hdr = 0; - $in_hdr = 1; $kept_last = 0; } } if ($in_hdr) { --- 143,171 ---- open(IN, "/tmp/resend.$$.in") || die("resend: Can't open /tmp/resend.$$.tmp: $!"); + $pre_hdr = 0; + $in_hdr = 1; do { $restart = 0; while () { if ($pre_hdr) { ! if ((/^\s*$/) || (/^>from\s*/i)){ # skip leading blank lines; usually only there if this is a # restart after an in-body "Approved:" line + # also skip any quoted Unix From lines next; } else { $pre_hdr = 0; $kept_last = 0; + if ((/^[a-z\-]+:.*/i) || (/^from.*/i)) { + # found a header during restart so + # start over + $in_hdr = 1; + close(OUT); + unlink("/tmp/resend.$$.out"); + open(OUT, ">/tmp/resend.$$.out") || + die("resend: Can't open /tmp/resend.$$.out: $!"); + } } } if ($in_hdr) { *************** *** 245,252 **** } } else { # this isn't a header line, so print it (maybe) ! # first, though, is the first line of the body an "Approved:" line? ! if (($body_len == 0) && /^approved:\s*(.*)/i && defined($opt_a)) { # OK, is it a valid "Approved:" line? $approved = &chop_nl($1); if ($approved ne $opt_a && --- 261,270 ---- } } else { # this isn't a header line, so print it (maybe) ! # first, though, is the first real line the ! # body an "Approved:" line? ! # 10 gives is 10 newlines or a 9 character word ! if (($body_len <= 10) && /^approved:\s*(.*)/i && defined($opt_a)) { # OK, is it a valid "Approved:" line? $approved = &chop_nl($1); if ($approved ne $opt_a && *************** *** 256,265 **** # Yes, it's a valid "Approved:" line... # So, we start over $restart = 1; ! close(OUT); ! unlink("/tmp/resend.$$.out"); ! open(OUT, ">/tmp/resend.$$.out") || ! die("resend: Can't open /tmp/resend.$$.out: $!"); last; } } --- 274,280 ---- # Yes, it's a valid "Approved:" line... # So, we start over $restart = 1; ! $pre_hdr = 1; last; } } From majordomo-workers-owner Fri Sep 9 03:12:19 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id DAA12291; Fri, 9 Sep 1994 03:12:19 GMT Received: from unpc.queernet.org by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id UAA12284; Thu, 8 Sep 1994 20:12:07 -0700 Received: by unpc.queernet.org (Smail3.1.28.1 #9) id m0qiwRR-00014wC; Thu, 8 Sep 94 20:15 WET DST Message-Id: To: majordomo-workers@greatcircle.com Subject: Addition to the "resend" Administrivia Filter Date: Thu, 08 Sep 1994 20:15:55 -0700 From: "Roger B.A. Klorese" Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk For mailing lists that have Usenet gateways, adding an admin check for "cmsg" can keep us from distributing cancel messages. --- ROGER B.A. KLORESE rogerk@QueerNet.ORG 2215-R Market Street #576 San Francisco, CA 94114 +1 415 ALL-ARFF "There is only one real blasphemy: the refusal of joy." -- Paul Rudnick From majordomo-workers-owner Fri Sep 9 03:35:49 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id DAA12392; Fri, 9 Sep 1994 03:35:49 GMT Received: from oulu.fi by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id UAA12386; Thu, 8 Sep 1994 20:35:40 -0700 Received: from paju.oulu.fi by oulu.fi (4.1/SMI-4.1) id AA29775; Fri, 9 Sep 94 06:41:00 +0300 Received: by paju.oulu.fi (931110.SGI/930416.SGI.AUTO) for @ousrvr.oulu.fi:majordomo-workers@greatcircle.com id AA27873; Fri, 9 Sep 94 06:40:14 +0300 Date: Fri, 9 Sep 1994 06:40:12 +0200 From: Marko Hotti To: majordomo-users@greatcircle.com Cc: majordomo-workers@greatcircle.com Subject: Problem with 'get' Message-Id: Organization: University of Oulu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk I have a problem with the 'get' command in our majordomo server. If I send the 'index' command to Majordomo, I get the names and dates etc. of the files for the particular list. However, when I try to get the file, Majordomo can't find the files. Where is the problem. Here's the message from Majordomo: ---------- Forwarded message ---------- Date: Fri, 9 Sep 1994 06:19:38 +0300 From: Majordomo@phoenix To: mhotti@paju.oulu.fi Subject: Majordomo results -- >>>> index finlandia total 2 -rw-rw-rw- 1 mhotti 492 Sep 9 05:37 booklist -rw-r----- 1 mhotti 242 Sep 9 05:59 faq >>>> get finlandia booklist #### No such file 'booklist' for list 'finlandia' >>>> The permissions for the booklist file are for user: mhotti group: majordom so Majordomo should be able to read the file. Where can I look for the cause of the problem. I've checked the majordomo.cf and everything seems to be in order. Thank you for any help! PS Anything new about how to subscribe from an X.400 email address? I'm referring to the '/' characters. From majordomo-workers-owner Fri Sep 9 04:29:40 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id IAA13744; Fri, 9 Sep 1994 08:43:45 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id BAA13735; Fri, 9 Sep 1994 01:43:32 -0700 Received: from uucp5.UU.NET by relay2.UU.NET with SMTP id QQxgox00643; Fri, 9 Sep 1994 04:48:56 -0400 Received: from csfb1.UUCP by uucp5.UU.NET with UUCP/RMAIL ; Fri, 9 Sep 1994 04:49:23 -0400 Received: from csfp.co.uk (chronos) by csfb1 (4.1/SMI-4.1.v1) id AA17915; Fri, 9 Sep 94 04:36:56 EDT Received: from odin.csfp.co.uk by csfp.co.uk (4.1/SMI-4.1.v1(H_chronos)) id AA24116; Fri, 9 Sep 94 09:37:17 BST Received: by odin.csfp.co.uk (4.1/SMI-4.1(V_Default)) id AA09577; Fri, 9 Sep 94 09:37:16 BST From: "Murray Herbert" Message-Id: <9409090937.ZM9575@odin> Date: Fri, 9 Sep 1994 09:37:16 +0100 In-Reply-To: Dilios Panagiotis "Re: Help with archive in 1.92" (Sep 9, 10:30am) References: X-Face: "6LO'iD0N-8.Hl68TnIdNcxpr|@JNT@SrJF3zdyY7`-`u0g*agt-IR0oUTmx`q$p\}7,YeMB X-Mailer: Z-Mail (3.2.0 16aug94) To: majordomo-workers@GreatCircle.COM Subject: Re: Help with archive in 1.92 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk I posted to the group asking why majordom could write to an archive -but no-one else. There were several people who mailed me asking for the answer when I found it and a LOT of people who thought opening up the permissions to world-writeable (666) would do it. World-write enabling on the archive file or directories is NOT the answer. So with help -here is what I found... I had not checked the permissioning and ownership of 'wrapper'. -This is because I had not paid attention to the make output -nor read the Makefile. In the Makefile (for a BSD system) the W_GROUP entry is bblisa and this needs to be majordom (for my site) -the group owner of the directories and archive file and the install-wrapper has a cp entry... cp wrapper $(W_BIN)/wrapper this kicks the make into touch (sorry -breaks it) and stops the ownership and permissioning being set. -I was installing the wrapper in the 'top level directory' and the copy fails. Commenting out the cp line enabled the chown and chmod to be run. And now everyone's postings are being archived. :-) Thanks to all who responded. -- ---------------------------------------------------------------------------- Murray Herbert phone: +44 71 516 2199 UNIX Technical Services fax: +44 71 516 3924 Credit Suisse Financial Products London ---------------------------------------------------------------------------- From majordomo-workers-owner Sun Sep 11 20:00:49 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id UAA03143; Sun, 11 Sep 1994 20:00:49 GMT Received: from netcomsv.netcom.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id NAA03137; Sun, 11 Sep 1994 13:00:36 -0700 Received: from quake.UUCP by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id MAA28171; Sun, 11 Sep 1994 12:58:40 -0700 Received: by getunx.quake.com id AA18149 (5.65c/IDA-1.4.4); Sun, 11 Sep 1994 12:09:31 -0700 Date: Sun, 11 Sep 1994 12:09:31 -0700 From: "Glenn E. Thobe" Message-Id: <199409111909.AA18149@getunx.quake.com> To: majordomo-workers@greatcircle.com Subject: bug report - "Sender:" Cc: owner-current-users@netbsd.org Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk Majordomo developers- I found a situation in which majordomo fails to put a "Sender:" field in the mail header. This prevents my mail splitter from identifying the mailing list further preventing automated archiving of articles. (Perhaps my ad hoc method of identifying the mailing list by parsing the "Sender:" field is naive. It might be useful to define a "correct" way of making this identification, perhaps involving yet another new mail header field especially for this purpose.) Here is the bug: Suppose someone submits a posting to a mailing list in the following manner, i.e. using the "Cc:" field only. Then no "Sender:" field is generated. The following example illustrates this: ~From uucp Sun Sep 11 06:37 PDT 1994 ~>From NetBSD.ORG!owner-current-users@quake.UUCP Sat Sep 10 15:22:28 1994 ~To: burgess@s069.infonet.net ~Cc: current-users@NetBSD.ORG, port-sparc@NetBSD.ORG ~Subject: Re: debugging kernel core dumps ? ~Date: Sat, 10 Sep 1994 22:22:28 -0700 ~From: Greg Earle I believe this is Majordomo rev.1.8. Thank you. -Glenn Thobe From majordomo-workers-owner Mon Sep 12 03:30:53 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id DAA05297; Mon, 12 Sep 1994 03:30:53 GMT Received: from alpha.bostic.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id UAA05291; Sun, 11 Sep 1994 20:30:44 -0700 Received: by alpha.bostic.com; id AA17310; Sun, 11 Sep 1994 23:36:07 -0400 Message-Id: <9409120336.AA17310@alpha.bostic.com> To: "Glenn E. Thobe" Cc: majordomo-workers@greatcircle.com, owner-current-users@netbsd.org Subject: Re: bug report - "Sender:" In-Reply-To: Your message of "Sun, 11 Sep 1994 12:09:31 PDT." <199409111909.AA18149@getunx.quake.com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. Date: Sun, 11 Sep 1994 23:36:07 -0400 From: "Chris G. Demetriou" Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk > Suppose someone submits a posting to a mailing list in the following > manner, i.e. using the "Cc:" field only. Then no "Sender:" field is > generated. The following example illustrates this: I don't buy this; i dunno about the old version of majordomo we were using, but i've received several pieces from the new version, where the list is only cc'd, that definitely do the right thing. > I believe this is Majordomo rev.1.8. Actually, we were running 1.62, and are now running 1.92. I think it's more likely that this was caused by the recent (serious) re-organization of how the NetBSD mailing lists are handled... We tried to do the transition to a new machine seamlessly, but it didn't quite work out that way. cgd (owner-current-users@netbsd.org) From majordomo-workers-owner Mon Sep 12 15:17:42 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id PAA10196; Mon, 12 Sep 1994 15:17:42 GMT Received: from chalmers.se by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id IAA10180; Mon, 12 Sep 1994 08:17:24 -0700 Received: from fyserv1.fy.chalmers.se by chalmers.se (5.60+IDA/3.14+gl) id AA10054; Mon, 12 Sep 94 17:22:53 +0200 From: Andy Polyakov Received: from fysun4 by fyserv1.fy.chalmers.se (5.0/3.14+gl) id AA10260; Mon, 12 Sep 1994 17:22:58 --100 Received: by fysun4 (5.0/SVR4-minimal.client) id AA25708; Date: Mon, 12 Sep 1994 17:20:57 --100 Message-Id: <9409121520.AA25708@fysun4> To: majordomo-workers@greatcircle.com Subject: majordomo-1.92/resend script X-Sun-Charset: US-ASCII Content-Length: 5047 Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk Hello, guys! I have few comments about majordomo software and about resend script in particular. I want you to consider this note as no-priority user feedback, but if you find my comments useful, I'd appreciate if you give me a note. First of all, I've found that in order to get it working it reqiures too much mail aliases to set up and resend script requires too much arguments to pass, so that I've made a decision to modify the code a bit to make life easier for me. Here is a part of resend.README with my comments and patches: > > -C specify alternate config file (must be first!) Actually I had to comment out all external config file calls starting at line#81, because it doesn't seem to work (at least the options are not overridable by command line options, which is desirable in order to protect system from list manager's mistakes). > -l REQUIRED: specify list name > -h REQUIRED: specify host name Then I couldn't realize why this field could not be derived from $whereami config variable? Something like following just after Getopts: @line#67 + if (! defined($opt_h)) { $opt_h=$whereami; } > -f specify "sender" (default -request) I've modified default "-request" to "-owner" in order to reduce number of mail aliases to setup. > -m specify special sendmail flags > -M specify max message length to forward > -p add "Precedence: " header > -r add "Reply-To: " header If I specify -r somebody@some.where it gets rewritten as somebody@some.where@right.here, so that I had to hack the line #79: ! $opt_r = join('@',(split('@',"$opt_r@$opt_h"))[0,1]) if ( defined($opt_r) ); Probably it's good idea to get rid of $opt_r@$opt_h expansion at all... And I think it would be fair to include the address of non-member posting to a list to "Reply-To:" header, so I did as following: @line#162 if (defined($opt_r)) { ! print OUT "Reply-To: ", &config'substitute_values($opt_r); ! # Andy. 940912 add non-member to Reply-To: header! ! if (open(LISTFD,"<$listdir/$opt_l") != 0) { ! @output = grep (&addr_match($from,$_), ); ! close (LISTFD); ! print OUT ", ", &ParseAddrs($from) if ( $#output == -1 ); ! } ! print OUT "\n"; } > -I Bounce messages from users not listed in file > in colon-separated Shouldn't it be defaulted to $listdir/$opt_l? > -a approval password I consider it as big security hole! The password can in principal be obtained by anybody by making 'telnet majordomo-host 25' and issuing 'vrfy list' command, which normaly gives complete command line with this password. Why haven't you use $listdir/$opt_l.passwd? So I had to overcome this: @line#119 if (defined($opt_A) && ! defined($opt_a)) { ! open(PWD, "$listdir/$opt_l.passwd") || die("resend: open(PWD, \$listdir/$opt_l.passwd\"): $!"); ! $opt_a = &chop_nl(); ! #die("resend: must also specify '-a passwd' if using '-A' flag"); } > -A moderate list (require "Approved:" for posting) > -R delete "Received:" lines > -s enable "administrivia" checks > -d debug; say it, but don't do it Well, after one specifies all these options, he/she is supposed to pass at least one argument, which is usually mail alias pointing to $listdir/$opt_l file, e.g.: "list-outgoing: :include:/blah-blah/Lists/list" First of all I consider it also as a security hole, because it permits anybody to obtain member list for closed lists by issuing 'vrfy list-outgoing' at "sendmail" prompt (see above). And then can't resend script handle it all by itself? It has all the information, hasn't it? And I won't have a chance to mistype /blah-blah path... So I did as following: @line#75 ! #if ( ! @ARGV) { ! # die("resend: must specify outgoing list as last arg(s)"); ! #} @line#328 ! $sendmail_cmd = "/usr/lib/sendmail $opt_m -f$sendmail_sender "; ! if (@ARGV) { ! $sendmail_cmd .= join(" ", @ARGV); ! } else { ! open (LISTFD,"$listdir/$opt_l") || die("resend: open(LISTFD, \$listdir/$opt_l\"): $!"); ! while () { ! @_ = &ParseAddrs($_); ! push (@THE_LIST,@_); ! } ! close (LISTFD); ! $sendmail_cmd .= join(" ", @THE_LIST); ! } And finally there is a tipo at line#347. It should look like following: ! unlink(); Otherwise it leaves those temporary files in /tmp, which is also sort-of security hole. Sincerely yours. Andy. ========================================================================= Andy Polyakov, System Manager ------------------------------------------------------------------------- E-Mail: appro@fy.chalmers.se | Mail: Fysikgrand 3 | Chalmers University of Technology Phone: +46(31)7723390 | S-412 96 Goteborg FAX: +46(31)7723471 | Sweden ------------------------------------------------------------------------- From majordomo-workers-owner Mon Sep 12 20:58:00 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id UAA13098; Mon, 12 Sep 1994 20:58:00 GMT Received: from zoom.bga.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id XAA29082; Sat, 10 Sep 1994 23:52:11 -0700 Received: (from fmouse@localhost) by zoom.bga.com (8.6.9/8.6.9) id BAA06187; Sun, 11 Sep 1994 01:57:30 -0500 From: Lindsay Haisley Message-Id: <199409110657.BAA06187@zoom.bga.com> Subject: no_who needed! To: majordomo-workers@GreatCircle.COM Date: Sun, 11 Sep 1994 01:57:30 -0500 (CDT) Cc: majordomo-users@GreatCircle.COM X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 869 Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk I'm the Majordomo administrator at Real/Time Communications (bga.com). We have several users who use Majordomo to distribute e-zines. As with any publication, the subscription list of an e-zine is, or should be, private to the e-zine publishers. For such users, private_who is not sufficient since anone can subscribe to the e-zine and once subscribed, do a who of all the other subscribers. What is badly needed here is a no_who option which will prevent anyone but the list administrator from running a who on the list. Has anyone added this to Majordomo? We're running 1.92 here. ----------------------------------------------- Lindsay Haisley |"On the Internet, no one knows you're a dog" | fmouse@bga.com | --- The New Yorker Magazine | Austin, Texas, USA ----------------------------------------------- * * * * * * * From majordomo-workers-owner Tue Sep 13 02:59:17 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id CAA16303; Tue, 13 Sep 1994 02:59:17 GMT Received: from mycroft.GreatCircle.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id TAA16293; Mon, 12 Sep 1994 19:59:10 -0700 Message-Id: <199409130259.TAA16293@mycroft.GreatCircle.COM> To: Arnold de Leon cc: barnhart@mcs.com (Aaron Barnhart), rouilj@cs.umb.edu, Majordomo-workers@greatcircle.com Subject: Re: "Approved" frenzies for big Majordomo lists (fwd) In-reply-to: Your message of Mon, 12 Sep 1994 17:34:19 -0700 Date: Mon, 12 Sep 1994 19:59:09 -0700 From: Brent Chapman Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk Arnold de Leon writes: # The problem is with the way majordomo does locking. # # If you have a large number of requests come together the # machine ends up thrasing. # # Here are the changes I made the locking to make friendlier # to the machine. This is pretty deep in the guts of Majordomo, so I've redirected this reply to Majordomo-Workers. Clearly something needs to be done about locking and thrashing in Majordomo, but I'm not sure this change (exponential backoff) isn't going to cause more problems than it solves. On my machine, each running Majordomo seems to account for about 8 MB of swap space, between the sendmail process and the perl process. Keep a few of these waiting around, and you're talking about a _lot_ of swap space tied up. On the other hand, I currently have to be careful not to issue more than 2 or 3 simultaneous "approve" commands, or the load on the machine goes through the roof and it starts thrashing anyway. The current locking mechanism doesn't even begin to preserve ordering of near-simultaneous requests. An exponential backoff is going to make the situation even worse for processes that are waiting for locks; they'll try less often for the lock, and end up waiting even longer. Essentially, what Majordomo has now is a spin lock. A better system would be either a wait lock, or some sort of queuing mechanism. A wait lock would not solve the swap space problem mentioned above, and you'd have to be careful of deadlock. Queuing would have to be done by Majordomo, not by the mail system, if you want to preserve ordering, and that adds a fair bit of complexity to Majordomo. On the other hand, I've long wished for a generalized queuing package written in perl, for a variety of different uses; anybody want to take up the challenge of writing such a package (or integrating an existing one) for Majordomo? Another change that needs to be made to the locking is what happens with permission problems. If it's a permission problem that's causing shlock to fail, it should say so and abort, rather than trying until it times out and then simply reporting "lock failure". -Brent -- Brent Chapman | Great Circle Associates | Call or email for info about Brent@GreatCircle.COM | 1057 West Dana Street | upcoming Internet Security +1 415 962 0841 | Mountain View, CA 94041 | Firewalls Tutorial dates From majordomo-workers-owner Tue Sep 13 14:38:51 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id OAA20409; Tue, 13 Sep 1994 14:38:51 GMT Received: from ideanet.doe.state.in.us by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id HAA20398; Tue, 13 Sep 1994 07:38:31 -0700 Received: from ima.isd.state.in.us by ideanet.doe.state.in.us (5.65/1.35) id AA05273; Tue, 13 Sep 94 09:32:07 -0500 Received: from ccMail by IMA.ISD.STATE.IN.US (IMA Internet Exchange) with VIM id e75baae0; Tue, 13 Sep 94 09:43:58 -0500 Mime-Version: 1.0 Date: Tue, 13 Sep 1994 09:43:27 -0500 Message-Id: From: "KEVIN_T._LIKES"@IMA.ISD.STATE.IN.US To: majordomo-workers@greatcircle.com Subject: Re: Majordomo Problem Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk This is a copy of a note I sent to John Rouillard and his reply to it. The only thing I guess I should add at this point is that I'm pretty sure that Majordomo doesn't handle double quoted strings inside of <>, since the pattern for removing double quoted strings from addresses doesn't take into account angle brackets. Kevin T. Likes ______________________________ Forward Header __________________________________ Subject: Re: Majordomo Problem Author: "John P. Rouillard" at IMA Date: 9/13/94 10:27 AM In message , "KEVIN_T._LIKES"@IMA.ISD.STATE.IN.US writes: >I apologize for sending this directly to you instead of to one of the >mailing lists, but the reason why will quickly become apparent. Actually, this should have gone to majordomo-workers@greatcircle.com This is the list where the developers live, and somebody may have a fix for it already. If you would post a copy of your email there and follow up, or include this reply I would appreciate it. >After some investigation, I have come to the conclusion that >Majordomo is mishandling some headers. The log file shows that my >address is "Kevin_T._Likes"@ima.isd.state.in.us which is indeed >correct. The problem is those quote marks. majordomo.pl assumes >that anything in double quotes in an address header is a comment and >can be ignored. They way I read RFC822 is that this is wrong. They >include an example something like "John Doe"@acme.com as a valid way >of quoting characters in an address. That quotes the space. I think rfc822 leaves it ambiguous as to whether "John_rouillard"@foo.com is valid since John_rouillard@foo.com is valid and is not ambiguous. Part of the problem is that your address should probably be enclosed in <>'s according to the newer standards, and I think majordomo handles that ok. But you are right, it needs a real rfc822 parser, and I think I have one that is available and I will put into the code for the next release if I get a chance. >I'm not sure what the best fix is (I'm going to look for a space >after the closing double quote), but this is something that should be >fixed in future versions because in the future many people will be >getting on the internet from packages like the CC:mail gateway. CC:mail's SMTP gateway needs lots of work and there really isn't anybody there who has a clue from what I can tell. -- John John Rouillard Senior Systems Administrator IDD Information Services rouilj@dstar.iddis.com Waltham, MA (617) 890-1576 x225 Senior Systems Consultant (SERL Project) University of Massachusetts at Boston rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480 =============================================================================== My employers don't acknowledge my existence much less my opinions. From majordomo-workers-owner Tue Sep 13 21:27:02 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id VAA24409; Tue, 13 Sep 1994 21:27:02 GMT Received: from chronos.synopsys.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id OAA24403; Tue, 13 Sep 1994 14:26:48 -0700 Received: from gaea.synopsys.com by chronos.synopsys.com with SMTP id AA25423 (5.65c/IDA-1.4.4 for ); Tue, 13 Sep 1994 14:32:14 -0700 Received: from atropos.synopsys.com by gaea.synopsys.com with SMTP id AA03194 (5.65c/IDA-1.4.4 for ); Tue, 13 Sep 1994 14:32:13 -0700 Received: from mango.synopsys.com (mango-backbone.synopsys.com [146.225.64.212]) by atropos.synopsys.com (8.6.9/8.6.9) with ESMTP id OAA17499 for ; Tue, 13 Sep 1994 14:32:10 -0700 Received: (from arnold@localhost) by mango.synopsys.com (8.6.9/8.6.9) id OAA01962 for majordomo-workers@greatcircle.com; Tue, 13 Sep 1994 14:32:09 -0700 Date: Tue, 13 Sep 1994 14:32:09 -0700 From: Arnold de Leon Message-Id: <199409132132.OAA01962@mango.synopsys.com> In-Reply-To: Brent Chapman "Re: "Approved" frenzies for big Majordomo lists (fwd)" (Sep 12, 7:59pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: majordomo-workers@greatcircle.com Subject: locking in the face of multiple subscribe requests Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk I don't believe ordering of near simultaneous commands to majordomo is important. First there is no guarantee anyway that two messages sent one after each other will be delivered to majordomo in the same order. This means that majordomo preserving the order adds little value. Majordomo already preserves ordering of multiple commands in the same message, although it does not guarantee that another command will not be executed in between. I am planning to write a "abort, retry" routine for majordomo (basically cleanup and exit EX_TEMPFAIL). so I that several failures can be retried Then I can have the lock failures optionally fail with "abort, retry". This would prevent too many processes from waiting for locks and taking up swap space. This has the advantage of using the queueing mechanism implemented by the mail system already. Lock failures should probably be noted with e-mail to the owner and/or sent to an external logging mechanism (such as syslog). Naturally this should be optional. Some observations and other data: o it takes aprox 20 seconds to process an {un}subscribe command on 3500+ address mailing list o The time to process an {un}subscribe command grows linearly with the size of the list. o the machine I use is a Solbourne S4000DX (aprox. a Sparcation 2 class machine) o multiple majordomo processes using spin locks causes enough trashing that a given subscribe call would timeout if several subscribe requests came in as separate messages. o The backoff that I implemented stops backing off at 60 seconds. o The first few retries will occur 1, 2 and 4 seconds later. This behaviour is similar to the spin locks in terms of responsives. o I believe that if the lock was not available after ~8 seconds then the resource is probably going to be unavailable for a while. o I have been running with the backoff code for over 6 weeks. It's definitely better than the old way. arnold From majordomo-workers-owner Tue Sep 13 21:57:36 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id VAA24707; Tue, 13 Sep 1994 21:57:36 GMT Received: from hub.ucsb.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id OAA24685; Tue, 13 Sep 1994 14:57:06 -0700 Received: from dokoka (dokoka.ucsb.edu) by hub.ucsb.edu; id AA24235 sendmail 4.1/UCSB-2.1-sun Tue, 13 Sep 94 15:02:25 PDT for brent@greatcircle.com Received: from localhost.ucsb.edu by dokoka via SMTP (931110.SGI/920502.SGI.v2) for @hub.ucsb.edu:Majordomo-workers@greatcircle.com id AA05843; Tue, 13 Sep 94 15:04:12 -0700 Message-Id: <9409132204.AA05843@dokoka> To: Brent Chapman Cc: Arnold de Leon , barnhart@mcs.com (Aaron Barnhart), rouilj@cs.umb.edu, Majordomo-workers@greatcircle.com Subject: Re: "Approved" frenzies for big Majordomo lists (fwd) Reply-To: "Alan K. Stebbens" Comments: Hyperbole mail buttons accepted, v3.15. Date: Tue, 13 Sep 1994 15:04:01 -0700 From: "Alan K. Stebbens " Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk > Clearly something needs to be done about locking and thrashing in > Majordomo, but I'm not sure this change (exponential backoff) isn't > going to cause more problems than it solves. This may be approaching heresey, but here goes: Have any of you considered integrating the Majordomo features into Manfredi's MailAgent package? Rafael has done considerable work in the "infrastructure" needed to support a generic mail server and filter, but as a mail server, it needs an "application" to build on top of it. IMHO, Majordomo would be a good such application. The win for Majordomo would be a fairly robust queueing mechanism and underlying infrastructure to support the mail server functions. Conceptually, it shouldn't be that hard: Mailagent is written in Perl, and has good support for Perl "hooks", with an optional C code interpreter for those who want it to go really fast, and don't have to worry about multiple architectures running the filter. I've done a *lot* of improvements to Majordomo, and am now at a nexus requiring a decision to either: a. submit my diffs to majordomo-workers for integration with Majordomo proper; b. migrate the features of Majordomo to another mail server "platform", which has the necessary support for heavily-used mailers. Any thoughts? Alan From majordomo-workers-owner Tue Sep 13 22:29:13 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id WAA25113; Tue, 13 Sep 1994 22:29:13 GMT Received: from bosnia.pop.psu.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id PAA25107; Tue, 13 Sep 1994 15:29:01 -0700 Received: from localhost (barr@localhost) by bosnia.pop.psu.edu (8.6.9/8.6.9) with ESMTP id SAA29728; Tue, 13 Sep 1994 18:34:18 -0400 Message-Id: <199409132234.SAA29728@bosnia.pop.psu.edu> To: eric.hammond@sdrc.com (Eric Hammond), Jared_Rhine@hmc.edu cc: majordomo-workers@GreatCircle.COM Subject: Re: X.400 address 'hostile' In-reply-to: Your message of "Tue, 13 Sep 1994 17:42:55 CDT." <9409132142.AA00388@sdrc.com> 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 Date: Tue, 13 Sep 1994 18:34:17 -0400 From: David Barr Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk (from majordomo-users) In message <9409132142.AA00388@sdrc.com>, Eric Hammond writes: >Jared: > >> Hogwash. > >Disagreed. (Obviously, or I would not have said what I said.) Hold it. You're both saying the same thing, yet say say you disagree. Read his message again. Jared and you are completely correct. I see absolutely no reason why Majordomo should enforce a policy which is does not apply to the system on which it runs. If "/" in an address is not a problem to the MTA, then it should be configurable for Majordomo to not complain about the address. Of course the existence of a password should not override a "hostile" address. An interesting alternative would be to forward the "hostile" address (when approved by the list manager) to Owner-Majordomo and require the the list manager manually add the address in the file. (via edit, not by e-mail approval) Replies to majordomo-workers, please. --Dave From majordomo-workers-owner Tue Sep 13 22:46:30 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id WAA25310; Tue, 13 Sep 1994 22:46:30 GMT Received: from osiris.ac.hmc.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id PAA25302; Tue, 13 Sep 1994 15:46:19 -0700 Received: (from jared@localhost) by osiris.ac.hmc.edu (8.6.8.1/8.6.7) id PAA28283; Tue, 13 Sep 1994 15:51:48 -0700 Date: Tue, 13 Sep 1994 15:51:48 -0700 Message-Id: <199409132251.PAA28283@osiris.ac.hmc.edu> From: Jared_Rhine@hmc.edu To: eric.hammond@sdrc.com (Eric Hammond), David Barr , majordomo-workers@GreatCircle.COM Subject: Re: X.400 address 'hostile' References: <9409132142.AA00388@sdrc.com> <199409132234.SAA29728@bosnia.pop.psu.edu> <199409131915.MAA13695@osiris.ac.hmc.edu> X-Attribution: JRhine Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk --> EH == Eric Hammond --> DB == David Barr JRhine> The possibility that a slash in an e-mail address can open a hole is JRhine> entirely MTA-dependent. EH> Agreed. JRhine> Majordomo shouldn't be enforcing policy decisions that I, as system JRhine> manager, disagree with. EH> What about this is a policy decision? As Dave says: DB> If "/" in an address is not a problem to the MTA, then it should be DB> configurable for Majordomo to not complain about the address. which agrees with your statement: EH> If you don't have the particular '/' hole in your MTA, then I would say EH> that it is perfectly acceptable for you or a majordomo configuration EH> option to remove that particular check from &valid_addr(). So let's add a configuration option. Sorry if my intent wasn't clear. I've argued before that Majordomo should be as flexible as possible; I'll argue it again, I suppose. EH> Note, however, that other checks currently exist there and more may be EH> added in the future. Right, and any that are not obviously applicable to all sites should be configuration options, not hard-wired policy decisions. Jeez, I've heard of agreeing to disagree, but never disagreeing to agree :) -- Jared_Rhine@hmc.edu | Harvey Mudd College | http://www.hmc.edu/~jared/home.html "Society in every state is a blessing, but Government, even in its best state, is but a necessary evil; in its worst state, an intolerable one." -- Thomas Paine From majordomo-workers-owner Tue Sep 13 22:59:02 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id WAA25376; Tue, 13 Sep 1994 22:59:02 GMT Received: from nda.nda.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id PAA25370; Tue, 13 Sep 1994 15:58:53 -0700 Received: from localhost (kovar@localhost) by nda.nda.com (8.6.4/8.6.4) id TAA03433; Tue, 13 Sep 1994 19:03:37 -0400 From: David Kovar Message-Id: <199409132303.TAA03433@nda.nda.com> Subject: Re: X.400 address 'hostile' To: Jared_Rhine@hmc.edu Date: Tue, 13 Sep 1994 19:03:35 -0400 (EDT) Cc: eric.hammond@sdrc.com, barr@pop.psu.edu, majordomo-workers@GreatCircle.COM In-Reply-To: <199409132251.PAA28283@osiris.ac.hmc.edu> from "Jared_Rhine@hmc.edu" at Sep 13, 94 03:51:48 pm X-Mailer: ELM [version 2.4 PL20] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 446 Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk > EH> Note, however, that other checks currently exist there and more may be > EH> added in the future. > > Right, and any that are not obviously applicable to all sites should be > configuration options, not hard-wired policy decisions. I'd add that the options should default to 'on' and can be turned 'off' by using the switches or config file. That way, anyone who gets hit because the option is not enabled did it to themselves. -David From majordomo-workers-owner Wed Sep 14 02:55:51 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id CAA26624; Wed, 14 Sep 1994 02:55:51 GMT Received: from mycroft.GreatCircle.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id TAA26617; Tue, 13 Sep 1994 19:55:44 -0700 Message-Id: <199409140255.TAA26617@mycroft.GreatCircle.COM> To: Arnold de Leon cc: majordomo-workers@greatcircle.com Subject: Re: locking in the face of multiple subscribe requests In-reply-to: Your message of Tue, 13 Sep 1994 14:32:09 -0700 Date: Tue, 13 Sep 1994 19:55:42 -0700 From: Brent Chapman Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk Arnold de Leon writes: # I don't believe ordering of near simultaneous commands to # majordomo is important. I was actually thinking of ordering of postings via "resend", which can be somewhat important to preserving the semantic thread of a conversation. I agree that ordering of commands isn't important. In looking at it a little, it appears that "resend" doesn't use the locking open anyway; nor can I think of any reason why it should. So, just ignore what I said yesterday; it don't make no sense... Chalk it up to staying up too late at Interop. # I am planning to write a "abort, retry" # routine for majordomo (basically cleanup and exit EX_TEMPFAIL). # so I that several failures can be retried # Then I can have the lock failures optionally fail with # "abort, retry". This would prevent too many processes from # waiting for locks and taking up swap space. # # This has the advantage of using the queueing mechanism # implemented by the mail system already. Do mailers other than sendmail pay attention to EX_TEMPFAIL? # Some observations and other data: # # o it takes aprox 20 seconds to process an {un}subscribe # command on 3500+ address mailing list # # o The time to process an {un}subscribe command # grows linearly with the size of the list. # # o the machine I use is a Solbourne S4000DX (aprox. a # Sparcation 2 class machine) # # o multiple majordomo processes using spin locks # causes enough trashing that a given subscribe # call would timeout if several subscribe # requests came in as separate messages. # # o The backoff that I implemented stops backing # off at 60 seconds. # # o The first few retries will occur 1, 2 and 4 seconds # later. This behaviour is similar to the spin locks # in terms of responsives. # # o I believe that if the lock was not available after # ~8 seconds then the resource is probably going to be # unavailable for a while. # # o I have been running with the backoff code for over # 6 weeks. It's definitely better than the old way. Cool; it's clear that you've done a lot more work on this than I have, and I was somewhat confused anyway, so never mind my earlier comments. I _still_ want someone to implement (or point me to) a general queue package in Perl, though... :-) -Brent -- Brent Chapman | Great Circle Associates | Call or email for info about Brent@GreatCircle.COM | 1057 West Dana Street | upcoming Internet Security +1 415 962 0841 | Mountain View, CA 94041 | Firewalls Tutorial dates From majordomo-workers-owner Wed Sep 14 03:54:56 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id DAA27261; Wed, 14 Sep 1994 03:54:56 GMT Received: from osiris.ac.hmc.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id UAA27254; Tue, 13 Sep 1994 20:54:46 -0700 Received: (from jared@localhost) by osiris.ac.hmc.edu (8.6.8.1/8.6.7) id VAA18402; Tue, 13 Sep 1994 21:00:18 -0700 Date: Tue, 13 Sep 1994 21:00:18 -0700 Message-Id: <199409140400.VAA18402@osiris.ac.hmc.edu> From: Jared_Rhine@hmc.edu To: Arnold de Leon Cc: majordomo-workers@GreatCircle.COM Subject: locking in the face of multiple subscribe requests References: <199409132132.OAA01962@mango.synopsys.com> X-Attribution: JRhine Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk AdL == Arnold de Leon AdL> I don't believe ordering of near simultaneous commands to majordomo is AdL> important. But resource starvation is. On a heavily-loaded machine, it's not out of the question that a command might fail because every time it tries to get the lock, some newer process has it, instead. The problem is compounded by an exponential backoff because the older the process, the less frequently it will attempt the lock, meaning that young, whipper-snapper processes are more likely to obtain the lock. Majordomo design needs to think more about scalability. I'm currently having a bitch of a time because a single 'lists' command on an unloaded machine is starting to push 10 minutes to complete. We've got 190 lists, and a 'lists' command has to run a 'get_config' for each, which is an enormously expensive process. I'm thinking that I may implement the config variables in a dbm file, allowing me to go straight to the variable I want without any extraneous parsing. I don't know how this can be modularized into the majordomo design - it probably won't be too bad since I can just write a drop-in replacement for &get_config. Any comments on this, or other ideas about how to speed up &get_config by at least an order of magnitude? -- Jared_Rhine@hmc.edu | Harvey Mudd College | http://www.hmc.edu/~jared/home.html "A great many people think they are thinking when they are merely rearranging their prejudices." -- William James From majordomo-workers-owner Wed Sep 14 05:12:10 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id FAA27797; Wed, 14 Sep 1994 05:12:10 GMT Received: from gateway.sandelman.ocunix.on.ca by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id WAA27790; Tue, 13 Sep 1994 22:11:56 -0700 Received: from latour.sandelman.ocunix.on.ca (root@latour.sandelman.ocunix.on.ca [192.139.46.129]) by gateway.sandelman.ocunix.on.ca (8.6.9/8.6.9) with SMTP id BAA16705 for ; Wed, 14 Sep 1994 01:08:40 -0400 Received: from localhost by latour.sandelman.ocunix.on.ca with SMTP id AA11165 sender mcr@latour.sandelman.ocunix.on.ca (5.65a/IDA-1.4.2); Wed, 14 Sep 94 00:58:07 -0400 Message-Id: <9409140458.AA11165@latour.sandelman.ocunix.on.ca> To: majordomo-workers@greatcircle.com Subject: Re: locking in the face of multiple subscribe requests In-Reply-To: Your message of "Tue, 13 Sep 1994 21:00:18 PDT." <199409140400.VAA18402@osiris.ac.hmc.edu> Date: Wed, 14 Sep 1994 00:58:06 -0400 From: Michael Richardson Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk It seems to me that the locking code should try two or three times, and if it fails could: exit (EX_TEMPFAIL); sendmail will requeue the message for later deliver (hopefully during a queue run, which nicely serializes things). I believe that smail 3.x also understands such things. Alternatively, it could open a file in a directory, drop the whole message into that file (include pid to make name unique, I assume no one runs multiple majordomos on NFS mounted directories, otherwise, you'll need a lock for that too), and let a subsequent majordomo queue run (from cron) handle them. i.e. do our own queueing. Actually, some people might want to do this *all* the time to reduce load if latency isn't an issue. [UUCP sites have such high latency anyway...] :!mcr!: | "Elegant and extremely rapid for calculation are the Michael Richardson | techniques of Young tableaux. They also have the merit NCF: aa714 || xx714 /of being fun to play with." - p.47 Intro to Quarks&Partons Home: mcr@sandelman.ocunix.on.ca. PGP key available. From majordomo-workers-owner Wed Sep 14 13:51:17 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id NAA01227; Wed, 14 Sep 1994 13:51:17 GMT Received: from bosnia.pop.psu.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id GAA01221; Wed, 14 Sep 1994 06:50:53 -0700 Received: from localhost (barr@localhost) by bosnia.pop.psu.edu (8.6.9/8.6.9) with ESMTP id JAA07369 for ; Wed, 14 Sep 1994 09:56:04 -0400 Message-Id: <199409141356.JAA07369@bosnia.pop.psu.edu> To: majordomo-workers@greatcircle.com Subject: a faster get_config In-reply-to: Your message of "Tue, 13 Sep 1994 21:00:18 PDT." <199409140400.VAA18402@osiris.ac.hmc.edu> 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 Date: Wed, 14 Sep 1994 09:56:02 -0400 From: David Barr Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk In message <199409140400.VAA18402@osiris.ac.hmc.edu>, Jared_Rhine@hmc.edu write s: >machine is starting to push 10 minutes to complete. We've got 190 lists, >and a 'lists' command has to run a 'get_config' for each, which is an >enormously expensive process. Yeah, I've often thought if I had to re-implement Majordomo from scratch, I'd to the configuration stuff differently. Instead of a config file, you'd assign each list a directory, and make the configuration keywords files. For the sake of illustration, call it $listdir. So, for "widget-lovers", you'd have "/var/lists/widget-lovers/" or something. To read the list of members of the list, you'd read $listdir/list. (this is what the sendmail alias would use) To find out the owner(s) of the list, you'd read $listdir/owner, similiarly say $listdir/moderator, $listdir/approval. These would :include: files for the standard aliases for the list. This would always allow list owners the ability to change them, as well as make it as easy to have multiple owner/approvers/moderators as one, and WITHOUT having to create yet another Majordomo list. The "description" string would be $listdir/description. To find any information about a list, it's just an open()/read()/close(). Rarely do you ever need to access out _all_ information about a list, only when doing a config or newconfig. The config/newconfig commands would just slurp up all the files into one configuration file, and conversly explode a new configuration file into all the files. Doing headers and footers becomes really easy since you just have to append/prepend $listdir/header $listdir/footer To do the "lists" command, it would be one readdir() and N open()/read()/ close()'s. Still not very fast, but Majordomo could do some caching for special expensive operations like "lists" by writing the "lists" output in a file, and updating the cache whenever a list is added or when a "newinfo" or "newconfig" command is done. One easy way to do digests would be to have simply $listdir/digest/list, which would contain the list of people subscribed to the digest. $listdir/digest/options or something could contain all the stuff about when to send out digests. You'd have also $listdir/digest/header and $listdir/digest/footer, $listdir/digest/volume, etc. You'd still have to have some configuration files for certain things I think. There are so many options to majordomo now for resend with little stuff like reply_to, resend_host, and subject_prefex that it makes sense to put those together in some fast easy-to-parse format. Just some ideas. --Dave From majordomo-workers-owner Wed Sep 14 13:52:34 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id NAA01262; Wed, 14 Sep 1994 13:52:34 GMT Received: from cs.umb.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id GAA01250; Wed, 14 Sep 1994 06:52:17 -0700 Received: from terminus.cs.umb.edu by cs.umb.edu with SMTP id AA20505 (5.65c/IDA-1.4.4 for ); Wed, 14 Sep 1994 09:57:14 -0400 Message-Id: <199409141357.AA20505@cs.umb.edu> To: Jared_Rhine@hmc.edu Cc: Arnold de Leon , majordomo-workers@greatcircle.com Subject: Re: locking in the face of multiple subscribe requests In-Reply-To: Your message of "Tue, 13 Sep 1994 21:00:18 PDT." <199409140400.VAA18402@osiris.ac.hmc.edu> Date: Wed, 14 Sep 1994 09:57:10 -0400 From: "John P. Rouillard" Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk In message <199409140400.VAA18402@osiris.ac.hmc.edu>, Jared_Rhine@hmc.edu writes: >AdL == Arnold de Leon > >AdL> I don't believe ordering of near simultaneous commands to majordomo is >AdL> important. > >But resource starvation is. On a heavily-loaded machine, it's not >out of the question that a command might fail because every time it tries to >get the lock, some newer process has it, instead. The problem is compounded >by an exponential backoff because the older the process, the less frequently >it will attempt the lock, meaning that young, whipper-snapper processes are >more likely to obtain the lock. > >Majordomo design needs to think more about scalability. I'm currently >having a bitch of a time because a single 'lists' command on an unloaded >machine is starting to push 10 minutes to complete. We've got 190 lists, >and a 'lists' command has to run a 'get_config' for each, which is an >enormously expensive process. I'm thinking that I may implement the config >variables in a dbm file, allowing me to go straight to the variable I want >without any extraneous parsing. I don't know how this can be modularized >into the majordomo design - it probably won't be too bad since I can just >write a drop-in replacement for &get_config. Any comments on this, or other >ideas about how to speed up &get_config by at least an order of magnitude? Try turning off the validity checks in the interior loop unless you are in a newconfig operation. It uses the following code segment: if (defined($main'config_opts{$list,$key})) { $main'config_opts{$list,$key} .= "\001" . &$parse($value, $list, $key); } else { # we are starting an array $main'config_opts{$list,$key} = &$parse($value, $list, $key); this is unecessary iff all of the config files are installed using newconfig. You just need to add a parameter that says yes or no to the config code, and then create some generic (non checking) parse function that spits back the arguments as required. This is the first place I would look. I think dbm files are the wrong approach since there is no way for perl to tell if the dbm file is of the wrong byte order, and perl just crashes stupidly. I know of a number of sites whose backup mail hub is of different endidness from their primary, I have two sites that run that way myself. If the dbm files could be discovered to be of the wrong endidness before perl coredumps, and the regular config files were used instead, then the dbm file idea is great. Don't forget to compare the touch dates of the config files against the touch dates of the dbm files. As an alternate idea, how about a cache file (written in perl) that holds all of the contents of the config file(s). That way you just require the file, and the parsing overhead that goes on isn't necessary anymore. It would be pretty easy to do, actually you could have one cache file for all lists since the config files don't change that often. To write the cache file just do a loop like: foreach i (keys %config_opts) { print CACHE "\$config_opts{$i} =\"" . $config_opts{$key} . '"'; } Or something like that. -- John John Rouillard Senior Systems Administrator IDD Information Services rouilj@dstar.iddis.com Waltham, MA (617) 890-1576 x225 Senior Systems Consultant (SERL Project) University of Massachusetts at Boston rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480 =============================================================================== My employers don't acknowledge my existence much less my opinions. From majordomo-workers-owner Wed Sep 14 16:02:54 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id QAA02454; Wed, 14 Sep 1994 16:02:54 GMT Received: from cs.umb.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id JAA02448; Wed, 14 Sep 1994 09:02:44 -0700 Received: from terminus.cs.umb.edu by cs.umb.edu with SMTP id AA06823 (5.65c/IDA-1.4.4 for ); Wed, 14 Sep 1994 12:07:08 -0400 Message-Id: <199409141607.AA06823@cs.umb.edu> To: David Barr Cc: majordomo-workers@greatcircle.com Subject: Re: a faster get_config In-Reply-To: Your message of "Wed, 14 Sep 1994 09:56:02 EDT." <199409141356.JAA07369@bosnia.pop.psu.edu> Date: Wed, 14 Sep 1994 12:07:03 -0400 From: "John P. Rouillard" Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk In message <199409141356.JAA07369@bosnia.pop.psu.edu>, David Barr writes: >In message <199409140400.VAA18402@osiris.ac.hmc.edu>, >Jared_Rhine@hmc.edu writes: >>machine is starting to push 10 minutes to complete. We've got 190 >>lists, and a 'lists' command has to run a 'get_config' for each, >>which is an enormously expensive process. >Yeah, I've often thought if I had to re-implement Majordomo from >scratch, I'd to the configuration stuff differently. > >Instead of a config file, you'd assign each list a directory, >and make the configuration keywords files. One of the goals of the config file was to present a simple (well it was in the beginning) and consistant mechanism for updating and querying options for the list. With just two commands you can update the info, and query the info. This is in contrast to having the bunches of small files all over the place where you would have a rats next of commands to update each file. I really did want the interface to mimic the structure of files that contained the information, so having a config file interface that split the info out into subfiles wasn't really what I wanted. -- John John Rouillard Senior Systems Administrator IDD Information Services rouilj@dstar.iddis.com Waltham, MA (617) 890-1576 x225 Senior Systems Consultant (SERL Project) University of Massachusetts at Boston rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480 =============================================================================== My employers don't acknowledge my existence much less my opinions. From majordomo-workers-owner Fri Sep 16 04:36:38 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id KAA20865; Fri, 16 Sep 1994 10:07:16 GMT Received: from convex.csc.fi by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id DAA20858; Fri, 16 Sep 1994 03:06:52 -0700 Received: (from ukkonen@localhost) by convex.csc.fi (8.6.9/8.6.9+CSC-2.0) id NAA04588 for majordomo-workers@greatcircle.com; Fri, 16 Sep 1994 13:12:25 +0300 From: Jukka Ukkonen Message-Id: <199409161012.NAA04588@convex.csc.fi> Subject: Weird mailer error caused by majordomo... To: majordomo-workers@greatcircle.com Date: Fri, 16 Sep 1994 13:12:23 +0300 (EET DST) Latin-Date: Vineri XVI Septembrie a.d. MCMXCIV Organization: Centre for Scientific Computing (CSC) Phone: +358-0-4573208 (work) X400-From: /G=Jukka/S=Ukkonen/O=csc/ADMD=fumail/C=fi/ X-Editor: jove X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1539 Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk Hello everybody! I got a weird error message from sendmail when I sent a "which" message to our majordomo. The directory it complains about is the directory under which are all the list files. The funniest thing in this is that it really also sent the correct reply to my which query and the lists directory has the following protections. drwxrwxr-x 2 majordomomajordomo 3584 Sep 16 11:00 lists/ Here is the unexpected error. What should I do about it? Quoting Mail Delivery Subsystem: # # The original message was received at Fri, 16 Sep 1994 11:00:39 +0300 # from convex.csc.fi [128.214.46.5] # # ----- The following addresses had delivery problems ----- # "|/usr/local/lib/majordomo/wrapper majordomo" (unrecoverable error) # (expanded from: ) # # ----- Transcript of session follows ----- # Message delivered to mailing list # Can't open list /usr/local/lib/mail/lists/ # ABORT Can't open list /usr/local/lib/mail/lists/ at /usr/local/lib/majordomo/majordomo.pl line 209. # 554 "|/usr/local/lib/majordomo/wrapper majordomo"... unknown mailer error 9 BTW... Our sendmail is version 8.6.9 in case this could have something to do with the error. Cheers, // jau ------ / Jukka A. Ukkonen, M.Sc. (tech.) Centre for Scientific Computing /__ Internet: ukkonen@csc.fi Tel: (Home) +358-0-578628 / Internet: jau@cs.tut.fi (Work) +358-0-4573208 v X.400: c=fi, admd=fumail, no prmd, org=csc, pn=jukka.ukkonen From majordomo-workers-owner Sat Sep 17 02:27:58 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id CAA00561; Sat, 17 Sep 1994 02:27:58 GMT Received: from cs.umb.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id TAA00550; Fri, 16 Sep 1994 19:27:43 -0700 Received: from terminus.cs.umb.edu by cs.umb.edu with SMTP id AA13947 (5.65c/IDA-1.4.4 for ); Fri, 16 Sep 1994 22:32:33 -0400 Message-Id: <199409170232.AA13947@cs.umb.edu> To: "Alan K. Stebbens" Cc: Arnold de Leon , barnhart@mcs.com (Aaron Barnhart), Majordomo-workers@greatcircle.com Subject: Re: "Approved" frenzies for big Majordomo lists (fwd) In-Reply-To: Your message of "Tue, 13 Sep 1994 15:04:01 PDT." <9409132204.AA05843@dokoka> Date: Fri, 16 Sep 1994 22:32:27 -0400 From: "John P. Rouillard" Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk In message <9409132204.AA05843@dokoka>, "Alan K. Stebbens " writes: >> Clearly something needs to be done about locking and thrashing in >> Majordomo, but I'm not sure this change (exponential backoff) isn't >> going to cause more problems than it solves. > >This may be approaching heresey, but here goes: No more sacrilidge (sp?) 8-). >Have any of you considered integrating the Majordomo features into >Manfredi's MailAgent package? Rafael has done considerable work in the >"infrastructure" needed to support a generic mail server and filter, but >as a mail server, it needs an "application" to build on top of it. >IMHO, Majordomo would be a good such application. > >The win for Majordomo would be a fairly robust queueing mechanism and >underlying infrastructure to support the mail server functions. > >Conceptually, it shouldn't be that hard: Mailagent is written in Perl, >and has good support for Perl "hooks", with an optional C code >interpreter for those who want it to go really fast, and don't have to >worry about multiple architectures running the filter. Hmm interesting idea. Do you have an ftp site for this. It might be useful as a base for 2.0. >I've done a *lot* of improvements to Majordomo, and am now at a nexus >requiring a decision to either: > >a. submit my diffs to majordomo-workers for integration with Majordomo > proper; Actually you want to send them to me as well as majordomo-workers. While I try to pick stuff off of majordomo workers, I don't always suceed, and if I don't see it, it doesn't go into majordomo. Judging from some other code patches, 1.93 will be a really interesting release with some performance improvements. -- John John Rouillard Senior Systems Administrator IDD Information Services rouilj@dstar.iddis.com Waltham, MA (617) 890-1576 x225 Senior Systems Consultant (SERL Project) University of Massachusetts at Boston rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480 =============================================================================== My employers don't acknowledge my existence much less my opinions. From majordomo-workers-owner Tue Sep 20 02:51:07 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id CAA28293; Tue, 20 Sep 1994 02:51:07 GMT Received: from unpc.queernet.org by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id TAA28287; Mon, 19 Sep 1994 19:50:43 -0700 Received: by unpc.queernet.org (Smail3.1.28.1 #9) id m0qmvLr-00014wC; Mon, 19 Sep 94 19:54 PDT Message-Id: To: majordomo-workers@greatcircle.com Subject: Error handling for full disks? Date: Mon, 19 Sep 1994 19:54:26 -0700 From: "Roger B.A. Klorese" Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk Has anyone done anything to handle the inability to roll a digest number, wiping out and overwriting archived issues, if a disk fills? --- ROGER B.A. KLORESE rogerk@QueerNet.ORG 2215-R Market Street #576 San Francisco, CA 94114 +1 415 ALL-ARFF "There is only one real blasphemy: the refusal of joy." -- Paul Rudnick From majordomo-workers-owner Thu Sep 22 05:43:53 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id FAA22291; Thu, 22 Sep 1994 05:43:53 GMT Received: from oulu.fi by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id WAA22285; Wed, 21 Sep 1994 22:43:44 -0700 Received: from paju.oulu.fi by oulu.fi (4.1/SMI-4.1) id AA24308; Thu, 22 Sep 94 08:49:33 +0300 Received: by paju.oulu.fi (931110.SGI/930416.SGI.AUTO) for @ousrvr.oulu.fi:majordomo-workers@greatcircle.com id AA24986; Thu, 22 Sep 94 08:49:32 +0300 Date: Thu, 22 Sep 1994 08:49:30 +0200 From: Marko Hotti To: majordomo-users@greatcircle.com Cc: majordomo-workers@greatcircle.com Subject: Three questions: Message-Id: Organization: University of Oulu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk Question I: =========== I'd like to forward all the messages for my list to a local newsgroup. When using normal mail aliasing, it is possible to add commands to the delivery list ("|/path/command arguments") but is this possible with Majordomo and wrapper/resend commands? I don't want to mess up the system so I ask you. Question II: ============ If it is possible to forward list traffic to a newsgroup, which command do you suggest? An example would be appreciated. Question III: ============= I have asked this one before but no one answered (please: no flames!) I want to put the subjects of the digested messages to the beginning of the digest - like this: In this issue: Subject 1 Subject 2 Subject 3 In the Majordomo-1.92.README there *is* a perl script for message_fronter and message_footer to do this, but the instructions are nearly non- existent as to how to add the lines to the listname-digest.config file. Is the answer there or what else do I need? -Marko- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Marko Hotti University of Oulu Tervontie 4 C 11 Faculty of Medicine FIN-90230 OULU Tel: Int +385-(9)81-530 4878 From majordomo-workers-owner Wed Sep 28 04:54:17 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id EAA17223; Wed, 28 Sep 1994 04:54:17 GMT Received: from netcom11.netcom.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id VAA17217; Tue, 27 Sep 1994 21:54:06 -0700 Received: by netcom11.netcom.com (8.6.9/Netcom) id VAA10724; Tue, 27 Sep 1994 21:29:10 -0700 From: lcrocker@netcom.com (Lee Daniel Crocker) Message-Id: <199409280429.VAA10724@netcom11.netcom.com> Subject: Disabling "who" command To: majordomo-workers@greatcircle.com Date: Tue, 27 Sep 1994 21:29:10 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 732 Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk I own a list on Netcom, and I need to be able to disable the "who" command entirely for this list. I cannot modify the source, because the site is administered by Netcom, not me. But I could certainly talk them into getting the latest version from you. I am willing to pay for some development time to fix this problem, because it is critical to the list--If I can't disable the "who" command, then I will have to find a new Internet site and new mailing list software, and I really don't want to do that. Please give me an idea about what you or I might do to fix this. -- Lee Daniel Crocker /(o\ "When people are influenced by rulers, they follow lcrocker@netcom.com \o)/ what the rulers do, not what they say."--Huainanzi From majordomo-workers-owner Wed Sep 28 04:37:18 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id KAA19015; Wed, 28 Sep 1994 10:08:47 GMT Received: from ns1.ixa.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id DAA19009; Wed, 28 Sep 1994 03:08:38 -0700 Received: by ns1.ixa.com (Smail3.1.28.1 #13) id m0qpvzW-00000nC; Wed, 28 Sep 94 03:12 PDT Message-Id: To: majordomo-workers@greatcircle.com Subject: majordomo 2.0 rewrite specification... X-Mailer: MH 6.8.3 X-Discordia: Hail Eris - keep up OM Organization: Discordian Alliance For Teaching From: "Torin/Darren/Who Ever..." Date: Wed, 28 Sep 1994 03:12:01 -0700 Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk I can't seem to find the majordomo 2.0 rewrite specification anywhere in the distribution or in the ftp site. I have gone through the archive files; hoping that this isn't necessary. Where might I find it?? Torin From majordomo-workers-owner Fri Sep 30 16:48:46 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id QAA21560; Fri, 30 Sep 1994 16:48:46 GMT Received: from freeside.fc.net by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-940829) id JAA21554; Fri, 30 Sep 1994 09:48:35 -0700 Received: (from kevintx@localhost) by freeside.fc.net (8.6.8.1/8.6.6) id LAA17155 for majordomo-workers@greatcircle.com; Fri, 30 Sep 1994 11:52:00 -0500 From: Admin/Support Message-Id: <199409301652.LAA17155@freeside.fc.net> Subject: Using "noadvertise" To: majordomo-workers@greatcircle.com Date: Fri, 30 Sep 1994 11:52:00 -0500 (CDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 450 Sender: Majordomo-Workers-Owner@GreatCircle.COM Precedence: bulk Can anyone tell me what "noadvertise" line would make a list never show up on the "lists" command? I couldn't find any examples of how to do this.. I tried: noadvertise * << END END But it didn't make a difference.. I'm sure I'm missing something small here. thanks a lot, kevin -- kevintx@fc.net support@fc.net (see also kevintx@paranoia.com) Freeside Communications (512) 339-6094 *Internet Access for the Future!*