telecom@eecs.nwu.edu (TELECOM Moderator) (01/20/91)
WELCOME TO COMP.DCOM.TELECOM AND THE <TELECOM DIGEST>
=====================================================
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 1988; and I work from guest accounts provided to me at
several sites, primarily Northwestern University in Evanston, IL, but
also at Boston University, and the Massachusetts Institute of Technology
in Boston, MA and the University of California.
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
1989 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. Now the
Digest goes to several Bitnet and Fidonet sites as well, in addition
to being distributed on several other networks such as MCI Mail, AT&T
Mail, and Telenet, via the PC Pursuit Net Exchange BBS.
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 60-120 messages *each day* from readers. I
try to print as many as possible, which basically means putting out
two or three issues of the Digest each day. Some days I put out two
issues; other days I put out five. The salary they pay me for doing
this doesn't require me to work more than three hours per day on
telecom discussions. :) :)
I very rarely use anonymous messages. First, neither the sites which
permit me to use their facilities or the Internet itself support
anonymous postings. I'm a guest here -- not a policy maker. I do not
pay the first nickle to move telecom traffic around the net. So I
think it in my best interest to follow the rules others have made.
Second, there are so many postings from *real, live people* received
every day that I don't have to accept anonymous, maybe the person is,
maybe the person isn't real messages. I believe Moderators must be
held responsible for the messages in their groups; and I don't intend
to be in the trick-bag for anyone here. I will withhold names on
request when (in my discretion) I think the writer has a good reason
for it. But I insist on at least having the backup information in my
own files here. It comes down to the integrity of the net, in my
opinion. As the person who has been given one small section of the net
to operate in trust, that is the way I prefer to do it. There are
exceptions to my personal standard of 'no anonymous messages', but
they are few.
When several messages appear from various people saying almost the
same thing, that is intended to demonstrate the large volume of mail
on the topic. In other words, if eighty percent of my mail on a given
day is in response to some topic, it is likely two or three issues of
the Digest will be exclusively or almost entirely devoted to the same
topic -- even if that means many virtually identical messages. Each
issue of the Digest is intended as a *random sampling* of the mail I
received that day or the day before.
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.
Based on the 30-40 messages per day I publish (depending on the time I
can devote that day) versus the 60-120 I actually receive, I wind up
publishing between a third and half of the submissions.
The autoreply is, I think, unique to TELECOM Digest and comp.dcom.telecom.
There is no way I could begin to personally respond to the mail I
receive, and there will be times that messages won't get out for a day
or two because of the backlog. I try to move new messages with timely
and newsworthy content to the front of the queue. Sometimes this
causes someone else to get shoved back still another issue. So the
autoreply is my way of letting you know your article has been
received. I owe you that much courtesy.
Who gets autoreply / who does not receive it?
We use MMDF here for the mail. A feature of this software is that all
incoming mail is filtered through .maildelivery, a file which says how
to handle each incoming item. The autoreply program looks at each
piece of mail and takes the following actions:
Is there a 'reply to' line in addition to a 'from' line? If so, then
use 'reply to' to detirmine whether or not to send the reply. If no
'reply to' then use the 'from' line for this purpose, although 'from'
is notoriously inaccurate by the time some mailers get finished with
it!
Look for these strings in the 'from'/'reply-to' line. If seen, then do
NOT send an autoreply: daemon, postmaster, news@, uucp@, telecom,
ptownson@, and others. Such letters either were written by daemons to
bounce mail, are items forwarded by backbone sites found loose in
comp.dcom.telecom (unapproved postings), or are inter-account
transfers of mail by myself from one location to another. If we
autoreply to these, a loop may get started with daemons replying back
to autoreply, etc.
Despite how carefully I try to define the limited instances where
autoreply should not go out, there are a few users whose addresses
contain characteristics so similar that their mail gets treated the
same way. That is, I see it, but .maildelivery sorted it into a file
silently as it would do with bounced mail, telecom-request stuff, etc.
Over all, about 95 percent of the *actual, real people* who write me
get an autoreply generated. To avoid the risk of starting a loop in
the mail -- a war of the daemons as it were -- I prefer to err on the
conservative side and skip a few of you.
Individuals can be added to the 'do not reply' list: I routinely do
not send autoreply to regular administrative email. For example the
postmaster here at eecs, another user here who assists me with
technical problems, etc do not like the autoreply. When a reader
attempts to put an article direct into comp.dcom.telecom I will
receive sometimes <hundreds> of copies of the article as sites all
over the world forward it to me for handling. The user involved will
wind up getting hundreds of autoreplies back from me if there was a
'reply to' in his header. I manually edit these in and out of the
.maildelivery file as needed to turn off autoreply to that person if
needed. Other individuals who send me threatening, harrassing or
nonsensical mail on a frequent basis can and are also added. I see no
reason to encourage them to continue writing.
So ... about 95 percent of the 'real people' generate autoreply when
they write me, give or take manual exceptions added to the list as
needed. Do they all get the autoreply? No!
Maybe five or ten percent of those folks had their 'from' line in the
header so badly mangled (and there was no 'reply-to' to fall back on)
that the autoreply itself bounces and returns to me as bounced mail.
As an aside, that is one reason 'telecom' is in the exceptions list.
Imagine the dilemma: a deamon bounces my autoreply and I autoreply
right back ... and again, and again, and again. :)
So over all, I estimate 85-90 percent of the people who write me will
actually get the autoreply. If you are one of the ten or fifteen
percent who do not then either I have been unable to write my code to
include you, or you did not give me an unmolested 'reply-to' to reach
you, or in rare cases, I specifically have added you to the
exceptions if you were engaging in what I consider harrassing actions
toward the Digest or myself.
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** in the
body of your letter say NOT FOR PUBLICATION. I rarely answer letters
marked not for publication.
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. 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 usually receive the autoreply, and for some specific submission
do *not* receive it, before resubmitting the article, drop me a note
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, you did not get the autoreply AND you did not
get a note from me declining publication for whatever reason.
If you usually do not receive the autoreply due to the technical
reasons specified above, and 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.
TELECOM Digest supports two alternate mailing lists for discussions
which have sprung from controversial topics here:
Computer Underground Digest rk0jut2@niu.bitnet
Discussion of the social and legal ramifications of
computer 'hacking'; related activities.
Telecom Privacy telecom-priv@pica.army.mil
(moderator address: telecom-priv-request@pica.army.mil)
Discussion of privacy topics relating to telecommunications,
including Caller*ID, telemarketing data files, etc.
Messages are frequently interchanged, or cross posted between the
Digest and these two mailing lists, both of which also appear in their
own 'alt' groups.
ALL messages to comp.dcom.telecom and TELECOM Digest MUST be sent
through the Moderator's address: telecom@eecs.nwu.edu. You cannot use
the 'follow-up' feature of readnews with moderated groups. You can of
course reply direct to the poster if desired.
I apologize for the length of this special mailing, but many of you
have epxressed concern in recent days asking for clarification on how
the Digest is maintained. I hope this posting gives you some
background information. Responses will not appear in the Digest, but I
will try to answer questions and possibly summarize replies in the
near future.
Patrick Townson
TELECOM Digest Moderator / comp.dcom.telecom