[NNTP] LIST EXTENSIONS (again)

Russ Allbery rra at stanford.edu
Tue Nov 9 21:02:23 PST 2004


"Andrew - Supernews" <andrew at supernews.net> writes:

> Then you might give reader access to a peer for diagnostic or monitoring
> purposes. You might give reader access to a "peer" who is actually a
> suck-feeding client because you want them feeding you posts back
> properly rather than using rpost. Then there are some caching/proxy
> setups where you want both reader and transfer access from the cache to
> the real server. Then there are probably more scenarios I've not thought
> of (Russ might have some).

News administrators often open up transfer access to their own
workstations for testing purposes.  I have several hosts with both
transfer and reader access because some jobs that run on those hosts want
to inject Usenet messages without adding the standard trace headers for
various reasons.  Some providers offer both IHAVE and reader access to
clients, and one way to do this is to use the MODE READER support in INN.

Andrew's case of the single host is the most common, but there are a bunch
of other edge cases.  Usually they only involve fairly sophisticated
users.

> You'll notice in all of the above that the chances of something like
> Pine running into the issue are quite low (really only the single-user
> host case). OTOH, clients like perl's Net::NNTP are more likely to need
> correct MODE READER handling.

And indeed there have been various bugs in that area and work put into it
at various times.  It always sends MODE READER at the beginning of the
connection unless explicitly configured not to, but it ignores any failure
of the command (which is how it works around Diablo's issue).

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the ietf-nntp mailing list