From majordomo-workers-owner Sun Oct 1 13:03:31 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id MAA07307; Sun, 1 Oct 2000 12:50:51 -0700 (PDT) Received: from rina.torah.org (rina.torah.org [208.229.147.50]) by honor.greatcircle.com (Postfix) with ESMTP id 3041117E8B; Sun, 1 Oct 2000 12:50:42 -0700 (PDT) Received: from localhost (brozen@localhost) by rina.torah.org (8.9.3/8.9.3/Debian/GNU) with ESMTP id QAA11655; Sun, 1 Oct 2000 16:10:50 -0400 Date: Sun, 1 Oct 2000 22:10:50 +0200 (IST) From: Brock Rozen To: "Roger B.A. Klorese" Cc: The Hermit Hacker , Mills CP , "'majordomo-users@greatcircle.com'" , "'majordomo-workers@greatcircle.com'" Subject: Re: The future of Majordomo In-Reply-To: Message-ID: X-Backup: Disabled MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On Fri, 29 Sep 2000 at 07:00, Roger B.A. Klorese wrote about "Re: The...": > > Aren't Hotmail and others like it sufficient? > > Not to them. They like the eGroups model. I can see that. Listen, I'm not against more features. But I don't think implementing "eGroups" should be a show-stopper! That's definitely a version 2 feature! -- Brock Rozen brozen@torah.org From majordomo-workers-owner Sun Oct 1 13:33:30 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id NAA07601; Sun, 1 Oct 2000 13:29:21 -0700 (PDT) Received: from castro.queernet.org (castro.queernet.org [209.157.101.253]) by honor.greatcircle.com (Postfix) with ESMTP id 750AC17E8B; Sun, 1 Oct 2000 13:29:13 -0700 (PDT) Received: from localhost (rogerk@localhost) by castro.queernet.org (8.10.0.Beta6/8.10.0.Beta6) with ESMTP id e91Kok905095 Date: Sun, 1 Oct 2000 13:50:46 -0700 (PDT) From: "Roger B.A. Klorese" To: Brock Rozen Cc: The Hermit Hacker , Mills CP , "'majordomo-users@greatcircle.com'" , "'majordomo-workers@greatcircle.com'" Subject: Re: The future of 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, 1 Oct 2000, Brock Rozen wrote: > I can see that. Listen, I'm not against more features. But I don't think > implementing "eGroups" should be a show-stopper! > > That's definitely a version 2 feature! I couldn't agree more. However, one thing came to mind looking at the web GUI (which is far, far stornger than I ever thought it could be by now) that goes along with my earlier arguments. Developers tend to write GUIs that are really config file editors, providing a point-and-click interface which requires you to understand the underlying config variables, instead of the actions they control. An example: in the part where you determine which aliases are available, even though the config takes one-letter entries, why doesn't the GUI form list the mhole option? Or, going all the way to the task orientation, why not a check box for "Users should be able to send mail to LISTNAME-subscribe to be added to the list and to LISTNAME-unsubscribe" to be removed"? -- ROGER B.A. KLORESE rogerk@QueerNet.ORG PO Box 14309 San Francisco, CA 94114 "There is only one real blasphemy -- the refusal of joy!" -- Paul Rudnick From majordomo-workers-owner Sun Oct 1 16:18:31 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id QAA08874; Sun, 1 Oct 2000 16:16:14 -0700 (PDT) Received: from epithumia.math.uh.edu (epithumia.math.uh.edu [129.7.128.2]) by honor.greatcircle.com (Postfix) with ESMTP id A4A9D17E8B; Sun, 1 Oct 2000 16:16:05 -0700 (PDT) Received: (from tibbs@localhost) by epithumia.math.uh.edu (8.9.3/8.9.3) id SAA06196; Sun, 1 Oct 2000 18:37:44 -0500 To: majordomo-users@GreatCircle.COM, majordomo-workers@GreatCircle.COM Cc: mj2-dev@csf.colorado.edu Subject: Re: The future of Majordomo References: From: Jason L Tibbitts III Date: 01 Oct 2000 18:37:44 -0500 In-Reply-To: "Roger B.A. Klorese"'s message of "Sun, 1 Oct 2000 13:50:46 -0700 (PDT)" Message-ID: Lines: 20 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "RBAK" == Roger B A Klorese writes: RBAK> An example: in the part where you determine which aliases are RBAK> available, even though the config takes one-letter entries, why RBAK> doesn't the GUI form list the mhole option? Time. I sent out a proposal for changing the way 'aliases' works yesterday. RBAK> Or, going all the way to the task orientation, why not a check box RBAK> for "Users should be able to send mail to LISTNAME-subscribe to be RBAK> added to the list and to LISTNAME-unsubscribe" to be removed"? I agree fully. But now you're getting into the "refinements" stage where before we were in the "get some kind of web interface" stage. Keep bringing these kinds of things up, and keep a list if you like. Working on things like this would be a great way for someone who wants to contribute to get involved. - J< From majordomo-workers-owner Sun Oct 1 17:33:33 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id RAA09424; Sun, 1 Oct 2000 17:23:14 -0700 (PDT) Received: from castro.queernet.org (castro.queernet.org [209.157.101.253]) by honor.greatcircle.com (Postfix) with ESMTP id BCAEC17E8B; Sun, 1 Oct 2000 17:23:02 -0700 (PDT) Received: from localhost (rogerk@localhost) by castro.queernet.org (8.10.0.Beta6/8.10.0.Beta6) with ESMTP id e920if809164 Date: Sun, 1 Oct 2000 17:44:41 -0700 (PDT) From: "Roger B.A. Klorese" To: Jason L Tibbitts III Cc: majordomo-users@GreatCircle.COM, majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu Subject: Re: The future of 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 1 Oct 2000, Jason L Tibbitts III wrote: > I agree fully. But now you're getting into the "refinements" stage where > before we were in the "get some kind of web interface" stage. Keep > bringing these kinds of things up, and keep a list if you like. Working on > things like this would be a great way for someone who wants to contribute > to get involved. Cool. I am willing to track a list for user interface requirements (yeah, yeah, I know it's a domineering term, but it maps well to the input phase), and serve as a focus for a simplified and task-oriented end-user and administrative usage model. I know we won't get there in a single release, but since it's what I do for a day-job, it's an area I can add value. Y'know, as of a month ago, I was totally over Mj2, even though I've been following the -workers list for years. Since I've contemplated other alternatives -- mailman, a few commercial products -- I see how well things have been implemented here, and want to adopt Mj2. (Please count this as a voice toward getting a 2.0 beta -- or even better in some ways, an Mj2 1.0 beta -- out soon, despite the fact that I desperately need the UI work to move ahead as well.) But it's going to take the simplification of the UI to get there, and I'm ready to help. -- ROGER B.A. KLORESE rogerk@QueerNet.ORG PO Box 14309 San Francisco, CA 94114 "There is only one real blasphemy -- the refusal of joy!" -- Paul Rudnick From majordomo-workers-owner Sun Oct 1 20:19:05 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id UAA10930; Sun, 1 Oct 2000 20:09:38 -0700 (PDT) Received: from castro.queernet.org (castro.queernet.org [209.157.101.253]) by honor.greatcircle.com (Postfix) with ESMTP id C9C8517E8B for ; Sun, 1 Oct 2000 20:09:34 -0700 (PDT) Received: from localhost (rogerk@localhost) by castro.queernet.org (8.10.0.Beta6/8.10.0.Beta6) with ESMTP id e923VG812378; Sun, 1 Oct 2000 20:31:16 -0700 (PDT) Date: Sun, 1 Oct 2000 20:31:16 -0700 (PDT) From: "Roger B.A. Klorese" To: majordomo-workers@greatcircle.com Subject: Making Mail Interactions Easier Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk One thing that I believe will make end-users' interactions with Mj2 easier will be handling/ignoring the Internet convention ">" citation prefix, as well as the AOL "<<>>" citation brackets. I'd say fully 30% of the screw-ups I see involve reply citations confusing the parser. Granted, the new confirmation method may make this less of an issue... -- ROGER B.A. KLORESE rogerk@QueerNet.ORG PO Box 14309 San Francisco, CA 94114 "There is only one real blasphemy -- the refusal of joy!" -- Paul Rudnick From majordomo-workers-owner Sun Oct 1 22:48:33 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id WAA12300; Sun, 1 Oct 2000 22:45:58 -0700 (PDT) Received: from epithumia.math.uh.edu (epithumia.math.uh.edu [129.7.128.2]) by honor.greatcircle.com (Postfix) with ESMTP id D331017E8B for ; Sun, 1 Oct 2000 22:45:52 -0700 (PDT) Received: (from tibbs@localhost) by epithumia.math.uh.edu (8.9.3/8.9.3) id BAA06728; Mon, 2 Oct 2000 01:07:34 -0500 To: majordomo-workers@GreatCircle.COM Subject: Re: Making Mail Interactions Easier References: From: Jason L Tibbitts III Date: 02 Oct 2000 01:07:34 -0500 In-Reply-To: "Roger B.A. Klorese"'s message of "Sun, 1 Oct 2000 20:31:16 -0700 (PDT)" Message-ID: Lines: 28 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "RBAK" == Roger B A Klorese writes: RBAK> One thing that I believe will make end-users' interactions with Mj2 RBAK> easier will be handling/ignoring the Internet convention ">" citation RBAK> prefix, as well as the AOL "<<>>" citation brackets. What we do is report that we saw something we didn't understand, and then we just ignore further junk until we see something we do understand. It is possible to get clever, but if we were to do anything special with '>' quoting, I would prefer that we pretend that it isn't there, so you could just quote back the output of configshow instead of editing out your own quotes. Ignoring AOL quoting is also tough, because if done wrong, we could end up nuking entire messages because we misread a spurious '<<' and never saw a closing '>>'. (Insert usual grumbles about how stupid AOL's quoting format is.) RBAK> I'd say fully 30% of the screw-ups I see involve reply citations RBAK> confusing the parser. I assume this is Mj1. How does the parser get confused? Or is this just one of those instances where it spews a whole bunch of "I didn't understand this" and then tacks on the huge help text? We won't do that in any case; perhaps it's enough. - J< From majordomo-workers-owner Mon Oct 2 00:50:54 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id AAA13038; Mon, 2 Oct 2000 00:06:45 -0700 (PDT) Received: from castro.queernet.org (castro.queernet.org [209.157.101.253]) by honor.greatcircle.com (Postfix) with ESMTP id A362117E8B for ; Mon, 2 Oct 2000 00:06:41 -0700 (PDT) Received: from localhost (rogerk@localhost) by castro.queernet.org (8.10.0.Beta6/8.10.0.Beta6) with ESMTP id e927SNI15715 Date: Mon, 2 Oct 2000 00:28:23 -0700 (PDT) From: "Roger B.A. Klorese" To: Jason L Tibbitts III Cc: majordomo-workers@GreatCircle.COM Subject: Re: Making Mail Interactions Easier 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 2 Oct 2000, Jason L Tibbitts III wrote: > It is possible to get clever, but if we were to do anything special with > '>' quoting, I would prefer that we pretend that it isn't there, so you > could just quote back the output of configshow instead of editing out your > own quotes. Yes, that's what makes sense. > Ignoring AOL quoting is also tough, because if done wrong, we could end up > nuking entire messages because we misread a spurious '<<' and never saw a > closing '>>'. (Insert usual grumbles about how stupid AOL's quoting format > is.) Stupid, yes, but here to stay, it seems. > RBAK> I'd say fully 30% of the screw-ups I see involve reply citations > RBAK> confusing the parser. > > I assume this is Mj1. How does the parser get confused? Or is this just > one of those instances where it spews a whole bunch of "I didn't understand > this" and then tacks on the huge help text? That's right. But for my typical AOL user, << subscribe foo >> and subscribe foo are the same. (And when the error message has that silly >>>>> << subscribe foo >> look to it, they really freak.) -- ROGER B.A. KLORESE rogerk@QueerNet.ORG PO Box 14309 San Francisco, CA 94114 "There is only one real blasphemy -- the refusal of joy!" -- Paul Rudnick From majordomo-workers-owner Mon Oct 2 07:18:43 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id HAA14612; Mon, 2 Oct 2000 07:16:20 -0700 (PDT) Received: from castro.queernet.org (castro.queernet.org [209.157.101.253]) by honor.greatcircle.com (Postfix) with ESMTP id 245B617E8B for ; Mon, 2 Oct 2000 07:16:16 -0700 (PDT) Received: from localhost (rogerk@localhost) by castro.queernet.org (8.10.0.Beta6/8.10.0.Beta6) with ESMTP id e92Ec1c22422 Date: Mon, 2 Oct 2000 07:38:01 -0700 (PDT) From: "Roger B.A. Klorese" To: SRE Cc: majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu Subject: Re: Making Mail Interactions Easier In-Reply-To: <4.3.1.0.20001002060849.00ccec70@pop.climber.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On Mon, 2 Oct 2000, SRE wrote: > For example, the error module COULD look for leading "<<" and mention > that AOL quoting which encloses commands in double angle brackets can > prevent the command from being parsed. You're trying to train users to match the software, rather than modify the software to match the users' assumptions. -- ROGER B.A. KLORESE rogerk@QueerNet.ORG PO Box 14309 San Francisco, CA 94114 "There is only one real blasphemy -- the refusal of joy!" -- Paul Rudnick From majordomo-workers-owner Mon Oct 2 07:33:59 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id HAA14510; Mon, 2 Oct 2000 07:05:31 -0700 (PDT) Received: from kachina.jetcafe.org (kachina.jetcafe.org [205.147.43.2]) by honor.greatcircle.com (Postfix) with ESMTP id CBF3717E8B for ; Mon, 2 Oct 2000 07:05:24 -0700 (PDT) Received: from ee-nt.climber.org (sdn-ar-011casfrMP175.dialsprint.net [158.252.242.177]) by kachina.jetcafe.org (8.9.3/8.9.1) with ESMTP id HAA02517; Mon, 2 Oct 2000 07:27:02 -0700 (PDT) Message-Id: <4.3.1.0.20001002054342.00cd6430@pop.climber.org> X-Sender: eckert@pop.climber.org X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 02 Oct 2000 05:57:18 -0700 To: majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu From: SRE Subject: Re: Mj2: Re: RTFM problem? Perl problem? Mj2 problem? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk At 08:40 PM 9/29/00, Jason L Tibbitts III wrote: >Can folks with this problem verify that the following fixes it? I still have old Mj2 source from August, and the patch works there also. Thanks! Here is my other (apparently unrelated) problem: % bin/mj_shell Cannot connect: Invalid address: ee@ee-ultra You did not include a complete hostname. [aborts to the Unix shell with no further msgs] Well, no change there. I'm still not sure how the 'complete hostname' error comes about on this damn Solaris box, but I know the workaround: % bin/mj_shell -u whatever@wherever.org Entering Majordomo interactive mode. [snip] I could use some clues to fix the hostname problem, but it's NOT a Mj2 issue. It's the damn OS installation on a permanent loaner machine (for which I don't have OS media and can't re-install). The invalid address that mj_shell complains about is username@hostname, where hostname doesn't include a dot. From majordomo-workers-owner Mon Oct 2 07:48:52 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id HAA14941; Mon, 2 Oct 2000 07:43:55 -0700 (PDT) Received: from epithumia.math.uh.edu (epithumia.math.uh.edu [129.7.128.2]) by honor.greatcircle.com (Postfix) with ESMTP id 4869E17E8B for ; Mon, 2 Oct 2000 07:43:50 -0700 (PDT) Received: (from tibbs@localhost) by epithumia.math.uh.edu (8.9.3/8.9.3) id KAA07767; Mon, 2 Oct 2000 10:05:35 -0500 To: majordomo-workers@GreatCircle.COM Subject: Re: Making Mail Interactions Easier References: From: Jason L Tibbitts III Date: 02 Oct 2000 10:05:35 -0500 In-Reply-To: "Roger B.A. Klorese"'s message of "Mon, 2 Oct 2000 00:28:23 -0700 (PDT)" Message-ID: Lines: 33 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "RBAK" == Roger B A Klorese writes: RBAK> Yes, that's what makes sense. Actually, now that I think about it some more, quoting (in the '>' style) serves to protect the parser from recognizing spurious commands that might fall within text (and thus preventing even worse confusion). "accept" is the one we are really concerned with. Owners could make use of a theoretical 'ignore prefix' to do: ignore > > confiset blah << HURL > stuff > stuff RBAK> But for my typical AOL user, << subscribe foo >> and subscribe foo RBAK> are the same. Doesn't listname-subscribe and the availability of a web interface make this mostly go away? A large portion of people only ever want to get on and off lists and never use the server for anything else. Although, with Mj1 there wasn't much else they could do, so perhaps things will be different under Mj2. There is a danger here of trying to eliminate too much cruft or being too permissive in what we accept, especially when the cruft looks so much like actual syntax that we want to make use of. This has already bitten us once with signature_separator preventing some people from accepting tokens. I think it's prudent to see just how many issues crop up with the new software then work on solving them. - J< From majordomo-workers-owner Mon Oct 2 08:03:41 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id IAA15220; Mon, 2 Oct 2000 08:00:36 -0700 (PDT) Received: from castro.queernet.org (castro.queernet.org [209.157.101.253]) by honor.greatcircle.com (Postfix) with ESMTP id B796E17E8B for ; Mon, 2 Oct 2000 08:00:26 -0700 (PDT) Received: from localhost (rogerk@localhost) by castro.queernet.org (8.10.0.Beta6/8.10.0.Beta6) with ESMTP id e92FMBN23040 Date: Mon, 2 Oct 2000 08:22:11 -0700 (PDT) From: "Roger B.A. Klorese" To: Jason L Tibbitts III Cc: majordomo-workers@GreatCircle.COM Subject: Re: Making Mail Interactions Easier 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 2 Oct 2000, Jason L Tibbitts III wrote: > Actually, now that I think about it some more, quoting (in the '>' style) > serves to protect the parser from recognizing spurious commands that might > fall within text (and thus preventing even worse confusion). "accept" is > the one we are really concerned with. Owners could make use of a > theoretical 'ignore prefix' to do: > > ignore > Yes, good. > Doesn't listname-subscribe and the availability of a web interface make this > mostly go away? Mostly. The problem is that, for many of us, there are printed or on-line subscription instructions (that are semi-followed) in dozens of places, and we pay the price for it every day. > I think it's prudent to see just how many issues crop up with the new > software then work on solving them. In general, yes. -- ROGER B.A. KLORESE rogerk@QueerNet.ORG PO Box 14309 San Francisco, CA 94114 "There is only one real blasphemy -- the refusal of joy!" -- Paul Rudnick From majordomo-workers-owner Mon Oct 2 08:19:02 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id HAA14536; Mon, 2 Oct 2000 07:06:18 -0700 (PDT) Received: from kachina.jetcafe.org (kachina.jetcafe.org [205.147.43.2]) by honor.greatcircle.com (Postfix) with ESMTP id 2CD0D17EB4 for ; Mon, 2 Oct 2000 07:06:01 -0700 (PDT) Received: from ee-nt.climber.org (sdn-ar-011casfrMP175.dialsprint.net [158.252.242.177]) by kachina.jetcafe.org (8.9.3/8.9.1) with ESMTP id HAA02537; Mon, 2 Oct 2000 07:27:09 -0700 (PDT) Message-Id: <4.3.1.0.20001002060849.00ccec70@pop.climber.org> X-Sender: eckert@pop.climber.org X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 02 Oct 2000 06:16:29 -0700 To: "Roger B.A. Klorese" From: SRE Subject: Re: Making Mail Interactions Easier Cc: majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On 2 Oct 2000, Jason L Tibbitts III wrote: > It is possible to get clever, but if we were to do anything special with > '>' quoting, I would prefer that we pretend that it isn't there At 12:28 AM 10/2/00, Roger B.A. Klorese wrote: >Yes, that's what makes sense. I disagree: People reply to confirmation tokens by quoting the entire message and tacking "accept" on to the end. If you read quoted stuff as plain commands, you'll parse the entire confirmation text and FIND things like sample unsubscribe commands. Bummer! >But for my typical AOL user, ><< subscribe foo >> >and > subscribe foo >are the same. (And when the error message has that silly > >>>>> << subscribe foo >> >look to it, they really freak.) Then what we REALLY need is a better error reporting module! I've thought for some time that syntax suggestions in the error msg would be better than looser parsing rules to avoid the syntax problem. For example, the error module COULD look for leading "<<" and mention that AOL quoting which encloses commands in double angle brackets can prevent the command from being parsed. For another example, if the "subscribe" command doesn't have an email address but the very next line IS an email address without a command, the user now gets two error messages that aren't merged into one suggestion of "your command may have been broken into two lines, so here's how to use a backslash to avoid that problem". Try sending "subscribe listname@xxx.com user@xxx.com" where "xxx" is replaced with the domain that your server actually runs on. BOOM. This is a case where the command parser could be taught to ignore domain names attached to list names, OR the error module could detect an extra "@" and remind the user that domain names only go on email addresses (not the listname field). Perhaps you could also compile a list of error message improvements? From majordomo-workers-owner Mon Oct 2 08:33:47 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id IAA15492; Mon, 2 Oct 2000 08:19:30 -0700 (PDT) Received: from epithumia.math.uh.edu (epithumia.math.uh.edu [129.7.128.2]) by honor.greatcircle.com (Postfix) with ESMTP id 0E9B917E8B for ; Mon, 2 Oct 2000 08:19:25 -0700 (PDT) Received: (from tibbs@localhost) by epithumia.math.uh.edu (8.9.3/8.9.3) id KAA07915; Mon, 2 Oct 2000 10:41:11 -0500 To: mj2-dev@csf.colorado.edu, majordomo-workers@GreatCircle.COM Subject: Re: Various minor issues References: <4.3.1.0.20001002062447.00cbe540@pop.climber.org> From: Jason L Tibbitts III Date: 02 Oct 2000 10:41:11 -0500 In-Reply-To: SRE's message of "Mon, 02 Oct 2000 06:33:04 -0700" Message-ID: Lines: 18 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "S" == SRE writes: S> It would be extra ugly to upgrade the software and find that your S> existing lists don't function anymore. That's what README.UPGRADE is for. I don't think it reasonable to say that we can't break compatibility at this stage in the game. We should do it rarely, but we should be able to do it. I would of course provide a script to fix all of this up for existing lists. S> I wonder if we would all agree on which one goes in which category? Probably. I'm willing to trust your judgment on this. (I'll just set expert = 5 and be done with it.) - J< From majordomo-workers-owner Mon Oct 2 08:45:53 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id HAA14521; Mon, 2 Oct 2000 07:05:38 -0700 (PDT) Received: from kachina.jetcafe.org (kachina.jetcafe.org [205.147.43.2]) by honor.greatcircle.com (Postfix) with ESMTP id 82C1B17EB4 for ; Mon, 2 Oct 2000 07:05:31 -0700 (PDT) Received: from ee-nt.climber.org (sdn-ar-011casfrMP175.dialsprint.net [158.252.242.177]) by kachina.jetcafe.org (8.9.3/8.9.1) with ESMTP id HAA02543; Mon, 2 Oct 2000 07:27:12 -0700 (PDT) Message-Id: <4.3.1.0.20001002062447.00cbe540@pop.climber.org> X-Sender: eckert@pop.climber.org X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 02 Oct 2000 06:33:04 -0700 To: Jason L Tibbitts III From: SRE Subject: Re: Various minor issues Cc: mj2-dev@csf.colorado.edu, majordomo-workers@GreatCircle.COM In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk At 11:04 AM 9/30/00, Jason L Tibbitts III wrote: >1) The help file for createlist is a bit out of date; Yep. Fixed in CVS. >3) We have several instances where a config variable takes a string like > "ORQ" instead of an enum_array of > I started this dumbness with default_flags, but I think it needs to > change. I'd like to just break backwards compatibility with this > instead of writing a bunch of specialized parsing functions. It would be extra ugly to upgrade the software and find that your existing lists don't function anymore. What happens if it finds the flag-style settings? Which configs are involved? >5) I wonder if we couldn't get a volunteer to go over all of the config > variables and rate them according to "expert level". > This just involves reading the variable descriptions and rating the > variable from 1 to, say, 5, with 5 being access_rules and 1 being > description. I wonder if we would all agree on which one goes in which category? On my system, list owners get these in a boilerplate, and all the others are set up for them by a config-generation script. I'll start the ball rolling by suggesting that THESE are the level 1 options: >configset listname category >configset listname comments >configset listname description >configset listname description_long >configset listname maxlength >configset listname message_footer_frequency >configset listname message_fronter_frequency >configset listname moderate >configset listname moderator >configset listname moderator_group >configset listname owners >configset listname post_limits >configset listname subject_prefix >configset listname subscribe_policy >7) I recently received a complaint about Majordomo1 to the effect that the > default admin_body checks were dumb. We need to review these for Mj2. Agreed. I chopped many of them out to save time and added X-Loop long ago. This may vary greatly from site to site, and the default should probably be less checks so the server doesn't waste time on stuff that users don't do. From majordomo-workers-owner Mon Oct 2 08:48:37 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id IAA15595; Mon, 2 Oct 2000 08:30:18 -0700 (PDT) Received: from epithumia.math.uh.edu (epithumia.math.uh.edu [129.7.128.2]) by honor.greatcircle.com (Postfix) with ESMTP id D492A17E8B for ; Mon, 2 Oct 2000 08:30:08 -0700 (PDT) Received: (from tibbs@localhost) by epithumia.math.uh.edu (8.9.3/8.9.3) id KAA08008; Mon, 2 Oct 2000 10:51:54 -0500 To: majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu Subject: Re: RTFM problem? Perl problem? Mj2 problem? References: <4.3.1.0.20001002054342.00cd6430@pop.climber.org> From: Jason L Tibbitts III Date: 02 Oct 2000 10:51:54 -0500 In-Reply-To: SRE's message of "Mon, 02 Oct 2000 05:57:18 -0700" Message-ID: Lines: 25 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "S" == SRE writes: S> I could use some clues to fix the hostname problem, but it's NOT a Mj2 S> issue. Hmmm. Net::Domain (in the libnet I have) can be configured to return a domain name instead of trying to intuit it from the system. Edit Net/Config.pm and change inet_domain. That should at least fix the Majordomo problem. Net::Domain tries to get the name from /etc/resolv.conf, then it calls getdomainname, then it does some reverse name lookups on the hostname, then it looks in $ENV{DOMAIN} and $ENV{LOCALDOMAIN} although once we finish hacking on the wrappers a bit those variables won't exist. S> It's the damn OS installation on a permanent loaner machine (for which I S> don't have OS media and can't re-install). Solaris is free these days, so if you really need media, you should be able to get it. For the workaround, just set addr_require_fqdn to 0 and never worry about using -u again. - J< From majordomo-workers-owner Mon Oct 2 08:56:37 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id HAA14530; Mon, 2 Oct 2000 07:06:08 -0700 (PDT) Received: from kachina.jetcafe.org (kachina.jetcafe.org [205.147.43.2]) by honor.greatcircle.com (Postfix) with ESMTP id C146D17E8B; Mon, 2 Oct 2000 07:05:58 -0700 (PDT) Received: from ee-nt.climber.org (sdn-ar-011casfrMP175.dialsprint.net [158.252.242.177]) by kachina.jetcafe.org (8.9.3/8.9.1) with ESMTP id HAA02530; Mon, 2 Oct 2000 07:27:06 -0700 (PDT) Message-Id: <4.3.1.0.20001002055806.00c04de0@pop.climber.org> X-Sender: eckert@pop.climber.org X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 02 Oct 2000 06:07:35 -0700 To: "Roger B.A. Klorese" From: SRE Subject: Re: The future of Majordomo Cc: majordomo-users@GreatCircle.COM, majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk At 01:50 PM 10/1/00, Roger B.A. Klorese wrote: >Developers tend to write GUIs that are really config file editors, >providing a point-and-click interface which requires you to understand the >underlying config variables, instead of the actions they control. Yep. That's so ANYTHING can be controlled, not just the things the GUI writer thought of. >going all the way to the task orientation, why not a check box for >"Users should be able to send mail to LISTNAME-subscribe to be added >to the list and to LISTNAME-unsubscribe" to be removed"? Listserv has something like this, which handles 90% of list admin for inexperienced list owners. As a more experienced owner, I find myself always escaping to their, which is basically the "configedit" command in Mj2. I ran into this with commercial software I wrote and sold: The config file had 80+ options (Mj2 has 110+) and they interacted with each other in complex ways (just like Mj2). Users would ask for a simple interface to do complex things, but would then spend page after page of email trying to define what they wanted to do before realizing they really DID need to understand all the options to set them intelligently. List configs interact with each other, and most of those interactions are captured in the help files. Trying to explain them on a web GUI might wind up looking like HTML help instead of a list config form. After all that ranting, if you've got time to study the configs and write down some sort of spec for how the GUI can simplify the common admin tasks, I'll see if that would allow me to configure my 30 lists as they are now. You'll also get further with the guy who's writing the web interface if you say "please do these specific things" instead of saying "please do this sort of thing". >serve as a focus for a simplified and task-oriented end-user and >administrative usage model. I know we won't get there in a single >release, but since it's what I do for a day-job, it's an area I can add >value. You bet! Good specs make coding SOOO much easier! From majordomo-workers-owner Mon Oct 2 09:04:36 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id IAA15851; Mon, 2 Oct 2000 08:55:31 -0700 (PDT) Received: from epithumia.math.uh.edu (epithumia.math.uh.edu [129.7.128.2]) by honor.greatcircle.com (Postfix) with ESMTP id C189717E8B for ; Mon, 2 Oct 2000 08:55:21 -0700 (PDT) Received: (from tibbs@localhost) by epithumia.math.uh.edu (8.9.3/8.9.3) id LAA08088; Mon, 2 Oct 2000 11:17:06 -0500 To: majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu Subject: Re: Making Mail Interactions Easier References: From: Jason L Tibbitts III Date: 02 Oct 2000 11:17:06 -0500 In-Reply-To: "Roger B.A. Klorese"'s message of "Mon, 2 Oct 2000 08:22:11 -0700 (PDT)" Message-ID: Lines: 82 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "RBAK" == Roger B A Klorese writes: RBAK> The problem is that, for many of us, there are printed or on-line RBAK> subscription instructions (that are semi-followed) in dozens of RBAK> places, and we pay the price for it every day. I have that problem too, and had managed to forget about it. So it comes down to making a list of boneheaded things that users do when communicating with the server and seeing if each can be remedied without collateral damage. ----- << command args >> seems easy (s/^<<\s*(.*)\s*>>$/$1/) but: 1) How does this possibly interfere with <<< TAG? 2) Does this ever appear as a legitimate quote? I.e. might the user _not_ want this to execute because they're quoting the server? 3) Is it really ever on one line? What happens to: << command args >> or << command >> ? Let's not think about << command args >> ---- > command args s/^>\s*//; 1) Does anyone (besides owners quoting a configshow) ever actually do this and expect the command to execute? 2) How would this impact the ignoring of quoted token messages while looking for a trailing "accept"? (We always include the "accept" in quotes, so technically it should never appear bare in the message unless the user typed it. 3) Wouldn't this just cause more harm than good? The quoting protects us from ever seeing a spurious command in a big quoted reply sent to Majordomo. ---- While we're at it: subscribe listname-digest We _must_ handle this. if valid_list($list) then handle as normal. if ($list =~ /(.*)-digest/ && valid_list($list)) then {$mode .= '-digest'}; ---- echo | mail listname-digest-subscribe echo | mail listname-subscribe-digest These seem to be reasonable guesses for someone to make. Perhaps an additional setting for the 'aliases' variable? ---- I'm sure there are many others, but most of the ones I see come from the bogus Mj1 help files: subscribe list [] Aargh! - J< From majordomo-workers-owner Mon Oct 2 09:10:28 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id HAA14597; Mon, 2 Oct 2000 07:15:08 -0700 (PDT) Received: from castro.queernet.org (castro.queernet.org [209.157.101.253]) by honor.greatcircle.com (Postfix) with ESMTP id 8902917E8B; Mon, 2 Oct 2000 07:14:57 -0700 (PDT) Received: from localhost (rogerk@localhost) by castro.queernet.org (8.10.0.Beta6/8.10.0.Beta6) with ESMTP id e92Eafp22350 Date: Mon, 2 Oct 2000 07:36:41 -0700 (PDT) From: "Roger B.A. Klorese" To: SRE Cc: majordomo-users@GreatCircle.COM, majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu Subject: Re: The future of Majordomo In-Reply-To: <4.3.1.0.20001002055806.00c04de0@pop.climber.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On Mon, 2 Oct 2000, SRE wrote: > At 01:50 PM 10/1/00, Roger B.A. Klorese wrote: > >Developers tend to write GUIs that are really config file editors, > >providing a point-and-click interface which requires you to understand the > >underlying config variables, instead of the actions they control. > > Yep. That's so ANYTHING can be controlled, not just the things > the GUI writer thought of. Which is fine, for a very advanced mode. But most users want more than just knobs -- they want a consistent usage model that leads them to accomplish specific tasks, > >going all the way to the task orientation, why not a check box for > >"Users should be able to send mail to LISTNAME-subscribe to be added > >to the list and to LISTNAME-unsubscribe" to be removed"? > > Listserv has something like this, which handles 90% of list admin > for inexperienced list owners. As a more experienced owner, I find > myself always escaping to their, which is basically the "configedit" > command in Mj2. But -- and I say this with great repspect -- you're a GEEK. Most list managers are not and need not be. > I ran into this with commercial software I wrote and sold: The config > file had 80+ options (Mj2 has 110+) and they interacted with each other > in complex ways (just like Mj2). Users would ask for a simple interface > to do complex things, but would then spend page after page of email > trying to define what they wanted to do before realizing they really > DID need to understand all the options to set them intelligently. Then the interactions are poorly defined. > List configs interact with each other, and most of those interactions > are captured in the help files. Trying to explain them on a web GUI > might wind up looking like HTML help instead of a list config form. HTML help with a couple of choices is far more useful for most users than a web config form. I give my llist-owners exactly two choices at setup time: a predefined discussion list setup and a predefined announcement list setup. I then have about 4 specific variations. About 5% of my list owners go beyond that to tweak options. > After all that ranting, if you've got time to study the configs and > write down some sort of spec for how the GUI can simplify the common > admin tasks, I'll see if that would allow me to configure my 30 lists > as they are now. The fact is, whether it will allow *you* (or even me) to do it is not that important. It's whether it will allow the averabe newbie list-owner to do it with 15 minutes' reading that counts. > You'll also get further with the guy who's writing > the web interface if you say "please do these specific things" instead > of saying "please do this sort of thing". Of course. -- ROGER B.A. KLORESE rogerk@QueerNet.ORG PO Box 14309 San Francisco, CA 94114 "There is only one real blasphemy -- the refusal of joy!" -- Paul Rudnick From majordomo-workers-owner Mon Oct 2 09:21:08 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id JAA16125; Mon, 2 Oct 2000 09:14:28 -0700 (PDT) Received: from kachina.jetcafe.org (kachina.jetcafe.org [205.147.43.2]) by honor.greatcircle.com (Postfix) with ESMTP id 22D5217E8B for ; Mon, 2 Oct 2000 09:14:21 -0700 (PDT) Received: from ee-nt.climber.org (sdn-ar-011casfrMP175.dialsprint.net [158.252.242.177]) by kachina.jetcafe.org (8.9.3/8.9.1) with ESMTP id JAA04485; Mon, 2 Oct 2000 09:35:59 -0700 (PDT) Message-Id: <4.3.1.0.20001002092400.00c8c4c0@pop.climber.org> X-Sender: eckert@pop.climber.org X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 02 Oct 2000 09:28:38 -0700 To: Jason L Tibbitts III From: SRE Subject: Re: Mj2: Re: Making Mail Interactions Easier Cc: majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu In-Reply-To: References: <"Roger B.A. Klorese"'s message of "Mon, 2 Oct 2000 08:22:11 -0700 (PDT)"> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk At 09:17 AM 10/2/00, Jason L Tibbitts III wrote: >2) How would this impact the ignoring of quoted token messages while > looking for a trailing "accept"? (We always include the "accept" in > quotes, so technically it should never appear bare in the message unless > the user typed it. Or unless you're a GEEK like me that customizes the server messages! (damn nifty feature of Mj2, which prevents me from sending in a bunch of enhancement requests and allows me to adapt to the sort of errors my users are making by suggesting other things they SHOULD do) I put all sorts of valid Mj2 commands in there, including some that have real addresses in them, so the user can copy/paste entire lines at a time instead of thinking so much. Unquoting them will cause problems. Here's an example from my welcome file: approve $PASSWORD unsubscribe $LIST $USER Note that the variables get filled in and would nail the subscription. >3) Wouldn't this just cause more harm than good? The quoting protects us > from ever seeing a spurious command in a big quoted reply sent to > Majordomo. Exactly. From majordomo-workers-owner Mon Oct 2 09:33:37 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id IAA15431; Mon, 2 Oct 2000 08:16:12 -0700 (PDT) Received: from castro.queernet.org (castro.queernet.org [209.157.101.253]) by honor.greatcircle.com (Postfix) with ESMTP id B6B6E17EB4 for ; Mon, 2 Oct 2000 08:16:06 -0700 (PDT) Received: from localhost (rogerk@localhost) by castro.queernet.org (8.10.0.Beta6/8.10.0.Beta6) with ESMTP id e92Fbqv23449 Date: Mon, 2 Oct 2000 08:37:52 -0700 (PDT) From: "Roger B.A. Klorese" To: SRE Cc: majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu Subject: Re: Mj2: Re: Making Mail Interactions Easier In-Reply-To: <4.3.1.0.20001002081054.00ba8500@pop.climber.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On Mon, 2 Oct 2000, SRE wrote: > Personal experience suggests that there are more ways to do it wrong > than there are people in the world. Trying to accommodate mistakes > tends to encourage mistakes, and my life as a list owner and system > administrator got TOUGHER (not easier) when I did things for the > users instead of educating them. My life as a service provider becomes easier when I take away choices and flexibility from the average user, making it easier for 95% of them to accomplish their goals. > I believe most people are trainable. I don't think we need to "dumb down" > so much as we need to explain clearly... that's why I suggested some > changes to the error report would be best. I believe that raising others to our levels of literacy s a lot like expecting doctors to talk to patients in minutely accurate detail, and trying to educate them to handle the information. Not only is it a big task, it's irrelevant to the vast majority. > >Most list managers are not and need not be. > > That's where system administrators shine, NOT where the software takes over! Most list managers are not system administrators, and shouldn't be forced into daily dialogs with them. It's a major goal of good UI design tl keep the support phone from ringing. > Looks like you agree with me: Newbie owners should be given choices by > their admins, advanced owners need a powerful GUI, so who needs a simple > one? Newbies (which we will herein define as non-technical users -- many of my best list-owners of 2 to 5 years' standing would be "newbies" by this definition) should be given those choices BY THE GUI. There's no reason for them to interact with me. > Which problem would you like the GUI to solve? Absolute newbies (for > which you have properly provided defaults), or for the person setting > up the defaults (for which access to ALL the options is important)? Both, of course. That's why an expert, "all-bets-are-off" mode as a config editor is fine, but not as the primary interface presented. > You assume there are lots of newbies, that they can't or won't learn, > and that they have no access to experts who can steer them. Lots of > assumptions, neither of us has proof. I assume that the average eGroups list owner does not call eGroups to set up each list. I asume that I don't need or want to spend my time sterring, and neither do most IT professionals or service providers. > That problem is best solved with examples and not a GUI. I used to believe that. > I'll be happy > to install sample complete list configs in the help system if there is > general concensus on what should be there (and which help file it should > go into). Good help files keep the phone from ringing. But good task-oriented UIs keep even the help files from needing to be consulted. > If we do what you've already done (provide stock templates) > with notes about the things they shouldn't touch unless they educate > themselves, haven't we made their life even EASIER? Only if those are the main track of the UI, not a grafted-on simplification. -- ROGER B.A. KLORESE rogerk@QueerNet.ORG PO Box 14309 San Francisco, CA 94114 "There is only one real blasphemy -- the refusal of joy!" -- Paul Rudnick From majordomo-workers-owner Mon Oct 2 09:49:19 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id JAA16433; Mon, 2 Oct 2000 09:39:11 -0700 (PDT) Received: from epithumia.math.uh.edu (epithumia.math.uh.edu [129.7.128.2]) by honor.greatcircle.com (Postfix) with ESMTP id 3904817E8B for ; Mon, 2 Oct 2000 09:39:05 -0700 (PDT) Received: (from tibbs@localhost) by epithumia.math.uh.edu (8.9.3/8.9.3) id MAA08211; Mon, 2 Oct 2000 12:00:51 -0500 To: majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu Subject: Re: Mj2: Re: Making Mail Interactions Easier References: <"Roger B.A. Klorese"'s message of "Mon, 2 Oct 2000 08:22:11 -0700 (PDT)"> <4.3.1.0.20001002092400.00c8c4c0@pop.climber.org> From: Jason L Tibbitts III Date: 02 Oct 2000 12:00:51 -0500 In-Reply-To: SRE's message of "Mon, 02 Oct 2000 09:28:38 -0700" Message-ID: Lines: 17 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "S" == SRE writes: S> I put all sorts of valid Mj2 commands in there, including some that have S> real addresses in them, so the user can copy/paste entire lines at a S> time instead of thinking so much. Unquoting them will cause S> problems. Keep in mind that things like AOL-style and tab-style quoting exist and thus you really have no protection. The prevalence of '>'-style quoting only conveniently eliminates some confusion, but it's bad practice to rely on it. I recommend always using quotes around commands in the help text, and explicitly say "(without the quotes)". This will keep things like tab-quoting from killing you. - J< From majordomo-workers-owner Mon Oct 2 09:51:20 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id IAA15304; Mon, 2 Oct 2000 08:06:20 -0700 (PDT) Received: from kachina.jetcafe.org (kachina.jetcafe.org [205.147.43.2]) by honor.greatcircle.com (Postfix) with ESMTP id 6F85517E8B for ; Mon, 2 Oct 2000 08:06:14 -0700 (PDT) Received: from ee-nt.climber.org (sdn-ar-011casfrMP175.dialsprint.net [158.252.242.177]) by kachina.jetcafe.org (8.9.3/8.9.1) with ESMTP id IAA03378; Mon, 2 Oct 2000 08:27:37 -0700 (PDT) Message-Id: <4.3.1.0.20001002081054.00ba8500@pop.climber.org> X-Sender: eckert@pop.climber.org X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 02 Oct 2000 08:23:47 -0700 To: "Roger B.A. Klorese" From: SRE Subject: Re: Mj2: Re: Making Mail Interactions Easier Cc: majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu In-Reply-To: References: <4.3.1.0.20001002060849.00ccec70@pop.climber.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk At 07:38 AM 10/2/00, Roger B.A. Klorese wrote: >You're trying to train users to match the software, rather than modify the >software to match the users' assumptions. Personal experience suggests that there are more ways to do it wrong than there are people in the world. Trying to accommodate mistakes tends to encourage mistakes, and my life as a list owner and system administrator got TOUGHER (not easier) when I did things for the users instead of educating them. I believe most people are trainable. I don't think we need to "dumb down" so much as we need to explain clearly... that's why I suggested some changes to the error report would be best. An example where modifying the software for one user caused problems for another user: We talked Jason into allowing a regular expression for sig block separators, with a default lenient enough to catch all the yahoo/hotmail/etc freebie providers. SOOO lenient, in fact, that it now catches the "on xxx you wrote" quoting header from at least one mail tool: This means that the rest of the msg, including the "accept" command, is discarded as a signature block. Did we do the right thing? Yes, for at least some people. Did we do the wrong thing? Yes again. As I posted earlier, "reading through" quotations means that you will find false commands that are in the confirmation message, and confuse the situation even more. Training *IS* the solution to this problem, I think, because the OTHER solution screws up even MORE people. At 07:36 AM 10/2/00, Roger B.A. Klorese wrote: >But -- and I say this with great repspect -- you're a GEEK. True by some definitions, but the REAL geeks complain that I won't learn emacs and use WinNT instead of FreeBSD for my daily operations. >Most list managers are not and need not be. That's where system administrators shine, NOT where the software takes over! >I give my llist-owners exactly two choices at setup time: a predefined >discussion list setup and a predefined announcement list setup. I then >have about 4 specific variations. Looks like you agree with me: Newbie owners should be given choices by their admins, advanced owners need a powerful GUI, so who needs a simple one? Which problem would you like the GUI to solve? Absolute newbies (for which you have properly provided defaults), or for the person setting up the defaults (for which access to ALL the options is important)? >The fact is, whether it will allow *you* (or even me) to do it is not that >important. You assume there are lots of newbies, that they can't or won't learn, and that they have no access to experts who can steer them. Lots of assumptions, neither of us has proof. >It's whether it will allow the averabe newbie list-owner to do >it with 15 minutes' reading that counts. That problem is best solved with examples and not a GUI. I'll be happy to install sample complete list configs in the help system if there is general concensus on what should be there (and which help file it should go into). If we do what you've already done (provide stock templates) with notes about the things they shouldn't touch unless they educate themselves, haven't we made their life even EASIER? SRE mailto:eckert@climber.org | http://www.climber.org/eckert/ Info on peak climbing email lists mailto:info@climber.org Things change. People change. Things change people. From majordomo-workers-owner Mon Oct 2 10:34:02 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id KAA16942; Mon, 2 Oct 2000 10:22:49 -0700 (PDT) Received: from icarus.dur.ac.uk (icarus.dur.ac.uk [129.234.4.81]) by honor.greatcircle.com (Postfix) with ESMTP id 0075817E8B for ; Mon, 2 Oct 2000 10:22:42 -0700 (PDT) Received: from mercury.dur.ac.uk (mercury.dur.ac.uk [129.234.4.40]) by icarus.dur.ac.uk (8.9.1/8.9.1) with ESMTP id SAA00012; Mon, 2 Oct 2000 18:42:06 +0100 (BST) Received: from arachne (arachne.dur.ac.uk [129.234.2.4]) by mercury.dur.ac.uk (8.9.1/8.9.1) with ESMTP id SAA29963; Mon, 2 Oct 2000 18:42:05 +0100 (BST) Date: Mon, 2 Oct 2000 18:42:04 +0100 (BST) From: David Lee To: "Roger B.A. Klorese" Cc: SRE , majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu Subject: Re: Mj2: Re: Making Mail Interactions Easier 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 Mon, 2 Oct 2000, Roger B.A. Klorese wrote: > On Mon, 2 Oct 2000, SRE wrote: > > Personal experience suggests that there are more ways to do it wrong > > than there are people in the world. Trying to accommodate mistakes > > tends to encourage mistakes, and my life as a list owner and system > > administrator got TOUGHER (not easier) when I did things for the > > users instead of educating them. > > My life as a service provider becomes easier when I take away choices and > flexibility from the average user, making it easier for 95% of them to > accomplish their goals. > > [...] > Most list managers are not system administrators, and shouldn't be forced > into daily dialogs with them. It's a major goal of good UI design tl keep > the support phone from ringing. > > [...] > Newbies (which we will herein define as non-technical users -- many > of my best list-owners of 2 to 5 years' standing would be > "newbies" by this definition) should be given those choices BY THE > GUI. There's no reason for them to interact with me. > > [...] > Good help files keep the phone from ringing. > > But good task-oriented UIs keep even the help files from needing to be > consulted. > > > If we do what you've already done (provide stock templates) > > with notes about the things they shouldn't touch unless they educate > > themselves, haven't we made their life even EASIER? > > Only if those are the main track of the UI, not a grafted-on > simplification. Roger makes some valid points for one way of operating. It would be most useful if he could demonstrate these points. But this brings us full circle to the "release" question. We are not in a position to commit ourselves, and our employers' resources, to Mj2 (including to such demonstrations) unless we can be reasonably confident that Mj2 is itself committed to us. That is: that there is seen to be a commitment to its release and maintenance (in open-source style). It is a covenant relationship (in the theological sense): Mj2 commits to us, and we in turn commit to it. Until that happens, Roger's ideas (whether we think them good or bad is irrelevant) will not get the chance to prove (or disprove) themselves. -- : David Lee I.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/~dcl0tdl South Road : : Durham : : Phone: +44 191 374 2882 U.K. : From majordomo-workers-owner Mon Oct 2 12:03:44 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id LAA18019; Mon, 2 Oct 2000 11:56:15 -0700 (PDT) Received: from epithumia.math.uh.edu (epithumia.math.uh.edu [129.7.128.2]) by honor.greatcircle.com (Postfix) with ESMTP id 2CA5217E8B for ; Mon, 2 Oct 2000 11:56:09 -0700 (PDT) Received: (from tibbs@localhost) by epithumia.math.uh.edu (8.9.3/8.9.3) id OAA08597; Mon, 2 Oct 2000 14:17:53 -0500 To: David Lee Cc: majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu Subject: Re: Mj2: Re: Making Mail Interactions Easier References: From: Jason L Tibbitts III Date: 02 Oct 2000 14:17:53 -0500 In-Reply-To: David Lee's message of "Mon, 2 Oct 2000 18:42:04 +0100 (BST)" Message-ID: Lines: 44 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "DL" == David Lee writes: DL> But this brings us full circle to the "release" question. We are not DL> in a position to commit ourselves, and our employers' resources, to Mj2 DL> (including to such demonstrations) unless we can be reasonably DL> confident that Mj2 is itself committed to us. "Mj2" is only committed to anyone (whatever that means) as long as people are committed to it. The software exists. It is there. It is "released". We give it to you freely (under the terms of the license, of course). Yes, I understand that some "official" "release" statement can act as a motivating factor for _users_, since it would carry some implications about the stability or feasibility for use of the software (even though we go to a lot of effort to disclaim any responsibility for either). And that is precisely why we haven't made such a statement. DL> It is a covenant relationship (in the theological sense): Mj2 commits DL> to us, and we in turn commit to it. Mj2 cannot commit to you any more than a wrench can commit to you. It is a piece of software, a tool. I could commit to you, but I'm not going to unless you pay me. I'm committed to the software instead. We could "release" Mj2 today and walk away tomorrow. You have no guarantees (and _certainly_ not any contractual ones). Yet the software remains. DL> Until that happens, Roger's ideas (whether we think them good or bad is DL> irrelevant) will not get the chance to prove (or disprove) themselves. What does that mean? Are you trying to imply that if your standards of "release" aren't met, all of our work and discussion is meaningless? If so, you are very wrong. And as I've already said, the main issue holding up a release (i.e. that "official" announcement) in my eyes is me managing to finish bounce handling and to get in a couple of incompatible changes that are better done earlier than later). I don't know if Michael is planning any big work any time soon; if not then we're reaching a stability plateau that provides an ideal release point. - J< From majordomo-workers-owner Mon Oct 2 12:33:43 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id MAA18332; Mon, 2 Oct 2000 12:20:37 -0700 (PDT) Received: from intranet.com.mx (intranet.com.mx [200.33.246.7]) by honor.greatcircle.com (Postfix) with ESMTP id 24D5617E8B; Mon, 2 Oct 2000 12:20:28 -0700 (PDT) Received: from jbpc (200.33.246.4) by intranet.com.mx with SMTP (Eudora Internet Mail Server 3.0); Mon, 2 Oct 2000 14:42:15 -0500 Message-Id: <3.0.6.32.20001002144405.018c6670@intranet.com.mx> X-Sender: jbiquez@intranet.com.mx X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 02 Oct 2000 14:44:05 -0500 To: majordomo-users@GreatCircle.COM, majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu From: Jorge Biquez Subject: Re: The future of Majordomo In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk hello all. I'm sorry if this sounds stupid. Is there a site where I can consult what's the "wish list" of the features that users of Majordomo has asked through the years? Thanks in advance. JB At 05:44 p.m. 01/10/00 -0700, you wrote: >On 1 Oct 2000, Jason L Tibbitts III wrote: >> I agree fully. But now you're getting into the "refinements" stage where >> before we were in the "get some kind of web interface" stage. Keep >> bringing these kinds of things up, and keep a list if you like. Working on >> things like this would be a great way for someone who wants to contribute >> to get involved. > >Cool. > >I am willing to track a list for user interface requirements (yeah, yeah, >I know it's a domineering term, but it maps well to the input phase), and >serve as a focus for a simplified and task-oriented end-user and >administrative usage model. I know we won't get there in a single >release, but since it's what I do for a day-job, it's an area I can add >value. > >Y'know, as of a month ago, I was totally over Mj2, even though I've been >following the -workers list for years. Since I've contemplated other >alternatives -- mailman, a few commercial products -- I see how well >things have been implemented here, and want to adopt Mj2. (Please count >this as a voice toward getting a 2.0 beta -- or even better in some ways, >an Mj2 1.0 beta -- out soon, despite the fact that I desperately need the >UI work to move ahead as well.) But it's going to take the simplification >of the UI to get there, and I'm ready to help. > >-- >ROGER B.A. KLORESE rogerk@QueerNet.ORG >PO Box 14309 San Francisco, CA 94114 >"There is only one real blasphemy -- the refusal of joy!" -- Paul Rudnick > > > From majordomo-workers-owner Mon Oct 2 14:04:19 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id NAA19716; Mon, 2 Oct 2000 13:54:49 -0700 (PDT) Received: from epithumia.math.uh.edu (epithumia.math.uh.edu [129.7.128.2]) by honor.greatcircle.com (Postfix) with ESMTP id 5236317E8B; Mon, 2 Oct 2000 13:54:39 -0700 (PDT) Received: (from tibbs@localhost) by epithumia.math.uh.edu (8.9.3/8.9.3) id QAA08903; Mon, 2 Oct 2000 16:16:25 -0500 To: Jorge Biquez Cc: majordomo-users@GreatCircle.COM, majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu Subject: Re: The future of Majordomo References: <3.0.6.32.20001002144405.018c6670@intranet.com.mx> From: Jason L Tibbitts III Date: 02 Oct 2000 16:16:25 -0500 In-Reply-To: Jorge Biquez's message of "Mon, 02 Oct 2000 14:44:05 -0500" Message-ID: Lines: 14 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "JB" == Jorge Biquez writes: JB> Is there a site where I can consult what's the "wish list" of the JB> features that users of Majordomo has asked through the years? Well, you could read the list archives. I don't think anyone ever collected every user request that came in since '92. But I did collect many of them as the initial TODO list for Mj2, and most of that is implemented already. So the current feature list might be a good start, as most of what's there is in because someone asked for it (or it's infrastructure for implementing things that folks have asked for, as with the case of access_rules). - J< From majordomo-workers-owner Mon Oct 2 16:18:45 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id QAA21183; Mon, 2 Oct 2000 16:11:11 -0700 (PDT) Received: from intranet.com.mx (intranet.com.mx [200.33.246.7]) by honor.greatcircle.com (Postfix) with ESMTP id 6D67C17E8B; Mon, 2 Oct 2000 16:11:02 -0700 (PDT) Received: from jbpc (200.33.246.4) by intranet.com.mx with SMTP (Eudora Internet Mail Server 3.0); Mon, 2 Oct 2000 18:32:52 -0500 Message-Id: <3.0.6.32.20001002183445.016ecd50@intranet.com.mx> X-Sender: jbiquez@intranet.com.mx X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 02 Oct 2000 18:34:45 -0500 To: majordomo-users@GreatCircle.COM, majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu From: Jorge Biquez Subject: Re: The future of Majordomo In-Reply-To: References: <3.0.6.32.20001002144405.018c6670@intranet.com.mx> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk The last question on this. Thanks I'd like to have the original list and how the application evolutioned. This is because I'd like to use it as an example of a good work done for people working on the same ideal and in need of a product that solved something specific (on the internet of course). This is for a class on computer science for a University outside USA. What would be the best resource to study about this?. I bought a book that compares different software for managing list of messages but it is not enough for what I need. Thanks in advance. At 04:16 p.m. 02/10/00 -0500, you wrote: >>>>>> "JB" == Jorge Biquez writes: > >JB> Is there a site where I can consult what's the "wish list" of the >JB> features that users of Majordomo has asked through the years? > >Well, you could read the list archives. I don't think anyone ever >collected every user request that came in since '92. But I did collect >many of them as the initial TODO list for Mj2, and most of that is >implemented already. So the current feature list might be a good start, as >most of what's there is in because someone asked for it (or it's >infrastructure for implementing things that folks have asked for, as with >the case of access_rules). > > - J< > From majordomo-workers-owner Mon Oct 2 18:18:39 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id SAA22353; Mon, 2 Oct 2000 18:09:27 -0700 (PDT) Received: from kachina.jetcafe.org (kachina.jetcafe.org [205.147.43.2]) by honor.greatcircle.com (Postfix) with ESMTP id 4B46B17E8B for ; Mon, 2 Oct 2000 18:09:22 -0700 (PDT) Received: from ee-nt.climber.org (sdn-ar-001casfrMP184.dialsprint.net [158.252.208.186]) by kachina.jetcafe.org (8.9.3/8.9.1) with ESMTP id SAA09471; Mon, 2 Oct 2000 18:30:59 -0700 (PDT) Message-Id: <4.3.1.0.20001002173441.00c86660@pop.climber.org> X-Sender: eckert@pop.climber.org X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 02 Oct 2000 17:52:54 -0700 To: mj2-dev@csf.colorado.edu From: SRE Subject: Re: Mj2: Re: Making Mail Interactions Easier Cc: majordomo-workers@GreatCircle.COM In-Reply-To: <20001002172625.A311@moscow.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk At 05:26 PM 10/2/00, Michael Yount wrote: >Given Roger Klorese's recent comments, Paul Hancock's list "flavors" >look like a really good feature. Is this something you'd put as a createlist option, or in the help files? I think it's just a help file example, that "help createlist" can point to, and as such isn't a gating item for a full release. If I understand what you mean by "flavor", it's what Paul called a "template", and it just contains a set of configs that could actually be used out of the box: a moderated list, a list with digests and archives, etc. Anyone want to enumerate the flavors we need to provide? >The project needs an up-to-date web page and better introductions >for novices. How about switching some of the release files from plain text to html, and putting them on the web in addition to in the release? (Things like TODO and README, with a bit of buffing up.) Otherwise we're going to get out of synch as soon as we finish creating the updated web page. Do you mean introduction for novice list owners or novice subscribers? Either way, I think "help help" is the file to start with, I think that everything we put on the web should be in the help system, and I think the help system should be html-ized as part of the install procedure (with each site deciding whether to install the available files or not). I can provide the script I use to create HTML help at my site, but it cannot run until the help system is installed and operational since it relies on variable evaluations and file inclusions to have occurred before the html edits are made. >A separate web/help page for each category of >configuration settings would be a boon for inexperienced list owners. If someone will suggest exhaustive category names, I'll take care of the formatting. This probably belongs in "help admin_commands" file, not "help commands", right? Also, it would be better to categorize ALL commands, not just the configset sub-commands. I've done a bit along the lines of grouping commands with the "see also" section at the bottom of most configset help files, trying to point people in the direction of other settings that do similar things or need to be considered at the same time. It's not going to be easy to form non-intersecting sets of commands, so think about how many categories each command or configset option should be in. I've been thinking of a nomenclature pass: I remember when I was starting that "configs" meant nothing to me. The command was "configset", but that didn't sink in for a while. Then I came across documentation that spoke of "variables", and finally figured out the 'configs' consisited of a bunch of 'configset variables'. Then we got to the ACTUAL variables that are evaluated as a message gets sent... and occasionally I still stumble on the fact that "mode" really means "option to a configset command". I'd like to make a pass thru the docs finding and replacing all such terms with rigidly defined terms that appear in a glossary. Again, I could use some help here so I don't pick terms that the developers hate or old Mj1 users don't understand. 'config' --> list configuration SETTING 'config variable' --> list configuration OPTION 'variable' --> access rules variable, file substitution variable 'command' --> note that configset is a command with LOTS of command options 'mode' --> configset command option There are a ton of these, and I'm the wrong person to write the glossary. Anyone want to help? From majordomo-workers-owner Mon Oct 2 21:48:38 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id VAA24236; Mon, 2 Oct 2000 21:42:31 -0700 (PDT) Received: from epithumia.math.uh.edu (epithumia.math.uh.edu [129.7.128.2]) by honor.greatcircle.com (Postfix) with ESMTP id E6C5417E8B; Mon, 2 Oct 2000 21:42:21 -0700 (PDT) Received: (from tibbs@localhost) by epithumia.math.uh.edu (8.9.3/8.9.3) id AAA09770; Tue, 3 Oct 2000 00:04:12 -0500 To: Jorge Biquez Cc: majordomo-users@GreatCircle.COM, majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu Subject: Re: The future of Majordomo References: <3.0.6.32.20001002144405.018c6670@intranet.com.mx> <3.0.6.32.20001002183445.016ecd50@intranet.com.mx> From: Jason L Tibbitts III Date: 03 Oct 2000 00:04:12 -0500 In-Reply-To: Jorge Biquez's message of "Mon, 02 Oct 2000 18:34:45 -0500" Message-ID: Lines: 84 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "JB" == Jorge Biquez writes: JB> What would be the best resource to study about this? There's a paper presented at a LISA conference written by Brent Chapman that talks about why the wrote Majordomo and what problem they were trying to solve. If you understand what they were originally trying to do, you will have some deep insight into why Majordomo1 works the way it does. Some quick notes: First they just wanted automatic maintenance of an address list that Sendmail would expand. Later, they added filtering (i.e. resend), then the moderation and post approval mechanism. After that, they put in the remote configuration system, so you could actually manage a list remotely Some time in there they also added simple file distribution. That brings you up to 1.92, I think. Maybe 1.90. I don't remember what was in 1.68. I've never been near the source of anything older. Everything from 1.92 to 1.94.x has been tweaks. I came in at 1.93 but didn't start contributing until my rewrite of the approval stuff in 1.94.1 (I think). This is around '97. (Some will remember the marathon hacking session that got the code done before I went on vacation.) I started tinkering at 1.94.1, at which point I branched a private 1.95 that nobody ever saw. I started rewriting the command parser (because it was nasty) and wanted to add MIME handling to it. But MIME-Tools was perl5 only, so I started removing perl4-isms. Eventually I came down to just a few design decisions: 1) Addresses needed to be stored in a database, so additional data could be tracked with them. 2) All core functions should pass through a single access control mechanism. This needed to allow any command to be stopped pending some kind of approval. The access control mechanism needed to be extremely flexible. 3) The core set of functionality should be split from the interface and stuck in a library. The user requests that drove these were: 1) Need to be able to set nomail/vacation status. Digests need to be a setting on the main list, not a separate list. Need to let a user not get copies of their own posts. 2) Lots of people asked for various different restrictions or exceptions. I.e. "ban some posters", "force approval for subscriptions from AOL", something less restrictive than "only members can post" that doesn't get a moderator involved. Plus I have a belief that postings should never be rejected without a human at least reading them, but lots of others don't agree. 3) Majorcool is neat, but the way it works internally is horrendous. It should be able to just call the Majordomo library to do stuff. Plus, I wanted a command line interface. There were other "minor" requirements that shaped the code: Multiple digests per list and on-demand custom digest generation (which drove the integration of the archive system and the building of digests from the archives). Automatic MTA configuration and support for multiple MTAs. Flexible delivery to help sendmail go faster (which, along with the "addresses in databases" stuff, required that we talk SMTP directly to the MTA. Automatic bounce handling. Now, once those main three design decisions were arrived at, I decided there was only one thing to do: delete all of the code and start over. This also enabled a license change, to something which is actually considered a "free software" license. Anyway, that gets us to '98. The rest is just me working away, essentially alone, until SRE came in and started writing documentation. Then Michael came along almost precisely when I burned out completely after three years of sinking all of my free time into the thing. He revived the whole project, and more recently I've been getting back into to contributing a bunch of code. I hope this helps you. - J< From majordomo-workers-owner Tue Oct 3 11:03:38 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id LAA05130; Tue, 3 Oct 2000 11:01:53 -0700 (PDT) Received: from smtp.gu.se (smtp.gu.se [130.241.150.66]) by honor.greatcircle.com (Postfix) with ESMTP id D7F9D17E8B for ; Tue, 3 Oct 2000 11:01:46 -0700 (PDT) Received: from elake.max.ffs.gu.se (IDENT:root@elake.max.ffs.gu.se [130.241.172.43]) by smtp.gu.se (8.10.2/8.10.2) with ESMTP id e93IN4618719; Tue, 3 Oct 2000 20:23:04 +0200 Date: Tue, 3 Oct 2000 18:22:28 +0200 (CEST) From: Nalle Johansson X-Sender: root@elake.max.ffs.gu.se To: "Roger B.A. Klorese" Cc: SRE , majordomo-workers@GreatCircle.COM Subject: Re: Making Mail Interactions Easier In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk I have tryed to get of this list but i dont get an answer. What address should I use to get of the list? /Nalle On Mon, 2 Oct 2000, Roger B.A. Klorese wrote: > On Mon, 2 Oct 2000, SRE wrote: > > For example, the error module COULD look for leading "<<" and mention > > that AOL quoting which encloses commands in double angle brackets can > > prevent the command from being parsed. > > You're trying to train users to match the software, rather than modify the > software to match the users' assumptions. > > -- > ROGER B.A. KLORESE rogerk@QueerNet.ORG > PO Box 14309 San Francisco, CA 94114 > "There is only one real blasphemy -- the refusal of joy!" -- Paul Rudnick > > From majordomo-workers-owner Tue Oct 10 12:33:45 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id MAA21094; Tue, 10 Oct 2000 12:26:13 -0700 (PDT) Received: from rina.torah.org (rina.torah.org [208.229.147.50]) by honor.greatcircle.com (Postfix) with ESMTP id CAE1E17E8B for ; Tue, 10 Oct 2000 12:26:07 -0700 (PDT) Received: from localhost (brozen@localhost) by rina.torah.org (8.9.3/8.9.3/Debian/GNU) with ESMTP id PAA16593; Tue, 10 Oct 2000 15:49:01 -0400 Date: Tue, 10 Oct 2000 21:49:01 +0200 (IST) From: Brock Rozen To: Mj2 Development Lists , mj2-dev@csf.colorado.edu Subject: Installation Issues & Suggestions Message-ID: X-Backup: Disabled MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Hi, I've always been a little baffled by the way Mj2 is installed. While it's fairly easy, at last count (and my last count is fairly old), you had to setup domains during the installation process, as well as various other settings. I don't know...isn't there any other way to do this? Couldn't we make the "make", "make test", "make install" process not include actual configuration? IMHO, this should be a separate utility, that can be run over and over again after installation, but wouldn't actually result in another "make install" (which might scare quite a few people once they have a living, breathing production system). This utility could be a simple menu system (something similar to the Linux kernel "make menuconfig" comes to mind) that has an "Options", "Add Domain", "Delete Domain", "Change Domain", "Change Admin Password" options. I guess it could be the "backdoor" to the whole system....but it'd sure put less pressure on the original installation process! Thoughts? Thanks! -- Brock Rozen brozen@torah.org From majordomo-workers-owner Tue Oct 10 13:18:49 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id NAA21448; Tue, 10 Oct 2000 13:08:38 -0700 (PDT) Received: from epithumia.math.uh.edu (epithumia.math.uh.edu [129.7.128.2]) by honor.greatcircle.com (Postfix) with ESMTP id 70C1F17E8B for ; Tue, 10 Oct 2000 13:08:33 -0700 (PDT) Received: (from tibbs@localhost) by epithumia.math.uh.edu (8.9.3/8.9.3) id PAA08861; Tue, 10 Oct 2000 15:31:35 -0500 To: Mj2 Development Lists , mj2-dev@csf.colorado.edu Subject: Re: Installation Issues & Suggestions References: From: Jason L Tibbitts III Date: 10 Oct 2000 15:31:35 -0500 In-Reply-To: Brock Rozen's message of "Tue, 10 Oct 2000 21:49:01 +0200 (IST)" Message-ID: Lines: 22 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "BR" == Brock Rozen writes: BR> While it's fairly easy, at last count (and my last count is fairly BR> old), you had to setup domains during the installation process, as well BR> as various other settings. The reason for this is that some things are actually written into the scripts as they are installed. This frees us from having to put a configuration file in a "well known" location. That's not a very good reason, however, because it's essentially trumped by the need for system-independent packages and adding domains at runtime. BR> I don't know...isn't there any other way to do this? Yes, there is. We need to allow for an external configuration file and move into it nearly everything that gets written into the scripts by installbin. (I think what can stay is LOCK_EX, LOCK_NB, LOCK_UN, O_WRONLY, O_CREAT, O_EXCL and we would need to include the path to the config file.) The only problem with this is time. - J< From majordomo-workers-owner Tue Oct 10 15:19:59 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id PAA22700; Tue, 10 Oct 2000 15:10:25 -0700 (PDT) Received: from rina.torah.org (rina.torah.org [208.229.147.50]) by honor.greatcircle.com (Postfix) with ESMTP id 6F77F17E8B for ; Tue, 10 Oct 2000 15:10:14 -0700 (PDT) Received: from localhost (brozen@localhost) by rina.torah.org (8.9.3/8.9.3/Debian/GNU) with ESMTP id SAA00734; Tue, 10 Oct 2000 18:33:25 -0400 Date: Wed, 11 Oct 2000 00:33:25 +0200 (IST) From: Brock Rozen To: Jason L Tibbitts III Cc: Mj2 Development Lists , mj2-dev@csf.colorado.edu Subject: Re: Installation Issues & Suggestions In-Reply-To: Message-ID: X-Backup: Disabled MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On 10 Oct 2000 at 15:31, Jason L Tibbitts III wrote about "Re: Installation...": > The reason for this is that some things are actually written into the > scripts as they are installed. This frees us from having to put a > configuration file in a "well known" location. That's not a very good > reason, however, because it's essentially trumped by the need for > system-independent packages and adding domains at runtime. The latter is my main concern, actually. > BR> I don't know...isn't there any other way to do this? > > Yes, there is. We need to allow for an external configuration file and > move into it nearly everything that gets written into the scripts by > installbin. (I think what can stay is LOCK_EX, LOCK_NB, LOCK_UN, O_WRONLY, > O_CREAT, O_EXCL and we would need to include the path to the config file.) Looks good to me! Hopefully this will be one of those things that Michael comes back with and says "Implemented!" ;-) But, I think, it most definitely needs to be done. Otherwise we're unneedlessly making installation and usage too hard... Thanks! -- Brock Rozen brozen@torah.org From majordomo-workers-owner Tue Oct 10 16:35:02 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id QAA23401; Tue, 10 Oct 2000 16:28:08 -0700 (PDT) Received: from epithumia.math.uh.edu (epithumia.math.uh.edu [129.7.128.2]) by honor.greatcircle.com (Postfix) with ESMTP id EBECA17E8B for ; Tue, 10 Oct 2000 16:28:02 -0700 (PDT) Received: (from tibbs@localhost) by epithumia.math.uh.edu (8.9.3/8.9.3) id SAA09345; Tue, 10 Oct 2000 18:51:16 -0500 To: Mj2 Development Lists , mj2-dev@csf.colorado.edu Subject: Re: Installation Issues & Suggestions References: From: Jason L Tibbitts III Date: 10 Oct 2000 18:51:16 -0500 In-Reply-To: Brock Rozen's message of "Wed, 11 Oct 2000 00:33:25 +0200 (IST)" Message-ID: Lines: 22 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "BR" == Brock Rozen writes: BR> But, I think, it most definitely needs to be done. It would be nice to have a volunteer here who understands the needs of the packaging systems. I can do the work, but I'm not sure exactly what you can and can't do. I have made RPMs but I wouldn't call myself an expert. BR> Otherwise we're unneedlessly making installation and usage too BR> hard... Is it really hard now, though? I can't imagine anything easier than the current Q&A installation setup. I think it needs to be preserved. Hand-editing config files is really not the best thing to inflict on folks. Moving this until after a make install step really changes very little but allows packages to work; the installer wouldn't see much change (an extra step) but if what we have now makes installation and usage too hard then what we'll have afterwards won't really make it any easier. (You can actually add domains on the fly now, but nobody's written the code to do it. It would still have to be written after any of these changes.) - J< From majordomo-workers-owner Tue Oct 10 23:06:34 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id XAA27330; Tue, 10 Oct 2000 23:03:34 -0700 (PDT) Received: from rina.torah.org (rina.torah.org [208.229.147.50]) by honor.greatcircle.com (Postfix) with ESMTP id 690E617E8B for ; Tue, 10 Oct 2000 23:03:29 -0700 (PDT) Received: from localhost (brozen@localhost) by rina.torah.org (8.9.3/8.9.3/Debian/GNU) with ESMTP id CAA24454; Wed, 11 Oct 2000 02:26:45 -0400 Date: Wed, 11 Oct 2000 08:26:44 +0200 (IST) From: Brock Rozen To: Jason L Tibbitts III Cc: Mj2 Development Lists , mj2-dev@csf.colorado.edu Subject: Re: Installation Issues & Suggestions In-Reply-To: Message-ID: X-Backup: Disabled MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On 10 Oct 2000 at 18:51, Jason L Tibbitts III wrote about "Re: Installation...": > BR> But, I think, it most definitely needs to be done. > > It would be nice to have a volunteer here who understands the needs of the > packaging systems. I can do the work, but I'm not sure exactly what you > can and can't do. I have made RPMs but I wouldn't call myself an expert. Packages need the ability to "pre-compile" the software. That is, many systems (especially Debian) will take the software, patch it to follow it's own structure of directories, and then install it. Some may ask configuration questions afterwards and apply that. Actually, this really means that configuration has to be separate from installation. Naturally, you can't expect it to work without configuration -- but it just has to be a separate "job". Debian has introduced the "debconf" software which could, interactively, handle the configuration of Mj2 for Debian users and output a config file at the end of the process. I think Mj2 having the ability to accept a config file and act upon it would be a great thing. I remember talk about this as well. > BR> Otherwise we're unneedlessly making installation and usage too > BR> hard... > > Is it really hard now, though? I can't imagine anything easier than the > current Q&A installation setup. I think it needs to be preserved. I haven't checked any changes that might have been made recently (past few months) -- but consider adding a new domain. My memory says you had to go through the installation process again. Certainly, that could be easier? > Hand-editing config files is really not the best thing to inflict on Agreed. And that's why I suggested a config utility. It could be within the shell utility or through email -- but it needs to exist. Perhaps the installation could ask for the "master" domain, through which all following configuration could happen via email (like "create system") > folks. Moving this until after a make install step really changes very > little but allows packages to work; the installer wouldn't see much change > (an extra step) but if what we have now makes installation and usage too > hard then what we'll have afterwards won't really make it any easier. (You > can actually add domains on the fly now, but nobody's written the code to > do it. It would still have to be written after any of these changes.) Adding domains on the fly, I believe, seems to be the one main hinderance to proper installation and usage. And moving the configuration until after a `make install` might mean one more step, but it means that for many users who use packages the whole process just got a lot easier! When I said the process is `hard`, I was really referring to the fact that you can't add domains on the fly and that to do that you had to go through the install process again. That is `hard`. Running "make", "make test" and "make install" is not hard in and of itself -- but having to do it for new domains is! :) Thanks! -- Brock Rozen brozen@torah.org From majordomo-workers-owner Wed Oct 11 20:18:39 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id UAA12732; Wed, 11 Oct 2000 20:09:41 -0700 (PDT) Received: from thelab.hub.org (CDR8-44.accesscable.net [24.138.8.44]) by honor.greatcircle.com (Postfix) with ESMTP id 614B517E8B for ; Wed, 11 Oct 2000 20:09:36 -0700 (PDT) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.11.1/8.11.0) with ESMTP id e9C3VnL20525; Thu, 12 Oct 2000 00:31:49 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Thu, 12 Oct 2000 00:31:49 -0300 (ADT) From: The Hermit Hacker To: majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu Subject: bug in queuerun? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk hub# less mj_queuerun.debug [96456]Majordomo queue runner - Wed Oct 11 23:30:35 2000 [96456].Compilation took 0.148u, 0.000s [96456].Loading modules [96456].Loading modules..done, took 0.000 sec [96456].main::run_queue: Running queue [96456]..Majordomo::new: /usr/local/majordomo/lists, hub.org [96456]..Majordomo::new..done, took 1.000 sec --== Argument "" isn't numeric in gt at /usr/local/majordomo/bin/mj_queuerun line 287. [96568]Majordomo queue runner - Wed Oct 11 23:31:08 2000 [96568].Compilation took 0.133u, 0.016s [96568].Loading modules [96568].Loading modules..done, took 0.000 sec [96568].main::run_queue: Running queue [96568]..Majordomo::new: /usr/local/majordomo/lists, hub.org [96568]..Majordomo::new..done, took 0.000 sec --== Argument "" isn't numeric in gt at /usr/local/majordomo/bin/mj_queuerun line 287. relevant line being: # Now set the logging level to that of the list. $debug2 = $mj->list_config_get(undef, undef, $list, 'debug'); if ($debug1 > $debug2) {$debug2 = $debug1}; $::log->set_level($debug2); Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org From majordomo-workers-owner Sun Oct 15 16:07:36 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id PAA14867; Sun, 15 Oct 2000 15:52:00 -0700 (PDT) Received: by honor.greatcircle.com (Postfix, from userid 1013) id 3FDF017EB3; Sun, 15 Oct 2000 15:51:58 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by honor.greatcircle.com (Postfix) with ESMTP id CB07C17E8B; Fri, 13 Oct 2000 07:44:54 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e9DEvBJ01103; Fri, 13 Oct 2000 07:57:11 -0700 (PDT) Received: from netscape.com ([205.217.228.127]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id G2DJE602.9UA; Fri, 13 Oct 2000 08:08:30 -0700 Message-ID: <39E72511.527D5CBF@netscape.com> Date: Fri, 13 Oct 2000 10:06:57 -0500 From: dliston@netscape.com (Dan Liston) Organization: iPlanet E-Commerce Solutions, A Sun Netscape Alliance X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: majordomo-users@greatcircle.com Cc: majordomo-workers@greatcircle.com Subject: Re: Majordomo Security Issue? References: <01C0349C.900EB780.pboake@sympatico.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Eric brought up the fact that resend will allow a pipe to an executable as an argument to resend. I felt this to be dangerous, but not "that" dangerous. Either way, here is a fix. Change line 56 on an unmodified majordomo version 1.94.5 resend script: from if ($ARGV[0] =~ /^\@/) { to if (($ARGV[0] =~ /^\@/) && ($ARGV[0] !~ /[|]/)) { or insert this between lines 55 and 56 if ($ARGV[0] =~ /[|]/) { die("Pipe symbol found: $!\nStopped") } I think there is already a resend.5 patch, but I have not looked at it to see if either of these are included yet. The first solution silently ignores pipe/bar symbols as arguments, and the second squawks and dies with an error message if a pipe symbol is found in the argument. Either way, the "open" function is bypassed, and another security hole is closed. Dan Liston From majordomo-workers-owner Mon Oct 16 09:08:50 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id IAA26944; Mon, 16 Oct 2000 08:55:33 -0700 (PDT) Received: from rina.torah.org (rina.torah.org [208.229.147.50]) by honor.greatcircle.com (Postfix) with ESMTP id 69C8717E8C for ; Mon, 16 Oct 2000 08:55:27 -0700 (PDT) Received: from localhost (brozen@localhost) by rina.torah.org (8.9.3/8.9.3/Debian/GNU) with ESMTP id MAA16101; Mon, 16 Oct 2000 12:19:23 -0400 Date: Mon, 16 Oct 2000 18:19:22 +0200 (IST) From: Brock Rozen To: SRE Cc: Mj2 Development Lists , mj2-dev@csf.colorado.edu Subject: Re: Installation Issues & Suggestions In-Reply-To: <4.3.1.0.20001016060552.00dba4c0@pop.climber.org> Message-ID: X-Backup: Disabled MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On Mon, 16 Oct 2000 at 06:18, SRE wrote about "Re: Installation Issues &...": > >wouldn't actually result in another "make install" (which might scare quite > >a few people once they have a living, breathing production system). > > during the install. This will be required for creating and > renaming domains on the fly, so it might as well be available > for upgrades. Perhaps "make install" should be different than > "make upgrade"??? "make install" does a full configuration. IMHO, it shouldn't fully do it. Program location and stuff that normally doesn't change from install to install should be included in it. Beyond that, things that SHOULD be easily changeable (like domains) should be a different command. This should be to the point that we can do a "make install" over a current installation and have the old configuration *still* continue to work. That also makes it easy to ascertain what belongs in "make install" and what belongs in a "make config" (or something of the sort) -- anything that changes from version to version or install to install goes into "make install" and anything that makes sure configuration stays the same is "make config". (someone can probably do a better job at defining it than I did...but I hope you get the idea from this anyhow) > >I guess it could be the "backdoor" to the whole system....but it'd sure > >put less pressure on the original installation process! > > You mean leave the current "make install" alone, including that you > must specify at least one domain, and then come back later to change > and add stuff? That seems like a reasonable choice to me, but then > again I'm not the one who'll be writing it! from above, "make install" might run "make config" if it was previously not run. But "make install" should not touch domains, IMHO. -- Brock Rozen brozen@torah.org From majordomo-workers-owner Sun Oct 22 06:18:45 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id GAA28338; Sun, 22 Oct 2000 06:04:45 -0700 (PDT) Received: from gull.prod.itd.earthlink.net (gull.prod.itd.earthlink.net [207.217.121.85]) by honor.greatcircle.com (Postfix) with ESMTP id 1E13017E8B; Sun, 22 Oct 2000 06:04:37 -0700 (PDT) Received: from ee-nt.climber.org (pool0116.cvx7-bradley.dialup.earthlink.net [209.178.164.116]) by gull.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id GAA05315; Sun, 22 Oct 2000 06:29:41 -0700 (PDT) Message-Id: <4.3.1.0.20001022053531.00b9d7b0@pop.climber.org> X-Sender: eckert@pop.climber.org X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 22 Oct 2000 05:43:43 -0700 To: list-managers@GreatCircle.COM, majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu From: SRE Subject: Re: X Loop trapping Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk problem: Many list servers add some sort of loop trapping header, but at least one service provider adds identical headers to every email originated by any user in their domain... so those users appear to be bounces when they send posts or requests. ('*' replaces '-' below, to avoid traps on THIS list) At 08:40 PM 10/17/00, A. Subscriber wrote: >Never mind about the MS Outlook question...it appears that my mail server is >adding the X*Loop header...I tried sending using other mail programs and saw >the same header. So here's a guy for which EVERY message contains the header X*Loop*Detect: 1 At 08:40 PM 10/17/00, A. Subscriber wrote: >I have no control over this...is there any way for me to work around this >and get a response from the list server? I can disable Mj2's loop trapping stuff, but that opens up other problems and so far no one else I'm aware of is adding X*Loop. I add X*Loop headers to outgoing messages, and trap them in posts, to keep loops from hitting the list subscribers. I'm not sure what other packages do, so I'm consulting the oracle to see what you all suggest. Are you using X*Loop as an error trap? Do you have subscribers who send human-originated email with X*Loop headers? Opinions and experiences requested! Below is the response from this subscriber's tech support person: >Thank you for contacting technical support. I apologize for all the >inconvenience this issue may have caused you. Our mail system puts this >comment, X*Loop*Detect: 1, in the subject line to track looping mail > >According to RFCs, you can put a user-defined field that starts with ‘X-‘ >and we use this to track looping mail through our mail servers. If any mail >server isn’t accepting mail because of this, please contact the >administrators of that mail server and request them to setup their mail >server according to RFCs. > >If you have any other question or feel that this issue has not been resolved >to your satisfaction, please feel free to contact us again. > >Best regards >Technical support. From majordomo-workers-owner Sun Oct 22 09:18:45 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id JAA29714; Sun, 22 Oct 2000 09:15:07 -0700 (PDT) Received: from mailgate.novagate.net (mailgate.novagate.net [205.138.138.22]) by honor.greatcircle.com (Postfix) with ESMTP id DCA4217E8B for ; Sun, 22 Oct 2000 09:15:01 -0700 (PDT) Received: from [192.168.2.1] (004gra147.chartermi.net [24.247.4.147]) by mailgate.novagate.net (8.9.3/8.9.3) with ESMTP id MAA24417; Sun, 22 Oct 2000 12:40:05 -0400 (EDT) (envelope-from justdave@a2central.com) Mime-Version: 1.0 Message-Id: In-Reply-To: <4.3.1.0.20001022053531.00b9d7b0@pop.climber.org> References: <4.3.1.0.20001022053531.00b9d7b0@pop.climber.org> Date: Sun, 22 Oct 2000 12:40:01 -0400 To: majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu From: David Miller Subject: Re: X Loop trapping Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On 10/22/00 5:43 AM -0700, SRE wrote: >I'm not sure what other packages do, so I'm consulting the oracle to >see what you all suggest. Are you using X*Loop as an error trap? Do you >have subscribers who send human-originated email with X*Loop headers? > >Opinions and experiences requested! > >Below is the response from this subscriber's tech support person: > >>Thank you for contacting technical support. I apologize for all the >>inconvenience this issue may have caused you. Our mail system puts this >>comment, X*Loop*Detect: 1, in the subject line to track looping mail >> >>According to RFCs, you can put a user-defined field that starts with ëX-ë >>and we use this to track looping mail through our mail servers. If any mail >>server isnít accepting mail because of this, please contact the >>administrators of that mail server and request them to setup their mail >>server according to RFCs. >> >>If you have any other question or feel that this issue has not been resolved >>to your satisfaction, please feel free to contact us again. A: that ISP needs a lesson in what it means to follow the RFCs. :) Majordomo's following them just fine. B: Seems to me that instead of putting "X*Loop*Detect: 1" in the header and filtering on the presence of that header, it would make better sense to put in "X*Loop*Detect: majordomo@yourhost.com" and filter based on the content of that header matching. (replace * with - where necessary) Or, since X-headers can be anything you want, maybe even X-Majordomo-Loop-Detect: yourhost.com Dave Miller Technical Lead / Database Support A2Central.com: Your total source for Apple II computing news http://www.a2central.com/ justdave@a2central.com From majordomo-workers-owner Sun Oct 22 13:18:47 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id NAA01837; Sun, 22 Oct 2000 13:15:27 -0700 (PDT) Received: from epithumia.math.uh.edu (epithumia.math.uh.edu [129.7.128.2]) by honor.greatcircle.com (Postfix) with ESMTP id C0BCC17E8B for ; Sun, 22 Oct 2000 13:15:18 -0700 (PDT) Received: (from tibbs@localhost) by epithumia.math.uh.edu (8.9.3/8.9.3) id PAA28246; Sun, 22 Oct 2000 15:40:25 -0500 To: Stefan Morrell Cc: majordomo-workers@greatcircle.com, mj2-dev@csf.colorado.edu Subject: Re: Some thoughts on qmail.. References: <20001022180610.H12680@mort.level5.net> From: Jason L Tibbitts III Date: 22 Oct 2000 15:40:24 -0500 In-Reply-To: Stefan Morrell's message of "Sun, 22 Oct 2000 18:06:10 +0100" Message-ID: Lines: 47 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "SM" == Stefan Morrell writes: SM> The problem here is that having a .qmail-default file isn't enough. That's odd. The qmail support was contributed and has worked fine for other folks for some time now. Patches are of course welcome, but I don't have the means to test them. For the benefit of the folks on the mj2-dev list, where I'm CC'ing this, I'll quote the rest of the message. SM> In fact what is really needed is a .qmail file in ~alias for each and SM> every address qmail creates, to pipe the mail back into mj_enqueue, as SM> in the .qmail file created during install, or an entry in SM> /var/qmail/users/assign (along with running qmail-newu to rebuild the SM> cdb file and restarting the qmail queue daemons). I dunno how you might SM> want to automate this, but it will need to likely run setuid root or SM> possibly alias. Alternatively, the poor, long suffering sysadmin can SM> create all the files by hand... SM> Unless... SM> The aforementioned sysadmin can create himself a subdomain specifically SM> and only to handle mailing list traffic, in which case the whole thing SM> becomes much simpler and more elegant. He simply adds MX records for SM> the subdomain pointing at the canonical name of the qmail server and SM> then adds a line into /var/qmail/control/virtualdomains of the form SM> lists.mydomain.com:majordomo SM> Which causes all email for lists.mydomain.com to be processed according SM> to rules contained in .qmail files in majordomo's $HOME. Then he SM> creates a .qmail-default file with the pipe to mj_enqueue so that all SM> addresses on the lists subdomain are sent to the majordomo scripts, SM> which then process the email as normal. SM> My apologies if (as I suspect) I'm singing an old and weatherworn song, SM> but the qmail documentation and configuration questions currently in SM> the package aren't massively clear (so far at least), so I thought I'd SM> throw my hat into the ring. I have to say that this is the first time I've heard of problems like these with qmail. I do know that other qmail users have been able to use the software without problems, so I suspect that there's something beyond my understanding at work here. - J< From majordomo-workers-owner Sun Oct 22 17:49:00 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id RAA04060; Sun, 22 Oct 2000 17:43:50 -0700 (PDT) Received: from ivan.iecc.com (ivan.iecc.com [208.31.42.33]) by honor.greatcircle.com (Postfix) with SMTP id 9C24717E8B for ; Sun, 22 Oct 2000 17:43:45 -0700 (PDT) Received: (qmail 14728 invoked by uid 100); 22 Oct 2000 21:08:53 -0400 Date: Sun, 22 Oct 2000 21:08:43 -0400 (EDT) From: John R Levine To: Jason L Tibbitts III Cc: Stefan Morrell , majordomo-workers@greatcircle.com, mj2-dev@csf.colorado.edu Subject: Re: Some thoughts on qmail.. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk > SM> The problem here is that having a .qmail-default file isn't enough. > > That's odd. The qmail support was contributed and has worked fine for > other folks for some time now. Patches are of course welcome, but I don't > have the means to test them. The problem is that there are two different ways to glue qmail into majordomo. The simpler but less flexible is to use a .qmail-default file, which tells qmail to hand all mail to any otherwise unknown address to MJ, at which point MJ figures out what the address means and how to handle the mail. This works fine if the domain isn't used for much else. It doesn't work at all if, for example, the other addresses in the domain are looked up in a database, because the database lookup also needs to use a -default to catch its addresses. The other approach, which I've used for MJ 1, is to create all of the explicit aliases that each mailing list needs. That works, but it's a lot of qmail files. It's also possible to put multiple commands in a -default file, so that in principle MJ2 could sniff the address and do its thing if it's an address it recognizes, otherwise fall through to another program. Having done all sorts of things like that, I can report that it's too fragile -- if both programs are expecting the same address, one will win and the other will lose. My suggestion in most cases is to use a separate domain for mailing lists, lists.whatever.com, and only put mailing list addresses there. For that, the current -default technique works fine. 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 majordomo-workers-owner Mon Oct 23 01:35:03 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id BAA08544; Mon, 23 Oct 2000 01:27:36 -0700 (PDT) Received: from salsa.corp.adastra.co.uk (salsa.adastra.co.uk [195.153.31.100]) by honor.greatcircle.com (Postfix) with ESMTP id 26FD217EB9 for ; Mon, 23 Oct 2000 01:27:31 -0700 (PDT) Received: by salsa.corp.adastra.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 23 Oct 2000 09:48:21 +0100 Message-ID: <01C96046F0CCD311B216009027577A2B1C90CC@salsa.corp.adastra.co.uk> From: James Berry To: majordomo-workers@greatcircle.com, mj2-dev@csf.colorado.edu Subject: RE: Some thoughts on qmail.. Date: Mon, 23 Oct 2000 09:48:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk > The problem is that there are two different ways to glue qmail into > majordomo. The simpler but less flexible is to use a > .qmail-default file, which tells qmail to hand all mail to any otherwise unknown > address to MJ, at which point MJ figures out what the address means and how to > handle the mail. This works fine if the domain isn't used for much else. It > doesn't work at all if, for example, the other addresses in the domain are > looked up in a database, because the database lookup also needs to use a > -default to catch its addresses. I appologise for the last aborted message. Let's try again! :-) All .qmail files (including .qmail-default) respect error codes: 0 means that the delivery was successful; 99 means that the delivery was successful, but that qmail-local should ignore all further delivery instructions; 100 means that the delivery failed permanently (hard error); 111 means that the delivery failed but should be tried again in a little while (soft error). So; if mj2 exits with a "0" when it can't find the address and "99" when it recognises the address Then other applications that use the database can be after the majordomo line in ".qmail-default". Best wishes James From majordomo-workers-owner Mon Oct 23 01:50:41 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id BAA08510; Mon, 23 Oct 2000 01:23:53 -0700 (PDT) Received: from salsa.corp.adastra.co.uk (salsa.adastra.co.uk [195.153.31.100]) by honor.greatcircle.com (Postfix) with ESMTP id 0CAC217E8B for ; Mon, 23 Oct 2000 01:23:47 -0700 (PDT) Received: by salsa.corp.adastra.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 23 Oct 2000 09:44:36 +0100 Message-ID: <01C96046F0CCD311B216009027577A2B1C90CB@salsa.corp.adastra.co.uk> From: James Berry To: majordomo-workers@greatcircle.com, mj2-dev@csf.colorado.edu Subject: RE: Some thoughts on qmail.. Date: Mon, 23 Oct 2000 09:44:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk > > SM> The problem here is that having a .qmail-default file > isn't enough. > > > > That's odd. The qmail support was contributed and has > worked fine for > > other folks for some time now. Patches are of course > welcome, but I don't > > have the means to test them. > > The problem is that there are two different ways to glue qmail into > majordomo. The simpler but less flexible is to use a > .qmail-default file, which tells qmail to hand all mail to any otherwise unknown > address to MJ, at which point MJ figures out what the address means and how to > handle the mail. This works fine if the domain isn't used for much else. It > doesn't work at all if, for example, the other addresses in the domain are > looked up in a database, because the database lookup also needs to use a > -default to catch its addresses. Exit codes are used in .qmail-default (and other qmail commands): > > The other approach, which I've used for MJ 1, is to create all of the > explicit aliases that each mailing list needs. That works, > but it's a lot of > qmail files. It's also possible to put multiple commands in > a -default file, > so that in principle MJ2 could sniff the address and do its > thing if it's an > address it recognizes, otherwise fall through to another program. > > Having done all sorts of things like that, I can report that > it's too fragile > -- if both programs are expecting the same address, one will > win and the > other will lose. My suggestion in most cases is to use a > separate domain for > mailing lists, lists.whatever.com, and only put mailing list > addresses there. > For that, the current -default technique works fine. > > 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 majordomo-workers-owner Mon Oct 23 07:05:43 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id HAA13492; Mon, 23 Oct 2000 07:01:56 -0700 (PDT) Received: from menyapa.cc.columbia.edu (menyapa.cc.columbia.edu [128.59.59.38]) by honor.greatcircle.com (Postfix) with ESMTP id 8829A17E8B; Mon, 23 Oct 2000 07:01:46 -0700 (PDT) Received: from dynamic-31-229.dyn.columbia.edu (dynamic-31-229.dyn.columbia.edu [128.59.31.229]) by menyapa.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA06043; Mon, 23 Oct 2000 10:20:24 -0400 (EDT) Date: Mon, 23 Oct 2000 10:20:22 -0400 From: Joseph Brennan Reply-To: Postmaster To: SRE , list-managers@GreatCircle.COM, majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu Cc: @columbia.edu Subject: Re: X Loop trapping Message-ID: <51450588.3181285222@dynamic-31-229.dyn.columbia.edu> In-Reply-To: <4.3.1.0.20001022053531.00b9d7b0@pop.climber.org> X-Mailer: Mulberry/2.0.0 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk --On Sunday, October 22, 2000 05:43 -0700 SRE wrote: > At 08:40 PM 10/17/00, A. Subscriber wrote: > >I have no control over this...is there any way for me to work > around this >and get a response from the list server? > > I can disable Mj2's loop trapping stuff, but that opens up other > problems and so far no one else I'm aware of is adding X*Loop. > I add X*Loop headers to outgoing messages, and trap them in posts, > to keep loops from hitting the list subscribers. I don't have Majordomo 2 yet, but the only reliable way to do this is to put your own system's name into the X-Loop: header, to make it unique. Relying on something as generic as "X-Loop-Detect: 1" is asking for trouble. If it had "X-Loop: Majordomo-myhostname.mydomain 1" then you'd have better reason to question another host putting your host's name and domain into their mail. FYI, Procmail recommends putting X-Loop headers into automatic replies. Joseph Brennan postmaster@columbia.edu Academic Technologies Group, Academic Information Systems (AcIS) From majordomo-workers-owner Mon Oct 23 17:50:31 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id RAA19253; Mon, 23 Oct 2000 17:46:27 -0700 (PDT) Received: from avocet.prod.itd.earthlink.net (avocet.prod.itd.earthlink.net [207.217.121.50]) by honor.greatcircle.com (Postfix) with ESMTP id 927FE17E8B; Mon, 23 Oct 2000 17:46:18 -0700 (PDT) Received: from ee-nt.climber.org (sdn-ar-015casfrMP164.dialsprint.net [158.252.219.166]) by avocet.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id SAA08121; Mon, 23 Oct 2000 18:11:45 -0700 (PDT) Message-Id: <4.3.1.0.20001023174734.00c12520@pop.climber.org> X-Sender: eckert@pop.climber.org X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 23 Oct 2000 17:50:43 -0700 To: Joe Smith From: SRE Subject: Re: Mj2: Re: X Loop trapping Cc: list-managers@greatcircle.com, majordomo-workers@greatcircle.com, mj2-dev@csf.colorado.edu In-Reply-To: <20001023143936.A11737@tardis.Tymnet.COM> References: <4.3.1.0.20001022053531.00b9d7b0@pop.climber.org> <4.3.1.0.20001022053531.00b9d7b0@pop.climber.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk At 02:39 PM 10/23/00, Joe Smith wrote: >Any loop detector that is not based on the list name is doomed to failure. Well, just trapping ANY x*loop header certainly stops loops! It also stops a bunch of autoresponders that follow the convention of putting loop headers in. This is the first time I've seen an ISP put them in every message sent by every client, and I deliberately set my lists up to look for ANY variant of x*loop because I've seen a bunch of them and they were ALL automated messages. If I make my server only trap headers added by my server, then I don't catch vacation autoresponders and badly behaving routers. (Yes, I look both in the headers and the message body...) From majordomo-workers-owner Sun Oct 29 14:20:47 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id OAA29477; Sun, 29 Oct 2000 14:09:27 -0800 (PST) Received: from thelab.hub.org (CDR20-53.accesscable.net [24.138.20.53]) by honor.greatcircle.com (Postfix) with ESMTP id 6ED8717E8B for ; Sun, 29 Oct 2000 14:09:22 -0800 (PST) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.11.1/8.11.1) with ESMTP id e9TMY7F13242; Sun, 29 Oct 2000 18:34:07 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Sun, 29 Oct 2000 18:34:07 -0400 (AST) From: The Hermit Hacker To: majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu Subject: excessive loading ... ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk there is no load on the machine, how can it be excessive? [85064].Enqueue: In... [85064].Enqueue: In: Excessive load; queueing [85064].Enqueue: Excessive load; queueing [85064].Enqueue: In... [85064].Enqueue: In: Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org From majordomo-workers-owner Mon Oct 30 08:34:33 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id IAA12238; Mon, 30 Oct 2000 08:25:07 -0800 (PST) Received: from epithumia.math.uh.edu (epithumia.math.uh.edu [129.7.128.2]) by honor.greatcircle.com (Postfix) with ESMTP id C239D17E8B for ; Mon, 30 Oct 2000 08:25:00 -0800 (PST) Received: (from tibbs@localhost) by epithumia.math.uh.edu (8.9.3/8.9.3) id KAA21432; Mon, 30 Oct 2000 10:51:42 -0600 To: majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu Subject: Re: excessive loading ... ? References: From: Jason L Tibbitts III Date: 30 Oct 2000 10:51:42 -0600 In-Reply-To: The Hermit Hacker's message of "Sun, 29 Oct 2000 18:34:07 -0400 (AST)" Message-ID: Lines: 17 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "THH" == The Hermit Hacker writes: THH> there is no load on the machine, how can it be excessive? All of the queue runners are busy (i.e. the load exceeds the maximum concurrency that you configured things to run with), so the queue server logs the fact and drops the message into the queue to be picked up by the next idle runner. There is actually a condition (which I believe is quite rare) that will cause this to happen when all of the queue slots were full but then all of the runners exited. We go through noting their deaths and run out of slots without starting up a new runner. Is this happening to you often? Do you have runners working at the time? - J< From majordomo-workers-owner Mon Oct 30 13:48:49 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id NAA15258; Mon, 30 Oct 2000 13:34:16 -0800 (PST) Received: from thelab.hub.org (CDR20-53.accesscable.net [24.138.20.53]) by honor.greatcircle.com (Postfix) with ESMTP id C7D9F17EB1 for ; Mon, 30 Oct 2000 13:34:05 -0800 (PST) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.11.1/8.11.1) with ESMTP id e9ULx6c05005; Mon, 30 Oct 2000 17:59:06 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Mon, 30 Oct 2000 17:59:06 -0400 (AST) From: The Hermit Hacker To: Jason L Tibbitts III Cc: majordomo-workers@GreatCircle.COM, mj2-dev@csf.colorado.edu Subject: Re: excessive loading ... ? 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 30 Oct 2000, Jason L Tibbitts III wrote: > >>>>> "THH" == The Hermit Hacker writes: > > THH> there is no load on the machine, how can it be excessive? > > All of the queue runners are busy (i.e. the load exceeds the maximum > concurrency that you configured things to run with), so the queue server > logs the fact and drops the message into the queue to be picked up by the > next idle runner. > > There is actually a condition (which I believe is quite rare) that will > cause this to happen when all of the queue slots were full but then all of > the runners exited. We go through noting their deaths and run out of slots > without starting up a new runner. > > Is this happening to you often? Do you have runners working at the time? Right now, I'm getting some very *weird* activity on the pgsql lists, that I'm not sure if is a problem with majordomo or with sendmail ... Michael already has access to the machine, but if you would like to look around, you are most welcome to have access to it also ... From majordomo-workers-owner Mon Oct 30 16:34:41 2000 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id QAA16966; Mon, 30 Oct 2000 16:30:35 -0800 (PST) Received: from gull.prod.itd.earthlink.net (gull.prod.itd.earthlink.net [207.217.121.85]) by honor.greatcircle.com (Postfix) with ESMTP id 3C1C117E8B for ; Mon, 30 Oct 2000 16:30:28 -0800 (PST) Received: from ee-nt.climber.org (sdn-ar-015casfrMP127.dialsprint.net [158.252.219.129]) by gull.prod.itd.earthlink.net (EL-8_9_3_