ietf-nntp Draft 17 pre-2

[Ken Murchison]

Russ Allbery wrote:
> 
> Ken Murchison <ken at oceana.com> writes:
> 
> > This is to prevent some dumb client from trying a plaintext mechanism
> > USER/PASS or PLAIN only to find out that the server has disabled these
> > (either entirely or until protected by TLS) for security reasons.
> 
> This isn't a problem for AUTHINFO USER since AUTHINFO USER will return an
> error and the client then won't continue by sending the password.  Does
> SASL PLAIN have this problem, or does it similarly have a way for the
> server to abort the authentication before the password is sent?

Well, yes and no.  If the client sends an initial response, eg:

AUTHINFO SASL PLAIN AHRlc3QAdGVzdA==

then the cat is already out of the bag.  If it doesn't (costing an extra
round trip), eg:

AUTHINFO SASL PLAIN

the the server can return a 482 or something and the client should not
send the response.

IMO this is a kludge.  The whole point of LIST EXTENSIONS is so the
client can discover the presense of optional functionality (and in the
case of SASL, available mechs).  What's the point of having it if we're
not not going to encourage/require that be used?


> > I'd consider a client that knows about LIST EXTENSIONS, but doesn't use
> > it (eg, just tries commands to see what works and what doesn't), at the
> > very least unfriendly and at the worst poorly implemented.
> 
> I think this is going to depend some on what extensions one is using.  In
> another five years, for example, I certainly won't expect clients to send
> LIST EXTENSIONS before trying OVER.

Why not?  It might be safe to assume that all servers implement OVER,
but what's the harm in checking?  Is there some technical reason why
clients would/should/might not want to do option discovery, or is this
just an argument being made by potentially lazy authors (not saying that
Russ is lazy)?

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