This is the CSSD Usenet News Frequently Asked Questions document. You can use the index below to quickly jump to individual questions, or you can just scroll the document yourself. You can also go to the University of Pittsburgh Usenet News top-level page, if you didn't jump here from there.
The CSSD Usenet News NNTP Server (generally referred to as the NNTP server or news server for short) is a service provided by Computing Services and Systems Development for the University of Pittsburgh newsreading community. The Usenet News NNTP Server provides access to Usenet news groups and articles via the NNTP protocol.
The hostname of the Usenet news NNTP server is usenet.pitt.edu. You should configure your newsreading software accordingly.
You should not configure the IP address of the news server into your newsreading software; you should instead use the name usenet.pitt.edu. By using the name usenet.pitt.edu instead of the raw IP address, your newsreading software will always be able to access the news server, no matter what its IP address might happen to be.
The IP address of the Usenet news server is currently 136.142.185.40. However, this is not guaranteed to remain constant: in order to be able to effectively deal with any problems which might arise, CSSD reserves the right to change the IP number at any time, without notice. So, please use the name usenet.pitt.edu instead of the raw IP address!
Currently, access to the news server is host-based; any host in the pitt.edu or upmc.edu domains is permitted to read and post news articles via usenet.pitt.edu. (For example, if the hostname of your machine is foo.bar.pitt.edu, or foo.bar.upmc.edu, you can access the news server.) Without exception, machines not in the above domains cannot access the news server.
This check is applied to the hostnames of machines which connect to the news server, not their IP addresses. A machine which has only an IP address (and does not have a hostname assigned to it) will not be permitted to access the news server. If you want to read news from such a machine, you will need to ask your network administrator to set up a DNS entry for it.
Any system problems with the news server (unavailability, connection refusal, etc.) should be reported to the University of Pittsburgh Help Desk.
General (non-emergency) problems, questions, and comments can be mailed to <news+@pitt.edu>. This includes questions about newsgroups carried, reports of Usenet abuse, requests to carry new newsgroups, etc. (In short, anything that does not warrant contacting the Help Desk should be sent to the above address.)
Erin Peszko is Newsmaster General.
Please do not send comments/questions to the individual Newsmasters; please use the <news+@pitt.edu> address instead.
The University of Pittsburgh Newsgroup Guidelines document should cover any questions you might have concerning available newsgroups on the CSSD Usenet News NNTP server.
Carnegie Mellon University considers their cmu.* newsgroups to be private, and will not propagate them to other sites. Therefore, we can't offer the cmu.* newsgroups on the CSSD news server.
Note that CSSD in no way, shape, or form condemns CMU's decision to restrict access to the cmu hierarchy. In fact, CSSD will similarly restrict the pitt.* newsgroups at some point in the future, to help combat the ever-increasing amount of Usenet spam.
Short explanation:
Because Microsoft doesn't distribute this hierarchy, and doesn't support its distribution. Microsoft wants you to read newsgroups in this hierarchy by using their public NNTP server. For more information, see Microsoft Technical Support.
Long explanation:
Normally, Usenet news articles are transferred from news server to news server by using active distribution. This means that if your news server wants to propagate articles it receives (e.g., user posts, articles received from other news servers, etc.), it must actively connect to another news server and offer the articles to it. Other news servers will not connect to your news server and "ask" it if it has any new articles for them.
However, this is not the only way Usenet news articles can be transferred. Any client newsreader can connect to a news server and (for example) download every single article in a particular newsgroup. If the client newsreader were programmed with sufficient capability, it could then turn around and "post" all of those articles to another news server.
In fact, programs with such capabilities exist, for this explicit purpose. Normally, they run on the news server machine itself, and "suck" articles from one or more other news servers by pretending to be normal NNTP client newsreaders. The programs then inject the articles directly into the news server on which they are running, as if the other news servers had actively transferred the articles to it.
Propagating Usenet news articles using NNTP "sucking" programs is usually vastly less efficient than using active distribution to propagate articles. Additionally, "suckers" can take newsgroups (or entire hierarchies) and give them a much wider distribution than they would normally have. For these and other reasons, most news administrators do not appreciate NNTP "sucking" programs, and many news administrators actively take steps to discourage them.
Microsoft intended the microsoft.* hierarchy of newsgroups to be available only on their public NNTP news server. However, various news administrators decided to use "sucking" programs to extract the newsgroups from Microsoft's server and give them worldwide propagation. Many other news administrators, upon seeing microsoft.* newsgroups flying about, added the microsoft.* hierarchy to their own servers and began offering microsoft.* articles to other news servers, believing that Microsoft had intended for the newsgroups to be distributed in this manner.
However, the normal active distribution method of Usenet news propagation did not work well for the microsoft.* newsgroups. Many of the newsgroups had non-standard names which caused difficulties for certain news servers. Also, many of the articles which were posted in the newsgroups did not conform to the standard news article format, which caused difficulties for various news servers. News administrators who carried the microsoft.* newsgroups were understandably upset when their news servers crashed because of "mangled" microsoft.* newsgroups and articles, and Microsoft was pelted with many scathing commentaries on their ability to administer a newsgroup hierarchy. In this particular case, however, the problems weren't Microsoft's fault; the problems were caused by the people who attempted to use Microsoft's public NNTP server in a manner Microsoft didn't intend and didn't support.
This is why Pitt doesn't carry the microsoft.* hierarchy: distributing these newsgroups is not what Microsoft intends, and doing so can potentially cause problems. If Microsoft changes their position on this issue, then we will reevaluate our position as well, but in the meantime, if you wish to read the microsoft.* hierarchy, you should do so by using Microsoft's public NNTP server. For more information, see Microsoft Technical Support.
Short explanation:
It's a bug in tin; you can safely ignore the warning.
Long explanation:
For each newsgroup, the news server maintains a list of information about all articles in the group. Each article in the group has exactly one entry in the list, which consists of the article's Subject, From, Date, Message-ID, References, Bytes, Lines, and Xref headers. This "database" of information is called the News OVerview database, or NOV for short.
The NOV database allows intelligent newsreaders to perform article threading in a more efficient manner. Instead of grabbing every single article in the newsgroup to perform threading (getting the Subject and Reference headers, etc.), NOV-aware newsreaders just grab the entire NOV database for the newsgroup. This is much easier on the news server as well: sending 1 file to the client is a lot less work than sending several thousand. (This is the main reason why the NOV database was created: in order to keep threading newsreaders from crushing news servers into the ground.)
Tin's author assumed that no individual NOV record would contain more than 1024 characters. However, excessively crossposted articles will have huge Xref headers, and articles in long-lived threads will have huge References headers. Because the NOV database contains these two headers, the NOV records for such articles often do exceed 1024 characters. When tin processes NOV records with more than 1024 characters, it unwittingly truncates its copy of the records to the first 1024 characters, and then complains about the records being bogus.
What this all boils down to is that the "Bad Overview Record" error is emitted due to a bug in tin, and not because the NOV database is actually corrupted. The error message can safely be ignored.
Short explanation:
The initial "new articles in this newsgroup" count which some newsreaders show at the newsgroup selection level (i.e., when you're not "in" any particular newsgroup) is only an estimate; it will rarely be completely accurate.
Long explanation:
At the newsgroup selection level, the initial "articles in group" number is only an estimate; almost all newsreaders generate it by subtracting the lowest-numbered article in the group (called the "low-water mark") from the highest-numbered article in the group (the "high-water" mark). (Every time a new article is received for a group, the group's "highest" count is incremented by one, and the new article receives the "highest" count for its article number.)
Articles which are cancelled cause "gaps" in this range, and thus cause the low/high water mark difference to be greater than the number of actual articles in the group. Additionally, articles which are posted with an Expires header significantly into the future (e.g., an FAQ which is posted monthly, with an Expires header set to 1 month into the future) will "anchor" the low-water mark until the date/time in the Expires header is reached and the article is finally expired, which will cause the low/high water marks to "stretch" out enough that the difference can be 2 or 3 times more articles than are actually in the group.
A more accurate method of determining how many articles are actually in a newsgroup would be to simply ask the news server to go out and count the number of articles which are actually in each group. But this would be a very, very costly operation for someone who subscribes to many groups. The low/high water marks for all groups are contained in just one file (called the "active" file); it is much more efficient to ask for just this file and live with the inaccuracies.
If the news server detects an error or problem in an article you are trying to post, it will reject the article, and return an error code (with accompanying text) to your newsreader. If your newsreader is well-behaved, it will then display the text of the error message to you.
Listed below are explanations of what some of the more common rejection messages mean, and how you can avoid them.
This means you attempted to post an article that had more "quoted" text than new text. Here's the archetypal example of an article that has more quoted text than new text:
From: droopy+@pitt.edu (Droopy Dog)
Newsgroups: pitt.test
> Blah.
> Blah.
> Blah.
> Blah.
> Blah.
Me too!
Originally, this restriction against posting an article that had more quoted text than new text was designed to prevent people from accidentally posting a follow-up article that had no new text at all. (The restriction was not designed to force people to post articles that had more new text than quoted text, as is commonly believed.)
In retrospect, the "articles must not have more included text than new text" restriction was probably not a good idea. Nowadays, the "noise" that a follow-up article with no new text represents is dwarfed by the hundreds of thousands of spam, off-topic, and other low-content articles that are posted to Usenet every day. Although many news servers still implement the restriction by default, it is largely falling out of use.
The CSSD news server used to implement the "articles must not have more included text than new text" restriction. The restriction was lifted on June 1, 1998. Therefore, people using the CSSD news server should no longer encounter this restriction.
For historical purposes, the typical way one worked around the "articles must not have more included text than new text" restriction was to change the "quote" prefix string to something besides "> " (which is the only character sequence prefix most news servers that implement the restriction check for).
As an example, here's one way (certainly not the only one) to modify the previous example article so that it wouldn't be caught by most "more included text than new text" detectors.
From: droopy+@pitt.edu (Droopy Dog)
Newsgroups: pitt.test.
} Blah.
} Blah.
} Blah.
} Blah.
} Blah.
Me too!
(Of course, one probably wouldn't want to post an article like this anyway, but you get the idea.)
Copyright 1998 University of Pittsburgh. All rights reserved.
$Id: faq.html,v 1.16 2001/07/31 20:36:45 epeszko Exp epeszko $