From List-Managers-Owner Wed Sep 1 08:15:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02360; Wed, 1 Sep 93 08:15:40 GMT Received: from CS.UWindsor.Ca (csgate.lamf.uwindsor.ca) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02353; Wed, 1 Sep 93 01:15:32 PDT Received: by CS.UWindsor.Ca (4.1/SMI-DDN) id AA07846; Wed, 1 Sep 93 04:16:51 EDT Date: Tue, 31 Aug 1993 17:19:35 -0400 From: "F. Scott Ophof" Subject: Re: Tuning sendmail? Message-Id: <930831.171935-0400@MReXX-0.18> To: List-Managers@GreatCircle.COM In-Reply-To: Your message of Mon, 30 Aug 1993 21:58:10 +0200 Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk On Mon, 30 Aug 1993 21:58:10 +0200 Eric Thomas said: >On Mon, 30 Aug 1993 16:01:25 EDT "Michael H. Morse" said: I said: >>> Actually, I'm rather shocked that this imho rather obvious solution >>> hasn't yet been suggested and implemented in the Internet world. Will >>> someone please prove me wrong in some way?!? >>The problem was solved long ago. It's called news. Please, let's stay with the subject, which I think was considering possibilities to reduce the time/resources needed to deliver items to subscribers. >LISTSERV has had a working solution to the problem of "large" lists since >1987 This (ie. DISTRIBUTE) is what I was actually referring to. I do hope to see it made use of; it's been proven to work, and the RFC is freely available from the usual sources. I would certainly like to see any valid reasons AGAINST using those concepts. The whole problem is of course two-sided: 1: Time/resources used delivering an item to where the recipients can access it. 2: Time/resources used by the recipient to access & read an item. The only way I see to reduce (2) is to deliver items meant for multiple recipients at the same site to a common mbox and give those recipients common read/copy access (and delete the item when all relevant recipients have tagged an item as deletable). But probably more work than it's worth. Maybe solutions from the Netnews world could be useful here? As to (1), would I be correct in assuming that it's already S.O.P. for MLMs in the Internet world to have the MTA at the recipient's site do the local fan-out if there is more than 1 local recipient? Regards. $$\ From List-Managers-Owner Wed Sep 1 18:40:03 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03884; Wed, 1 Sep 93 18:40:03 GMT Received: from note2.nsf.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03872; Wed, 1 Sep 93 11:39:36 PDT Received: from z.nsf.gov by Note2.nsf.gov id aa04205; 1 Sep 93 9:03 EDT Received: by z.nsf.gov (4.1/SMI-4.1) id AA05357; Wed, 1 Sep 93 09:07:13 EDT Message-Id: <9309011307.AA05357@z.nsf.gov> From: "Michael H. Morse" Date: Wed, 1 Sep 1993 09:07:12 EDT In-Reply-To: "F. Scott Ophof" "Re: Tuning sendmail?" (Aug 31, 5:19pm) X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: "F. Scott Ophof" , List-Managers@GreatCircle.COM Subject: Re: Tuning sendmail? Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk > This (ie. DISTRIBUTE) is what I was actually referring to. > I do hope to see it made use of; it's been proven to work, and the > RFC is freely available from the usual sources. I would certainly > like to see any valid reasons AGAINST using those concepts. I've read RFC 1429, and it basically says that Listserv has a more efficient way of sending mail than sendmail, so if you want to send mail efficiently, here's a way to get Listserv to do it for you. You *do* need to find a friendly Listserv host that will agree to that, but, in my experience, that shouldn't be to hard. Heck, they'll probably offer to run your list for you! The additional efficiency comes from Listserv having information about network topology (even of the Internet(!)), and, presumably, a list of friendly sites that can be used to redistribute messages. There is no detailed information in the rfc about exactly how Listserv accomplishes its efficiency, nor references to other documents or rfc's. I don't see any reason why a list manager wouldn't want to use DISTRIBUTE, except that they just don't. I, for example, don't like being dependent on another site for a critical computer resource. I'd have to maintain contact with them, follow their plans for upgrades, downtime, etc. Management might change, and the new folks might not be so friendly. Also, it doesn't matter to me, given my list, whether it takes 15 minutes (Distribute) or 2 hours (sendmail) to complete the mailing. Again, this is just for my site, and my lists. I can certainly see how others might feel differently. If you are suggesting that Internet sites use a similar protocol for efficient delivery, I would suggest that that is a great idea, but the information on the protocol is not in the RFC. (BTW, I apologize for the crack about news. However, I do believe that the existance of news on the Internet has been a factor in the lack of solution to mailing list problems. It just takes some of the urgency away from the problem. But I should have been more descriptive in my post.) > The whole problem is of course two-sided: > 1: Time/resources used delivering an item to where the recipients > can access it. > 2: Time/resources used by the recipient to access & read an item. You left out the main reason we're using MLM's in the first place: mailing list administrator time. I am much more concerned about that than computer time/resources. > As to (1), would I be correct in assuming that it's already S.O.P. > for MLMs in the Internet world to have the MTA at the recipient's > site do the local fan-out if there is more than 1 local recipient? I defer to the sendmail experts on this one, but I doubt that it is S.O.P. The reason is that it's pretty hard to do. You have to analyze all the addresses to decide which ones are to be delivered to the same hosts, then sort them by host, and attempt delivery. If delivery fails, what do you do? Some of the addresses might have alternate mail exchangers, some might not. Nonetheless, I know that some sendmail's do attempt to do this, and certainly MMDF does. I just don't know how widely these are used. Sendmail experts please feel free to correct me, I'm also interested in the answer. --Mike From List-Managers-Owner Thu Sep 2 19:17:05 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08236; Thu, 2 Sep 93 19:17:05 GMT Received: from sws1.CTD.ORNL.GOV by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08229; Thu, 2 Sep 93 12:16:47 PDT Received: by sws1.CTD.ORNL.GOV (5.65/DEC-Ultrix/4.3) id AA14160; Thu, 2 Sep 1993 15:19:03 -0400 Date: Thu, 2 Sep 1993 15:19:03 -0400 From: Dave Sill Message-Id: <9309021919.AA14160@sws1.CTD.ORNL.GOV> To: List-Managers@GreatCircle.COM Subject: Another sendmail problem Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk OK, I hacked my "resend" to send the message out through a script that splits the list into bite-sized pieces. The goal, from the "Tuning sendmail" thread, was to improve turnaround time. In the script, I invoke sendmail as follows: /usr/lib/sendmail -odi -oep -oi -f $1 $i Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08252; Thu, 2 Sep 93 19:19:35 GMT Received: from sws1.CTD.ORNL.GOV by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08245; Thu, 2 Sep 93 12:19:20 PDT Received: by sws1.CTD.ORNL.GOV (5.65/DEC-Ultrix/4.3) id AA14243; Thu, 2 Sep 1993 15:21:39 -0400 Date: Thu, 2 Sep 1993 15:21:39 -0400 From: Dave Sill Message-Id: <9309021921.AA14243@sws1.CTD.ORNL.GOV> To: List-Managers@GreatCircle.COM Subject: Another sendmail problem Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk I wrote: > /usr/lib/sendmail -odi -oep -oi -f $1 $i >where $1 is the pseudo-address of the resender, $i is a file >containing a piece of the list, and /tmp/aom$$ is the message. I forgot to mention that $i is also a local alias that does an include on the $i file. -- Dave Sill (de5@ornl.gov) Computers should work the way beginners Martin Marietta Energy Systems expect them to, and one day they will. Workstation Support -- Ted Nelson From List-Managers-Owner Thu Sep 2 22:27:58 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08676; Thu, 2 Sep 93 22:27:58 GMT Received: from CS.UWindsor.Ca ([137.207.192.3]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08669; Thu, 2 Sep 93 15:27:43 PDT Received: by CS.UWindsor.Ca (4.1/SMI-DDN) id AA11160; Thu, 2 Sep 93 18:29:06 EDT Date: Wed, 1 Sep 1993 21:03:41 -0400 From: "F. Scott Ophof" Subject: Re: Tuning sendmail? Message-Id: <930901.210341-0400@MReXX-0.20> To: List-Managers@GreatCircle.COM In-Reply-To: Your message of Wed, 1 Sep 1993 09:07:12 EDT Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk On Wed, 1 Sep 1993 09:07:12 EDT Michael H. Morse said: (in reply to F. Scott Ophof) >I've read RFC 1429, and it basically says that Listserv has a more >... >probably offer to run your list for you! The additional efficiency >comes from Listserv having information about network topology (even of >the Internet(!)), and, presumably, a list of friendly sites that can be >used to redistribute messages. I don't know exactly how LISTSERV does it either, but applied what I've heard & read to what I know of the Internet. Like that "list of friendly sites" could be likened to the basic structure of a network within a network (what else are the Internet and Usenet anyway?), all running MLMs which can understand each other and where the relevant personnel have come to some agreement with each other for mutual support. >I don't see any reason why a list manager wouldn't want to use >DISTRIBUTE, except that they just don't. I, for example, don't like >being dependent on another site for a critical computer resource. I'd >have to maintain contact with them, follow their plans for upgrades, >downtime, etc. Management might change, and the new folks might not be >so friendly. Re your points above: Those have been taken into consideration with Revised LISTSERV. Otherwise the LISTSERV network wouldn't run as smoothly as it does. Like downtime being much more critical in a daisychained network; one needed to have alternative routes to ensure reasonable service even if an important node went down (for whatever reason). Dependancy on other sites in the current Internet is *much* less a factor than in a daisychained network. Take for example the REXX mailing list; it's spread across something like at least 6 hosts world-wide, and they all work together to service their respective "areas". Downtime at 1 or more of the hosts delays only their parts of the list, not of the whole list. Upgrading of the MLM software is done centrally, by the implementor. He sends out the patches/fixes/upgrades/etc. as they are needed. You might want to ask on LSTSRV-L what it takes to maintain a Revised LISTSERV. Betcha that you don't need to be a system guru like for most Unix MLMs (though of course the more you know, the easier it is). Feel free to change the source. But do realise you're on your own then and don't expect support if something breaks. On the other hand, suggest the change on LSTSRV-L, and you're likely to get a better, even more useful, more solid patch/mod, and all other LISTSERVs will get it too. Maintaining contact in such a network of instances of MLMs is just as easy as here on List-Managers. And one doesn't get a copy of Revised LISTSERV oneself; it is sent to you on receipt by the implementor of some agreement you, he, and the LISTSERV network enter into. I'm rather vague on the details here, but it works something like that. For exact stuff write Eric Thomas, LSTSRV-L, or anyone you know who runs a Revised LISTSERV. > Also, it doesn't matter to me, given my list, whether it >takes 15 minutes (Distribute) or 2 hours (sendmail) to complete the >mailing. Again, this is just for my site, and my lists. I can >certainly see how others might feel differently. Yes indeed; imho it certainly matters. I personally can accept 3 hours turnaround in a daisychained network working with 4800/9600 line speeds. But in the current Internet structure? No way. In fact, with network speeds of Mbits and higher, I find it rather intolerable that a loop (for 500 subscribers) of setting up a connection with another site, sending the item, & closing it should take more than about 5, max. 10 minutes. And it should be even less if intelligent distribution/load-sharing is implemented. >If you are suggesting that Internet sites use a similar protocol for >efficient delivery, I would suggest that that is a great idea, but the >information on the protocol is not in the RFC. That is indeed what I suggest. Anyone interested will undoubtedly get in touch with the author, Eric Thomas. I haven't read the RFC in detail, but I imagine that it will give enough hints to develop useful ideas from those hints if Eric prefers to keep implementation details to himself. (please see further on re my daydream...) >(BTW, I apologize for the crack about news. Erm.. I was also rather sarcastic in my original posting, though mixed with honest amazement. >However, I do believe that the existance of news on the Internet >has been a factor in the lack of solution to mailing list problems. >It just takes some of the urgency away from the problem. The way I see it, MLMs could benefit from solutions used in Netnews, and vice-versa. And various MLMs from each other. Of course my hope is that various MLM authors start working together to create a DAMNED GOOD MLM, *so* much better & more solid than all others that it will emerge as the state of the art, *the* standard. (OK, accuse me again of daydreaming out loud... :-) ) >> The whole problem is of course two-sided: >> 1: Time/resources used delivering an item to where the recipients >> can access it. >> 2: Time/resources used by the recipient to access & read an item. >You left out the main reason we're using MLM's in the first place: >mailing list administrator time. I am much more concerned about that >than computer time/resources. You mean that Netnews-admin time is even more? The time I meant was wall-clock time and how it affects the subscriber, not computer time. Administration of a list or an MLM should NOT cost much time either, agreed. Running a mailing list via Revised LISTSERV would not cost its owner a lot of time, and heesh need not be a VM/CMS expert. I have been offered the chance to run a list on a Unix MLM, but prefer to decline, having heared the level of Unix knowledge it takes to run such a list. Besides continuous frustration, I'd forever be bugging the maintainer of the MLM and y'all for info you consider standard knowledge. Please see this as an indication that running a list should be made MUCH easier for the prospective list owner. If that is already so difficult for just a list-owner, then I can extrapolate to what an MLM-maintainer must do & know, and suggest the same make-it-easier for those people; as you say, it is a valid concern. [Defer delivery to multiple recipients to the MTA at that site] >I defer to the sendmail experts on this one, but I doubt that it is >S.O.P. The reason is that it's pretty hard to do. You have to >analyze all the addresses to decide which ones are to be delivered to >the same hosts, then sort them by host, and attempt delivery. This analysis & sorting need not be done for each and every item to be distributed, but only when the list of subscribers changes, right? And maybe also build in some intelligence to take care of changes to the hosts? >If delivery fails, what do you do? Some of the addresses might have >alternate mail exchangers, some might not. If "deferred delivery" fails, then so would normal delivery, right? So with all the error-headers and addrs present in most items, I would think that that MTA should be able to inform the originating MLM of the failure? >just don't know how widely these are used. Sendmail experts please >feel free to correct me, I'm also interested in the answer. Hey bud, wait your turn! I'm much more likely to make mistakes than you are, so I "deserve" to be corrected/flamed first... (grin) To summarize a private reply, "sendmail" bundles up messages intended for multiple recipients on the same host and delivers only a single copy with multiple recipients. Also something about "sendmail" being able to detect when different hosts have a common set of MX records, but maybe only with version 8.? Regards. (donning asbestos suit...) $$\ From List-Managers-Owner Mon Sep 20 00:31:20 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13741; Mon, 20 Sep 93 06:38:44 GMT Received: from KENTVM.KENT.EDU ([131.123.1.8]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13734; Sun, 19 Sep 93 23:38:32 PDT Message-Id: <9309200638.AA13734@mycroft.GreatCircle.COM> Received: from KENTVM.KENT.EDU by KENTVM.KENT.EDU (IBM VM SMTP V2R2) with BSMTP id 6900; Sun, 19 Sep 93 22:30:33 EST Received: from KENTVM (NJE origin DKOVACS@KENTVM) by KENTVM.KENT.EDU (LMail V1.1d/1.7f) with BSMTP id 2195; Sun, 19 Sep 1993 22:30:32 -0500 Date: Sun, 19 Sep 93 22:30:16 EST From: Diane Kovacs Subject: Directory of Scholarly Electronic Conferences, 7th Revision Release To: INFO-FUTURES@ENCORE.com, IPCT-L%GUVM.bitnet@KENTVM.KENT.EDU, LIST-MANAGERS@GreatCircle.COM, L-OHACAD%AKRONVM.bitnet@KENTVM.KENT.EDU, LSTOWN-L%INDYCMS.bitnet@KENTVM.KENT.EDU, NETSCOUT%VMTECMEX.bitnet@KENTVM.KENT.EDU, NREN-DISC@PSI.com, OWNERSHIP@CNI.ORG, PLEARN-L%UBVM.bitnet@KENTVM.KENT.EDU, PUBNET@CHINACAT.UNI.com.com, REDALC%FRMOP11.bitnet@KENTVM.KENT.EDU Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk The 7th Revision of the _Directory of Scholarly Electronic Conferences_ is now available on the LISTSERV@KENTVM or LISTSERV@KENTVM.KENT.EDU and via anonymous FTP to ksuvxa.kent.edu in the library directory. This announcement is extracted from the ACADLIST README file ***************** This directory contains descriptions of electronic conferences (e-conferences) on topics of interest to scholars. E-conference is the umbrella term that includes Bitnet and Internet discussion lists, Internet interest groups, Usenet newsgroups, distributions for e-journals, e- newsletters, electronic fora, etc. We have used our own judgment in deciding what is of scholarly interest, and will consider any advice or critique about our decisions. ******** The Files Available ******** ACADLIST README (explanatory notes for the Directory) ACADSTAC HQX (binhexed, self-decompressing, HYPERCARD version of the Directory - Keyword searchable) 498 ACADSMAL HQX (the above only smaller for small screen Macs) ACADLIST FILE1 (Anthropology- Education) 85 k ACADLIST FILE2 (Geography-Library and Information Science) 115k ACADLIST FILE3 (Linguistics-Political Science) 64k ACADLIST FILE4 (Psychology-Writing) 68k ACADLIST FILE5 (Biological Sciences) 55k ACADLIST FILE6 (Physical Sciences) 51k ACADLIST FILE7 (Business, Academia, News) 31k ACADLIST FILE8 (Computer Science; Social, Cultural, and Political Aspects of Computing; and Academic Computing Support) 139k ACADLIST CHANGES (Listing of all deleted e-conferences deleted because they no longer function) *********** How to retrieve files from the LISTSERV@KENTVM or LISTSERV@KENTVM.KENT.EDU *********** 1. Send an e-mail message addressed to LISTSERV@KENTVM or LISTSERV@KENTVM.KENT.EDU. 2. Leave the subject and other info lines blank. 3. The message must read: GET Filename Filetype f=mail (e.g., ACADLIST FILE1 or ACADSTAC HQX or whatever) 4. If you need assistance receiving, etc. contact your local Computer Services people *********** How to retreive files via anonymous FTP to KSUVXA.KENT.EDU *********** 1. type: ftp KSUVXA.KENT.EDU at your dollar sign prompt (VAX) your shell prompt (Unix) or ready screen (IBM VM). If you are on another kind of system consult with your computer services people to find out the proper procedure. 2. when prompted for 'USERID,' type ANONYMOUS. 3. Your password will be your actual userid on your local machine. 4. Type: cd library 5. Type: get Filename.Filetype (e.g., ACADLIST FILE1 or ACADSTAC HQX or whatever) 6. The files will be transferred directly into the directory you ftp'ed from. ******** The Directory Team: ******** Diane Kovacs-Editor-in-Chief (Bitnet) dkovacs@kentvm (Internet) dkovacs@kentvm.kent.edu Laura Bartolo (Bitnet) lbartolo@kentvm (Internet) lbartolo@kentvm.kent.edu Gladys Bell (Bitnet) gbell@kentvm (Internet) gbell@kentvm.kent.edu Paul Fehrmann (Bitnet) pfehrman@kentvm (Internet) pfehrman@kentvm.kent.edu Michael Kovacs (Internet) mkovacs@mcs.kent.edu Leslie Haas (Bitnet) lhaas@kentvm (Internet) lhaas@kentvm.kent.edu Jeannie Langendorfer (Bitnet) jlangend@kentvm (Internet) jlangend@kentvm.kent.edu Amey Park (Bitnet) apark@kentvm (Internet) apark@kentvm.kent.edu Kara Robinson (Bitnet) krobinso@kentvm (Internet) krobinso@kentvm.kent.edu From List-Managers-Owner Mon Sep 27 04:57:00 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA27957; Mon, 27 Sep 93 04:57:00 GMT Received: from KENTVM.KENT.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA27810; Sun, 26 Sep 93 20:05:13 PDT Message-Id: <9309270305.AA27810@mycroft.GreatCircle.COM> Received: from KENTVM.KENT.EDU by KENTVM.KENT.EDU (IBM VM SMTP V2R2) with BSMTP id 1723; Sun, 26 Sep 93 23:05:32 EST Received: from KENTVM (NJE origin DKOVACS@KENTVM) by KENTVM.KENT.EDU (LMail V1.1d/1.7f) with BSMTP id 6220; Sun, 26 Sep 1993 22:59:49 -0500 Date: Sun, 26 Sep 93 22:57:59 EST From: Diane Kovacs Subject: Call for Papers: Gender and Computing To: AFRICANA%WMVM1.bitnet@KENTVM.KENT.EDU, ANN-LOTS%NDSUVM1.bitnet@KENTVM.KENT.EDU, ARACHNET%UOTTAWA.bitnet@KENTVM.KENT.EDU, CNI-COPYRIGHT@CNI.ORG, CNI-LEGISLATION@CNI.ORG, CNI-MANAGEMENT@CNI.ORG, CNI-MODERNIZATION@CNI.ORG, CNI-PUBINFO@CNI.ORG, CNI-TRANSFORMATION@CNI.ORG, COM-PRIV@PSI.com, COMP-ACADEMIC-FREEDOM-TALK@EFF.ORG, comP-PRIVACY@PICA.ARMY.MIL, comp-Soc@LIMBO.INTUITIVE.com, CONFER-L%NCSUVM.bitnet@KENTVM.KENT.EDU, CPSR%GWUVM.bitnet@KENTVM.KENT.EDU, DERIV@CNI.ORG, ETHCSE-L@UTKVM1.UTK.EDU, EUEARN-L%UBVM.bitnet@KENTVM.KENT.EDU, GNET@DHVX20.CSUDH.EDU, HELPNET%NDSUVM1.bitnet@KENTVM.KENT.EDU, RESOURSES@CNI.ORG, RISKS@CSL.SRI.com, SHOTHC-L%SIVM.bitnet@KENTVM.KENT.EDU, SOFTPATS@UVMVM.UVM.EDU, SUEARN-L%UBVM.bitnet@KENTVM.KENT.EDU, TECHNOLOGY-TRANSFER-LIST@SEI.CMU.EDU, TELE.com-PRIV@PICA.ARMY.MIL, UG-L%BITNIC.bitnet@KENTVM.KENT.EDU, INFO-FUTURES@ENCORE.com, IPCT-L%GUVM.bitnet@KENTVM.KENT.EDU, LIST-MANAGERS@GreatCircle.COM, L-OHACAD%AKRONVM.bitnet@KENTVM.KENT.EDU, LSTOWN-L%INDYCMS.bitnet@KENTVM.KENT.EDU, NETSCOUT%VMTECMEX.bitnet@KENTVM.KENT.EDU, NREN-DISC@PSI.com, OWNERSHIP@CNI.ORG, PLEARN-L%UBVM.bitnet@KENTVM.KENT.EDU, PUBNET@CHINACAT.UNI.com.com, REDALC%FRMOP11.bitnet@KENTVM.KENT.EDU, educom-w%bitnic.bitnet@KENTVM.KENT.EDU Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk CALL FOR ARTICLES EJVC: ELECTRONIC JOURNAL ON VIRTUAL CULTURE ----------------------------------------------------------------- Special Issue: Gender Issues in Computer Networking Issue Editor: Leslie Regan Shade McGill University Graduate Program in Communications (czsl@musica.mcgill.ca; shade@well.sf.ca.us) EJVC is a new peer-reviewed electronic journal dedicated to scholarly research and discussion of all aspects of computer- mediated human experience, behavior, action, and interaction. This special issue of the EJVC will be devoted to gender issues in networking. Despite the abundance of various private networks and the meteoric growth of the Internet,this rapidly expanding user base does not include an equal proportion of men and women. How can women become equally represented in the new "electronic frontier" of cyberspace? Issues to be discussed can include, but are not limited to, the following: *Access issues--to hardware, software, and training. What barriers do women face? What are some success stories? *How can women be given the technical expertise to become comfortable and versatile with computer networking? *Interface design: can there be a feminist design? *How can networking realize its potential as a feminist tool? *How can woman scholars exploit networking's technology? *What information technology policies could be developed to ensure computer networking equity for women, as well as minorities? *How does one define computer pornography and "offensive" material on the net? Should it be allowed? *How should sexual harassment on the net be treated? *Are women-only groups necessary? *How do women interact on MUDS and MOOs? *What net resources exist for women? Deadlines: December 1, 1993 submission of abstracts April 1, 1994 submission of contributions Abstracts will be reviewed by the issue editor for appropriate- ness of content and overall balance of the issue as a whole. In turn, authors will then be invited to submit full-length contributions, which will be peer-reviewed by the journal's normal editorial process before final acceptance for publication. The issue editor encourages correspondence about proposed contributions even before submission of an abstract. Potential contributors may obtain a more detailed statement about the focus and range of this special issue by sending electronic mail to the issue editor with the Subject line: EJVC Issue or by anonymous ftp to byrd.mu.wvnet.edu, directory /pub/ejvc, get ejvc.shade.call. Further information about EJVC may be obtained by sending e-mail to LISTSERV@KENTVM.BITNET or LISTSERV@KENTVM.KENT.EDU with one or more of the following lines in the text: SUBSCRIBE EJVC-L YourFirst LastName GET EJVC WELCOME INDEX EJVC-L Also, the file is available by anonymous ftp to byrd.mu.wvnet.edu in the pub/ejvc directory. From List-Managers-Owner Tue Sep 28 07:14:00 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA03744; Tue, 28 Sep 93 14:00:40 GMT Received: from sws1.ctd.ornl.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA03325; Tue, 28 Sep 93 04:48:54 PDT Received: by sws1.ctd.ornl.gov (5.65/DEC-Ultrix/4.3) id AA20126; Tue, 28 Sep 1993 07:51:04 -0400 Date: Tue, 28 Sep 1993 07:51:04 -0400 From: Dave Sill Message-Id: <9309281151.AA20126@sws1.ctd.ornl.gov> To: list-managers@GreatCircle.COM Subject: setting up a "bounces" list Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk I've set up a list called "bounces" to which I subscribe members of other mailing lists to whom mail bounces. I'm using Majordomo, and have the following aliases: bounces: :include:/usr/local/mail/lists/bounces owner-bounces: /dev/null bounces-owner: /dev/null bounces-approval: de5 bounces-request: "|/usr/local/mail/majordomo/wrapper request-recording bounces" And the following crontab entry: 1 2 * * * /usr/ucb/mail -s "Bounces list" bounces Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA05293; Wed, 29 Sep 93 01:19:14 GMT Received: from ora.com (ruby.ora.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA04409; Tue, 28 Sep 93 09:48:01 PDT Received: from rubble.west.ora.com by ora.com (5.65c/Spike-2.1) id AA14005; Tue, 28 Sep 1993 12:50:59 -0400 Received: by rubble.west.ora.com (4.1/SMI-4.1+JP-2.5) id AA08010; Tue, 28 Sep 93 09:51:03 PDT From: Jerry Peek Reply-To: jerry@ora.com X-Mailer: MH 6.8 To: Dave Sill Cc: list-managers@GreatCircle.COM Subject: Re: setting up a "bounces" list In-Reply-To: Message from Dave Sill of "Tue, 28 Sep 1993 07:51:04 -0400." <9309281151.AA20126@sws1.ctd.ornl.gov> Date: Tue, 28 Sep 1993 09:51:00 -0700 Message-Id: <8009.749235060@rubble.west.ora.com> Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk > I've set up a list called "bounces" to which I subscribe members of > other mailing lists to whom mail bounces. ... > Everything works OK, except I'm still getting bounces returned to > root. How can stop that? I run ours from the personal crontab file of the "nobody" user. Because "nobody" is aliased to /dev/null in our aliases file, all the bounces are nuked. Even broken mailers that return errors to the "From:" address send to /dev/null. Works great. If you don't have per-user crontabs, run the command from the root crontab with: su nobody -c '/usr/ucb/...' The only problem with running as "nobody" is that errors during mailing are also nuked (sent to "nobody"). For instance, if the list file is missing, I won't hear about it. So I pipe the stdout and stderr of that crontab entry to another mail command. In your case it'd look something like: > 1 2 * * * (/usr/ucb/mail -s "Bounces list" bounces &1 | /usr/ucb/mail -s "bounces mailing output" de5 Running the command in a subshell, with (), catches errors from the < redirection. You get an empty mail message every day, but that helps you know that this beast is running. You can keep it quiet by adding a temp file and a 'test -s' command, but this is getting pretty long already.. :) -- Jerry Peek, O'Reilly & Associates, jerry@ora.com, +1 707-829-0515 From List-Managers-Owner Thu Sep 30 00:10:13 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA11108; Thu, 30 Sep 93 00:10:13 GMT Received: from cgl.ucsf.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA11101; Wed, 29 Sep 93 17:10:03 PDT Received: from ccnext.ucsf.EDU by cgl.ucsf.EDU (5.65/GSC4.22) id AA02844 for List-Managers@greatcircle.com; Wed, 29 Sep 93 17:13:13 -0700 Received: by ccnext.ucsf.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA06279; Wed, 29 Sep 93 17:12:59 PDT Date: Wed, 29 Sep 93 17:12:59 PDT From: owner@ccnext.ucsf.edu (Richard Karpinski) Message-Id: <9309300012.AA06279@ccnext.ucsf.edu> To: List-Managers@GreatCircle.COM Subject: Permissions problem? Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk Since my first list seemed to work fine, I went right ahead with the second, but this one seems to have a problem. Here is an example of the result of trying to post something to emed-l, followed by all the details that I suspect might be at fault. The complaint that the wrapper needs to be recompiled with POSIX flags seems wrong to me since the other list works fine. Symptoms: zReceived: by itsa.ucsf.EDU (AIX 3.2/UCB 5.64/GSC4.22) id AA57952; Tue, 28 Sep 1993 09:30:06 -0700 Date: Tue, 28 Sep 1993 09:30:25 -0700 From: postmaster (Mail Delivery Subsystem) Subject: Returned mail: unknown mailer error 4 Message-Id: <9309281630.AA57952@itsa.ucsf.EDU> To: owner-emed-l ----- Transcript of session follows ----- /u1/NOT/m/majordom/bin/wrapper: error: recompile with POSIX flags. 554 "|/u1/NOT/m/majordom/bin/wrapper resend -p bulk -M 10000 -l emed-l -f emed-l-Owner -h itsa.ucsf.edu -s emed-l-outgoing"... unknown mailer error 4 ----- Unsent message follows ----- Received: by itsa.ucsf.EDU (AIX 3.2/UCB 5.64/GSC4.22) id AA25673; Tue, 28 Sep 1993 09:30:11 -0700 Date: Tue, 28 Sep 1993 09:30:11 -0700 From: calaham (Michael Callaham) Message-Id: <9309281630.AA25673@itsa.ucsf.EDU> To: emed-l@itsa.ucsf.edu Subject: testing callaham test If i send a message "who emed-l" to majordomo, nothing is sent back. Any clues???? ++++++++++ Here is the set of aliases for the list: # Majordomo aliases majordomo: "|/u1/NOT/m/majordom/bin/wrapper majordomo" majordomo-owner: dick owner-majordomo: dick # emed-l mailing list (medical students for choice) emed-l: "|/u1/NOT/m/majordom/bin/wrapper resend -p bulk -M 10000 -l emed-l -f e" owner-emed-l: emed-l-owner emed-l-outgoing: :include:/u1/NOT/m/majordom/lists/emed-l, emed-l-archive owner-emed-l-outgoing: emed-l-owner emed-l-archive: /u1/NOT/m/majordom/archives/emed-l owner-emed-l-archive: emed-l-owner emed-l-request: "|/u1/NOT/m/majordom/bin/wrapper request-answer emed-l" owner-emed-l-request: emed-l-owner emed-l-approval: cbarton emed-l-owner: cbarton owner-emed-l-owner: dick ++++++++++ Here are the files themselves: drwxrwsr-x 2 majordom majordom 512 Sep 23 17:32 ./ drwxr-xr-x 11 majordom majordom 512 Sep 29 16:47 ../ -rw-rw-r-- 1 majordom majordom 75 Sep 28 11:43 emed-l -rw-rw-r-- 1 majordom majordom 295 Sep 23 16:26 emed-l.info -rw-rw-r-- 3 majordom majordom 203 Sep 23 16:08 emed-l.open -rw--w---- 1 majordom majordom 9 Sep 23 16:23 emed-l.passwd drwxrwxr-x 2 majordom majordom 512 Sep 23 21:41 ./ drwxr-xr-x 11 majordom majordom 512 Sep 29 16:47 ../ -rw-rw-r-- 1 majordom majordom 1375 Sep 28 00:36 emed-l +++++++++++ And finally the configuration file: # revised 6 Sep 93 by R. Karpinski # $whereami -- What machine am I running on? $whereami = "itsa.ucsf.edu"; # $whoami -- Who do users send requests to me as? $whoami = "majordom@$whereami"; # $whoami_owner -- Who is the owner of the above, in case of problems? $whoami_owner = "dick@ccnext.ucsf.edu"; # $homedir -- Where can I find my extra .pl files, like majordomo.pl, # shlock.pl, and majordomo_version.pl? $homedir = "/u1/NOT/m/majordom/bin"; # $listdir -- Where are the mailing lists? $listdir = "/u1/NOT/m/majordom/lists"; # $log -- Where do I write my log? $log = "/u1/NOT/m/majordom/Logs"; # $mailer -- What program and args do I use to send mail? $mailer = "/usr/lib/sendmail -f\$sender \$to"; # Majordomo will look for "get" and "index" files related to $list in # directory "$filedir/$list$filedir_suffix", so set $filedir and # $filedir_suffix appropriately. For instance, to look in # /usr/local/mail/files/$list, use: # $filedir = "/usr/local/mail/files"; # $filedir_suffix = ""; # empty string # or to look in $listdir/$list.archive, use: # $filedir = "$listdir"; # $filedir_suffix = ".archive"; $filedir = "/u1/NOT/m/majordom/archives"; $filedir_suffix = ""; # What command should I use to process an "index" request? $index_command = "/bin/ls -lRL"; # If you want to use FTPMAIL, rather than local access, for file transfer # and access, define the following: # $ftpmail_address = "ftpmail@decwrl.dec.com"; # $ftpmail_location = "FTP.$whereami"; # $Header: /mycroft/brent/majordomo/RCS/sample.cf,v 1.4 1993/09/03 05:35:47 bre$ +++++++++++ Anybody have a hint for me about how to fix this? Dick Dick Karpinski Minicomputer Manager, UCSF Information Technology Services Domain: dick@ccnext.ucsf.edu FAX: (415) 476-5523 (415) 476-4529 (10-6) BITNET: dick@ucsfvm (510) 658-6803 (Home) USPS: Box 0704 UCSF, San Francisco, CA 94143-0704 (510) 658-3797 (ans) From List-Managers-Owner Thu Sep 30 00:21:34 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA11142; Thu, 30 Sep 93 00:21:34 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA11134; Wed, 29 Sep 93 17:21:21 PDT Message-Id: <9309300021.AA11134@mycroft.GreatCircle.COM> To: owner@ccnext.ucsf.edu (Richard Karpinski) Cc: List-Managers@GreatCircle.COM Subject: Re: Permissions problem? In-Reply-To: Your message of Wed, 29 Sep 93 17:12:59 PDT Date: Wed, 29 Sep 1993 17:21:20 -0700 From: Brent Chapman Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk owner@ccnext.ucsf.edu (Richard Karpinski) writes: # # Since my first list seemed to work fine, I went right ahead with the # second, but this one seems to have a problem. Here is an example of # the result of trying to post something to emed-l, followed by all the # details that I suspect might be at fault. The complaint that the # wrapper needs to be recompiled with POSIX flags seems wrong to me since # the other list works fine. This is totally Majordomo-specific, and therefore should be dealt with on Majordomo-Users rather than List-Managers. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From List-Managers-Owner Thu Sep 30 13:48:26 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12955; Thu, 30 Sep 93 13:48:26 GMT Received: from KENTVM.KENT.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12948; Thu, 30 Sep 93 06:48:15 PDT Message-Id: <9309301348.AA12948@mycroft.GreatCircle.COM> Received: from KENTVM.KENT.EDU by KENTVM.KENT.EDU (IBM VM SMTP V2R2) with BSMTP id 2793; Thu, 30 Sep 93 09:48:46 EST Received: from KENTVM (NJE origin DKOVACS@KENTVM) by KENTVM.KENT.EDU (LMail V1.1d/1.7f) with BSMTP id 7045; Wed, 29 Sep 1993 21:18:51 -0500 Date: Wed, 29 Sep 93 21:18:09 EST From: Diane Kovacs Subject: GOPHER link to _Directory of Scholarly Electronic Conferences_ To: INFO-FUTURES@ENCORE.com, IPCT-L%GUVM.bitnet@KENTVM.KENT.EDU, LIST-MANAGERS@GreatCircle.COM, L-OHACAD%AKRONVM.bitnet@KENTVM.KENT.EDU, LSTOWN-L%INDYCMS.bitnet@KENTVM.KENT.EDU, NETSCOUT%VMTECMEX.bitnet@KENTVM.KENT.EDU, NREN-DISC@PSI.com, OWNERSHIP@CNI.ORG, PLEARN-L%UBVM.bitnet@KENTVM.KENT.EDU, PUBNET@CHINACAT.UNI.com.com, REDALC%FRMOP11.bitnet@KENTVM.KENT.EDU, pubnet@chinacat.com Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk Please feel free to add Gopher to the list of ways one can retrieve The _Directory of Scholarly Electronic Conferences_ Type=1 Name=Directory of Scholarly Electronic Conferences Path=1/Computing/Internet Information/Directory of Scholarly Electronic Conferences Host=gopher.usask.ca Port=70 -- Earl Fogel Computing Services phone: (306) 966-4861 University of Saskatchewan email: earl.fogel@usask.ca