home *** CD-ROM | disk | FTP | other *** search
/ Telecom / 1996-04-telecom-walnutcreek.iso / new-readers / how.to.post.msgs.here < prev    next >
Internet Message Format  |  1991-01-20  |  15KB

  1. Received: from hub.eecs.nwu.edu by mintaka.lcs.mit.edu id aa02030;
  2.           19 Jan 91 19:39 EST
  3. Received: from mailinglists.eecs.nwu.edu by delta.eecs.nwu.edu id aa05142;
  4.           19 Jan 91 18:10 CST
  5. Received: from mailinglists.eecs.nwu.edu by delta.eecs.nwu.edu id aa14183;
  6.           19 Jan 91 17:05 CST
  7. Date:     Sat, 19 Jan 91 16:51:58 CST
  8. From:     TELECOM Moderator <telecom@eecs.nwu.edu>
  9. [To]:     telecom@eecs
  10. Subject:  A Special Notice About the Digest
  11. BCC:         
  12. Message-ID:  <9101191651.ab16557@delta.eecs.nwu.edu>
  13.  
  14.  
  15.  Date: Sat, 19 Jan 91 16:52:00 CST
  16.  From: TELECOM Moderator <telecom@eecs.nwu.edu>
  17.  Newsgroups: comp.dcom.telecom
  18.  
  19.  
  20.          WELCOME TO COMP.DCOM.TELECOM AND THE <TELECOM DIGEST>
  21.          =====================================================
  22.  
  23. This is a special posting to readers of comp.dcom.telecom and the
  24. TELECOM Digest, to tell you a little about the group, the procedures 
  25. for posting here and my philosophy as Moderator.
  26.  
  27. TELECOM Digest was started in August, 1981 by Jon Solomon as a mailing
  28. list on the old ARPA network. It was an offshoot of the Human Nets
  29. forum intended for discussion of telephones and related communications
  30. topics. I've been the Moderator/Editor/facilitator of the Digest since
  31. the fall of 1988; and I work from guest accounts provided to me at
  32. several sites, primarily Northwestern University in Evanston, IL, but
  33. also at Boston University, and the Massachusetts Institute of Technology
  34. in Boston, MA and the University of California.
  35.  
  36. TELECOM Digest is not strictly speaking part of Usenet. It is an
  37. official Internet mailing list publication. A decision was made at
  38. some point in the past to 'port' the Digest to the Usenet news group
  39. 'comp.dcom.telecom', in order that Usenet readers would be able to
  40. participate in the Digest. I became Moderator of comp.dcom.telecom in
  41. 1989 in addition to being Moderator of TELECOM Digest. For all
  42. practical purposes, the messages in comp.dcom.telecom are identical to
  43. tne messages which appear simultaneously in TELECOM Digest. Now the
  44. Digest goes to several Bitnet and Fidonet sites as well, in addition
  45. to being distributed on several other networks such as MCI Mail, AT&T
  46. Mail, and Telenet, via the PC Pursuit Net Exchange BBS.
  47.  
  48. Both comp.dcom.telecom and TELECOM Digest are *moderated*. This means
  49. that unlike many Usenet groups, messages must be channeled through the
  50. Moderator's mailbox to be considered for publication. Like other
  51. moderated groups on Usenet, the reason for this is to reduce the flow
  52. of traffic on the net; to reduce the number of postings which
  53. essentially say nothing new; and to group or collect the messages in a
  54. logical and convenient to read way. Moderators have the duty of
  55. weeding through duplicate messages; standardizing the output; making
  56. minor changes to correct spelling, grammar and punctuation;
  57. 'repairing' header information and subject title information as needed
  58. to cause messages to 'thread' correctly, and otherwise helping to
  59. maintain the flow of traffic on the net and the attractive appearance
  60. of their group.
  61.  
  62. Moderators are entitled to have opinions of their own on the topics
  63. of discussion, but should make an effort to keep the discussion
  64. balanced with all sides permitted to express their opinion. In the
  65. event of such a heavy flow of traffic that not all -- or only a small
  66. portion -- of the messages received can be used, the Moderator is
  67. expected to balance the flow as evenly as possible. Quite obviously
  68. this is more of a judgment-call than anything else at times.
  69.  
  70. In TELECOM Digest and comp.dcom.telecom my specific guidelines are
  71. these:
  72.  
  73. We receive an average of 60-120 messages *each day* from readers. I
  74. try to print as many as possible, which basically means putting out
  75. two or three issues of the Digest each day. Some days I put out two
  76. issues; other days I put out five. The salary they pay me for doing
  77. this doesn't require me to work more than three hours per day on
  78. telecom discussions.  :)  :)
  79.  
  80. I very rarely use anonymous messages. First, neither the sites which
  81. permit me to use their facilities or the Internet itself support
  82. anonymous postings. I'm a guest here -- not a policy maker. I do not
  83. pay the first nickle to move telecom traffic around the net. So I
  84. think it in my best interest to follow the rules others have made.
  85.  
  86. Second, there are so many postings from *real, live people* received
  87. every day that I don't have to accept anonymous, maybe the person is,
  88. maybe the person isn't real messages. I believe Moderators must be
  89. held responsible for the messages in their groups; and I don't intend
  90. to be in the trick-bag for anyone here. I will withhold names on
  91. request when (in my discretion) I think the writer has a good reason
  92. for it. But I insist on at least having the backup information in my
  93. own files here.   It comes down to the integrity of the net, in my
  94. opinion. As the person who has been given one small section of the net
  95. to operate in trust, that is the way I prefer to do it. There are
  96. exceptions to my personal standard of 'no anonymous messages', but
  97. they are few.
  98.  
  99. When several messages appear from various people saying almost the
  100. same thing, that is intended to demonstrate the large volume of mail
  101. on the topic. In other words, if eighty percent of my mail on a given
  102. day is in response to some topic, it is likely two or three issues of
  103. the Digest will be exclusively or almost entirely devoted to the same
  104. topic -- even if that means many virtually identical messages. Each
  105. issue of the Digest is intended as a *random sampling* of the mail I
  106. received that day or the day before. 
  107.  
  108. A Moderator is not required to print all submissions recieved and is
  109. in fact encouraged not to do so. It comes down many times to simply a
  110. judgment call by the Moderator to accept one and not accept another.
  111. Based on the 30-40 messages per day I publish (depending on the time I
  112. can devote that day) versus the 60-120 I actually receive, I wind up
  113. publishing between a third and half of the submissions. 
  114.  
  115. The autoreply is, I think, unique to TELECOM Digest and comp.dcom.telecom.
  116. There is no way I could begin to personally respond to the mail I
  117. receive, and there will be times that messages won't get out for a day
  118. or two because of the backlog. I try to move new messages with timely
  119. and newsworthy content to the front of the queue. Sometimes this
  120. causes someone else to get shoved back still another issue. So the
  121. autoreply is my way of letting you know your article has been
  122. received. I owe you that much courtesy.
  123.  
  124. Who gets autoreply / who does not receive it?
  125.  
  126. We use MMDF here for the mail. A feature of this software is that all
  127. incoming mail is filtered through .maildelivery, a file which says how
  128. to handle each incoming item. The autoreply program looks at each
  129. piece of mail and takes the following actions:
  130.  
  131. Is there a 'reply to' line in addition to a 'from' line? If so, then
  132. use 'reply to' to detirmine whether or not to send the reply. If no
  133. 'reply to' then use the 'from' line for this purpose, although 'from'
  134. is notoriously inaccurate by the time some mailers get finished with
  135. it!
  136.  
  137. Look for these strings in the 'from'/'reply-to' line. If seen, then do
  138. NOT send an autoreply:  daemon, postmaster, news@, uucp@, telecom,
  139. ptownson@, and others. Such letters either were written by daemons to
  140. bounce mail, are items forwarded by backbone sites found loose in
  141. comp.dcom.telecom (unapproved postings), or are inter-account
  142. transfers of mail by myself from one location to another. If we
  143. autoreply to these, a loop may get started with daemons replying back
  144. to autoreply, etc.
  145.  
  146. Despite how carefully I try to define the limited instances where
  147. autoreply should not go out, there are a few users whose addresses
  148. contain characteristics so similar that their mail gets treated the
  149. same way. That is, I see it, but .maildelivery sorted it into a file
  150. silently as it would do with bounced mail, telecom-request stuff, etc.
  151. Over all, about 95 percent of the *actual, real people* who write me
  152. get an autoreply generated. To avoid the risk of starting a loop in
  153. the mail -- a war of the daemons as it were -- I prefer to err on the
  154. conservative side and skip a few of you. 
  155.  
  156. Individuals can be added to the 'do not reply' list: I routinely do
  157. not send autoreply to regular administrative email. For example the
  158. postmaster here at eecs, another user here who assists me with
  159. technical problems, etc do not like the autoreply. When a reader
  160. attempts to put an article direct into comp.dcom.telecom I will
  161. receive sometimes <hundreds> of copies of the article as sites all
  162. over the world forward it to me for handling. The user involved will
  163. wind up getting hundreds of autoreplies back from me if there was a
  164. 'reply to' in his header. I manually edit these in and out of the
  165. .maildelivery file as needed to turn off autoreply to that person if
  166. needed. Other individuals who send me threatening, harrassing or
  167. nonsensical mail on a frequent basis can and are also added. I see no
  168. reason to encourage them to continue writing.
  169.  
  170. So ... about 95 percent of the 'real people' generate autoreply when
  171. they write me, give or take manual exceptions added to the list as
  172. needed.  Do they all get the autoreply?  No!
  173.  
  174. Maybe five or ten percent of those folks had their 'from' line in the
  175. header so badly mangled (and there was no 'reply-to' to fall back on)
  176. that the autoreply itself bounces and returns to me as bounced mail.
  177. As an aside, that is one reason 'telecom' is in the exceptions list.
  178. Imagine the dilemma: a deamon bounces my autoreply and I autoreply
  179. right back ... and again, and again, and again. :)
  180.  
  181. So over all, I estimate 85-90 percent of the people who write me will
  182. actually get the autoreply. If you are one of the ten or fifteen
  183. percent who do not then either I have been unable to write my code to
  184. include you, or you did not give me an unmolested 'reply-to' to reach
  185. you, or in rare cases, I specifically have added you to the
  186. exceptions if you were engaging in what I consider harrassing actions
  187. toward the Digest or myself.
  188.  
  189. I do not guarentee I will answer personal mail on telecom issues.
  190. Sometimes I will take your letter and publish it in the Digest so
  191. others can answer better than I unless you **specifically** in the
  192. body of your letter say NOT FOR PUBLICATION. I rarely answer letters
  193. marked not for publication.
  194.  
  195. If I do not wish to use your submission I attempt to do one of two
  196. things: If it is a lengthy piece and obviously required work to
  197. prepare it, I will attempt to return it. If it bounces once, then I
  198. will disgard it. If your article was a short piece -- just a few lines
  199. of response or similar -- I will often times simply disgard it and
  200. answer you with a note of my own. Again, if it bounces, I have no
  201. resources or time to track down your address ... not and publish
  202. three, four or five Digests per day as well.
  203.  
  204. If you usually receive the autoreply, and for some specific submission
  205. do *not* receive it, before resubmitting the article, drop me a note
  206. asking if I received it. I'll tell you if I did or not. If your
  207. article is not time-sensitive (and most are not) then if possible
  208. watch the Digest for a couple days and see if it appears before you
  209. write me. After two or three days do please write to follow up if your
  210. item has not appeared, you did not get the autoreply AND you did not
  211. get a note from me declining publication for whatever reason.
  212.  
  213. If you usually do not receive the autoreply due to the technical
  214. reasons specified above, and if your article has not been published
  215. or returned within two or three days contact me again. If you send a
  216. duplicate copy of your article, please note DUPLICATE near the top
  217. somewhere to catch my eye as I am editing it. 
  218.  
  219. Yes, I can lose things, but my record is pretty good for not losing
  220. submissions. Any large moderated group will have technical problems
  221. from time to time, but I am trying my best on this end to make the
  222. Digest and comp.dcom.telecom one of the best groups on the net.
  223.  
  224. Some readers complain that I publish ** too much ** here -- that I
  225. should limit the output to one Digest per day; but that would mean
  226. tossing out a great deal of what I receive. I'd rather make the extra
  227. effort to publish as wide a variety of stuff as possible, from as many
  228. readers as possible. Perhaps I am too tolerant of many of your
  229. submissions, but I take this task very seriously and try to do it
  230. well.
  231.  
  232. However I cannot -- will not -- publish messages which in my
  233. estimation are intended only as flames, deliberate attacks on myself
  234. or other users, or which are calculated to throw the Digest up for
  235. grabs and cause a big backlog of meta-discussions about the operation
  236. of the Digest itself. I trust none of the long-time readers here will
  237. ever claim that I refuse to publish all sides of an issue, or that I
  238. refuse to publish opinions contrary to my own. If anything, I permit
  239. too many rebuttal messages; but I want all sides to be aired here,
  240. save my few 'blind spots' if you wish to call them that: I won't
  241. publish phreak/cracker messages which jeopardize the security of this
  242. net or the telephone network; anonymous messages will be a rarity
  243. here; persons abusing network hospitality and/or lacking basic 'net
  244. etiquette' by sending messages with fake names and addresses or by
  245. forging the required headers to break into comp.dcom.telecom will find
  246. no kinship with me. I do not acknowledge or respond to the individuals
  247. who send such messages.
  248.  
  249. The Digest is 'wide-open' for conversation on all aspects of
  250. telephony: there is no honest way these days to separate the technical
  251. aspects from the politics involved, or vice-versa. Both telecom
  252. 'heavyweights' and inexperienced users are welcome here subject to the
  253. few rules of courtesy which should apply in any forum. 
  254.  
  255. Comp.dcom.telecom is not 'just another Usenet group' ... it is
  256. intended to be one of the best, and I sincerely thank all of you who
  257. have helped to make it that way. 
  258.  
  259. TELECOM Digest supports two alternate mailing lists for discussions
  260. which have sprung from controversial topics here:
  261.  
  262.        Computer Underground Digest    rk0jut2@niu.bitnet
  263.       
  264.        Discussion of the social and legal ramifications of
  265.        computer 'hacking'; related activities.
  266.  
  267.        Telecom Privacy         telecom-priv@pica.army.mil
  268.            (moderator address: telecom-priv-request@pica.army.mil)
  269.     
  270.        Discussion of privacy topics relating to telecommunications,
  271.        including Caller*ID, telemarketing data files, etc.
  272.  
  273. Messages are frequently interchanged, or cross posted between the
  274. Digest and these two mailing lists, both of which also appear in their
  275. own 'alt' groups.
  276.  
  277. ALL messages to comp.dcom.telecom and TELECOM Digest MUST be sent
  278. through the Moderator's address: telecom@eecs.nwu.edu. You cannot use
  279. the 'follow-up' feature of readnews with moderated groups. You can of
  280. course reply direct to the poster if desired. 
  281.  
  282. I apologize for the length of this special mailing, but many of you
  283. have epxressed concern in recent days asking for clarification on how
  284. the Digest is maintained. I hope this posting gives you some
  285. background information. Responses will not appear in the Digest, but I
  286. will try to answer questions and possibly summarize replies in the
  287. near future.
  288.  
  289.  
  290. Patrick Townson
  291. TELECOM Digest Moderator   / comp.dcom.telecom
  292.