ietf-nntp LIST EXTENSIONS non-pipelined and non-cacheable?

Ken Murchison ken at oceana.com
Wed Sep 10 07:09:26 PDT 2003


Clive D.W. Feather wrote:

> Note that what you're saying is:
> 
>     [C] DATE
>     [C] AUTHINFO SASL PLAIN asdlfnkasf
>     [S] 111 20030910090204
>     [S] 502 No mechanism available
> 
> is fine but, on the other hand:

I'm not saying this is fine at all.  A client MUST make sure that the 
plaintext mechanism can be used before using it.

> 
>     [C] LIST EXTENSIONS
>     [C] AUTHINFO SASL PLAIN asdlfnkasf
>     [S] 202 Extension list follows:
>     [S] AUTHINFO USER
>     [S] .
>     [S] 502 No mechanism available
> 
> isn't.

Correct, for the same reason as above.


> You are assuming that clients will always use LIST EXTENSIONS to decide how
> to do authentication. Surely it's equally likely that they'll just work
> down their list of known methods in order of security, or something like
> that?

That would be extremely poor design.  As I said before, why would a 
client author be so stupid as to blindly try a bunch of command and/or 
authentication mechanisms in a hit-or-miss fashion, when in ONE rountrip 
is can find out exactly what it can and can't do?

I ask again, why would a client NOT want to use LIST EXTENSIONS?

> In any case, forcing a LIST EXTENSIONS isn't going to cure any client that
> badly designed.

True, but we also shouldn't encourage what IMO is bad design.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp




More information about the ietf-nntp mailing list