ietf-nntp Re: MODE READER (revisited)

[Russ Allbery]

Ken Murchison <ken at oceana.com> writes:

> Having reread 5.2.2 of base-17 and read the previous MODE READER
> threads, how is a single process which can do both peer-to-peer and
> reader connections, supposed to determine which is which?

Probably the best way is to use port 433 for transit connections and 119
for reader connections.  That's what I do, and that makes everything very
straightforward.

Alternately, you can often distinguish pretty easily by the IP address of
the connection; usually one's peers and one's readers form a disjoint set.

Finally, you don't have to do what INN does and separate the
implementations; you can implement the entire protocol in a single daemon
and then just either accept or not accept the peer and the reader commands
based on whatever authentication mechanism that you're using.

MODE READER is discouraged because it's a wart that adds an unnecessary
round trip to every connection and is normally avoidable using some other
technique.

> Would this scenario be in the spirit of the current draft:

> if the IP address of the client matches a known feeder, then allow
> feeder commands only {
>     if the known feeder wishes to become a reader, then it can use MODE
> READER
> }
> else if the client has an unknown IP address, then it becomes an
> anonymous reader (possibly limited/no reader commands based on site
> policy) {
>     if the client uses in-band authentication, then it becomes an
> authenticated reader (access to more/all reader         commands based
> on site policy)
> }

Yes.  That's exactly how INN works.

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

          Please post questions rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.