From list-managers-owner Tue Jun 1 03:14:34 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id DAA11133; Tue, 1 Jun 1999 03:06:18 -0700 (PDT) Received: from mailgate.rz.uni-karlsruhe.de (nz40.rz.uni-karlsruhe.de [129.13.197.4]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id DAA11126 for ; Tue, 1 Jun 1999 03:06:04 -0700 (PDT) Received: from torres.gf1.internal (mail@isdn216-198.rz.uni-karlsruhe.de [129.13.216.198]) by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 2.04 #3) id 10olTv-0005yX-00; Tue, 1 Jun 1999 12:09:15 +0200 Received: from janeway.gf1.internal ([192.168.130.31]) by torres.gf1.internal with smtp (Exim 3.01-patchmh1 #1) id 10olTh-00069z-00; Tue, 01 Jun 1999 12:09:01 +0200 From: Marc.Haber-lists@gmx.de (Marc Haber) To: "David W. Tamkin" Cc: list-managers@greatcircle.com Subject: Re: Automatic confirmations Date: Tue, 01 Jun 1999 10:09:01 GMT Organization: posting from University of Karlsruhe, Germany References: <199906010119.UAA47105@Mars.mcs.net> In-Reply-To: <199906010119.UAA47105@Mars.mcs.net> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Sender: list-managers-owner@GreatCircle.COM Precedence: bulk On Mon, 31 May 1999 20:19:08 +1900 (CDT), you wrote: >Very possible, Marc. After all, they were clueless enough to select = such >software in the first place. Hey, Exchange isn't _that_ bad if configured correctly. Greetings Marc --=20 -------------------------------------- !! No courtesy copies, please !! = ----- Marc Haber | " Questions are the | Mailadresse im = Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32= 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31= 29 From list-managers-owner Tue Jun 1 06:59:54 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id GAA15688; Tue, 1 Jun 1999 06:52:49 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id GAA15681 for ; Tue, 1 Jun 1999 06:52:43 -0700 (PDT) Received: from Jupiter.mcs.net (dattier@Jupiter.mcs.net [192.160.127.88]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id IAA24890 for ; Tue, 1 Jun 1999 08:56:57 -0500 (CDT) Received: (from dattier@localhost) by Jupiter.mcs.net (8.8.7/8.8.2) id IAA13531 for list-managers@greatcircle.com; Tue, 1 Jun 1999 08:56:57 -0500 (CDT) From: "David W. Tamkin" Message-Id: <199906011356.IAA13531@Jupiter.mcs.net> Subject: Re: Automatic confirmations Date: Tue, 1 Jun 1999 08:56:57 -0500 (CDT) Cc: list-managers@greatcircle.com In-Reply-To: from "Marc Haber" at Jun 1, 99 10:09:01 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: list-managers-owner@GreatCircle.COM Precedence: bulk I had written, | >Very possible, Marc. After all, they were clueless enough to select such | >software in the first place. Marc Haber rejoined, | Hey, Exchange isn't _that_ bad if configured correctly. OK, then, the mail admins were clueless enough to select Lotus Notes or to misconfigure Exchange. Whatever, all the lists I've run have been for non-business purposes, and it took only one time that I got burned (I asked a site's postmaster about my trouble reaching a subscriber there and the subscriber raised hell with me for jeopardizing his job by ratting him out to management for what I didn't know to be misuse of his email access) for me to learn that when subscribers at corporate or university accounts can't be reached or their mailers cause problems, to cut them off instead of opening a can of worms. Subscribers at retail ISPs are another story; they're paying for their access and are entitled to get their email. But employees and students getting free email can't be choosers. From list-managers-owner Tue Jun 1 14:15:31 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id OAA20554; Tue, 1 Jun 1999 14:05:43 -0700 (PDT) Received: from socrates.uophx.edu (socrates.uophx.edu [204.17.17.98]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id OAA20545; Tue, 1 Jun 1999 14:05:36 -0700 (PDT) Received: from localhost (sgmiller@localhost) by socrates.uophx.edu (8.8.7/8.8.7) with SMTP id OAA30467; Tue, 1 Jun 1999 14:17:19 -0700 Date: Tue, 1 Jun 1999 14:17:19 -0700 (MST) From: "Steven G. Miller" To: Majordomo-Users cc: List-Managers Subject: Messages with Attachments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Running MD 1.94.4 RH 5.0 Perl 5.004 Sendmail 8.x Problem: All text messages seem to right through and out to the list, but I can't seem to send a message through with an attachment. Is this a sendmail problem or amajordomo issue? Steve From list-managers-owner Tue Jun 1 20:32:43 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id UAA25282; Tue, 1 Jun 1999 20:20:51 -0700 (PDT) Received: from vjs.org (vjs.telephonet.com [207.252.88.49]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id UAA25275 for ; Tue, 1 Jun 1999 20:20:44 -0700 (PDT) Received: from [207.252.88.49] (207.252.88.49) by vjs.org with ESMTP (Eudora Internet Mail Server 2.2); Tue, 1 Jun 1999 23:26:34 -0400 Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Organization: Little to None X-Mailer: Eudora 4.0 for Cray T3E-1200 Date: Tue, 1 Jun 1999 23:25:59 -0400 To: "Steven G. Miller" From: Vince Sabio Subject: Re: Messages with Attachments Cc: List-Managers Sender: list-managers-owner@GreatCircle.COM Precedence: bulk ** Sometime around 5:17 PM -0400 6/1/99, Steven G. Miller sent everyone: >Running MD 1.94.4 >RH 5.0 >Perl 5.004 >Sendmail 8.x > >Problem: All text messages seem to right through and out to the list, but >I can't seem to send a message through with an attachment. Is this a >sendmail problem or amajordomo issue? Neither; it's a feature. ;-) __________________________________________________________________________ Vince Sabio Boy & His Sabre: vince-lists@vjs.org Stop Internet Spam! From list-managers-owner Tue Jun 1 21:48:04 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id VAA26007; Tue, 1 Jun 1999 21:36:32 -0700 (PDT) Received: from tymix.Tymnet.COM (tymix.tymnet.com [131.146.2.1]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id VAA26000 for ; Tue, 1 Jun 1999 21:36:26 -0700 (PDT) Received: by tymix.Tymnet.COM (4.1/SMI-4.1) id AA07394; Tue, 1 Jun 99 21:40:44 PDT Received: from tardis by Tymnet.COM (in.smtpd); 1 Jun 0 21:40:43 PDT Received: from romana.Tymnet.COM by tardis.tymnet.com (8.8.8+Sun/SMI-SVR4) id VAA09611; Tue, 1 Jun 1999 21:40:41 -0700 (PDT) Received: (from jms@localhost) by romana.Tymnet.COM (8.9.1b+Sun/8.9.1) id VAA18619 for list-managers@greatcircle.com; Tue, 1 Jun 1999 21:40:39 -0700 (PDT) Date: Tue, 1 Jun 1999 21:40:39 -0700 (PDT) From: Joe Smith Message-Id: <199906020440.VAA18619@romana.Tymnet.COM> To: list-managers@greatcircle.com Subject: Topica mentioned in newspaper article about WWII vets Sender: list-managers-owner@GreatCircle.COM Precedence: bulk E-mail list service links W.W. II veterans http://www.mercurycenter.com/premium/nation/docs/elists31.htm This article in the San Jose Mercury News has two points: 1) Veterans of World War II exchange memories via e-mail on the "Heavy Bombers" list hosted at Topica. 2) Can companies such as Topica turn free list-maintenance services into a viable business? "It's not a grass-roots thing any longer when you've got Microsoft and Aolscape playing in it." -Joe From list-managers-owner Wed Jun 2 04:17:35 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id EAA02849; Wed, 2 Jun 1999 04:07:52 -0700 (PDT) Received: from MAINE.maine.edu (maine.maine.edu [130.111.39.100]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id EAA02841 for ; Wed, 2 Jun 1999 04:07:41 -0700 (PDT) Received: from polaris.umpi.maine.edu [130.111.208.87] by MAINE.maine.edu (IBM VM SMTP Level 310) via TCP with SMTP ; Wed, 02 Jun 1999 07:09:56 EDT Received: from POLARIS/SpoolDir by polaris.umpi.maine.edu (Mercury 1.43); 2 Jun 99 07:11:52 EST Received: from SpoolDir by POLARIS (Mercury 1.43); 2 Jun 99 07:11:22 EST Received: from albert (130.111.208.84) by polaris.umpi.maine.edu (Mercury 1.43); 2 Jun 99 07:11:20 EST From: "Anthony J. Albert" Organization: University of Maine at PI To: List-Managers@GreatCircle.COM Date: Wed, 2 Jun 1999 07:11:19 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Messages with Attachments In-reply-to: <199906020800.BAA27988@honor.greatcircle.com> X-mailer: Pegasus Mail for Win32 (v3.01d) Message-ID: <14B865A21990@polaris.umpi.maine.edu> Sender: list-managers-owner@GreatCircle.COM Precedence: bulk On 2 Jun 99, at 1:00, List-Managers-Digest wrote: >Date: Tue, 1 Jun 1999 14:17:19 -0700 (MST) >From: "Steven G. Miller" >Subject: Messages with Attachments > >Running MD 1.94.4 >RH 5.0 >Perl 5.004 >Sendmail 8.x > >Problem: All text messages seem to right through and out to the list, but >I can't seem to send a message through with an attachment. Is this a >sendmail problem or amajordomo issue? > >Steve Most likely it's a Majordomo "issue" with the length of the attachment. This has been an infrequent problem with the lists I oversee. Majordomo doesn't give an error message for this; it just drops the email and attachment into /dev/null. In the configuration file for your list, look for the "maxlength" parameter. Frequently, this is set low, around 20,000 characters, meaning that an attachment of a file of approximately 13KB or larger is unlikely to go through. Change the parameter to a larger number, such as 200000, or 500000, and it will allow attachments of that size to be sent to the list. Beware, though, as this size limit is there for a reason. It takes significantly longer to send attachments to large numbers of subscribers. 1 message of 2KB * 100 subscribers = 200KB = approx. 1 sec to send on 10Base-T (@2.5MB/sec) 1 message of 2000KB * 100 sub. = 200000KB = 200MB = approx. 640 sec to send at 10Base-T (@2.5MB/sec), which is approximately ten minutes For large attachments, I suggest WWW or FTP publication of the file, and just send a URL in the email, pointing to the file. Anthony J. Albert ============================================================== Anthony J. Albert albert@polaris.umpi.maine.edu Systems and Software Support Specialist Postmaster Computer Services - University of Maine, Presque Isle Attention: the next meeting of the Time Travellers' Society will be last Tuesday. From list-managers-owner Wed Jun 2 08:31:40 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id IAA05400; Wed, 2 Jun 1999 08:17:11 -0700 (PDT) Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id IAA05393 for ; Wed, 2 Jun 1999 08:17:02 -0700 (PDT) Received: from solva.ifi.uio.no (1368@solva.ifi.uio.no [129.240.64.20]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with SMTP id RAA01898; Wed, 2 Jun 1999 17:21:24 +0200 (MET DST) Received: (from thomasg@localhost) by solva.ifi.uio.no ; Wed, 2 Jun 1999 17:21:23 +0200 Date: Wed, 2 Jun 1999 17:21:22 +0200 From: Thomas Gramstad Reply-To: thomasg@ifi.uio.no To: list-managers@GreatCircle.COM Subject: Re: Automatic confirmations In-Reply-To: "David W. Tamkin" 's message of Tue, 1 Jun 1999 08:56:57 -0500 (CDT) References: <199906011356.IAA13531@Jupiter.mcs.net> Message-ID: Sender: list-managers-owner@GreatCircle.COM Precedence: bulk David W. Tamkin wrote: > Whatever, all the lists I've run have been for non-business > purposes, and it took only one time that I got burned (I asked a > site's postmaster about my trouble reaching a subscriber there > and the subscriber raised hell with me for jeopardizing his job > by ratting him out to management for what I didn't know to be > misuse of his email access) for me to learn that when > subscribers at corporate or university accounts can't be reached > or their mailers cause problems, to cut them off instead of > opening a can of worms. > > Subscribers at retail ISPs are another story; they're paying for > their access and are entitled to get their email. But employees > and students getting free email can't be choosers. I disagree with everything. ISP subscribers are often frivolous and clueless and they change e-mail addresses faster than a certain president change young secretaries. And they haven't paid ME anything, so I owe them nothing. University or corporate subscribers are at least serious enough to have a job or a study, and have more stable addresses. Their relationship to their employer is their business. Thomas Gramstad thomasg@ifi.uio.no "Those who educate children well are more to be honored than parents, for these only gave life, those the art of living well." -- Aristotle From list-managers-owner Thu Jun 3 08:12:54 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id HAA22736; Thu, 3 Jun 1999 07:54:49 -0700 (PDT) Received: from sws5.ctd.ornl.gov (sws5.ctd.ornl.gov [128.219.128.125]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id HAA22728 for ; Thu, 3 Jun 1999 07:54:37 -0700 (PDT) Received: (qmail 189592 invoked by uid 3995); 3 Jun 1999 14:59:13 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14166.38977.661432.2089@sws5.ctd.ornl.gov> Date: Thu, 3 Jun 1999 10:59:13 -0400 (EDT) From: Dave Sill To: List-Managers@GreatCircle.COM Subject: Re: Messages with Attachments In-Reply-To: <14B865A21990@polaris.umpi.maine.edu> References: <199906020800.BAA27988@honor.greatcircle.com> <14B865A21990@polaris.umpi.maine.edu> X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) Organization: Oak Ridge National Lab, Oak Ridge, Tenn., USA X-Face: "p~Q]mg{;e*}YR|)&Q/&Q\*~5UWfZX34;5M wrote: >On 2 Jun 99, at 1:00, List-Managers-Digest wrote: >>Date: Tue, 1 Jun 1999 14:17:19 -0700 (MST) >>From: "Steven G. Miller" >>Subject: Messages with Attachments >> >>Running MD 1.94.4 >>RH 5.0 >>Perl 5.004 >>Sendmail 8.x >> >>Problem: All text messages seem to right through and out to the list, but >>I can't seem to send a message through with an attachment. What happens? Does it bounce, or does the attachment/message get corrupted? >>Is this a >>sendmail problem or amajordomo issue? Almost certainly a majordomo issue. > Most likely it's a Majordomo "issue" with the length of the >attachment. No, it's more likely to be due to the fact that "resend" strips MIME header fields when resending to moderated lists, resulting in what appears, to the recipients, to be a garbled message. -Dave From list-managers-owner Fri Jun 4 16:13:35 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id QAA16607; Fri, 4 Jun 1999 16:06:34 -0700 (PDT) Received: from tcp.com (tcp.com [207.126.126.64]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id QAA16600 for ; Fri, 4 Jun 1999 16:06:29 -0700 (PDT) Received: from localhost by tcp.com (8.9.0/8.6.10) with ESMTP id QAA27825 for ; Fri, 4 Jun 1999 16:11:21 -0700 (PDT) Date: Fri, 4 Jun 1999 16:11:20 -0700 (PDT) From: James Lick To: list-managers@greatcircle.com Subject: FYI: listquest.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Heads up. Watch out for listquest.com. I received a query from them asking if I wanted to let them archive my lists, immediately followed by subscription requests (which were rejected as they attached some sort of image file to the request). Don't know their intentions, but it doesn't look good. ---- James Lick ---- jlick@drivel.com ---- http://drivel.com/ ---- From list-managers-owner Fri Jun 4 19:13:36 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id TAA18128; Fri, 4 Jun 1999 19:08:35 -0700 (PDT) Received: from ma-1.rootsweb.com (ma-1.rootsweb.com [209.192.148.153]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id TAA18121 for ; Fri, 4 Jun 1999 19:08:28 -0700 (PDT) Received: (from twp@localhost) by ma-1.rootsweb.com (8.9.3/8.9.3) id WAA08522 for list-managers@greatcircle.com; Fri, 4 Jun 1999 22:13:19 -0400 (EDT) Date: Fri, 4 Jun 1999 22:13:19 -0400 From: Tim Pierce To: list-managers@greatcircle.com Subject: HTML demangler for mailing lists Message-ID: <19990604221319.L72837@ma-1.rootsweb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i Sender: list-managers-owner@GreatCircle.COM Precedence: bulk [ I tried posting this a couple of times before, but it never showed up, maybe because the message was too long with source code enclosed. ] There's considerable demand for a tool that will strip out the HTML portions of multipart messages and leave only text/plain, but as far as I can tell, no such tool exists. So I wrote one. Get it at http://www.rootsweb.com/~twp/unhtml.c. This program reads a message on standard input and prints a demangled version on standard output. If the message has a content-type of `multipart/alternative', the body is discarded and replaced with the first text/plain subpart that can be found. If the message isn't multipart/alternative, or if it contains no text/plain subparts, the original message is passed through unmodified. For example, it can easily be hooked into SmartList in rc.local.s00 (and .r00): :0 wf * ^Content-Type: multipart | unhtml It is not guaranteed to be bug-free and should be considered beta software, at best. For what it's worth, it's been running in production on RootsWeb's mail servers for several days (an excellent torture test) and the initial bugs seem to have been shaken out. Anyway, I give it unto the world for them what wants it. Corrections and fixes welcomed. -- Regards, Tim Pierce RootsWeb Genealogical Data Cooperative system obfuscator and hack-of-all-trades From list-managers-owner Fri Jun 4 22:28:51 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id WAA19742; Fri, 4 Jun 1999 22:16:04 -0700 (PDT) Received: from dragoncat.net (herne.dragoncat.net [216.122.4.136]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id WAA19735 for ; Fri, 4 Jun 1999 22:15:54 -0700 (PDT) Received: from localhost (jtraub@localhost) by dragoncat.net (8.9.3/8.9.3) with ESMTP id WAA06686 for ; Fri, 4 Jun 1999 22:21:18 -0700 Date: Fri, 4 Jun 1999 22:21:18 -0700 (PDT) From: JT To: list-managers@GreatCircle.COM Subject: Re: HTML demangler for mailing lists In-Reply-To: <19990604221319.L72837@ma-1.rootsweb.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: list-managers-owner@GreatCircle.COM Precedence: bulk On Fri, 4 Jun 1999, Tim Pierce wrote: > [ I tried posting this a couple of times before, but it never showed > up, maybe because the message was too long with source code > enclosed. ] > > There's considerable demand for a tool that will strip out the HTML > portions of multipart messages and leave only text/plain, but as far > as I can tell, no such tool exists. So I wrote one. Get it at > http://www.rootsweb.com/~twp/unhtml.c. Amusingly enough, code to do this is in the Listar mailing list manager core. It also strips out OTHER mime types (like gifs and such as well). The reason I mention is the comment about no such tool existing :) --JT -- [-------------------------------------------------------------------------] [ Practice random kindness and senseless acts of beauty. ] [ It's hard to seize the day when you must first grapple with the morning ] [-------------------------------------------------------------------------] From list-managers-owner Sat Jun 5 04:55:06 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id EAA26430; Sat, 5 Jun 1999 04:37:29 -0700 (PDT) Received: from scifi.squawk.com (scifi.squawk.com [208.235.116.1]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id EAA26423 for ; Sat, 5 Jun 1999 04:37:22 -0700 (PDT) Received: from tpad.squawk.com (root@localhost [127.0.0.1]) by scifi.squawk.com (8.8.7/8.8.7) with SMTP id HAA17631; Sat, 5 Jun 1999 07:41:59 -0400 Message-Id: <3.0.5.32.19990605074149.03b50410@127.0.0.1> X-Sender: njs@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sat, 05 Jun 1999 07:41:49 -0400 To: Tim Pierce From: Nick Simicich Subject: Re: HTML demangler for mailing lists Cc: list-managers@GreatCircle.COM In-Reply-To: <19990604221319.L72837@ma-1.rootsweb.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: list-managers-owner@GreatCircle.COM Precedence: bulk At 10:13 PM 6/4/99 -0400, Tim Pierce wrote: >[ I tried posting this a couple of times before, but it never showed > up, maybe because the message was too long with source code > enclosed. ] > >There's considerable demand for a tool that will strip out the HTML >portions of multipart messages and leave only text/plain, but as far >as I can tell, no such tool exists. So I wrote one. Get it at >http://www.rootsweb.com/~twp/unhtml.c. I thought so as well, several months ago, so I wrote demime, a perl script that not only strips out the html alternative sections, but renders it if the only alternative section is html, renders plain text, removes attachments and so forth. http://scifi.squawk.com/demime.html -- That which does not kill us, makes us stronger. That which does kill us makes us smell stronger, after a few days, anyway. Nick Simicich mailto:njs@scifi.squawk.com or (last choice) mailto:njs@us.ibm.com http://scifi.squawk.com/njs.html -- Stop by and Light Up The World! From list-managers-owner Sat Jun 5 06:45:05 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id GAA27257; Sat, 5 Jun 1999 06:34:52 -0700 (PDT) Received: from ma-1.rootsweb.com (ma-1.rootsweb.com [209.192.148.153]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id GAA27250 for ; Sat, 5 Jun 1999 06:34:43 -0700 (PDT) Received: (from twp@localhost) by ma-1.rootsweb.com (8.9.3/8.9.3) id JAA14198; Sat, 5 Jun 1999 09:39:30 -0400 (EDT) Date: Sat, 5 Jun 1999 09:39:30 -0400 From: Tim Pierce To: Nick Simicich Cc: list-managers@GreatCircle.COM Subject: Re: HTML demangler for mailing lists Message-ID: <19990605093930.A14133@ma-1.rootsweb.com> References: <19990604221319.L72837@ma-1.rootsweb.com> <3.0.5.32.19990605074149.03b50410@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <3.0.5.32.19990605074149.03b50410@127.0.0.1>; from Nick Simicich on Sat, Jun 05, 1999 at 07:41:49AM -0400 Sender: list-managers-owner@GreatCircle.COM Precedence: bulk On Sat, Jun 05, 1999 at 07:41:49AM -0400, Nick Simicich wrote: > At 10:13 PM 6/4/99 -0400, Tim Pierce wrote: > > > >There's considerable demand for a tool that will strip out the HTML > >portions of multipart messages and leave only text/plain, but as far > >as I can tell, no such tool exists. So I wrote one. Get it at > >http://www.rootsweb.com/~twp/unhtml.c. > > I thought so as well, several months ago, so I wrote demime, a perl script > that not only strips out the html alternative sections, but renders it if > the only alternative section is html, renders plain text, removes > attachments and so forth. http://scifi.squawk.com/demime.html Thanks for reminding me. I didn't mean to dismiss your work. I just needed a very lightweight solution, since the load on a busy list server can get pretty extreme. I can't fire up Perl every time someone posts a message. A precompiled tool is pretty much the only way to go, and I couldn't find one written in C anywhere. (Thanks to the fellow who pointed me at Listar; I'll take a look at that.) -- Regards, Tim Pierce RootsWeb Genealogical Data Cooperative system obfuscator and hack-of-all-trades From list-managers-owner Sun Jun 6 01:25:15 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id AAA06968; Sun, 6 Jun 1999 00:58:03 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id AAA06960 for list-managers@greatcircle.com; Sun, 6 Jun 1999 00:58:00 -0700 (PDT) Received: from ma-1.rootsweb.com (ma-1.rootsweb.com [209.192.148.153]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id HAA10238 for ; Fri, 4 Jun 1999 07:31:12 -0700 (PDT) Received: (from twp@localhost) by ma-1.rootsweb.com (8.9.3/8.9.3) id KAA03302 for list-managers@greatcircle.com; Fri, 4 Jun 1999 10:35:53 -0400 (EDT) Date: Fri, 4 Jun 1999 10:35:53 -0400 From: Tim Pierce To: list-managers@greatcircle.com Subject: HTML demangler for mailing lists Message-ID: <19990604103552.Z72837@ma-1.rootsweb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i Sender: list-managers-owner@GreatCircle.COM Precedence: bulk [ I sent this last night, but, what timing, included the source code as an attachment. Please forgive me if this creates any reduplication. ] There's considerable demand for a tool that will strip out the HTML portions of multipart messages and leave only text/plain, but as far as I can tell, no such tool exists. So I wrote one. This program reads a message on standard input and prints a demangled version on standard output. If the message has a content-type of `multipart/alternative', the body is discarded and replaced with the first text/plain subpart that can be found. If the message isn't multipart/alternative, or if it contains no text/plain subparts, the original message is passed through unmodified. For example, it can easily be hooked into SmartList in rc.local.s00 (and .r00): :0 wf * ^Content-Type: multipart | unhtml It is not guaranteed to be bug-free and should be considered beta software, at best. For what it's worth, it's been running in production on RootsWeb's mail servers for several days (an excellent torture test) and the initial bugs seem to have been shaken out. Anyway, I give it unto the world for them what wants it. Corrections and fixes welcomed. Regards, Tim Pierce RootsWeb Genealogical Data Cooperative system obfuscator and hack-of-all-trades -------------------- >snip here< -------------------- /* * unhtml: parse a MIME multipart message and, if `multipart/alternative', * discard all but the `text/plain' part. * * This code is in the public domain except where noted otherwise. * * Tim Pierce * 3 June 1999 */ #include #include #include struct list { struct message *data; struct list *next; }; /* * The `message' struct is used to represent a MIME multipart message, * as defined in RFC 2045 and RFC 2046. * * The `header' and `preamble' fields are flat text arrays containg * the raw text of the message header and preamble (any text preceding * the first body part). In the case of a single-part message, the * `preamble' field is used to store the whole body. * * The `epilogue' field stores any text following the last body part. * * The `content_type' field contains the value of the message's * Content-Type header, minus any parameters: for example, * "text/plain". It is NULL if the message lacks a Content-Type * header. The `boundary' field contains the value of the `boundary' * parameter to the Content-Type field, if present. * * The `hsize' parameter is the size of the header, in bytes. The * `bsize' parameter is the size of the body, in bytes. These * parameters are not presently used and may be discarded. */ struct message { char *header; char *preamble; /* text (if any) preceding the first body-part */ char *epilogue; /* text (if any) following the last body-part */ char *content_type; char *boundary; int is8bit; /* does this message contain 8bit data? */ int hsize; /* bytes allocated for hdr (may be more than necessary) */ int bsize; /* bytes allocated for body (may be more than necessary) */ struct list *parts; }; struct message *mime_parse (char *body); void mime_write (struct message *msg); void mime_warn (char *s); void mime_fatal (char *s); void mime_destroy (struct message *msg); int check_msgtype (struct message *msg, char *type); void getheader (struct message *msg, char *hdrname, char **hdrvalp, int *hdrlen); char *next_boundary (char *body, char *boundary); int add_subpart (struct message *msg, struct message *part); void print_msg_info (struct message *msg, int indent); void mime_decode_qp (struct message *msg); void mime_decode_b64 (char *buf); void mime_output_qp (char *text); int main (argc, argv) int argc; char **argv; { struct message *msg; int len, c, last_char, bi, bsize; char *p, *body; if (argc > 1) { if (freopen (argv[1], "r", stdin) == NULL) { perror ("unhtml: freopening standard input"); exit(1); } } /* Read the message. */ bi = 0; body = (char *) malloc (sizeof(char) * 1000); if (body == NULL) { perror ("unhtml: could not malloc memory for body"); exit(1); } while ((len = read (fileno(stdin), body+bi, 1000)) == 1000) { bi += 1000; body = (char *) realloc (body, sizeof(char) * (bi+1000)); if (body == NULL) { perror ("unhtml: could not realloc memory for body"); exit(1); } } bsize = bi + len; body[bsize] = '\0'; msg = mime_parse (body); /* * Here's the important stuff: walk through the parts of a * multipart/alternative and look for a text/plain attachment. * If we find one, rewrite the headers of the parent message * (this is ugly) and output the text/plain body. */ if (msg->content_type && !strncasecmp (msg->content_type, "multipart/alternative", 21)) { struct list *p; for (p = msg->parts; p != NULL; p = p->next) { if (p->data->content_type == NULL || !strncasecmp (p->data->content_type, "text/plain", 10)) { /* XXX: Rewrite the headers. This is clumsy, and also * doesn't handle Content-Type or Content-Length if they're * the first headers in the message. */ char *cp; for (cp = msg->header; *cp; ++cp) { putchar (*cp); /* Skip Content-Length and Content-Transfer-Encoding. */ if (*cp == '\n' && (!strncasecmp (cp+1, "Content-Length:",15) || !strncasecmp (cp+1, "Content-Transfer-Encoding:", 26))) { do { cp = strchr (cp+1, '\n'); } while (cp != NULL && isspace(cp[1])); if (cp == NULL) break; } /* Rewrite Content-Type. */ if (*cp == '\n' && !strncasecmp (cp+1, "Content-Type:", 13)) { char *hp; int hlen; if (p->data->content_type) printf ("Content-Type: %s\n", p->data->content_type); /* Skip to next header. */ do { cp = strchr (cp+1, '\n'); } while (cp != NULL && isspace(cp[1])); if (cp == NULL) break; } } putchar ('\n'); puts (p->data->preamble); break; } } if (p != NULL) return 0; } /* * If we got here, either the message wasn't multipart/alternative * or it didn't have a text/plain component. In either case we * give up and write the original message to stdout. */ fputs (body, stdout); return 0; } /* * mime_parse: process an RFC 2046 multipart message and return * a message structure with all the necessary fields filled in. * * The BODY argument is a character array containing the raw text of the * message to be parsed. * * In the event of a fatal system error (should only happen in the * case of insufficient memory) or a fatal MIME parsing error, a * message will be printed on standard error and the return value * will be NULL. */ struct message * mime_parse (body) char *body; { char *p, *bodyp; int len; struct message *msg; /* Initialize the message. */ msg = (struct message *) malloc (sizeof(struct message)); if (msg == NULL) { perror ("unhtml: mime_parse could not malloc new message struct"); exit(1); } msg->header = NULL; msg->preamble = NULL; msg->epilogue = NULL; msg->content_type = NULL; msg->boundary = NULL; msg->parts = NULL; msg->is8bit = 0; /* Get the header. */ /* Special case for message with zero-length header. */ if (body[0] == '\n') { msg->hsize = 0; msg->header = (char *) malloc(sizeof(char)); if (msg->header == NULL) { perror ("unhtml: mime_parse could not malloc header buffer"); return NULL; } msg->header[0] = '\0'; bodyp = body + 1; } else { bodyp = strstr (body, "\n\n"); if (bodyp == NULL) { mime_fatal ("no message header found"); return NULL; } msg->hsize = bodyp - body + 1; msg->header = (char *) malloc (sizeof(char) * (msg->hsize+1)); if (msg->header == NULL) { perror ("unhtml: mime_parse could not malloc header buffer"); return NULL; } strncpy (msg->header, body, msg->hsize); msg->header[msg->hsize] = '\0'; bodyp += 2; } /* Find the content-type. */ getheader (msg, "Content-Type", &p, &len); if (p != NULL) { msg->content_type = (char *) malloc (sizeof(char) * (len + 1)); if (msg->content_type == NULL) { perror ("unhtml: mime_parse could not malloc Content-Type buffer"); mime_destroy (msg); return NULL; } strncpy (msg->content_type, p, len); msg->content_type[len] = '\0'; } /* * If this is a message/rfc822, then the body is an encapsulated * message. Parse it, attach the result to the current message, * and we're done. */ if (msg->content_type && !strcasecmp (msg->content_type, "message/rfc822")) { msg->parts = (struct list *) malloc (sizeof(struct list)); if (msg->parts == NULL) { perror ("unhtml: mime_parse could not malloc attachment list"); return NULL; } msg->parts->data = mime_parse (bodyp); msg->parts->next = NULL; return msg; } /* Find the message boundary. */ if (msg->content_type && !strncasecmp (msg->content_type, "multipart/", 10)) { /* Skip to next semicolon and see what keyword follows it. */ p = msg->content_type; while ((p = strchr (p, ';')) != NULL) { ++p; p += strspn (p, " \t\v\r\n"); if (strncasecmp (p, "boundary", 8) == 0) { char *dest; p += 8 + strspn (p+8, " \t\v\r\n"); if (*p++ != '=') { mime_fatal ("expected `=' after `boundary' parameter"); mime_destroy (msg); return NULL; } p += strspn (p, " \t\v\r\n"); dest = msg->boundary = (char *) malloc (strlen(p)); if (dest == NULL) { perror ("unhtml: mime_parse could not malloc boundary"); mime_destroy (msg); return NULL; } /* If next char is a quote, read the following quoted-string. */ if (*p == '"') { ++p; while (*p != '\0' && *p != '"') { if (*p == '\\') ++p; *dest++ = *p; ++p; } } else /* Generic non-special characters. */ { while (*p != '\0' && !strchr ("()<>@,;:\\\"/[]?=", *p)) { *dest++ = *p; ++p; } } *dest = '\0'; break; } } if (msg->boundary == NULL) { mime_fatal ("Content-Type lacks required `boundary' parameter"); mime_destroy (msg); return NULL; } } /* Break up multiparts. */ if (check_msgtype (msg, "multipart/")) { char *nextpart; struct message *part; /* Preamble. */ p = next_boundary (bodyp, msg->boundary); if (p == NULL) msg->preamble = strdup (bodyp); else { int psize = p - bodyp - strlen(msg->boundary) - 3; /* Special case: a boundary line may occur at the very beginning of the body, which means that no newline precedes it and psize is negative. */ if (psize < 0) psize = 0; msg->preamble = (char *) malloc (sizeof(char) * (psize+1)); if (msg->preamble == NULL) { perror ("unhtml: mime_parse could not malloc preamble buffer"); mime_destroy (msg); return NULL; } strncpy (msg->preamble, bodyp, psize); msg->preamble[psize] = '\0'; } /* Scan to each boundary and parse the body part contained therein. */ while (p != NULL && strncmp (p, "--\n", 3) != 0) { nextpart = next_boundary (++p, msg->boundary); if (nextpart == NULL) { char buf[512]; snprintf (buf, sizeof buf, "no terminating `%s' boundary found", msg->boundary); mime_warn (buf); break; } else { char *part_end = nextpart - strlen(msg->boundary) - 3; char c = *part_end; /* XXX: Parsing a body part should not require munging the buffer passed to mime_parse. */ *part_end = '\0'; part = mime_parse (p); *part_end = c; if (part == NULL) { mime_destroy (msg); return NULL; } if (!add_subpart (msg, part)) { mime_destroy (msg); return NULL; } } p = nextpart; } /* Get epilogue. */ if (p != NULL) { while (*p++ != '\n') ; if ((msg->epilogue = strdup(p)) == NULL) { perror ("unhtml: mime_parse could not strdup message epilogue"); mime_destroy (msg); return NULL; } } } else /* not multipart */ { msg->preamble = strdup (bodyp); if (msg->preamble == NULL) { perror ("unhtml: mime_parse could not strdup message body"); mime_destroy (msg); return NULL; } } /* Decode the body (preamble), if appropriate. */ getheader (msg, "Content-Transfer-Encoding", &p, &len); if (p != NULL) { if (!strncasecmp (p, "quoted-printable", len)) mime_decode_qp (msg); else if (!strncasecmp (p, "base64", len)) mime_decode_b64 (msg->preamble); else if (strncasecmp (p, "7bit", 4) != 0 && strncasecmp (p, "8bit", 4) != 0) mime_warn ("unknown Content-Transfer-Encoding"); } return msg; } /* * check_msgtype: check the type of a MIME message structure and return 1 if * the message is of the desired type, 0 otherwise. */ int check_msgtype (msg, type) struct message *msg; char *type; { return (msg->content_type && !strncasecmp (msg->content_type, type, strlen(type))); } /* * getheader: examine a MIME message for a particular header, and * record the location of that header's value (following the header name) * and its length (excluding the trailing newline). * * The MSG argument is a message structure containing a parsed MIME message. * The HDRNAME argument is the name of the desired header, e.g. "Content-Type". * The HDRVALP argument stores a pointer to the beginning of the header * contents, if that header is found in the message. * The HDRLEN argument stores the length of the header contents. */ void getheader (msg, hdrname, hdrvalp, hdrlen) struct message *msg; char *hdrname; char **hdrvalp; int *hdrlen; { char *p, *hvp; int hdrnamelen, hvlen; *hdrvalp = NULL; *hdrlen = 0; hdrnamelen = strlen(hdrname); p = msg->header; while (p != NULL) { if (strncasecmp (p, hdrname, hdrnamelen) == 0) { hvp = p + hdrnamelen; if (*hvp++ != ':') /* colon must follow header name */ continue; while (*hvp != '\0' && isspace(*hvp)) ++hvp; for (hvlen = 0; hvp[hvlen] != '\0'; ++hvlen) { if (hvp[hvlen] == '\n' && !isspace(hvp[hvlen+1])) { *hdrvalp = hvp; *hdrlen = hvlen; return; } } } p = strchr (p, '\n'); if (p) ++p; } } /* * next_boundary: find the next MIME multipart boundary in a message. * The return value is a pointer to the end of the boundary text, * or NULL if no boundary can be found in this message. * * The BODY argument is a character array containing the message body. * The BOUNDARY argument is a character array containing the boundary * delimiter. * * Because the return value points to the end of the boundary, it * will point to `\n' if this is an ordinary boundary or `--\n' if * it is a final boundary. */ char * next_boundary (body, boundary) char *body; char *boundary; { char *p; /* For efficiency reasons, look for the boundary first and then examine the characters around it. */ p = strstr (body, boundary); if (p != NULL && strncmp (p-3, "\n--", 3) == 0) return p + strlen(boundary); return NULL; } /* * add_subpart: append one message to the list of sub-parts for another * message. * * The argument MSG is a message structure representing a multipart message. * The argument PART is another message (possibly multipart) which is to * be added to MSG's list of sub-parts. * * Return 1 on success. If a fatal error arises, return 0. */ int add_subpart (msg, part) struct message *msg; struct message *part; { struct list *p; if (msg->parts == NULL) { msg->parts = (struct list *) malloc (sizeof(struct list)); if (msg->parts == NULL) { perror ("unhtml: add_subpart could not malloc attachment list"); return 0; } msg->parts->data = part; msg->parts->next = NULL; } else { for (p = msg->parts; p->next != NULL; p = p->next) ; p = p->next = (struct list *) malloc (sizeof(struct list)); if (p == NULL) { perror ("unhtml: add_subpart could not malloc attachment buffer"); return 0; } p->data = part; p->next = NULL; } return 1; } void mime_write (msg) struct message *msg; { if (msg->header) { fputs (msg->header, stdout); putc ('\n', stdout); } /* message/rfc822 needs special handling. */ if (msg->content_type && !strncasecmp (msg->content_type, "message/rfc822", 14)) { mime_write (msg->parts->data); return; } /* XXX: watch out for 8bit data here. */ fputs (msg->preamble, stdout); if (msg->parts != NULL) { struct list *p; for (p = msg->parts; p != NULL; p = p->next) { printf ("\n--%s\n", msg->boundary); mime_write (p->data); } printf ("\n--%s--\n", msg->boundary); fputs (msg->epilogue, stdout); } } void mime_warn (s) char *s; { fprintf (stderr, "MIME parser: warning: %s\n", s); } void mime_fatal (s) char *s; { fprintf (stderr, "MIME parser: fatal: %s\n", s); } void mime_destroy (msg) struct message *msg; { struct list *p, *q; if (msg->header != NULL) free (msg->header); if (msg->preamble != NULL) free (msg->preamble); if (msg->epilogue != NULL) free (msg->epilogue); if (msg->content_type != NULL) free (msg->content_type); if (msg->boundary != NULL) free (msg->boundary); p = msg->parts; while (p != NULL) { if (p->data != NULL) mime_destroy (p->data); q = p; p = p->next; free (q); } } void print_msg_info (msg, indent) struct message *msg; int indent; { char indbuf[80]; indbuf[indent--] = '\0'; while (indent >= 0) indbuf[indent--] = ' '; printf ("%sHeader:\n", indbuf); printf ("%s--BEGIN--\n", indbuf); printf ("%s\n", msg->header); printf ("%s--END--\n", indbuf); printf ("%sContent-Type: %s\n", indbuf, msg->content_type); printf ("%sBoundary: %s\n", indbuf, msg->boundary); printf ("%s----------------------------------------\n", indbuf); if (msg->parts != NULL) { struct list *p; for (p = msg->parts; p != NULL; p = p->next) { print_msg_info (p->data, indent + 4); } } } int hex2dec_char(ch) char ch; { if (isdigit(ch)) return ch-'0'; else if (isupper(ch)) return ch-'A'+10; else return ch-'a'+10; } /* * mime_decode_qp: convert the preamble of MSG from a quoted-printable * encoding to raw text. */ void mime_decode_qp (msg) struct message *msg; { unsigned char *src, *dst; dst = src = msg->preamble; while (*src != '\0') { if (*src == '=') { if (*++src == '\n') { ++src; continue; } else { int hi, lo; hi = hex2dec_char(*src++); lo = hex2dec_char(*src); *dst = hi*16 + lo; if (*dst > 0x7f) msg->is8bit = 1; } } else *dst = *src; ++dst, ++src; } } void mime_output_qp (text) char *text; { /* XXX: write this. */ } /* * The char64 macro and `mime_decode_b64' routine are taken from * metamail 2.7, which is copyright (c) 1991 Bell Communications * Research, Inc. (Bellcore). The following license applies to all * code below this point: * * Permission to use, copy, modify, and distribute this material * for any purpose and without fee is hereby granted, provided * that the above copyright notice and this permission notice * appear in all copies, and that the name of Bellcore not be * used in advertising or publicity pertaining to this * material without the specific, prior written permission * of an authorized representative of Bellcore. BELLCORE * MAKES NO REPRESENTATIONS ABOUT THE ACCURACY OR SUITABILITY * OF THIS MATERIAL FOR ANY PURPOSE. IT IS PROVIDED "AS IS", * WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES. */ static char index_64[128] = { -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,62, -1,-1,-1,63, 52,53,54,55, 56,57,58,59, 60,61,-1,-1, -1,-1,-1,-1, -1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9,10, 11,12,13,14, 15,16,17,18, 19,20,21,22, 23,24,25,-1, -1,-1,-1,-1, -1,26,27,28, 29,30,31,32, 33,34,35,36, 37,38,39,40, 41,42,43,44, 45,46,47,48, 49,50,51,-1, -1,-1,-1,-1 }; #define char64(c) (((c) < 0 || (c) > 127) ? -1 : index_64[(c)]) void mime_decode_b64 (src) char *src; { char *dst; int c1, c2, c3, c4; int newline = 1, DataDone = 0; dst = src; while ((c1 = *src++) != '\0') { if (isspace(c1)) { if (c1 == '\n') { newline = 1; } else { newline = 0; } continue; } if (DataDone) continue; newline = 0; do { c2 = *src++; } while (c2 != '\0' && isspace(c2)); do { c3 = *src++; } while (c3 != '\0' && isspace(c3)); do { c4 = *src++; } while (c4 != '\0' && isspace(c4)); if (c2 == '\0' || c3 == '\0' || c4 == '\0') { fprintf(stderr, "Warning: base64 decoder saw premature EOF!\n"); return; } if (c1 == '=' || c2 == '=') { DataDone=1; continue; } c1 = char64(c1); c2 = char64(c2); *dst++ = (c1<<2) | ((c2&0x30)>>4); if (c3 == '=') DataDone = 1; else { c3 = char64(c3); *dst++ = ((c2&0XF) << 4) | ((c3&0x3C) >> 2); if (c4 == '=') DataDone = 1; else { c4 = char64(c4); *dst++ = ((c3&0x03) <<6) | c4; } } } *dst = '\0'; } From list-managers-owner Sun Jun 6 01:40:16 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id AAA06918; Sun, 6 Jun 1999 00:57:17 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id AAA06908 for list-managers@greatcircle.com; Sun, 6 Jun 1999 00:57:14 -0700 (PDT) Received: from ma-1.rootsweb.com (ma-1.rootsweb.com [209.192.148.153]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id VAA01426 for ; Thu, 3 Jun 1999 21:17:42 -0700 (PDT) Received: (from twp@localhost) by ma-1.rootsweb.com (8.9.3/8.9.3) id AAA00157; Fri, 4 Jun 1999 00:21:59 -0400 (EDT) Date: Fri, 4 Jun 1999 00:21:58 -0400 From: Tim Pierce To: list-managers@greatcircle.com Cc: SmartList@informatik.rwth-aachen.de Subject: HTML demangler for mailing lists Message-ID: <19990604002158.N72837@ma-1.rootsweb.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=y0Ed1hDcWxc3B7cn X-Mailer: Mutt 0.95.1i Sender: list-managers-owner@GreatCircle.COM Precedence: bulk --y0Ed1hDcWxc3B7cn Content-Type: text/plain; charset=us-ascii There's considerable demand for a tool that will strip out the HTML portions of multipart messages and leave only text/plain, but as far as I can tell, no such tool exists. So I wrote one. This program reads a message on standard input and prints a demangled version on standard output. If the message has a content-type of `multipart/alternative', the body is discarded and replaced with the first text/plain subpart that can be found. If the message isn't multipart/alternative, or if it contains no text/plain subparts, the original message is passed through unmodified. For example, it can easily be hooked into SmartList in rc.local.s00 (and .r00): :0 wf * ^Content-Type: multipart | unhtml It is not guaranteed to be bug-free and should be considered beta software, at best. For what it's worth, it's been running in production on RootsWeb's mail servers for several days (an excellent torture test) and the initial bugs seem to have been shaken out. Anyway, I give it unto the world for them what wants it. Corrections and fixes welcomed. -- Regards, Tim Pierce RootsWeb Genealogical Data Cooperative system obfuscator and hack-of-all-trades --y0Ed1hDcWxc3B7cn Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="unhtml.c" /* * unhtml: parse a MIME multipart message and, if `multipart/alternative', * discard all but the `text/plain' part. * * This code is in the public domain except where noted otherwise. * * Tim Pierce * 3 June 1999 */ #include #include #include struct list { struct message *data; struct list *next; }; /* * The `message' struct is used to represent a MIME multipart message, * as defined in RFC 2045 and RFC 2046. * * The `header' and `preamble' fields are flat text arrays containg * the raw text of the message header and preamble (any text preceding * the first body part). In the case of a single-part message, the * `preamble' field is used to store the whole body. * * The `epilogue' field stores any text following the last body part. * * The `content_type' field contains the value of the message's * Content-Type header, minus any parameters: for example, * "text/plain". It is NULL if the message lacks a Content-Type * header. The `boundary' field contains the value of the `boundary' * parameter to the Content-Type field, if present. * * The `hsize' parameter is the size of the header, in bytes. The * `bsize' parameter is the size of the body, in bytes. These * parameters are not presently used and may be discarded. */ struct message { char *header; char *preamble; /* text (if any) preceding the first body-part */ char *epilogue; /* text (if any) following the last body-part */ char *content_type; char *boundary; int is8bit; /* does this message contain 8bit data? */ int hsize; /* bytes allocated for hdr (may be more than necessary) */ int bsize; /* bytes allocated for body (may be more than necessary) */ struct list *parts; }; struct message *mime_parse (char *body); void mime_write (struct message *msg); void mime_warn (char *s); void mime_fatal (char *s); void mime_destroy (struct message *msg); int check_msgtype (struct message *msg, char *type); void getheader (struct message *msg, char *hdrname, char **hdrvalp, int *hdrlen); char *next_boundary (char *body, char *boundary); int add_subpart (struct message *msg, struct message *part); void print_msg_info (struct message *msg, int indent); void mime_decode_qp (struct message *msg); void mime_decode_b64 (char *buf); void mime_output_qp (char *text); int main (argc, argv) int argc; char **argv; { struct message *msg; int len, c, last_char, bi, bsize; char *p, *body; if (argc > 1) { if (freopen (argv[1], "r", stdin) == NULL) { perror ("unhtml: freopening standard input"); exit(1); } } /* Read the message. */ bi = 0; body = (char *) malloc (sizeof(char) * 1000); if (body == NULL) { perror ("unhtml: could not malloc memory for body"); exit(1); } while ((len = read (fileno(stdin), body+bi, 1000)) == 1000) { bi += 1000; body = (char *) realloc (body, sizeof(char) * (bi+1000)); if (body == NULL) { perror ("unhtml: could not realloc memory for body"); exit(1); } } bsize = bi + len; body[bsize] = '\0'; msg = mime_parse (body); /* * Here's the important stuff: walk through the parts of a * multipart/alternative and look for a text/plain attachment. * If we find one, rewrite the headers of the parent message * (this is ugly) and output the text/plain body. */ if (msg->content_type && !strncasecmp (msg->content_type, "multipart/alternative", 21)) { struct list *p; for (p = msg->parts; p != NULL; p = p->next) { if (p->data->content_type == NULL || !strncasecmp (p->data->content_type, "text/plain", 10)) { /* XXX: Rewrite the headers. This is clumsy, and also * doesn't handle Content-Type or Content-Length if they're * the first headers in the message. */ char *cp; for (cp = msg->header; *cp; ++cp) { putchar (*cp); /* Skip Content-Length and Content-Transfer-Encoding. */ if (*cp == '\n' && (!strncasecmp (cp+1, "Content-Length:",15) || !strncasecmp (cp+1, "Content-Transfer-Encoding:", 26))) { do { cp = strchr (cp+1, '\n'); } while (cp != NULL && isspace(cp[1])); if (cp == NULL) break; } /* Rewrite Content-Type. */ if (*cp == '\n' && !strncasecmp (cp+1, "Content-Type:", 13)) { char *hp; int hlen; if (p->data->content_type) printf ("Content-Type: %s\n", p->data->content_type); /* Skip to next header. */ do { cp = strchr (cp+1, '\n'); } while (cp != NULL && isspace(cp[1])); if (cp == NULL) break; } } putchar ('\n'); puts (p->data->preamble); break; } } if (p != NULL) return 0; } /* * If we got here, either the message wasn't multipart/alternative * or it didn't have a text/plain component. In either case we * give up and write the original message to stdout. */ fputs (body, stdout); return 0; } /* * mime_parse: process an RFC 2046 multipart message and return * a message structure with all the necessary fields filled in. * * The BODY argument is a character array containing the raw text of the * message to be parsed. * * In the event of a fatal system error (should only happen in the * case of insufficient memory) or a fatal MIME parsing error, a * message will be printed on standard error and the return value * will be NULL. */ struct message * mime_parse (body) char *body; { char *p, *bodyp; int len; struct message *msg; /* Initialize the message. */ msg = (struct message *) malloc (sizeof(struct message)); if (msg == NULL) { perror ("unhtml: mime_parse could not malloc new message struct"); exit(1); } msg->header = NULL; msg->preamble = NULL; msg->epilogue = NULL; msg->content_type = NULL; msg->boundary = NULL; msg->parts = NULL; msg->is8bit = 0; /* Get the header. */ /* Special case for message with zero-length header. */ if (body[0] == '\n') { msg->hsize = 0; msg->header = (char *) malloc(sizeof(char)); if (msg->header == NULL) { perror ("unhtml: mime_parse could not malloc header buffer"); return NULL; } msg->header[0] = '\0'; bodyp = body + 1; } else { bodyp = strstr (body, "\n\n"); if (bodyp == NULL) { mime_fatal ("no message header found"); return NULL; } msg->hsize = bodyp - body + 1; msg->header = (char *) malloc (sizeof(char) * (msg->hsize+1)); if (msg->header == NULL) { perror ("unhtml: mime_parse could not malloc header buffer"); return NULL; } strncpy (msg->header, body, msg->hsize); msg->header[msg->hsize] = '\0'; bodyp += 2; } /* Find the content-type. */ getheader (msg, "Content-Type", &p, &len); if (p != NULL) { msg->content_type = (char *) malloc (sizeof(char) * (len + 1)); if (msg->content_type == NULL) { perror ("unhtml: mime_parse could not malloc Content-Type buffer"); mime_destroy (msg); return NULL; } strncpy (msg->content_type, p, len); msg->content_type[len] = '\0'; } /* * If this is a message/rfc822, then the body is an encapsulated * message. Parse it, attach the result to the current message, * and we're done. */ if (msg->content_type && !strcasecmp (msg->content_type, "message/rfc822")) { msg->parts = (struct list *) malloc (sizeof(struct list)); if (msg->parts == NULL) { perror ("unhtml: mime_parse could not malloc attachment list"); return NULL; } msg->parts->data = mime_parse (bodyp); msg->parts->next = NULL; return msg; } /* Find the message boundary. */ if (msg->content_type && !strncasecmp (msg->content_type, "multipart/", 10)) { /* Skip to next semicolon and see what keyword follows it. */ p = msg->content_type; while ((p = strchr (p, ';')) != NULL) { ++p; p += strspn (p, " \t\v\r\n"); if (strncasecmp (p, "boundary", 8) == 0) { char *dest; p += 8 + strspn (p+8, " \t\v\r\n"); if (*p++ != '=') { mime_fatal ("expected `=' after `boundary' parameter"); mime_destroy (msg); return NULL; } p += strspn (p, " \t\v\r\n"); dest = msg->boundary = (char *) malloc (strlen(p)); if (dest == NULL) { perror ("unhtml: mime_parse could not malloc boundary"); mime_destroy (msg); return NULL; } /* If next char is a quote, read the following quoted-string. */ if (*p == '"') { ++p; while (*p != '\0' && *p != '"') { if (*p == '\\') ++p; *dest++ = *p; ++p; } } else /* Generic non-special characters. */ { while (*p != '\0' && !strchr ("()<>@,;:\\\"/[]?=", *p)) { *dest++ = *p; ++p; } } *dest = '\0'; break; } } if (msg->boundary == NULL) { mime_fatal ("Content-Type lacks required `boundary' parameter"); mime_destroy (msg); return NULL; } } /* Break up multiparts. */ if (check_msgtype (msg, "multipart/")) { char *nextpart; struct message *part; /* Preamble. */ p = next_boundary (bodyp, msg->boundary); if (p == NULL) msg->preamble = strdup (bodyp); else { int psize = p - bodyp - strlen(msg->boundary) - 3; /* Special case: a boundary line may occur at the very beginning of the body, which means that no newline precedes it and psize is negative. */ if (psize < 0) psize = 0; msg->preamble = (char *) malloc (sizeof(char) * (psize+1)); if (msg->preamble == NULL) { perror ("unhtml: mime_parse could not malloc preamble buffer"); mime_destroy (msg); return NULL; } strncpy (msg->preamble, bodyp, psize); msg->preamble[psize] = '\0'; } /* Scan to each boundary and parse the body part contained therein. */ while (p != NULL && strncmp (p, "--\n", 3) != 0) { nextpart = next_boundary (++p, msg->boundary); if (nextpart == NULL) { char buf[512]; snprintf (buf, sizeof buf, "no terminating `%s' boundary found", msg->boundary); mime_warn (buf); break; } else { char *part_end = nextpart - strlen(msg->boundary) - 3; char c = *part_end; /* XXX: Parsing a body part should not require munging the buffer passed to mime_parse. */ *part_end = '\0'; part = mime_parse (p); *part_end = c; if (part == NULL) { mime_destroy (msg); return NULL; } if (!add_subpart (msg, part)) { mime_destroy (msg); return NULL; } } p = nextpart; } /* Get epilogue. */ if (p != NULL) { while (*p++ != '\n') ; if ((msg->epilogue = strdup(p)) == NULL) { perror ("unhtml: mime_parse could not strdup message epilogue"); mime_destroy (msg); return NULL; } } } else /* not multipart */ { msg->preamble = strdup (bodyp); if (msg->preamble == NULL) { perror ("unhtml: mime_parse could not strdup message body"); mime_destroy (msg); return NULL; } } /* Decode the body (preamble), if appropriate. */ getheader (msg, "Content-Transfer-Encoding", &p, &len); if (p != NULL) { if (!strncasecmp (p, "quoted-printable", len)) mime_decode_qp (msg); else if (!strncasecmp (p, "base64", len)) mime_decode_b64 (msg->preamble); else if (strncasecmp (p, "7bit", 4) != 0 && strncasecmp (p, "8bit", 4) != 0) mime_warn ("unknown Content-Transfer-Encoding"); } return msg; } /* * check_msgtype: check the type of a MIME message structure and return 1 if * the message is of the desired type, 0 otherwise. */ int check_msgtype (msg, type) struct message *msg; char *type; { return (msg->content_type && !strncasecmp (msg->content_type, type, strlen(type))); } /* * getheader: examine a MIME message for a particular header, and * record the location of that header's value (following the header name) * and its length (excluding the trailing newline). * * The MSG argument is a message structure containing a parsed MIME message. * The HDRNAME argument is the name of the desired header, e.g. "Content-Type". * The HDRVALP argument stores a pointer to the beginning of the header * contents, if that header is found in the message. * The HDRLEN argument stores the length of the header contents. */ void getheader (msg, hdrname, hdrvalp, hdrlen) struct message *msg; char *hdrname; char **hdrvalp; int *hdrlen; { char *p, *hvp; int hdrnamelen, hvlen; *hdrvalp = NULL; *hdrlen = 0; hdrnamelen = strlen(hdrname); p = msg->header; while (p != NULL) { if (strncasecmp (p, hdrname, hdrnamelen) == 0) { hvp = p + hdrnamelen; if (*hvp++ != ':') /* colon must follow header name */ continue; while (*hvp != '\0' && isspace(*hvp)) ++hvp; for (hvlen = 0; hvp[hvlen] != '\0'; ++hvlen) { if (hvp[hvlen] == '\n' && !isspace(hvp[hvlen+1])) { *hdrvalp = hvp; *hdrlen = hvlen; return; } } } p = strchr (p, '\n'); if (p) ++p; } } /* * next_boundary: find the next MIME multipart boundary in a message. * The return value is a pointer to the end of the boundary text, * or NULL if no boundary can be found in this message. * * The BODY argument is a character array containing the message body. * The BOUNDARY argument is a character array containing the boundary * delimiter. * * Because the return value points to the end of the boundary, it * will point to `\n' if this is an ordinary boundary or `--\n' if * it is a final boundary. */ char * next_boundary (body, boundary) char *body; char *boundary; { char *p; /* For efficiency reasons, look for the boundary first and then examine the characters around it. */ p = strstr (body, boundary); if (p != NULL && strncmp (p-3, "\n--", 3) == 0) return p + strlen(boundary); return NULL; } /* * add_subpart: append one message to the list of sub-parts for another * message. * * The argument MSG is a message structure representing a multipart message. * The argument PART is another message (possibly multipart) which is to * be added to MSG's list of sub-parts. * * Return 1 on success. If a fatal error arises, return 0. */ int add_subpart (msg, part) struct message *msg; struct message *part; { struct list *p; if (msg->parts == NULL) { msg->parts = (struct list *) malloc (sizeof(struct list)); if (msg->parts == NULL) { perror ("unhtml: add_subpart could not malloc attachment list"); return 0; } msg->parts->data = part; msg->parts->next = NULL; } else { for (p = msg->parts; p->next != NULL; p = p->next) ; p = p->next = (struct list *) malloc (sizeof(struct list)); if (p == NULL) { perror ("unhtml: add_subpart could not malloc attachment buffer"); return 0; } p->data = part; p->next = NULL; } return 1; } void mime_write (msg) struct message *msg; { if (msg->header) { fputs (msg->header, stdout); putc ('\n', stdout); } /* message/rfc822 needs special handling. */ if (msg->content_type && !strncasecmp (msg->content_type, "message/rfc822", 14)) { mime_write (msg->parts->data); return; } /* XXX: watch out for 8bit data here. */ fputs (msg->preamble, stdout); if (msg->parts != NULL) { struct list *p; for (p = msg->parts; p != NULL; p = p->next) { printf ("\n--%s\n", msg->boundary); mime_write (p->data); } printf ("\n--%s--\n", msg->boundary); fputs (msg->epilogue, stdout); } } void mime_warn (s) char *s; { fprintf (stderr, "MIME parser: warning: %s\n", s); } void mime_fatal (s) char *s; { fprintf (stderr, "MIME parser: fatal: %s\n", s); } void mime_destroy (msg) struct message *msg; { struct list *p, *q; if (msg->header != NULL) free (msg->header); if (msg->preamble != NULL) free (msg->preamble); if (msg->epilogue != NULL) free (msg->epilogue); if (msg->content_type != NULL) free (msg->content_type); if (msg->boundary != NULL) free (msg->boundary); p = msg->parts; while (p != NULL) { if (p->data != NULL) mime_destroy (p->data); q = p; p = p->next; free (q); } } void print_msg_info (msg, indent) struct message *msg; int indent; { char indbuf[80]; indbuf[indent--] = '\0'; while (indent >= 0) indbuf[indent--] = ' '; printf ("%sHeader:\n", indbuf); printf ("%s--BEGIN--\n", indbuf); printf ("%s\n", msg->header); printf ("%s--END--\n", indbuf); printf ("%sContent-Type: %s\n", indbuf, msg->content_type); printf ("%sBoundary: %s\n", indbuf, msg->boundary); printf ("%s----------------------------------------\n", indbuf); if (msg->parts != NULL) { struct list *p; for (p = msg->parts; p != NULL; p = p->next) { print_msg_info (p->data, indent + 4); } } } int hex2dec_char(ch) char ch; { if (isdigit(ch)) return ch-'0'; else if (isupper(ch)) return ch-'A'+10; else return ch-'a'+10; } /* * mime_decode_qp: convert the preamble of MSG from a quoted-printable * encoding to raw text. */ void mime_decode_qp (msg) struct message *msg; { unsigned char *src, *dst; dst = src = msg->preamble; while (*src != '\0') { if (*src == '=') { if (*++src == '\n') { ++src; continue; } else { int hi, lo; hi = hex2dec_char(*src++); lo = hex2dec_char(*src); *dst = hi*16 + lo; if (*dst > 0x7f) msg->is8bit = 1; } } else *dst = *src; ++dst, ++src; } } void mime_output_qp (text) char *text; { /* XXX: write this. */ } /* * The char64 macro and `mime_decode_b64' routine are taken from * metamail 2.7, which is copyright (c) 1991 Bell Communications * Research, Inc. (Bellcore). The following license applies to all * code below this point: * * Permission to use, copy, modify, and distribute this material * for any purpose and without fee is hereby granted, provided * that the above copyright notice and this permission notice * appear in all copies, and that the name of Bellcore not be * used in advertising or publicity pertaining to this * material without the specific, prior written permission * of an authorized representative of Bellcore. BELLCORE * MAKES NO REPRESENTATIONS ABOUT THE ACCURACY OR SUITABILITY * OF THIS MATERIAL FOR ANY PURPOSE. IT IS PROVIDED "AS IS", * WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES. */ static char index_64[128] = { -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,62, -1,-1,-1,63, 52,53,54,55, 56,57,58,59, 60,61,-1,-1, -1,-1,-1,-1, -1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9,10, 11,12,13,14, 15,16,17,18, 19,20,21,22, 23,24,25,-1, -1,-1,-1,-1, -1,26,27,28, 29,30,31,32, 33,34,35,36, 37,38,39,40, 41,42,43,44, 45,46,47,48, 49,50,51,-1, -1,-1,-1,-1 }; #define char64(c) (((c) < 0 || (c) > 127) ? -1 : index_64[(c)]) void mime_decode_b64 (src) char *src; { char *dst; int c1, c2, c3, c4; int newline = 1, DataDone = 0; dst = src; while ((c1 = *src++) != '\0') { if (isspace(c1)) { if (c1 == '\n') { newline = 1; } else { newline = 0; } continue; } if (DataDone) continue; newline = 0; do { c2 = *src++; } while (c2 != '\0' && isspace(c2)); do { c3 = *src++; } while (c3 != '\0' && isspace(c3)); do { c4 = *src++; } while (c4 != '\0' && isspace(c4)); if (c2 == '\0' || c3 == '\0' || c4 == '\0') { fprintf(stderr, "Warning: base64 decoder saw premature EOF!\n"); return; } if (c1 == '=' || c2 == '=') { DataDone=1; continue; } c1 = char64(c1); c2 = char64(c2); *dst++ = (c1<<2) | ((c2&0x30)>>4); if (c3 == '=') DataDone = 1; else { c3 = char64(c3); *dst++ = ((c2&0XF) << 4) | ((c3&0x3C) >> 2); if (c4 == '=') DataDone = 1; else { c4 = char64(c4); *dst++ = ((c3&0x03) <<6) | c4; } } } *dst = '\0'; } --y0Ed1hDcWxc3B7cn-- From list-managers-owner Mon Jun 7 06:10:37 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id GAA29544; Mon, 7 Jun 1999 06:01:07 -0700 (PDT) Received: from FSM-1.PICA.ARMY.MIL (fsm-1.pica.army.mil [129.139.96.87]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id GAA29537 for ; Mon, 7 Jun 1999 06:01:01 -0700 (PDT) Date: Mon, 7 Jun 99 9:06:39 EDT From: Info-LabVIEW List Maintainer To: list-managers@greatcircle.com Subject: Yahoo error msg query Message-ID: <9906070906.aa17762@fsm-1.fsm-1.pica.army.mil> Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Anyone have a clue what the heck this one means? I'm _guessing_ it's some sort of transient problem, although I must admit that I'd never seen it before last week, and now I seem to get them on a fairly regular basis. Date: 7 Jun 1999 05:41:29 -0700 From: MAILER-DAEMON@yahoo.com To: owner-bmwmc-digest@lists.ibmwr.org Subject: failed delivery Message from yahoo.com. Unable to deliver message to the following address(es). : preline: fatal: command not found : preline: fatal: command not found : preline: fatal: command not found : preline: fatal: command not found : preline: fatal: command not found : preline: fatal: command not found : preline: fatal: command not found : preline: fatal: command not found : preline: fatal: command not found : preline: fatal: command not found : preline: fatal: command not found : preline: fatal: command not found : preline: fatal: command not found : preline: fatal: command not found : preline: fatal: command not found : preline: fatal: command not found --- Original message follows. Return-Path: The original message is over 5k. Message truncated to 1K. Received: from europe.std.com (199.172.62.20) by mta102.yahoomail.com with SMTP; 7 Jun 1999 05:41:27 -0700 Received: by europe.std.com (STD1.2/BZS-8-1.0) [...] Tom Coradeschi, Info-LabVIEW List Maintainer http://k-whiner.pica.army.mil/info-labview/info-labview.html From list-managers-owner Mon Jun 7 09:56:06 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id JAA01867; Mon, 7 Jun 1999 09:46:15 -0700 (PDT) Received: from claude.akamai.com (access.akamai.com [4.17.143.9]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id JAA01860 for ; Mon, 7 Jun 1999 09:46:04 -0700 (PDT) Received: (from dshaw@localhost) by claude.akamai.com (8.8.7/8.8.7) id MAA13815 for list-managers@GreatCircle.COM; Mon, 7 Jun 1999 12:51:47 -0400 Date: Mon, 7 Jun 1999 12:51:47 -0400 From: David Shaw To: list-managers@GreatCircle.COM Subject: Re: Yahoo error msg query Message-ID: <19990607125147.B13586@jabberwocky.com> Mail-Followup-To: list-managers@GreatCircle.COM References: <9906070906.aa17762@fsm-1.fsm-1.pica.army.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <9906070906.aa17762@fsm-1.fsm-1.pica.army.mil>; from Info-LabVIEW List Maintainer on Mon, Jun 07, 1999 at 09:06:39AM -0400 X-PGP-Fingerprint: 3CB3B415/2048/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Crescent (45% of Full) X-Current-Email-Backlog: 451 X-Pointless-Random-Number: 57 X-Silly-Header: It sure is. X-Time-Til-Y2K: 29 weeks, 4 days, 12 hours, 9 minutes, 9 seconds Sender: list-managers-owner@GreatCircle.COM Precedence: bulk On Mon, Jun 07, 1999 at 09:06:39AM -0400, Info-LabVIEW List Maintainer wrote: > Anyone have a clue what the heck this one means? I'm _guessing_ it's some > sort of transient problem, although I must admit that I'd never seen it > before last week, and now I seem to get them on a fairly regular basis. I have no particular information about it aside to say that I've also been getting them. I figured it was just Yahoo feeling the pain of providing a free, and heavily loaded, service :) David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From list-managers-owner Mon Jun 7 11:25:29 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id LAA02877; Mon, 7 Jun 1999 11:20:45 -0700 (PDT) Received: from ivan.iecc.com (ivan.iecc.com [208.31.42.33]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id LAA02870 for ; Mon, 7 Jun 1999 11:20:38 -0700 (PDT) Received: (qmail 11491 invoked by uid 100); 7 Jun 1999 14:25:57 -0400 Date: Mon, 7 Jun 1999 14:25:57 -0400 (EDT) From: John R Levine To: Info-LabVIEW List Maintainer cc: list-managers@greatcircle.com Subject: Re: Yahoo error msg query In-Reply-To: <9906070906.aa17762@fsm-1.fsm-1.pica.army.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: list-managers-owner@GreatCircle.COM Precedence: bulk > Anyone have a clue what the heck this one means? Yahoo seems to have made a teensy config error that hosed mail to all of their gazillion free mail accounts. Maybe they'll notice and fix it, although discussions on other lists about how hard it is to contact a live human at Yahoo don't give me great hope. > : > preline: fatal: command not found Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4 2D AC 1E 9E A6 36 A3 47 From list-managers-owner Mon Jun 7 21:25:35 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id VAA09723; Mon, 7 Jun 1999 21:23:17 -0700 (PDT) Received: from plaidworks.com (plaidworks.com [209.239.169.200]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id VAA09716 for ; Mon, 7 Jun 1999 21:23:11 -0700 (PDT) Received: from (a197.plaidworks.com [209.239.169.197] (may be forged)) by plaidworks.com (8.9.1a/8.9.1) with ESMTP id VAA33402 ; Mon, 7 Jun 1999 21:28:09 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 7 Jun 1999 21:27:13 -0700 To: John R Levine , Info-LabVIEW List Maintainer From: Chuq Von Rospach Subject: Re: Yahoo error msg query Cc: list-managers@GreatCircle.COM Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: list-managers-owner@GreatCircle.COM Precedence: bulk > Yahoo seems to have made a teensy config error that hosed mail to all of > their gazillion free mail accounts. Maybe they'll notice and fix it, > although discussions on other lists about how hard it is to contact a live > human at Yahoo don't give me great hope. Even more fun -- it's intermittent. I'm only seeing it on some mail. And THAT tells me that ONE of their servers is screwed up, and until they figure it out and find which server is blowing its cookies, it'll continue. Because most of my mail seems to be going through okay, but every so often, it dumps on a given message. Since they have multiple, round-robinned MX hosts, all you need is one flakey machine to make your day... -- Chuq Von Rospach (Hockey fan? ) Apple Mail List Gnome (mailto:chuq@apple.com) Plaidworks Consulting (mailto:chuqui@plaidworks.com) + Snakes and trees aren't natural enemies -- but if the tree attacks first... (Ranger Gord, The Red Green Show) From list-managers-owner Tue Jun 8 16:46:30 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id QAA06139; Tue, 8 Jun 1999 16:40:24 -0700 (PDT) Received: from bigtime.blank.org (bigtime.blank.org [139.167.64.222]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id QAA06130 for ; Tue, 8 Jun 1999 16:40:17 -0700 (PDT) Received: (qmail 1716 invoked by uid 500); 8 Jun 1999 23:39:33 -0000 Message-ID: <19990608193933.P12737@blank.org> Date: Tue, 8 Jun 1999 19:39:33 -0400 From: "Nathan J. Mehl" To: list-managers@greatcircle.com Subject: dear lord. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Will the person who thought that it would be a bright idea for ibm.net's bounce messages to have the same "From" and "To" lines of the message being bounced please kill themselves in the name of all that is holy? Thank you, that is all. -n (no, I'm not kidding. they're really doing this.) ------------------------------------------------------ "Hunting porn on the Internet combines the best of art photography (pictures of people's private parts) with the excitement of video games (hunt, click, hunt, click, click, dirty pictures -- score!)." (--Dan Savage) ------------------------------------------ From list-managers-owner Sat Jun 12 15:12:29 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id OAA13402; Sat, 12 Jun 1999 14:50:24 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id OAA13392 for list-managers@greatcircle.com; Sat, 12 Jun 1999 14:50:21 -0700 (PDT) Received: from polaris.coppernet.zm (polaris.zccm.zm [194.130.159.16]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id AAA02485 for ; Sat, 12 Jun 1999 00:17:38 -0700 (PDT) Received: from localhost by polaris.coppernet.zm with SMTP (1.38.193.5/16.2) id AA22374; Sat, 12 Jun 1999 09:12:59 +0200 Message-Id: <3762087A.4562@coppernet.zm> Date: Sat, 12 Jun 1999 09:12:58 +0200 From: Wilbroad Chisanga Kasopa X-Mailer: Mozilla 3.0 (X11; I; HP-UX A.09.04 9000/867) Mime-Version: 1.0 To: list-managers@GreatCircle.COM Subject: Seeking a solution Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Hello, I am having problems with the footer message. I have created info files for the mailing lists but the files are not attached to the messages sent. The footer message only works when I include this message in the config files, when I include any attachment to my message the footer message dissappears. I am running Majordomo-1.94.4. The permissions seem to be alright. Anyone with a solution? Wilbroad. -- Wilbroad C Kasopa, url: http://www.coppernet.zm Corporate IT, e:mail: kasopaw@coppernet.zm P O Box 20172, FAX#:+260 2 245437 KITWE - ZAMBIA. Voice:+260 2 245200 :=)(=: I am in the Real Africa :=)(=: http://www.africa-insites.com/zambia From list-managers-owner Fri Jun 25 19:57:32 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id TAA07416; Fri, 25 Jun 1999 19:43:36 -0700 (PDT) Received: from mushi.colo.neosoft.com (mushi.colo.neosoft.com [206.109.6.82]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id TAA07409 for ; Fri, 25 Jun 1999 19:43:30 -0700 (PDT) Received: (qmail 22712 invoked from network); 26 Jun 1999 02:43:05 -0000 Received: from bonkers.neosoft.com (HELO bonkers.taronga.com) (206.109.2.48) by mushi.colo.neosoft.com with SMTP; 26 Jun 1999 02:43:05 -0000 Received: (from arielle@localhost) by bonkers.taronga.com (8.9.1/8.9.1) id VAA08218 for list-managers@greatcircle.com; Fri, 25 Jun 1999 21:41:57 -0500 (CDT) (envelope-from arielle) From: Stephanie da Silva Message-Id: <199906260241.VAA08218@bonkers.taronga.com> Subject: Teachers instructing students to join lists for coursework To: list-managers@greatcircle.com Date: Fri, 25 Jun 1999 21:41:57 -0500 (CDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Very recently, I received a piece of email that went: "I'm a student and for an assignment I'm supposed to j0in a listserv (sic). I have no idea what this is, so will you please tell me everything I need to know? [she'd also filled out the submit form on the PAML a couple times, so I got some random junk as an accompaniment.] Unfortunately, I had just woken up and not even having had my first Diet Coke of the day, chastised her somewhat severely. Was kind of funny, I referred to her instructor as "moronic". However, I do think her instructor is being rather lax if she's directing her students to go j0in a mailing list without telling them what one is, how to zubscribe, how to unzubscribe, plus failing to explain the distinction between terms like "mailing list" and "LISTSERV". Student passed my mail to teacher, her response is below. It appears she thinks this practice is acceptable and does not consider the impact it makes upon list owners. However, since she says she'll remove one's "group" from their course, please feel free to email her requesting she remove yours. Forwarded message: > From bcox@bunny.chaffey.cc.ca.us Fri Jun 25 19:19:57 1999 > Date: Fri, 25 Jun 1999 10:52:44 +0100 > From: Beverly Cox > Subject: (no subject) > To: arielle@Taronga.COM > Message-id: <3773516C.9D05DBAD@chaffey.cc.ca.us> > Organization: Chaffey College > MIME-version: 1.0 > X-Mailer: Mozilla 4.05 [en] (WinNT; I) > Content-type: text/plain; charset=us-ascii > Content-transfer-encoding: 7bit > > Who are you? AND what listserv do you proctor? I will try not to have my > students j0in unprofessional groups in the future. You are the first > proctor who ever complained. I apologize for my 'moronic' behavior. I > will forward your message to all my 'moronic' cohorts here and in the > Cal State system where I work so we do not make the mistake of including > your group in our course work. My apologies again. Beverly Cox From list-managers-owner Fri Jun 25 22:27:32 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id WAA08895; Fri, 25 Jun 1999 22:22:40 -0700 (PDT) Received: from plaidworks.com (plaidworks.com [209.239.169.200]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id WAA08888 for ; Fri, 25 Jun 1999 22:22:33 -0700 (PDT) Received: from (a197.plaidworks.com [209.239.169.197] (may be forged)) by plaidworks.com (8.9.1a/8.9.1) with ESMTP id WAA36654 ; Fri, 25 Jun 1999 22:18:45 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <199906260241.VAA08218@bonkers.taronga.com> References: <199906260241.VAA08218@bonkers.taronga.com> Date: Fri, 25 Jun 1999 22:17:51 -0700 To: Stephanie da Silva , list-managers@GreatCircle.COM From: Chuq Von Rospach Subject: Re: Teachers instructing students to join lists for coursework Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: list-managers-owner@GreatCircle.COM Precedence: bulk At 9:41 PM -0500 6/25/99, Stephanie da Silva wrote: > Student passed my mail to teacher, her response is below. It > appears she thinks this practice is acceptable and does not consider > the impact it makes upon list owners. Oh, heck. this stuff is old hat. it's just new that they're doing it at listservers. There are teachers who assign coursework without worrying about the impact on others (didn't we all have a teacher in college who for some reason assumed their class was the only one you were taking that semester?) We see these kind of requests on a regular basis, where teachers assign students to do some research on stuff. Since we run a hockey-history oriented web site, we get a lot of canadian kids writing us to answer questions (or write their paper for them...). Occasionally, we get one where the requests are somewhat over the top. We deal with those either by discussing it with the teacher directly, or by random cases of intermittent deafness. But in general, if you're running public resources, it shouldn't surprise you that they get used as a resource. And occasionally, someone has a different idea of what acceptable use is. Teachers are, in general, horribly underworked and overpaid. I'm generally willing to cut them some slack because they're doing a tough job in a culture where an athlete could make enough in a year to fund many schools, while the teacher is there paying for pencils out of their own pocket because the school has no budget. (but there are limits). In a case like this, I'd simply point the user at my list documentation. If the list documentation isn't good enough to walk them through it, it needs to be fixed. if they simply want me to do it for them, then the user needs to be fixed, and I'd treat it like any user who thinks I'm their paid servant... Yes, the instructor ought to be more proactive about stuff like this, but most likely, tey're already doing 60-70 hour weeks, and I can understand if they don't necessarily agree with me on it. By the way, if she's at cc.ca.us that's a Community College campus, aka a junior college or 2 year school. Wchih means she's quite far down the teaching totem pole, so to speak, and you should keep that in mind as well. Some people teach at those schools because they teach part time or teach something they really care for (my mother loves the local CC for their art classes, for instance). But most people teach there because they haven't gotten the degrees or the ability to teach at a higher level.... -- Chuq Von Rospach (Hockey fan? ) Apple Mail List Gnome (mailto:chuq@apple.com) Plaidworks Consulting (mailto:chuqui@plaidworks.com) + Snakes and trees aren't natural enemies -- but if the tree attacks first... (Ranger Gord, The Red Green Show) From list-managers-owner Sat Jun 26 01:29:24 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id BAA10286; Sat, 26 Jun 1999 01:03:11 -0700 (PDT) Received: from server.postmodern.com (server.postmodern.com [209.157.82.3]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id BAA10279 for ; Sat, 26 Jun 1999 01:03:05 -0700 (PDT) Received: from postmodern.com (foucault.postmodern.com [209.157.82.5]) by server.postmodern.com (8.8.5/mcb-980201) with ESMTP id BAA03075; Sat, 26 Jun 1999 01:03:21 -0700 (PDT) Message-ID: <37748949.E77A8DC7@postmodern.com> Date: Sat, 26 Jun 1999 01:03:22 -0700 From: "Michael C. Berch" Reply-To: mcb@postmodern.com Organization: Postmodern Consulting, California USA X-Mailer: Mozilla 4.6 (Macintosh; U; PPC) X-Accept-Language: en-US MIME-Version: 1.0 To: list-managers@GreatCircle.COM Subject: Re: Teachers instructing students to join lists for coursework References: <199906260241.VAA08218@bonkers.taronga.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Well, the content of the letters notwithstanding, I think Stephanie has earned her new nickname of "The Proctor"... :-) I'm now waiting for someone to found the List-Proctors mailing list. -- Michael C. Berch mcb@postmodern.com From list-managers-owner Sat Jun 26 01:42:32 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id BAA10322; Sat, 26 Jun 1999 01:09:29 -0700 (PDT) Received: from mushi.colo.neosoft.com (mushi.colo.neosoft.com [206.109.6.82]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id BAA10315 for ; Sat, 26 Jun 1999 01:09:23 -0700 (PDT) Received: (qmail 6948 invoked from network); 26 Jun 1999 08:08:52 -0000 Received: from bonkers.neosoft.com (HELO bonkers.taronga.com) (206.109.2.48) by mushi.colo.neosoft.com with SMTP; 26 Jun 1999 08:08:52 -0000 Received: (from arielle@localhost) by bonkers.taronga.com (8.9.1/8.9.1) id DAA14198; Sat, 26 Jun 1999 03:07:44 -0500 (CDT) (envelope-from arielle) From: Stephanie da Silva Message-Id: <199906260807.DAA14198@bonkers.taronga.com> Subject: Re: Teachers instructing students to join lists for coursework To: list-managers@GreatCircle.COM Date: Sat, 26 Jun 1999 03:07:43 -0500 (CDT) Cc: bcox@bunny.chaffey.cc.ca.us X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Chuck as usual very graciously intonates: > Oh, heck. this stuff is old hat. it's just new that they're doing it > at listservers. There are teachers who assign coursework without > worrying about the impact on others ... > > Yes, the instructor ought to be more proactive about stuff like this, > but most likely, tey're already doing 60-70 hour weeks, and I can > understand if they don't necessarily agree with me on it. > > By the way, if she's at cc.ca.us that's a Community College campus, > aka a junior college or 2 year school. ... But most > people teach there because they haven't gotten the degrees or the > ability to teach at a higher level.... Well, yes, I knew this stuff already. :-P It's just I know the people on this list are clever enough to figure all this stuff out that I don't have to spell it out for them. :-) Although I disagree with you about it's new about mailing lists and MLM's. I've been seeing this sort of stuff for years from Introduction to the Internet 101, Lesson 4 - Exercise 2: Go to this ftp/web site that has a lot of mailing lists referenced, find a random list, s*bscr*be, uns*bscr*be, then provide a printout with evidence of your doing so, etc, etc. But my point was (I should have made it better) is that this teacher thinks it's okay because no one has complained to her about it! So maybe if she got a few list owners explaining that it's not a very swift practice and why, she might see the light. I tend to sound confrontational even when I'm not trying to be, so I always think there's someone out there who can do say more eloquently than I can. From list-managers-owner Sat Jun 26 11:00:39 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id KAA18643; Sat, 26 Jun 1999 10:50:24 -0700 (PDT) Received: from shell7.ba.best.com (shell7.ba.best.com [206.184.139.138]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id KAA18634 for ; Sat, 26 Jun 1999 10:50:15 -0700 (PDT) Received: (from cnorman@localhost) by shell7.ba.best.com (8.9.3/8.9.2/best.sh) id KAA12391; Sat, 26 Jun 1999 10:50:34 -0700 (PDT) Date: Sat, 26 Jun 1999 10:50:34 -0700 (PDT) Message-Id: <199906261750.KAA12391@shell7.ba.best.com> From: Cyndi Norman To: list-managers@GreatCircle.COM CC: cnorman@best.com In-reply-to: <199906260241.VAA08218@bonkers.taronga.com> (message from Stephanie da Silva on Fri, 25 Jun 1999 21:41:57 -0500 (CDT)) Subject: Re: Teachers instructing students to join lists for coursework Reply-to: cnorman@best.com Sender: list-managers-owner@GreatCircle.COM Precedence: bulk From: Stephanie da Silva Date: Fri, 25 Jun 1999 21:41:57 -0500 (CDT) Very recently, I received a piece of email that went: "I'm a student and for an assignment I'm supposed to j0in a listserv (sic). I have no idea what this is, so will you please tell me everything I need to know? Sheesh...that's particulary bad if they ask you what a listserv is. I've had plenty who just joined then left. Really pissed me off back when I was doing the list by hand. My policy (which I really need to put on my website) is that students are welcome to join for the CONTENT of the list (many do) as long as they unsub themselves when they are done. I do not "allow" (in quotes because I have no control over it) students to join and leave merely for practice in joining and leaving lists. Though this isn't much worse than all the letters I get from students (and sometimes parents!!) saying "I have to write a paper on the immune system, please send me information. It's due on Tuesday." Never mind that my list/site is not about the immune system (it's a support group for people with illness related to the immune system...big difference...and very obvious to anyone who reads the front page of the site or the list blurb). I always write back explaining that I am not paid to help them but their librarian is and that's where they should go (if I get a truely specific and related question I will answer it...I also answer personal questions, no matter how silly ("should I take antibiotics for my viral infection?")). The responses I get from my polite letters are truely amazing. Some of the students yell at me or give me a sarcastic "thanks for helping." Some say their teachers required them to do the research on the internet (which is fine if they actually look up webpages and read them). Worst of all, many of the students indicate they have written large numbers of people for help (they thank me for at least giving them the curtosy of a reply, unlike all the others, despite how unhelpful I was). I think the worst example I've ever seen was on rec.gardens where a European parent wrote asking people to tell her what Plains Indians ate before Europeans arrived. This was for her child's school report. I wrote saying: send your child to the local library and stop doing their homework for them. Cyndi -- _______________________________________________________________________________ "There's nothing wrong with me. Maybe there's Cyndi Norman something wrong with the universe." (ST:TNG) cyndi@consultclarity.com http://www.consultclarity.com/ _________________ Owner of the Immune Website & Lists http://www.immuneweb.org/ From list-managers-owner Sat Jun 26 13:15:25 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id NAA19794; Sat, 26 Jun 1999 13:06:34 -0700 (PDT) Received: from mail.frostburg.edu (mail.frostburg.edu [131.118.64.250]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id NAA19787 for ; Sat, 26 Jun 1999 13:06:28 -0700 (PDT) Received: from 209.201.108.81 (dial108x81.gcnet.net) by mail.frostburg.edu (Sun Internet Mail Server sims.3.5.1998.08.08.00.06) with ESMTP id <0FDY00D4KABSTL@mail.frostburg.edu> for list-managers@GreatCircle.COM; Sat, 26 Jun 1999 16:02:20 -0400 (EDT) Date: Sat, 26 Jun 1999 16:05:41 +0100 From: Bill Southerly Subject: Re: Moderating and off-topic posts To: list-managers@GreatCircle.COM Reply-to: e2pysou@fre.fsu.umd.edu Message-id: <3774EC3F.ABF67C33@fre.fsu.umd.edu> Organization: Frostburg State University MIME-version: 1.0 X-Mailer: Mozilla 4.01 (Macintosh; I; PPC) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: X-Priority: 3 (Normal) Sender: list-managers-owner@GreatCircle.COM Precedence: bulk I wanted to expand this discussion that occurred last month on how to deal with off-topic posts and posters. I run an unmoderated list that deals with the teaching of psychology and has anywhere from 500-1500 subscribers depending on the time of year. It seems I always have one person who tends to ask questions that are in that grey area of whether it is legitimate for the group (when you are dealing with the teaching of human behavior you can make a logical case for almost anything) and seems to be worded in order to stir up controversy for the sake of controversy. This person quickly develops strong supporters in the group for his right to offer these type of questions (e.g., the free speech arguments) and logical arguments why they are related to the groups discussion of teaching (e.g., these are the type of questions students often ask) and strong non-supporters who reject anything the person says as useless or in some instances racist, sexist, etc (though in each instance the statements are open to interpretation). We then typically start into a discussion of whether this person should be able to ask these type of questions. This happens every few months and we are in the middle of one now. Any suggestions or experiences in dealing with the type of subscriber that seems to know how to play the edge and generate this type of off-topic discussion that focuses on them and not the primary focus of the group? Thanks. Bill ********************************************************* * * * TIPS LISTOWNER - CONTACT DIRECTLY IF YOU HAVE PROBLEMS * * BILL SOUTHERLY INTERNET: BSOUTHERLY@FROSTBURG.EDU * * DEPT. OF PSYCHOLOGY E2PYTIPS@FRE.FSU.UMD.EDU * * FROSTBURG STATE UNIVERSITY TIPSOWNER@FRE.FSU.UMD.EDU * * FROSTBURG, MARYLAND USA 21532 PHONE : (301) 687-4778 * * * ********************************************************** From list-managers-owner Sat Jun 26 15:45:45 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id OAA21550; Sat, 26 Jun 1999 14:51:17 -0700 (PDT) Received: (mcb@localhost) by honor.greatcircle.com (8.8.5/Honor-980202-1) id OAA21540 for list-managers@greatcircle.com; Sat, 26 Jun 1999 14:51:14 -0700 (PDT) Received: from sendmail.kirkland.com (sendmail.kirkland.com [137.169.20.245]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id NAA03762 for ; Fri, 25 Jun 1999 13:38:28 -0700 (PDT) Received: from mkleiman ([137.169.215.53] (may be forged)) by sendmail.kirkland.com (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP id PAA28801 for ; Fri, 25 Jun 1999 15:38:45 -0500 Reply-To: From: "Matthew N. Kleiman" To: Subject: Long Lines Date: Fri, 25 Jun 1999 15:41:21 -0500 Message-ID: <000301bebf4b$166012c0$35d7a989@mkleiman.chicago.kirkland.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: list-managers-owner@GreatCircle.COM Precedence: bulk I recently coded a "robomoderator" to reject attachments, html encoding, vacation notices, etc. Without much additional thought, I also programmed the robomoderator to reject any message with any line longer than 80 characters (excluding headers). To my surprise, this has been the most common problem "solved" by the robomoderator ... approximately 1 in 30 messages sent to the list have long lines. I've always believed that a well-behaved email client will wrap long lines before sending email, on the premise that some email programs don't have a word wrap feature. I simply assumed it was the _sender's_ obligation to wrap long lines, not the recipient's. However, upon further research, the internet email protocals clearly permit line lengths up to 1000 characters (rfc 821). This perhaps suggests that it's the _recipient's_ job to wrap long lines, not the sender's. On the other hand, even if long lines are "legal," that doesn't necessarily make them "polite." The recipient may not have a word wrap function, or the recipient's program may break long lines at incorrect places, impairing legibility. I'm fairly confident that every modern email program has a word wrap function, so imposing this rule on list subscribers should not impose a great burden. At the same time, I hate to see subscriber's messages get bounced, especially novices, to whom the 80 character limitation may seem arbitrary and make little sense given modern email clients. (After all, how many of you know the *original* derivation of the 80 character rule of thumb? Answer at the end of this email.) So, without a clear rule to guide me, I'm curious whether other list managers have a rule/policy on long lines and why. Any input would be appreciated. - Matt (Only half credit if you said that old computer terminals had 80 character screen widths ... full credit if you said that standard computer punch cards had 80 columns.) Matthew N. Kleiman * Chicago * Illinois * mailto:matt@berner.org Author * Bernese Mountain Dog Home Page * http://www.berner.org/ Administrator * berner-l@prairienet.org * Berner-L Mailing List Questions? Need help? * http://www.berner.org/faq * Berner-L FAQ From list-managers-owner Sat Jun 26 17:32:26 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id RAA23133; Sat, 26 Jun 1999 17:11:20 -0700 (PDT) Received: from smtp2.vnet.net (smtp2.vnet.net [166.82.1.32]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id RAA23126 for ; Sat, 26 Jun 1999 17:11:14 -0700 (PDT) Received: from katie.vnet.net (katie.vnet.net [166.82.1.7]) by smtp2.vnet.net (8.9.1a/8.9.1) with ESMTP id UAA01581; Sat, 26 Jun 1999 20:12:15 -0400 (EDT) Received: from localhost (murr@localhost) by katie.vnet.net (8.9.1a/8.8.8) with ESMTP id UAA07004; Sat, 26 Jun 1999 20:11:41 -0400 (EDT) X-Authentication-Warning: katie.vnet.net: murr owned process doing -bs Date: Sat, 26 Jun 1999 20:11:41 -0400 (EDT) From: murr rhame To: Bill Southerly cc: list-managers@GreatCircle.COM Subject: Re: Moderating and off-topic posts In-Reply-To: <3774EC3F.ABF67C33@fre.fsu.umd.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: list-managers-owner@GreatCircle.COM Precedence: bulk On Sat, 26 Jun 1999, Bill Southerly wrote: > ... This person quickly develops strong supporters in the group > for his right to offer these type of questions (e.g., the free > speech arguments) and logical arguments why they are related to > the groups discussion of teaching (e.g., these are the type of > questions students often ask) ... Note that the following is my opinion based on my experience running my own discussion lists. There are very few universal solutions, appropriate for all mailing lists. Each list admin should do what is best for their own particular situation. The first thing to remember is that, in most cases, the list admin is the boss. Most mailing lists are not democracies. The admin doesn't have to answer to anyone or make apologies for their decisions. This is not to say that all admins can act capriciously. If you are too heavy handed, your subscribers will go elsewhere. Typically, the list admin is the host of invited guests who are on the admin's turf. Act accordingly. Personally, I don't have much sympathy for folks who insist that they have an absolute and unconstrained right to free speech. There are almost always limits to freedom of speech. First amendment rights have never been interpreted as the right to say anything, anywhere, any time, particularly when the speech is at someone else's expense. You can't hijack the forum of your choice to do with as you please either online or off. If you doubt this principle, go to a public event and demand the right to make a completely off-topic speech. This won't cut it at a basket ball game, a theatrical production, a rock concert, a church service or even most political rallies. Similar rules apply to most administered online forums. The admin can set the agenda (charter) and enforce the agenda if need be. Most of the time, I've found that diplomacy by private email can steer a list away from off-topic threads. Occasionally, a public announcement is needed. On one extraordinary occasion an exceptionally ugly flame war forced me to switch one of my lists to full-blown, software controlled, moderation for a few days. The exact method used to guide a list is not as important as establishing guidelines. Take care in defining a charter for your list. Specify both the topics which are appropriate and areas that are off topic. The tricky part is to write in a manner that is not so vague that you can't understand it and is not too specific as to be overly confining. You should also specify list netiquette guidelines in a similar manner. Once you have the charter, publish it on the list. Mail it to every new subscriber. Let it be known that the charter is "the law of the land" for your mailing list. If you need a starting place, I can send a sample list charter. Ask via private email . - murr - From list-managers-owner Sat Jun 26 17:43:36 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id RAA23222; Sat, 26 Jun 1999 17:26:49 -0700 (PDT) Received: from smtp1.vnet.net (smtp1.vnet.net [166.82.1.31]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id RAA23215 for ; Sat, 26 Jun 1999 17:26:43 -0700 (PDT) Received: from katie.vnet.net (katie.vnet.net [166.82.1.7]) by smtp1.vnet.net (8.9.1a/8.9.1) with ESMTP id UAA11087; Sat, 26 Jun 1999 20:27:35 -0400 (EDT) Received: from localhost (murr@localhost) by katie.vnet.net (8.9.1a/8.8.8) with ESMTP id UAA07608; Sat, 26 Jun 1999 20:27:11 -0400 (EDT) X-Authentication-Warning: katie.vnet.net: murr owned process doing -bs Date: Sat, 26 Jun 1999 20:27:11 -0400 (EDT) From: murr rhame To: "Matthew N. Kleiman" cc: List-Managers@GreatCircle.COM Subject: Filtering [Was: Long Lines] In-Reply-To: <000301bebf4b$166012c0$35d7a989@mkleiman.chicago.kirkland.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: list-managers-owner@GreatCircle.COM Precedence: bulk I recently switched to Lyris software from Listproc 6.0c. Lyris has has fairly comprehensive filtering capabilities. Hadn't been able to tinker with filters before. I fiter: max consecutive lines of quotes, "Re: ListName Digest" in the subject line, HTML and binaries. Haven't tried to capture long lines. I have noticed a trend. The filters see to work pretty well as "errogance detectors." The only complaints I've had so far are from subscribers who are "too busy to trim quotes" or "haven't got time to type in a subject line." On the other hand, they don't seem to mind wasting the time of several hundred other list subscribers. - murr - From list-managers-owner Sat Jun 26 18:36:47 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id SAA23685; Sat, 26 Jun 1999 18:12:33 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id SAA23676 for ; Sat, 26 Jun 1999 18:12:27 -0700 (PDT) Received: from Venus.mcs.net (dattier@Venus.mcs.net [192.160.127.92]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id UAA17814 for ; Sat, 26 Jun 1999 20:12:51 -0500 (CDT) Received: (from dattier@localhost) by Venus.mcs.net (8.8.7/8.8.2) id UAA05270 for List-Managers@GreatCircle.COM; Sat, 26 Jun 1999 20:12:51 -0500 (CDT) From: "David W. Tamkin" Message-Id: <199906270112.UAA05270@Venus.mcs.net> Subject: Re: Long Lines Date: Sat, 26 Jun 1999 20:12:51 -0500 (CDT) Cc: List-Managers@GreatCircle.COM In-Reply-To: <000301bebf4b$166012c0$35d7a989@mkleiman.chicago.kirkland.com> from "Matthew N. Kleiman" at Jun 25, 99 03:41:21 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: list-managers-owner@GreatCircle.COM Precedence: bulk Matthew Kleiman wrote, | At the same time, I hate to see subscriber's messages get bounced, | especially novices, to whom the 80 character limitation may seem | arbitrary and make little sense given modern email clients. You can always reprogram your robomoderator to divert posts for your atten- tion, rather than rejecting them, if their only violation is being too wide. One thing to keep in mind is that expecting the recipient to handle word wrap makes it impossible to send tabular or columnar data: the recipient has to accept the sender's formatting, and the sender has to be responsible for formatting the body correctly. | So, without a clear rule to guide me, I'm curious whether other list | managers have a rule/policy on long lines and why. Since I have only one remaining list and I moderate it, my list's receipt for submissions adds another paragraph if the post is too wide, explaining that it will take a little extra time, since even if everything else in the post is just fine, the moderator will still have to edit it to fix the text width. Usually posters who receive it don't comment; some have apologized. None, so far, have responded unkindly. I used to have procmail filter them through fmt, but the versions of fmt to which I had access and my skill with their options were not enough to keep it from making the text less legible than it started out, so now I load them into vi and apply fmt by hand or rearrange a few line lengths here and there to get them within seventy-nine columns. Some of my members have mail clients or editors that will dutifully keep their new text narrow, but their cited text from earlier posts is sacrosanct, and if it was seventy-eight columns or wider, adding a two-column citation (such as "> ") will make it eighty columns wide and trigger my "too wide" addendum to the receipt. Those whose editors or mailers act that way get used to the notification when they post follow-ups to others' articles. BTW, your claim that the screen width originated with punch cards gave me a laugh: have you never heard of paper or typewriters? Eighty pica-sized cha- racters and two quarter-inch margins just fill the width of 8.5" stationery. From list-managers-owner Sat Jun 26 19:22:07 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id SAA24058; Sat, 26 Jun 1999 18:59:24 -0700 (PDT) Received: from ma-1.rootsweb.com (ma-1.rootsweb.com [209.192.148.153]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id SAA24051 for ; Sat, 26 Jun 1999 18:59:16 -0700 (PDT) Received: (from twp@localhost) by ma-1.rootsweb.com (8.9.3/8.9.3) id VAA53908; Sat, 26 Jun 1999 21:59:33 -0400 (EDT) Date: Sat, 26 Jun 1999 21:59:33 -0400 From: Tim Pierce To: "Matthew N. Kleiman" Cc: List-Managers@GreatCircle.COM Subject: Re: Long Lines Message-ID: <19990626215933.L31609@ma-1.rootsweb.com> References: <000301bebf4b$166012c0$35d7a989@mkleiman.chicago.kirkland.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <000301bebf4b$166012c0$35d7a989@mkleiman.chicago.kirkland.com>; from Matthew N. Kleiman on Fri, Jun 25, 1999 at 03:41:21PM -0500 Sender: list-managers-owner@GreatCircle.COM Precedence: bulk On Fri, Jun 25, 1999 at 03:41:21PM -0500, Matthew N. Kleiman wrote: > > I've always believed that a well-behaved email client will wrap long > lines before sending email, on the premise that some email programs > don't have a word wrap feature. I simply assumed it was the _sender's_ > obligation to wrap long lines, not the recipient's. > > However, upon further research, the internet email protocals clearly > permit line lengths up to 1000 characters (rfc 821). This perhaps > suggests that it's the _recipient's_ job to wrap long lines, not the > sender's. I think it suggests that the authors of the SMTP standard didn't want to constrain the format of message bodies any more than necessary. RFC 822, which actually defines the structure of an Internet message, places no restrictions on the lengths of lines in the message body. > On the other hand, even if long lines are "legal," that doesn't > necessarily make them "polite." The recipient may not have a word wrap > function, or the recipient's program may break long lines at incorrect > places, impairing legibility. I'm fairly confident that every modern > email program has a word wrap function, so imposing this rule on list > subscribers should not impose a great burden. Most of them do, but they don't generally restrict the wordwrap to 80 columns. You can resize an editing window to 120 columns and it'll happily wrap your lines to that length, without even warning you. -- Regards, Tim Pierce RootsWeb Genealogical Data Cooperative system obfuscator and hack-of-all-trades From list-managers-owner Sat Jun 26 20:51:05 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id UAA25070; Sat, 26 Jun 1999 20:40:26 -0700 (PDT) Received: from ivan.iecc.com (ivan.iecc.com [208.31.42.33]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id UAA25062 for ; Sat, 26 Jun 1999 20:40:21 -0700 (PDT) Received: (qmail 14633 invoked by uid 100); 26 Jun 1999 23:40:49 -0400 Date: Sat, 26 Jun 1999 23:40:48 -0400 (EDT) From: John R Levine To: murr rhame cc: List-Managers@GreatCircle.COM Subject: Re: Filtering [Was: Long Lines] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: list-managers-owner@GreatCircle.COM Precedence: bulk > I have noticed a trend. The filters see to work pretty well as > "errogance detectors." The only complaints I've had so far are from > subscribers who are "too busy to trim quotes" or "haven't got time to > type in a subject line." On the other hand, they don't seem to mind > wasting the time of several hundred other list subscribers. I have a long standing policy in the comp.compilers newsgroup, which I hand-moderate, that if it's not important enough for the author to make his message usable, it's not important enough for me, either. I don't get many arguments. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4 2D AC 1E 9E A6 36 A3 47 From list-managers-owner Sat Jun 26 21:05:49 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id UAA25194; Sat, 26 Jun 1999 20:47:51 -0700 (PDT) Received: from ivan.iecc.com (ivan.iecc.com [208.31.42.33]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with SMTP id UAA25187 for ; Sat, 26 Jun 1999 20:47:46 -0700 (PDT) Received: (qmail 14887 invoked by uid 100); 26 Jun 1999 23:48:16 -0400 Date: Sat, 26 Jun 1999 23:48:16 -0400 (EDT) From: John R Levine To: list-managers@GreatCircle.COM Subject: Re: Moderating and off-topic posts In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: list-managers-owner@GreatCircle.COM Precedence: bulk >> ... This person quickly develops strong supporters in the group >> for his right to offer these type of questions (e.g., the free >> speech arguments) ... After a lot of years moderating both newsgroups and mailing lists, I've come to a fairly hard-nosed position where I give people one warning and if they don't get the hint, I kick them off the list. As others have noted, the Internet has plenty of fora for free speech, and your list is not one of them. Also through experience I've discovered that it is a bad idea to permit discussions of list management policy on the list, although it's OK in private mail. This may seem awfully fascistic, but the reality is that someone has to be in charge of your list, and if it's not you, it'll be the loudest and most persistently obnoxious people on the list. If you're in a generous mood you can create a parallel unmoderated whatever-discuss list where people who have nothing better to do than to complain about your moderation policy can do so in a place where you don't have to read about it. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4 2D AC 1E 9E A6 36 A3 47 From list-managers-owner Sat Jun 26 21:20:50 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id UAA25255; Sat, 26 Jun 1999 20:51:16 -0700 (PDT) Received: from ctc.swva.net (ctc.swva.net [165.166.123.19]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id UAA25240 for ; Sat, 26 Jun 1999 20:51:08 -0700 (PDT) Received: from default (pem-2.swva.net [208.140.224.114]) by ctc.swva.net (8.9.0/8.9.0) with SMTP id XAA02504 for ; Sat, 26 Jun 1999 23:51:32 -0400 Message-Id: <199906270351.XAA02504@ctc.swva.net> From: "Bernie Cosell" Organization: Fantasy Farm Fibers To: Date: Sat, 26 Jun 1999 23:51:26 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Long Lines Reply-to: bernie@fantasyfarm.com In-reply-to: <000301bebf4b$166012c0$35d7a989@mkleiman.chicago.kirkland.com> X-mailer: Pegasus Mail for Win32 (v3.11) Sender: list-managers-owner@GreatCircle.COM Precedence: bulk On 25 Jun 99, at 15:41, Matthew N. Kleiman wrote: > I recently coded a "robomoderator" ... > ...to reject any message with any line longer > than 80 characters (excluding headers). To my surprise, this has been > the most common problem "solved" by the robomoderator ... approximately > 1 in 30 messages sent to the list have long lines. > > I've always believed that a well-behaved email client will wrap long > lines before sending email, on the premise that some email programs > don't have a word wrap feature. I simply assumed it was the _sender's_ > obligation to wrap long lines, not the recipient's. > > However, upon further research, the internet email protocals clearly > permit line lengths up to 1000 characters (rfc 821). This perhaps > suggests that it's the _recipient's_ job to wrap long lines, not the > sender's. Actually, you missed a part of that section. That section of RFC 821 [= STD 10] is the "minimum maximum". Yes, long lines are permitted, as they should be: the *transport* machinery shouldn't impose unnecessary arbitrary limits on the package it is transporting. The place you're looking at is: > 4.5.3. SIZES > > There are several objects that have required minimum maximum > sizes. > [...] And it goes on to say that: > **************************************************** > * * > * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * > * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * > * OF THESE OBJECTS SHOULD BE USED. * > * * > **************************************************** a limitation here [for SMTP] would preclude *all*other* possible internal data formats using SMTP for its transport, and so it, quite properly, should be generous [or unlimited!]. Now, if you go a level down, into the message within the wrapper, you turn to RFC 822 [STD-11] and things are a bit stranger. Still: as it should be, the RFCs are fairly careful *not* to constrain the format overly, lest it cripple future uses for email, but to my reading we can make some deductions about what was intended... Consider that the header field is explictly set up with machinery for "folding" and having continuation lines, when it could easily have been specified to be [and indeed, it is specified to be handled *as*if* it were] a single line with the header-tag at its beginning. Clearly they expected those header fields to be wrapped explicitly in the message, whereas if they had merely had intended arbitrarily-long-lines they wouldn't have bothered [and indeed, it'd make parsing 822 headers easier NOT to have to deal with continuations..:o)]. You look farther on to the definition of "linear white space" and you see that the spec makes a distinction between the semantics of "SPACE" and "FOLDING" -- clearly [IMO] the intent for the semantics of LWSP that is _not_ a CR is different from an actual CRLF. More indications, to my reading, that their -intent- was for regular text with CRLFs indicating where new lines should begin, but with _allowances_ for other, fancier, data formats... At a practical level, another problem with wrapping long lines at the reader's end is that it is, in general, not really possible to do it quite right unless you have something like
tags available to give the reader's client a clue *NOT* to mess with text that _has_ been formatted [it is rather WAAY too much of an restriction on email to mandate that _only_ unformatted, microsoft-style "paragraphs" should be sent!]. E.g., I get system messages with unix log snippets in it and histograms [basically, ascii-ized graphs], and all the nice neat columns are rather thouroughly trashed if my mail client folds gratuitously. I also get things with macsyma-generated equations in them [where superscripts and fractions and such are done via multi-line prints, like: 2 2 2 x + y = z and you havne't seen a MESS until you've seen some of _that_ stuff re- wrapped by the reader's client! :o)] > At the same time, I hate to see subscriber's messages get bounced, > especially novices, to whom the 80 character limitation may seem > arbitrary and make little sense given modern email clients. (After all, > how many of you know the *original* derivation of the 80 character rule > of thumb? Answer at the end of this email.) I do know that, but your derivation has it wrong: the reason for the 80- char rule *IS* the size of terminals [both hardcopy [e.g., TTYs] and CRTs ["glass TTYs and their descendents]]. The fact that Teletype corp may have been looking elsewhere when they decided to make the platen on the KSR33 be 80 characters wide isn't really relevant... *Those*devices*, for whatever reason, *did* standarize on 80 chars and the constraints on email is *NOT* a homage to the IBM 407, but rather the reality of what the terminals *had* standardized on. [and yes, I know there were a few terminals of other sizes [I think my old TI silent 700 only had 72 char lines, and I used an IBM 2741 that had lots more than 80... but overwhelmingly, 80 was the number...] Moreover, the proper limitation is *less* than 80 characters. For example, RFC 1855 [the netiquette RFC] simply says: > - Limit line length to fewer than 65 characters and end a line > with a carriage return. good advice then, good advice now... /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:bernie@fantasyfarm.com Pearisburg, VA --> Too many people, too few sheep <-- From list-managers-owner Sat Jun 26 21:51:49 1999 Received: (majordom@localhost) by honor.greatcircle.com (8.8.5/Honor-Lists-980720-1) id VAA25621; Sat, 26 Jun 1999 21:24:10 -0700 (PDT) Received: from plaidworks.com (plaidworks.com [209.239.169.200]) by honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id VAA25613 for ; Sat, 26 Jun 1999 21:24:01 -0700 (PDT) Received: from (a197.plaidworks.com [209.239.169.197] (may be forged)) by plaidworks.com (8.9.1a/8.9.1) with ESMTP id VAA37164 ; Sat, 26 Jun 1999 21:24:24 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sat, 26 Jun 1999 21:20:24 -0700 To: murr rhame , Bill Southerly From: Chuq Von Rospach Subject: Re: Moderating and off-topic posts Cc: list-managers@GreatCircle.COM Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: list-managers-owner@GreatCircle.COM Precedence: bulk At 8:11 PM -0400 6/26/99, murr rhame wrote: > Personally, I don't have much sympathy for folks who insist that they > have an absolute and unconstrained right to free speech. Far as I'm concerned, they do. they have the absolute and unconstrained right to start their own mailing list and post whatever they want on it -- on their own nickel. Long as