[NNTP] LIST EXTENSIONS (again)

[Andrew - Supernews]

>>>>> "Ken" == Ken Murchison <ken at oceana.com> writes:

 Ken> Argh!!!  I didn't realize that we have two contradicting
 Ken> servers, one which requires MODE READER before AUTHINFO (INN)
 Ken> and one that requires AUTHINFO before MODE READER (Diablo).

Diablo does not require MODE READER at all. But it will give a 480
response to it if authentication is required and the client hasn't
authenticated yet.

 Ken> Unless this can be worked out with some combination of existing
 Ken> failure responses (which I'm sure Mark has tried),

This algorithm works for slrn, knews, gnus at minimum, against all known
servers:

0) connect to server and get initial banner
1) send MODE READER
   - if response is 480, then:
      - execute authentication procedure
      - send MODE READER again
   (the handling of 480 there can be generic code used for all commands)
2) if the configuration specifies that we should authenticate preemptively,
   and we've not authenticated yet, then execute the authentication
   procedure now
3) proceed with reader commands

What this would end up being replaced with, after adding in all the
new stuff from the draft, is something along these lines:

0) connect to server and get initial banner
1) send LIST EXTENSIONS
2) if the extensions output indicated that MODE READER is required,
   _or_ this is an old (non NNTPv2 or whatever we call it) server,
   then:
       send MODE READER
         - if response is 480 (should only happen on an old server),
           then:
            - execute authentication procedure
            - send MODE READER again
         mark old LIST EXTENSIONS data invalid
3) execute authentication procedure unless we already did it
4) proceed with reader commands

The authentication procedure would be something like:

0) do LIST EXTENSIONS if we don't have valid data yet
1) if TLS is desired, or if the available auth schemes don't
   include a desired one, then do STARTTLS and get the
   LIST EXTENSIONS data again
2) if no suitable auth scheme available, fail
3) do AUTHINFO with the desired scheme

This should mean that when a new client is talking to a new server,
assuming the client wants both tls and auth, the sequence is:

 LIST EXTENSIONS
 STARTTLS
 LIST EXTENSIONS
 AUTHINFO
 LIST EXTENSIONS (if needed)
 ...normal commands...

 Ken> Does anyone know if the Diablo design has the same dependency on
 Ken> MODE READER as INN?  Andrew may have covered this, but I don't
 Ken> recall what he said.

You could always read my messages again.

 Ken> Hmm, thinking on my feet...

 Ken> What about this heuristic for INN?  AFAIK, most sites have a
 Ken> list of peers that they are willing to accept an NNTP feed from.
 Ken> When innd accepts a connection, it checks the remote hostname/ip
 Ken> against its table and if it finds a match, it stays in transit
 Ken> mode.  If it doesn't find a match, it automatically switches to
 Ken> reader mode (nnrpd).

This is exactly what INN always did.

 Ken> I would imagine that a feeding host wouldn't also have reading
 Ken> clients originating from it.

Well, that's the problem; your imagination isn't covering the
real-world cases. The most common case, for example, is when you run a
client directly on the server itself (either because you're the admin,
or it's a single-user box, or the client is some automated script or a
web interface or similar); by default INN gives transfer access to
localhost. (On something like a multiuser shell box you'd disable
that.)

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).

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.

-- 
Andrew, Supernews
http://www.supernews.com