Re: POP handling commands given in wrong state

[Randall Gellens <[e-mail]>]

At 12:22 PM +0300 7/26/11, Mykyta Yevstifeyev wrote:

>  I meant just the situation like this.  Eg., when one is using 
> POP3-over-TLS whereas TLS connection is established before POP 
> transaction starts, TLS negotiation may be used instead USER-PASS 
> or AUTH authentication, entering the server into the TRANSACTION 
> state; on the other hand, the server may require authentication 
> under TLS layer, entering AUTHORIZATION state after establishing 
> TLS connection.  I and Alexey Melnikov are currently working on the 
> POP-over-TLS specification 
> (https://datatracker.ietf.org/doc/draft-melnikov-pop3-over-tls/) 
> and the problem is that the client don't know what state is the 
> server in after TLS negotiation.  If the client tries giving USER 
> and received -ERR, it may mean that the user name is unknown or 
> that the user is authenticated already, and the client can't know 
> for sure what does it mean.  Don't you have other idea of 
> indicating the state?

Per RFC 4206, the server should issue the AUTH-RESP-CODE capability 
tag, indicating "that the server includes the AUTH response code with 
any authentication error caused by a problem with the user's 
credentials" and then in the case you cite, don't issue the AUTH 
response code in an -ERR response to USER.

By issuing the AUTH response code and then not including the AUTH 
response code, that indicates that the error has nothing to do with 
the user's credentials.

I agree that you would have to infer that the user is already 
authenticated, which isn't as nice as having an explicit response 
code.  I'm not sure if it's worth adding the explicit tag or not, but 
don't have an objection to it.


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Think twice before speaking, but don't say "think think click click".