From List-Managers-Owner Mon Nov 1 03:04:10 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA08074; Mon, 1 Nov 93 10:22:40 GMT Received: from dcs.ed.ac.uk (stroma.dcs.ed.ac.uk) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA08066; Mon, 1 Nov 93 02:22:23 PST Received: from vacsay.dcs.ed.ac.uk by dcs.ed.ac.uk id aa06103; 1 Nov 93 10:14 GMT Date: Mon, 1 Nov 93 10:14:28 GMT Message-Id: <16020.9311011014@vacsay.dcs.ed.ac.uk> From: "Morna.Findlay" Subject: Re: List Managers Digest V2 #96 To: List-Managers@GreatCircle.com, List-Managers-Digest@GreatCircle.com In-Reply-To: List-Managers-Digest-Owner@GreatCircle.com's message of Sat, 30 Oct 93 01:10:05 PDT Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk >In the past we have used simple files and /etc/aliases for list maintenance. > > We have found that hierarchical list structures, where one list includes > other lists, were valuable (examples discussed below). If these were all > kept on one machine, then sendmail would do the nice thing of removing > duplicate addresses for those people subscribed to multiple included lists. > > It would also remove duplicates when people cross posted to multiple lists > on the same machine. > > ** Can I ask how others deal with this issue? If at all? Using MMDF and majordomo, I also have lots of hierarchical lists. MMDf will strip out duplicate addresses *as long as they are expanded at the same level of the tree*. I can't say if your software might do the same, but it might be worth a look. i.e list "blob" contains names "mary", "jim" and list "plop" list "plop" contains "mary" "fred" and "alison". One message send to "blob@dcs.ed.ac.uk" is processes into two by the mmdf list channel - msg.a1 is delivered to "mary", "jim" and "plop" msg.a2 is delivered to "mary, "fred" and "alison" each msg will only be deliverd to each address once - so if you can arrange the likely groups so that they are expanded by the list channel *at the same level* then you can arrange this. This may mean that you need to put in a "dummy" list sometimes. M From List-Managers-Owner Sun Nov 7 23:53:30 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA16571; Sun, 7 Nov 93 23:53:30 GMT Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA16561; Sun, 7 Nov 93 15:53:25 PST Received: from longs.lance.colostate.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01000; Thu, 4 Nov 93 00:08:19 PST Received: from parry.lance.colostate.edu by longs.lance.colostate.edu (5.65/lance.1.5) id AA08479; Thu, 4 Nov 93 01:07:43 -0700 Message-Id: <9311040807.AA08479@longs.lance.colostate.edu> To: list-managers@greatcircle.com Cc: ld231782@longs.lance.colostate.edu Subject: automated protocol for mailing list tracking Date: Thu, 04 Nov 93 01:07:42 -0700 From: "L. Detweiler" X-Mts: smtp Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk hello, I'm not a subscriber here but found the address from an associate, and I'm hoping to toss in an idea that people here might be able to implement. it seems to me there is a very large fragmentation of the databases that track mailing lists, those that exist are incomplete, overlapping, or hand updated, and that the opportunity is *ripe* for a single coherent database tracking all the public mailing lists in existence on the internet. what I imagine is something along the lines of the Archie protocol where servers and daemons take care of automatically updating a database of all the mailing lists out there, and anyone can search it as a unified system. toward this end, I propose developing a standard email query protocol whereby the databases could send a message to a mailing list address and automatically get an update as to the status of that mailing list, including the critical information like the subscription address, the type of the list (majordomo vs. listserv etc.), possibly the number of subscribers, the average daily traffic, the description, etc. This would be useful for sites that are mail list servers handling many lists and are continually adding new lists. also, of course it should be possible for operators to just send a message in standard syntax to the server and update entries on their own lists. It seems to me there is a *tremendous* explosion of internet mailing lists, that is going to become even *more* enlarged, and many lists are not even publicly tracked, and a lot of people are missing out on valuable lists that interest them, for no other reason than they are hard to locate. A publicly searchable database entailing standardized protocols across all mailing lists would be *extremely* useful. thanks for your attention. please forward this message anywhere it might be of interest. From List-Managers-Owner Sun Nov 7 17:15:30 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA16758; Mon, 8 Nov 93 00:03:47 GMT Received: from hawkwind.utcs.toronto.edu (hawkwind.utcs.utoronto.ca) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA16750; Sun, 7 Nov 93 16:03:39 PST Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <32818>; Sun, 7 Nov 1993 19:03:40 -0500 To: "L. Detweiler" Cc: list-managers@GreatCircle.COM Subject: Re: automated protocol for mailing list tracking In-Reply-To: ld231782's message of Thu, 04 Nov 1993 03:07:42 -0500. <9311040807.AA08479@longs.lance.colostate.edu> Date: Sun, 7 Nov 1993 19:03:31 -0500 From: Chris Siebenmann Message-Id: <93Nov7.190340est.32818@hawkwind.utcs.toronto.edu> Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk It is worth remembering that one of the reasons Archie has been so widely successful is precisely because it does /not/ require service operators to make any changes to their software and configuration. I think that this is a lesson people planning other indexing services would do well to consider. - cks From List-Managers-Owner Mon Nov 8 04:10:47 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18534; Mon, 8 Nov 93 04:10:47 GMT Received: from cc-server4.massey.ac.nz by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18526; Sun, 7 Nov 93 20:10:34 PST Received: from smee.massey.ac.nz by cc-server4.massey.ac.nz (5.64+IDA-1.3.1) id AA13898; Mon, 8 Nov 93 17:10:21 +1300 Date: Mon, 8 Nov 93 17:10:21 +1300 Received: from SMEE/MAILQUEUE by smee.massey.ac.nz (Mercury 1.1); Mon, 8 Nov 93 17:10:19 GMT+12 Received: from [130.123.3.69] by smee.massey.ac.nz (Mercury 1.1); Mon, 8 Nov 93 17:10:11 GMT+12 To: LIST-MANAGERS@GREATCIRCLE.COM From: D.Viehland@massey.ac.nz X-Sender: DViehlan@smee.massey.ac.nz Subject: Description of List Parameters Message-Id: <8114D4616A@smee.massey.ac.nz> Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk I am setting up a new list and I am unable to find my description of list parameters (eg what the example listed below means). Can someone please advise me where I can find a definition of each parameter (eg, Ack, Confidential, Files, etc) and what are my options under each parameter (eg, public, private, yes, no, etc). Seems to me I had a listserver command file on this from BITNIC, but can't find my copy and it would be outdated anyway. Thanks for your help. Dennis * Ack= Yes Notebook= No * Confidential= NO Reply-To= Viehland@massey.ac.nz * Files= Yes Review= Public * Stats= Normal,Private * Notify= Yes Send= Editor * Subscription= By_owner Errors-To= Viehland@massey.ac.nz * X-Tags= Yes Validate= Store only From List-Managers-Owner Mon Nov 8 14:55:59 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA20297; Mon, 8 Nov 93 14:55:59 GMT Received: from note2.nsf.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA20289; Mon, 8 Nov 93 06:55:45 PST Received: from z.nsf.gov by Note2.nsf.gov id aa01679; 8 Nov 93 8:41 EST Received: by z.nsf.gov (4.1/SMI-4.1) id AA02972; Mon, 8 Nov 93 08:45:36 EST Message-Id: <9311081345.AA02972@z.nsf.gov> From: "Michael H. Morse" Date: Mon, 8 Nov 1993 08:45:36 EST In-Reply-To: Chris Siebenmann "Re: automated protocol for mailing list tracking" (Nov 7, 7:03pm) X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Chris Siebenmann , "L. Detweiler" Subject: Re: automated protocol for mailing list tracking Cc: list-managers@greatcircle.com Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk > It is worth remembering that one of the reasons Archie has been so > widely successful is precisely because it does /not/ require service > operators to make any changes to their software and configuration. I > think that this is a lesson people planning other indexing services > would do well to consider. I think that even the Archie creators are recognizing its weaknesses, and are calling for something similar to what was proposed here. The main problem with Archie is that you can't find something unless you know what you are looking for. A project to solve this is called the Bunyip Internet Directory project and involves administrators setting up informative files, in a specific structure, in their anonymous FTP directories. I realize that some (maybe many) sites that run mailing lists don't also offer anonymous FTP, but presumably most have the capability. I don't think the project is perfect (certainly the documentation could be improved) but it seems reasonable, and has the blessing of the IETF (Internet Engineering Task Force). It is fairly well thought out, takes into account the needs of site administrators (and their limited time for stuff like this). I think we should support it because it holds the promise of a standardized way to advertise, index, search and discover Internet resources, of all types, not just mailing lists. For more info, write to templates-info@bunyip.com --Mike From List-Managers-Owner Mon Nov 8 15:33:52 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA20515; Mon, 8 Nov 93 15:33:52 GMT Received: from cheviot.ncl.ac.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA20507; Mon, 8 Nov 93 07:33:00 PST Received: from pow (pow.ncl.ac.uk) by cheviot.ncl.ac.uk id (5.65cVUW/NCL-CMA.1.35 for ) with SMTP; Mon, 8 Nov 1993 15:32:59 GMT From: John Martin Message-Id: Subject: Re: automated protocol for mailing list tracking To: ld231782@longs.lance.colostate.edu (L. Detweiler) Date: Mon, 8 Nov 1993 15:32:57 +0000 (GMT) Cc: list-managers@GreatCircle.COM, ld231782@longs.lance.colostate.edu In-Reply-To: <9311040807.AA08479@longs.lance.colostate.edu> from "L. Detweiler" at Nov 4, 93 01:07:42 am Organisation: NISP Mailbase (TM) Address: Computing Service, University of Newcastle, Newcastle upon Tyne NE1 7RU, UK Phone: +44 91 222 8087 (voice) +44 91 222 8765 (fax) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1427 Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk Hi, Re: > toward this end, I propose developing a standard email query protocol > whereby the databases could send a message to a mailing list address > and automatically get an update as to the status of that mailing list, > including the critical information like the subscription address, the > type of the list (majordomo vs. listserv etc.), possibly the number of > subscribers, the average daily traffic, the description, etc. This > would be useful for sites that are mail list servers handling many > lists and are continually adding new lists. I too have been considering writing such a mailing-list-archie type searcher. All of the methods I have looked at involve the person running the host doing something and that is the immediate downfall. (The one I settled on was writing suitable extensions to publicly available Sendmail implementations to support an extended-SMTP command 'LISTS' - or such like - in accordance with RFC1425.) You might also want to look at the following - though my understanding is that it is compiled using templates. (There is no polling of remote machines for info). This is compiled by Diane Kovacs and is sometimes referred to as the Kovacs list of lists. (via gopher) Name='Directory of Scholarly Electronic Conferences' Host=gopher.usask.ca Path='1/Computing/Internet Information/Directory of Scholarly Electronic Conferences' Regards, John -- AKA: postmaster@mailbase.ac.uk From List-Managers-Owner Mon Nov 8 16:45:06 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA20909; Mon, 8 Nov 93 16:45:06 GMT Received: from MIT.EDU (MIT.MIT.EDU) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA20619; Mon, 8 Nov 93 08:14:18 PST Received: from TQM.MIT.EDU by MIT.EDU with SMTP id AA00854; Mon, 8 Nov 93 11:13:53 EST Message-Id: <9311081613.AA00854@MIT.EDU> Date: Mon, 8 Nov 1993 11:14:04 -0500 To: List-Managers@GreatCircle.COM From: mlbarrow@MIT.EDU Subject: Sendmail security... Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk I haven't seen anything about this on this list and I figured that you all might want to know.... From: CERT Advisory Date: Thu, 4 Nov 93 21:47:47 EST To: cert-advisory@cert.org Subject: CERT ADVISORY - Sendmail Vulnerability Organization: Computer Emergency Response Team : 412-268-7090 ============================================================================ = CA-93:16 CERT Advisory November 4, 1993 Sendmail Vulnerability ---------------------------------------------------------------------------- - The CERT Coordination Center is working on eliminating a vulnerability in sendmail(8). This vulnerability potentially affects all systems running sendmail. CERT is working with the vendor community to address this vulnerability. At this time, there are no known patches available for any vendor implementation that fully address this vulnerability. Until there is complete vendor information, CERT recommends that all implementations of sendmail be considered susceptible. This advisory supersedes the sendmail portion of the CERT advisory (CA-93:15) of October 21, 1993. CERT will continue to work with the vendors and will alert the community when patches become available. Included with this advisory is an appendix describing tips that can be used by system administrators who are concerned about the possible exploitation of this vulnerability at their site. ---------------------------------------------------------------------------- - I. Description A vulnerability exists in most versions of sendmail that allows unauthorized remote or local users to execute programs as any system user other than root. This vulnerability affects the final destination sendmail host and can be exploited through an intermediate mail machine. Therefore, all sendmail recipient machines within a domain are potentially vulnerable. II. Impact Anyone (remote or local) can execute programs on the affected hosts as any userid other than root. III. Approaches CERT suggests three possible approaches to this problem. Although these approaches address all known aspects of this vulnerability, they are suggested only until vendor patches for this sendmail vulnerability are available. Familiarity with sendmail and its installation and configuration, is recommended before implementing these modifications. In order to protect your entire site it is necessary to apply the selected approach to *ALL* systems running sendmail at the site, and not just the mail hub. A. Approach 1 This approach involves modifying the sendmail configuration to restrict the sendmail program mailer facility. To restrict sendmail's program mailer facility, obtain and install the sendmail restricted shell program (smrsh 1.2) by Eric Allman (the original author of sendmail), following the directions included with the program. 1. Where to obtain the program Copies of this program may be obtained via anonymous FTP from info.cert.org, in the /pub/tools/smrsh directory, or via anonymous FTP from ftp.uu.net in the /pub/security/smrsh directory. Checksum information: BSD Sum 30114 5 README 25757 2 smrsh.8 46786 5 smrsh.c System V Sum 56478 10 README 42281 4 smrsh.8 65517 9 smrsh.c MD5 Checksum MD5 (README) = fc4cf266288511099e44b664806a5594 MD5 (smrsh.8) = 35aeefba9714f251a3610c7b1714e355 MD5 (smrsh.c) = d4822ce7c273fc8b93c68e39ec67739c 2. Impacts of this approach While this approach allows a site to specify which programs can be run by sendmail (e.g. vacation(1)), attempts to invoke programs that are not included in the allowed set, or attempts using shell meta-characters (see smrsh program listing for a complete set of disallowed characters), will fail, resulting in log output to the syslog(3) facility. Programs that are specified in a site's /etc/aliases file should be considered for inclusion in the allowable program list. Since .forward files allow user-specified programs to be run by sendmail, a survey of the contents of the system's .forward files may be required to prevent failure to deliver user mail. *** WARNING *************************************************** * It is very important that sites *NOT* include interpreter * * programs (e.g. /bin/sh, /bin/csh, /bin/perl, /bin/uudecode, * * /bin/sed, ...) in the list of allowed programs. * *************************************************************** B. Approach 2 Like approach 1, this approach involves modifying the sendmail configuration. However, this approach completely disables the sendmail program mailer facility. This is a drastic, but quick action that can be taken while a site installs one of the other suggestions. Before implementing this approach, save a copy of the current sendmail configuration file. To implement this approach edit the sendmail.cf file: change from: Mprog, P=/bin/sh, F=slFDM, S=10, R=20, A=sh -c $u to: Mprog, P=/bin/false, F=, S=10, R=20, A= Any changes to the sendmail.cf file will require that the sendmail process be restarted to ensure that the new configuration is used. See item 3 in Appendix A for more details. 1. Impacts of this approach Attempts to invoke programs through sendmail will not be successful. C. Approach 3 To the best of our knowledge, Eric Allman's public domain implementation of sendmail, sendmail 8.6.4, does not appear to be susceptible to this vulnerability. A working solution would then be to replace a site's sendmail, with sendmail 8.6.4. 1. Where to obtain the program Copies of this version of sendmail may be obtained via anonymous FTP from ftp.cs.berkeley.edu in the /ucb/sendmail directory. Checksum information: BSD Sum sendmail.8.6.4.base.tar.Z: 07718 428 sendmail.8.6.4.cf.tar.Z: 28004 179 sendmail.8.6.4.misc.tar.Z: 57299 102 sendmail.8.6.4.xdoc.tar.Z: 33954 251 System V Sum 64609 856 sendmail.8.6.4.base.tar.Z 42112 357 sendmail.8.6.4.cf.tar.Z 8101 203 sendmail.8.6.4.misc.tar.Z 50037 502 sendmail.8.6.4.xdoc.tar.Z MD5 Checksum MD5 (sendmail.8.6.4.base.tar.Z) = 59727f2f99b0e47a74d804f7ff654621 MD5 (sendmail.8.6.4.cf.tar.Z) = cb7ab7751fb8b45167758e9485878f6f MD5 (sendmail.8.6.4.misc.tar.Z) = 8eaa6fbe9e9226667f719af0c1bde755 MD5 (sendmail.8.6.4.xdoc.tar.Z) = a9da24e504832f21a3069dc2151870e6 2. Impacts of this workaround Depending upon the currently installed sendmail program, switching to a different sendmail may require significant effort for the system administrator to become familiar with the new program. The site's sendmail configuration file may require considerable modification in order to provide existing functionality. In some cases, the site's sendmail configuration file may be incompatible with the sendmail 8.6.4 configuration file. --------------------------------------------------------------------------- The CERT Coordination Center wishes to thank the members of the following response teams for their assistance in analyzing and testing both the problem and the solutions: SERT, ASSIST, CIAC, and DFN-CERT. CERT would especially like to thank Eric Allman, Matt Blaze, Andy Sherman, Gene Spafford, Tim Seaver, and many others who have provided technical assistance with this effort. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in Forum of Incident Response and Security Teams (FIRST). Internet E-mail: cert@cert.org Telephone: 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Past advisories, information about FIRST representatives, and other information related to computer security are available via anonymous FTP from info.cert.org. Appendix A This appendix describes tips that can be used by system administrators who are concerned about the possible exploitation of this vulnerability at their site. There are two actions that can be taken by system administrators to try to detect the exploitation of this vulnerability at their sites. - Examine all bounced mail to look for unusual occurrences. - Examine syslog files for unusual occurrences of "|" characters In order to do this, sendmail must be configured to direct bounced mail to the postmaster (or other designated person who will examine the bounced mail). Sendmail must also be configured to provide adequate logging. 1) To direct bounced mail to the postmaster, place the following entry in the options part of the general configuration information section of the sendmail.cf file. # Cc my postmaster on error replies I generate OPpostmaster 2) To set sendmail's logging level, place the following entry in the options part of the general configuration information section of the sendmail.cf file. Note that the logging level should be 9 or higher in order to provide adequate logging. # log level OL9 3) Once changes have been made in the sendmail configuration file, it will be necessary to kill all existing sendmail processes, refreeze the configuration file (if needed - see the note below), and restart the sendmail program. Here is an example from SunOS 4.1.2: As root: # /usr/bin/ps -aux | /usr/bin/grep sendmail root 130 0.0 0.0 168 0 ? IW Oct 2 0:10 /usr/lib/sendmail -bd -q # /bin/kill -9 130 (kill the current sendmail process) # /usr/lib/sendmail -bz (create the configuration freeze file) # /usr/lib/sendmail -bd -q30m (run the sendmail daemon) **Note: Some sites do not use frozen configuration files and some do. If your site is using frozen configuration files, there will be a file named sendmail.fc in the same directory as the sendmail configuration file (sendmail.cf). From List-Managers-Owner Mon Nov 8 17:02:53 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA21005; Mon, 8 Nov 93 17:02:53 GMT Received: from hawkwind.utcs.toronto.edu (hawkwind.utcs.utoronto.ca) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA20987; Mon, 8 Nov 93 09:02:32 PST Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <32819>; Mon, 8 Nov 1993 12:02:24 -0500 To: List-Managers@GreatCircle.COM Subject: Re: Sendmail security... In-Reply-To: mlbarrow's message of Mon, 08 Nov 1993 11:14:04 -0500. <9311081613.AA00854@MIT.EDU> Date: Mon, 8 Nov 1993 12:02:13 -0500 From: Chris Siebenmann Message-Id: <93Nov8.120224est.32819@hawkwind.utcs.toronto.edu> Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk Note that it now appears as if simply installing smrsh isn't good enough. The newsgroup to watch for up to the minute reports (assuming a fast Internet newsfeed) seems to be comp.security.unix. IT'S VERY IMPORTANT THAT YOU TRACK THIS SECURITY PROBLEM! I know of one sample session that's been posted and one script that's been fairly widely distributed; crackers are apparently using this hole NOW and the knowledge is spreading rapidly to even casual pokers. - cks From List-Managers-Owner Tue Nov 9 05:16:55 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25159; Tue, 9 Nov 93 05:16:55 GMT Received: from hawkwind.utcs.toronto.edu (hawkwind.utcs.utoronto.ca) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25151; Mon, 8 Nov 93 21:16:43 PST Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <32820>; Tue, 9 Nov 1993 00:16:46 -0500 To: "L. Detweiler" Cc: list-managers@GreatCircle.COM Subject: Re: automated protocol for mailing list tracking In-Reply-To: ld231782's message of Tue, 09 Nov 1993 00:06:03 -0500. <9311090506.AA29623@longs.lance.colostate.edu> Date: Tue, 9 Nov 1993 00:16:44 -0500 From: Chris Siebenmann Message-Id: <93Nov9.001646est.32820@hawkwind.utcs.toronto.edu> Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk Protocols on the Internet seem to succeed best (or only) when they and their support tools are filling a vacuum. Attempting to displace or update existing tools results in strong difficulties; for one thing, one must persuade enough people to do that to make it worthwhile to use the new service. It is my intuition that the version of archie that needs site admins to do work will have at best 1/100th of the entries in the current archie, and perhaps less. Requiring mailing list software maintainers everywhere to upgrade or replace mailing list managers has all of those problems; you are not moving into a vacuum. Indeed, you are moving into the area of tools that many consider critical, and will be justly loath to make major changes to. It is not impossible to do the job now; there are relatively few common mailing list management packages that support index requests in the first place. Merely write a program, like archie, that knows how to send querries and parse the output it gets back. As a bonus, you will learn, from /experience/, what fields and output formats are useful or necessary, and what are not. - cks [on a side note: one cannot simply get an RFC issued. The current RFC approval process requires two independant implementations before the proposal moves from draft to RFC stage. RFCs are not magic wands that will create comforming implementations; RFCs are done with work and sweat.] From List-Managers-Owner Mon Nov 8 21:29:30 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25090; Tue, 9 Nov 93 05:06:28 GMT Received: from longs.lance.colostate.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25060; Mon, 8 Nov 93 21:06:08 PST Received: from parry.lance.colostate.edu by longs.lance.colostate.edu (5.65/lance.1.5) id AA29623; Mon, 8 Nov 93 22:06:06 -0700 Message-Id: <9311090506.AA29623@longs.lance.colostate.edu> To: Chris Siebenmann Cc: "L. Detweiler" , list-managers@GreatCircle.COM Subject: Re: automated protocol for mailing list tracking In-Reply-To: Your message of "Sun, 07 Nov 93 19:03:31 EST." <93Nov7.190340est.32818@hawkwind.utcs.toronto.edu> Date: Mon, 08 Nov 93 22:06:03 -0700 From: "L. Detweiler" X-Mts: smtp Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk > It is worth remembering that one of the reasons Archie has been so >widely successful is precisely because it does /not/ require service >operators to make any changes to their software and configuration. I >think that this is a lesson people planning other indexing services >would do well to consider. Yes, but on the other hand *many* very significant Internet standards started from *scratch* and people implemented them because they were a good idea. I'm definitely in favor of minimizing headaches to everyone involved, but that's the whole point of inventing new protocols, is that the old one's don't cut it -- entirely new areas must be addressed by new protocols. Just to attack your analogy, many people complain about Archie -- `you have to know the exact file name' -- I think there is a wide open opportunity for people to develop a protocol that allows searchable descriptions as well (look at how nonstandardized all the README files are -- gad, people have to hunt just to get an email address of a site maintainer! atrocious!). A more sophisticated system And would assuredly will require some compliance by FTP site operators, but to everyone's ultimate benefit. (I know I brought up Archie in the first place, but you're the one taking the risk in taking me too literally! all good anecdotes have their boundaries!) I think a lot of people are going to look at Archie in the future and see it as a bandaid to some far more powerful systems. After all, there isn't a whole lot of utility from the end-users point of view, who often wishes to search by *category*, *computer model*, etc.--in regular expression searches on filenames. If all the list software already had a standardized way of retrieving descriptions, I wouldn't have written all the paragraphs above. But because they do not, that can be viewed as a deficiency in that layer considering that a higher layer (the `list scanning protocol', any other names out there?) requires slightly different capabilities than those currently offered. (I suppose some forward-thinking list software writers may have considered the possibility of description searches, and if they put in the capability in advance, good for them.) That's the initials RFC -- Request for Conformance. Although, If one group of `list software writers' becomes rather intransigent about adhering to the List Database Protocol (or whatever) there's always the possibility of writing converters to their existing `list formats'. If they don't have a standardize way of querying list descriptions, well, in my opinion they don't exist. By the way, if there has been any other comments on this list, I have missed them, because I'm not on it, and Mr. Siebenmann cc:ed me. If anyone else wants my arrogant opinion, feel free to do the same From List-Managers-Owner@GreatCircle.COM Tue Nov 9 08:25:27 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27016; Tue, 9 Nov 93 08:25:27 GMT Received: from longs.lance.colostate.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27001; Tue, 9 Nov 93 00:25:00 PST Received: from parry.lance.colostate.edu by longs.lance.colostate.edu (5.65/lance.1.5) id AA04781; Tue, 9 Nov 93 01:24:58 -0700 Message-Id: <9311090824.AA04781@longs.lance.colostate.edu> To: Chris Siebenmann Cc: "L. Detweiler" , list-managers@GreatCircle.COM Subject: Re: automated protocol for mailing list tracking In-Reply-To: Your message of "Tue, 09 Nov 93 00:16:44 EST." <93Nov9.001646est.32820@hawkwind.utcs.toronto.edu> Date: Tue, 09 Nov 93 01:24:57 -0700 From: "L. Detweiler" X-Mts: smtp Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk > Protocols on the Internet seem to succeed best (or only) when they >and their support tools are filling a vacuum. Attempting to displace >or update existing tools results in strong difficulties; for one >thing, one must persuade enough people to do that to make it >worthwhile to use the new service. Just as, in my original message, I pointed out the vacuum that the proposed list-searching software would fill. There are tens of thousands of people out there that want to get matched up with their interests. Existing lists are incomplete, haphazard, repetitive, etc. And mailing lists are *far* more valuable than newsgroups. (even the method to find newsgroups is very impoverished and embarassingly unsophisticated -- `grep 'interest' .newsrc) >It is my intuition that the version >of archie that needs site admins to do work will have at best 1/100th >of the entries in the current archie, and perhaps less. Mr. Siebenmann, there always intransigent people who resist progress. But after a certain point the momentum carries them away. With Archie, there is *already* that data out there, and site maintainers are updating it, but it is being *wasted* in some ways because it is not in a useable, uniform form. Since you continue to cling to the analogy, let me extend it to mailing lists -- everyone is currently maintaining descriptions of their mailing lists, but they are all in inconsistent and wildly varying forms. Quick- retrieve a description of all the lists and their moderators you are currently subscribing to. Shouldn't this be *trivial*? Isn't this a *basic* function of any mailing list software? wouldn't it be *simple* to implement the feature? wouldn't it be of *immense benefit* to the people you are supposedly supporting? Why do you oppose it? >It is not impossible to do the job now; there are relatively few >common mailing list management packages that support index requests in >the first place. Merely write a program, like archie, that knows how >to send querries and parse the output it gets back. As a bonus, you >will learn, from /experience/, what fields and output formats are >useful or necessary, and what are not. you misunderstand the whole idea: they do so in a *nonstandard* way that puts an immense burden on anyone that would attempt to undertake such an endeavor. Why do you oppose the standardization of something that should be standardized? where everyone ultimately benefits with a little cooperation and not a lot of labor? This attitude of `someone else should do it' is precisely what is the obstacle to the implementation of brand new protocols. Or, `why do *we* have to deal with this? all we do is write list software.' but, that's the *point*. Frankly, the services that match `people to resources' on the Internet are of UTMOST IMPORTANCE and form one of the most CRITICAL ASPECTS of its FUTURE GROWTH. That is the trend in the popularity of things like Veronica, Archie, Wais, Gopher, etc. I think anyone who is a wet blanket on them will be looked on as rather a self-serving obstacle. Again, I'm somewhat ashamed that these protocols aren't already in place when millions of users desperately *need* them. >[on a side note: one cannot simply get an RFC issued. The current RFC >approval process requires two independant implementations before the >proposal moves from draft to RFC stage. RFCs are not magic wands that >will create comforming implementations; RFCs are done with work and >sweat.] Generally, there is not a strong obstacle to issuing an RFC if there is even a bare smidgeon of interest and cooperation. If that isn't there, then very definitely the RFC is not the route to go! I think others will bear me out on this, but I admit to never having gone through the process personally (and there are many RFCs that have absolutely nothing to do with `implementations' of anything, and are just informative, so I'm not entirely sure what you mean by your statement). From List-Managers-Owner@GreatCircle.COM Tue Nov 9 09:10:30 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27144; Tue, 9 Nov 93 09:10:30 GMT Received: from hawkwind.utcs.toronto.edu (hawkwind.utcs.utoronto.ca) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27132; Tue, 9 Nov 93 01:10:20 PST Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <32823>; Tue, 9 Nov 1993 04:10:18 -0500 To: "L. Detweiler" Cc: list-managers@GreatCircle.COM Subject: Re: automated protocol for mailing list tracking In-Reply-To: ld231782's message of Tue, 09 Nov 1993 03:24:57 -0500. <9311090824.AA04781@longs.lance.colostate.edu> Date: Tue, 9 Nov 1993 04:10:07 -0500 From: Chris Siebenmann Message-Id: <93Nov9.041018est.32823@hawkwind.utcs.toronto.edu> Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk [I will live to regret writing this message.] | Why do you oppose [mail list indexing]? I don't. Now that we've gotten that out of the way, can we stop shouting? (thank you) I think the idea is great. I think the implementation approach you are suggesting is likely to have less than stellar success, and I consider this a pity when with a few small changes it could be made to work much better. | you misunderstand the whole idea: they do so in a *nonstandard* way | that puts an immense burden on anyone that would attempt to | undertake such an endeavor. Quick: is the output from 'dir' in ftp standardized? The answer is no, and in fact archie must work to parse it sensibly. It was, however, possible to do so, and the fact that archie indexing thus required no changes on the ftp sites led to a huge number of them being indexed. The huge number of sites indexed led in turn to widespread use of archie, warts and all. For all its faults, archie is a lot better than no archie. No one said writing a mailing list indexer would be /easy/. If it was, someone would already have done it (someone's axiom: "all the easy hacks have already been done"). The history of Internet resource discovery projects seems to convincingly demonstrate that waiting for people to register in some fashion does not work particularly well. If one wishes to have a wide information base, one needs to go out and find it, because it seems that many information sources are operated on a very casual part-time basis. The history of software around the Internet and Usenet (and from measurements I've seen, BITNET as well) seems to convincingly demonstrate that people rarely upgrade software, even when the software doesn't work that well. To install support for a new mailing list indexing protocol, people would have to upgrade software. You are welcome to dispute this, but I think the historical evidence is against you here. [the following will sound nasty:] | Again, I'm somewhat ashamed that these protocols aren't already in | place when millions of users desperately *need* them. Said millions of users seem disinclined to pay for them. For better or worse, money is the best motivator and evidence of sincerity. Indeed, historically it has been very difficult to get funding for Internet resources; see, for example, SIMTEL-20 or Archie itself (both are exceptions in that they have actually survived; smaller information sources go under every day -- for an example of one very useful one that didn't make it, see comp.archives). - cks | (and there are many RFCs that have absolutely nothing to do with | `implementations' of anything, and are just informative, so I'm not | entirely sure what you mean by your statement). As I understand it, 'protocol' RFCs (as opposed to informative RFCs or things like the hosts requirements RFCs) require two independant implementations of the protocol. This serves as a brake on the OSI effect ('standardize first then see if it works'), a brake on unused protocols, and demonstration that the RFC is complete enough to write interoperable implementations from. From List-Managers-Owner@GreatCircle.COM Tue Nov 9 03:07:47 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27249; Tue, 9 Nov 93 09:43:56 GMT Received: from longs.lance.colostate.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27241; Tue, 9 Nov 93 01:43:38 PST Received: from parry.lance.colostate.edu by longs.lance.colostate.edu (5.65/lance.1.5) id AA06059; Tue, 9 Nov 93 02:43:35 -0700 Message-Id: <9311090943.AA06059@longs.lance.colostate.edu> To: Chris Siebenmann Cc: "L. Detweiler" , list-managers@GreatCircle.COM Subject: Re: automated protocol for mailing list tracking In-Reply-To: Your message of "Tue, 09 Nov 93 04:10:07 EST." <93Nov9.041018est.32823@hawkwind.utcs.toronto.edu> Date: Tue, 09 Nov 93 02:43:33 -0700 From: "L. Detweiler" X-Mts: smtp Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk >| Why do you oppose [mail list indexing]? > > I don't. Now that we've gotten that out of the way, can we stop >shouting? (thank you) what, then, are /you/ in favor of doing to /support/ it? >I think the idea is great. I think the implementation approach you >are suggesting is likely to have less than stellar success, and I >consider this a pity when with a few small changes it could be made >to work much better. (I will live to regret writing this ) but... it seems to me, your letters are densely filled with elaborate and complex euphemisms for saying, `you have a great idea but I don't want to do anything personally to help you.' or, `It's not my problem.' or `Its not something mailing-list software writers or maintainers should have to deal with.' (BTW, Mr. Siebenmann, I have to thank you for showing me a neat style of /emphasis/. ) From List-Managers-Owner@GreatCircle.COM Tue Nov 9 13:18:52 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28084; Tue, 9 Nov 93 13:18:52 GMT Received: from cheviot.ncl.ac.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28076; Tue, 9 Nov 93 05:17:50 PST Received: from pow (pow.ncl.ac.uk) by cheviot.ncl.ac.uk id (5.65cVUW/NCL-CMA.1.35 for ) with SMTP; Tue, 9 Nov 1993 13:17:52 GMT From: John Martin Message-Id: Subject: Re: automated protocol for mailing list tracking To: list-managers@GreatCircle.COM Date: Tue, 9 Nov 1993 13:17:49 +0000 (GMT) Organisation: NISP Mailbase (TM) Address: Computing Service, University of Newcastle, Newcastle upon Tyne NE1 7RU, UK Phone: +44 91 222 8087 (voice) +44 91 222 8765 (fax) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 715 Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk You may be interested to know that there is currently at least one RARE Task Force working on a standardised interface to e-mail list servers. My understanding is that there will probably be an IETF one also, in the near future. This will almost certainly result in an RFC on User Interfaces to Mail Based Servers (or something similar) though it should be borne in mind that the last TF broke up through, I think, differences of opinions. I would personally like to pole some opinion among mailing list server *developers* (sorry, not users :-)). I would be grateful if anyone on this list who is a developer would reply to this message so that I can form a list. Cheers, John -- AKA: postmaster@mailbase.ac.uk From List-Managers-Owner@GreatCircle.COM Tue Nov 9 14:42:13 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28451; Tue, 9 Nov 93 14:42:13 GMT Received: from note2.nsf.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28443; Tue, 9 Nov 93 06:41:41 PST Received: from z.nsf.gov by Note2.nsf.gov id aa24454; 9 Nov 93 9:24 EST Received: by z.nsf.gov (4.1/SMI-4.1) id AA03540; Tue, 9 Nov 93 09:28:46 EST Message-Id: <9311091428.AA03540@z.nsf.gov> From: "Michael H. Morse" Date: Tue, 9 Nov 1993 09:28:46 EST In-Reply-To: Chris Siebenmann "Re: automated protocol for mailing list tracking" (Nov 9, 4:10am) X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Chris Siebenmann , "L. Detweiler" Subject: Re: automated protocol for mailing list tracking Cc: list-managers@greatcircle.com Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk > | Why do you oppose [mail list indexing]? > > I don't. Now that we've gotten that out of the way, can we stop > shouting? (thank you) > > I think the idea is great. I think the implementation approach you > are suggesting is likely to have less than stellar success, and I > consider this a pity when with a few small changes it could be made > to work much better. I also agree the implementation approach is unlikely to meet with success. I've watched the major authors of mailing list software, and, to put it mildly, they are an independent bunch, bless their hearts. I also agree that administrators will be loath to upgrade working software for an elusive benefit. For example, we are running Tasos' software version 5.41 (a major version old), but it does all we need, and is very reliable. We have 3,000 addresses on our lists, many of whom depend on the lists running reliably. It's just really hard to justify the time and effort and danger of upgrading. Many, if not most, mailing list administrators are as independent as the software authors. Many feel they owe nothing to anybody, since they are essentially volunteers giving to the community. > No one said writing a mailing list indexer would be /easy/. If it > was, someone would already have done it (someone's axiom: "all the > easy hacks have already been done"). > > The history of Internet resource discovery projects seems to > convincingly demonstrate that waiting for people to register in some > fashion does not work particularly well. If one wishes to have a wide > information base, one needs to go out and find it, because it seems > that many information sources are operated on a very casual part-time > basis. I disagree, partly, with the "one needs to go out and find it" sentence. I think the history of resource discovery projects is enough to make us realize that there has to be a better way. Having all these indexers going around at night and on weekends trying to make sense of a diverse and rapidly growing net is just not scalable and doesn't make sense. That's why I support the Bunyip Internet Directory project. I think folks understand we've gone as far as we can with these automated resource discoverers. It's time to standardize a little at the resource end. If site administrators are offering services to the Internet, it is not too much to ask that they prepare a structured, standardized, description of them. Yes, the indexers will still "go out and find" the stuff, taking most of the work off site administrators, but the site administrators would have control over what was being indexed, and how it was presented. Many of the casual part-time resources *shouldn't* be indexed. Look at the controversy caused by both Archie and Veronica going into sites uninvited, unannounced, and unwelcome. Many system administrators want control of how their service is advertised. > | Again, I'm somewhat ashamed that these protocols aren't already in > | place when millions of users desperately *need* them. I agree with cks that you haven't adequately demonstrated the "desperate need". Since very few individuals directly pay for their Internet access, there is usually a University that instructs, or an organization that employs, each person on the Internet. Presumably, if there was a desperate need, these organizations would realize that their students or employees needs weren't being met, and would be willing to contract for these services. --Mike From List-Managers-Owner@GreatCircle.COM Tue Nov 9 17:15:06 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29394; Tue, 9 Nov 93 17:15:06 GMT Received: from hawkwind.utcs.toronto.edu (hawkwind.utcs.utoronto.ca) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29384; Tue, 9 Nov 93 09:14:47 PST Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <32822>; Tue, 9 Nov 1993 12:14:31 -0500 To: "L. Detweiler" Cc: list-managers@GreatCircle.COM Subject: Re: automated protocol for mailing list tracking In-Reply-To: ld231782's message of Tue, 09 Nov 1993 04:43:33 -0500. <9311090943.AA06059@longs.lance.colostate.edu> Date: Tue, 9 Nov 1993 12:14:20 -0500 From: Chris Siebenmann Message-Id: <93Nov9.121431est.32822@hawkwind.utcs.toronto.edu> Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk | it seems to me, your letters are densely filled with elaborate and | complex euphemisms for saying, `you have a great idea but I don't want | to do anything personally to help you.' or, `It's not my problem.' [...] You'd be wrong. My letters are filled with patient words trying to say 'I don't think this will work as well as you want it to, and here's why.' | what, then, are /you/ in favor of doing to /support/ [mail list | indexing]? Someone writing a mail list indexer that understands majordomo output, listserv output, et al. Start with the Usenet list of mailing lists, and try to find indexers on their machines; expand to BITNET mailing lists; provide a querryable interface. It's probably best to use gopher or WWW as the query interface; people already have clients for them. Publicize it widely. This gives people a proof of concept implementation and some idea of how much demand for such a service there is. This can be used to persuade people to write RFCs, software, and upgrade their software. - cks From List-Managers-Owner@GreatCircle.COM Tue Nov 9 10:07:41 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29837; Tue, 9 Nov 93 17:51:24 GMT Received: from yonge.csri.toronto.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29779; Tue, 9 Nov 93 09:49:44 PST Received: from alias by yonge.csri.toronto.edu with UUCP id <14452>; Tue, 9 Nov 1993 12:49:26 -0500 Received: from dino.alias.com by barney.alias.com with SMTP id AA16888 (5.65a/IDA-1.4.2 for ld231782@longs.lance.colostate.edu); Tue, 9 Nov 93 17:37:46 GMT Received: by dino.alias.com id AA25709 (5.65a/IDA-1.4.2 for list-managers@GreatCircle.COM); Tue, 9 Nov 93 12:37:43 -0500 From: chk@alias.com (C. Harald Koch) Message-Id: <9311091737.AA25709@dino.alias.com> Subject: Re: automated protocol for mailing list tracking To: ld231782@longs.lance.colostate.edu (L. Detweiler) Date: Tue, 9 Nov 1993 12:37:41 -0500 Cc: list-managers@GreatCircle.COM In-Reply-To: <9311090943.AA06059@longs.lance.colostate.edu> from "L. Detweiler" at Nov 9, 93 04:43:33 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1712 Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk > it seems to me, your letters are densely filled with elaborate and > complex euphemisms for saying, `you have a great idea but I don't want > to do anything personally to help you.' or, `It's not my problem.' or > `Its not something mailing-list software writers or maintainers should > have to deal with.' But he's perfectly correct. For example, I'm the mail, network, etc. person for this organization of approximately 200 people. I'm *busy*. I wish I had time to keep up with all the latest releases of even the important software we use. My electronic mail system works just fine for what I need it to do right now. Installing new versions is always a headache; I have to make sure that everything still works in the new version. I don't have time to make changes to my software installation just to make *your* life easier; you don't have anything to do with my paycheques. Having said that, I'm actually the best (of the people I regularly see from other commercial organizaions) at keeping reasonably up-to-date with net software. I'm actually interested in running/using the latest software. Most people, once they get something working, don't want to make any changes until they absolutely have to. I can *want* to help you all I want, but I usually don't have the time or energy to actually do so. The rest of the world is similar. Therefore, any indexing project that requires everyone (or even a significant portion of everyone) to upgrade is doomed to failure. -- C. Harald Koch, Network Analyst | Grandpa Charnock's Law: Alias Research Inc. Toronto, ON | You never really learn to swear until chk@alias.com | you learn to drive. chk@utcc.utoronto.ca | From List-Managers-Owner@GreatCircle.COM Tue Nov 9 20:04:12 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01581; Tue, 9 Nov 93 20:04:12 GMT Received: from chx400.switch.ch by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01573; Tue, 9 Nov 93 12:03:58 PST Received: from maya.netconsult.ch by chx400.switch.ch with SMTP (PP) id <15800-0@chx400.switch.ch>; Tue, 9 Nov 1993 21:03:38 +0100 Received: by netconsult.ch (4.1/SMI-4.1) id AA02122; Tue, 9 Nov 93 21:03:09 GMT From: Paul Klarenberg Message-Id: <9311092103.AA02122@netconsult.ch> Subject: Re: automated protocol for mailing list tracking To: chk@alias.com (C. Harald Koch) Date: Tue, 9 Nov 1993 21:03:09 +0000 (GMT) Cc: ld231782@longs.lance.colostate.edu, list-managers@GreatCircle.COM In-Reply-To: <9311091737.AA25709@dino.alias.com> from "C. Harald Koch" at Nov 9, 93 12:37:41 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1067 Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk Harald Koch writes: > I can *want* to help you all I want, but I usually don't have the time or > energy to actually do so. The rest of the world is similar. Therefore, any > indexing project that requires everyone (or even a significant portion of > everyone) to upgrade is doomed to failure. Hi, I'm actually coordinating the RARE taskforce (list: mbs-user-req@mailbase.ac.uk) that John Martin referred to. This taskforce is primarily user orientated. From this perspective I was wondering: how much time does it take you to explain to users how they can (un)subscribe from mailing lists, get the archives of it, or how to find lists on particular subjects? More generally I'm interested to know about the experiences from the postmasters/responsibles on this list with problems thye encounter that have to do with self operated or external mailing lists. Could anyone interested give me the top-five or so of what take most of your time? I hope to get a real-life impression of what the real (cost) problem is. Results of course go back on this list. Paul. From List-Managers-Owner@GreatCircle.COM Tue Nov 9 22:21:15 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA02766; Tue, 9 Nov 93 22:21:15 GMT Received: from cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA02743; Tue, 9 Nov 93 14:20:06 PST Received: from terminus.cs.umb.edu by cs.umb.edu with SMTP id AA05683 (5.65c/IDA-1.4.4 for ); Tue, 9 Nov 1993 17:19:43 -0500 Message-Id: <199311092219.AA05683@cs.umb.edu> To: Paul Klarenberg Cc: ld231782@longs.lance.colostate.edu, list-managers@greatcircle.com Subject: Re: automated protocol for mailing list tracking In-Reply-To: Your message of "Tue, 09 Nov 1993 21:03:09 GMT." <9311092103.AA02122@netconsult.ch> Date: Tue, 09 Nov 1993 17:19:42 -0500 From: "John P. Rouillard" Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk In message <9311092103.AA02122@netconsult.ch>, Paul Klarenberg writes: > Harald Koch writes: > > > I can *want* to help you all I want, but I usually don't have the > time or > > energy to actually do so. The rest of the world is similar. There > fore, any > > indexing project that requires everyone (or even a significant po > rtion of > > everyone) to upgrade is doomed to failure. > > Hi, I'm actually coordinating the RARE taskforce (list: > mbs-user-req@mailbase.ac.uk) that John Martin referred to. This > taskforce is primarily user orientated. From this perspective I was > wondering: how much time does it take you to explain to users how > they can (un)subscribe from mailing lists, get the archives of it, or > how to find lists on particular subjects? > > More generally I'm interested to know about the experiences from the > postmasters/responsibles on this list with problems thye encounter that > have to do with self operated or external mailing lists. Could anyone > interested give me the top-five or so of what take most of your time? Correcting those that post subscribe requests to the list address rather than the list-request address. I run majordomo that has pretty good help information for get, lists, ssubscribe unsubscribe etc. -- John John Rouillard Special Projects Volunteer University of Massachusetts at Boston rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480 =============================================================================== My employers don't acknowledge my existence much less my opinions. From List-Managers-Owner@GreatCircle.COM Wed Nov 10 01:44:47 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04130; Wed, 10 Nov 93 01:44:47 GMT Received: from lokkur.dexter.mi.us (dexter-gw.dexter.msen.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04113; Tue, 9 Nov 93 17:43:49 PST Received: from localhost (scs@localhost) by lokkur.dexter.mi.us (8.6.4/8.6.4) id TAA08584 for list-managers@greatcircle.com; Tue, 9 Nov 1993 19:53:48 -0500 From: Steve Simmons Message-Id: <199311100053.TAA08584@lokkur.dexter.mi.us> Subject: Re: automated protocol for mailing list tracking To: list-managers@greatcircle.com Date: Tue, 9 Nov 1993 19:52:53 -0500 (EST) Action: gers@GreatCircle.COM In-Reply-To: <9311090824.AA04781@longs.lance.colostate.edu> from "L. Detweiler" at Nov 9, 93 01:24:57 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 958 Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk "Tastes great!" (we *need* this protocol) The idea of a tool that gives the convenience of majordomo with interactive speed is terribly appealing. "Less filling!" (we *don't* need this protocol) The idea of a tool that someone could use to put me on thousands of mailing lists in a few seconds is appalling. In My Humble and No Offense Intended Opinion, this is a matter that could use less talk and more action. If there really is a need and the result really fills it, it's a big win. That's how we got archie, prospero, and a whole host of other things. The first step is to assemble a working group, grab a template RFC from the NIC, and approach the IETF (or is it the IAB? I dunno....) Off the top of my head, I find a lot more negatives (mostly potential for mischief) than positives. Not that there's any less potential for mischief in the present systems, but the turnaround rate is positively glacial compared to an interactive protocol. From List-Managers-Owner@GreatCircle.COM Wed Nov 10 05:52:21 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05641; Wed, 10 Nov 93 05:52:21 GMT Received: from longs.lance.colostate.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05633; Tue, 9 Nov 93 21:52:13 PST Received: from parry.lance.colostate.edu by longs.lance.colostate.edu (5.65/lance.1.5) id AA07531; Tue, 9 Nov 93 22:52:10 -0700 Message-Id: <9311100552.AA07531@longs.lance.colostate.edu> To: list-managers@greatcircle.com Cc: ld231782@longs.lance.colostate.edu Subject: I Surrender Date: Tue, 09 Nov 93 22:52:08 -0700 From: "L. Detweiler" X-Mts: smtp Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk Dear list managers, thank you for your patience with my stark ignorance of the Internet. You have succeeded in convincing me that my idea for indexing mailing lists for the benefit of cyberspatial humanity is superfluous, futile and worthless, not necessarily in that order. "Michael H. Morse" >Many, if not most, mailing list administrators are as independent as >the software authors. Many feel they owe nothing to anybody, since >they are essentially volunteers giving to the community. Somehow, my brain seizes simultaneously on the words `volunteers giving to the community' and `many feel they owe nothing to anybody'. (somehow, I think about this and the spirit of volunteerism that built the current Internet, and I despair.) Once again, Majordomo list maintainers, thank you for allowing me into your fiefdom momentarily. I sympathize with your wretched plight. There is no reason you should contribute to a global list database. Where's the need? What about people who don't want their lists in it? What's the assurance it would work? If it was valuable somebody would have already invented it. And if they didn't, you would have to pay someone some serious $ for anyone to be interested. Why, even upgrading all that free Internet software developed by other volunteers is extremely burdensome, let alone any independent programming. Thanks for convincing me. I think I really will forget it. Let me apologize for unduly troubling anyone with inconvenient new ideas. p.s. Could someone tell me if the Bunyip project intends to be comprehensive for *all* resources, including mail lists? I have not received any information from an address I sent mail to. p.p.s. thank god that mailing lists have walls, and that cyberspace doesn't. From List-Managers-Owner@GreatCircle.COM Wed Nov 10 16:43:22 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09092; Wed, 10 Nov 93 16:43:22 GMT Received: from cs.brown.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09069; Wed, 10 Nov 93 08:43:12 PST Received: from miles.cs.brown.edu by cs.brown.edu (5.64+/Bullwinkle-1.7) id AA26851; Wed, 10 Nov 93 11:43:19 -0500 Received: by miles.cs.brown.edu (5.64+/BrownCS-1.2) id AA20523; Wed, 10 Nov 93 11:43:17 -0500 Date: Wed, 10 Nov 93 11:43:17 -0500 From: rv@cs.brown.edu (rodrigo vanegas) Message-Id: <9311101643.AA20523@miles.cs.brown.edu> To: ld231782@longs.lance.colostate.edu, list-managers@GreatCircle.COM Subject: Re: I Surrender Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk >If it was valuable somebody would have >already invented it. Hasn't it? I believe there is a periodic posting (don't know what group it is posted to) that lists all publicly available mailing lists known to the author and secondary contributors. rodrigo vsnrgsd rv@cs.brown.edu From List-Managers-Owner@GreatCircle.COM Thu Nov 11 00:43:04 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12998; Thu, 11 Nov 93 00:43:04 GMT Received: from note2.nsf.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12990; Wed, 10 Nov 93 16:42:56 PST Received: from z.nsf.gov by Note2.nsf.gov id aa19804; 10 Nov 93 8:07 EST Received: by z.nsf.gov (4.1/SMI-4.1) id AA04448; Wed, 10 Nov 93 08:11:55 EST Message-Id: <9311101311.AA04448@z.nsf.gov> From: "Michael H. Morse" Date: Wed, 10 Nov 1993 08:11:55 EST In-Reply-To: "L. Detweiler" "I Surrender" (Nov 9, 10:52pm) X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: "L. Detweiler" , list-managers@greatcircle.com Subject: Re: I Surrender Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk > Dear list managers, thank you for your patience with my stark ignorance > of the Internet. You have succeeded in convincing me that my idea for > indexing mailing lists for the benefit of cyberspatial humanity is > superfluous, futile and worthless, not necessarily in that order. E-mail discussions are not like face-to-face discussions. You have conversed with, I think, three people out of hundreds of list maintainers. I didn't hear *any* of the software authors. You and one writer, who was sincerely trying to help, got into a flame battle. This is a normal thing in e-mail discussions. My advice: Don't take it personally. Your idea is good, and the goal is shared by many. There are legitimate and sincere differences in implementation strategies. --Mike p.s. Sarcasm and humor don't work well in e-mail, and should be avoided. From List-Managers-Owner@GreatCircle.COM Thu Nov 11 00:53:18 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13145; Thu, 11 Nov 93 00:53:18 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13136; Wed, 10 Nov 93 16:53:03 PST Message-Id: <9311110053.AA13136@mycroft.GreatCircle.COM> To: "Michael H. Morse" Cc: "L. Detweiler" , list-managers@greatcircle.com Subject: Re: I Surrender In-Reply-To: Your message of Wed, 10 Nov 1993 08:11:55 EST Date: Wed, 10 Nov 1993 16:53:02 -0800 From: Brent Chapman Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk "Michael H. Morse" writes: # # > Dear list managers, thank you for your patience with my stark ignorance # > of the Internet. You have succeeded in convincing me that my idea for # > indexing mailing lists for the benefit of cyberspatial humanity is # > superfluous, futile and worthless, not necessarily in that order. # # E-mail discussions are not like face-to-face discussions. You have # conversed with, I think, three people out of hundreds of list # maintainers. I didn't hear *any* of the software authors. You and one # writer, who was sincerely trying to help, got into a flame battle. # This is a normal thing in e-mail discussions. My advice: Don't take # it personally. The mailer software authors are all (well, most of us anyway) busy dealing with this Sendmail security mess, and don't even have time to do more than scan any other mail right now. -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@GreatCircle.COM Thu Nov 11 02:32:13 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14119; Thu, 11 Nov 93 02:32:13 GMT Received: from mentor.cc.purdue.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14111; Wed, 10 Nov 93 18:32:02 PST Received: by mentor.cc.purdue.edu (5.61/Purdue_CC) id AA17010; Wed, 10 Nov 93 21:31:58 -0500 From: jac@mentor.cc.purdue.edu (John Clear) Message-Id: <9311110231.AA17010@mentor.cc.purdue.edu> Subject: Re: I Surrender To: mmorse@z.nsf.gov (Michael H. Morse) Date: Wed, 10 Nov 93 21:31:56 EST Cc: ld231782@longs.lance.colostate.edu, list-managers@GreatCircle.COM In-Reply-To: <9311101311.AA04448@z.nsf.gov>; from "Michael H. Morse" at Nov 10, 93 8:11 am Reply-To: jac@mentor.cc.purdue.edu Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk Previously, Michael H. Morse said: > > > Your idea is good, and the goal is shared by many. There are > legitimate and sincere differences in implementation strategies. > Why not right a stand alone ultility, instead of making it apart of the various mailing list packages? Correct me if I am wrong, I'm new at this, but would it really be that difficult, when creating a new mailing list, to enter the various pieces of info on that list into a program, and then letting that program take care of it? All you would really have to do is cut and paste what you have to type in anyway to get the list set up. I dont see it being really all that difficult, except for all the lists already out there.... John -- John `SpaceCadet` Clear - jac@mentor.cc.purdue.edu, jac@panix.com Vice-President Purdue Daemons; Purdue Pilots, Inc. PP-ASEL C/LTC, CAP-NYW "Aviation is proof, that given the will, we have the capacity to achieve the impossible." -- Eddie Rickenbacker pgp key upon request From List-Managers-Owner@GreatCircle.COM Thu Nov 11 05:42:10 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15087; Thu, 11 Nov 93 05:42:10 GMT Received: from goose.aa.ox.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15080; Wed, 10 Nov 93 21:41:59 PST Received: by goose.aa.ox.com (/\==/\ Smail3.1.22.1 #22.9) id ; Thu, 11 Nov 93 00:42 EST Message-Id: Date: Thu, 11 Nov 93 00:42 EST From: paulh@ox.com (Paul Haas) To: list-managers@GreatCircle.COM Subject: Re: I Surrender Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk Previously, jac@mentor.cc.purdue.edu (John Clear) said: > Why not right a stand alone ultility, instead of making it apart of > the various mailing list packages? Because, it is not necessary. I did a whole 20 minutes of research on this, so you should take everything with a grain of salt or perhaps a saltlick. I queried a couple Majordomo's and a "ListProcessor". First I did: echo help | mail majordomo@greatcircle.com echo help | mail majordomo@[another_site_running_majordomo] echo help | mail listserv@[a_site_running_listserv] As I got the replies back, I checked to make sure that they were what I expected. Then echo lists | mail majordomo@greatcircle.com etc... I parsed what I got back, and thought to myself, I could almost certainly parse these responses with Perl. Note, that I would need different parsing rules for the listserv response, this is ok, Perl has an "if" statement. In practice, I would almost certainly need slightly different parsing rules for different revisions of the mailing list managers. Fortunately, the help replies include the revision number of the mailing list manager. So, this is just more bookkeeping. echo info bounces | mail majordomo@greatcircle.com etc... The info messages are also straight forward to parse. Note, that I was lazy and got one info reply per mail message. This makes parsing the replies slightly easier. So, now I've got this test database of info files. From here it would be easy to stick the database into a Gopher server (if I had one). But, I would want one extra step. I would want to search for a permission string like: "Ok to redistribute this message and subscription info via Gopher." Requiring the permission line, will save a whole lot of political problems. This does force list administrators to update info files if they want their list information propagated, but this is far less work than most of the other proposals. So, who has a Gopher server we can use for this? Any suggestions for other legal permission strings? "if" statements are my friend. My strategy would be to query each "known" server monthly until a permission string is found, then query it daily. Maintaining the list of known servers would be labor intensive, the rest should be relatively automatic. I should note, that even if there is a huge groundswell of support, I'll wait for the system administrators to recover from the sendmail thing before I start anything. -- Paul Haas home: paulh@hamjudo.ox.com work: paulh@ox.com From List-Managers-Owner@GreatCircle.COM Thu Nov 11 21:02:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19319; Thu, 11 Nov 93 21:02:11 GMT Received: from lobby.ti.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19310; Thu, 11 Nov 93 13:02:02 PST Received: from mk1501.dseg.ti.com ([128.247.206.175]) by lobby.ti.com with SMTP (5.65c/LAI-3.2) id AA22103; Thu, 11 Nov 1993 15:02:18 -0600 Received: from skopen.dseg.ti.com by mk1501.dseg.ti.com with SMTP (5.65c/LAI-3.2) id AA03283; Thu, 11 Nov 1993 14:59:35 -0600 Received: by skopen.dseg.ti.com (4.1/SMI-4.1) id AA24297; Thu, 11 Nov 93 14:57:53 CST Date: Thu, 11 Nov 93 14:57:53 CST From: dansmith@skopen.dseg.ti.com (Dan Smith - 575-6017) Message-Id: <9311112057.AA24297@skopen.dseg.ti.com> To: list-managers@greatcircle.com Subject: Help with a mailing list Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk I know this is trivial for you guys, but I am trying to set up a mailing list and I need some help. The list works fine as far as sending everyone all of the messages, but it bounces undeliverable mail back to whoever posts instead of the list administrator (me). Here is what I have in my aliases file to set up the list: testlist:"|/usr/lib/sendmail -oim -ftestlist-request testlist-out" testlist-out: :include:/home/test/testlist.list testlist-request:dansmith@skopen.dseg.ti.com owner-testlist:dansmith@skopen.dseg.ti.com It changes the From: at the top of the messages to testlist-request but mail error messages are still bounced back to the poster. I have noticed in the bounced mail that the Return-path: has the address of the poster. Is there any way to change that? How are mailing lists set up through sendmail so that mail error messages are bounced back to the list administrator only? Thanks for any help you can give me with this. Dan Smith dansmith@skopen.dseg.ti.com From List-Managers-Owner@GreatCircle.COM Fri Nov 12 02:53:06 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA20986; Fri, 12 Nov 93 02:53:06 GMT Received: from cc-server4.massey.ac.nz by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA20979; Thu, 11 Nov 93 18:52:54 PST Received: from smee.massey.ac.nz by cc-server4.massey.ac.nz (5.64+IDA-1.3.1) id AA09176; Fri, 12 Nov 93 15:52:59 +1300 Date: Fri, 12 Nov 93 15:52:59 +1300 Received: from SMEE/MAILQUEUE by smee.massey.ac.nz (Mercury 1.1); Fri, 12 Nov 93 15:52:57 GMT+12 Received: from [130.123.3.69] by smee.massey.ac.nz (Mercury 1.1); Fri, 12 Nov 93 15:52:51 GMT+12 To: LIST-MANAGERS@GreatCircle.COM From: D.Viehland@massey.ac.nz X-Sender: DViehlan@smee.massey.ac.nz Subject: List Parameters (Again) Message-Id: Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk Hello out there...... Earlier this week I posted the following message to list-managers. To my surprise I have not received a response privately nor have I seen a response posted on the list. Can someone help? Please post to the list to share with others. Thanks, Dennis >I am setting up a new list and I am unable to find my description of list >parameters (eg what the example listed below means). Can someone please >advise me where I can find a definition of each parameter (eg, Ack, >Confidential, Files, etc) and what are my options under each parameter (eg, >public, private, yes, no, etc). > >Seems to me I had a listserver command file on this from BITNIC, but can't >find my copy and it would be outdated anyway. > >Thanks for your help. > >Dennis > > > >* Ack= Yes Notebook= No >* Confidential= NO Reply-To= Viehland@massey.ac.nz >* Files= Yes Review= Public >* Stats= Normal,Private >* Notify= Yes Send= Editor >* Subscription= By_owner Errors-To= Viehland@massey.ac.nz >* X-Tags= Yes Validate= Store only * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Dennis W. Viehland D.Viehland@Massey.ac.nz Senior Lecturer (06) 350-4213 Information Systems (06) 350-5233 (messages) Massey University (06) 350-5611 (fax) Palmerston North, New Zealand * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * From List-Managers-Owner@GreatCircle.COM Sat Nov 13 01:27:54 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26384; Sat, 13 Nov 93 01:27:54 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26376; Fri, 12 Nov 93 17:27:41 PST Message-Id: <9311130127.AA26376@mycroft.GreatCircle.COM> To: D.Viehland@massey.ac.nz Cc: LIST-MANAGERS@GreatCircle.COM Subject: Re: List Parameters (Again) In-Reply-To: Your message of Fri, 12 Nov 93 15:52:59 +1300 Date: Fri, 12 Nov 1993 17:27:39 -0800 From: Brent Chapman Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk D.Viehland@massey.ac.nz writes: # Hello out there...... # # Earlier this week I posted the following message to list-managers. To my # surprise I have not received a response privately nor have I seen a # response posted on the list. # # Can someone help? Please post to the list to share with others. List-Managers is for discussing management of mailing lists in general, regardless of the software used. You seem to be asking questions about a particular list management system (i.e., ListProc, or LISTSERV, or Majordomo, or ...), but you don't state which system you're asking about. In any case, such questions are better directed the support list for that specific list management system (for instance, the support list for the Majordomo list management system is Majordomo-Users@GreatCircle.COM). -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@GreatCircle.COM Sun Nov 14 03:34:58 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04943; Sun, 14 Nov 93 11:31:34 GMT Received: from ub-gate.UB.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04926; Sun, 14 Nov 93 03:31:12 PST Received: from bolis.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA18057; Sun, 14 Nov 93 03:22:48 PST Received: by hock.bolis.sf-bay.org (Smail3.1.28.1 #6) id m0oyevK-0002wQC; Sun, 14 Nov 93 02:43 PST Message-Id: From: Alan Millar Subject: Re: List Parameters (Again) To: brent@GreatCircle.COM (Brent Chapman) Date: Sun, 14 Nov 1993 02:43:13 -0800 (PST) Cc: D.Viehland@massey.ac.nz, LIST-MANAGERS@GreatCircle.COM In-Reply-To: <9311130127.AA26376@mycroft.GreatCircle.COM> from "Brent Chapman" at Nov 12, 93 05:27:39 pm Reply-To: Alan Millar X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1186 Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk > D.Viehland@massey.ac.nz writes: > > # Hello out there...... > # > # Earlier this week I posted the following message to list-managers. To my > # surprise I have not received a response privately nor have I seen a > # response posted on the list. > # > # Can someone help? Please post to the list to share with others. > > List-Managers is for discussing management of mailing lists in > general, regardless of the software used. You seem to be asking > questions about a particular list management system (i.e., ListProc, > or LISTSERV, or Majordomo, or ...), but you don't state which system > you're asking about. > > In any case, such questions are better directed the support list for > that specific list management system (for instance, the support list > for the Majordomo list management system is Majordomo-Users@GreatCircle.COM). It looked like a Revised LISTSERV question. I believe that list is lstsrv-l@uga.cc.uga.edu - Alan ---- ,,,, Alan Millar amillar@bolis.SF-Bay.org __oo \ System Administrator =___/ Batteries not included. From List-Managers-Owner@GreatCircle.COM Tue Nov 16 15:32:10 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25236; Tue, 16 Nov 93 15:32:10 GMT Received: from Princeton.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25228; Tue, 16 Nov 93 07:32:02 PST Received: by Princeton.EDU (5.65b/2.103/princeton) id AA18965; Tue, 16 Nov 93 10:10:54 -0500 Received: from localhost by silence.princeton.nj.us (8.6.4/1.101) id JAA26775; Tue, 16 Nov 1993 09:57:25 -0500 Date: Tue, 16 Nov 1993 09:57:25 -0500 From: Jay Plett Message-Id: <199311161457.JAA26775@silence.princeton.nj.us> To: list-managers@greatcircle.com Subject: Sendmail 8.6.4 vs. long lists Reply-To: jay@Princeton.EDU Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk Has anybody fixed the bug in sendmail 8.6.4 which causes it to dump core in syslog(3) on long lists? On a Sun running SunOS 4.1.3, it will happen on a list of about 500 characters to one host. It dumps core while delivering, with the result that the message is delivered but also stays on the queue for resending on the next queue run until you surgically remove it. :-( This was fixed in IDA, so it's a little disappointing to see such an egregious bug remaining in 8.6.4. Has anybody exercised 8.6.4 enough yet to gain confidence that it is ready for the real world? Jay Plett jay@princeton.edu From List-Managers-Owner@GreatCircle.COM Wed Nov 17 00:17:25 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28003; Wed, 17 Nov 93 00:17:25 GMT Received: from Thinkage.On.CA (thinkage.thinkage.on.ca) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27996; Tue, 16 Nov 93 16:17:16 PST Received: from hog.thinkage.on.ca (hog.thinkage.on.ca [192.102.11.6]) by Thinkage.On.CA (8.6.4/Thinkage931115) with ESMTP id TAA08807 for ; Tue, 16 Nov 1993 19:17:13 -0500 Received: by hog.thinkage.on.ca (4.1/SMI/930311-s) id AA22421; Tue, 16 Nov 93 18:53:58 EST Date: Tue, 16 Nov 93 18:53:58 EST From: kgdykes@Thinkage.On.CA (Ken Dykes) Message-Id: <9311162353.AA22421@hog.thinkage.on.ca> To: list-managers@greatcircle.com Subject: Re: Sendmail 8.6.4 vs. long lists Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk >Date: Tue, 16 Nov 1993 09:57:25 -0500 >From: Jay Plett >To: list-managers@GreatCircle.COM >Subject: Sendmail 8.6.4 vs. long lists >Has anybody fixed the bug in sendmail 8.6.4 which causes it to >dump core in syslog(3) on long lists? On a Sun running SunOS >4.1.3, it will happen on a list of about 500 characters to one >host. It dumps core while delivering, with the result that the >message is delivered but also stays on the queue for resending >on the next queue run until you surgically remove it. :-( in the sendmail src/conf.h there is a line #define TOBUFSIZE (1024-256) with a comment along the lines of "tweak this to match your syslog implementation, it will have to allow for the extra information printed" perhaps this is the problem?? - Ken Dykes, Thinkage Ltd., Kitchener, Ontario, Canada [43.47N 80.52W] kgdykes@thinkage.on.ca postmaster@thinkage.com harley-request@thinkage.on.ca {uunet | uunet.ca}!thinkage!kgdykes From List-Managers-Owner@GreatCircle.COM Thu Nov 18 03:36:41 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05513; Thu, 18 Nov 93 11:25:47 GMT Received: from spatula.csv.warwick.ac.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05500; Thu, 18 Nov 93 03:25:33 PST Date: Thu, 18 Nov 1993 11:25:48 GMT Message-Id: <12431.199311181125@spatula.csv.warwick.ac.uk> Received: from localhost by spatula.csv.warwick.ac.uk id LAA12431; Thu, 18 Nov 1993 11:25:48 GMT From: Ian Dickinson In-Reply-To: List-Managers-Digest-Owner@greatcircle.com "List Managers Digest V2 #106" (Nov 17, 1:10am) X-Mailer: Mail User's Shell (7.2.4 2/2/92) To: List-Managers@greatcircle.com Subject: Re: Sendmail 8.6.4 vs. long lists Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk > From: Jay Plett > Date: Tue, 16 Nov 1993 09:57:25 -0500 > Subject: Sendmail 8.6.4 vs. long lists > > Has anybody fixed the bug in sendmail 8.6.4 which causes it to > dump core in syslog(3) on long lists? On a Sun running SunOS > 4.1.3, it will happen on a list of about 500 characters to one > host. It dumps core while delivering, with the result that the > message is delivered but also stays on the queue for resending > on the next queue run until you surgically remove it. :-( I can't even get the thing to run lists at all. We used to use IDA with the UK-Sendmail configuration generator. We want to move to 8.6.4 but the configs fail. Everything works except piping to processes. Was this the fix that makes 8.6.4 safe? Disable the things completely? > This was fixed in IDA, so it's a little disappointing to see > such an egregious bug remaining in 8.6.4. Has anybody exercised > 8.6.4 enough yet to gain confidence that it is ready for the > real world? Indeed. But whilst I'm here - does anyone know of any list-manager independant packages for digestification. Most of the lists I run are simple reflectors using resend. I'd like to plug on a simple method of creating digests of those lists - MIME format if possible. Cheers, -- Ian From List-Managers-Owner@GreatCircle.COM Thu Nov 18 16:15:55 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06348; Thu, 18 Nov 93 16:15:55 GMT Received: from Princeton.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06341; Thu, 18 Nov 93 08:15:47 PST Received: by Princeton.EDU (5.65b/2.103/princeton) id AA03861; Thu, 18 Nov 93 10:42:47 -0500 Received: from localhost by silence.princeton.nj.us (8.6.4/1.101) id KAA09588; Thu, 18 Nov 1993 10:28:10 -0500 Date: Thu, 18 Nov 1993 10:28:10 -0500 From: Jay Plett Message-Id: <199311181528.KAA09588@silence.princeton.nj.us> To: List-Managers@greatcircle.com, vato@csv.warwick.ac.uk Subject: Re: Sendmail 8.6.4 vs. long lists Reply-To: jay@Princeton.EDU Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk > I can't even get the thing to run lists at all. > We used to use IDA with the UK-Sendmail configuration generator. 8.6.4 doesn't pretend to be plug-compatible with IDA. One does need to read the documentation and fix old .cf files. At the very least, options (Ox lines) must be reviewed carefully. If you were using features specific to IDA, you will probably find that they are missing, or need a different config syntax, in 8.6.4. Other than the long-list bug, I have not yet encountered any problems with 8.6.4. After fixing the bug, it does lists just fine. (Of course, I've only been running it for a few days.) I have reported the long-list bug to Allman. I have also done a quick-hack fix which I would be happy to share with anybody who needs it. I made no attempt at portability--I'm running 8.6.4 only on SunOS 4.1.3 and that's all I attempted to deal with. Systems whose syslog implementation allows less than 1024 bytes on a syslog line will need a more careful fix. Also, my fix potentially drops some log information. ...jay From List-Managers-Owner@GreatCircle.COM Thu Nov 18 20:58:42 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07647; Thu, 18 Nov 93 20:58:42 GMT Received: from de5.ctd.ornl.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07640; Thu, 18 Nov 93 12:58:28 PST Received: from localhost (de5@localhost) by de5.ctd.ornl.gov (8.6.4/8.6.4) id PAA07457; Thu, 18 Nov 1993 15:57:56 -0500 Date: Thu, 18 Nov 1993 15:57:56 -0500 From: Dave Sill Message-Id: <199311182057.PAA07457@de5.ctd.ornl.gov> To: Ian Dickinson Cc: List-Managers@GreatCircle.COM Subject: Re: Sendmail 8.6.4 vs. long lists In-Reply-To: <12431.199311181125@spatula.csv.warwick.ac.uk> References: <12431.199311181125@spatula.csv.warwick.ac.uk> Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk >I can't even get the thing [sendmail 8] to run lists at all. >We used to use IDA with the UK-Sendmail configuration generator. >We want to move to 8.6.4 but the configs fail. >Everything works except piping to processes. >Was this the fix that makes 8.6.4 safe? Disable the things >completely? No, we're running sendmail 8 one lot's of systems with mail delivered to majordomo, deliver, mail-to-news gateways, various resends, etc. >> This was fixed in IDA, so it's a little disappointing to see >> such an egregious bug remaining in 8.6.4. Has anybody exercised >> 8.6.4 enough yet to gain confidence that it is ready for the >> real world? > >Indeed. I've been running it since 8.5, back in early October. It's been great. -- 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 URL http://gatekeeper.dec.com/archive/pub/DEC/DECinfo/html/dsill.html From List-Managers-Owner@GreatCircle.COM Fri Nov 19 01:26:24 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA08913; Fri, 19 Nov 93 01:26:24 GMT Received: from skigo.graphics.cornell.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA08906; Thu, 18 Nov 93 17:26:14 PST Received: by skigo.graphics.cornell.edu (5.65/DEC-Ultrix/4.3) id AA19942; Thu, 18 Nov 1993 20:26:30 -0500 Message-Id: <9311190126.AA19942@skigo.graphics.cornell.edu> To: List-Managers@greatcircle.com Subject: Milnet headache for list-managers Date: Thu, 18 Nov 93 20:26:30 -0500 From: Mitch Collinsworth X-Mts: smtp Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk Just received this from a friend. Looks like Milnet wants list managers everywhere to have a group headache someday next year. ------- Forwarded Message Date: Wed, 17 Nov 1993 11:26:56 CST From: William Trefzger To: Multiple recipients of list PACS-L Subject: DISA Announces Plan to Separate DDN from Internet - ----------------------------Original message---------------------------- This is being posted to multiple lists. Please excuse the duplication. Note that the address for comments is: macnabr@cc.ims.disa.mil DISA to Establish Mail Relay Between DoD and the Internet A Defense Information Systems Agency (DISA) representative, Mr. Robert MacNab, announced at the Defense Technical Information Center's Annual Users Training Conference that DISA is planning to move forward with the separation of the DDN from the Internet early in 1994. This separation will be accomplished by the installation of a mail-relay between the DDN and the Internet. Exchange of electronic mail between DoD and Internet users will be allowed. Some accommodation will be required by users to communicate through the new mail- relay. For example: Currently: jones@abc.disa.mil jsmith@def.gsfc.nasa.gov After Mail-Gateway: DoD Users: jones@abc.disa.mil Internet Users: jones%abc.disa.mil@relay.mil DoD Users: smith%def.gsfc.nasa.gov@relay.int Internet Users: smith@def.gsfc.nasa.gov Electronic mail senders must know which network the receiver is on, in order to direct mail through the mail-relay. Network connections (for Telnet, FTP, etc.) from DoD sites into Internet resources will continue to be available to DoD users. However, Internet users will not be allowed to make direct network connections to DoD host computers. Mr. MacNab solicited comments from the user community on how these changes would effect them. His phone number is 703-285-5143 or email address is macnabr@cc.ims.disa.mil. Information Prepared by: Carlynn Thompson Defense Technical Information Center Directorate of Research, Development and Acquisition Information Support Cameron Station Alexandria, VA 22304-6145 Phone: 703-274-3639 Fax: 703-617-7087 Email: cthomps@dgis.dtic.dla.mil ------- End of Forwarded Message From List-Managers-Owner@GreatCircle.COM Fri Nov 19 02:36:14 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09180; Fri, 19 Nov 93 02:36:14 GMT Received: from mozart.aero.ufl.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09173; Thu, 18 Nov 93 18:36:04 PST Received: by mozart.aero.ufl.edu (5.61ufl/4.10) id AA04011; Thu, 18 Nov 93 21:35:55 -0500 Date: Thu, 18 Nov 93 21:35:55 -0500 From: "Mauricio Tavares" Message-Id: <9311190235.AA04011@mozart.aero.ufl.edu> To: List-Managers@GreatCircle.COM Subject: More on handling annoying subscription requests Cc: raubvogel@mozart.aero.ufl.edu Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk I am having problems with my mailing list. A lot of people, besides all my warnings, still send their (un)subscription requests to the mailing list instead of to me, who would then handle those requests. As if that was not enough, there was an user that simply kept sending subscription requests every other day for 3 weeks now. For the record, this very user was added to the list 3 weeks ago. What should I do? How can I filter those (un)subscription requests so to minimize the annoyance to the other users? BTW, the mail list code is written in sh shell (I wrote the beast). Other thing: My code currently does not know whether there is more than one mail list process running at a time (imagine that 2 mails to the list were received almost together). Some codes I saw use a lock file to do that, checking whether the lock file exists before attempting to run. Does anyone know how that is done? From List-Managers-Owner@GreatCircle.COM Fri Nov 19 03:40:30 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09396; Fri, 19 Nov 93 03:40:30 GMT Received: from sws1.ctd.ornl.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09389; Thu, 18 Nov 93 19:40:22 PST Received: from localhost (de5@localhost) by sws1.ctd.ornl.gov (8.6.4/8.6.4) id WAA08676; Thu, 18 Nov 1993 22:40:09 -0500 Date: Thu, 18 Nov 1993 22:40:09 -0500 From: Dave Sill Message-Id: <199311190340.WAA08676@sws1.ctd.ornl.gov> To: Mitch Collinsworth Cc: List-Managers@GreatCircle.COM In-Reply-To: <9311190126.AA19942@skigo.graphics.cornell.edu> Subject: Milnet headache for list-managers Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk >Just received this from a friend. Looks like Milnet wants list managers >everywhere to have a group headache someday next year. Why? It seems pretty easy to rewrite .mil addresses to go through the relay. It's no different than handling .csnet or .bitnet addresses. Of course it's a bit trickier for the Milnet folks since they'll have to handle .com, .edu, .gov, etc. -- 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 URL http://gatekeeper.dec.com/archive/pub/DEC/DECinfo/html/dsill.html From List-Managers-Owner@GreatCircle.COM Fri Nov 19 05:04:34 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09638; Fri, 19 Nov 93 05:04:34 GMT Received: from skigo.graphics.cornell.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09631; Thu, 18 Nov 93 21:04:26 PST Received: by skigo.graphics.cornell.edu (5.65/DEC-Ultrix/4.3) id AA20303; Fri, 19 Nov 1993 00:04:48 -0500 Message-Id: <9311190504.AA20303@skigo.graphics.cornell.edu> To: List-Managers@greatcircle.com Subject: Re: Sendmail 8.6.4 vs. long lists In-Reply-To: Your message of "Thu, 18 Nov 93 10:28:10 EST." <199311181528.KAA09588@silence.princeton.nj.us> Date: Fri, 19 Nov 93 00:04:48 -0500 From: Mitch Collinsworth X-Mts: smtp Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk >I have reported the long-list bug to Allman. I have also done a >quick-hack fix which I would be happy to share with anybody who >needs it. I made no attempt at portability--I'm running 8.6.4 >only on SunOS 4.1.3 and that's all I attempted to deal with. >Systems whose syslog implementation allows less than 1024 bytes >on a syslog line will need a more careful fix. Also, my fix >potentially drops some log information. Just asked Allman himself via the MBone broadcast of his BAY-LISA talk (still going on). He said this bug will be fixed in 8.6.5, which will be out in "probably several weeks". -Mitch From List-Managers-Owner@GreatCircle.COM Fri Nov 19 05:11:57 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09665; Fri, 19 Nov 93 05:11:57 GMT Received: from skigo.graphics.cornell.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09658; Thu, 18 Nov 93 21:11:51 PST Received: by skigo.graphics.cornell.edu (5.65/DEC-Ultrix/4.3) id AA20323; Fri, 19 Nov 1993 00:12:13 -0500 Message-Id: <9311190512.AA20323@skigo.graphics.cornell.edu> To: List-Managers@greatcircle.com Subject: Re: Milnet headache for list-managers In-Reply-To: Your message of "Thu, 18 Nov 93 22:40:09 EST." <199311190340.WAA08676@sws1.ctd.ornl.gov> Date: Fri, 19 Nov 93 00:12:12 -0500 From: Mitch Collinsworth X-Mts: smtp Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk >>Just received this from a friend. Looks like Milnet wants list managers >>everywhere to have a group headache someday next year. > >Why? It seems pretty easy to rewrite .mil addresses to go through >the relay. It's no different than handling .csnet or .bitnet >addresses. Hmm, good point. Didn't think of that. Just change the sendmail config file and leave the lists alone. -Mitch From List-Managers-Owner@GreatCircle.COM Fri Nov 19 02:57:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA10281; Fri, 19 Nov 93 09:51:27 GMT Received: from gateway.morgan.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA10274; Fri, 19 Nov 93 01:51:16 PST Received: from ls5.fid.morgan.com ([138.20.113.10]) by gateway.morgan.com with SMTP id <41392>; Fri, 19 Nov 1993 04:51:05 -0500 Received: from iluvatar.Morgan.COM by ls5.fid.morgan.com (4.1/MS/FID-1.0) id AA06740; Fri, 19 Nov 93 09:50:56 GMT From: dpk@fid.morgan.com (Doug Kingston) Message-Id: <9311190950.ZM24953@iluvatar.fid.morgan.com> Date: Fri, 19 Nov 1993 04:50:55 -0500 In-Reply-To: List-Managers-Digest-Owner@GreatCircle.COM "List Managers Digest V2 #107" (Nov 19, 4:10) References: <9311190910.AA10125@mycroft.GreatCircle.COM> X-Face: &BwlKrS,nawC24`-5)ip}p^e@tDUAuup!:KDh\$|;)'+6Z1#.02U7++zf^k$TV9}.~j_""&U,!K%epaKMB_sn59WR7>!vi'Me_b]wk^-O.L2l$EYAe:+c8DU=R.O`_HKbRkw=8>%(%_l2|LnjpnN,BV~6o4#VdXlcq@OQ~R7% X-Mailer: Z-Mail (3.0B.1026 26oct93) To: List-Managers@GreatCircle.COM, List-Managers-Digest@GreatCircle.COM Subject: Re: List Managers Digest V2 #107 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk Someone needs (or perhaps everyone!) needs to get to this Mr. MacNab soon and tell him about wildcard MX records. This user%host@relay.dom cannot be allowed to go forward. Its an addressing nightmare. Using MX records for this purpose is precisely how virtually every firewall host is currently set up. Inside the Milnet, a similar MX game will solve the problem for Milnet users sending mail out of the Milnet. -Doug- > DISA to Establish Mail Relay Between DoD and the Internet > > A Defense Information Systems Agency (DISA) representative, > Mr. Robert MacNab, announced at the Defense Technical > Information Center's Annual Users Training Conference that > DISA is planning to move forward with the separation of the > DDN from the Internet early in 1994. This separation will be > accomplished by the installation of a mail-relay between the > DDN and the Internet. Exchange of electronic mail between DoD > and Internet users will be allowed. Some accommodation will > be required by users to communicate through the new mail- > relay. For example: > > Currently: jones@abc.disa.mil > jsmith@def.gsfc.nasa.gov > > After Mail-Gateway: > DoD Users: jones@abc.disa.mil > Internet Users: jones%abc.disa.mil@relay.mil > DoD Users: smith%def.gsfc.nasa.gov@relay.int > Internet Users: smith@def.gsfc.nasa.gov > ... > Mr. MacNab solicited comments from the user community on > how these changes would effect them. His phone number is > 703-285-5143 or email address is macnabr@cc.ims.disa.mil. From List-Managers-Owner@GreatCircle.COM Fri Nov 19 12:05:18 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA11086; Fri, 19 Nov 93 12:05:18 GMT Received: from d.ecc.engr.uky.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA11079; Fri, 19 Nov 93 04:05:11 PST Received: from s.ecc.engr.uky.edu by d.ecc.engr.uky.edu (5.59/25-eef) id AA16923; Fri, 19 Nov 93 07:09:45 EST Received: by s.ecc.engr.uky.edu (4.1/SMI-4.1) id AA11204; Fri, 19 Nov 93 07:09:21 EST Date: Fri, 19 Nov 93 07:09:21 EST From: morgan@engr.uky.edu (Wes Morgan) Message-Id: <9311191209.AA11204@s.ecc.engr.uky.edu> To: list-managers@greatcircle.com Subject: Re: MILNET <-> DDN separation Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk > After Mail-Gateway: > DoD Users: jones@abc.disa.mil > Internet Users: jones%abc.disa.mil@relay.mil > DoD Users: smith%def.gsfc.nasa.gov@relay.int > Internet Users: smith@def.gsfc.nasa.gov To quote from Mad Magazine, "Blech! Feh! Ecch!" We've been spending the last few years *eradicating* hybrid addresses such as these; now, MILNET wants to bring them back wholesale? >> Mr. MacNab solicited comments from the user community on >> how these changes would effect them. His phone number is >> 703-285-5143 or email address is macnabr@cc.ims.disa.mil. I was glad to see this; I'll be suggesting MX records... --Wes From List-Managers-Owner@GreatCircle.COM Fri Nov 19 13:15:27 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA11332; Fri, 19 Nov 93 13:15:27 GMT Received: from note2.nsf.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA11325; Fri, 19 Nov 93 05:15:17 PST Received: from z.nsf.gov by Note2.nsf.gov id aa14962; 19 Nov 93 8:03 EST Received: by z.nsf.gov (4.1/SMI-4.1) id AA11024; Fri, 19 Nov 93 08:07:44 EST Message-Id: <9311191307.AA11024@z.nsf.gov> From: "Michael H. Morse" Date: Fri, 19 Nov 1993 08:07:44 EST In-Reply-To: "Mauricio Tavares" "More on handling annoying subscription requests" (Nov 18, 9:35pm) X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Mauricio Tavares Subject: Re: More on handling annoying subscription requests Cc: list-managers@greatcircle.com Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk > I am having problems with my mailing list. A lot of people, > besides all my warnings, still send their (un)subscription requests > to the mailing list instead of to me, who would then handle those > requests. As if that was not enough, there was an user that simply > kept sending subscription requests every other day for 3 weeks now. > For the record, this very user was added to the list 3 weeks ago. > What should I do? How can I filter those (un)subscription requests > so to minimize the annoyance to the other users? BTW, the mail > list code is written in sh shell (I wrote the beast). I have a little Perl script that examines the incoming mail to try to decide if it's a vacation reply or a subscription request. It's not perfect, but it probably catches 95% of the bad stuff. I think it just returns the mail to the user (hmmm... could generate a vacation loop, I guess) saying something like, "Your posting looks too much like a vacation note or a subscription command, blah, blah, blah." Here's the algorithm I use. Read the text of the message. Count lines that contain any of the following words: vacation, "remove me", subscribe, unsubscribe, signon, signoff. Count lines that don't contain any of these words. At the end, if any lines contain one of the words, and there are fewer than 5 lines that don't, reject the message. Obviously, this is not a perfect algorithm. But my plan was to watch it for a few months, and fine tune it based on what was getting through. In fact, I've never fine tuned it, since it does most of the work. The subsription/unsubscription requests are really easy, and the above algorithm will stop them. Vacation replies are much trickier, and judging by some I've seen lately, it's tough to stop them without also stopping some legitimate mail. Anyway, it shouldn't be too hard to put something like this into your shell script. --Mike From List-Managers-Owner@GreatCircle.COM Fri Nov 19 16:59:32 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA11971; Fri, 19 Nov 93 16:59:32 GMT Received: from easy.CES.CWRU.Edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA11964; Fri, 19 Nov 93 08:59:20 PST Received: by easy.CES.CWRU.Edu (5.64+/ane.09.11.90.2) id AA28904; Fri, 19 Nov 93 11:59:20 -0500 Date: Fri, 19 Nov 93 11:59:20 -0500 From: Aydin Edguer Message-Id: <9311191659.AA28904@easy.CES.CWRU.Edu> To: macnabr@cc.ims.disa.mil Subject: Re: DISA Announces Plan to Separate DDN from Internet Cc: List-Managers@GreatCircle.COM, cthomps@dgis.dtic.dla.mil Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk > Some accommodation will be required by users to communicate through > the new mail-relay. > > Currently: jones@abc.disa.mil > After Mail-Gateway: > Internet Users: jones%abc.disa.mil@relay.mil This is not necessary. The whole point behind DNS MX records was to make relays and gateways invisible, ending the need for users to know explicit paths to reach a destination and consequently eliminate the need for local (non RFC-822) characters like "%" in addresses. All the DoD needs to do is update the nameservers with a wildcard MX record for "*.mil" pointing to relay.mil. This is not a mailer issue, but a nameserver issue. The switch over for electronic mail services should be invisible. Aydin Edguer From List-Managers-Owner@GreatCircle.COM Fri Nov 19 17:25:20 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12045; Fri, 19 Nov 93 17:25:20 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12038; Fri, 19 Nov 93 09:25:13 PST Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA19332; Fri, 19 Nov 93 12:25:07 -0500 Received: from rde.UUCP by uucp1.uu.net with UUCP/RMAIL (queueing-rmail) id 122315.6631; Fri, 19 Nov 1993 12:23:15 EST Received: from homebase.vistachrome.com by cyan.vistachrome.COM (4.1/SMI-4.1) id AA09311; Fri, 19 Nov 93 12:15:08 EST Received: by homebase.vistachrome.com (5.65/1.35) id AA11910; Fri, 19 Nov 93 13:15:06 -0500 From: andy@homebase.vistachrome.com (Andy Finkenstadt) Message-Id: <9311191815.AA11910@homebase.vistachrome.com> Subject: Re: .MIL sites going through RELAY.MIL To: list-managers@greatcircle.com Date: Fri, 19 Nov 1993 13:15:06 -0500 (EST) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 616 Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk Perhaps I am too far from a solution, but could not the DNS servers for the .MIL domain set up a wildcard MX record which points ALL mail for *.MIL to RELAY.MIL ? Then no one has to change anything at all. Andy -- Andrew Finkenstadt | Systems Analyst, Homes & Land Publishing Corporation +1 904-575-0189 | GEnie Sysop andy@genie.geis.com | THE RELATIONAL OATH: "I promise to use the key, the andy@homes.com | whole key, and nothing but the key, so help me Codd." ,,, (. .) -------------------------o00-(_)-00o------------------------------ From List-Managers-Owner@GreatCircle.COM Fri Nov 19 10:46:53 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12413; Fri, 19 Nov 93 18:36:28 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12395; Fri, 19 Nov 93 10:35:47 PST Message-Id: <9311191835.AA12395@mycroft.GreatCircle.COM> To: Mitch Collinsworth Cc: List-Managers@greatcircle.com Subject: Re: Sendmail 8.6.4 vs. long lists In-Reply-To: Your message of Fri, 19 Nov 93 00:04:48 -0500 Date: Fri, 19 Nov 1993 10:35:46 -0800 From: Brent Chapman Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk Mitch Collinsworth writes: # # >I have reported the long-list bug to Allman. I have also done a # >quick-hack fix which I would be happy to share with anybody who # >needs it. I made no attempt at portability--I'm running 8.6.4 # >only on SunOS 4.1.3 and that's all I attempted to deal with. # >Systems whose syslog implementation allows less than 1024 bytes # >on a syslog line will need a more careful fix. Also, my fix # >potentially drops some log information. # # Just asked Allman himself via the MBone broadcast of his BAY-LISA # talk (still going on). He said this bug will be fixed in 8.6.5, which # will be out in "probably several weeks". # # -Mitch To expand a bit, he said that was his _planned_ release date for 8.6.5, but that he'd release it much sooner if there was a major bug fix (perhaps this one in it). Eric had been sick for most of the week, and hadn't done more than glance at the incoming messages about this bug, so he hasn't decided yet if it's a major bug (warranting an early release of a patch) or not. -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@GreatCircle.COM Fri Nov 19 10:56:53 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12589; Fri, 19 Nov 93 18:47:26 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12553; Fri, 19 Nov 93 10:46:42 PST Message-Id: <9311191846.AA12553@mycroft.GreatCircle.COM> To: Mauricio Tavares , list-managers@greatcircle.com Subject: Re: More on handling annoying subscription requests Date: Fri, 19 Nov 1993 10:46:41 -0800 From: Brent Chapman Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk # > I am having problems with my mailing list. A lot of people, # > besides all my warnings, still send their (un)subscription requests # > to the mailing list instead of to me, who would then handle those # > requests. As if that was not enough, there was an user that simply # > kept sending subscription requests every other day for 3 weeks now. # > For the record, this very user was added to the list 3 weeks ago. # > What should I do? How can I filter those (un)subscription requests # > so to minimize the annoyance to the other users? BTW, the mail # > list code is written in sh shell (I wrote the beast). The heuristics from the "resend" piece of the Majordomo package identify something as "administrivia" if it has "subscribe" or "unsubscribe" in the "Subject:" header has "add me", "delete me", "subscribe", or "unsubscribe" anywhere in the first 5 lines of the body. has "sub" or "unsub" at the beginning of a line anywhere in the first 5 lines of the body. -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@GreatCircle.COM Mon Nov 22 14:27:09 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28126; Mon, 22 Nov 93 14:27:09 GMT Received: from mozart.aero.ufl.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28118; Mon, 22 Nov 93 06:27:02 PST Received: from localhost by mozart.aero.ufl.edu (5.61ufl/4.10) id AA20708; Mon, 22 Nov 93 09:26:57 -0500 Message-Id: <9311221426.AA20708@mozart.aero.ufl.edu> To: list-managers@GreatCircle.COM Subject: Wanted: new home for a mailing list Date: Mon, 22 Nov 93 09:26:56 -0500 From: mauricio@mozart.aero.ufl.edu X-Mts: smtp Sender: List-Managers-Owner@GreatCircle.COM Precedence: bulk As I may lose this account in a year or so, the future of my Sinclair mailing list is dark. Does anyone know of any place that can handle another mailing list? Listserv systems are nice; I can handle them without problem.