Re: POP handling commands given in wrong state

Mykyta Yevstifeyev <evnikita2@gmail.com> Tue, 26 July 2011 09:21 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6Q9LvYw089409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 02:21:57 -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 p6Q9Lvuo089408; Tue, 26 Jul 2011 02:21:57 -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-ew0-f43.google.com (mail-ew0-f43.google.com [209.85.215.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6Q9LsVK089394 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for <ietf-pop3ext@imc.org>; Tue, 26 Jul 2011 02:21:56 -0700 (MST) (envelope-from evnikita2@gmail.com)
Received: by ewy20 with SMTP id 20so338718ewy.16 for <ietf-pop3ext@imc.org>; Tue, 26 Jul 2011 02:22:09 -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=9EAGb9xLgkizLPiOtEAgxb+GANUYj8zhgcbogpRp1ik=; b=ZfegCEvfCn5/BHnUy4ySvtsZ1IfyZ91Ai12R2BSgNsdqE6C7ynOVipVoT9FwySU1cU EP3gmZtAszYdc3hOFl8dmj4o51p3U5jt30CeflY0/+TQPLS7BwGi1PArCgued5yodnYg yhl7preAlvVv/0Hnxh6arAkLnRySzy60SGMYo=
Received: by 10.205.82.197 with SMTP id ad5mr1569565bkc.238.1311672129334; Tue, 26 Jul 2011 02:22:09 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id p16sm106326bku.31.2011.07.26.02.22.01 (version=SSLv3 cipher=OTHER); Tue, 26 Jul 2011 02:22:02 -0700 (PDT)
Message-ID: <4E2E8762.5030805@gmail.com>
Date: Tue, 26 Jul 2011 12:22:42 +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: Paul Smith <paul@pscs.co.uk>
CC: 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>
In-Reply-To: <4E2E7708.3080004@pscs.co.uk>
Content-Type: text/plain; charset=UTF-8; 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 11:12, Paul Smith wrote:
> On 26/07/2011 05:59, Mykyta Yevstifeyev wrote:
>
> [ . .  .]
>
> If the state was server defined, so that it may change on the server's 
> decision, rather than by purely bad coding in the client, then yes, an 
> extended response code may be useful, but when it is only bad coding 
> in the client which can make it happen - no.
Paul,

[Adding Alexey Melnikov to CC list; see below.]

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?

<thinking>The user agent may allow the user to choose the authentication 
way for POP-over-TLS transaction.  Eg., Thunderbird allows me to set 
POP-over-TLS and then one of the following: (1) plain auth. under TLS, 
(2) use AUTH command, (3) use Kerberos, or (4) use TLS certificate.  I 
suppose if (4) is chosen, -ERR indicates that TLS certificate didn't 
lead to successful authentication and server is in AUTHORIZATION and +OK 
means that server is in TRANSACTION.  (1), (2) and (3) assume that the 
server enters the TRANSACTION state after TLS negotiation and requires 
additional authentication.  I don't know the situation with Outlook 
and/or something else, but I suppose it will be rather the same and this 
issue may be successfully resolved.  So what's your opinion, Alexey? 
(Comments from 3rd parties are welcome as well, of course.)</thinking>

Mykyta
> Just my 2p worth