WELCOME TO COMP.DCOM.TELECOM AND THE ===================================================== Updated by Bill Horne 2010-01-09 This is a special posting to readers of comp.dcom.telecom and the TELECOM Digest, to tell you a little about the group, the procedures for posting here and my philosophy as Moderator. TELECOM Digest was started in August, 1981 by Jon Solomon as a mailing list on the old ARPA network. It was an offshoot of the Human Nets forum intended for discussion of telephones and related communications topics. I've been the Moderator/Editor/facilitator of the Digest since the fall of 2007; and I work from guest accounts provided to me at the Massachusetts Institute of Technology in Boston, MA. TELECOM Digest is not strictly speaking part of Usenet. It is an official Internet mailing list publication. A decision was made at some point in the past to 'port' the Digest to the Usenet news group 'comp.dcom.telecom', in order that Usenet readers would be able to participate in the Digest. I became Moderator of comp.dcom.telecom in 2007 in addition to being Moderator of TELECOM Digest. For all practical purposes, the messages in comp.dcom.telecom are identical to tne messages which appear simultaneously in TELECOM Digest. Both comp.dcom.telecom and TELECOM Digest are *moderated*. This means that unlike many Usenet groups, messages must be channeled through the Moderator's mailbox to be considered for publication. Like other moderated groups on Usenet, the reason for this is to reduce the flow of traffic on the net; to reduce the number of postings which essentially say nothing new; and to group or collect the messages in a logical and convenient to read way. Moderators have the duty of weeding through duplicate messages; standardizing the output; making minor changes to correct spelling, grammar and punctuation; 'repairing' header information and subject title information as needed to cause messages to 'thread' correctly, and otherwise helping to maintain the flow of traffic on the net and the attractive appearance of their group. Moderators are entitled to have opinions of their own on the topics of discussion, but should make an effort to keep the discussion balanced with all sides permitted to express their opinion. In the event of such a heavy flow of traffic that not all -- or only a small portion -- of the messages received can be used, the Moderator is expected to balance the flow as evenly as possible. Quite obviously this is more of a judgment-call than anything else at times. In TELECOM Digest and comp.dcom.telecom my specific guidelines are these: We receive an average of 5 - 50 messages *each day* from readers. I try to use as many as possible, which basically means readers may receive more than one digest per day. Some days we put out two issues; other days we put out three, although that's rare. The salary they pay me for doing this doesn't require me to work more than three hours per day on telecom discussions. :-) In the past, the Digest did not accept anonymous messages. As Usenet has evolved to deal with spam and the increasing capabilities of search engines, that policy has changed. Posts to the Digest are accepted or rejected based on their content without regard to the identity of the contributor. However, I reserve the right to require that any poster provide his/her real identity prior to publishing an anonymous contribution. I'll try to keep it private, and to use it only for feeding back suggestions or requests for changes, but I can't predict what happens if a court order arrives. A Moderator is not required to print all submissions recieved and is in fact encouraged not to do so. It comes down many times to simply a judgment call by the Moderator to accept one and not accept another. I sometimes delete "me too" messages, or those that are only a rehash of previous submissions. Who gets autoreply / who does not receive it? In the past, the Digest used an auto-response robot to acknowledge receipt of posts. However, so many contributors use obfuscated addresses now that the auto-responses had to be discontinued. If you send a contribution to the Digest, and it hasn't appeared on the email or Usenet feeds within 72 hours, send a message to the moderator FROM A REAL EMAIL ADDRESS, with the glyph "[NFP]" in the subject line, (it means "Not For Publication". The quotation marks aren't included, but the square brackets MUST be.), and I'll tell you the reason your post was rejected, or investigate what happened if I never got it. I do not guarentee I will answer personal mail on telecom issues. Sometimes I will take your letter and publish it in the Digest so others can answer better than I unless you **specifically** mark your email as Not For Publication by putting the "[NFP]" glyph in the subject line and by including the words "Not For Publication" in the FIRST line of the message. If I do not wish to use your submission I attempt to do one of two things: If it is a lengthy piece and obviously required work to prepare it, I will attempt to return it with my reasons for rejecting it. If it bounces once, then I will disgard it. If your article was a short piece -- just a few lines of response or similar -- I will often times simply disgard it and answer you with a note of my own. Again, if it bounces, I have no resources or time to track down your address ... not and publish three, four or five Digests per day as well. If you don't receive my reply, before resubmitting the article, drop me a note FROM A VALID EMAIL ADDRESS asking if I received it. I'll tell you if I did or not. If your article is not time-sensitive (and most are not) then if possible watch the Digest for a couple days and see if it appears before you write me. After two or three days do please write to follow up if your item has not appeared, AND you did not get a note from me declining publication for whatever reason. If your article has not been published or returned within two or three days, contact me again. If you send a duplicate copy of your article, please note DUPLICATE near the top somewhere to catch my eye as I am editing it. Yes, I can lose things, but my record is pretty good for not losing submissions. Any large moderated group will have technical problems from time to time, but I am trying my best on this end to make the Digest and comp.dcom.telecom one of the best groups on the net. Some readers complain that I publish ** too much ** here -- that I should limit the output to one Digest per day; but that would mean tossing out a great deal of what I receive. I'd rather make the extra effort to publish as wide a variety of stuff as possible, from as many readers as possible. Perhaps I am too tolerant of many of your submissions, but I take this task very seriously and try to do it well. However I cannot -- will not -- publish messages which in my estimation are intended only as flames, deliberate attacks on myself or other users, or which are calculated to throw the Digest up for grabs and cause a big backlog of meta-discussions about the operation of the Digest itself. I trust none of the long-time readers here will ever claim that I refuse to publish all sides of an issue, or that I refuse to publish opinions contrary to my own. If anything, I permit too many rebuttal messages; but I want all sides to be aired here, save my few 'blind spots' if you wish to call them that: I won't publish phreak/cracker messages which jeopardize the security of this net or the telephone network; anonymous messages will be a rarity here; persons abusing network hospitality and/or lacking basic 'net etiquette' by sending messages with fake names and addresses or by forging the required headers to break into comp.dcom.telecom will find no kinship with me. I do not acknowledge or respond to the individuals who send such messages. The Digest is 'wide-open' for conversation on all aspects of telephony: there is no honest way these days to separate the technical aspects from the politics involved, or vice-versa. Both telecom 'heavyweights' and inexperienced users are welcome here subject to the few rules of courtesy which should apply in any forum. Comp.dcom.telecom is not 'just another Usenet group' ... it is intended to be one of the best, and I sincerely thank all of you who have helped to make it that way. ALL messages to comp.dcom.telecom and TELECOM Digest MUST be sent either through the Moderator's address: telecomdigestmoderator.at.telecom-digest.org, or via posting with an nntp client. If you don't have access to a news reader or a Usenet server, you may file a post by using Google News, but you'll need to take out a Google email address to do that. N.B. We use POSITIVE anti-spam filtering now, i.e., your post MUST have one of the following keyword glyphs in the Subject line, or it will disappear into the spamassassin black hole. The square brackets are REQUIRED! [NFP] Not For Publication, i.e., private email for the moderator. [Anonymous] Request to remove all trace of your identity before publication. [Obfuscate] Request to make your email address human-readable, i.e., to rewrite it so that humans can use it but spambots can't. For example, user@domain.com may become user.remove-this@and-this-too.domain.com. Your name will NOT be altered or removed. [Telecom] All regular posts which may be published "as is", without any changes requested. I hope this posting gives you some background information on how email may be sent to the Digest. Bill Horne TELECOM Digest Moderator / comp.dcom.telecom January 2010
http://massis.lcs.mit.edu/archives/new-readers/how.to.post.msgs.here
massis.lcs.mit.edu
crawl=CC-MAIN-2018-34
9998
application/http; msgtype=response
sha1:4N5L4DMMKLJFBZHEYPVYPSHCRSPOOBXH
<urn:uuid:1e2984e7-767d-466a-8996-b47ca718a4b5>
2018-08-14T11:30:08Z
128.31.0.31
application/octet-stream
sha1:3JPHQHYDR7YYVXYT7R5WKTQAJGL75NM6
<urn:uuid:3984a5d5-2b7e-4d91-b9b2-b6331df8e5a7>
http://massis.lcs.mit.edu/archives/new-readers/how.to.post.msgs.here
response
<urn:uuid:4df1ce83-25f8-4c71-a9d6-418ba2639351>
isPartOf: CC-MAIN-2018-34
publisher: Common Crawl
description: Wide crawl of the web for August 2018
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-180-184-243.ec2.internal
software: Apache Nutch 1.15 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 0.11-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: http://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/