NNTPD provides NNTP service, accepting NNTP commands on its input and sending NNTP responses and message data on its output. If no socket is specified as an argument, it uses its standard input and standard output for input and output. Otherwise, it uses the named socket, which it closes when it has finished with it. The IP address and TCP port number on which NNTP service is thus provided is determined by its parent process, not NNTPD itself. Conventionally, the port number is 119 and the IP address is one that is reachable by Internet at large.
NNTPD expects the news spool to be stored in the standard format below the current directory of the dæmon.
NNTPD is designed to be spawned on demand by TCPSRUN. It can also be spawned by INETD, although the control of client access levels based upon the client's IP address, which TCPSRUN does, will be unavailable as a consequence.
Where client access is denied, NNTPD simply exits immediately, closing the socket. With any other access level, normal NNTP service is provided.
NNTPD writes log information to its standard error.
NNTPD provides service in two modes. In both modes, the NNTP verbs
quit are available. Each mode supports further additional
Peer mode service
provides transport service to other, peer, NetNews nodes. The additional
NNTP verbs available in peer mode are
ihave. NNTPD thus advertises the
capabilities in peer mode.
Reader mode service
provides reader service to News User Agents, using NNTP to read and to
post articles. The additional NNTP verbs available in reader mode are
post. NNTPD thus
post capabilities in
NNTPD, like many other NNTP servers, provides a variation from the documented protocol (which in practice is respected far more widely in the breach than the observance). In particular, it varies in the following ways:
head verb is not available to peers.
The protocol definition makes this available in both "transit" and "reader" modes. In practice, this is a reader-only verb.
slave verb is not supported in any mode.
This verb, originally specified in RFC 977, was never widely supported in real implementations, and is not used in practice by NNTP clients.
Two-digit years are not supported.
We've experienced the Century Bug once already. NNTPD is not in the
business of helping it to happen all over again in 100 years' time. All
years must be expressed with four digits in the
NEWGROUPS verbs. RFC 3977 specifies semantics for guessing
the centuries of two-digit years but (a) they differ from
the RFC 977 semantics,
(b) they differ from
the Single Unix Specification version 2 semantics, and (c) they're
quite silly. RFC 3977, for example, instructs servers to assume that
clients stating "300101" are specifying the date 1930-01-01, which is more
than 40 years before NetNews was even invented.
The more sensible Single Unix Specification semantics would cause NNTPD to infer the date 2030-01-01, and render it impossible for clients to ask for dates prior to 1970. But this is just papering over the cracks at this point. Bad NNTP clients, that send two-digit years, should have already been eliminated back in the year 1999 when the Century Bug first became a major public issue. NNTPD provides no accommodation for such bad NNTP clients.
NNTPD canonicalizes posted messages and requires messages transferred from peer NetNews nodes to already be in canonical form. After a message has been canonicalized, or checked to see that it is already in canonical form, NNTPD imposes the following restrictions:
Messages that do not have exactly one message ID are rejected. Not only does RFC 1036 mandate this, but NNTPD's news spool structure requires it. All messages must have one, globally unique, ID, for NNTPD to accept them from either peer NetNews nodes or News User Agents.
Messages that do not have at least one newsgroup are rejected.
Messages that do not have at least one carried newsgroup are rejected. NNTPD will accept messages that list newsgroups that are not locally carried only if they also list one or more newsgroups that are.
Messages that are dated too far into the past or the future are rejected.
Messages where the news spool already contains a message with the same message ID are rejected. Such messages are duplicates.
Messages whose IDs are listed in the history index are rejected. The history index records the message IDs of messages that have already been included in the news spool once, and have since been expired. New messages with the same message IDs are presumed to be duplicates.
To (canonical form) messages that satisfy these requirements, NNTPD makes further modifications:
To messages received from News User Agents in reader mode via the
post verb, it prepends (if the information is known)
Path: headers giving its own (server) IP address and current
To messages received from peer NetNews nodes in peer mode via the
ihave verb, it prepends trace information and headers, in the
form of additional
Path: header components and (optionally)
A "TCPService.RUN" run file, for NNTPD to be spawned by TCPSRUN, would typically look similar to:
chdir %NEWSROOT%\ program %APPS%\JdeBP\IU\Bin\NNTPD.exe argument NNTPD argument %3
TCPSRUN itself would be invoked under RUNSVC, the Service Manager in the OS/2 Command Line Utilities version 2.2, with a run file similar to:
chdir %_BOOT%:\Config\Services\%1 program %APPS%\JdeBP\IU\bin\TCPSRun.exe argument TCPSRun argument 0.0.0.0 argument nntp argument TCPService.RUN