Re: POP handling commands given in wrong state

Mykyta Yevstifeyev <> Wed, 27 July 2011 05:04 UTC

Received: from (localhost []) by (8.14.4/8.14.3) with ESMTP id p6R54Q5u046235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 22:04:26 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.14.4/8.13.5/Submit) id p6R54PhI046234; Tue, 26 Jul 2011 22:04:25 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.14.4/8.14.3) with ESMTP id p6R54Oah046229 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for <>; Tue, 26 Jul 2011 22:04:25 -0700 (MST) (envelope-from
Received: by eya28 with SMTP id 28so1890789eya.21 for <>; Tue, 26 Jul 2011 22:04:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3mbBOIrNda0gSNOjWUg8+HKFvMN3KI7mIpMh8Kf85n4=; b=MEGYbBOv9X4/e4/Sf4behXAZPQ4z/sl63QABlmix2Ul3t8bk6xB80Yz9EAAqMznOsW A/8ThO1WHFRWheRY+O6IMHmnY1N6IqH9rCWDS3XUZT9UxJwfHTuAXwhRA30nZiyYzmIH fK9QdL81OzpB/zD0Rb2Ls+YaND0yAobMwEa90=
Received: by with SMTP id x11mr307560bka.294.1311743079258; Tue, 26 Jul 2011 22:04:39 -0700 (PDT)
Received: from [] ([]) by with ESMTPS id o11sm245720bkt.4.2011. (version=SSLv3 cipher=OTHER); Tue, 26 Jul 2011 22:04:38 -0700 (PDT)
Message-ID: <>
Date: Wed, 27 Jul 2011 08:05:18 +0300
From: Mykyta Yevstifeyev <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Randall Gellens <randy@Qualcomm.Com>
CC: Paul Smith <>,, Alexey Melnikov <>
Subject: Re: POP handling commands given in wrong state
References: <> <> <> <p0624060cca546d8a1a68@[]> <p06240610ca5480599784@[]>
In-Reply-To: <p06240610ca5480599784@[]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: <>
List-ID: <>
List-Unsubscribe: <>

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.

S: -ERR [WRONG-STATE/AUTHORIZATION] Not authenticated yet; current state 
C: <authenticates itself>
C: USER foo