home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / alt / comp / acadfre / talk / 3723 < prev    next >
Encoding:
Text File  |  1992-12-13  |  4.3 KB  |  93 lines
  1. Newsgroups: uno.cwis,alt.comp.acad-freedom.talk
  2. Path: sparky!uunet!think.com!spool.mu.edu!tulane!ukma!morgan
  3. From: morgan@engr.uky.edu (Wes Morgan)
  4. Subject: Re: Chain letters?
  5. References: <1992Dec11.165515.22434@eff.org> 
  6.     <1992Dec11.180920.28593@ms.uky.edu> <1992Dec12.215820.12189@eff.org>
  7. Message-ID: <1992Dec13.120141.22163@ms.uky.edu>
  8. Organization: University of Kentucky Engineering Computing Center
  9. Sender: morgan@ms.uky.edu (Wes Morgan)
  10. Date: Sun, 13 Dec 1992 17:01:40 GMT
  11. Lines: 80
  12.  
  13. greeny@eff.org (J S Greenfield) wrote:
  14. >morgan@engr.uky.edu (Wes Morgan) writes:
  15. >>I'd classify anything that says "send this to XX other people" as
  16. >>a chain letter..........
  17. >
  18. >OK, Wes.  I bite.  By this standard, isn't *your* post a "chain letter?"
  19. >
  20. >For that matter, isn't mine, and isn't every other post in this thread that
  21. >has excerpted this portion of the original letter?
  22.  
  23. Nope, because this isn't email.  8)  I'll make the distinction more clear
  24. later in this post.........
  25.  
  26. >Personally, I agree with Carl.  A toy car is not a car.  Dana Carvey's
  27. >parody of a Bush speech is not a Bush speech.  And a parody of a chain
  28. >letter is not (necessarily) a chain letter.
  29.  
  30. Of course, you're assuming that recipients will correctly identify it
  31. as a parody and refuse to "play along".  Didn't Orson Welles make the 
  32. same assumption with _War of the Worlds_?
  33.  
  34. I've been bitten by chain letters several times; they have been, without 
  35. exception, useless, resource-intensive, and utterly valueless.
  36.  
  37. You may ask, "what's the difference between a chain letter and a Usenet
  38. group?"  There is one critical difference.  Most Usenet sites control the
  39. delivery of Usenet news; it's often delivered in batch mode during non-prime
  40. computing time.  Email, on the other hand, is considered a more 'immediate'
  41. need, and is often placed much higher on the priority pole.  
  42.  
  43. A flood of Usenet posts won't do much to most systems; the flood will be 
  44. handled in the next batch, which presumably runs at 2 AM (or thereabouts). 
  45. Expire times also help control the "usenet amok" syndrome to some extent.
  46. A flood of email, on the other hand, can bring a system (or, conceivably,
  47. an entire network) to its knees.  Remember CHRISTMA EXEC on BITNET?  Do
  48. you remember IBM being forced to shut down its entire internal network
  49. for several days?  Do you remember BITNET links dying slow agonizing 
  50. deaths for a week?  Move that picture into a microcosm, and you've got
  51. a picture of what chain letters can do to a local network.
  52.  
  53. >I certainly don't buy your rule of thumb for defining a chain letter.
  54.  
  55. My definition of "chain letter" may not jibe with that used by the Postal
  56. Service, but I'm more concerned with the effects than the content.  I'll
  57. stick by my original statement, with a slight rephrasing:
  58.  
  59.     Any email message whose *main* purpose is to generate email 
  60.     traffic FOR THE SAKE OF GENERATING TRAFFIC can be classified 
  61.     as an electronic "chain letter".
  62.  
  63. I do make a distinction between "chain letters" and mass mailings; there
  64. may be a valid reason for such a mass mailing, but I would hope to get 
  65. some warning before 2100 copies of a 68Kb message drop into my /usr/mail
  66. file system.  <This happened a few years ago, and I received no warning;
  67. it was a *very* long evening.  Did you ever try to write a shellscript
  68. to remove one particular message from user mailboxes *without* exposing
  69. oneself to the contents of said mailboxes?  I was rather proud of that
  70. one....>
  71.  
  72. I'm not going to snoop around to find them; however, if I see my mail 
  73. system dying under 100+ messages of near-identical size from a small 
  74. group of senders, you can bet that I'm going to investigate.  <Of course, 
  75. I'll probably be the recipient of one of those copies anyway...8( >
  76.  
  77. I agree completely that this is yet another judgement call.  Of course,
  78. the admin's obligation to provide effective computing service often re-
  79. quires such independent action.  I wouldn't take action in the absence
  80. of a *real* problem, but you can bet that I'll do something when the
  81. system starts taking noticable hits.  
  82.  
  83. --Wes
  84.  
  85. ps>  The mail daemon hits!  Your system feels slower.......
  86.  
  87.  
  88. -- 
  89. MORGAN@UKCC         |       Wes Morgan       |        ...!ukma!ukecc!morgan 
  90. morgan@ms.uky.edu   | Engineering  Computing |   morgan@wuarchive.wustl.edu
  91. morgan@engr.uky.edu | University of Kentucky | JWMorgan@dockmaster.ncsc.mil
  92.   Mailing list for AT&T StarServer S/E  - starserver-request@engr.uky.edu
  93.