Articles are routed based on information found in the header lines defined in RFC 1036. Of particular interest to a transit server are:
In most cases, the sending server controls the article transfer process. It compares the Newsgroups and Distribution of each newly arrived article against a set of patterns called newsfeeds, listing each remote server and the newsgroups its operator wishes to receive. Some senders also examine the Path; if the receiving server appears in this line, it is not offered. Other local rules may also be added. The sender transmits matching articles' Message-IDs to the receiving server. The receiver indicates which Message-IDs it has not yet stored locally, and those articles are sent.
The receiving server examines the incoming articles. A message is normally discarded if the Message-ID is duplicated by an article already received (i.e., another server sent it in the meantime), the Date or Expires lines indicate that the article is too old, the header syntax appears to be invalid, the Approved header is missing for a moderated newsgroup, or additional local rules disallow it. Most servers also maintain a list of active newsgroups. If the Newsgroups header of a new article does not match the active list, it may be discarded or placed in a special "junk" newsgroup. Once the article is stored, the server attempts to retransmit it to any servers in its own newsfeed list.
Articles with Control lines are given special handling. They are typically filed in special "control" newsgroups and may cause the server to automatically carry out exceptional actions. The newgroup and rmgroup commands can cause newsgroups to be created or removed; checkgroups can be used to reconcile the local active list with a commonly accepted set; and cancel commands are used to request the deletion of a specific article. ihave and sendme are sometimes used with UUCP to transmit lists of offered and wanted Message-IDs. Other commands (version, sendsys, uuname) are requests for server configuration details. Once used to create network maps, they now are generally obsolete.
Specialized transit servers may omit some of these checks. Other hosts will then need to perform the checks, but the reduced processing overhead allows articles to be relayed in less time.
Most reader servers support posting, either through NNTP or a special inews program. When an article is posted, the process is much the same as when a transit server receives news, but with additional checks. For posting, the server will normally fill in missing Path and Message-ID lines and check the syntax of headers intended for human readers, such as From and Subject. If the article is posted to a moderated group, the server will attempt to mail it to the newsgroup moderator if the Approved header is absent. Additional identity checks and filters are also typically applied at this point.
Because hybrid servers usually use the posting function to send news, article headers are reformatted by the posting function and tracing information can be lost. Also, the delayed sucking process can result in excess activity on the remote reader servers. For these reasons, the use of hybrid servers is often discouraged or disallowed without prior agreement.
Among the operators and users of commercial news servers, common concerns are the continually increasing storage and network capacity requirements and their effects. Completion (the ability of a server to successfully receive all traffic), retention (the amount of time articles are made available to readers) and overall system performance are the topics of frequent discussion. With the increasing demands, it is common for the transit and reader server roles to be subdivided further into numbering, storage and front end systems. These server farms are continually monitored by both insiders and outsiders, and measurements of these characteristics are often used by consumers when choosing a commercial news service.