[ietf-nntp] AUTHINFO draft 01

[Jeffrey M. Vinocur]

On Sat, 3 Jul 2004, Russ Allbery wrote:

> Clive D W Feather <clive at demon.net> writes:
> 
> > 2.1.2 last para: if you change the syntax to
> >     AUTHINFO USER username...
> >     AUTHINFO PASS password...
> 
> > then the white-space problem mostly goes away, because:
> 
> >     AUTHINFO USER fred flintstone
> >     AUTHINFO PASS very secret
> 
> > becomes legal.
> 
> The only worry here is that many servers split on whitespace before doing
> anything else, and then wouldn't be able to distinguish between:
> 
>     AUTHINFO USER fred flintstone
>     AUTHINFO USER fred  flintstone
> 
> That being said, I have no objections to making the above change; I still
> wouldn't encourage people to use whitespace, though, given that it isn't
> always going to work unless the server handles AUTHINFO specially.

(Hi everybody -- sorry for being silent of late, I was out of the country 
and then catching up on all sorts of backlog.  I'll try to catch the 
important bits of this discussion.)

Anyway, I actually implemented something like the above proposal for 
INN at one point, because it seemed like the sanest "be liberal in what 
you accept" approach when AUTHINFO was only documented by 2980.  And it 
turns out to have the corner cases above with sequential whitespace, as 
well as issues as to what kinds of whitespace are permitted (tabs? CR? 
LF?), and whether leading or trailing whitespace is significant (some 
clients may have been sending extraneous whitespace for years and to 
change the meaning of that whitespace now might be a mess).

And it also turns out to be a mess to implement, because unless you want
to special-case your parser, you have to take the pre-split argument array
and append it back together into something that might look like the
original password.

I don't believe we ever committed the patch for all of those reasons.

Point being, this is no trivial issue.  And given that we're here trying 
simply to document existing implementations, and additionally given that 
many AUTHINFO implementations will never be updated to comply with this 
document anyway, I tend to think that trying to make these changes is 
unrealistic and probably worse than leaving it as is.

Honestly, the biggest problem with the whitespace issue in practice is
that it doesn't result in a good error message with most clients/servers.  
If the only change we ask is for additional awareness and alerting the
user to this issue, I think we'll have made the great majority of the 
improvement possible, and worrying about the last incremental benefit when 
we're already providing a new solution that takes care of all of 
this...just doesn't seem worthwhile to me.


-- 
Jeffrey M. Vinocur
jeff at litech.org