NNTPCache is a proxy cache newsgroups.
NNTPCache (efficiently) executes on the localhost pretending to be an NNRP news reading server. In fact, what it does is pass certain NNTP commands through to real (remote and possibly local) news-servers based on various pattern matching rules.
NNTPCache then takes the output from those servers and caches & indexes it in funky ways (much case specific magic goes into this). The next time such information is asked for, or other information which can be logically inferred from the previously collated information, it is sent directly from the cache, without consulting the remote servers.
NNTPCache can transparently merge local newsgroups & multiple remote feeds (usually handled by INN) with remote NNRPD and NNTPCache servers to create mind-bogglingly large "virtual" newsfeeds, without having to negotiate for standard feeds or allocating anything like bandwidth or drive space normally required (normally around 3-10G/day).
NNTPCache is an obsessive SPAM killer. NNTPCache has full support for cryptographically signed NoCem messages, and if enabled, actively monitors news.lists.filters and alt.nocem.misc for NoCem SPAM advisories. Tagged SPAM message ID's are then transparently filtered from NNTPCache traffic.
NNTPCache can also act selectively as an intelligent chrooted firewall NNTP application proxy and supports full RFC931/ident, source address and newsgroup access controls with quite a reasonable degree of granularity.
NNTPCache saves IMMENSE amounts of bandwidth (we were quite astounded to see just how much bandwidth news uses - on our network, news accounted for more IP traffic than everything else combined (though we're not sure if this says more about the authors' proclivities or network traffic statistics in general.
NNTPCache also saves truly huge amounts of drive space (if you are talking about a full feed - as of writing that's around 3 - 10Gb a day). With NNTPCache, startup times for news readers become limited only by the speed of the internal network (or the loopback device if the readers are run on the same machine as NNTPCache). It is possible to run several NNTPCached's on different machines - indeed with larger sites, this practice is recommended; even intranets can become clogged with news traffic.
NNTPCache tries very hard to look like nnrpd, so there shouldn't be any reason why the remote servers that NNTPCache is directed to feed from can not be other NNTPCache's themselves.
NNTPCache performs sophisticated filtering based on weighted extended regular expression pattern matching against article headers and content on a per-user, per-group, per-host (etc) basis (so the filters only effect particular user groups, not the entire population). This can be used (for instance) as a kind of Usenet "net-nanny" or to transparently remove usenet SPAM (and probably a few not so nice uses as well, like political censorship. Sadly to say though, after introducting this feature we have had not had one iota thanks from neo-corporate east-asian totalitarian capitalist running dogs). ).
NNTPCache tries very hard to emulate remote article numbering. This means that NNTPCache can be "dropped" in into an nntp network without interrupting (at the news level) the flow/ordering of articles. In the same manner, it can be transparently "plucked" from the network in the same way should it not prove to be as sexy as a sweet, ripe, red persimmon (well, it's unlikely, but you never know.
NNTPCache caches the active, active.times, newsgroups and overview.fmt files, article, head, body, stat, group, listgroup, newgroups, newgroups, xgtitle, xover and xhdr commands. NNTPCache cross-posts seeds its cache and also maintains a database of message-id -> group/article_number tuples. This is just about everything.
NNTPCache has been designed to be quite efficient, in order to serve very large reader populations. It takes full advantage of copy-on-write OS design, shared memory and mmaped files/memory/anonymous regions.
NNTPCache has a built in web-server and macro language - ostensibly for displaying NNTPCache statistical information, but the depraved or security retentive (ok, ok, AND) could use it for other diversions.
Alleged to autoconfigure, compile and run, dance and make walnut milkshakes on a wide number of unix platforms. But not NT (of course!).