Re: POP handling commands given in wrong state

Randall Gellens <randy@Qualcomm.Com> Tue, 26 July 2011 13:20 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6QDKtQK002204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 06:20:56 -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 p6QDKt6K002203; Tue, 26 Jul 2011 06:20:55 -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 wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6QDKs4s002198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-pop3ext@imc.org>; Tue, 26 Jul 2011 06:20:54 -0700 (MST) (envelope-from randy@qualcomm.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1311686470; x=1343222470; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; z=Message-ID:=20<p0624060cca546d8a1a68@[130.129.83.90]> |In-Reply-To:=20<4E2E8762.5030805@gmail.com>|References: =20<4E2E49AC.9090207@gmail.com>=20<4E2E7708.3080004@pscs. co.uk>=0D=0A=20<4E2E8762.5030805@gmail.com>|X-Mailer:=20E udora=20for=20Mac=20OS=20X|Date:=20Tue,=2026=20Jul=202011 =2006:17:24=20-0700|To:=20Mykyta=20Yevstifeyev=20<evnikit a2@gmail.com>,=20Paul=20Smith=20<paul@pscs.co.uk>|From: =20Randall=20Gellens=20<randy@qualcomm.com>|Subject:=20Re :=20POP=20handling=20commands=20given=20in=20wrong=20stat e|CC:=20<ietf-pop3ext@imc.org>,=20Alexey=20Melnikov=20<al exey.melnikov@isode.com>|MIME-Version:=201.0 |Content-Type:=20text/plain=3B=20charset=3D"us-ascii"=3B =20format=3Dflowed|X-Random-Sig-Tag:=201.0b28 |X-Originating-IP:=20[172.30.39.5]; bh=Yl0FZjYeaM38dbUwZeRqG9f85NWHwhQqCt/+9JhNtl8=; b=DdmRMl0H6ZDv2XUPgpyWv0c6dXz+VA53Ml8tbImc2VPL/kcbq5Q/S+wv qtdpQFljWMsdJ++j4t6f3vvl01HC6YRGs0G9/gxNbRNaw/bl9YRdzUUmu KjjhLBRixT8hX2txuNvQAdIEywwLkCn5idWekq9z+JLL9J4Yj8kdk9Mme 4=;
X-IronPort-AV: E=McAfee;i="5400,1158,6418"; a="105962769"
Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine01.qualcomm.com with ESMTP; 26 Jul 2011 06:21:09 -0700
X-IronPort-AV: E=Sophos;i="4.67,266,1309762800"; d="scan'208";a="118417072"
Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 26 Jul 2011 06:21:08 -0700
Received: from [130.129.83.90] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.323.0; Tue, 26 Jul 2011 06:21:08 -0700
Message-ID: <p0624060cca546d8a1a68@[130.129.83.90]>
In-Reply-To: <4E2E8762.5030805@gmail.com>
References: <4E2E49AC.9090207@gmail.com> <4E2E7708.3080004@pscs.co.uk> <4E2E8762.5030805@gmail.com>
X-Mailer: Eudora for Mac OS X
Date: Tue, 26 Jul 2011 06:17:24 -0700
To: Mykyta Yevstifeyev <evnikita2@gmail.com>, Paul Smith <paul@pscs.co.uk>
From: Randall Gellens <randy@Qualcomm.Com>
Subject: Re: POP handling commands given in wrong state
CC: <ietf-pop3ext@imc.org>, Alexey Melnikov <alexey.melnikov@isode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [172.30.39.5]
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>

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