Article View: cle.config
Article #45Re: Proposal: stop the leaks
From: March Hare
Date: Thu, 23 May 1996 00:00
Date: Thu, 23 May 1996 00:00
159 lines
9636 bytes
9636 bytes
Lines: 156
In article <4nn657$8be@ns2.wariat.org>,
zbig@ns2.wariat.org (Zbigniew J. Tyrlik) wrote:
>John, be aware that what you face is a limitation of OS/newsreader.
>Unix based newsreaders will present crossposted articel only once;
>after you read it in first newsgroup, you won't see it in aother newsgroups.
>
>On Dos/windows based systems, since they keep a separate copy of crossposted
>article for every newsgroup, massive crossposting is very painful. Still,
>it is OS/newsreader limitation.
Yes, on my system it is actually an implementation issue, I'm pretty
sure. I don't know if UNIX uses links for news or not, but the memory
issues presented in DOS could be overcome, I'm sure. In the defense of
UUPC, though, it was originally ported to DOS first.
Even then, the subject of excessive crossposting creates large amounts
of unwanted traffic in the affected newsgroups. For example, there was
a large crosspost recently that hit such closely related groups
(insert smiley for the sarcastically impaired) as alt.flame, alt.sex.wanted,
comp.os.os2.misc and comp.os.mswindows.advocacy. I've always likened
Usenet to panning for gold in a river: you end up with a lot of worthless
rocks but you occasionally find a nugget or two. Massive and professional
spamming have made it more like looking for a needle in a haystack,
however, the hay has been used already as livestock bedding. Sifting
through river rocks might have a sense of adventure, but sifting through
cow manure certainly does not.
...
>scientology issue. So, if you plan any kind of filter/antispam technology,
>please limit it to your own machine. If it will affect downfeed sites,
>you should make them aware that you do limit/censor traffic on your site.
Yes, it will be limited to my machine and to any downstream. I should
have made that more clear. It will also email the author a somewhat
polite note that said action has taken place. Most, from my experience,
won't get overly disgruntled about it, but I am buying another hard drive
to make sure that someone really has to work at being a jerk. It isn't
in production yet, mostly because of the difficulty in determining EMP
spams. The multiple crosspost was the easy part. Also, just to be
sure it is on the up-and-up, I plan on adding an automatic posting to
news.admin.net-abuse.misc. My hope is that it would at least do a
cursory look in that newsgroup before posting, though, and that may be
more difficult than I'm expecting. After all, the intent is to lessen
the baloney, not increase it.
In other words, I plan on being conservative to a flaw whenever possible.
After all, the goal is not censorship, but how often one must be accosted
by make money fast schemes, unwanted ads (well outside the charter for
the newsgroup) and autopostings of dubious value. Their intent is
obvious, and it adds nothing of value to the discussions at hand. It
only wastes disk space and time -- my disk space and my time. By cross-
posting to 30 newsgroups (and there are more than I was aware of before),
the spammer hits one, two or three newsgroups that I read, in which no
one there cares a whit about what is being peddled. Health products in
alt.bbs? Yes, it happens all the time. If I really was interested, I'd
be looking in one of the biz.* groups, or maybe
alt.quack.herbal.medicine.scam.me.and.take.all.my.money.laugh.to.the.bank
or some such nonsense. I'm not against someone posting a quip about
their new BBS in alt.bbs, or postings by BBS software authors hawking
their wares. Even though there is a group called alt.bbs.ads, it is
not (technically) outside the newsgroup charter to do so. "A time and
place for everything", goes the saying. Yet, in spite of how I feel
about a lot of this, I will do my best to count the Newsgroups and
Follow-up lines, then calculate an appropriate BI. Only if a crosspost
exceeds 19 newsgroups will it automatically receive a noncumulative
BI of 20. Only if an inappropriate article has been manually put in
will a cumulative BI ever ensue. Both of these guidelines have been
put forward by others who have been working with computers longer than
myself, and let's just say that is a long time.
>For this reasons, APK does not censor/restrict news traffic. We do not see
>advantages in trying to micromanage news flow. We belive that it is function
>of user interface ( newsreader ) to allow kill files, topic selection,
>gentle cross-posting handling etc. As long as we have resources we will
>carry all traffic.
Although I understand the poster's sentiments that started this thread,
I would not really care to see APK restricting news traffic or see the
cle.* groups become local distribution. I do assume, though, that APK
does honor cancels from the reliable sources, no?
Here's a simple experiment: Estimate how much traffic goes through
the newsgroups you normally read. Don't be shy, stick some comp.*
groups in there because they do a so much better job of controlling
spam, right? Now, create a kill file that kills anything posted
to over 10 groups. Then, calculate how many articles you see per
day. I was surprised to see that ~30% of the articles got dropped
as a rough calculation. Some of the high spam groups surprised me
as well: comp.os.os2.programmer, comp.os.msdos.4dos, alt.winsock,
comp.lang.java. And, alt.bbs? It lost roughly half of the daily
articles. I even reset my newsrc and dropped the killfile, and I
found that very few were more than senseless flames and make money
fast schemes. That was when I first had the impulse to write a
spam filter that yanked anything over 10 newsgroups. However,
upping it to 20 really does not make a significant difference, other
than I have yet to see anything on-topic get yanked at all instead
of a small margin that could conceivably be (or was) on-topic.
I'm not anti-killfile, though. Killfiles still have their uses. One
thing to keep in mind, though, they were first conceived of in a very
different environment for a very specific purpose. They work great
on a large computer or network where the news is spooled and read by
many people that share the system and the costs of maintaining the
system, such as a university mainframe. It gives the reader great
flexibility in tailoring their reading without affecting others. If
some bozo keeps making an ass of himself, an entry in the killfile
does the trick very quickly. However, killfiles have some disadvantages
as well:
1. On some systems, such as ANU News for VMS, it has a high overhead.
This overhead can be enough to prevent a user from responding to news
through either email or followup.
2. It does nothing to deter the spammer. In spite of the menacing name,
kill subjects don't even know they are dying :). I have yet to see some-
one's account get yanked because he was ignored too much.
3. It does nothing to save disk space. The article stays there, period,
until the natural expiration of the article. Why reward spammers by
keeping the article around?
4. Killfiles can be hard for the average user to configure. Automatic
killing by a newsreader is great, but doing it manually is more efficient.
Of course, what works on my killfiles probably won't work on a different
newsreader, so even getting advice can be a task.
Now, if half of the people reading this agree with everything I've said,
I'd certainly be surprised. I do know, however, that there are more than
a few who feel similarly. In the long run, it probably doesn't matter,
though. Someone will figure out a way, somehow, someday, to charge
people for advertising on the now commercialized net. I think that will
solve a large portion of the problem once people have to cough up some
cash. It probably won't solve everything, since many magazines are
nothing more than half advertising anyhow, but at least it won't be
the spam-and-run type of stuff that keeps happening now. Another
possibility in the works, is tailored newsgroups that goes beyond the
hierarchical nature we have now. A user would actually order up a
tailored news reading according to specified criteria set out before-
hand. So, if you don't agree with me, at least take some consulation
that I don't control the net, I never will and I have no delusions of
trying to take it over or mold it into my own little vision.
Well, I've really worn out the soapbox this time. Spent all of my
time writing insteading of reading news, but now I gotta get back to
real life. Just gotta remember where I put it at ... :)
John
--
//------------------------------------------------------------------------
// momerath@apk.net sevot yhtils eht dna ,gillirb sawT`
// sysop@mome.apk.net ebaw eht ni elbmig dna eryg diD
// ,sevogorob eht erew ysmim llA
// .ebargtuo shtar emom eht dnA
In case of stupidity, break glass.
Technical Details
Message-ID:
<E15ox47UlpRU090yn@mome.apk.net>Path:
arc1-ca.pugleaf.net!unknown!not-for-mailReferences:
<4na8nl$89@madeline.INS.CWRU.Edu> <4nagtd$b3t@junior.wariat.org>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103394,b4524586926531f8 X-Google-Attributes: gid103394,public From: sysop@mome.apk.net (March Hare) Subject: Re: Proposal: stop the leaks Date: 1996/05/23 Message-ID: <E15ox47UlpRU090yn@mome.apk.net> X-Deja-AN: 156264154 distribution: world x-posting-software: UUPC/extended 1.12r inews (20Jan96 10:45) references: <4na8nl$89@madeline.INS.CWRU.Edu> <4nagtd$b3t@junior.wariat.org> newsgroups: cle.config