Re: POP handling commands given in wrong state

26.07.2011 17:35, Randall Gellens wrote:
> At 6:17 AM -0700 7/26/11, Randall Gellens wrote:
>
>>  Per RFC 3206, 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.
>
> Just to be clear, if the server issued AUTH-RESP-CODE, then the result 
> to USER can be interpreted:
>     +OK:            Accepted, proceed to PASS
>     -ERR [AUTH]:        Failed, problem with user credentials (not 
> likely with USER anyway)
>     -ERR [SYS/TEMP]:    Failed due to temporary system problem, try 
> again later
>     -ERR [SYS/PERM]:    Failed due to permanent system problem, advise 
> user to call for help
>     -ERR:                No problem w/ credentials nor system, if you 
> used TLS w/ cert, maybe authenticated already
This is an interesting idea.  We can also define the new code, AUTH-YET, 
to answer USER/PASS/AUTH given when already authenticated:

         -ERR [AUTH-YET]:      Already authenticated
         -ERR:                            Other error.

The initially proposed WRONG-STATE can be a generalization of the 
aforementioned AUTH-YET, eg.

C: STAT
S: -ERR [WRONG-STATE/AUTHORIZATION] Not authenticated yet; current state 
is AUTHORIZATION
---
C: <authenticates itself>
C: USER foo
S: -ERR [WRONG-STATE/TRANSACTION] Already in TRANSACTION.
---
etc.

Mykyta
>
>