From majordomo-workers-owner Wed Jul 1 16:14:55 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id QAA09834; Wed, 1 Jul 1998 16:12:10 -0700 (PDT) Received: from Mail.Golux.Com (ns2.remulak.net [198.115.138.27]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id QAA09822 for ; Wed, 1 Jul 1998 16:12:01 -0700 (PDT) Received: from Golux.Com (p64.tc1.nashu.NH.tiac.com [206.119.67.65]) by Mail.Golux.Com (8.8.5/8.8.5) with ESMTP id TAA00793; Wed, 1 Jul 1998 19:09:58 -0400 Message-ID: <359AC3AA.D21C9EC9@Golux.Com> Date: Wed, 01 Jul 1998 19:18:02 -0400 From: Rodent of Unusual Size Organization: The Apache Group X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: Majordomo-Workers@GreatCircle.Com Subject: Another semi-MD/mbox question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk My thanks to everyone who helped with my last question. As an aside, I was surprised when I fed a multimonth mbox file into archive2 and didn't get it split according to the message Date fields. Does anyone else think that would be a worthwhile ability? And the serious question: I have a friend who uses a POP server these days, but has an old Unix account that has been accumulating email for a while. Does anyone know if there's a way to pick up an mbox file and feed it to sendmail (or whatever) so it will be treated as the bunch of individual messages it really is? He wants to set up a .forward and then feed his existing mbox to something that will do the normal forwarding thing. As always, thanks to the mail gurus.. #ken P-)} Ken Coar Apache Group member "Apache Server for Dummies" From majordomo-workers-owner Wed Jul 1 16:44:55 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id QAA10165; Wed, 1 Jul 1998 16:42:33 -0700 (PDT) Received: from stingray.ivision.co.uk (stingray.ivision.co.uk [195.50.91.40]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id QAA10158 for ; Wed, 1 Jul 1998 16:42:27 -0700 (PDT) Received: from pretender.ivision.co.uk [194.112.51.42] by stingray.ivision.co.uk with smtp (Exim 1.62 #2) id 0yrWWx-0001Vi-00; Thu, 2 Jul 1998 00:43:16 +0100 Message-Id: <3.0.5.32.19980702004154.0080c560@stingray.ivision.co.uk> X-Sender: manarpop@stingray.ivision.co.uk X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 02 Jul 1998 00:41:54 +0100 To: Majordomo-Workers@GreatCircle.Com From: Manar Hussain Subject: Re: Another semi-MD/mbox question In-Reply-To: <359AC3AA.D21C9EC9@Golux.Com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk At 19:18 01/07/98 -0400, Rodent of Unusual Size wrote: >My thanks to everyone who helped with my last question. As an >aside, I was surprised when I fed a multimonth mbox file into archive2 >and didn't get it split according to the message Date fields. Does >anyone else think that would be a worthwhile ability? We have a "gateway" perl script for our web archive - on this we use the "last" received line - i.e. a good attempt at using the time of delivery. THis means a regexp needs tweeking so it could be a bit of a pain for a general roll out system but it's very nice to be able to do the something alogn the lines of "nuke all web archives ; cat archives//* | gateway" and always get pretty much the same result. >And the serious question: I have a friend who uses a POP server >these days, but has an old Unix account that has been accumulating >email for a while. Does anyone know if there's a way to pick >up an mbox file and feed it to sendmail (or whatever) so it >will be treated as the bunch of individual messages it really is? >He wants to set up a .forward and then feed his existing mbox >to something that will do the normal forwarding thing. > >As always, thanks to the mail gurus.. The file sitting behing the pop server is almost certainly in mbox format. If you have a hand from a sysadmin it shouldn't be too hard to tack it on the end of his pop box so that it get's downloaded as if he'd been sent it. I've not tried anything like that but I'd guess it should be possible. Or does he not want to download it as if it had hit his pop box via normal means? If you want to effectively resend it then I think all you need to do is break it up into seperate individual and properly formated message (remove the "from " line at the start and preferable most of the received lines and other stuff that wouldn't have been in the message pre-sending) and then do something like sendmail -t < as a trusted mail user in order to resend it. Manar From majordomo-workers-owner Wed Jul 1 16:59:57 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id QAA10465; Wed, 1 Jul 1998 16:51:13 -0700 (PDT) Received: from stingray.ivision.co.uk (stingray.ivision.co.uk [195.50.91.40]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id QAA10450 for ; Wed, 1 Jul 1998 16:51:06 -0700 (PDT) Received: from pretender.ivision.co.uk [194.112.51.42] by stingray.ivision.co.uk with smtp (Exim 1.62 #2) id 0yrWfO-0001aB-00; Thu, 2 Jul 1998 00:52:00 +0100 Message-Id: <3.0.5.32.19980702005037.007ed390@stingray.ivision.co.uk> X-Sender: manarpop@stingray.ivision.co.uk X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 02 Jul 1998 00:50:37 +0100 To: Majordomo-Workers@GreatCircle.Com From: Manar Hussain Subject: Re: Another semi-MD/mbox question In-Reply-To: <3.0.5.32.19980702004154.0080c560@stingray.ivision.co.uk> References: <359AC3AA.D21C9EC9@Golux.Com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk If my previous makes no sense shoot me for sending it way too late after a night out :) >We have a "gateway" perl script for our web archive - on this we use the >"last" received line - i.e. a good attempt at using the time of delivery. >THis means a regexp needs tweeking so it could be a bit of a pain for a By this I mean the code to get the time becomes somewhat dependant on the MTA and in our case even the hostname (allows for stronger matching). Manar From majordomo-workers-owner Wed Jul 1 17:29:58 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id RAA11009; Wed, 1 Jul 1998 17:22:50 -0700 (PDT) Received: from stingray.ivision.co.uk (stingray.ivision.co.uk [195.50.91.40]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id RAA11002 for ; Wed, 1 Jul 1998 17:22:44 -0700 (PDT) Received: from pretender.ivision.co.uk [194.112.51.42] by stingray.ivision.co.uk with smtp (Exim 1.62 #2) id 0yrXA2-0001iO-00; Thu, 2 Jul 1998 01:23:38 +0100 Message-Id: <3.0.5.32.19980702012216.0080f900@stingray.ivision.co.uk> X-Sender: manarpop@stingray.ivision.co.uk X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 02 Jul 1998 01:22:16 +0100 To: Majordomo-Workers@GreatCircle.COM From: Manar Hussain Subject: Re: Another semi-MD/mbox question In-Reply-To: <4.0.1.19980701170224.00ed66d0@www.sandiegoca.ncr.com> References: <3.0.5.32.19980702004154.0080c560@stingray.ivision.co.uk> <359AC3AA.D21C9EC9@Golux.Com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >If you have procmail, "formail -s mbox | /usr/lib/sendmail address". Don't >use -t! sendmail will re-interpret all headers including destination >addresses, so you could end up pumping old mail back to lists. Not good. Sorry - that was worth stressing. It's what I meant by "effectively resend". From majordomo-workers-owner Thu Jul 2 08:44:55 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id IAA22402; Thu, 2 Jul 1998 08:35:46 -0700 (PDT) Received: from spsem02.sps.mot.com ([192.70.231.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id IAA22395 for ; Thu, 2 Jul 1998 08:35:39 -0700 (PDT) Received: from mogate.sps.mot.com by spsem02.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA00415 for Majordomo-Workers@GreatCircle.COM; Thu, 2 Jul 98 08:36:37 MST Received: from motsps (motsps.sps.mot.com) by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA08173 for Majordomo-Workers@GreatCircle.COM; Thu, 2 Jul 98 08:36:25 MST Received: from nombre.risc.sps.mot.com by motsps (SMI-8.6/SMI-4.1/Email-2.1) id IAA28478 for ; Thu, 2 Jul 1998 08:35:26 -0700 Received: from miaow.risc.sps.mot.com (miaow.risc.sps.mot.com [223.72.249.15]) by nombre.risc.sps.mot.com (8.8.7/8.8.7) with ESMTP id KAA06361; Thu, 2 Jul 1998 10:34:10 -0500 (CDT) Received: (from dwolfe@localhost) by miaow.risc.sps.mot.com (8.7.1/8.7.3) id KAA13024; Thu, 2 Jul 1998 10:36:02 -0500 Message-Id: <19980702103602.C16674@risc.sps.mot.com> Date: Thu, 2 Jul 1998 10:36:02 -0500 From: Dave Wolfe To: Rodent of Unusual Size , Majordomo-Workers@GreatCircle.COM Subject: Re: Another semi-MD/mbox question References: <359AC3AA.D21C9EC9@Golux.Com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <359AC3AA.D21C9EC9@Golux.Com>; from Rodent of Unusual Size on Wed, Jul 01, 1998 at 07:18:02PM -0400 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk [ Rodent of Unusual Size writes: ] > As an aside, I was surprised when I fed a multimonth mbox file into > archive2 and didn't get it split according to the message Date fields. That's worked for me, exactly what was the command line you used? You must specify the -u option and either -m or -M to get messages broken out by month (and of course, -f ). Perhaps you didn't really have the envelope From_ headers still present in the mbox? -- Dave Wolfe From majordomo-workers-owner Thu Jul 2 12:45:09 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id MAA25212; Thu, 2 Jul 1998 12:36:24 -0700 (PDT) Received: from rudra3.ccsf.cc.ca.us (rudra3.ccsf.cc.ca.us [147.144.3.238]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id MAA25204 for ; Thu, 2 Jul 1998 12:36:17 -0700 (PDT) Received: from ns7.ccsf.cc.ca.us by rudra3.ccsf.cc.ca.us via smtpd (for honor.greatcircle.com [198.102.244.44]) with SMTP; 2 Jul 1998 19:37:16 UT Received: from sol.ccsf.cc.ca.us (sol.ccsf.cc.ca.us [147.144.20.31]) by ns7.ccsf.cc.ca.us (8.8.5/8.8.5) with SMTP id MAA20593 for ; Thu, 2 Jul 1998 12:50:50 -0700 (PDT) Received: from localhost by sol.ccsf.cc.ca.us (SMI-8.6/SMI-SVR4) id MAA05490; Thu, 2 Jul 1998 12:37:13 -0700 Date: Thu, 2 Jul 1998 12:37:13 -0700 (PDT) From: "Joe R. Jah" To: majordomo-workers@greatcircle.com Subject: Unofficial Majordomo patches and contrib site Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Hi, A clarification note: Our server has gone behind a firewall and the high number port, >1024, connections to the server are blocked. Web browsers connect to FTP sites via "passive FTP" through high number ports.; therefore, if you are navigating with a web browser you won't be able to connect to the old URLs; please use the following URLs: http://sol.ccsf.cc.ca.us/ftp/majordomo-patches/ http://sol.ccsf.cc.ca.us/ftp/majordomo-contrib/ However, if you use a "regular" FTP client use the old, unchanged, URLs: ftp://sol.ccsf.cc.ca.us/majordomo-patches/ ftp://sol.ccsf.cc.ca.us/majordomo-contrib/ Joe _/ _/_/_/ _/ ____________ __o _/ _/ _/ _/ ______________ _-\<,_ _/ _/ _/_/_/ _/ _/ ......(_)/ (_) _/_/ oe _/ _/. _/_/ ah jjah@sol.ccsf.cc.ca.us From majordomo-workers-owner Thu Jul 2 23:45:02 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id XAA01855; Thu, 2 Jul 1998 23:40:19 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id XAA01845 for majordomo-workers@greatcircle.com; Thu, 2 Jul 1998 23:40:16 -0700 (PDT) Received: from ncr-sd.SanDiegoCA.NCR.COM (tan7.NCR.COM [192.127.94.7]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id RAA10933 for ; Wed, 1 Jul 1998 17:11:32 -0700 (PDT) Received: from jabberwocky (jabberwocky.SanDiegoCA.NCR.COM [153.64.69.123]) by ncr-sd.SanDiegoCA.NCR.COM (8.8.5/8.7.3) with SMTP id RAA05969; Wed, 1 Jul 1998 17:11:16 -0700 (PDT) Message-Id: <4.0.1.19980701170224.00ed66d0@www.sandiegoca.ncr.com> X-Sender: bhoule@sparc.sandiegoca.ncr.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 01 Jul 1998 17:06:45 -0700 To: Manar Hussain , Majordomo-Workers@GreatCircle.COM From: Bill Houle Subject: Re: Another semi-MD/mbox question In-Reply-To: <3.0.5.32.19980702004154.0080c560@stingray.ivision.co.uk> References: <359AC3AA.D21C9EC9@Golux.Com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk At 12:41 AM 7/2/98 +0100, Manar Hussain wrote: > >If you want to effectively resend it then I think all you need to do is >break it up into seperate individual and properly formated message (remove >the "from " line at the start and preferable most of the received lines and >other stuff that wouldn't have been in the message pre-sending) and then do >something like sendmail -t < as a trusted mail user in order to >resend it. If you have procmail, "formail -s mbox | /usr/lib/sendmail address". Don't use -t! sendmail will re-interpret all headers including destination addresses, so you could end up pumping old mail back to lists. Not good. --bill From majordomo-workers-owner Thu Jul 2 23:46:59 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id XAA01517; Thu, 2 Jul 1998 23:35:58 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id XAA01509 for majordomo-workers@greatcircle.com; Thu, 2 Jul 1998 23:35:56 -0700 (PDT) Received: from ncr-sd.SanDiegoCA.NCR.COM (tan7.NCR.COM [192.127.94.7]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id VAA17127; Mon, 29 Jun 1998 21:03:49 -0700 (PDT) Received: from jabberwocky (jabberwocky.SanDiegoCA.NCR.COM [153.64.69.123]) by ncr-sd.SanDiegoCA.NCR.COM (8.8.5/8.7.3) with SMTP id VAA22964; Mon, 29 Jun 1998 21:04:18 -0700 (PDT) Message-Id: <199806300404.VAA22964@ncr-sd.SanDiegoCA.NCR.COM> X-Sender: bhoule@www.sandiegoca.ncr.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 29 Jun 1998 21:04:24 -0700 To: majordomo-users@greatcircle.com From: Bill Houle Subject: buglet warning: truncation of long config lines Cc: majordomo-workers@greatcircle.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Earlier this month, Richard Hopkins posted a possible MajorCool bug report noting that long restrict_post lines were being truncated. In investigating this report, I have found that the truncation is caused by Majordomo's use of fixed-length fields in support of the "writeconfig" command (which MajorCool uses to 'refresh' config file comments). The 'writeconfig' function uses a format string where the right-hand-side $value is written out using a ~72char field: format OUT = @<<<<<<<<<<<<<<<<<<< @<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< $key, $intro ^<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ~~ $comment @<<<<<<<<<<<<<<<<<< @<< @<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< $key, $op, $value . Thus, long lines (>72 char) in config files are truncated. So...no patch, but a warning: Majordomo 1.9x users: if you have long restrict_post lines (or any other, for that matter), avoid using the "writeconfig" command or risk truncating the long entries. Keep a backup config handy for recreating the shortened lines. MajorCool 1.1.0 and above users: if this is a big problem for you, consider turning off the generation of the comments ($opt_cfcomments in the site config file). Disabling this setting avoids having Majordomo issue the "writeconfig" command on Web submissions. (Submissions by email still subject to truncation, of course.) --bill From majordomo-workers-owner Fri Jul 3 07:31:20 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id HAA17679; Fri, 3 Jul 1998 07:18:22 -0700 (PDT) Received: from stingray.ivision.co.uk (stingray.ivision.co.uk [195.50.91.40]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id HAA17662 for ; Fri, 3 Jul 1998 07:18:14 -0700 (PDT) Received: from pretender.ivision.co.uk [195.50.91.43] by stingray.ivision.co.uk with smtp (Exim 1.62 #2) id 0ys6gM-0007XH-00; Fri, 3 Jul 1998 15:19:22 +0100 Message-Id: <3.0.5.32.19980703151748.008174a0@stingray.ivision.co.uk> X-Sender: manarpop@stingray.ivision.co.uk X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 03 Jul 1998 15:17:48 +0100 To: majordomo-workers@greatcircle.com From: Manar Hussain Subject: minor resend bug Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk If you set a subject prefix on a list and then a mail comes through with a blank subject line (line exists but the sender has not entered any subject text) majordomo will eat up to and *including* the line return and hence drag the next header line into the subject line. The problem is visible with majordomo 1.93 and 1.94.4 - here's what we did to resend fix it: # prepend subject prefix # if ( (/^subject:\s*/i) && ($config_opts{$opt_l,"subject_prefix"} ne '')) { print STDERR "$0: parse_header: adding subject prefix\n" if $DEBUG; local($foo) = &config'substitute_values($config_opts{$opt_l,"subject_prefix"}, $opt_l);#'; local($foo_pat) = $foo; $foo_pat =~ s/(\W)/\\$1/g; # s/^subject:\s*/Subject: $foo /i if !/$foo_pat/; # Hack for when subject line is "Subject:\n" Above is original line# s/^subject:[ \t]*/Subject: $foo /i if !/$foo_pat/; } Manar From majordomo-workers-owner Tue Jul 7 03:15:30 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id DAA18813; Tue, 7 Jul 1998 03:08:56 -0700 (PDT) Received: from infomail.es (ncc1.infomail.es [194.224.53.134]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id DAA18806 for ; Tue, 7 Jul 1998 03:08:31 -0700 (PDT) Received: from pp9 ([195.53.207.245]) by infomail.es (Tid InfoMail Exchanger v2.00) with SMTP id #899806405.142160001; Thu, 1 Jan 1970 01:00:07 +0200 Message-Id: <2.2.32.19980707181707.0069ddf8@nsb2.infomail.es> X-Sender: 00105185@nsb2.infomail.es X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 07 Jul 1998 12:17:07 -0600 To: majordomo-workers@greatcircle.com From: RAFAEL SEGOVIA VILCHEZ Subject: A project X-Infomail-Id: 899806405.3788010A811066.46935 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Hallo all, I am an spanish student of engeneer.I have had to make a project for finishing my career.And this has been a service of workspace via mail and web based in majordomo for most of the administrate things. All the users have some rights (to write to the list, to read, to moderate,to be able to acces via web...).(most of them based in majordomo)(for example to be able to the write I used RESTRICT_POST). But with some differences: When you susbcribe someone you do it giving some rights,and the program writes his address in the necessary files. * You can also make all this things via web, (like subcribing, unsubscribing,to modificate the config,intro,info files via web,etc ). * You have a web space to create folders,files, etc.(you can put everykind of files via web or mail) Now,I have almost finished it and I would really need and appreciate someone who could be interested in the theme and that wants in an altruist way to read what I have done to see what he/she thinks of the idea ,of how is made and which mistakes sees. One inconvenient, is that it is written is spanish. I would also appreciate any references of people working or relacionating in this who could be interested. Other thing: I have modified majordomo program.I know it is GNU.Should I publish the code that I have done?? It is nothing comercial it is just for my studies. Thank you very much in advance From majordomo-workers-owner Tue Jul 7 21:30:03 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id VAA05729; Tue, 7 Jul 1998 21:24:37 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id VAA05721 for majordomo-workers@greatcircle.com; Tue, 7 Jul 1998 21:24:34 -0700 (PDT) Received: from blue.ncl.ac.uk (blue.ncl.ac.uk [128.240.3.158]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id EAA15562 for ; Fri, 3 Jul 1998 04:00:34 -0700 (PDT) Received: (qmail 10246 invoked by uid 1007); 3 Jul 1998 11:01:35 -0000 Date: Fri, 3 Jul 1998 12:01:35 +0100 (BST) From: Paul.Haldane@newcastle.ac.uk X-Sender: nph9@blue.ncl.ac.uk To: Jason L Tibbitts III cc: majordomo-workers@greatcircle.com Subject: Re: mj2 w/ unresolvable addresses In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Apologies for reviving this thread - I'm catching up after forgetting to read my majordomo folder. > Yes, that's the absolute worst. I have run across domains that do this to > me, but so far I haven't been able to find one when I want to find one... You might like to try onestopshop.net or theonramp.net - they've been like this for ages. We've had problems with this in the past (not running majordomo (yet) - locally written MLM + sendmail). sendmail treats addresses that it can't resolve as a parse error and that doesn't get cached and the fact that the nameservers for the domain are unreachable doesn't get cached by bind 4.x. It's a pain :-<. Paul -- Paul Haldane Mailbase From majordomo-workers-owner Tue Jul 7 21:32:10 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id VAA05809; Tue, 7 Jul 1998 21:25:45 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id VAA05796 for majordomo-workers@greatcircle.com; Tue, 7 Jul 1998 21:25:40 -0700 (PDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id SAA23124 for ; Fri, 3 Jul 1998 18:54:05 -0700 (PDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA18783 for <@sgi.engr.sgi.com:majordomo-workers@greatcircle.com>; Fri, 3 Jul 1998 18:55:20 -0700 (PDT) mail_from (relph@mando.engr.sgi.com) Received: from mando.engr.sgi.com (mando.engr.sgi.com [130.62.51.85]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA02352 for <@cthulhu.engr.sgi.com:majordomo-workers@greatcircle.com>; Fri, 3 Jul 1998 18:55:20 -0700 (PDT) mail_from (relph@mando.engr.sgi.com) Received: (from relph@localhost) by mando.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id SAA01604 for majordomo-workers@greatcircle.com; Fri, 3 Jul 1998 18:55:17 -0700 (PDT) Date: Fri, 3 Jul 1998 18:55:17 -0700 (PDT) From: relph@mando.engr.sgi.com (John Relph) Message-Id: <9807031855.ZM101335@mando.engr.sgi.com> Reply-To: relph@sgi.com X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: majordomo-workers@greatcircle.com Subject: another subject_prefix fix Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk So I installed that last subject_prefix patch for 1.94.4, and thought I ought to test it, and I discovered something. If there is NO "Subject" header at all, one never finds out that the message is from the given list. So I fixed it. This patch puts in a "Subject" header if none was given (but only if subject_prefix is set). -- John *** resend~ Fri Jul 3 10:14:04 1998 --- resend Fri Jul 3 18:43:43 1998 *************** *** 578,583 **** --- 578,584 ---- sub parse_header { local($gonna_bounce); local($kept_last) = 0; # our return flag/string. + local($subject_found) = 0; print STDERR "$0: parse_header: enter.\n" if $DEBUG; print STDERR "$0: parse_header: taboo_headers = $is_taboo_header\n" if $DEBUG; *************** *** 700,705 **** --- 701,707 ---- # s/^subject:\s*/Subject: $foo /i if !/$foo_pat/; # Hack for when subject line is "Subject:\n" s/^subject:[ \t]*/Subject: $foo /i if !/$foo_pat/; + $subject_found = 1; } # snag reply-to field *************** *** 745,750 **** --- 747,761 ---- if (defined($opt_r)) { print OUT "Reply-To: ", &config'substitute_values($opt_r), "\n"; #'; + } + + if (($subject_found == 0) + && ($config_opts{$opt_l,"subject_prefix"} ne '')) { + + print STDERR "$0: parse_header: adding subject prefix\n" if $DEBUG; + print OUT "Subject: ", + &config'substitute_values($config_opts{$opt_l,"subject_prefix"}, $opt_l), #' + " (none)\n"; } # print out per-list additonal headers From majordomo-workers-owner Wed Jul 8 01:17:43 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id BAA13617; Wed, 8 Jul 1998 01:06:35 -0700 (PDT) Received: from stingray.ivision.co.uk (stingray.ivision.co.uk [195.50.91.40]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id BAA13610 for ; Wed, 8 Jul 1998 01:06:28 -0700 (PDT) Received: from pretender.ivision.co.uk [195.50.91.43] by stingray.ivision.co.uk with smtp (Exim 1.62 #2) id 0ytpH9-00008k-00; Wed, 8 Jul 1998 09:08:28 +0100 Message-Id: <3.0.5.32.19980708090655.009b5130@stingray.ivision.co.uk> X-Sender: manarpop@stingray.ivision.co.uk X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 08 Jul 1998 09:06:55 +0100 To: majordomo-workers@greatcircle.com From: Manar Hussain Subject: Re: another subject_prefix fix In-Reply-To: <9807031855.ZM101335@mando.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk At 18:55 03/07/98 -0700, John Relph wrote: >So I installed that last subject_prefix patch for 1.94.4, and thought >I ought to test it, and I discovered something. If there is NO >"Subject" header at all, one never finds out that the message is from >the given list. So I fixed it. This patch puts in a "Subject" header >if none was given (but only if subject_prefix is set). Thanks for that - we kinda wondered about the case where there was no subject line but thought that was non RFC compliant so shouldn't ever happen. That said when have we been able to rely on adherence to the RFCs when it comes to mail :( Manar From majordomo-workers-owner Wed Jul 8 07:45:13 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id HAA23222; Wed, 8 Jul 1998 07:34:31 -0700 (PDT) Received: from spsem02.sps.mot.com ([192.70.231.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id HAA23213 for ; Wed, 8 Jul 1998 07:34:22 -0700 (PDT) Received: from mogate.sps.mot.com by spsem02.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA16830 for majordomo-workers@GreatCircle.COM; Wed, 8 Jul 98 07:36:13 MST Received: from risc.risc.sps.mot.com by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA17625 for majordomo-workers@GreatCircle.COM; Wed, 8 Jul 98 07:34:01 MST Received: from miaow.risc.sps.mot.com (miaow.risc.sps.mot.com [223.72.249.15]) by risc.risc.sps.mot.com (8.8.7/8.8.7) with ESMTP id JAA21108; Wed, 8 Jul 1998 09:31:54 -0500 (CDT) Received: (from dwolfe@localhost) by miaow.risc.sps.mot.com (8.7.1/8.7.3) id JAA25066; Wed, 8 Jul 1998 09:33:47 -0500 Message-Id: <19980708093346.D13244@risc.sps.mot.com> Date: Wed, 8 Jul 1998 09:33:46 -0500 From: Dave Wolfe To: Manar Hussain Cc: majordomo-workers@GreatCircle.COM, Majordomo patches Subject: Re: minor resend bug References: <3.0.5.32.19980703151748.008174a0@stingray.ivision.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <3.0.5.32.19980703151748.008174a0@stingray.ivision.co.uk>; from Manar Hussain on Fri, Jul 03, 1998 at 03:17:48PM +0100 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk [ Manar Hussain writes: ] > > If you set a subject prefix on a list and then a mail comes through with a > blank subject line (line exists but the sender has not entered any subject > text) majordomo will eat up to and *including* the line return and hence > drag the next header line into the subject line. > > > The problem is visible with majordomo 1.93 and 1.94.4 - here's what we did > to resend fix it: > > # prepend subject prefix > # > if ( (/^subject:\s*/i) > && ($config_opts{$opt_l,"subject_prefix"} ne '')) { > > print STDERR "$0: parse_header: adding subject prefix\n" if > $DEBUG; > local($foo) = > &config'substitute_values($config_opts{$opt_l,"subject_prefix"}, $opt_l);#'; > local($foo_pat) = $foo; > $foo_pat =~ s/(\W)/\\$1/g; > # s/^subject:\s*/Subject: $foo /i if !/$foo_pat/; > # Hack for when subject line is "Subject:\n" Above is original line# > s/^subject:[ \t]*/Subject: $foo /i if !/$foo_pat/; > } May I suggest the following instead of just space and tab? It's all whitespace less newlines. --- resend.orig Wed Aug 27 09:59:24 1997 +++ resend Wed Jul 8 09:30:03 1998 @@ -695,7 +695,7 @@ local($foo) = &config'substitute_values($config_opts{$opt_l,"subject_prefix"}, $opt_l);#'; local($foo_pat) = $foo; $foo_pat =~ s/(\W)/\\$1/g; - s/^subject:\s*/Subject: $foo /i if !/$foo_pat/; + s/^subject:[^\S\n]*/Subject: $foo /i if !/$foo_pat/; } # snag reply-to field -- Dave Wolfe From majordomo-workers-owner Sat Jul 11 21:30:05 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id VAA17239; Sat, 11 Jul 1998 21:29:06 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id VAA17229 for majordomo-workers@greatcircle.com; Sat, 11 Jul 1998 21:29:03 -0700 (PDT) Received: from jonah.chrysalis.com (jonah.chrysalis.com [199.172.48.7]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id OAA23827 for ; Fri, 10 Jul 1998 14:02:33 -0700 (PDT) Received: from kenny.chrysalis.com (IDENT:root@kenny.chrysalis.com [199.172.48.67]) by jonah.chrysalis.com (8.9.0/8.9.0) with ESMTP id RAA24053 for ; Fri, 10 Jul 1998 17:04:33 -0400 (EDT) Received: from kenny.chrysalis.com (IDENT:tvd@localhost [127.0.0.1]) by kenny.chrysalis.com (8.9.0/8.9.0) with ESMTP id RAA01784 for ; Fri, 10 Jul 1998 17:04:31 -0400 Message-Id: <199807102104.RAA01784@kenny.chrysalis.com> X-Mailer: exmh version 2.0.2 2/24/98 To: majordomo-workers@greatcircle.com Subject: bug with majordomo moderated lists? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Jul 1998 17:04:31 -0400 From: Theo Van Dinter Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Sorry if this has been asked before, I couldn't do a search of the list of the archive. If I send a message to a moderated list: Message text I get the following in the body of the message the list sees: 1.94.4 test! Sender: owner-theo_test@chrysalis.com Precedence: bulk I put a blank line between the approved line and the message text, it works fine. I tested this on both Majordomo 1.94.3 and 1.94.4. Thanks. -- Theo Van Dinter UNIX Systems Administrator Chrysalis Symbolic Design 978/436-9911 x163 From majordomo-workers-owner Sun Jul 12 18:14:56 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id SAA08239; Sun, 12 Jul 1998 18:05:19 -0700 (PDT) Received: from ivan.iecc.com (ivan.iecc.com [208.31.42.33]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id SAA08232 for ; Sun, 12 Jul 1998 18:05:14 -0700 (PDT) Received: (qmail 6855 invoked by uid 100); 13 Jul 1998 01:08:04 -0000 Date: Sun, 12 Jul 1998 21:08:04 -0400 (EDT) From: John R Levine To: Theo Van Dinter cc: majordomo-workers@greatcircle.com Subject: Re: bug with majordomo moderated lists? In-Reply-To: <199807102104.RAA01784@kenny.chrysalis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk > I put a blank line between the approved line and the message text, it works > fine. A quick look at the documentation reveals that's deliberate. I'm not sure I agree that it's the best way to do it, but I see why it works the way it does. 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 Sun Jul 12 18:29:56 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id SAA08525; Sun, 12 Jul 1998 18:24:13 -0700 (PDT) Received: from queernet.queernet.org (queernet.queernet.org [140.174.78.69]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id SAA08518 for ; Sun, 12 Jul 1998 18:23:59 -0700 (PDT) Received: from localhost (rogerk@localhost) by queernet.queernet.org (8.8.5/8.8.5) with SMTP id SAA24146 Date: Sun, 12 Jul 1998 18:26:08 -0700 (PDT) From: "Roger B.A. Klorese" To: John R Levine cc: Theo Van Dinter , majordomo-workers@GreatCircle.COM Subject: Re: bug with majordomo moderated lists? 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, 12 Jul 1998, John R Levine wrote: > A quick look at the documentation reveals that's deliberate. I'm not > sure I agree that it's the best way to do it, but I see why it works the > way it does. It's a header, f'heaven's sake. The ability to put it in the body at all is a hack to work around broken mailers. -- ROGER B.A. KLORESE rogerk@QueerNet.ORG urgent: rogerk-page@QueerNet.ORG 2215-R Market Street #576 San Francisco, CA 94114 +1 415 ALL-ARFF "There is only one real blasphemy -- the refusal of joy!" -- Paul Rudnick From majordomo-workers-owner Mon Jul 13 10:30:21 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id KAA25088; Mon, 13 Jul 1998 10:18:43 -0700 (PDT) Received: from neviim.torah.org (neviim.torah.org [207.239.101.202]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id KAA25081 for ; Mon, 13 Jul 1998 10:18:36 -0700 (PDT) Received: from localhost (brozen@localhost) by neviim.torah.org (8.8.8/8.8.8) with SMTP id NAA28584; Mon, 13 Jul 1998 13:20:50 -0400 Date: Mon, 13 Jul 1998 20:20:50 +0300 (IDT) From: Brock Rozen Reply-To: Brock Rozen To: "Roger B.A. Klorese" cc: John R Levine , Theo Van Dinter , majordomo-workers@GreatCircle.COM Subject: Re: bug with majordomo moderated lists? In-Reply-To: Message-ID: X-Backup: Disable X-URL: http://www.torah.org/~brozen MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On Sun, 12 Jul 1998, Roger B.A. Klorese wrote: > > A quick look at the documentation reveals that's deliberate. I'm not > > sure I agree that it's the best way to do it, but I see why it works the > > way it does. > > It's a header, f'heaven's sake. The ability to put it in the body at all > is a hack to work around broken mailers. Yes, Roger's right. I was basically the one who came up with this design, along with Jason when we fixed a previously unknown and unreliable system of approving messages that didn't work for everybody. If I remember correctly (gosh, I can't even remember what I've designed!) there are three methods to approving messages: 1) Replacing ALL the headers and using the Approved header -- all in the message body. Don't forget that line between headers and message ! 2) Take a regular message and place the Approved header in the first line of the message text 3) Send a regular message and just take on a Approved header (not in the message body). Why did we do it this way? Well, first of all, we wanted to take account of broken mailers, so we allowed all the headers to be replaced in the message body. Or for those mailers that don't allow adding headers, we allowed the Approved header to be placed in the first line. Why is the blank line required? Well, let's say you wanted to do this: (headers) Approved: blah blah blah Iamstartingmymessagebody: and decided to place a colon on the line How would it know what's header and what's not? THe blank line is the answer. That's it in about one page.... ---------------------------------- | Brock Rozen | brozen@torah.org | ---------------------------------- From majordomo-workers-owner Mon Jul 13 18:45:17 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id SAA05043; Mon, 13 Jul 1998 18:39:42 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id SAA05036 for ; Mon, 13 Jul 1998 18:39:36 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id UAA26220; Mon, 13 Jul 1998 20:42:22 -0500 (CDT) To: majordomo-workers@greatcircle.com Cc: djb@cr.yp.to Subject: Re: reliability and fastforward compatibility References: <19980627045608.8620.qmail@cr.yp.to> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 13 Jul 1998 20:42:22 -0500 In-Reply-To: "D. J. Bernstein"'s message of "27 Jun 1998 04:56:08 -0000" Message-ID: Lines: 27 X-Mailer: Gnus v5.6.9/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk I didn't see a response to Dan's message in my absence, so here comes a belated one now that I'm back in the country. >>>>> "DJB" == D J Bernstein writes: DJB> Reportedly one can make majordomo 1.94.* work with qmail's fastforward DJB> package by inserting DJB> system("newinclude","$listdir/$clean_list"); DJB> before &lclose(LIST) in &do_subscribe and &do_unsubscribe. That should do it, yes. DJB> Are there going to be further 1.94.* releases for users who aren't DJB> experimenting with 2.0? I doubt it. Things have been pretty dead on the 1.94.x front for a while now, and I'm not doing any work on it. Someone qmail inclined could put together a tested patch which could make it into the FAQ, though. This is much easier to accomplish than a new release. Also useful would be someone qmail-inclined and willing to do things with the direct qmail support in 2.0. I'd like to change the way it does things but I don't want to mess with it because I can't test it. - J< From majordomo-workers-owner Mon Jul 13 18:59:56 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id SAA05270; Mon, 13 Jul 1998 18:48:35 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id SAA05253 for ; Mon, 13 Jul 1998 18:48:28 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id UAA26332; Mon, 13 Jul 1998 20:51:24 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: another subject_prefix fix References: <3.0.5.32.19980708090655.009b5130@stingray.ivision.co.uk> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 13 Jul 1998 20:51:24 -0500 In-Reply-To: Manar Hussain's message of "Wed, 08 Jul 1998 09:06:55 +0100" Message-ID: Lines: 16 X-Mailer: Gnus v5.6.9/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "MH" == Manar Hussain writes: MH> Thanks for that - we kinda wondered about the case where there was no MH> subject line but thought that was non RFC compliant so shouldn't ever MH> happen. It is perfectly RFC compliant for a message to lack a Subject: line. RFC822 section A.3.1 specifies that the required headers are Date:, From: and either Bcc: or To:. Many people believe it is not RFC compliant to add a Subject: header just to put in the prefix. In any case, I posted a patch to change this behavior in various 1.9x versions more than once over the past few years. Currently Mj2 always adds the Subject:, but I may make it configurable if someone who cares can refresh my memory on how it can be construed as illegal. - J< From majordomo-workers-owner Wed Jul 15 12:45:06 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id MAA15907; Wed, 15 Jul 1998 12:30:09 -0700 (PDT) Received: from home.samurai.com (samurai.reptiles.org [198.96.117.149]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id MAA15883; Wed, 15 Jul 1998 12:29:58 -0700 (PDT) Received: (from bryanf@localhost) by home.samurai.com (8.9.0/8.9.0) id PAA05538; Wed, 15 Jul 1998 15:33:11 -0400 (EDT) Message-ID: <19980715153311.Q9184@samurai.com> Date: Wed, 15 Jul 1998 15:33:11 -0400 From: Bryan Fullerton To: Russ Allbery , majordomo-users@GreatCircle.COM Cc: majordomo-workers@GreatCircle.COM Subject: Re: MTA's (was: VERY large mailing lists.) References: <199807151552.LAA04801@cis.ohio-state.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93i In-Reply-To: ; from Russ Allbery on Wed, Jul 15, 1998 at 12:10:50PM -0700 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On Wed, Jul 15, 1998 at 12:10:50PM -0700, Russ Allbery wrote: > > If you're honestly curious about this question, please see my FAQ. It > mentions several of the reasons why I think qmail is better than sendmail > for Majordomo; the primary reasons for me are better security and much > easier handling of incoming mail (no need to maintain lots of opaque > aliases), as well as totally avoiding the problem of an unprotected > outgoing alias. Sounds kinda like majordomo2. Are there any qmail people (testing||helping code) majordomo2? Bryan -- http://www.samurai.com http://www.feh.net http://www.icomm.ca "One Code to rule them all, one Code to bind them In the land of Redmond where the Shadows lie." - Joe Thompson in ASR, with apologies to Tolkien From majordomo-workers-owner Wed Jul 15 14:30:10 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id OAA21828; Wed, 15 Jul 1998 14:21:38 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id OAA21820 for ; Wed, 15 Jul 1998 14:21:30 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id QAA11809; Wed, 15 Jul 1998 16:24:43 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: MTA's (was: VERY large mailing lists.) References: <199807151552.LAA04801@cis.ohio-state.edu> <19980715153311.Q9184@samurai.com> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 15 Jul 1998 16:24:43 -0500 In-Reply-To: Bryan Fullerton's message of "Wed, 15 Jul 1998 15:33:11 -0400" Message-ID: Lines: 21 X-Mailer: Gnus v5.6.9/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "BF" == Bryan Fullerton writes: BF> Sounds kinda like majordomo2. Or TLB, or some of the things you can do with bulk_mailer. I will admit that at first TLB started out as a hack around Sendmail stupidity. Now TLB (and by extension Majordomo2) has much, much more functionality. At some point, even qmail on the same host as your MLM will get bogged down. Running outbound delivery (the most resource-consuming part of the list software's task) can be moved to one or more other hosts. BF> Are there any qmail people (testing||helping code) majordomo2? There is now; someone chimed in this morning. There's been direct qmail support deep in the delivery mechanism for some time now, but I haven't tested it. (Thanks to Ryan Tadlock for that.) The idea is that you give a special hostname to connect to (in this case, "@qmail") in delivery_rules and it calls the qmail-queue program directly, avoiding the SMTP transaction. - J< From majordomo-workers-owner Wed Jul 15 15:00:25 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id OAA22875; Wed, 15 Jul 1998 14:50:24 -0700 (PDT) Received: from po1.glue.umd.edu (po1.glue.umd.edu [128.8.10.97]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id OAA22866 for ; Wed, 15 Jul 1998 14:50:19 -0700 (PDT) Received: from atlantis.csc.umd.edu ((IDENT rsw)@atlantis.csc.umd.edu [129.2.8.129]) by po1.glue.umd.edu (8.9.0.Beta6/8.9.0.Beta6) with SMTP id RAA06023 for ; Wed, 15 Jul 1998 17:53:37 -0400 (EDT) Date: Wed, 15 Jul 1998 17:53:34 -0400 (EDT) From: "Randall S. Winchester" To: majordomo-workers@GreatCircle.COM Subject: Mail vs a file: aliases when a new list is created. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk It would be helpful to have an "aliases" file created/maintained by mj2 when a new list creation is accepted. Currently you get mail back with what lines to add. It would still be good to get that mail so you can review the changes though. However, automated list generation needs the aliases information in the proper aliases file to finish processesing. Modern sendmail's allow for multiple alias files; O AliasFile=hesiod:aliases,/etc/mail/aliases.majordomo,/etc/mail/aliases It would be helpful if you could turn on "aliases-generation". Then to specify the location and name of the file. For us "$listdir/aliases" would be a fine directory, and "$domain" would be a fine name foe the aliases file. Thus we could have a sendmail.cf file with the following. O AliasFile=/var/mj2/aliases/majordomo.umd.edu,/var/mj2/aliases/other.umd.edu We could set sendmail to automatically generate the aliases file, or their could be a command run be mj2; /usr/lib/sendmail -bi -O AliasFile=$listdir/aliases/$domain Randall From majordomo-workers-owner Wed Jul 15 16:14:57 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id QAA26693; Wed, 15 Jul 1998 16:08:31 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id QAA26686 for ; Wed, 15 Jul 1998 16:08:25 -0700 (PDT) Received: from Mars.mcs.net (les@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id SAA09906; Wed, 15 Jul 1998 18:11:46 -0500 (CDT) Received: (from les@localhost) by Mars.mcs.net (8.8.7/8.8.2) id SAA08455; Wed, 15 Jul 1998 18:11:45 -0500 (CDT) From: Leslie Mikesell Message-Id: <199807152311.SAA08455@Mars.mcs.net> Subject: Re: MTA's (was: VERY large mailing lists.) To: tibbs@hpc.uh.edu (Jason L Tibbitts III) Date: Wed, 15 Jul 1998 18:11:44 -0500 (CDT) Cc: majordomo-workers@GreatCircle.COM In-Reply-To: from "Jason L Tibbitts III" at Jul 15, 98 04:24:43 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk According to Jason L Tibbitts III: > > BF> Sounds kinda like majordomo2. > > Or TLB, or some of the things you can do with bulk_mailer. I will admit > that at first TLB started out as a hack around Sendmail stupidity. Now TLB > (and by extension Majordomo2) has much, much more functionality. At some > point, even qmail on the same host as your MLM will get bogged down. > Running outbound delivery (the most resource-consuming part of the list > software's task) can be moved to one or more other hosts. How about adding one more trick? Let one of the inputs to the decision of forwarding/relay hosts be the number of recipients at a destination. Then, after TLB/Majordom2 sort the list of addresses, it could hand off the single-recipient-per-host addresses to one or more qmail relay hosts and give the multiple-recipients-per-host to something that will hold them together. Les Mikesell les@mcs.com From majordomo-workers-owner Wed Jul 15 16:29:57 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id QAA26883; Wed, 15 Jul 1998 16:15:26 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id QAA26874 for ; Wed, 15 Jul 1998 16:15:20 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id SAA14600; Wed, 15 Jul 1998 18:18:36 -0500 (CDT) To: Leslie Mikesell Cc: majordomo-workers@GreatCircle.COM Subject: Re: MTA's (was: VERY large mailing lists.) References: <199807152311.SAA08455@Mars.mcs.net> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 15 Jul 1998 18:18:36 -0500 In-Reply-To: Leslie Mikesell's message of "Wed, 15 Jul 1998 18:11:44 -0500 (CDT)" Message-ID: Lines: 19 X-Mailer: Gnus v5.6.9/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "LM" == Leslie Mikesell writes: LM> Then, after TLB/Majordom2 sort the list of addresses, it could hand off LM> the single-recipient-per-host addresses to one or more qmail relay LM> hosts and give the multiple-recipients-per-host to something that will LM> hold them together. I think I can understand what you're looking for, but the amount of complexity already in the list splitting mechanism is pretty high. Plus I just can't get my head around how this will interact with Majordomo's VERP-like bounce handling. (Which for the sake of avoiding flames I'll point out doesn't have the downside of qmail's method because it only applies to a small piece of the list at any one time.) Perhaps you could look at the delivery_rules documentation, especially the section on the 'minseparate' split, and see if some simple modification of that would do what you're looking for. - J< From majordomo-workers-owner Wed Jul 15 16:33:32 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id QAA27480; Wed, 15 Jul 1998 16:25:31 -0700 (PDT) Received: from mail1.halcyon.com (mail1.halcyon.com [206.63.63.40]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id QAA27473 for ; Wed, 15 Jul 1998 16:25:26 -0700 (PDT) Received: from [206.63.47.20] (callisto.nwnexus.com [206.63.47.20]) by mail1.halcyon.com (8.8.8/8.8.8) with ESMTP id QAA07419 for ; Wed, 15 Jul 1998 16:28:43 -0700 (PDT) X-Sender: wdickson@mail.halcyon.com Message-Id: In-Reply-To: <19980715153311.Q9184@samurai.com> References: ; from Russ Allbery on Wed, Jul 15, 1998 at 12:10:50PM -0700 <199807151552.LAA04801@cis.ohio-state.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Jul 1998 16:35:29 -0700 To: majordomo-workers@GreatCircle.COM From: "William R. Dickson -- System Administration" Subject: Majordomo 2 (was Re: MTA's (was: VERY large mailing lists.)) Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk At 3:33 PM -0400 7/15/98, Bryan Fullerton wrote: >> If you're honestly curious about this question, please see my FAQ. It >> mentions several of the reasons why I think qmail is better than sendmail >> for Majordomo; the primary reasons for me are better security and much >> easier handling of incoming mail (no need to maintain lots of opaque >> aliases), as well as totally avoiding the problem of an unprotected >> outgoing alias. > >Sounds kinda like majordomo2. Speaking of which, I haven't heard much about majordomo2 on the list lately. No new snapshots lately, either. Any recent news I've missed? -Bill _________________________________________________________________________ William R. Dickson - System Administration wdickson@nwnexus.com Northwest Nexus - Professional Internet Services Bellevue, WA USA Voice: 425 455-3505 Web: http://www.nwnexus.com/ Info: info@nwnexus.com From majordomo-workers-owner Wed Jul 15 16:36:40 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id QAA27346; Wed, 15 Jul 1998 16:21:57 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id QAA27339 for ; Wed, 15 Jul 1998 16:21:50 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id SAA14785; Wed, 15 Jul 1998 18:25:08 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: Mail vs a file: aliases when a new list is created. References: Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 15 Jul 1998 18:25:08 -0500 In-Reply-To: "Randall S. Winchester"'s message of "Wed, 15 Jul 1998 17:53:34 -0400 (EDT)" Message-ID: Lines: 26 X-Mailer: Gnus v5.6.9/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "RSW" == Randall S Winchester writes: RSW> It would be helpful to have an "aliases" file created/maintained by RSW> mj2 when a new list creation is accepted. That is indeed the plan. Unfortunately Sendmail 8.9 came out and changed the rules on alias file location and ownership, which forced me to retreat to just sending the suggested info somewhere and hope that someone else knew enough about what the new requirements would be. The important function is in the Mj::MTAConfig module. Feel free to see what there needs to be modified. If you need additional parameters just let me know and I'll see about adding config variables for them. RSW> Modern sendmail's allow for multiple alias files; Yes, but they also place restrictions on who can own them and where they can be located. I don't want to advocate turning DontBlameSendmail on because that reduces security. Of course, this has to work completely differently for some other MTA, which is something else that troubles me. I would prefer that the choice of MTA give no changes in general Majordomo operation. You could argue that creating lists is not general Majordomo operation. - J< From majordomo-workers-owner Wed Jul 15 16:45:00 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id QAA28552; Wed, 15 Jul 1998 16:42:47 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id QAA28535 for ; Wed, 15 Jul 1998 16:42:40 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id SAA15091; Wed, 15 Jul 1998 18:45:59 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: Majordomo 2 (was Re: MTA's (was: VERY large mailing lists.)) References: ; from Russ Allbery on Wed, Jul 15, 1998 at 12:10:50PM -0700 <199807151552.LAA04801@cis.ohio-state.edu> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 15 Jul 1998 18:45:58 -0500 In-Reply-To: "William R. Dickson -- System Administration"'s message of "Wed, 15 Jul 1998 16:35:29 -0700" Message-ID: Lines: 12 X-Mailer: Gnus v5.6.9/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "WRD" == "William R Dickson <-- System Administration" > writes: WRD> Any recent news I've missed? Well, there was the news about me leaving the country for a month for a much-needed vacation in Norway. I'm back now, but work stopped in my absence. (Which I find unfortunate; there was traffic in majordomo-workers but most of it was just crossposted stuff from majordomo-users. I had hoped that people would hash out a few things that I could just implement instead of thinking hard about.) - J< From majordomo-workers-owner Thu Jul 16 09:16:25 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id JAA14878; Thu, 16 Jul 1998 09:08:37 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id JAA14871 for ; Thu, 16 Jul 1998 09:08:26 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id LAA29946; Thu, 16 Jul 1998 11:11:30 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: MTA's (was: VERY large mailing lists.) References: <199807152311.SAA08455@Mars.mcs.net> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 16 Jul 1998 11:11:30 -0500 In-Reply-To: Jason L Tibbitts III's message of "15 Jul 1998 18:18:36 -0500" Message-ID: Lines: 15 X-Mailer: Gnus v5.6.9/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "JLT" == Jason L Tibbitts writes: JLT> Perhaps you could look at the delivery_rules documentation, especially JLT> the section on the 'minseparate' split, and see if some simple JLT> modification of that would do what you're looking for. Actually I thought about this a bit more. The 'minseparate' split clusters together addresses which go to the same host and sends them in separate SMTP transactions. This ensures that your 500 recipients at AOL don't get stuck behind some downed host at bad-dns.com. It groups together the rarely-appearing hosts and sends them in separate batches. Are you asking that those single-host batches be sent to a host hot running qmail for delivery so the batch stays together? - J< From majordomo-workers-owner Thu Jul 16 11:30:09 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id LAA17138; Thu, 16 Jul 1998 11:18:31 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id LAA17131 for ; Thu, 16 Jul 1998 11:18:22 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id NAA03778; Thu, 16 Jul 1998 13:21:30 -0500 (CDT) To: majordomo-workers@GreatCircle.COM Subject: Re: MTA's (was: VERY large mailing lists.) References: <199807161739.LAA20734@office.esosoft.net> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 16 Jul 1998 13:21:29 -0500 In-Reply-To: Michael Tratz's message of "Thu, 16 Jul 1998 19:39:07 +0200" Message-ID: Lines: 64 X-Mailer: Gnus v5.6.9/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "MT" == Michael Tratz writes: MT> Perhaps an if - else statement would be good. I just don't see how it applies. MT> If we could do the following in the delivery rule: MT> if minseparate = true deliver to host1 else deliver to host2 But there's no control flow; it is not an imperative programming language. It's just a data structure. You wouldn't say 'if so-and-so is true' because the only way it gets to be true or false if because you set it that way. If you just want to specify a list of hosts that the batches of left-over addresses go do, that's not difficult to do. Admittedly there is some confusion because access_rules looks much more like a programming language. I reality the important difference is that access_rules has inputs, while delivery_rules does not. There is nothing in delivery_rules for anything to be conditional upon. MT> This will make sure that we only open one SMTP connection to AOL for MT> example while we deliver the whole message and send it to our 100 AOL MT> subscribers in one batch and we don't need 100 SMTP connections like MT> with qmail. We save bandwidth and so on. This may indicate a bit of confusion (though perhaps not, but I want to make it clear). We (i.e. Majordomo) never open any SMTP connection to AOL. Mj2 is not an MTA. Mj2 talks to MTAs via SMTP (because that happens to be a really easy, portable way to talk to MTAs), but it does _not_ do any delivery. It does no queuing, either. And most importantly, it doesn't do anything with MX records. You still have to run an MTA somewhere which will listen to Mj2, accept batches of RCPTs and do the actual delivery. Now, here are some delivery_rules examples. (Note that none of these makes any use of the fact that you can send different addresses to different places.) This duplicates bulk_mailer: ALL sort, maxdomains=20 This is essentially the TLB configuration that I use for all of my delivery; the host that runs majordomo is not used except in an emergency: ALL sort, minseparate=3, maxdomains=10 hosts=(farabi, gizmo, karazm, spinoza, bifur, fisher, larry, curly, moe, bart, lisa) backups=(sina) A proposal to send the collected 'straggler' addresses (for lack of a better name; feel free to suggest one) to a different set of hosts than the large batches; if 'stragglerhosts' is not set, the behavior just reverts to using 'hosts' for everything. ALL sort, minseparate=3, maxdomans=10 hosts=(a, b, c) stragglerhosts=(d, e, f) backups=(g, h, i) Where in any of this would you put an if/then construct? If you still think it's needed, feel free to give an example of how it would be used. - J< From majordomo-workers-owner Thu Jul 16 14:44:57 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id OAA19872; Thu, 16 Jul 1998 14:29:57 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id OAA19864 for ; Thu, 16 Jul 1998 14:29:50 -0700 (PDT) Received: from Jupiter.Mcs.Net (les@Jupiter.mcs.net [192.160.127.88]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id QAA08640; Thu, 16 Jul 1998 16:33:19 -0500 (CDT) Received: (from les@localhost) by Jupiter.Mcs.Net (8.8.7/8.8.2) id QAA02482; Thu, 16 Jul 1998 16:33:17 -0500 (CDT) From: Leslie Mikesell Message-Id: <199807162133.QAA02482@Jupiter.Mcs.Net> Subject: Re: MTA's (was: VERY large mailing lists.) To: tibbs@hpc.uh.edu (Jason L Tibbitts III) Date: Thu, 16 Jul 1998 16:33:17 -0500 (CDT) Cc: majordomo-workers@GreatCircle.COM In-Reply-To: from "Jason L Tibbitts III" at Jul 16, 98 11:11:30 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk According to Jason L Tibbitts III: > > >>>>> "JLT" == Jason L Tibbitts writes: > > JLT> Perhaps you could look at the delivery_rules documentation, especially > JLT> the section on the 'minseparate' split, and see if some simple > JLT> modification of that would do what you're looking for. > > Actually I thought about this a bit more. The 'minseparate' split clusters > together addresses which go to the same host and sends them in separate > SMTP transactions. This ensures that your 500 recipients at AOL don't get > stuck behind some downed host at bad-dns.com. It groups together the > rarely-appearing hosts and sends them in separate batches. Are you asking > that those single-host batches be sent to a host hot running qmail for > delivery so the batch stays together? Yes, I'd like to minimize the bandwidth for transmission by keeping multiple recipients on a single message to the extent possible. Perhaps more importantly, this gives remote gateways to corporate networks the ability to forward on through their private links in a single operation, and in some cases (cyrus, etc.) to store a single copy for multiple recipients. If you hand off to qmail it is going to split them up and prevent subsequent efficient handling. You do probably want some configurable upper limit on the number of addresses. If you have an option to relay these batches through a different host/port than the ones with only a single address per host you could still take advantage of qmail without causing trouble for others. Les Mikesell les@mcs.com From majordomo-workers-owner Thu Jul 16 16:15:05 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id QAA21241; Thu, 16 Jul 1998 16:04:38 -0700 (PDT) Received: from stingray.ivision.co.uk (stingray.ivision.co.uk [195.50.91.40]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id QAA21234 for ; Thu, 16 Jul 1998 16:04:32 -0700 (PDT) Received: from pretender.ivision.co.uk [195.50.91.43] by stingray.ivision.co.uk with smtp (Exim 1.62 #2) id 0ywx7w-000238-00; Fri, 17 Jul 1998 00:07:52 +0100 Message-Id: <3.0.5.32.19980717000800.00811e10@stingray.ivision.co.uk> X-Sender: manarpop@stingray.ivision.co.uk X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 17 Jul 1998 00:08:00 +0100 To: majordomo-workers@greatcircle.com From: Manar Hussain Subject: Re: Majordomo 2.0 Cc: Chris Rijk , m.chamberlain@ic.ac.uk, yoz@yoz.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Jason wrote: >MH> If you have any items on the web/cgi side you want looked at we're in a >MH> position to help in the immediate future. > >Well, of course there is the rewrite of MajorCool to be done, but I'm going >to let Bill call the shots on that one. I think things are firm enough in >most of the areas it will touch for work on that to begin. Bill: if you have any plans on this and want some input let us know ... >I'm not sure what to do with the little confirmation CGI widget I have; it >works for what it does but there are issues with it. It may just become >part of MajorCool or it could be kept separate. There is the issue of a >consistent look and feel from the web (and an accompanying logo), something >which I am completely unqualified to have anything to do with. Might well be able to provide some jazz'd up look and feel at some point but right now it's difficult (lost our main designer as we get loads of design work in :). >There is also the issue of the archiver. I have written and lightly tested >the machinery to generate the archives and associated indices. >Unfortunately I don't have any article fetching code in place. I recall >that you had an archive presenter written; I'd like to investigate linking >these together. We have a fair bit of developed perl code that takes an mbox or mail and shoves it into a "database" (load of dbm files with extendible multiple indexes of things like subjects, authors, months, day etc.). We then have a set of perl functions to push/pull things out of it. The messages themselves were stored in pseudo mbox format (we did some header and attachment stripping). On top of the message database abstraction layer we have something a "rendering engine" that is geared towards being used dynamically via a web site - it key's of the URL to pull in a layered set of templates on what to return a result. Turns it into a pretty decent web-board sitting on top of majordomo (err - see http://www.democracy.org.uk/virtual/groups/open/month/bydate/jul1998/ for an example) What we really need to do is get a more properly working version of mdom2 going here (so far it's just been a look through the code) and generally get a greater feel for it than you can get from mostly just lurking. One of the things we'd want to look at is what we can lift from our code to help out in majordomo 2 by way of code and/or concepts. A good many months ago when we first looked at this we had an idea towards effectively dropping a lot of our code in as the message archive database for mdom2 but Jason's done a hell of a lot more to get that side of mdom2 sorted so anything useful will be a lot more subtle more I'd guess. >MH> One of the other things I was going to get looked at was back-ending >MH> into MySQL as we'd quite like that (let's us look at better integrating >MH> into mdom 2 our web accessible database of messages we hang off the end >MH> of version 1) > >That would be interesting. I hadn't thought of having multiple archiving >backends but it is a valid idea and I'll see about making it happen. (We >just need to come up with an interface.) In any case I finished the work >to completely abstract the database backends and will start looking into >BerkDB in the near future. Of course, this doesn't have anything to do >with archiving but does have everything to do with subscriber lists. Perhaps a good first concrete thing for us to look at could well be a MySQL (via DBI) option for these backends. I seem to recall - without have looked at it again recently - that your abstracted database backends were written with a view to support a set of options (MySQL / flat file / DBM etc.) ... Regards, Manar From majordomo-workers-owner Fri Jul 17 16:30:02 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id QAA12776; Fri, 17 Jul 1998 16:21:48 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id QAA12766 for majordomo-workers@greatcircle.com; Fri, 17 Jul 1998 16:21:44 -0700 (PDT) Received: from krumm.commline.com (krumm.commline.com [209.218.54.252]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id PAA24445 for ; Wed, 15 Jul 1998 15:22:54 -0700 (PDT) Received: from localhost (dmbong@localhost) by krumm.commline.com (8.8.5/8.8.8) with SMTP id SAA23856; Wed, 15 Jul 1998 18:26:34 -0400 (EDT) (envelope-from dmbong@commline.com) Date: Wed, 15 Jul 1998 18:26:33 -0400 (EDT) From: "Brian L. Heess" To: "Randall S. Winchester" cc: majordomo-workers@GreatCircle.COM Subject: Re: Mail vs a file: aliases when a new list is created. 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 Wed, 15 Jul 1998, Randall S. Winchester wrote: > We could set sendmail to automatically generate the aliases file, or > their could be a command run be mj2; /usr/lib/sendmail -bi -O > AliasFile=$listdir/aliases/$domain Or typically "newaliases"... Cheers! -Brian From majordomo-workers-owner Fri Jul 17 16:33:34 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id QAA12857; Fri, 17 Jul 1998 16:22:33 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id QAA12844 for majordomo-workers@greatcircle.com; Fri, 17 Jul 1998 16:22:30 -0700 (PDT) Received: from csuite.ns.ca (CSuite.ns.ca [129.173.4.210]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id FAA11847 for ; Thu, 16 Jul 1998 05:38:00 -0700 (PDT) Received: from potter@localhost (fake: uid#1005@localhost) by csuite.ns.ca with SMTP id <44975-16777>; Thu, 16 Jul 1998 09:44:39 -0300 Date: Thu, 16 Jul 1998 09:44:26 -0300 (ADT) From: David Potter Reply-To: David Potter To: majordomo-workers@GreatCircle.COM Subject: Filtering (Taboo...) 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've been monitoring workers for months now but I have a short memory and can't recall any discussion about filtering mechanisms in 2... ----- Has the filtering mechanism(s) been significantly changed? Will (dreaming, for example) an individual listowner be able to override/cancel global taboos, admin bounce specificatons? (as an example... my userhelp listowner would prefer that /.*help/i not cause an administrative bounce...) ----- I'm also interested in a filter that would allow anyone from our local system (chebucto.ns.ca) to post to a list but bounce all off-site postings to the list owner. So far I've resorted to a extensive set of list specific taboo headers /from:.*com/i /from:.*net/i etc... ----- Spam has become such a problem for some of my listowners that I could spend all day tweeking filters and could charge for the service... deep in spam.... ;-) david potter Mailing List Administration Chebucto Community Net From majordomo-workers-owner Fri Jul 17 16:37:33 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id QAA12906; Fri, 17 Jul 1998 16:22:47 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id QAA12889 for majordomo-workers@greatcircle.com; Fri, 17 Jul 1998 16:22:41 -0700 (PDT) Received: from office.esosoft.net (office.esosoft.net [192.41.53.152]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id KAA16670 for ; Thu, 16 Jul 1998 10:36:15 -0700 (PDT) Received: (office@localhost) by office.esosoft.net (8.8.5) id LAA20734; Thu, 16 Jul 1998 11:39:32 -0600 (MDT) Message-Id: <199807161739.LAA20734@office.esosoft.net> Organization: Esosoft (http://www.esosoft.com) "The Full Featured IPP" X-Sender: michael@pop.office.esosoft.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Thu, 16 Jul 1998 19:39:07 +0200 To: Jason L Tibbitts III From: Michael Tratz Subject: Re: MTA's (was: VERY large mailing lists.) Cc: majordomo-workers@GreatCircle.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Jason, >JLT> Perhaps you could look at the delivery_rules documentation, especially >JLT> the section on the 'minseparate' split, and see if some simple >JLT> modification of that would do what you're looking for. >Actually I thought about this a bit more. The 'minseparate' split clusters >together addresses which go to the same host and sends them in separate >SMTP transactions. This ensures that your 500 recipients at AOL don't get >stuck behind some downed host at bad-dns.com. It groups together the >rarely-appearing hosts and sends them in separate batches. Are you asking >that those single-host batches be sent to a host hot running qmail for >delivery so the batch stays together? I have also started to think about this while following the discussion about the MTA's on majordomo-users which shows the pros and cons of sendmail & qmail. Perhaps an if - else statement would be good. Let us think we have set minseparate to 5 recipients. If I understand your minseparate correctly we'll create another batch if we deliver 5 or more messages to one host like to AOL or Juno... If we could do the following in the delivery rule: if minseparate = true deliver to host1 else deliver to host2 on host1 we are running sendmail and on host2 we have qmail running (local or remote). This will make sure that we only open one SMTP connection to AOL for example while we deliver the whole message and send it to our 100 AOL subscribers in one batch and we don't need 100 SMTP connections like with qmail. We save bandwidth and so on. Those batches where we deliver just a few equal messages or only one message will be processed by a qmail mail host, because if its just one message, we have to open one SMTP connection anyway and qmail will do it faster instead of sendmail, because sendmail will walk through the batch from top to end. And we'll get a bit rid of those bad-dns.com hosts which slow down sendmail, because its always doing a DNS lookup and if the DNS servers for bad-dns.com are down, sendmail has to wait until it times out... But as far as I know qmail doesn't do those DNS lookups if you send the message to a qmail host it will accept it immediately without looking up the DNS first. I'll see this with bulk_mailer sometimes one batch stays for a few minutes until sendmail times out and accepts the next recipient. What do you think?? Michael From majordomo-workers-owner Fri Jul 17 16:44:58 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-970926-1) id QAA13619; Fri, 17 Jul 1998 16:32:55 -0700 (PDT) Received: from shell7.ba.best.com (shell7.ba.best.com [206.184.139.138]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id QAA13604 for ; Fri, 17 Jul 1998 16:32:47 -0700 (PDT) Received: (from demit@localhost) by shell7.ba.best.com (8.9.0/8.9.0/best.sh) id QAA26743 for majordomo-workers@greatcircle.com; Fri, 17 Jul 1998 16:35:58 -0700 (PDT) From: Jeff Graham Message-Id: <199807172335.QAA26743@shell7.ba.best.com> Subject: Problem with mj2 installs To: majordomo-workers@greatcircle.com Date: Fri, 17 Jul 1998 16:35:58 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk I was installing mj2 to eval it for possible use (yes even the alpha version) and ran into some minor problems I installed apparently ok the first time, but mail to the majordomo@host blew up with an invalid mailer problem. I played around a bit and decided to try reinstalling.. Now at the make install step I get the following: Do basic global configuration now? [no] ->yes Do not be alarmed if the first command fails. /usr/local/majordomo/bin/mj_shell -d anarchy.com -F /tmp/inst.5206 Error executing /usr/local/majordomo/bin/mj_shell, 65280 at postinstall line 280 , chunk 2. I seem to get that error no matter what I do. Any clues? -- Jeffrey Graham | PGP public key by request Senior Systems Administrator (UNIX) | From majordomo-workers-owner Wed Jul 22 07:24:36 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id HAA19496; Wed, 22 Jul 1998 07:14:32 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id HAA19473 for ; Wed, 22 Jul 1998 07:14:21 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id JAA24472; Wed, 22 Jul 1998 09:18:49 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Am I just being left out? Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 22 Jul 1998 09:18:48 -0500 Message-ID: Lines: 18 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk OK, Majordomo-workers (and majordomo-users) has been dead to me for some time now, though majordomo@greatcircle.com is finally answering periodic requests I've been pinging off of it. Now I see that there are messages in the Greatcircle archives that I'm not getting here. This is somewhat annoying, as it's difficult for me to actually do any development when I'm not seeing any of the discussion. Yes, I am still on the list. Let's hope this makes it. If anyone has any questions of me that have gone unanswered, please ask them again and make sure to CC a copy to me personally just in case. I'll try to dig any others out of the archives. Because these list problems are really cutting into progress on the new version, I have to consider running my own development list. Before I do anything like that, though, I need the input of folks on this list. Does anyone here think that would be a bad thing, a slap in the face of the owner of this list or Greatcircle, or otherwise? - J< From majordomo-workers-owner Wed Jul 22 07:38:35 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id HAA19756; Wed, 22 Jul 1998 07:35:20 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id HAA19748 for ; Wed, 22 Jul 1998 07:35:13 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id JAA24738; Wed, 22 Jul 1998 09:39:40 -0500 (CDT) To: majordomo-workers@greatcircle.com Cc: Jeff Graham Subject: Re: Problem with mj2 installs Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 22 Jul 1998 09:39:40 -0500 Message-ID: Lines: 26 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk [I never received the original message; I'm citing this out of the archives. Remember to CC any responses to me.] >I installed apparently ok the first time, but mail to the majordomo@host >blew up with an invalid mailer problem. I'd like to see the messages. Of course, I'd also like to see complete version and platform info, which is essential in any bug report. I'd also like to see pertinent parts of your majordomo configuration, like whether or not you're using the wrappers. >/usr/local/majordomo/bin/mj_shell -d anarchy.com -F /tmp/inst.5206 >Error executing /usr/local/majordomo/bin/mj_shell, 65280 at postinstall >line 280 >, chunk 2. >I seem to get that error no matter what I do. Any clues? What happens when you run mj_shell by itself? Can you get any debug info at all out of it? Try something like 'mj_shell -D lists'. That error isn't one I recognize (besides being 255 * 256). The line number doesn't match what I have in my current sources, so without version information I can't do much more. - J< From majordomo-workers-owner Wed Jul 22 07:53:33 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id HAA19678; Wed, 22 Jul 1998 07:25:16 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id HAA19669 for ; Wed, 22 Jul 1998 07:25:09 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id JAA24624; Wed, 22 Jul 1998 09:29:37 -0500 (CDT) To: majordomo-workers@greatcircle.com Cc: David Potter Subject: Re: Filtering (Taboo...) Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 22 Jul 1998 09:29:36 -0500 Message-ID: Lines: 32 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk [I'm citing this out of the Greatcircle archives, since I never received the original message. I may not receive any responses unless they are CC'd to me.] >Has the filtering mechanism(s) been significantly changed? Yes. >Will (dreaming, for example) an individual listowner be able to >override/cancel global taboos, admin bounce specificatons? Yes. Well, not individually, but I think that the global settings are the wrong way to do; instead, there should be a nice set of defaults for the list-local variables. >I'm also interested in a filter that would allow anyone from our local >system (chebucto.ns.ca) to post to a list but bounce all off-site >postings to the list owner. So far I've resorted to a extensive set of >list specific taboo headers > /from:.*com/i > /from:.*net/i >etc... You can do that, either with an inverted match (new stuff here) of the form !/^from:.*your\.site\.com/i (which must match somewhere or else the message bounces) or an access restriction rule. The latter is probably the more logical thing, since you can restrict other requests (zubscribe, who, etc.) in the same way. - J< From majordomo-workers-owner Wed Jul 22 10:39:00 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id KAA21761; Wed, 22 Jul 1998 10:29:44 -0700 (PDT) Received: from home.samurai.com (samurai.reptiles.org [198.96.117.149]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id KAA21752 for ; Wed, 22 Jul 1998 10:29:31 -0700 (PDT) Received: (from bryanf@localhost) by home.samurai.com (8.9.1/8.9.0) id NAA22881; Wed, 22 Jul 1998 13:33:43 -0400 (EDT) Message-ID: <19980722133343.D23262@samurai.com> Date: Wed, 22 Jul 1998 13:33:43 -0400 From: Bryan Fullerton To: Jason L Tibbitts III , majordomo-workers@GreatCircle.COM Subject: Re: Am I just being left out? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: ; from Jason L Tibbitts III on Wed, Jul 22, 1998 at 09:18:48AM -0500 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On Wed, Jul 22, 1998 at 09:18:48AM -0500, Jason L Tibbitts III wrote: > > Because these list problems are really cutting into progress on the new > version, I have to consider running my own development list. Before I do > anything like that, though, I need the input of folks on this list. Does > anyone here think that would be a bad thing, a slap in the face of the > owner of this list or Greatcircle, or otherwise? If the existing list isn't working, and impeding progress, I don't see why you shouldn't setup another list - though you might want to see if the current list owner wants to continue in that role at a new location (assuming said person isn't the cause of the problem - I don't know who the list owner is or why exactly you're not getting posts, so it's kinda hard to say on that point). Have the Greatcircle people said anything about the problem? Bryan -- http://www.samurai.com http://www.feh.net http://www.icomm.ca "One Code to rule them all, one Code to bind them In the land of Redmond where the Shadows lie." - Joe Thompson in ASR, with apologies to Tolkien From majordomo-workers-owner Wed Jul 22 12:53:39 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id MAA23567; Wed, 22 Jul 1998 12:48:44 -0700 (PDT) Received: from rudra3.ccsf.cc.ca.us (rudra3.ccsf.cc.ca.us [147.144.3.238]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id MAA23560 for ; Wed, 22 Jul 1998 12:48:38 -0700 (PDT) Received: from ns7.ccsf.cc.ca.us by rudra3.ccsf.cc.ca.us via smtpd (for honor.greatcircle.com [198.102.244.44]) with SMTP; 22 Jul 1998 19:53:07 UT Received: from sol.ccsf.cc.ca.us (sol.ccsf.cc.ca.us [147.144.20.31]) by ns7.ccsf.cc.ca.us (8.8.5/8.8.5) with SMTP id MAA00839; Wed, 22 Jul 1998 12:57:53 -0700 (PDT) Received: from localhost by sol.ccsf.cc.ca.us (SMI-8.6/SMI-SVR4) id MAA06953; Wed, 22 Jul 1998 12:53:04 -0700 Date: Wed, 22 Jul 1998 12:53:04 -0700 (PDT) From: "Joe R. Jah" To: Bryan Fullerton cc: Jason L Tibbitts III , majordomo-workers@GreatCircle.COM Subject: Re: Am I just being left out? In-Reply-To: <19980722133343.D23262@samurai.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On Wed, 22 Jul 1998, Bryan Fullerton wrote: > Date: Wed, 22 Jul 1998 13:33:43 -0400 > From: Bryan Fullerton > To: Jason L Tibbitts III , > majordomo-workers@GreatCircle.COM > Subject: Re: Am I just being left out? > > On Wed, Jul 22, 1998 at 09:18:48AM -0500, Jason L Tibbitts III wrote: > > > > Because these list problems are really cutting into progress on the new > > version, I have to consider running my own development list. Before I do > > anything like that, though, I need the input of folks on this list. Does > > anyone here think that would be a bad thing, a slap in the face of the > > owner of this list or Greatcircle, or otherwise? > > If the existing list isn't working, and impeding progress, I don't see > why you shouldn't setup another list - though you might want to see if > the current list owner wants to continue in that role at a new location > (assuming said person isn't the cause of the problem - I don't know who > the list owner is or why exactly you're not getting posts, so it's kinda > hard to say on that point). > > Have the Greatcircle people said anything about the problem? FWIW, I was left out too; this is not the first time either. I think the list members are owed a prompt explanation of what caused the black out, and if it's going to be repeated. Joe _/ _/_/_/ _/ ____________ __o _/ _/ _/ _/ ______________ _-\<,_ _/ _/ _/_/_/ _/ _/ ......(_)/ (_) _/_/ oe _/ _/. _/_/ ah jjah@sol.ccsf.cc.ca.us From majordomo-workers-owner Wed Jul 22 13:13:12 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id MAA23682; Wed, 22 Jul 1998 12:54:38 -0700 (PDT) Received: from atlantis.csc.umd.edu (atlantis.csc.umd.edu [129.2.8.129]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id MAA23675 for ; Wed, 22 Jul 1998 12:54:32 -0700 (PDT) Received: from atlantis.csc.umd.edu ((IDENT rsw)@localhost [127.0.0.1]) by atlantis.csc.umd.edu (8.9.0.Beta6/8.9.0.Beta6) with ESMTP id PAA24630; Wed, 22 Jul 1998 15:58:56 -0400 (EDT) Received: from localhost by atlantis.csc.umd.edu (8.9.0.Beta6/8.9.0.Beta6) with SMTP id PAA24625; Wed, 22 Jul 1998 15:58:54 -0400 (EDT) X-Authentication-Warning: atlantis.csc.umd.edu: rsw owned process doing -bs Date: Wed, 22 Jul 1998 15:58:54 -0400 (EDT) From: "Randall S. Winchester" To: Jason L Tibbitts III cc: majordomo-workers@GreatCircle.COM Subject: Re: Am I just being left out? 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 22 Jul 1998, Jason L Tibbitts III wrote: : OK, Majordomo-workers (and majordomo-users) has been dead to me for some : time now, though majordomo@greatcircle.com is finally answering periodic : requests I've been pinging off of it. Now I see that there are messages in : the Greatcircle archives that I'm not getting here. This is somewhat : annoying, as it's difficult for me to actually do any development when I'm : not seeing any of the discussion. Yes, I am still on the list. : : Let's hope this makes it. If anyone has any questions of me that have gone : unanswered, please ask them again and make sure to CC a copy to me : personally just in case. I'll try to dig any others out of the archives. : : Because these list problems are really cutting into progress on the new : version, I have to consider running my own development list. Before I do : anything like that, though, I need the input of folks on this list. Does : anyone here think that would be a bad thing, a slap in the face of the : owner of this list or Greatcircle, or otherwise? : Well we (umd.edu) have been silent waiting for your return. Mj2 is still your baby, and I do not know if anyone else is involved in the current development. Others my be in a similar mindset ( Means we sure are grateful you have done so damn much work on the new mj.) However, as I mentioned to Jason before his vacation, and grabed him the moment he came back and posted on another list... What we are trying to do may be of interest to the list in general. We are currently working on deploying mj2 for automated course lists. Mj2 will be getting its list creation as well as add/drop requests from a web site interfacing to our campus records database. A faculty member can go to a web site and request mj2 mail lists for any of the courses or course-section's that they teach. This will create a database query who's results will be an email message to mj2 to create, configure, and populate the list. Then for those courses that have had a list created, additional email will be sent to mj2 to do the subscribes/unsubscribes as students add/drop courses. The faculty member, and the TA's will be able to post by default, and the Faculty (or who they share the password with) will be able to make configuration changes to the list in the usual way. We will also archive all the lists. At the end of the semester, the directory which contains the "course" virtual domain will be removed, as well as the "course" aliases file, once the archives have been sent to the professors. Mj2 is pretty cool in its ability to create the list on the fly. We currently have a Sun Ultra 1 dedicated to this service. We expect at least 1000 lists. Jason has suggested turning off the few commands that need to peruse all the lists for performance reasons. The sendmail aliases are generated at list creation time. We had to make one change to the sendmail source for it to autorebuild the aliases when the file was mode 444 (as a funtion of using RCS on the aliases file). The database/web people are strating to test against the mj2 server now, so our "noise" level should increase. A comment about mj2: "This is not your fathers majordomo server." Randall From majordomo-workers-owner Wed Jul 22 13:38:38 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id NAA24281; Wed, 22 Jul 1998 13:37:41 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id NAA24274 for ; Wed, 22 Jul 1998 13:37:30 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id PAA02254; Wed, 22 Jul 1998 15:41:45 -0500 (CDT) To: "Randall S. Winchester" Cc: majordomo-workers@GreatCircle.COM Subject: Re: Am I just being left out? References: Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 22 Jul 1998 15:41:45 -0500 In-Reply-To: "Randall S. Winchester"'s message of "Wed, 22 Jul 1998 15:58:54 -0400 (EDT)" Message-ID: Lines: 60 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "RSW" == Randall S Winchester writes: RSW> Well we (umd.edu) have been silent waiting for your return. Mj2 is RSW> still your baby, and I do not know if anyone else is involved in the RSW> current development. I don't think there is, and this bothers me to some degree. There are many things that I'm not very good at and if it comes down to just me doing all of the work the end product is going to be deficient in those areas. RSW> What we are trying to do may be of interest to the list in general. It should be of very much interest. Frankly, that someone is willing to make use of the software is enough to keep me hacking and I'm perfectly willing to concentrate on the wishes of early adopters. RSW> Mj2 is pretty cool in its ability to create the list on the fly. We RSW> currently have a Sun Ultra 1 dedicated to this service. Woo. That's way more than what I have it running with. Of course, the fact that I run it on such pitiful hardware will go a good ways towards making sure that the performance of the end result is reasonable. RSW> We expect at least 1000 lists. Jason has suggested turning off the few RSW> commands that need to peruse all the lists for performance reasons. Once I can profile things on a large enough installation, I can begin to optimize things a bit. The most time-consuming command, period, is 'lists'. If run in a backwards-compatible manner, it opens all of the list configs (fortunately it doesn't have to parse them, as that's already optimized away) and checks membership for every list. Ouch. But for special purposes, this can be optimized and indeed I can probably get rid of the config file loads. I can also get rid of the need to scan the lists directory on startup if I can trust that a stat of the list directory is enough to tell me if any directories within it have come or gone. RSW> The sendmail aliases are generated at list creation time. I'd like to see your code for this; the mechanism is there to have Mj2 maintain the aliases file itself but currently it only suggests the aliases. RSW> The database/web people are strating to test against the mj2 server RSW> now, so our "noise" level should increase. OK. I'm pretty much ready for it. I assume your operating deadline is the end of August? It looks like it's going to be a fun month. RSW> A comment about mj2: "This is not your fathers majordomo server." That has given me pause many times. It's way different, but if you don't look too hard it can look just like 1.94. But just about everything new that Mj2 does has been called for repeatedly in majordomo-users. It didn't take much coding to figure out that it would just be too painful to bolt all of the extra things I wanted onto 1.9x. BTW, the posts seem to be trickling in from majordomo-workers now; it looks like about five hours of delay which is better than nothing. - J< From majordomo-workers-owner Wed Jul 22 14:23:51 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id OAA25125; Wed, 22 Jul 1998 14:20:34 -0700 (PDT) Received: from atlantis.csc.umd.edu (atlantis.csc.umd.edu [129.2.8.129]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id OAA25114 for ; Wed, 22 Jul 1998 14:20:10 -0700 (PDT) Received: from atlantis.csc.umd.edu ((IDENT rsw)@localhost [127.0.0.1]) by atlantis.csc.umd.edu (8.9.0.Beta6/8.9.0.Beta6) with ESMTP id RAA25112; Wed, 22 Jul 1998 17:24:41 -0400 (EDT) Received: from localhost by atlantis.csc.umd.edu (8.9.0.Beta6/8.9.0.Beta6) with SMTP id RAA25107; Wed, 22 Jul 1998 17:24:39 -0400 (EDT) X-Authentication-Warning: atlantis.csc.umd.edu: rsw owned process doing -bs Date: Wed, 22 Jul 1998 17:24:39 -0400 (EDT) From: "Randall S. Winchester" To: Jason L Tibbitts III cc: majordomo-workers@GreatCircle.COM Subject: Re: Am I just being left out? 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 22 Jul 1998, Jason L Tibbitts III wrote: : >>>>> "RSW" == Randall S Winchester writes: : : RSW> Well we (umd.edu) have been silent waiting for your return. Mj2 is : RSW> still your baby, and I do not know if anyone else is involved in the : RSW> current development. : : I don't think there is, and this bothers me to some degree. There are many : things that I'm not very good at and if it comes down to just me doing all : of the work the end product is going to be deficient in those areas. I know you probably have said this before, but "What areas, besides documentation (I remember that one)?" : RSW> What we are trying to do may be of interest to the list in general. : : It should be of very much interest. Frankly, that someone is willing to : make use of the software is enough to keep me hacking and I'm perfectly : willing to concentrate on the wishes of early adopters. Great, thank you. Hopefully us early people will pave the road for others. : RSW> The sendmail aliases are generated at list creation time. : : I'd like to see your code for this; the mechanism is there to have Mj2 : maintain the aliases file itself but currently it only suggests the : aliases. Joe Sackett , will pass his changes along. The change I made to sendmail (src/alias.c) is here; diff -u -r1.1 alias.c --- alias.c 1998/07/21 20:53:09 1.1 +++ alias.c 1998/07/21 20:53:45 @@ -483,7 +483,7 @@ { struct stat stb; - if ((errno != EACCES && errno != EROFS) || automatic || + if ((errno != EACCES && errno != EROFS) || /*automatic ||*/ (af = safefopen(map->map_file, O_RDONLY, 0, sff)) == NULL) { int saveerr = errno; I need to send it to my sendmail.org friends as well. : : RSW> The database/web people are strating to test against the mj2 server : RSW> now, so our "noise" level should increase. : : OK. I'm pretty much ready for it. I assume your operating deadline is the : end of August? It looks like it's going to be a fun month. Correct, though the database end needs to be operational in 7 days. We may allow some limited testing over the last summer session to better work out the bugs. : : RSW> A comment about mj2: "This is not your fathers majordomo server." : : That has given me pause many times. It's way different, but if you don't : look too hard it can look just like 1.94. But just about everything new : that Mj2 does has been called for repeatedly in majordomo-users. It didn't : take much coding to figure out that it would just be too painful to bolt : all of the extra things I wanted onto 1.9x. Well, I had a 1964 Olds 88 in college when I was poor that I bought for $25.00. My brother ran it while he was in college till the drive shaft fell off on the way down to Blacksburg, and pole vaulted his car, leaving the transmission in hundreds of piece on 81. I much prefer the newer cars, though I have fond memories of driving around with my black "Blues brothers hat". So, hoping this helps to clarify my "comment about mj2", I really like the new mj2, despite the fond memories of the mj-1.60. Randall From majordomo-workers-owner Wed Jul 22 16:25:50 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id QAA27115; Wed, 22 Jul 1998 16:16:54 -0700 (PDT) Received: from pop02.globecomm.net ([207.51.48.186]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id QAA27108 for ; Wed, 22 Jul 1998 16:16:47 -0700 (PDT) Received: from mindless.com (unknown21.horizsys.com [205.231.56.21]) by pop02.globecomm.net (8.9.0/8.8.0) with ESMTP id TAA15886 for ; Wed, 22 Jul 1998 19:21:31 -0400 (EDT) Message-ID: <35B6738D.EDA052B@mindless.com> Date: Wed, 22 Jul 1998 19:19:42 -0400 From: Tom X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: "majordomo-workers@GreatCircle.COM" Subject: Re: Am I just being left out? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk is there a web page listing of all of the majordomo mailing lists or of all mailing lists? Jason L Tibbitts III wrote: > >>>>> "RSW" == Randall S Winchester writes: > > RSW> Well we (umd.edu) have been silent waiting for your return. Mj2 is > RSW> still your baby, and I do not know if anyone else is involved in the > RSW> current development. > > I don't think there is, and this bothers me to some degree. There are many > things that I'm not very good at and if it comes down to just me doing all > of the work the end product is going to be deficient in those areas. > > RSW> What we are trying to do may be of interest to the list in general. > > It should be of very much interest. Frankly, that someone is willing to > make use of the software is enough to keep me hacking and I'm perfectly > willing to concentrate on the wishes of early adopters. > > RSW> Mj2 is pretty cool in its ability to create the list on the fly. We > RSW> currently have a Sun Ultra 1 dedicated to this service. > > Woo. That's way more than what I have it running with. Of course, the > fact that I run it on such pitiful hardware will go a good ways towards > making sure that the performance of the end result is reasonable. > > RSW> We expect at least 1000 lists. Jason has suggested turning off the few > RSW> commands that need to peruse all the lists for performance reasons. > > Once I can profile things on a large enough installation, I can begin to > optimize things a bit. The most time-consuming command, period, is > 'lists'. If run in a backwards-compatible manner, it opens all of the list > configs (fortunately it doesn't have to parse them, as that's already > optimized away) and checks membership for every list. Ouch. But for > special purposes, this can be optimized and indeed I can probably get rid > of the config file loads. I can also get rid of the need to scan the lists > directory on startup if I can trust that a stat of the list directory is > enough to tell me if any directories within it have come or gone. > > RSW> The sendmail aliases are generated at list creation time. > > I'd like to see your code for this; the mechanism is there to have Mj2 > maintain the aliases file itself but currently it only suggests the > aliases. > > RSW> The database/web people are strating to test against the mj2 server > RSW> now, so our "noise" level should increase. > > OK. I'm pretty much ready for it. I assume your operating deadline is the > end of August? It looks like it's going to be a fun month. > > RSW> A comment about mj2: "This is not your fathers majordomo server." > > That has given me pause many times. It's way different, but if you don't > look too hard it can look just like 1.94. But just about everything new > that Mj2 does has been called for repeatedly in majordomo-users. It didn't > take much coding to figure out that it would just be too painful to bolt > all of the extra things I wanted onto 1.9x. > > BTW, the posts seem to be trickling in from majordomo-workers now; it looks > like about five hours of delay which is better than nothing. > > - J< -- http://www.cyberthrill.com/cgi-bin/sponsor/dave169/ricochet.cgi?-026zh http://www.cuy.net/books/ From majordomo-workers-owner Wed Jul 22 16:38:56 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id QAA27278; Wed, 22 Jul 1998 16:26:14 -0700 (PDT) Received: from neviim.torah.org (neviim.torah.org [207.239.101.202]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id QAA27270 for ; Wed, 22 Jul 1998 16:25:58 -0700 (PDT) Received: from localhost (brozen@localhost) by neviim.torah.org (8.8.8/8.8.8) with SMTP id TAA28868; Wed, 22 Jul 1998 19:30:16 -0400 Date: Thu, 23 Jul 1998 02:30:16 +0300 (IDT) From: Brock Rozen Reply-To: Brock Rozen To: Jason L Tibbitts III cc: "Randall S. Winchester" , majordomo-workers@GreatCircle.COM Subject: Re: Am I just being left out? In-Reply-To: Message-ID: X-Backup: Disable X-URL: http://www.torah.org/~brozen MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On 22 Jul 1998, Jason L Tibbitts III wrote: > RSW> We expect at least 1000 lists. Jason has suggested turning off the few > RSW> commands that need to peruse all the lists for performance reasons. > > Once I can profile things on a large enough installation, I can begin to > optimize things a bit. The most time-consuming command, period, is > 'lists'. If run in a backwards-compatible manner, it opens all of the list > configs (fortunately it doesn't have to parse them, as that's already > optimized away) and checks membership for every list. Ouch. But for > special purposes, this can be optimized and indeed I can probably get rid > of the config file loads. I can also get rid of the need to scan the lists > directory on startup if I can trust that a stat of the list directory is > enough to tell me if any directories within it have come or gone. This may be a wacko idea -- but what about an "info" (database?) file for each address itself? It would store all the info about an address, not that there's much. Problem with "aliases" or "equivalent" addresses....how does it look up one and not the other. Of course, that can be solved with an "equivalent addresses" database -- but that's just another thing. -- ---------------------------------- | Brock Rozen | brozen@torah.org | ---------------------------------- From majordomo-workers-owner Wed Jul 22 18:23:34 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id SAA28935; Wed, 22 Jul 1998 18:22:40 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id SAA28928 for ; Wed, 22 Jul 1998 18:22:34 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id UAA06931; Wed, 22 Jul 1998 20:27:02 -0500 (CDT) To: majordomo-workers@greatcircle.com, "Randall S. Winchester" Subject: Re: Am I just being left out? References: Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 22 Jul 1998 20:27:01 -0500 In-Reply-To: "Randall S. Winchester"'s message of "Wed, 22 Jul 1998 17:24:39 -0400 (EDT)" Message-ID: Lines: 51 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "RSW" == Randall S Winchester writes: RSW> I know you probably have said this before, but "What areas, besides RSW> documentation (I remember that one)?" Well, there's the web programming and design and such. This goes beyond the Majorcool stuff. (Which is, BTW, major cool but unfortunately is going to require a nontrivial amount of work.) That and docs are the two major issues, but within the main body of programming there are plenty of things that need doing that I just don't have the time to do. After all, the TODO list is pretty big and there are piles of things that people want done that realistically I'm just not going to get to do anytime soon. At least not if people ever want to actually see this software. RSW> Great, thank you. Hopefully us early people will pave the road for RSW> others. Well, when nobody actually wanted to use it it was easy to bumble about experimenting with various features. Having actual users requires a more focused approach. RSW> Joe Sackett , will pass his changes along. Do you just use an external program to manage the aliases, or did you code something in to Mj::MTAConfig? RSW> Correct, though the database end needs to be operational in 7 days. We RSW> may allow some limited testing over the last summer session to better RSW> work out the bugs. OK. Well, from what I can tell just about everything that you're going to be using actually works (imagine that). Just be aware that for things like archiving you need up-do-date stuff. I'm getting my test rig running again and should cut another snapshot when I can get the time. RSW> So, hoping this helps to clarify my "comment about mj2", I really like RSW> the new mj2, despite the fond memories of the mj-1.60. Well, the simple 'tie it together with aliases' functionality of 1.x was really elegant. Unfortunately it had a huge number of problems like footers and subject prefixes in the archives and digests, the insecure outgoing alias, etc. I'll probably still have standalone programs that work like archive and digest did, just because, but having everything logically integrated makes things much cleaner. I will not shed one tear about the removal of the perl 4 junk (including all of that 'passing arrays in scalars' stuff (join("\001", @arry), ugh)) and piles of global variables and modules polluting multiple package namespaces. No way. - J< From majordomo-workers-owner Wed Jul 22 20:08:58 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id UAA29999; Wed, 22 Jul 1998 20:06:08 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id UAA29992 for ; Wed, 22 Jul 1998 20:06:02 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id WAA08094; Wed, 22 Jul 1998 22:10:36 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: Am I just being left out? References: Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 22 Jul 1998 22:10:36 -0500 In-Reply-To: Brock Rozen's message of "Thu, 23 Jul 1998 02:30:16 +0300 (IDT)" Message-ID: Lines: 25 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "BR" == Brock Rozen writes: BR> This may be a wacko idea -- but what about an "info" (database?) file BR> for each address itself? It would store all the info about an address, BR> not that there's much. Let's see; that's some hundreds of thousands of databases on a busy site. Not the best thing to have, so I assume it's not what you really meant. Now, I have toyed with the idea of having one master database containing info on all addresses. Majordomo has always kept separate lists separate and for that and several technical reasons I decided that I just didn't want to do that. It would make some interesting things possible, though. BR> Problem with "aliases" or "equivalent" addresses....how does it look up BR> one and not the other. That's actually not a problem; you make a function call to turn an address into its canonical form, and another call to do aliasing lookup. BR> Of course, that can be solved with an "equivalent addresses" database BR> -- but that's just another thing. Well, it's another thing that already exists, at least for aliases. - J< From majordomo-workers-owner Wed Jul 22 23:08:54 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id XAA02362; Wed, 22 Jul 1998 23:04:13 -0700 (PDT) Received: from plaidworks.com (plaidworks.com [207.167.80.66]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id XAA02355 for ; Wed, 22 Jul 1998 23:04:07 -0700 (PDT) Received: from (zamboni.plaidworks.com [207.167.80.70]) by plaidworks.com (8.8.8/8.8.8) with ESMTP id XAA28128 ; Wed, 22 Jul 1998 23:10:28 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: chuqui2@plaidworks.com Message-Id: In-Reply-To: References: Brock Rozen's message of "Thu, 23 Jul 1998 02:30:16 +0300 (IDT)" Date: Wed, 22 Jul 1998 22:46:41 -0700 To: Jason L Tibbitts III , majordomo-workers@GreatCircle.COM From: Chuq Von Rospach Subject: Re: Am I just being left out? Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk At 8:10 PM -0700 7/22/98, Jason L Tibbitts III wrote: > Now, I have toyed with the idea of having one master database containing > info on all addresses. Majordomo has always kept separate lists separate > and for that and several technical reasons I decided that I just didn't > want to do that. It would make some interesting things possible, though. Sure would. It's something I'd like to see happen down the road, if only from the situation of easing things for the user. You could disassociate the subscription from the e-mail address, allowing a user to take an account/password, assign a delivery address to it, and then choose subscriptions on a site-wide basis. someone moves, they don't need to remember all the lists and update them all, it's all in one place, one change. It really simplifies it from the point of view of the user. they now have a site account, rather than 1 to N subscriptions, and you can build some really nice administration tools to work with them on it. It has some complications, especially if you're doing virtual domain or want to keep some stuff separate, but trying to build fewer, global (or mostly global) data sets can really add power and flexibility, and reduce confusion and complication for the end user. We've actually been looking at this as a long term requirement for some of the corporate things, where we integrate the server functions into a customer database, so users can do EVERYTHING having to do with the company (lists, product registration, whatever...) from a single site, with a single account/password. that's ultimate integration on an enterprise-caliber level, and definitely a goal, not a project, but adding in hooks to suport it, or building tools that bring that kind of integration into tools like majordomo, are definitely first steps. -- Chuq Von Rospach (Hockey fan? ) Apple Mail List Gnome (mailto:chuq@apple.com) Plaidworks Consulting (mailto:chuqui@plaidworks.com) + From majordomo-workers-owner Thu Jul 23 00:24:09 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id AAA03115; Thu, 23 Jul 1998 00:23:02 -0700 (PDT) Received: from neviim.torah.org (neviim.torah.org [207.239.101.202]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id AAA03108 for ; Thu, 23 Jul 1998 00:22:55 -0700 (PDT) Received: from localhost (brozen@localhost) by neviim.torah.org (8.8.8/8.8.8) with SMTP id DAA09211; Thu, 23 Jul 1998 03:27:29 -0400 Date: Thu, 23 Jul 1998 10:27:29 +0300 (IDT) From: Brock Rozen Reply-To: Brock Rozen To: Jason L Tibbitts III cc: majordomo-workers@GreatCircle.COM Subject: Addresses - Was: Re: Am I just being left out? In-Reply-To: Message-ID: X-Backup: Disable X-URL: http://www.torah.org/~brozen MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On 22 Jul 1998, Jason L Tibbitts III wrote: > >>>>> "BR" == Brock Rozen writes: > > BR> This may be a wacko idea -- but what about an "info" (database?) file > BR> for each address itself? It would store all the info about an address, > BR> not that there's much. > > Let's see; that's some hundreds of thousands of databases on a busy site. > Not the best thing to have, so I assume it's not what you really meant. > Now, I have toyed with the idea of having one master database containing > info on all addresses. Majordomo has always kept separate lists separate > and for that and several technical reasons I decided that I just didn't > want to do that. It would make some interesting things possible, though. Yes, that's why I threw out my first idea myself -- because of the number of databases. The "equivalent addresses" idea was actually meant for the line of one master database. With that in place, would it mean that any call to any list, or even to the 'lists' command would hit the master database? 'who' (but not 'which') commands probably wouldn't touch it. What are the benefits though? For Randall, it's probably great because it means less time on the lists command, or even the which equivalent. What else? It probably means more overhead for the rest of the commands, as they have to modify the master database, as well as their own database. -- ---------------------------------- | Brock Rozen | brozen@torah.org | ---------------------------------- From majordomo-workers-owner Thu Jul 23 02:25:11 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id CAA05143; Thu, 23 Jul 1998 02:09:22 -0700 (PDT) Received: from stingray.ivision.co.uk (stingray.ivision.co.uk [195.50.91.40]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id CAA05136 for ; Thu, 23 Jul 1998 02:09:15 -0700 (PDT) Received: from pretender.ivision.co.uk [195.50.91.43] by stingray.ivision.co.uk with smtp (Exim 1.62 #2) id 0yzHRi-0002qM-00; Thu, 23 Jul 1998 10:13:54 +0100 Message-Id: <3.0.5.32.19980723101355.00921600@stingray.ivision.co.uk> X-Sender: manarpop@stingray.ivision.co.uk X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 23 Jul 1998 10:13:55 +0100 To: majordomo-workers@GreatCircle.COM From: Manar Hussain Subject: Re: Am I just being left out? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >Sure would. It's something I'd like to see happen down the road, if >only from the situation of easing things for the user. You could >disassociate the zubscription from the e-mail address, allowing a user >to take an account/password, assign a delivery address to it, and then >choose zubscriptions on a site-wide basis. someone moves, they don't >need to remember all the lists and update them all, it's all in one >place, one change. It really simplifies it from the point of view of >the user. they now have a site account, rather than 1 to N >zubscriptions, and you can build some really nice administration tools >to work with them on it. We're very keen on this approach - it's one of the main things I'd want to sanitise between how our web stuff and majordomo works. Having all the majordomo stuff in an SQL database will help us do this as we can more easily layer things on top of whatever mj2 does but having the concept more naturally part of mj2's way is better. Basically you have a distinct user registration system within mj2 - each user then get's a uid and it is *this* that get's (internally) "zubscribed" to the mailing list (along with params indicating things like which of the user's email address should have mail sent to it, does this user have posting rights or is read only etc. - to be discussed). The problem is that this is a more radical departure from the original mj1.x way. >It has some complications, especially if you're doing virtual domain or You need to be very clear about shared / non-shared name spaces for the usernames. We normally call these "clusters" (i.e. you cluster user details where each cluster has it's own uid namespace). People's uid+clusterid is thus unique and you either make sure that the clusterid is made available when people are doing things that needs access control or you infer it somehow. The obvious way to be able to infer it is to say that when you create a new virtual domain you assign it to a single given "cluster". As an aside - we'd also like to ensure that clusterid's are Internet wide unique and then at some point accommodate cross cluster interaction across the whole net (hooking into http://www.w3.org/P3P/) ... >want to keep some stuff separate, but trying to build fewer, global (or >mostly global) data sets can really add power and flexibility, and >reduce confusion and complication for the end user. One of the main dangers is that this can make things harder (initially) on the end user. I think it's vital that a new user can come in and mail a "zubscribe list1" message to majordomo@domain.com and it just works. We don't want them to have to go through any more hoops. The way I'd reconcile this with the desire for a global user registration system is to auto set up new accounts for these people and provide the means for accounts to be merged if the user considers it useful enough. I could discuss this a bit further but I don't really have time at the moment and I'm probably incoherent/off track anyways :) >We've actually been >looking at this as a long term requirement for some of the corporate >things, where we integrate the server functions into a customer >database, so users can do EVERYTHING having to do with the company >(lists, product registration, whatever...) from a single site, with a >single account/password. that's ultimate integration on an >enterprise-caliber level, and definitely a goal, not a project, but >adding in hooks to suport it, or building tools that bring that kind of >integration into tools like majordomo, are definitely first steps. We've got much the same aim/approach that we've been slowly progressing down for a couple of years now (at a guess, we don't have as much justification to spend the time on it as you - it's more a case if it being something we're interested in). From majordomo-workers-owner Thu Jul 23 07:39:44 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id HAA10167; Thu, 23 Jul 1998 07:29:01 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id HAA10160 for ; Thu, 23 Jul 1998 07:28:53 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id JAA16942; Thu, 23 Jul 1998 09:33:29 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Global address database and _serious_ call for a volunteer References: Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 23 Jul 1998 09:33:29 -0500 In-Reply-To: Chuq Von Rospach's message of "Wed, 22 Jul 1998 22:46:41 -0700" Message-ID: Lines: 85 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "CVR" == Chuq Von Rospach writes: CVR> Sure would. It's something I'd like to see happen down the road, if CVR> only from the situation of easing things for the user. You could CVR> disassociate the subscription from the e-mail address, allowing a user CVR> to take an account/password, assign a delivery address to it, and then CVR> choose subscriptions on a site-wide basis. Nothing prevents this from happening now; it's actually not difficult to do but the last time I solicited ideas on it none were forthcoming so it didn't get implemented. It's been on the todo list for some time now. CVR> It has some complications, especially if you're doing virtual domain CVR> or want to keep some stuff separate, but trying to build fewer, global CVR> (or mostly global) data sets can really add power and flexibility, and CVR> reduce confusion and complication for the end user. Virtual domains are not a problem. Remember that virtual domains have absolutely no knowledge of each other, so there is no data sharing. Now, you still have to have per-list databases because there are many per-list things you want to keep track of and for efficiency issues. (And there are optimizations that may call for more databases.) CVR> We've actually been looking at this as a long term requirement for CVR> some of the corporate things, [...] This is why more people need to become involved. If this is ever going to happen, it needs to happen sooner rather than later. There are users now, and we just can't go changing the entire database structure without supplying a migration tool that takes ages to write. So I'm going to lay this out now and hope the list is running well enough to let this discussion happen. First off, I have a pretty busy life right now and its taking me more time than I would have liked to get ramped back up and get my head back in the code. What I _really_ need is someone to volunteer to write the digest engine and perhaps do some work on the archiver. A rough design is already done and I figure it shouldn't take more than a week of evening hacking. Is anyone up to it? Now, some discussion about a "global" (to a majordomo virtual domain, not the planet) address list. Here's what we store per (list,subscriber): full address (with comments and everything) stripped address (the address that goes in the RCPT) zubscribe time record last change time (automatically maintained by database) zubscription class 2 class arguments (vacation date, digest type, etc.) zubscriber flags (receive acks? do cc elimination?) bounce data (a string reserved for the bounce processor data) preferred language warnings (reserved for messages stored for next communication with user) password How should that be split up? I see: GLOBAL: full addr strip addr password (probably encrypted somehow) bounce data (?) language warnings a list of lists the user is a member of PER LIST: full addr (for doing 'who' quickly) strip addr zub. class + args flags (need to be per list) Really, this is not difficult to split up but I want to split it once and leave it that way. I can see places where you might want a global default and a per-list override but I'd really, really like to try to get away without doing that. Now, the global list doesn't even have to be Majordomo-maintained; it could be on an LDAP server somewhere assuming that the fields it needs can be created. The per-list stuff should be probably be internal, though. Ideas? - J< From majordomo-workers-owner Thu Jul 23 10:40:59 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id KAA12903; Thu, 23 Jul 1998 10:31:06 -0700 (PDT) Received: from stingray.ivision.co.uk (stingray.ivision.co.uk [195.50.91.40]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id KAA12887 for ; Thu, 23 Jul 1998 10:30:28 -0700 (PDT) Received: from stingray.ivision.co.uk [195.50.91.40] by stingray.ivision.co.uk with smtp (Exim 1.62 #2) id 0yzPGm-0007d6-00; Thu, 23 Jul 1998 18:35:08 +0100 Date: Thu, 23 Jul 1998 18:35:07 +0100 (BST) From: Chris Rijk To: majordomo-workers@GreatCircle.COM Subject: Installation problems Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Everything works fine until the last bit of 'make install': /bin/perl -w postinstall Setting permissions...ok Majordomo stores its lists in a hiearachy of directories. These can be created for you now. The various list files will be created as needed. Create directories? [no] ->yes /home/stingray/chris/mail/mailing_lists, /tmp/mj, 100, 100 Making directories for ivision.co.uk, mode 770. Making directories for lists.wot-club.org.uk, mode 770. The installation can do some basic global configuration using the questions answered before installation began. If you do not do this, the rest of the installation may not proceed correctly, since the global password needs to be set in order for this program to make configuration changes. Do basic global configuration now? [no] ->yes Do not be alarmed if the first command fails. /home/stingray/chris/usr/bin/mj_shell -d ivision.co.uk -F /tmp/inst.29025 Error executing /home/stingray/chris/usr/bin/mj_shell, 1280 at postinstall line 301, chunk 2. more /tmp/inst.29025 gives: approve GLOBAL.pass configset GLOBAL master_password = ******** default password ******** configset GLOBAL tmpdir = /tmp/mj configset GLOBAL site_name = Internet Vision MLs configset GLOBAL install_dir = /home/stingray/chris/usr configset GLOBAL lists_dir = /home/stingray/chris/mail/mailing_lists configset GLOBAL mta = sendmail configset GLOBAL whereami = ivision.co.uk If I just say 'no' I get: /bin/perl -w postinstall Setting permissions...ok Majordomo stores its lists in a hiearachy of directories. These can be created for you now. The various list files will be created as needed. Create directories? [no] -> The installation can do some basic global configuration using the questions answered before installation began. If you do not do this, the rest of the installation may not proceed correctly, since the global password needs to be set in order for this program to make configuration changes. Do basic global configuration now? [no] -> Majorodmo stores response files (the confirmation message, the various help texts, etc.) separately instead of placing them into the program code. These files must be installed into the Majordomo system. Answer 'no' to skip this step; any existing files will be preserved. Install response files? [no] -> We will now generate some basic configuration information: (/home/stingray/chris/usr/bin/mj_shell -d ivision.co.uk -p ******** createlist=nocreate,quiet GLOBAL) Error executing /home/stingray/chris/usr/bin/mj_shell, 1792 at postinstall line 378, chunk 3. --- the ******** is of course the password... Anyone got any ideas? It's hard to guess, but it doesn't seem likely the above problem could just be ignored. -- +-- Chris Rijk --------------------------------------- chris@ivision.co.uk --+ | Dictionary of Alternative Meanings: marriage | | Like a cage; one sees the birds outside desperate to get in, and those | | inside equally desperate to get out. | From majordomo-workers-owner Thu Jul 23 14:38:55 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id OAA15759; Thu, 23 Jul 1998 14:24:33 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id OAA15752 for ; Thu, 23 Jul 1998 14:23:59 -0700 (PDT) Received: from Jupiter.Mcs.Net (les@Jupiter.mcs.net [192.160.127.88]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id QAA27718; Thu, 23 Jul 1998 16:27:20 -0500 (CDT) Received: (from les@localhost) by Jupiter.Mcs.Net (8.8.7/8.8.2) id QAA15749; Thu, 23 Jul 1998 16:27:19 -0500 (CDT) From: Leslie Mikesell Message-Id: <199807232127.QAA15749@Jupiter.Mcs.Net> Subject: Re: Global address database and _serious_ call for a volunteer To: tibbs@hpc.uh.edu (Jason L Tibbitts III) Date: Thu, 23 Jul 1998 16:27:19 -0500 (CDT) Cc: majordomo-workers@GreatCircle.COM In-Reply-To: from "Jason L Tibbitts III" at Jul 23, 98 09:33:29 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk According to Jason L Tibbitts III: > > GLOBAL: > full addr > strip addr > password (probably encrypted somehow) > bounce data (?) > language > warnings > a list of lists the user is a member of > > PER LIST: > full addr (for doing 'who' quickly) > strip addr > zub. class + args > flags (need to be per list) > > Really, this is not difficult to split up but I want to split it once and > leave it that way. I can see places where you might want a global default > and a per-list override but I'd really, really like to try to get away > without doing that. Why not design it so even the global values have a key that could be different per-list or not? Then if you end up being wrong you just use a different identifier for the lists that turn out to be different. > Now, the global list doesn't even have to be Majordomo-maintained; it could > be on an LDAP server somewhere assuming that the fields it needs can be > created. The per-list stuff should be probably be internal, though. > > Ideas? LDAP might be the best long-term choice, especially if you teach it to automatically make the list addresses available and let sendmail use it directly for the expansions, but I expect it to be several years before many sites are prepared for that. Right now you could use DBI with the base distribution set up for DBD::CSV which uses a flat file storage instead of needing a backend database. Places that outgrow that scheme or want access from multiple machines could drop in their choice of server and DBD backends without changing the base code. Les Mikesell les@mcs.com From majordomo-workers-owner Thu Jul 23 16:08:48 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id PAA17018; Thu, 23 Jul 1998 15:55:08 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id PAA17007 for ; Thu, 23 Jul 1998 15:54:56 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id RAA27901; Thu, 23 Jul 1998 17:59:36 -0500 (CDT) To: majordomo-workers@greatcircle.com, Chris Rijk Subject: Re: Installation problems References: Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 23 Jul 1998 17:59:35 -0500 In-Reply-To: Chris Rijk's message of "Thu, 23 Jul 1998 18:35:07 +0100 (BST)" Message-ID: Lines: 13 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "CR" == Chris Rijk writes: CR> /home/stingray/chris/usr/bin/mj_shell -d ivision.co.uk -F CR> /tmp/inst.29025 Error executing /home/stingray/chris/usr/bin/mj_shell, CR> 1280 at postinstall line 301, chunk 2. Before I can say much of anything, I'm going to have to know all pertinent info about your platform, your perl version and what version of Mj2 you're trying to install. What happens when you run mj_shell by hand? - J< From majordomo-workers-owner Thu Jul 23 16:39:21 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id QAA17708; Thu, 23 Jul 1998 16:34:50 -0700 (PDT) Received: from stingray.ivision.co.uk (stingray.ivision.co.uk [195.50.91.40]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id QAA17701 for ; Thu, 23 Jul 1998 16:34:41 -0700 (PDT) Received: from stingray.ivision.co.uk [195.50.91.40] by stingray.ivision.co.uk with smtp (Exim 1.62 #2) id 0yzUxJ-0001ll-00; Fri, 24 Jul 1998 00:39:25 +0100 Date: Fri, 24 Jul 1998 00:39:25 +0100 (BST) From: Chris Rijk To: Jason L Tibbitts III cc: majordomo-workers@greatcircle.com Subject: Re: Installation problems 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 23 Jul 1998, Jason L Tibbitts III wrote: >>>>>> "CR" == Chris Rijk writes: > >CR> /home/stingray/chris/usr/bin/mj_shell -d ivision.co.uk -F >CR> /tmp/inst.29025 Error executing /home/stingray/chris/usr/bin/mj_shell, >CR> 1280 at postinstall line 301, chunk 2. > >Before I can say much of anything, I'm going to have to know all pertinent >info about your platform, your perl version and what version of Mj2 you're >trying to install. duh... perl 5.004_4, Solaris (Sparc) 2.5.1, I CVS checked it out yesterday, majordomo.pm says $VERSION = "0.1199805230" >What happens when you run mj_shell by hand? No output. I tried what the install thing was doing, I've tried giving it random command line stuff, I tried a couple of other things I saw in the archive/man page. Still no output - though I didn't check the return codes. -- +-- Chris Rijk --------------------------------------- chris@ivision.co.uk --+ | Dictionary of Alternative Meanings: friendship | | Like money, easier made than kept. | From majordomo-workers-owner Thu Jul 23 17:24:24 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id RAA18362; Thu, 23 Jul 1998 17:15:12 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id RAA18349 for ; Thu, 23 Jul 1998 17:14:57 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id TAA29104; Thu, 23 Jul 1998 19:19:31 -0500 (CDT) To: Chris Rijk Cc: majordomo-workers@greatcircle.com Subject: Re: Installation problems References: Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 23 Jul 1998 19:19:30 -0500 In-Reply-To: Chris Rijk's message of "Fri, 24 Jul 1998 00:39:25 +0100 (BST)" Message-ID: Lines: 23 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "CR" == Chris Rijk writes: CR> duh... perl 5.004_4, Solaris (Sparc) 2.5.1, I CVS checked it out CR> yesterday, majordomo.pm says $VERSION = "0.1199805230" Nothing wrong there. CR> No output. That's very odd. Are you running it with or without wrappers? What does the final installed bin directory look like? Please try to truss is (though you may have to be root) because of the setuid nature. And do check that return code. The only other thing I can recommend is to try some debugging with -D, but it really sounds like no perl is getting executed at all. That could conceivably happen if the wrappers are being used and they bomb somehow, since they don't check any errors or anything. One other question: you aren't trying to install into the build directory, are you? - J< From majordomo-workers-owner Thu Jul 23 17:38:55 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id RAA18551; Thu, 23 Jul 1998 17:26:09 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id RAA18544 for ; Thu, 23 Jul 1998 17:25:58 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id TAA29288; Thu, 23 Jul 1998 19:30:28 -0500 (CDT) To: Leslie Mikesell Cc: majordomo-workers@GreatCircle.COM Subject: Re: Global address database and _serious_ call for a volunteer References: <199807232127.QAA15749@Jupiter.Mcs.Net> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 23 Jul 1998 19:30:28 -0500 In-Reply-To: Leslie Mikesell's message of "Thu, 23 Jul 1998 16:27:19 -0500 (CDT)" Message-ID: Lines: 35 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "LM" == Leslie Mikesell writes: LM> Why not design it so even the global values have a key that could be LM> different per-list or not? Then if you end up being wrong you just use LM> a different identifier for the lists that turn out to be different. No reason for that; I can push something down to the list level with code changes and, frankly, putting per-list things in a global database would be more of a performance hit than I'm willing to consider. The point is that I don't want to get it wrong from the beginning, I want to get it right. LM> LDAP might be the best long-term choice, I'm not certain of that, and I'll certainly never depend on LDAP for anything in Majordomo. LM> especially if you teach it to automatically make the list addresses LM> available and let sendmail use it directly for the expansions, You're still thinking Majordomo1 here; remember that the address list changes dynamically for every message. 'noselfcopy', 'eliminatecc' and the various subscriber classes require that from the start. Plus, I eventually want to experiment with server-side filters (though you shouldn't expect to see that for a while). And I didn't spend so much effort writing an SMTP exploder just to go back to relying on local MTA dependencies to feed in the address list. LM> Right now you could use DBI with the base distribution set up for LM> DBD::CSV which uses a flat file storage instead of needing a backend LM> database. Majordomo2 has its own database abstraction layer (much, much simpler than DBD) and already includes a flat text database module. - J< From majordomo-workers-owner Thu Jul 23 18:54:24 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id SAA20372; Thu, 23 Jul 1998 18:47:39 -0700 (PDT) Received: from ncr-sd.SanDiegoCA.NCR.COM (tan7.NCR.COM [192.127.94.7]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id SAA20363 for ; Thu, 23 Jul 1998 18:47:24 -0700 (PDT) Received: from jabberwocky (jabberwocky.SanDiegoCA.NCR.COM [153.64.69.123]) by ncr-sd.SanDiegoCA.NCR.COM (8.8.5/8.7.3) with SMTP id SAA20978 for ; Thu, 23 Jul 1998 18:51:51 -0700 (PDT) Message-Id: <199807240151.SAA20978@ncr-sd.SanDiegoCA.NCR.COM> X-Sender: bhoule@sparc.sandiegoca.ncr.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Thu, 23 Jul 1998 18:41:08 -0700 To: majordomo-workers@GreatCircle.COM From: Bill Houle Subject: Re: Am I just being left out? In-Reply-To: References: <"Randall S. Winchester"'s message of "Wed, 22 Jul 1998 17:24:39 -0400 (EDT)"> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk At 08:27 PM 7/22/98 -0500, Jason L Tibbitts III wrote: > >Well, there's the web programming and design and such. This goes beyond >the Majorcool stuff. (Which is, BTW, major cool but unfortunately is going >to require a nontrivial amount of work.) The UI and general flow can be duplicated, but I have resigned myself to the fact that the bulk of the coding will be a total rewrite (just as mj2 already is). --bill From majordomo-workers-owner Thu Jul 23 20:08:48 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id UAA21640; Thu, 23 Jul 1998 20:06:29 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id UAA21633 for ; Thu, 23 Jul 1998 20:06:20 -0700 (PDT) Received: from Mars.mcs.net (les@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id WAA12083; Thu, 23 Jul 1998 22:11:04 -0500 (CDT) Received: (from les@localhost) by Mars.mcs.net (8.8.7/8.8.2) id WAA00749; Thu, 23 Jul 1998 22:11:04 -0500 (CDT) From: Leslie Mikesell Message-Id: <199807240311.WAA00749@Mars.mcs.net> Subject: Re: Global address database and _serious_ call for a volunteer To: tibbs@hpc.uh.edu (Jason L Tibbitts III) Date: Thu, 23 Jul 1998 22:11:03 -0500 (CDT) Cc: les@Mcs.Net, majordomo-workers@GreatCircle.COM In-Reply-To: from "Jason L Tibbitts III" at Jul 23, 98 07:30:28 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk According to Jason L Tibbitts III: > > >>>>> "LM" == Leslie Mikesell writes: > > LM> Why not design it so even the global values have a key that could be > LM> different per-list or not? Then if you end up being wrong you just use > LM> a different identifier for the lists that turn out to be different. > > No reason for that; I can push something down to the list level with code > changes and, frankly, putting per-list things in a global database would be > more of a performance hit than I'm willing to consider. The point is that > I don't want to get it wrong from the beginning, I want to get it right. I guess it depends on how 'global' you make global. I thought you might want different groups of global settings, say per list-owner instead of per domain. > LM> Right now you could use DBI with the base distribution set up for > LM> DBD::CSV which uses a flat file storage instead of needing a backend > LM> database. > > Majordomo2 has its own database abstraction layer (much, much simpler than > DBD) and already includes a flat text database module. The point of DBI is that there are already DBD's for most of the popular databases so using whatever you have would be a config file change. With your custom version everyone will have to write their own glue code to use their preferred backend. Les Mikesell les@mcs.com From majordomo-workers-owner Thu Jul 23 20:54:01 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id UAA22078; Thu, 23 Jul 1998 20:40:23 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id UAA22068 for ; Thu, 23 Jul 1998 20:40:08 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id WAA02064; Thu, 23 Jul 1998 22:44:43 -0500 (CDT) To: Leslie Mikesell Cc: majordomo-workers@GreatCircle.COM Subject: Re: Global address database and _serious_ call for a volunteer References: <199807240311.WAA00749@Mars.mcs.net> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 23 Jul 1998 22:44:43 -0500 In-Reply-To: Leslie Mikesell's message of "Thu, 23 Jul 1998 22:11:03 -0500 (CDT)" Message-ID: Lines: 47 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "LM" == Leslie Mikesell writes: LM> I guess it depends on how 'global' you make global. I thought you LM> might want different groups of global settings, say per list-owner LM> instead of per domain. I just don't see much point in making it anything other than per-domain. Why would a list member care who the list owner is when setting up their language preference? Perhaps I'm missing something. LM> The point of DBI is that there are already DBD's for most of the LM> popular databases so using whatever you have would be a config file LM> change. But there are many things against it. 1) DBI::CSV did not exist when I started. 2) It's SLOOW. 3) It's big. 4) It prohibits doing many of the optimizations that you can do when you know just what kind of data you're storing. 5) It is not as transparent as you may think. If MYSql is the backend, I have to send SQL. If BerkDB is the backend (if such even exists) I can't send SQL unless an SQL interpreter is somehow in the perl module. I don't want an SQL interpreter in the perl module; I don't need more than a few simple access functions. LM> With your custom version everyone will have to write their own glue LM> code to use their preferred backend. Yes. Well, you could write the glue code to DBI, if indeed something like that can really be done. It's not like there is a whole bunch of glue code needed. I just don't think DBI is really uniform enough. I'm planning to use DBI::MySQL for the MySQL backend, but every time I've looked at it there hasn't been a way to even use the same code for another big SQL engine, much less for a simple keyed database like BerkDB. Perhaps you could enlighten me as to how that's done? I don't want to dismiss this out of hand, but the database plan has existed in exactly its current form for 16 months now. If you're willing to get your hands dirty and help to make it work the way you think it should work then I'm all for pointing you in the right direction as long as those five points above are easily worked around. But this is the first time anyone has offered a conflicting point of view, and it's a little late in the game to go rewriting all of the internals just because. - J< From majordomo-workers-owner Thu Jul 23 22:10:02 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id WAA23279; Thu, 23 Jul 1998 22:06:40 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id WAA23272 for ; Thu, 23 Jul 1998 22:06:26 -0700 (PDT) Received: from Mars.mcs.net (les@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id AAA18017; Fri, 24 Jul 1998 00:11:10 -0500 (CDT) Received: (from les@localhost) by Mars.mcs.net (8.8.7/8.8.2) id AAA02225; Fri, 24 Jul 1998 00:11:10 -0500 (CDT) From: Leslie Mikesell Message-Id: <199807240511.AAA02225@Mars.mcs.net> Subject: Re: Global address database and _serious_ call for a volunteer To: tibbs@hpc.uh.edu (Jason L Tibbitts III) Date: Fri, 24 Jul 1998 00:11:10 -0500 (CDT) Cc: les@Mcs.Net, majordomo-workers@GreatCircle.COM In-Reply-To: from "Jason L Tibbitts III" at Jul 23, 98 10:44:43 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk According to Jason L Tibbitts III: > > I just don't see much point in making it anything other than per-domain. > Why would a list member care who the list owner is when setting up their > language preference? Perhaps I'm missing something. Probably overkill - just a way to deal with a global turning out to be less global than you planned. > 1) DBI::CSV did not exist when I started. > 5) It is not as transparent as you may think. If MYSql is the backend, I > have to send SQL. If BerkDB is the backend (if such even exists) I > can't send SQL unless an SQL interpreter is somehow in the perl module. > I don't want an SQL interpreter in the perl module; I don't need more > than a few simple access functions. DBI expects you to send SQL. DBD::CSV uses SQL::Statement to parse SQL and operate on the underlying file. I don't think there is anything similar for dbm files. > > LM> With your custom version everyone will have to write their own glue > LM> code to use their preferred backend. > > Yes. Well, you could write the glue code to DBI, if indeed something like > that can really be done. It's not like there is a whole bunch of glue > code needed. I just don't think DBI is really uniform enough. I'm > planning to use DBI::MySQL for the MySQL backend, but every time I've > looked at it there hasn't been a way to even use the same code for another > big SQL engine, much less for a simple keyed database like BerkDB. Perhaps > you could enlighten me as to how that's done? In theory you should be able to interchange any DBD's as long as the backends understand the sql you are sending and most of them should accept INSERT, SELECT, UPDATE and DELETE which is probably all you need. However, I would expect the performance of DBD::CSV to be pretty bad so it might be best to keep your code if you don't have a backend, and replace it with DBI if you do. If your interface maps more or less to the sql statments it shouldn't be too hard. > I don't want to dismiss this out of hand, but the database plan has existed > in exactly its current form for 16 months now. If you're willing to get > your hands dirty and help to make it work the way you think it should work > then I'm all for pointing you in the right direction as long as those five > points above are easily worked around. But this is the first time anyone > has offered a conflicting point of view, and it's a little late in the game > to go rewriting all of the internals just because. With RedHat shipping Postgresql in the stock distribution there will be a lot of people with a backend that can deliver the sorted list faster than you can do it in perl, plus there will likely be some people running on big iron with Oracle/Sybase, etc. available. There are also a lot of other interfaces to these databases that could be used to manage the lists. Les Mikesell les@mcs.com From majordomo-workers-owner Fri Jul 24 01:23:50 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id BAA25684; Fri, 24 Jul 1998 01:00:53 -0700 (PDT) Received: from neviim.torah.org (neviim.torah.org [207.239.101.202]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id BAA25642 for ; Fri, 24 Jul 1998 01:00:22 -0700 (PDT) Received: from localhost (brozen@localhost) by neviim.torah.org (8.8.8/8.8.8) with SMTP id EAA08216; Fri, 24 Jul 1998 04:05:03 -0400 Date: Fri, 24 Jul 1998 11:05:03 +0300 (IDT) From: Brock Rozen Reply-To: Brock Rozen To: Jason L Tibbitts III cc: majordomo-workers@GreatCircle.COM Subject: Re: Global address database and _serious_ call for a volunteer In-Reply-To: Message-ID: X-Backup: Disable X-URL: http://www.torah.org/~brozen MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On 23 Jul 1998, Jason L Tibbitts III wrote: > Now, some discussion about a "global" (to a majordomo virtual domain, not > the planet) address list. Here's what we store per (list,subscriber): > > full address (with comments and everything) > stripped address (the address that goes in the RCPT) > zubscribe time > record last change time (automatically maintained by database) > zubscription class > 2 class arguments (vacation date, digest type, etc.) > zubscriber flags (receive acks? do cc elimination?) > bounce data (a string reserved for the bounce processor data) > preferred language > warnings (reserved for messages stored for next communication with user) > password Any possibility of getting 'record created date/time' ? It's created once and then never changed. -- ---------------------------------- | Brock Rozen | brozen@torah.org | ---------------------------------- From majordomo-workers-owner Fri Jul 24 07:12:46 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id GAA03033; Fri, 24 Jul 1998 06:49:04 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id GAA03026 for ; Fri, 24 Jul 1998 06:48:49 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id IAA10845; Fri, 24 Jul 1998 08:53:31 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: Global address database and _serious_ call for a volunteer References: Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 24 Jul 1998 08:53:31 -0500 In-Reply-To: Brock Rozen's message of "Fri, 24 Jul 1998 11:05:03 +0300 (IDT)" Message-ID: Lines: 9 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "BR" == Brock Rozen writes: BR> Any possibility of getting 'record created date/time' ? It's created BR> once and then never changed. That's what 'zubscribe time' is intended to be. I can make a global field that keeps the time the record was first added. - J< From majordomo-workers-owner Sat Jul 25 10:09:03 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id KAA21626; Sat, 25 Jul 1998 10:07:30 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id KAA21619 for ; Sat, 25 Jul 1998 10:07:22 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id MAA05843; Sat, 25 Jul 1998 12:12:22 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: More ideas on a master address database Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 25 Jul 1998 12:12:21 -0500 Message-ID: Lines: 46 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Well, discussion has been pretty thin and I'm not sure whether this stems from more list problems, from a lack of time or from a general lack of interest. If it's the latter, then all I can say is that if you want to propose an idea, it stands a much greater chance of being implemented if you stick around to talk about it. Now, my ideas: Unless I get responses with reasons I shouldn't I'm going to go with the split I mentioned earlier except that I will add a 'registration date' to the master database that tracks the time the entry was first added. (Thanks, Brock.) I will add a 'register' command that adds an entry to the master database but not to any lists. This will assign a password. The owner can choose to have the process confirmed or to just have registration send the password to the registered address. The normal 'zubscribe' and 'unzubscribe' commands will work as expected, but they will also update the 'lists' entry in the master database. 'zubscribe will automatically register the user, but I haven't decided whether or not it will assign a password. (Doing so might be confusing; Listserv's password stuff even confuses me.) I'll make it settable whether or not the master database entry gets removed when the user leaves all lists in the domain. (Otherwise the database would have unbounded size.) The 'password' command will set or change a password. There will be a command to explicitly authorize any request using the assigned password; I haven't decided whether to drop this into the 'approve' password or make a new 'auth' command. Unfortunately we can't just slip the password somewhere on the normal command line. Having an appropriate password just bypasses confirmation (by default; it will just be an access control variable so a list owner could code up just about anything). There will be a function usable by an interface which will check the validity of a password. A web interface could make good use of this. Eventually hooks could be coded in to link into some other kind of user database. All of the password stuff will come later; right now I'm interested in getting the code to maintain the master database running. - J< From majordomo-workers-owner Sat Jul 25 17:10:14 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id RAA24647; Sat, 25 Jul 1998 17:06:17 -0700 (PDT) Received: from stingray.ivision.co.uk (stingray.ivision.co.uk [195.50.91.40]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id RAA24640 for ; Sat, 25 Jul 1998 17:06:10 -0700 (PDT) Received: from pretender.ivision.co.uk [195.50.91.43] by stingray.ivision.co.uk with smtp (Exim 1.62 #2) id 0z0EPE-0006oF-00; Sun, 26 Jul 1998 01:11:16 +0100 Message-Id: <3.0.5.32.19980726011113.009a1860@stingray.ivision.co.uk> X-Sender: manarpop@stingray.ivision.co.uk X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 26 Jul 1998 01:11:13 +0100 To: majordomo-workers@greatcircle.com From: Manar Hussain Subject: Re: More ideas on a master address database In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >'zubscribe will automatically register the user, but I haven't decided >whether or not it will assign a password. (Doing so might be confusing; >Listserv's password stuff even confuses me.) I'll make it settable whether We'll want a "have you forgotten your password - enter some details and we'll email one to the official email address" function anyways which should give you most of the code to allow a passwordless account to gain a password (if we keep the password crytped we'll already need to be setting the password to something new). What you will probably also need though is something to merge two accounts. Someone might zubscribe to two different lists with different email addresses and hence create two different "master user db accounts" ... Manar From majordomo-workers-owner Sun Jul 26 08:08:53 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id HAA03979; Sun, 26 Jul 1998 07:55:06 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id HAA03967 for ; Sun, 26 Jul 1998 07:54:57 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id KAA18260; Sun, 26 Jul 1998 10:00:04 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: More ideas on a master address database References: <3.0.5.32.19980726011113.009a1860@stingray.ivision.co.uk> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 26 Jul 1998 10:00:04 -0500 In-Reply-To: Manar Hussain's message of "Sun, 26 Jul 1998 01:11:13 +0100" Message-ID: Lines: 23 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "MH" == Manar Hussain writes: MH> We'll want a "have you forgotten your password - enter some details and MH> we'll email one to the official email address" function anyways which MH> should give you most of the code to allow a passwordless account to MH> gain a password (if we keep the password crytped we'll already need to MH> be setting the password to something new). Then you just set one. You can always set a password without knowing password; it just goes through email confirmation again. Nothing will assume that the unencrypted password can be extracted from the database. MH> What you will probably also need though is something to merge two MH> accounts. Someone might zubscribe to two different lists with different MH> email addresses and hence create two different "master user db MH> accounts" ... Then they have two different registrations. Perhaps that's the way they wanted it? I don't really see the utility when compared to the amount of coding time I have to implement these features, but you will always be welcome to submit patches. - J< From majordomo-workers-owner Sun Jul 26 14:54:54 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id OAA07127; Sun, 26 Jul 1998 14:46:54 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id OAA07120 for ; Sun, 26 Jul 1998 14:46:48 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id QAA23091; Sun, 26 Jul 1998 16:52:03 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: More ideas on a master address database References: <3.0.5.32.19980726011113.009a1860@stingray.ivision.co.uk> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 26 Jul 1998 16:52:02 -0500 In-Reply-To: Jason L Tibbitts III's message of "26 Jul 1998 10:00:04 -0500" Message-ID: Lines: 18 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "JLT" == Jason L Tibbitts writes: JLT> I don't really see the utility when compared to the amount of coding JLT> time I have to implement these features, but you will always be JLT> welcome to submit patches. I should reiterate that I'm not going to do the password stuff up front anyway (too much work right now and I haven't heard from any early adopter who says they want to use it) so there's plenty of time for you to try to convince me I'm wrong. This goes for just about anything here: you should always be prepared to argue your case; when I'm trying to fit as much useful code production into my limited hacking time I'm going to work on feature requests based on the perceived benefit. Show that there's plenty of benefit and things get done (eventually). ^_^ - J< From majordomo-workers-owner Sun Jul 26 15:24:56 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id PAA07445; Sun, 26 Jul 1998 15:09:48 -0700 (PDT) Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id PAA07438 for ; Sun, 26 Jul 1998 15:09:42 -0700 (PDT) Received: from pythagoras (bollow@pythagoras [129.132.146.161]) by frege.math.ethz.ch (8.8.8/Main-STAT-mailer) with ESMTP id AAA22551; Mon, 27 Jul 1998 00:14:52 +0200 (MET DST) Received: (bollow@localhost) by pythagoras (SMI-8.6/D-MATH-client) id AAA08489; Mon, 27 Jul 1998 00:14:56 +0200 Date: Mon, 27 Jul 1998 00:14:56 +0200 Message-Id: <199807262214.AAA08489@pythagoras> From: Norbert Bollow Prefer-Language: de, en, fr To: tibbs@hpc.uh.edu CC: majordomo-workers@greatcircle.com In-reply-to: (message from Jason L Tibbitts III on 26 Jul 1998 10:00:04 -0500) Subject: Re: More ideas on a master address database Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Jason L Tibbitts III writes > >>>>> "MH" == Manar Hussain writes: [..] > MH> What you will probably also need though is something to merge two > MH> accounts. Someone might zubscribe to two different lists with different > MH> email addresses and hence create two different "master user db > MH> accounts" ... > > Then they have two different registrations. Perhaps that's the way they > wanted it? Possible, but more often this will come about by accident, and create a lot of confusion. I don't see a good solution to this dilemma, though. Or is it possible to come up with a user interface for merging two such "email address accounts" without making things even more confusing to the avarage user? -- NB. > I don't really see the utility when compared to the amount of > coding time I have to implement these features, but you will always be > welcome to submit patches. > > - J< > From majordomo-workers-owner Mon Jul 27 08:58:28 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id IAA19477; Mon, 27 Jul 1998 08:50:50 -0700 (PDT) Received: from neviim.torah.org (neviim.torah.org [207.239.101.202]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id IAA19464 for ; Mon, 27 Jul 1998 08:50:36 -0700 (PDT) Received: from localhost (brozen@localhost) by neviim.torah.org (8.8.8/8.8.8) with SMTP id LAA27713; Mon, 27 Jul 1998 11:55:40 -0400 Date: Mon, 27 Jul 1998 18:55:40 +0300 (IDT) From: Brock Rozen Reply-To: Brock Rozen To: Manar Hussain cc: majordomo-workers@GreatCircle.COM Subject: Re: More ideas on a master address database In-Reply-To: <3.0.5.32.19980726011113.009a1860@stingray.ivision.co.uk> Message-ID: X-Backup: Disable X-URL: http://www.torah.org/~brozen MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On Sun, 26 Jul 1998, Manar Hussain wrote: > We'll want a "have you forgotten your password - enter some details and > we'll email one to the official email address" function anyways which > should give you most of the code to allow a passwordless account to gain a > password (if we keep the password crytped we'll already need to be setting > the password to something new). Only if responds to the main address and not to any "Reply-To" header. If you've lost your password AND have changed your e-mail address, then IMHO, you should be "up the creek". (As the Galacticomm BBS software says) > What you will probably also need though is something to merge two accounts. > Someone might zubscribe to two different lists with different email > addresses and hence create two different "master user db accounts" ... Interesting idea. Potentially, very useful. -- ---------------------------------- | Brock Rozen | brozen@torah.org | ---------------------------------- From majordomo-workers-owner Mon Jul 27 09:10:11 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id JAA19668; Mon, 27 Jul 1998 09:03:38 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id JAA19660 for ; Mon, 27 Jul 1998 09:03:24 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id LAA07922; Mon, 27 Jul 1998 11:08:35 -0500 (CDT) To: Brock Rozen Cc: majordomo-workers@GreatCircle.COM Subject: Re: More ideas on a master address database References: Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 27 Jul 1998 11:08:34 -0500 In-Reply-To: Brock Rozen's message of "Mon, 27 Jul 1998 19:01:12 +0300 (IDT)" Message-ID: Lines: 9 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "BR" == Brock Rozen writes: BR> Can the owner assign a password? I can't think of any reason why not. After all, any password just bypasses access restrictions, so it would take additional code to make this not work. - J< From majordomo-workers-owner Mon Jul 27 09:24:58 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id JAA19788; Mon, 27 Jul 1998 09:06:20 -0700 (PDT) Received: from neviim.torah.org (neviim.torah.org [207.239.101.202]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id JAA19781 for ; Mon, 27 Jul 1998 09:06:06 -0700 (PDT) Received: from localhost (brozen@localhost) by neviim.torah.org (8.8.8/8.8.8) with SMTP id MAA27967; Mon, 27 Jul 1998 12:11:26 -0400 Date: Mon, 27 Jul 1998 19:11:26 +0300 (IDT) From: Brock Rozen Reply-To: Brock Rozen To: Jason L Tibbitts III cc: majordomo-workers@GreatCircle.COM Subject: Re: More ideas on a master address database In-Reply-To: Message-ID: X-Backup: Disable X-URL: http://www.torah.org/~brozen MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On 27 Jul 1998, Jason L Tibbitts III wrote: > BR> Can the owner assign a password? > > I can't think of any reason why not. After all, any password just bypasses > access restrictions, so it would take additional code to make this not > work. At the same time as issuing the register command? -- ---------------------------------- | Brock Rozen | brozen@torah.org | ---------------------------------- From majordomo-workers-owner Mon Jul 27 10:01:12 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id IAA19515; Mon, 27 Jul 1998 08:54:11 -0700 (PDT) Received: from neviim.torah.org (neviim.torah.org [207.239.101.202]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id IAA19508 for ; Mon, 27 Jul 1998 08:54:02 -0700 (PDT) Received: from localhost (brozen@localhost) by neviim.torah.org (8.8.8/8.8.8) with SMTP id LAA27760; Mon, 27 Jul 1998 11:59:12 -0400 Date: Mon, 27 Jul 1998 18:59:12 +0300 (IDT) From: Brock Rozen Reply-To: Brock Rozen To: Norbert Bollow cc: tibbs@hpc.uh.edu, majordomo-workers@GreatCircle.COM Subject: Re: More ideas on a master address database In-Reply-To: <199807262214.AAA08489@pythagoras> Message-ID: X-Backup: Disable X-URL: http://www.torah.org/~brozen MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On Mon, 27 Jul 1998, Norbert Bollow wrote: > > Then they have two different registrations. Perhaps that's the way they > > wanted it? > > I don't see a good solution to this dilemma, though. Or is it possible to > come up with a user interface for merging two such "email address accounts" > without making things even more confusing to the avarage user? It would have to be a seperate command, and definitely not automatic to take care of the issue Jason brought up (of them wanting it that way). It would have to involve approvals (password or tokens; whatever) with both of the e-mail addresses and then actually do it. It's a nicety, IMO. Not critical and probably doesn't even need any more ground work to be laid for it to actually be programmed. Let me just say, I'd like to see other things first. Of course, CHANGING addresses is a different thing. That I like. :) Best regards, -- ---------------------------------- | Brock Rozen | brozen@torah.org | ---------------------------------- From majordomo-workers-owner Mon Jul 27 10:10:30 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id IAA19443; Mon, 27 Jul 1998 08:47:51 -0700 (PDT) Received: from neviim.torah.org (neviim.torah.org [207.239.101.202]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id IAA19436 for ; Mon, 27 Jul 1998 08:47:42 -0700 (PDT) Received: from localhost (brozen@localhost) by neviim.torah.org (8.8.8/8.8.8) with SMTP id LAA27679; Mon, 27 Jul 1998 11:52:58 -0400 Date: Mon, 27 Jul 1998 18:52:58 +0300 (IDT) From: Brock Rozen Reply-To: Brock Rozen To: Jason L Tibbitts III cc: majordomo-workers@GreatCircle.COM Subject: Re: Global address database and _serious_ call for a volunteer In-Reply-To: Message-ID: X-Backup: Disable X-URL: http://www.torah.org/~brozen MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On 24 Jul 1998, Jason L Tibbitts III wrote: > BR> Any possibility of getting 'record created date/time' ? It's created > BR> once and then never changed. > > That's what 'zubscribe time' is intended to be. I can make a global field > that keeps the time the record was first added. Might be useful. That way you can see how long the person has been around, even if they've unsubscribed from the first list they subscribed to. It could also be used as a variable in the bounce handler to use a "sliding scale" to decide on how long to give a bad address before it removes it. In addition, any analyzing program created to look at the global database could use this to give the site owner an idea of things as well. Question, which should be obvious, but I'll ask anyhow. If somebody is no longer subscribed to any lists, are they still in the global databse? Probably not, that makes sense. -- ---------------------------------- | Brock Rozen | brozen@torah.org | ---------------------------------- From majordomo-workers-owner Mon Jul 27 10:14:21 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id IAA19540; Mon, 27 Jul 1998 08:56:00 -0700 (PDT) Received: from neviim.torah.org (neviim.torah.org [207.239.101.202]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id IAA19533 for ; Mon, 27 Jul 1998 08:55:50 -0700 (PDT) Received: from localhost (brozen@localhost) by neviim.torah.org (8.8.8/8.8.8) with SMTP id MAA27815; Mon, 27 Jul 1998 12:01:12 -0400 Date: Mon, 27 Jul 1998 19:01:12 +0300 (IDT) From: Brock Rozen Reply-To: Brock Rozen To: Jason L Tibbitts III cc: majordomo-workers@GreatCircle.COM Subject: Re: More ideas on a master address database In-Reply-To: Message-ID: X-Backup: Disable X-URL: http://www.torah.org/~brozen MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On 25 Jul 1998, Jason L Tibbitts III wrote: > I will add a 'register' command that adds an entry to the master database > but not to any lists. This will assign a password. The owner can choose > to have the process confirmed or to just have registration send the > password to the registered address. Can the owner assign a password? > The normal 'zubscribe' and 'unzubscribe' commands will work as expected, > but they will also update the 'lists' entry in the master database. > 'zubscribe will automatically register the user, but I haven't decided > whether or not it will assign a password. (Doing so might be confusing; > Listserv's password stuff even confuses me.) I'll make it settable whether > or not the master database entry gets removed when the user leaves all > lists in the domain. (Otherwise the database would have unbounded size.) And you just answered my previous question. :) Thanks. -- ---------------------------------- | Brock Rozen | brozen@torah.org | ---------------------------------- From majordomo-workers-owner Mon Jul 27 10:39:56 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id KAA20747; Mon, 27 Jul 1998 10:37:15 -0700 (PDT) Received: from stingray.ivision.co.uk (stingray.ivision.co.uk [195.50.91.40]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id KAA20740 for ; Mon, 27 Jul 1998 10:37:07 -0700 (PDT) Received: from stingray.ivision.co.uk [195.50.91.40] by stingray.ivision.co.uk with smtp (Exim 1.62 #2) id 0z0rI5-0000gq-00; Mon, 27 Jul 1998 18:42:29 +0100 Date: Mon, 27 Jul 1998 18:42:29 +0100 (BST) From: Chris Rijk To: Jason L Tibbitts III cc: majordomo-workers@greatcircle.com Subject: Re: Installation problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Sorry about the late reply, but I decied to wait until I could get root access easily. (I rarely install stuff, I write stuff) Anyway, I installed the latest set again (on a different OS/computer), and got the same problem. After getting the kernal re-compiled so I could use ktrace, I found out it was a _permssions_ problem. In make install it sets .mj_confirm, .mj_email, .mj_resend and .mj_shell in the bin/ directory to be not executeable. I added a line in postinstall to make them executeable, after which, everything worked. Are they supposed to be executeable? btw make test runs with them not being executeable and it says everything's okay. Is it a bug in install (setting permissions wrong), or in the thing calling the above scripts? (or something else?) -- +-- Chris Rijk --------------------------------------- chris@ivision.co.uk --+ | Dictionary of Alternative Meanings: epitaph | | A belated advertisement for a line of goods that has been permanently | | discontinued. | From majordomo-workers-owner Mon Jul 27 10:54:56 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id KAA20829; Mon, 27 Jul 1998 10:45:39 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id KAA20819 for ; Mon, 27 Jul 1998 10:45:21 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id MAA09614; Mon, 27 Jul 1998 12:50:39 -0500 (CDT) To: Chris Rijk Cc: majordomo-workers@greatcircle.com Subject: Re: Installation problems References: Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 27 Jul 1998 12:50:38 -0500 In-Reply-To: Chris Rijk's message of "Mon, 27 Jul 1998 18:42:29 +0100 (BST)" Message-ID: Lines: 43 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "CR" == Chris Rijk writes: CR> Sorry about the late reply, but I decied to wait until I could get root CR> access easily. (I rarely install stuff, I write stuff) It's OK, I managed to duplicate this last night. It is an error that only occurs when running with wrappers which I somehow managed to miss. CR> Are they supposed to be executeable? Yes, they are. CR> btw make test runs with them not being executeable and it says CR> everything's okay. make test makes no use of them; you have to be able to run the tests without installing, so it uses the munged but not setuid scripts that end up in the blib directory just before installation. CR> Is it a bug in install (setting permissions wrong), or in the thing CR> calling the above scripts? (or something else?) It's a simple install bug. Here's the diff between current CVS and my tree: diff -u -r1.15 postinstall --- postinstall 1998/06/15 03:24:28 1.15 +++ postinstall 1998/07/27 17:48:40 @@ -221,7 +221,13 @@ my $scripts = shift; print "Setting permissions..."; $id = $config->{'install_dir'}; + if ($config->{wrappers}) { + for my $i (@$sidscripts) { + push @$scripts, ".$i"; + } + } map {$_ = "$id/bin/$_" unless /\//} @$sidscripts, @$scripts; + $uid = getpwnam($config->{'uid'}); $gid = getgrnam($config->{'gid'}); - J< From majordomo-workers-owner Mon Jul 27 11:09:57 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id LAA21077; Mon, 27 Jul 1998 11:01:29 -0700 (PDT) Received: from stingray.ivision.co.uk (stingray.ivision.co.uk [195.50.91.40]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id LAA21053 for ; Mon, 27 Jul 1998 11:01:19 -0700 (PDT) Received: from pretender.ivision.co.uk [195.50.91.43] by stingray.ivision.co.uk with smtp (Exim 1.62 #2) id 0z0rfP-0000ul-00; Mon, 27 Jul 1998 19:06:35 +0100 Message-Id: <3.0.5.32.19980727190630.00971a60@stingray.ivision.co.uk> X-Sender: manarpop@stingray.ivision.co.uk X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 27 Jul 1998 19:06:30 +0100 To: Jason L Tibbitts III From: Manar Hussain Subject: Re: More ideas on a master address database Cc: Brock Rozen , majordomo-workers@GreatCircle.COM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >BR> Can the owner assign a password? > >I can't think of any reason why not. After all, any password just bypasses >access restrictions, so it would take additional code to make this not >work. In our system the owner assigns himself a password but of course any email addresses provided are not validated (live in the system) unless that address has been confirmed - and the confirmation occurs by sending out a one time password (well one time password and/or URL) to the address being validated. Manar From majordomo-workers-owner Mon Jul 27 11:24:57 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id LAA21148; Mon, 27 Jul 1998 11:14:38 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id LAA21141 for ; Mon, 27 Jul 1998 11:14:13 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id NAA10312; Mon, 27 Jul 1998 13:18:31 -0500 (CDT) To: Manar Hussain Cc: Brock Rozen , majordomo-workers@GreatCircle.COM Subject: Re: More ideas on a master address database References: <3.0.5.32.19980727190630.00971a60@stingray.ivision.co.uk> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 27 Jul 1998 13:18:31 -0500 In-Reply-To: Manar Hussain's message of "Mon, 27 Jul 1998 19:06:30 +0100" Message-ID: Lines: 18 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "MH" == Manar Hussain writes: MH> In our system the owner assigns himself a password but of course any MH> email addresses provided are not validated (live in the system) unless MH> that address has been confirmed - and the confirmation occurs by MH> sending out a one time password (well one time password and/or URL) to MH> the address being validated. That sounds exactly like what Majordomo2 does already. You still have to go through confirmation when you register, even when you assign a password. That password is meaningless until something secret sent to the email address comes back. Everything in Mj2 works on this principle (unless, of course, it's configured to do otherwise). Of course, if the list owner is registering folks, then the list owner is trusted. - J< From majordomo-workers-owner Mon Jul 27 11:40:24 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id LAA21300; Mon, 27 Jul 1998 11:30:22 -0700 (PDT) Received: from stingray.ivision.co.uk (stingray.ivision.co.uk [195.50.91.40]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id LAA21278 for ; Mon, 27 Jul 1998 11:29:47 -0700 (PDT) Received: from pretender.ivision.co.uk [195.50.91.43] by stingray.ivision.co.uk with smtp (Exim 1.62 #2) id 0z0s73-000151-00; Mon, 27 Jul 1998 19:35:09 +0100 Message-Id: <3.0.5.32.19980727193504.009ab670@stingray.ivision.co.uk> X-Sender: manarpop@stingray.ivision.co.uk X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 27 Jul 1998 19:35:04 +0100 To: majordomo-workers@GreatCircle.COM From: Manar Hussain Subject: Re: More ideas on a master address database In-Reply-To: References: <3.0.5.32.19980727190630.00971a60@stingray.ivision.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >That sounds exactly like what Majordomo2 does already. You still have to >go through confirmation when you register, even when you assign a password. >That password is meaningless until something secret sent to the email >address comes back. Everything in Mj2 works on this principle (unless, of >course, it's configured to do otherwise). There may be a subtle variation. In our system the *account* is enabled before the email address is validated. This is, however, because people can in theory do things without using their email address - e.g. to change their personal details used on their "personal web page" or to come back and provide an alternative email address because the first one was a typo :) As it happens we never got around to offering any of these services but I think the distinction is valid. Manar From majordomo-workers-owner Mon Jul 27 13:40:05 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id NAA22625; Mon, 27 Jul 1998 13:24:37 -0700 (PDT) Received: from neviim.torah.org (neviim.torah.org [207.239.101.202]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id NAA22618 for ; Mon, 27 Jul 1998 13:24:31 -0700 (PDT) Received: from localhost (brozen@localhost) by neviim.torah.org (8.8.8/8.8.8) with SMTP id QAA31084; Mon, 27 Jul 1998 16:29:56 -0400 Date: Mon, 27 Jul 1998 23:29:56 +0300 (IDT) From: Brock Rozen Reply-To: Brock Rozen To: Jason L Tibbitts III cc: majordomo-workers@GreatCircle.COM Subject: Re: More ideas on a master address database In-Reply-To: Message-ID: X-Backup: Disable X-URL: http://www.torah.org/~brozen MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On 27 Jul 1998, Jason L Tibbitts III wrote: > This brings up a good point about what the arguments to a 'register' email > command should be. After some thought I can't see requiring anything other > than a password. In other words: > > register password Dude > > with the address part optional since we can dig it out of the header. This > oddly makes the register command and the password command nearly > identical. Hmmm. Well, the register command would fail if the user is > already registered, while the password command wouldn't. Maybe. Well, the reason I was thinking of allowing the password in the register command is simply because if the owner uses it -- we don't want him changing the password IMMEDIATELY after it's just been sent to the user. And does the password command confirm with the new password in the letter? If not (which I think is the proper way -- password should be returned as XXXX), that means he would have to send yet another letter to tell the person of the new password, after he just registered them. -- ---------------------------------- | Brock Rozen | brozen@torah.org | ---------------------------------- From majordomo-workers-owner Mon Jul 27 15:25:50 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id PAA24581; Mon, 27 Jul 1998 15:17:07 -0700 (PDT) Received: from stingray.ivision.co.uk (stingray.ivision.co.uk [195.50.91.40]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id PAA24574 for ; Mon, 27 Jul 1998 15:17:01 -0700 (PDT) Received: from pretender.ivision.co.uk [194.112.62.100] by stingray.ivision.co.uk with smtp (Exim 1.62 #2) id 0z0veu-00024R-00; Mon, 27 Jul 1998 23:22:21 +0100 Message-Id: <3.0.5.32.19980727232215.009eae80@stingray.ivision.co.uk> X-Sender: manarpop@stingray.ivision.co.uk X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 27 Jul 1998 23:22:15 +0100 To: majordomo-workers@GreatCircle.COM From: Manar Hussain Subject: Re: More ideas on a master address database In-Reply-To: References: <199807262214.AAA08489@pythagoras> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk a) I'd agree that the "merge two accounts" option is basically a nicety - especially since it should be easy for us to ensure it's pretty easy to slot in once the time to do so is available. It is will take a little thought to make sure it's properly approved (both account owners involved etc.). b) Date stamps - we've found that when we apply date stamps to things we always want to set at least 2 - "created on" and "last modified". We very often set a 3rd and possibly 4th which you might call something like the "display" date. The "display" date is sort of an editable "created on" or "last modified" date - basically many systems wind up displaying the date to the "public" and thus it's sometimes important to give someone the right to force set these to something but it's also useful if the service admin can always rely on a last modifed and created date. This may not be appropriate here. c) I think it would be nice to at least the option to retain accounts that are no longer zubscribed to anything. Maybe have it as an option plus have an API (which must be there anyways) to be able to access the database and apply a custom purge routine. I actually think it would also be nice to have unvalidated/inactive/old etc. email addresses for an account stay in the database for possible statistics use (suitably tagged of course). Then again I've always has the attitude that disk space is cheap and plentiful :) Off hand examples of why not nuking "null" accounts might be useful - on our system we would support someone having read only access to a read controlled "list" via the web site without an email address - but they'd need an account to authenticate against. I fully agree with people who think that the list systems should primarily focus on email functionality but there shouldn't be unnecessary blocking of useful web features. Also it can happen in the pure email side of things that someone looses an email address with warning. Nice souls that they are they may unsub (?suspend?) all their accounts and then when their new email address comes in they will resub (unsuspend?) things. c) I'm not sure we've tackled an issue of what counts as a username - do we base this on the email address or give out an actual username. I'd incline towards basing on an email address but then we need to give a little thought as to how this fits wrt multiple email addresses. I'd probably go with something like saying that the email address should always be interchangeable *except* when it comes to zubscribing to a list where ideally you'd get an *account* zubscribing to a list. But if so - do you then get a mask indicating which email address(es) get the mail / have mail allowed from etc (most functional but possibly difficult with the UI) or assume that there is a master email address for each account that recieves all email. That may be a particularly daft suggestion in that it's a long way from the current model for how zubscription is handled. I need to have a closer look at this end of mj2 before I risk making overly unhelpful suggestions :) Manar From majordomo-workers-owner Mon Jul 27 15:39:57 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id PAA24733; Mon, 27 Jul 1998 15:30:46 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id PAA24726 for ; Mon, 27 Jul 1998 15:30:39 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id RAA17232; Mon, 27 Jul 1998 17:36:04 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: More ideas on a master address database References: <3.0.5.32.19980727190630.00971a60@stingray.ivision.co.uk> <3.0.5.32.19980727193504.009ab670@stingray.ivision.co.uk> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 27 Jul 1998 17:36:04 -0500 In-Reply-To: Manar Hussain's message of "Mon, 27 Jul 1998 19:35:04 +0100" Message-ID: Lines: 22 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "MH" == Manar Hussain writes: MH> There may be a subtle variation. In our system the *account* is enabled MH> before the email address is validated. This is, however, because people MH> can in theory do things without using their email address But to Majordomo everything is about email addresses. After all, that is what it deals with most fundamentally. Before anything 'damaging' can happen (basically sending any mail that isn't a confirmation message) a confirmation must happen. Remember that Majordomo isn't anything more than a mailing list manager. It has no business doing anything related to setting up personal web pages or anything else. It may one day be flexible enough to hook into another account system assuming that system is flexible enough to store the information that Majordomo needs to store (although I suppose a suitable database abstraction could hide an inability to do that). Majordomo doesn't store 'personal details' other than that needed to run its lists. In order to maintain focus, I have to make sure that stays clear. - J< From majordomo-workers-owner Mon Jul 27 17:53:55 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id RAA26393; Mon, 27 Jul 1998 17:49:42 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id RAA26385 for ; Mon, 27 Jul 1998 17:49:35 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id TAA20217; Mon, 27 Jul 1998 19:55:03 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: More ideas on a master address database References: Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 27 Jul 1998 19:55:02 -0500 In-Reply-To: Brock Rozen's message of "Mon, 27 Jul 1998 23:29:56 +0300 (IDT)" Message-ID: Lines: 26 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "BR" == Brock Rozen writes: BR> Well, the reason I was thinking of allowing the password in the BR> register command is simply because if the owner uses it -- we don't BR> want him changing the password IMMEDIATELY after it's just been sent to BR> the user. That's a good point. I really haven't put in any deep thought on this because I'm concentrating on getting the master database working instead of working out a password system. Yes, we'll have to accept a password at register time unless we just want to go with randomly generated ones that the user can change later. (Which seems to be what Listserv does.) BR> And does the password command confirm with the new password in the BR> letter? I prefer to keep the confirmation engine completely separate and general; it just knows it has an action to confirm. There's no reason it should communicate the password; the password itself can come after confirmation. Besides, it's useless before confirmation anyway because the registration hasn't really happened. (This is an integral part of the way Mj2 works.) Doing it any other way would be confusing. - J< From majordomo-workers-owner Mon Jul 27 18:23:55 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id SAA26780; Mon, 27 Jul 1998 18:21:33 -0700 (PDT) Received: from plaidworks.com (plaidworks.com [207.167.80.66]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id SAA26773 for ; Mon, 27 Jul 1998 18:21:27 -0700 (PDT) Received: from (zamboni.plaidworks.com [207.167.80.70]) by plaidworks.com (8.8.8/8.8.8) with ESMTP id SAA30772 ; Mon, 27 Jul 1998 18:28:43 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: chuqui2@plaidworks.com Message-Id: In-Reply-To: References: <3.0.5.32.19980726011113.009a1860@stingray.ivision.co.uk> Date: Mon, 27 Jul 1998 18:00:56 -0700 To: Brock Rozen , Manar Hussain From: Chuq Von Rospach Subject: Re: More ideas on a master address database Cc: majordomo-workers@GreatCircle.COM Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk At 8:55 AM -0700 7/27/98, Brock Rozen wrote: > Only if responds to the main address and not to any "Reply-To" header. If > you've lost your password AND have changed your e-mail address, then IMHO, > you should be "up the creek". (As the Galacticomm BBS software says) I guess this could be defined as "a second password", but do what credit card companies do. Store "mother's maiden name" or some such other unique identifier, and if they know that and their previous e-mail address, you're pretty darn sure it's them. Actually, the way I'd handle this is that if the old address is dead and they can't get back into the database, then let them register as new. But if the old address is forwarding but unavailable, you can send them the password info via the address in the database -- and if it gets to them, they can then unlock. Since the address in the database is validated, you can safely send them the info there. And if that address doesn't forward, it'll likely start bouncing some day anyway, and you can drop them... -- Chuq Von Rospach (Hockey fan? ) Apple Mail List Gnome (mailto:chuq@apple.com) Plaidworks Consulting (mailto:chuqui@plaidworks.com) + From majordomo-workers-owner Mon Jul 27 19:23:55 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id TAA27491; Mon, 27 Jul 1998 19:17:51 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id TAA27484 for ; Mon, 27 Jul 1998 19:17:45 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id VAA22225; Mon, 27 Jul 1998 21:23:13 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: More ideas on a master address database References: <199807262214.AAA08489@pythagoras> <3.0.5.32.19980727232215.009eae80@stingray.ivision.co.uk> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 27 Jul 1998 21:23:13 -0500 In-Reply-To: Manar Hussain's message of "Mon, 27 Jul 1998 23:22:15 +0100" Message-ID: Lines: 58 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "MH" == Manar Hussain writes: MH> - especially since it should be easy for us to ensure it's pretty easy MH> to slot in once the time to do so is available. Eventually... Right now I'm trying to finish testing and cleanup before I start into the master database change set. MH> It is will take a little thought to make sure it's properly approved MH> (both account owners involved etc.). This could get very complicated. MH> b) Date stamps These things aren't really for display, unless the owner decides not to restrict the 'show' command (which is the generic database-data-dumper). The two fields (create and change) are essentially maintained by the database backend anyway. If we find that more are necessary, we can add them. MH> c) I think it would be nice to at least the option to retain accounts MH> that are no longer zubscribed to anything. Especially if Majordomo's just a client of an external database. I said earlier it would be settable, but I'm not confident that everything is getting out. I see a separate purge routine as sort of wasteful as you have to do a database update for every unzubscribe, so why not just remove it then? But then again it's five lines of callback sub and a call to mogrify(), so why not? MH> Also it can happen in the pure email side of things that someone looses MH> an email address with warning. Nice souls that they are they may unsub MH> (?suspend?) all their accounts and then when their new email address MH> comes in they will resub (unsuspend?) things. I imagine they'd 'nomail' them instead of nuking them if they wanted to be kind, but who can say. MH> c) I'm not sure we've tackled an issue of what counts as a username - MH> do we base this on the email address or give out an actual MH> username. It really has to be an address. Else we get into a uniqueness issue which I just don't want to get into. And as I said before, the fundamental focus has to be addresses here. I don't want simple sites with simple users having to go through some complicated system when all they wanted was to join a single list. Perhaps I'm setting my sights short of a new paradigm of Internet information delivery here, but I'm really just trying to write a mailing list manager (and get it out before the millennium). If we eventually want to bolt on some other kind of distribution technology, it's easier to start with addresses and add 'pseudo-addresses' later (like account@web-push for a push channel, or user@webview for a hypothetical system that lets users read over the web and tracks new messages and such for them, or whatever). - J< From majordomo-workers-owner Mon Jul 27 21:08:57 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id VAA28771; Mon, 27 Jul 1998 21:03:33 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id VAA28764 for ; Mon, 27 Jul 1998 21:03:20 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id XAA24136; Mon, 27 Jul 1998 23:08:47 -0500 (CDT) To: majordomo-workers@greatcircle.com, Chuq Von Rospach Subject: Re: More ideas on a master address database References: <3.0.5.32.19980726011113.009a1860@stingray.ivision.co.uk> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 27 Jul 1998 23:08:46 -0500 In-Reply-To: Chuq Von Rospach's message of "Mon, 27 Jul 1998 18:00:56 -0700" Message-ID: Lines: 35 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "CVR" == Chuq Von Rospach writes: CVR> Actually, the way I'd handle this is that if the old address is dead CVR> and they can't get back into the database, then let them register as CVR> new. But if the old address is forwarding but unavailable, you can CVR> send them the password info via the address in the database -- and if CVR> it gets to them, they can then unlock. Right. The whole point of having passwords boils down to these two benefits: Bypassing confirmation, which really helps web interfaces where waiting for emailed responses is less than fun. It also improves 'perceived responsiveness' for email users because they only have to wait for the server to process one request, not two (where the second is the confirmation acceptance). And if they forget the password, they can still confirm either once to get a new password or ignore passwords altogether and deal with confirmations. _Reducing_ the list-owner time investment, by giving users another mechanism for dealing with address changes or mismatches because of non-masqueraded hosts. If they can remember their password, they can still manipulate their registration/zubscriptions. If they don't remember their passwords and can't mail from a matching address, then nobody's any worse off than they were before and a mail to $list-owner clears it up. Or they can just reregister and the old address can bounce and be nuked. There's just no point in trying to obsolete the list owner, only in doing whatever is possible to reduce the load. Of course, I could be missing some big benefit of passwords, but the facts that we've been getting by without them for so long and that I've never had to use them even on systems that have them mean that in the context of Majordomo, they can't be much more than a convenience. - J< From majordomo-workers-owner Tue Jul 28 08:24:17 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id IAA08489; Tue, 28 Jul 1998 08:11:25 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id IAA08482 for ; Tue, 28 Jul 1998 08:11:16 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id KAA02963; Tue, 28 Jul 1998 10:16:43 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Some commits Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 28 Jul 1998 10:16:42 -0500 Message-ID: Lines: 53 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk I just committed a bunch of changes to the CVS tree; these are somewhat tested but don't be surprised if you find some additional instability. The bulk of these changes have to do with unifying all of the code that sits at an email address (the command processors at majordomo and *-request, the owner-forwarder, the request-response thing that sits at -request, the bounce processor, and resend) into one executable. After writing several of these things by cut and paste I figured it made much more sense to just combine them. This simplifies things quite a bit and paves the way for using the -default stuff that qmail provides. You will have to redo your aliases. 'createlist' will tell you the new aliases you need. They look like this: # Aliases for Majordomo majordomo: "|/path/to/mj_email -m -d host.edu" majordomo-owner: "|/path/to/mj_email -o -d host.edu" owner-majordomo: majordomo-owner, # End aliases for Majordomo # Aliases for test-list test-list: "|/path/to/mj_email -r -d host.edu -l test-list" test-list-request: "|/path/to/mj_email -q -d host.edu -l test-list" test-list-owner: "|/path/to/mj_email -o -d host.edu -l test-list" owner-test-list: test-list-owner, # End aliases for test-list (-m is majordomo, -r is resend, -q is reQuest, -o is owner.) There are some new goodies: the request_answer variable controls what happens to messages sent to $list-request; it has three values: majordomo - the message will be processed for commands owner - the message will be sent to the list owner response - the contents of the file 'request_response' will be returned to the sender of the message. Blame the list-managers discussion for that one. The variable is global, as this is a site policy decision. The list owner can of course upload their own request_response file; the default is taken from the request-answer script in the 1.94.4. distribution. Also, since the owner is no longer hardcoded in the aliases, it is settable in the config file. The 'owners' variable is an array of addresses which hold all of the list owners. This is initialized at 'createlist' time. mj_resend still exists for a while but shouldn't be used; I'll remove it in a week or so. I went through and standardized everything to use list-owner instead of owner-list. This has always made more sense to me. I have not yet updated README.UPGRADE, so watch out. - J< From majordomo-workers-owner Wed Jul 29 06:24:10 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id GAA26294; Wed, 29 Jul 1998 06:23:03 -0700 (PDT) Received: from neviim.torah.org (neviim.torah.org [207.239.101.202]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id GAA26287 for ; Wed, 29 Jul 1998 06:22:56 -0700 (PDT) Received: from localhost (brozen@localhost) by neviim.torah.org (8.8.8/8.8.8) with SMTP id JAA23443; Wed, 29 Jul 1998 09:28:36 -0400 Date: Wed, 29 Jul 1998 16:28:36 +0300 (IDT) From: Brock Rozen Reply-To: Brock Rozen To: Chuq Von Rospach cc: Manar Hussain , majordomo-workers@GreatCircle.COM Subject: Re: More ideas on a master address database In-Reply-To: Message-ID: X-Backup: Disable X-URL: http://www.torah.org/~brozen MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On Mon, 27 Jul 1998, Chuq Von Rospach wrote: > I guess this could be defined as "a second password", but do what > credit card companies do. Store "mother's maiden name" or some such > other unique identifier, and if they know that and their previous > e-mail address, you're pretty darn sure it's them. Right -- but it's more code. > Actually, the way I'd handle this is that if the old address is dead > and they can't get back into the database, then let them register as > new. But if the old address is forwarding but unavailable, you can send > them the password info via the address in the database -- and if it > gets to them, they can then unlock. Since the address in the database > is validated, you can safely send them the info there. And if that > address doesn't forward, it'll likely start bouncing some day anyway, > and you can drop them... My suggestion exactly, the password should be sent ONLY to the address on file, not paying attention to Reply-To headers or anything else. If it's being forwarded, then no problem -- if not, then it'll bounce somebody, I assume. -- ---------------------------------- | Brock Rozen | brozen@torah.org | ---------------------------------- From majordomo-workers-owner Wed Jul 29 06:38:55 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id GAA26334; Wed, 29 Jul 1998 06:29:12 -0700 (PDT) Received: from neviim.torah.org (neviim.torah.org [207.239.101.202]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id GAA26327 for ; Wed, 29 Jul 1998 06:29:04 -0700 (PDT) Received: from localhost (brozen@localhost) by neviim.torah.org (8.8.8/8.8.8) with SMTP id JAA23473; Wed, 29 Jul 1998 09:34:42 -0400 Date: Wed, 29 Jul 1998 16:34:42 +0300 (IDT) From: Brock Rozen Reply-To: Brock Rozen To: Jason L Tibbitts III cc: majordomo-workers@GreatCircle.COM Subject: Re: More ideas on a master address database In-Reply-To: Message-ID: X-Backup: Disable X-URL: http://www.torah.org/~brozen MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On 27 Jul 1998, Jason L Tibbitts III wrote: > MH> It is will take a little thought to make sure it's properly approved > MH> (both account owners involved etc.). > > This could get very complicated. And given the nature, something that can be added in later -- no need to ponder on this now. > MH> Also it can happen in the pure email side of things that someone looses > MH> an email address with warning. Nice souls that they are they may unsub > MH> (?suspend?) all their accounts and then when their new email address > MH> comes in they will resub (unsuspend?) things. > > I imagine they'd 'nomail' them instead of nuking them if they wanted to be > kind, but who can say. Right, 'nomail' essentially makes the account immune to being removed from bad bounces -- unless that idea of a tracer goes into effect. I know some list software sends me a message like every 6 weeks (the BugTraq list does this) just to verify that I'm around. It works on the presumption that I am NOT around, and will take me off in a week if I don't respond! > MH> c) I'm not sure we've tackled an issue of what counts as a username - > MH> do we base this on the email address or give out an actual > MH> username. > > It really has to be an address. Else we get into a uniqueness issue which > I just don't want to get into. And as I said before, the fundamental focus > has to be addresses here. I don't want simple sites with simple users > having to go through some complicated system when all they wanted was to > join a single list. And what's the purpose of uniqueness? What do they possibly need a userid for that an e-mail address couldn't supplement? Are we looking at password-protected archives for people who aren't on the list itself? I think that's, at least now, beyond Majordomo's scope. Majordomo is MAILING-LIST software, after-all! -- ---------------------------------- | Brock Rozen | brozen@torah.org | ---------------------------------- From majordomo-workers-owner Thu Jul 30 03:38:56 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id DAA11930; Thu, 30 Jul 1998 03:27:02 -0700 (PDT) Received: from frege.math.ethz.ch (frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id DAA11922 for ; Thu, 30 Jul 1998 03:26:55 -0700 (PDT) Received: from leibniz.math.ethz.ch (bollow@leibniz [129.132.146.163]) by frege.math.ethz.ch (8.8.8/Main-STAT-mailer) with ESMTP id MAA06264; Thu, 30 Jul 1998 12:32:42 +0200 (MET DST) Received: (bollow@localhost) by leibniz.math.ethz.ch (8.6.12/D-MATH-client) id MAA01320; Thu, 30 Jul 1998 12:32:46 +0200 Date: Thu, 30 Jul 1998 12:32:46 +0200 Message-Id: <199807301032.MAA01320@leibniz.math.ethz.ch> From: Norbert Bollow Prefer-Language: de, en, fr To: majordomo-workers@greatcircle.com Subject: MIME-Mailer Vulnerability Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk This calls for a patch to resend to stop messages with overly long MIME headers from being relayed. Does anyone know how long is "overly long"? -- Norbert. > __________________________________________________________ > > The U.S. Department of Energy > Computer Incident Advisory Capability > ___ __ __ _ ___ > / | /_\ / > \___ __|__ / \ \___ > __________________________________________________________ > > ADVISORY BULLETIN > > Mime Name Vulnerability in Outlook and Messenger > >July 27, 1998 20:00 GMT Number I-077 >______________________________________________________________________________ >PROBLEM: A buffer overflow vulnerability has been identified in > Microsoft Outlook, Outlook Express, and Netscape Messenger > (Mail) that allows an e-mail or news message to contain > malicious code in a mime header. That code is executed when the > header is read by the e-mail/news reader. All of these > e-mail/news readers are widely distributed with popular > packages such as Internet Explorer, Windows 98, Windows 97, > Office 97, and Netscape Communicator. >PLATFORM: Any platform that runs the vulnerable e-mail/news readers: > Windows 95, Windows 98, Windows NT, Macintosh and Solaris. >DAMAGE: If exploited, this vulnerability allows a remote user to run > arbitrary code on a users machine with the user's privileges. > The remotely executed code could do anything from sending > thousands of e-mails in the user's name to formatting the hard > drive. >SOLUTION: Apply patches from Microsoft and Netscape. >______________________________________________________________________________ >VULNERABILITY Risk is high. While we have not yet heard of anyone exploiting >ASSESSMENT: this vulnerability for malicious purposes, the ease with which > it can be exploited, the wide distribution of vulnerable > readers, and the potential for damage makes it a very serious > problem. >______________________________________________________________________________ From majordomo-workers-owner Thu Jul 30 05:44:47 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id FAA12969; Thu, 30 Jul 1998 05:37:27 -0700 (PDT) Received: from mermaid.shore.net (mermaid.shore.net [207.244.124.6]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id FAA12962 for ; Thu, 30 Jul 1998 05:37:20 -0700 (PDT) Received: from smoe.org [204.167.97.154] by mermaid.shore.net with esmtp (Exim) id 0z1s34-00050p-00; Thu, 30 Jul 1998 08:43:10 -0400 Received: (from jeffw@localhost) by smoe.org (8.8.7/8.8.7/daemon-mode-relay2) id IAA10926; Thu, 30 Jul 1998 08:43:09 -0400 (EDT) Message-ID: <19980730084308.E538@smoe.org> Date: Thu, 30 Jul 1998 08:43:08 -0400 From: Jeff Wasilko To: Norbert Bollow , majordomo-workers@GreatCircle.COM Subject: Re: MIME-Mailer Vulnerability Mail-Followup-To: Norbert Bollow , majordomo-workers@GreatCircle.COM References: <199807301032.MAA01320@leibniz.math.ethz.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <199807301032.MAA01320@leibniz.math.ethz.ch>; from "Norbert Bollow" on Thu, Jul 30, 1998 at 12:32:46PM +0200 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk On Thu, Jul 30, 1998 at 12:32:46PM +0200, Norbert Bollow wrote: > This calls for a patch to resend to stop messages with overly long MIME > headers from being relayed. Does anyone know how long is "overly long"? I think it's 256 bytes in Mickeysoft clients and 1024 bytes in other clients. Jeff From majordomo-workers-owner Thu Jul 30 09:09:48 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id JAA15242; Thu, 30 Jul 1998 09:04:07 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id JAA15233 for ; Thu, 30 Jul 1998 09:03:48 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id LAA27268; Thu, 30 Jul 1998 11:09:36 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: MIME-Mailer Vulnerability References: <199807301032.MAA01320@leibniz.math.ethz.ch> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 30 Jul 1998 11:09:36 -0500 In-Reply-To: Norbert Bollow's message of "Thu, 30 Jul 1998 12:32:46 +0200" Message-ID: Lines: 17 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "NB" == Norbert Bollow writes: NB> This calls for a patch to resend to stop messages with overly long MIME NB> headers from being relayed. Does anyone know how long is "overly long"? 'Overly long' is very much platform dependent, but 128 characters is probably more than reasonable. I'm not sure that this is possible in 1.94.x resend without making it completely MIME-aware, unless you want to use some nasty heuristics. It's easy in 2.0 since we already traverse the MIME tree, and I'll commit a change to make it deal with this tonight. I suspect that a default action of bouncing to the owner when any MIME header exceeds some configurable length (default 128) is sufficient. I'm not sure this is really Majordomo's responsibility to fix in any case, but I can't see how it could hurt. - J< From majordomo-workers-owner Thu Jul 30 09:24:51 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id JAA15354; Thu, 30 Jul 1998 09:16:09 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id JAA15340; Thu, 30 Jul 1998 09:15:45 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id LAA27426; Thu, 30 Jul 1998 11:21:39 -0500 (CDT) To: majordomo-users@greatcircle.com, majordomo-workers@greatcircle.com Subject: Perl 5.005_01 problems Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 30 Jul 1998 11:21:39 -0500 Message-ID: Lines: 12 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Please note that today there arrived a message at the perl bug report address detailing a problem with Majordomo (the version was not stated in typical bad bug reporting style) when running under perl5.005_01 (the very latest version). This is definitely a bug in perl (it should never segfault when running code) but it is possible that a change to the Majordomo source code may work around it. I have not had a chance to investigate further, and will provide more information after I have done so. Until then I advise caution when upgrading to 5.005_01. -- Jason L Tibbitts III - tibbs@uh.edu - 713/743-3486 - 660PGH - 94 PC800 System Manager: University of Houston Department of Mathematics "I survived while Ruby died in Jackie's trashy fantasy..." From majordomo-workers-owner Thu Jul 30 11:12:09 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id LAA16890; Thu, 30 Jul 1998 11:05:41 -0700 (PDT) Received: from primefactor.com (primefactor.com [38.234.255.99]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id LAA16875 for ; Thu, 30 Jul 1998 11:05:27 -0700 (PDT) Received: from localhost (matt@localhost) by primefactor.com (8.8.7/8.8.7) with SMTP id OAA18280 for ; Thu, 30 Jul 1998 14:08:51 -0400 Date: Thu, 30 Jul 1998 14:08:51 -0400 (EDT) From: Matt Perry To: majordomo-workers@greatcircle.com Subject: Stopping spaming modification to Majordomo Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk I, like I'm sure many people, receive spam through mailing lists. This happens because some spammer has the mailing list address as the recipient. One way that I saw in the FAQ to turn this off is to set the restrict_post option. Well, I stopped the spam locally using procmail and thought that the way I did it would be a great modification for Majordomo. If this is already in Majordomo 2 or has been discussed to death, my apologies. The basic idea revolves around this. Spammers rarely have the recipient's name in the headers. Usually both the To: and From: lines are fake addresses. Add to this that I can't find anyone who can give me a valid reason why you would want to blind carbon copy a mailing list, gives me this solution. When a message is sent to a mailing list, resend could check the headers to make sure that they actually contain the mailing list address. If the mailing list address is not found, resend could either bounce to message to the list admin for approval, or just delete it. I could see this being a three option config variable for Majordomo list config files. None, Bounce, or Delete None, of course, means that it wouldn't even perform the check. -=- For those who are interested, I got this idea because a friend of mine started receiving a lot of spam through the Cypherpunks mailing list. I set him up with the following procmail receipe that fix this: :0: * ^Sender.*owner-cypherpunks@toad.com { :0 * ^TOcypherpunks@toad.com cypherpunks :0 E cpspam } All of his spam went straight to a folder called cpspam. I think he's now changed this to /dev/null. :-) BTW, the ^TO part of the above expands into the following regex: (^((Original-)?(Resent-)?(To|Cc|Bcc)|(X-Envelope|Apparently(-Resent)?)-To:):(.*[^a-zA-Z])?) -- Matt Perry | matt at primefactor dot com "After ecstasy, laundry." - Zen writing From majordomo-workers-owner Thu Jul 30 14:08:57 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id OAA19267; Thu, 30 Jul 1998 14:08:32 -0700 (PDT) Received: from cis.ohio-state.edu (mail.cis.ohio-state.edu [164.107.115.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id OAA19260 for ; Thu, 30 Jul 1998 14:08:26 -0700 (PDT) Received: from stumble.cis.ohio-state.edu (barr@stumble.cis.ohio-state.edu [164.107.128.12]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id RAA24967 for ; Thu, 30 Jul 1998 17:14:25 -0400 (EDT) Message-Id: <199807302114.RAA24967@cis.ohio-state.edu> To: majordomo-workers@GreatCircle.COM Subject: Re: Stopping spaming modification to Majordomo In-reply-to: Your message of "Thu, 30 Jul 1998 14:08:51 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Jul 1998 17:13:56 -0400 From: Dave Barr Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >The basic idea revolves around this. Spammers rarely have the recipient's >name in the headers. Unfortunately this assumption is often false. I routinely get "EMAIL MARKETING WORKS" spams mailed directly to half a dozen mailing lists that I'm on. The mail has the mailing lists in the To: and/or Cc: lines. This can most effectively be stopped by using restrict_post. I get other spams regularly sent to me with my address in it. Some spammers seem to be intentionally targeting mailing lists this way. Relying on techniques that are easily worked around is not a very effective way of stopping a problem. Spammers will simply modify their tactics, as they have in the past. Using things like the RBL, restrict_post, and common sense filtering are effective and rational ways to combat spam (together with a sprinkling of laws and industry policing too!). --Dave From majordomo-workers-owner Thu Jul 30 15:39:13 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id PAA20153; Thu, 30 Jul 1998 15:37:34 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id PAA20146 for ; Thu, 30 Jul 1998 15:37:21 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id RAA06182; Thu, 30 Jul 1998 17:43:05 -0500 (CDT) To: majordomo-workers@greatcircle.com, Matt Perry Subject: Re: Stopping spaming modification to Majordomo References: Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 30 Jul 1998 17:43:05 -0500 In-Reply-To: Matt Perry's message of "Thu, 30 Jul 1998 14:08:51 -0400 (EDT)" Message-ID: Lines: 35 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "MP" == Matt Perry writes: MP> Well, I stopped the spam locally using procmail and thought that the MP> way I did it would be a great modification for Majordomo. If this is MP> already in Majordomo 2 or has been discussed to death, my apologies. Requiring the list name somewhere in the headers is not a new idea; in Majordomo2 you can just use a simple inverted taboo_header match like: !/^(To|CC):.*listname/i This will bounce (or it could just dump on the floor, your choice) the message if that expression doesn't match somewhere in the header. MP> Add to this that I can't find anyone who can give me a valid reason why MP> you would want to blind carbon copy a mailing list, gives me this MP> solution. This happens a whole lot. Much more than you think it does given your quick dismissal; root back through the list-manager archives for some good discussion about this. I think that for lists which can tolerate the no-bcc restriction, this is a pretty good defense, but that self-confirmation (or automoderation or whatever you want to call it) is better. This requires non-zubscribers to respond to a confirmation message before their message is posted. Majordomo2 supports this, too. And since it supports an aliasing mechanism, the problem of joining under one address but posting from another goes away. The list owner doesn't have to get involved in any moderation. This does, unfortunately, make it more difficult for address mungers who are real but don't post with legal addresses. (Which doesn't bother me one bit. Fortunately it's up to the list owner to decide what they want for their list.) - J< From majordomo-workers-owner Thu Jul 30 15:53:58 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id PAA20200; Thu, 30 Jul 1998 15:40:40 -0700 (PDT) Received: from ivan.iecc.com (ivan.iecc.com [208.31.42.33]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id PAA20186 for ; Thu, 30 Jul 1998 15:40:28 -0700 (PDT) Received: (qmail 25062 invoked by uid 100); 30 Jul 1998 22:46:27 -0000 Date: Thu, 30 Jul 1998 18:46:27 -0400 (EDT) From: John R Levine To: Matt Perry cc: majordomo-workers@greatcircle.com Subject: Re: Stopping spaming modification to 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 > addresses. Add to this that I can't find anyone who can give me a valid > reason why you would want to blind carbon copy a mailing list, gives me > this solution. I bcc mailing lists all the time. Some of the lists I'm on are private but related to other public lists, and I bcc the private list when I send something to the public list. Also, as others have noted, spamware increasingly puts each victim's name in the To: line, making this hack ineffective. Making a list "members only" for posting is a lot more effective and already works. 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 Thu Jul 30 16:54:17 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id QAA20942; Thu, 30 Jul 1998 16:41:29 -0700 (PDT) Received: from gsulaw.gsu.edu (gsulaw.Gsu.EDU [131.96.159.141]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id QAA20935 for ; Thu, 30 Jul 1998 16:41:24 -0700 (PDT) Received: from localhost (lawppw@localhost) by gsulaw.gsu.edu (8.8.5/8.8.5) with SMTP id TAA13574; Thu, 30 Jul 1998 19:45:10 -0400 Date: Thu, 30 Jul 1998 19:45:10 -0400 (EDT) From: Patrick Wiseman To: Jason L Tibbitts III cc: majordomo-workers@GreatCircle.COM Subject: Re: Perl 5.005_01 problems 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 Jul 1998, Jason L Tibbitts III wrote: :Please note that today there arrived a message at the perl bug report :address detailing a problem with Majordomo (the version was not stated in :typical bad bug reporting style) when running under perl5.005_01 (the very :latest version). This is definitely a bug in perl I "upgraded" to 5.005_01 on a non-production machine, and it broke (not segfaulted) some scripts which had been working fine before. In my particular case, it turned out that the behavior of the "rename" function has apparently changed -- it used to behave just like the UNIX "mv" command (i.e. one could "rename" a file from one location to another). I had not relied on that behavior on purpose :) but it doesn't appear to work that way any more, and I have a lot of work to do on some scripts if they're going to work with 5.005_01. (It may well be that I had inadvertently relied on what was bad behavior anyway; but maybe this perl version has some other problems.) Patrick (note: I took -users out of the list, as it seemed not of continuing interest there) From majordomo-workers-owner Thu Jul 30 17:09:28 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id RAA21201; Thu, 30 Jul 1998 17:00:53 -0700 (PDT) Received: from spsem02.sps.mot.com (spsem02.sps.mot.com [192.70.231.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id RAA21194 for ; Thu, 30 Jul 1998 17:00:46 -0700 (PDT) Received: from mogate.sps.mot.com by spsem02.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA11936 for majordomo-workers@GreatCircle.COM; Thu, 30 Jul 98 17:06:43 MST Received: from motsps (motsps.sps.mot.com) by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA12040 for nb@thinkcoach.com; Thu, 30 Jul 98 17:06:41 MST Received: from risc.risc.sps.mot.com by motsps (SMI-8.6/SMI-4.1/Email-2.1) id JAA26249 for ; Thu, 30 Jul 1998 09:25:23 -0700 Received: from miaow.risc.sps.mot.com (miaow.risc.sps.mot.com [223.72.249.15]) by risc.risc.sps.mot.com (8.8.7/8.8.7) with ESMTP id LAA06023; Thu, 30 Jul 1998 11:24:06 -0500 (CDT) Received: (from dwolfe@localhost) by miaow.risc.sps.mot.com (8.7.1/8.7.3) id LAA05814; Thu, 30 Jul 1998 11:26:03 -0500 Message-Id: <19980730112602.A26956@risc.sps.mot.com> Date: Thu, 30 Jul 1998 11:26:02 -0500 From: Dave Wolfe To: Norbert Bollow Cc: majordomo-workers@GreatCircle.COM Subject: Re: MIME-Mailer Vulnerability References: <199807301032.MAA01320@leibniz.math.ethz.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199807301032.MAA01320@leibniz.math.ethz.ch>; from Norbert Bollow on Thu, Jul 30, 1998 at 12:32:46PM +0200 X-Mutt-References: <199807301032.MAA01320@leibniz.math.ethz.ch> Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk [ Norbert Bollow writes: ] > This [header buffer overflow bug in MS Outlook and NS Messenger] calls > for a patch to resend to stop messages with overly long MIME headers > from being relayed. Does anyone know how long is "overly long"? I read somewhere, maybe on the MS site, that 200 bytes and longer triggered the bug. Anyway, Mj 1.94 (all versions) seems to already have this covered. From sample.cf: # The maximum character length of the header lines for resend # $MAX_HEADER_LINE_LENGTH = 128; However, the real problem is (multi-part?) MIME headers in the body of mail. While this shouldn't be any big deal for Mj2, Mj 1.x doesn't grok MIME, it's all just bits to it, so a patch would have to implement new functionality (MIME awareness) and any simple hacks (check anything that looks like a header) might end up causing more problems than they fix, e.g. unnecessarily bounced messages, rejection of all MIME messages, etc. If you want to go for the "check anything that looks like a header" hack, try this: --- resend.orig Wed Aug 27 09:59:24 1997 +++ resend Thu Jul 30 11:22:17 1998 @@ -808,6 +808,13 @@ $gonna_bounce .= " Message too long (>$opt_M chars) "; next; } + + # Is this (MIME header) line too long? + if (/^[\w-]+:/ && (length($_) > $MAX_HEADER_LINE_LENGTH)) { + &bounce("MIME header line too long in body (>$MAX_HEADER_LINE_LENGTH)"); + return(undef); + } + } print OUT $_; } # while -- Dave Wolfe From majordomo-workers-owner Thu Jul 30 20:08:57 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id TAA23637; Thu, 30 Jul 1998 19:59:42 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id TAA23630 for ; Thu, 30 Jul 1998 19:59:36 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id WAA12416; Thu, 30 Jul 1998 22:05:37 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: MIME-Mailer Vulnerability References: <199807301032.MAA01320@leibniz.math.ethz.ch> <19980730112602.A26956@risc.sps.mot.com> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 30 Jul 1998 22:05:33 -0500 In-Reply-To: Dave Wolfe's message of "Thu, 30 Jul 1998 11:26:02 -0500" Message-ID: Lines: 36 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "DW" == Dave Wolfe writes: DW> Anyway, Mj 1.94 (all versions) seems to already have this covered. From DW> sample.cf: [MAX_HEADER_LINE_LENGTH] This is kind of interesting. After I implemented this functionality in Mj2, I found that I was bouncing a large number of messages because of it. A really, really large number, in fact. Why? Because 1.94 doesn't check the lines _unfolded_. It just looks at every line of the message before the first blank individually. Most Received: headers are longer than 128 characters, and Mj2 only pokes at a decoded and unfolded version of the headers (though an original copy is saved so that it is not mangled in the process). In the end I upped the default to 448. For some reason I'm not really sure why I chose 448; 512 is too large for some sites. [Patch] This also doesn't consider folded lines. Does anyone know if the original bug is still triggerable with folded header lines? One important point that I must make, though: Majordomo is not the right place to do this kind of thing. If you read bugtraq you know that along with this problem is the problem of large embedded OBJECT tags which have exactly the same result as large header lines when it comes to broken MS products. Should we be trapping those, too? What about the latest email-borne exploit? Majordomo has a history of limiting header line length which is why I don't see a problem with extending it to MIME headers, but we shouldn't get into the business of trying to filter out every exploit that comes around. - J< From majordomo-workers-owner Thu Jul 30 20:39:36 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id UAA23986; Thu, 30 Jul 1998 20:25:37 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [36.21.0.44]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id UAA23977 for ; Thu, 30 Jul 1998 20:25:22 -0700 (PDT) Received: (qmail 7533 invoked by uid 500); 31 Jul 1998 03:31:18 -0000 To: majordomo-workers@GreatCircle.COM Subject: Re: Perl 5.005_01 problems References: From: Russ Allbery In-Reply-To: Patrick Wiseman's message of "Thu, 30 Jul 1998 19:45:10 -0400 (EDT)" Date: 30 Jul 1998 20:31:18 -0700 Message-ID: Lines: 24 X-Mailer: Gnus v5.4.66/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Patrick Wiseman writes: > I "upgraded" to 5.005_01 on a non-production machine, and it broke (not > segfaulted) some scripts which had been working fine before. In my > particular case, it turned out that the behavior of the "rename" > function has apparently changed -- it used to behave just like the UNIX > "mv" command (i.e. one could "rename" a file from one location to > another). Er.... rename() in Perl just calls rename(2). I'm fairly certain that this has never been the case. Are you certain that this wasn't a case of the source and destination previously being on the same file system and now are not on the same file system any more? rename(2) requires that the destination be on the same file as the source since it doesn't do a copy, only manipulates directory entries. In any case, if you want the functionality of mv, including a renaming by copy and unlink when renaming across filesystems, use File::Copy::move. -- Russ Allbery (rra@stanford.edu) From majordomo-workers-owner Fri Jul 31 09:52:31 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id JAA05478; Fri, 31 Jul 1998 09:28:56 -0700 (PDT) Received: from dns.cyberlink.ch (dns.cyberlink.ch [193.246.253.10]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id JAA05464 for ; Fri, 31 Jul 1998 09:28:31 -0700 (PDT) Received: from quill (norbert@gate3-24.cyberlink.ch [195.246.74.94]) by dns.cyberlink.ch (8.8.8/8.8.8) with ESMTP id SAA15075; Fri, 31 Jul 1998 18:34:15 +0200 Received: (from norbert@localhost) by quill (8.8.8/8.8.8) id NAA00395; Fri, 31 Jul 1998 13:32:12 +0200 Date: Fri, 31 Jul 1998 13:32:12 +0200 Message-Id: <199807311132.NAA00395@quill> From: Norbert Bollow Prefer-Language: de, en, fr To: tibbs@hpc.uh.edu CC: majordomo-workers@GreatCircle.COM In-reply-to: (message from Jason L Tibbitts III on 30 Jul 1998 22:05:33 -0500) Subject: Re: MIME-Mailer Vulnerability Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Jason writes: > One important point that I must make, though: Majordomo is not the right > place to do this kind of thing. If you read bugtraq you know that along > with this problem is the problem of large embedded OBJECT tags which have > exactly the same result as large header lines when it comes to broken MS > products. Should we be trapping those, too? What about the latest > email-borne exploit? Yes, at least one of my clients needs a version which makes sure that no mailcious code can possibly be transmitted through certain mailing lists. This is not as impossible as it sounds at first, because most weird (and hence hard-to-check) stuff is not very portable between various kinds of systems anyway, and hence not appropriate anyway for posting on the lists in question. So, what I need is the ability run lists in some kind of 'paranoid' mode which may be somewhat limiting with regard to what messages can be relayed though the list, but which must make sure that it is absolutely impossible for viruses to be transmitted through messages on the list. Until very recently I thought it was sufficient to toboo MIME content-types containing /application/i but now it appears that this may not be enough. So what is enough? -- NB From majordomo-workers-owner Fri Jul 31 09:53:59 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id JAA05660; Fri, 31 Jul 1998 09:40:45 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id JAA05646 for ; Fri, 31 Jul 1998 09:40:31 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id LAA25099; Fri, 31 Jul 1998 11:46:25 -0500 (CDT) To: Norbert Bollow Cc: majordomo-workers@GreatCircle.COM Subject: Re: MIME-Mailer Vulnerability References: <199807311132.NAA00395@quill> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 31 Jul 1998 11:46:25 -0500 In-Reply-To: Norbert Bollow's message of "Fri, 31 Jul 1998 13:32:12 +0200" Message-ID: Lines: 44 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "NB" == Norbert Bollow writes: NB> Yes, at least one of my clients needs a version which makes sure that NB> no mailcious code can possibly be transmitted through certain mailing NB> lists. Then your customer needs to turn off all of their computers. This is absolutely, completely impossible to do. We do not know what bugs lie in the various MUAs. NB> This is not as impossible as it sounds at first, because most weird NB> (and hence hard-to-check) stuff is not very portable between various NB> kinds of systems anyway, and hence not appropriate anyway for posting NB> on the lists in question. But that doesn't mean that they won't be posted. Propriety doesn't factor on when you're talking about malice. If your customer is trying to cover his ass, you (or he) must protect against everything. NB> So, what I need is the ability run lists in some kind of 'paranoid' NB> mode which may be somewhat limiting with regard to what messages can be NB> relayed though the list, but which must make sure that it is absolutely NB> impossible for viruses to be transmitted through messages on the NB> list. Majordomo will never be able to provide such a thing. (It can provide the infrastructure, but not the out-of-box functionality.) If you want to follow bugtraq and keep up with the exploits then you may be able to construct appropriate taboo regexps to filter _most_ of them out. Paranoid header length checks just won't cut it when you're talking completeness. We don't even know what all of the bugs are! NB> Until very recently I thought it was sufficient to toboo MIME NB> content-types containing /application/i but now it appears that this NB> may not be enough. So what is enough? Nothing is enough. Filter every content type not of type text/plain (including the top level; allow no MIME at all), limit header length strictly, turn off any form of header encoding and strip the 8th bit from everything. Taboo out anything that looks like '; Fri, 31 Jul 1998 10:13:11 -0700 (PDT) Received: from atlantis.csc.umd.edu ((IDENT rsw)@localhost [127.0.0.1]) by atlantis.csc.umd.edu (8.9.0.Beta6/8.9.0.Beta6) with ESMTP id NAA12401; Fri, 31 Jul 1998 13:19:17 -0400 (EDT) Received: from localhost by atlantis.csc.umd.edu (8.9.0.Beta6/8.9.0.Beta6) with SMTP id NAA12396; Fri, 31 Jul 1998 13:19:15 -0400 (EDT) X-Authentication-Warning: atlantis.csc.umd.edu: rsw owned process doing -bs Date: Fri, 31 Jul 1998 13:19:14 -0400 (EDT) From: "Randall S. Winchester" To: Jason L Tibbitts III cc: majordomo-workers@GreatCircle.COM Subject: Re: Stopping spaming modification to 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 A problem that I have seen many times of late, is not how majordomo deals with incomming spam, but its' handling of mail returned it from down stream sites that have spam blocks stricter then the the majordmo server. For example, our site has been hit by spam very heavily over the last few years, and have thus had a user community grateful for a reasonable spam blocking policy. However, when spam that we would normally block, like bulls-eye, comes through other sites majordomo servers to our users, we would bounce it back. The user would then get dropped from the other sites list as a bad or undeliverable address. It would be advantageous if majordomo could evaluate the smtp response codes and tray to make a determination of the bounce. In other words, majordomo should allow some bounces to happen, and ignore them, or at least note them as not a bad address issue. I know that some of this occurs by others add on bounce collectors, and by -owners who do not read or are to busy to read the responce. I, have since, hacked our sendmail to look for the "Precedence:" field in the SMTP header and discard the mail instead of bouncing it if this field is present. Most of my users now stay on their majordomo lists, but do not get as much spam though these lists. Randall From majordomo-workers-owner Fri Jul 31 10:39:02 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id KAA06274; Fri, 31 Jul 1998 10:36:46 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id KAA06267 for ; Fri, 31 Jul 1998 10:36:40 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id MAA26382; Fri, 31 Jul 1998 12:42:45 -0500 (CDT) To: "Randall S. Winchester" Cc: majordomo-workers@GreatCircle.COM Subject: Re: Stopping spaming modification to Majordomo References: Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 31 Jul 1998 12:42:45 -0500 In-Reply-To: "Randall S. Winchester"'s message of "Fri, 31 Jul 1998 13:19:14 -0400 (EDT)" Message-ID: Lines: 16 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "RSW" == Randall S Winchester writes: RSW> It would be advantageous if majordomo could evaluate the smtp response RSW> codes and tray to make a determination of the bounce. In other words, RSW> majordomo should allow some bounces to happen, and ignore them, or at RSW> least note them as not a bad address issue. Well, we don't do any bounce processing at all right now; Majordomo just isn't involved in that. When we do implement it, we'll have to worry about these kinds of things. (Well, perhaps; I don't think anyone proposes removing an address that bounces only once.) But doing this kind of thing requires actual bounce parsing; VERPs (or the Mj2 analogue) can't help you there. Then again, most MTAs supporting those kinds of filters also use a reasonable bounce format. - J< From majordomo-workers-owner Fri Jul 31 11:09:09 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id LAA06593; Fri, 31 Jul 1998 11:01:53 -0700 (PDT) Received: from atlantis.csc.umd.edu (atlantis.csc.umd.edu [129.2.8.129]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id LAA06586 for ; Fri, 31 Jul 1998 11:01:47 -0700 (PDT) Received: from atlantis.csc.umd.edu ((IDENT rsw)@localhost [127.0.0.1]) by atlantis.csc.umd.edu (8.9.0.Beta6/8.9.0.Beta6) with ESMTP id OAA12553; Fri, 31 Jul 1998 14:07:52 -0400 (EDT) Received: from localhost by atlantis.csc.umd.edu (8.9.0.Beta6/8.9.0.Beta6) with SMTP id OAA12548; Fri, 31 Jul 1998 14:07:50 -0400 (EDT) X-Authentication-Warning: atlantis.csc.umd.edu: rsw owned process doing -bs Date: Fri, 31 Jul 1998 14:07:50 -0400 (EDT) From: "Randall S. Winchester" To: Jason L Tibbitts III cc: majordomo-workers@GreatCircle.COM Subject: Re: Stopping spaming modification to 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 31 Jul 1998, Jason L Tibbitts III wrote: : >>>>> "RSW" == Randall S Winchester writes: : : RSW> It would be advantageous if majordomo could evaluate the smtp response : RSW> codes and tray to make a determination of the bounce. In other words, : RSW> majordomo should allow some bounces to happen, and ignore them, or at : RSW> least note them as not a bad address issue. : : Well, we don't do any bounce processing at all right now; Majordomo just : isn't involved in that. Yes, but I wanted to comment on the issue so others could consider it. This will bite others as they implement anti-spam policies. : When we do implement it, we'll have to worry about these kinds of : things. (Well, perhaps; I don't think anyone proposes removing an : address that bounces only once.) Well, as more sites turn off relaying it will get somewhat better. Once a big spammer gets your majordmo list, it will be more then one that goes though and bounced. : But doing this kind of thing requires actual bounce parsing; VERPs (or : the Mj2 analogue) can't help you there. Then again, most MTAs : supporting those kinds of filters also use a reasonable bounce format. Yes, most do. Randall From majordomo-workers-owner Fri Jul 31 11:23:59 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id LAA06861; Fri, 31 Jul 1998 11:21:49 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id LAA06854 for ; Fri, 31 Jul 1998 11:21:42 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id NAA27566; Fri, 31 Jul 1998 13:27:33 -0500 (CDT) To: "Randall S. Winchester" Cc: majordomo-workers@GreatCircle.COM Subject: Re: Stopping spaming modification to Majordomo References: Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 31 Jul 1998 13:27:33 -0500 In-Reply-To: "Randall S. Winchester"'s message of "Fri, 31 Jul 1998 14:07:50 -0400 (EDT)" Message-ID: Lines: 34 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "RSW" == Randall S Winchester writes: RSW> Well, as more sites turn off relaying it will get somewhat RSW> better. Once a big spammer gets your majordmo list, it will be more RSW> then one that goes though and bounced. True, but I think that trying to parse out bounces is not necessarily the best answer. For one, it's a heck of a lot of work and we're never guaranteed to be able to figure out everything (although this shouldn't stop us from parsing common formats). Some way for the owner to remove a particular message from considering in bounce calculations would be interesting. You always know know the message number that bounce, because it's always in the envelope if you have an MTA that supports it. (Look at the envelopes from any Mj2-run lists.) Sendmail and qmail do; someone tells me that MMDF does and I can't see why Exim and Zmailer wouldn't though I don't know what their separators are. (Sendmail uses '+', qmail uses '-', I've heard MMDF uses '='.) So the bounce processor can use this to its advantage, and the owner could theoretically tell it not to worry about bounces from a particular message. Another thing to do is to make your input filters as strong as those downstream of you. (But of course you know this.) I have some play code to implement RBL lookups on every IP address mentioned in the Received: lines of a message and bounce transgressing messages to the owner. (It's pretty easy, really, and this is less Draconian than refusing to accept the messages at all.) If people stop relaying then we can actually trust this information. An interesting side effect of bounce processing: I can forge bounces to the processor and remove someone I don't like from a list. - J< From majordomo-workers-owner Fri Jul 31 11:53:59 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id LAA07099; Fri, 31 Jul 1998 11:42:26 -0700 (PDT) Received: from atlantis.csc.umd.edu (atlantis.csc.umd.edu [129.2.8.129]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id LAA07092 for ; Fri, 31 Jul 1998 11:42:19 -0700 (PDT) Received: from atlantis.csc.umd.edu ((IDENT rsw)@localhost [127.0.0.1]) by atlantis.csc.umd.edu (8.9.0.Beta6/8.9.0.Beta6) with ESMTP id OAA12681; Fri, 31 Jul 1998 14:48:24 -0400 (EDT) Received: from localhost by atlantis.csc.umd.edu (8.9.0.Beta6/8.9.0.Beta6) with SMTP id OAA12676; Fri, 31 Jul 1998 14:48:21 -0400 (EDT) X-Authentication-Warning: atlantis.csc.umd.edu: rsw owned process doing -bs Date: Fri, 31 Jul 1998 14:48:21 -0400 (EDT) From: "Randall S. Winchester" To: Jason L Tibbitts III cc: majordomo-workers@GreatCircle.COM Subject: Re: Stopping spaming modification to 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 31 Jul 1998, Jason L Tibbitts III wrote: : >>>>> "RSW" == Randall S Winchester writes: : : RSW> Well, as more sites turn off relaying it will get somewhat : RSW> better. Once a big spammer gets your majordmo list, it will be more : RSW> then one that goes though and bounced. : : True, but I think that trying to parse out bounces is not necessarily the : best answer. For one, it's a heck of a lot of work and we're never : guaranteed to be able to figure out everything (although this shouldn't : stop us from parsing common formats). Some way for the owner to remove a : particular message from considering in bounce calculations would be : interesting. : : You always know know the message number that bounce, because it's always in : the envelope if you have an MTA that supports it. (Look at the envelopes : from any Mj2-run lists.) Sendmail and qmail do; someone tells me that MMDF : does and I can't see why Exim and Zmailer wouldn't though I don't know what : their separators are. (Sendmail uses '+', qmail uses '-', I've heard MMDF : uses '='.) So the bounce processor can use this to its advantage, and the : owner could theoretically tell it not to worry about bounces from a : particular message. My "Precedence:" hack does have some merit as well. If it can be done in a non-hack fashion, it could make it into a future sendmail release. It logically makes sence to handle rejects from a mailing list differently, as there are "man in the middle" issues where they will have no knowledge of others policies. As long as mailing lists use the "Precedence:" field, they can be handled differently. I do not evaluate what if anything is to the right of that field as there is no standard, but maillists are usually the only things that set this field. : : Another thing to do is to make your input filters as strong as those : downstream of you. (But of course you know this.) I have some play code : to implement RBL lookups on every IP address mentioned in the Received: : lines of a message and bounce transgressing messages to the owner. (It's : pretty easy, really, and this is less Draconian than refusing to accept the : messages at all.) If people stop relaying then we can actually trust this : information. Stopping the relay's is an important first step in the spam wars. : An interesting side effect of bounce processing: I can forge bounces to the : processor and remove someone I don't like from a list. Yes, along with the "subscribe enemy" to all lists in the world, I keep expecting to see the "unsubscribe enemy" ones... Randall From majordomo-workers-owner Fri Jul 31 13:54:06 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id NAA09323; Fri, 31 Jul 1998 13:42:27 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id NAA09313 for majordomo-workers@greatcircle.com; Fri, 31 Jul 1998 13:42:24 -0700 (PDT) Received: from krumm.commline.com (krumm.commline.com [209.218.54.252]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id MAA23749 for ; Wed, 22 Jul 1998 12:59:03 -0700 (PDT) Received: from localhost (dmbong@localhost) by krumm.commline.com (8.8.5/8.8.8) with SMTP id QAA17737; Wed, 22 Jul 1998 16:03:31 -0400 (EDT) (envelope-from dmbong@commline.com) Date: Wed, 22 Jul 1998 16:03:31 -0400 (EDT) From: "Brian L. Heess" To: Jason L Tibbitts III cc: majordomo-workers@GreatCircle.COM Subject: Re: Am I just being left out? 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 22 Jul 1998, Jason L Tibbitts III wrote: > Because these list problems are really cutting into progress on the new > version, I have to consider running my own development list. Before I > do anything like that, though, I need the input of folks on this list. > Does anyone here think that would be a bad thing, a slap in the face of > the owner of this list or Greatcircle, or otherwise? I understand this...I can see good and not-so-good reasons for either way... :) If it's not at GC, you can turn off the administrativa stuff...plus it might be faster...BUT, GC does work, and it's a slap, BUT it could tend to divide efforts, you know? All already know where it is at GC, too, and it's documented being there, as well, they are nice enough to keep it there. SO, I say leave it with GC, but, I am willing to hear other sides. From majordomo-workers-owner Fri Jul 31 14:09:00 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id NAA09415; Fri, 31 Jul 1998 13:43:38 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id NAA09405 for majordomo-workers@greatcircle.com; Fri, 31 Jul 1998 13:43:34 -0700 (PDT) Received: from krumm.commline.com (krumm.commline.com [209.218.54.252]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id OAA15788 for ; Thu, 23 Jul 1998 14:26:58 -0700 (PDT) Received: from localhost (dmbong@localhost) by krumm.commline.com (8.8.5/8.8.8) with SMTP id RAA21156 for ; Thu, 23 Jul 1998 17:32:03 -0400 (EDT) (envelope-from dmbong@commline.com) Date: Thu, 23 Jul 1998 17:32:02 -0400 (EDT) From: "Brian L. Heess" To: Majordomo Workers Subject: Re: Global address database and _serious_ call for a volunteer 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 23 Jul 1998, Jason L Tibbitts III wrote: > Now, the global list doesn't even have to be Majordomo-maintained; it > could be on an LDAP server somewhere assuming that the fields it needs > can be created. The per-list stuff should be probably be internal, > though. > > Ideas? As I was reading this message I started thinking about how cool it would be to have other optional fields related to a subscriber (for some things I have done with my music related lists)... Now, I don't know too much about LDAP, but I figured an LDAP server can have info like a mailing address, title and LOTS of other info in it, right? Now, to interface to sticking a mailing address in with a list subscriber would be wicked. I sometimes get promo stuff from record labels that I can use to give away on my lists, so making a contest and then having the list members send in an address to majordomo would be way cool and easy for me to maintain such a "contest award engine" or something goofy like that.. :) Time to go read about LDAP. :( -Brian From majordomo-workers-owner Fri Jul 31 14:24:00 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id OAA10124; Fri, 31 Jul 1998 14:22:55 -0700 (PDT) Received: from spsem02.sps.mot.com (spsem02.sps.mot.com [192.70.231.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id OAA10117 for ; Fri, 31 Jul 1998 14:22:48 -0700 (PDT) Received: from mogate.sps.mot.com by spsem02.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AB19790 for majordomo-workers@GreatCircle.COM; Fri, 31 Jul 98 14:28:51 MST Received: from risc.risc.sps.mot.com by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA00418 for majordomo-workers@GreatCircle.COM; Fri, 31 Jul 98 14:28:21 MST Received: from miaow.risc.sps.mot.com (miaow.risc.sps.mot.com [223.72.249.15]) by risc.risc.sps.mot.com (8.8.7/8.8.7) with ESMTP id QAA09038; Fri, 31 Jul 1998 16:26:46 -0500 (CDT) Received: (from dwolfe@localhost) by miaow.risc.sps.mot.com (8.7.1/8.7.3) id QAA20832; Fri, 31 Jul 1998 16:28:43 -0500 Message-Id: <19980731162842.A19272@risc.sps.mot.com> Date: Fri, 31 Jul 1998 16:28:42 -0500 From: Dave Wolfe To: Jason L Tibbitts III , "Randall S. Winchester" Cc: majordomo-workers@GreatCircle.COM Subject: Re: Stopping spaming modification to Majordomo References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Jason L Tibbitts III on Fri, Jul 31, 1998 at 01:27:33PM -0500 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk [ Jason L Tibbitts III writes: ] > > Another thing to do is to make your input filters as strong as those > downstream of you. (But of course you know this.) I have some play code > to implement RBL lookups on every IP address mentioned in the Received: > lines of a message and bounce transgressing messages to the owner. Watch out there. I've already been bitten by someone trying that without realizing that those of us on private networks behind firewalls may show IP numbers that fall in the holes of the RBL. One would hope that Received headers originating behind such firewalls are removed from messages passing through the firewall to the outside world, but 'tain't always so. And there's no good way to determine which Received host is such a firewall for a given message without keeping a database of them similar to the RBL. My life as a MLM for a moderate-sized list has been made pure hell by the ever-growing set of over zealous mail filterers. -- Dave Wolfe From majordomo-workers-owner Fri Jul 31 15:09:02 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id PAA10717; Fri, 31 Jul 1998 15:07:06 -0700 (PDT) Received: from dns.cyberlink.ch (dns.cyberlink.ch [193.246.253.10]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id PAA10709 for ; Fri, 31 Jul 1998 15:06:56 -0700 (PDT) Received: from quill (norbert@gate3-14.cyberlink.ch [195.246.74.84]) by dns.cyberlink.ch (8.8.8/8.8.8) with ESMTP id AAA05960; Sat, 1 Aug 1998 00:12:59 +0200 Received: (from norbert@localhost) by quill (8.8.8/8.8.8) id AAA00305; Sat, 1 Aug 1998 00:58:19 +0200 Date: Sat, 1 Aug 1998 00:58:19 +0200 Message-Id: <199807312258.AAA00305@quill> From: Norbert Bollow Prefer-Language: de, en, fr To: rsw@Glue.umd.edu CC: majordomo-workers@GreatCircle.COM In-reply-to: (rsw@Glue.umd.edu) Subject: Re: Stopping spaming modification to Majordomo Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Randall S. Winchester wrote: > For example, our site has been hit by spam very heavily over the last few > years, and have thus had a user community grateful for a reasonable spam > blocking policy. However, when spam that we would normally block, like > bulls-eye, comes through other sites majordomo servers to our users, we > would bounce it back. The user would then get dropped from the other sites > list as a bad or undeliverable address. > > It would be advantageous if majordomo could evaluate the smtp response codes > and try to make a determination of the bounce. In other words, majordomo > should allow some bounces to happen, and ignore them, or at least note them > as not a bad address issue. The bounce-handler which I've written for Majordomo2 isn't quite ready for committing the code to the CVS tree, but I can assure you that it is very careful not to remove addresses if only a few messages to a subscribed address bounce. However it would certainly be handy to have a method to tell from the bounce when a message was message is rejected because it triggered the spam filters and not because of delivery problems. Of course the smtp response code is not in all cases available from the bounce (we have no control over what MTA might be attempting to relay the message to your host). However I would be willing to check incoming bounces for the regular expression /554.*spam/i and in such a case have much more patience with the address than otherwise. (Note that RFC821 does not define any response code specifically for "this message not accepted because it looks like spam", and according to section 5.2.10 of RFC1123, "A receiver-SMTP SHOULD send only the reply codes listed in section 4.2.2 of RFC-821". Hence the choice is limited to one of the following: 550 Requested action not taken: mailbox unavailable [E.g., mailbox not found, no access] 551 User not local; please try 552 Requested mail action aborted: exceeded storage allocation 553 Requested action not taken: mailbox name not allowed [E.g., mailbox syntax incorrect] 554 Transaction failed Which one do you use? Something like "554 Message seems to be spam" I'd suppose.) -- NB. From majordomo-workers-owner Fri Jul 31 15:39:04 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id PAA10897; Fri, 31 Jul 1998 15:25:51 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id PAA10890 for ; Fri, 31 Jul 1998 15:25:43 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id RAA03317; Fri, 31 Jul 1998 17:29:13 -0500 (CDT) To: Dave Wolfe Cc: "Randall S. Winchester" , majordomo-workers@GreatCircle.COM Subject: Re: Stopping spaming modification to Majordomo References: <19980731162842.A19272@risc.sps.mot.com> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 31 Jul 1998 17:29:12 -0500 In-Reply-To: Dave Wolfe's message of "Fri, 31 Jul 1998 16:28:42 -0500" Message-ID: Lines: 12 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "DW" == Dave Wolfe writes: DW> Watch out there. Why? It's play code that does nothing worse than make it possible for the list owner to take a look at RBL-rejected messages. I don't see what there is to watch out for. Certainly much better for your case than implementing the RBL at the MTA level. I'd think you'd be happy that this were an alternative to the Draconian proposition of having the MTA bounce these messages out of hand without anyone ever seeing them. - J< From majordomo-workers-owner Fri Jul 31 15:54:21 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id PAA11290; Fri, 31 Jul 1998 15:51:27 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id PAA11283 for ; Fri, 31 Jul 1998 15:51:20 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id RAA04094; Fri, 31 Jul 1998 17:57:30 -0500 (CDT) To: Norbert Bollow Cc: majordomo-workers@GreatCircle.COM Subject: Re: Stopping spaming modification to Majordomo References: <199807312343.BAA00362@quill> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 31 Jul 1998 17:57:29 -0500 In-Reply-To: Norbert Bollow's message of "Sat, 1 Aug 1998 01:43:42 +0200" Message-ID: Lines: 22 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "NB" == Norbert Bollow writes: NB> I once thought the same, but now I have some pretty neat parser code... Ah, well, that changes the game entirely. NB> Only if this is not the case we have to fall back to VERP-probing, or NB> bother the list-owner if the local MTA won't allow VERPs.) Neat. Of course, if you have a bounce as a result of a periodic probe (or you're running behind qmail) you can always trust the probe info. NB> This will not be possible if the bounce-handler is designed properly, NB> using something like a confirmation code to verify than an address is NB> genuinely bouncing. That's true; if you know (or at least have been fooled into thinking that) you're going to get a bounce back, you can probe with a token in the envelope. When a message comes back to that special envelope address, you know you have a real bouncer. I suppose that solves the problem. - J< From majordomo-workers-owner Fri Jul 31 16:09:22 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id PAA11169; Fri, 31 Jul 1998 15:42:04 -0700 (PDT) Received: from dns.cyberlink.ch (dns.cyberlink.ch [193.246.253.10]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id PAA11162 for ; Fri, 31 Jul 1998 15:41:58 -0700 (PDT) Received: from quill (norbert@gate3-14.cyberlink.ch [195.246.74.84]) by dns.cyberlink.ch (8.8.8/8.8.8) with ESMTP id AAA14385; Sat, 1 Aug 1998 00:48:01 +0200 Received: (from norbert@localhost) by quill (8.8.8/8.8.8) id BAA00362; Sat, 1 Aug 1998 01:43:42 +0200 Date: Sat, 1 Aug 1998 01:43:42 +0200 Message-Id: <199807312343.BAA00362@quill> From: Norbert Bollow Prefer-Language: de, en, fr To: tibbs@hpc.uh.edu CC: rsw@Glue.umd.edu, majordomo-workers@GreatCircle.COM In-reply-to: (message from Jason L Tibbitts III on 31 Jul 1998 13:27:33 -0500) Subject: Re: Stopping spaming modification to Majordomo Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk Jason L Tibbitts III wrote: > True, but I think that trying to parse out bounces is not necessarily the > best answer. I once thought the same, but now I have some pretty neat parser code... > For one, it's a heck of a lot of work It's not that bad, really. (Code exists already to parse all of the common bounce formats. Also if the headers of the original message are returned as part of the bounce, chances are that it may be possible to find the bouncing address from the Received: headers; this has a chance of revealing the subscribed address even it forwards to an entirely different address which then generates bounces. The parser returns a list reference to a list of addresses which might possibly be responsible for the bounce. Then the bounce-handler checks if any of these addresses is actually subscribed to the list in question. Only if this is not the case we have to fall back to VERP-probing, or bother the list-owner if the local MTA won't allow VERPs.) > An interesting side effect of bounce processing: I can forge bounces > to the processor and remove someone I don't like from a list. This will not be possible if the bounce-handler is designed properly, using something like a confirmation code to verify than an address is genuinely bouncing. -- NB. From majordomo-workers-owner Fri Jul 31 16:39:01 1998 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id QAA12089; Fri, 31 Jul 1998 16:36:26 -0700 (PDT) Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id QAA12067 for ; Fri, 31 Jul 1998 16:36:16 -0700 (PDT) Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id SAA04707; Fri, 31 Jul 1998 18:42:26 -0500 (CDT) To: majordomo-workers@greatcircle.com Subject: Re: Global address database and _serious_ call for a volunteer References: Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Jason L Tibbitts III Date: 31 Jul 1998 18:42:25 -0500 In-Reply-To: "Brian L. Heess"'s message of "Thu, 23 Jul 1998 17:32:02 -0400 (EDT)" Message-ID: Lines: 16 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: majordomo-workers-owner@GreatCircle.COM Precedence: bulk >>>>> "BLH" == Brian L Heess writes: BLH> As I was reading this message I started thinking about how cool it BLH> would be to have other optional fields related to a subscriber (for BLH> some things I have done with my music related lists)... I could be persuaded to add a couple of fields in the list and master databases for whatever the list owner might desire to put there. I don't really want to get into defining access to those fields now, though. LDAP doesn't really come into it, other than being a possible place for Majordomo to stuff some of its data. I don't see Majordomo becoming any kind of general LDAP interface; if you wanted to stuff data in an LDAP directory somewhere, you'd have to use an alternate interface. - J<