Re: POP handling commands given in wrong state

Mykyta Yevstifeyev <evnikita2@gmail.com> Wed, 27 July 2011 05:04 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (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 owner-ietf-pop3ext@mail.imc.org)
Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p6R54PhI046234; Tue, 26 Jul 2011 22:04:25 -0700 (MST) (envelope-from owner-ietf-pop3ext@mail.imc.org)
X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-pop3ext@mail.imc.org using -f
Received: from mail-ey0-f176.google.com (mail-ey0-f176.google.com [209.85.215.176]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6R54Oah046229 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for <ietf-pop3ext@imc.org>; Tue, 26 Jul 2011 22:04:25 -0700 (MST) (envelope-from evnikita2@gmail.com)
Received: by eya28 with SMTP id 28so1890789eya.21 for <ietf-pop3ext@imc.org>; Tue, 26 Jul 2011 22:04:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.204.18.203 with SMTP id x11mr307560bka.294.1311743079258; Tue, 26 Jul 2011 22:04:39 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id o11sm245720bkt.4.2011.07.26.22.04.36 (version=SSLv3 cipher=OTHER); Tue, 26 Jul 2011 22:04:38 -0700 (PDT)
Message-ID: <4E2F9C8E.8040403@gmail.com>
Date: Wed, 27 Jul 2011 08:05:18 +0300
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
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 <paul@pscs.co.uk>, ietf-pop3ext@imc.org, Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: POP handling commands given in wrong state
References: <4E2E49AC.9090207@gmail.com> <4E2E7708.3080004@pscs.co.uk> <4E2E8762.5030805@gmail.com> <p0624060cca546d8a1a68@[130.129.83.90]> <p06240610ca5480599784@[130.129.83.90]>
In-Reply-To: <p06240610ca5480599784@[130.129.83.90]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=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.

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