			     NNTP SUPPORT
			     ------------

This file describes the NNTP support available in nn .  The
NNTP support was implemented by Rene' Seindal, seindal@diku.dk.


			    PREREQUISITES
			    -------------

First of all, you need read-access to an NNTP-server, and if you want
to post, the server must allow that.

The necessary modules to access a remote NNTP server is an integrated
part of nn, so if you specify to use NNTP, the necessary code is
automatically included.

A recent version of the `mini-inews' program which is required to post
articles via an NNTP server is also included for your convenience.
See the INEWS section below.

			     HOW IT WORKS
			     ------------
With NOV (Network OVeriew) NN will function as a pure NNTP client,
it can access both news articles and the NOV article database.


			    CONFIGURATION
			    -------------

To use NNTP in nn, you must edit the relevant parts of config.h:

NNTP
	You enable the use of NNTP by defining the macro NNTP.

NNTP_SERVER
	Both the master and the clients will look up their NNTP-server
	in the file given by the macro NNTP_SERVER.  If the name is not
	an absolute path name, it is taken to be relative to
	LIB_DIRECTORY.

	The format of the file is compatible with the one used in
	clientlib.c in the nntp-1.5 distribution, i.e., the first
	non-blank line, not starting with '#' is taken to be the name of
	the NNTP-server.  This file MUST be present, and must contain a
	valid host name.

NNTP_POST
	If you use the NNTP based inews (part on the NNTP distribution)
	and you have hosts that are not allowed to post to the NNTP
	server, you should defined this.  It will make nn check at
	connect time whether the NNTP server allows postings, and reject
	all attempts to post, if the server disallows posting.  If you
	do not define this, users will be allowed to post by nn, but the
	posting will eventually fail.

	Again, this parameter is only relevant, if you use the NNTP
	based inews, and have hosts that are not allowed to post.

NNTP_MINI_INEWS_HEADER
	This should not be set if you are using the INEWS that
	comes with NN, but may be required if you are using the
	separate NNTP distribution.

NEWS_LIB_DIRECTORY & INEWS
	If either is defined, they specify the destination of the
	mini-inews program when installed below with INEWS being used
	if both are defined.  If neither is defined, it will be
	installed in /usr/lib/news/inews.

EXCELAN
	This is unlikely to be required.

	You can define this symbol if your tcp/ip is based on the
	EXCELAN implementation (no netdb.h, no getservbyname(), no
	gethostbyname()).  (This belongs in the s- file!)
	You will (probably) also need to add -lsocket to NNTP_EXTRA_LIB.
	Normally it will use port 119 for nntp, but this can be modified
	through "#define IPPORT_NNTP 1150" (or similar) in the init file.

NO_BZERO
NO_RENAME
	You can define these symbols if your system doesn't provide
	the bzero() and/or rename() functions (these #define:s belong
	in the s- file).

NNTP_EXTRA_LIB
	Here you can specify libraries and loader flags which are only
	needed when compiled with NNTP.  The normal EXTRA_LIB is still
	used.
	
		
				TUNING
				------

Both the server and each client maintains a cache of recently accessed
articles, to minimize communication with the server (mainly to avoid
fetching large digests continuously).  The master needs the cache when
it splits digests, and the clients need it, because nn has a tendency to
reopen the articles several times.

NN caches articles since it tends open articles several times. The cache
is kept in the users .nn directory.  The constant NNTPCACHE (defined in
nntp.c but can be redefined in config.h) defines the size of the cache,
whose optimal size depends on the amount of news kept on line on the
NNTP-server.  Values of 5-10 gives reasonable results.  The effect is
most striking when reading digested news.

The location and size of the cache can also be changed on a per-user
basis via the related nntp- variables (see nn.1).


			     INSTALLATION
			     ------------

Making and installing nn using NNTP does not differ from a non-NNTP nn
installation, except for the differences in the configuration and the
need to specify the NNTP server in the NNTP_SERVER file.

				INEWS
				-----

If you want to post news via the NNTP server, you will need to run a
program named `(mini-)inews' which is included in the normal NNTP
distribution.  However, since this is the only part of the NNTP you
need to run nn, a recent version (1.5.7) of the mini-inews program is
included with nn in the inews/ directory.

If you already have installed and maintain mini-inews on your system,
you should not use the version that comes with nn - it would just be
extra unnecessary work.

However, if you don't run mini-inews already, using the version that
comes with nn will be somewhat simpler to configure, because it takes
advantage of the definitions you have already made for nn in config.h.

Thanks to Steve Simmons who contributed the simplified inews
configuration (which I took the freedom to simplify even further).

To configure and install mini-inews, all you should need to do is
(everything must be done with inews/ as current working directory):

	$ cd inews
	$ edit conf.h	-- modify as described in the file
	$ make

If things work, type:

	$ su
	# make install

As far as I know, NNTP_MINI_INEWS_HEADER needs to be defined in
nn's config.h for nn to work with this mini-inews version.

See the files inews/README.NN and inews/README for further information.

			       PROBLEMS
			       --------

I am not certain what should happen if the server sends back responses
in the 1xx range.  I do not know whether a NNTP server is allowed to
return one of these responses on its own initiative.  If it is, nn
should probably ignore (or display) the messages.  Currently, nothing is
done to treat these responses in any way.

		      SPONTANEOUS NNTP ERROR 502
		      --------------------------

Sometimes nn  may stop with the following message:

	NNTP 502 You only have permission to transfer, sorry. 

This particular case is probably the result of the NNTP server trying to
turn your IP address into a fully qualified domain name (FQDN) so it can
look you up in its access file.

The NNTP server probably uses the domain name server (DNS) to map IP
addresses into FQDNs.  If the local DNS doesn't already know the answer, it
has to go out over the network to find it.  This can take a few seconds, and
the library routine that does all this for the NNTP server might time out
before the answer gets back to it.  If this happens, the NNTP server doesn't
know your FQDN, so it gives you the default access specified in the server's
nntp_access file, which is usually "xfer" (article transfer only).

In the time it takes for you to run nn again the DNS usuallu has its answer
back, so things usually work the second time.  

One way to work around this problem is to specify the IP address of the
client in the nntp server's access file; then it is not necessary to lookup
the FQDN.

Thanks to Tim Ramsey and Nick Sayer for this information.


		      DEBUGGING NNTP CONNECTIONS
		      --------------------------

In  nn  you can turn on the nntp-debug variable in
the init file.


