[NNTP] LIST EXTENSIONS (again)

[Russ Allbery]

Mark Crispin <MRC at CAC.Washington.EDU> writes:
> On Tue, 9 Nov 2004, Russ Allbery wrote:

>> Pine in its current implemention as you described it does not work with
>> any INN installation that requires both AUTHINFO and MODE READER.

> Please explain how.

> If the user does not specify a /user=xxx specifier, it will not do
> AUTHINFO, and eventually it will hit a command that sends a 480 and Pine
> will AUTHINFO at that time.

Ah, I didn't realize that you did also do reactive authentication.  (A
misconception of mine from a previous discussion.)  Yes, if you also do
reactive authentication, this implementation works in that mode.  If,
however, the user does specify /user=xxx to force authentication, that
authentication would fail in this situation since it would be done against
the transit server component.

If your client does have everything enabled and sends, as you described
earlier:

    STARTTLS
    AUTHINFO
    MODE READER

in that order to an INN server in a situation that actually requires MODE
READER, STARTTLS would fail, AUTHINFO would fail, and then MODE READER
would actually give you a reader connection.  I expect that this would
throw some sort of error to the user in Pine (and, in fact, I expect that
this configuration of Pine wouldn't proceed after STARTTLS failed).

That MODE READER that you're sending in the order above doesn't work
properly and *never* worked properly with INN unless neither of the
commands before it were actually sent.  (Or, to be more pedantically
correct, the two commands sent before it would not have worked properly,
but it amounts to the same thing.)

This is a great illustration of why we needed a real NNTP standard years
ago, since the implementation that you (quite reasonably) arrived at via
experimentation was, in fact, always broken and never would have worked
properly in the situation you were attempting to allow for.  (That
situation is just quite rare.)  It is indeed the fault of the NNTP
community and the INN developers for not documenting MODE READER clearly
enough so that both you and Diablo made different, apparently reasonable
mistakes in implementation (although Diablo's mistake is frankly less
reasonable than yours).

> The fact still remains that MODE READER itself is a broken, and that it
> is not permissible to require MODE READER before STARTTLS since TLS does
> a complete reversion to initial connection state.

Could you point me at where this is documented?  I'm aware that it
requires discarding all information about server capabilities and all
authentication credentials, but this is a stronger statement that I don't
recall seeing in the documents that I've read.

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