Re: POP handling commands given in wrong state

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

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6QEjmqR007520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 07:45:48 -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 p6QEjm8j007519; Tue, 26 Jul 2011 07:45:48 -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 p6QEjl0n007514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-pop3ext@imc.org>; Tue, 26 Jul 2011 07:45:48 -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=1311691563; x=1343227563; 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<p06240610ca5480599784@[130.129.83.90]> |In-Reply-To:=20<p0624060cca546d8a1a68@[130.129.83.90]> |References:=20<4E2E49AC.9090207@gmail.com>=20<4E2E7708.3 080004@pscs.co.uk>=0D=0A=20<4E2E8762.5030805@gmail.com> =20<p0624060cca546d8a1a68@[130.129.83.90]>|X-Mailer:=20Eu dora=20for=20Mac=20OS=20X|Date:=20Tue,=2026=20Jul=202011 =2007:35:42=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=/u7VZp1tOPObbYiKYW8yK5WdEvk6yQHQ1sAh8g+IWBk=; b=tKIKoP0YGU9gpSKiMd+zteBEW8eLV6ss+XmmAfme1xVddNwK6/EJF7dF gmpaj+6JF14I9qGzX+NvghWw0AV3GPnV+GSNB4IBwmaLNiHOcig9fsbwC nJla2Wnunfazt49X+OO44B6QPU5yvlaMGKLeXtXwCASXvo9gH4PabJbGG Y=;
X-IronPort-AV: E=McAfee;i="5400,1158,6418"; a="105987155"
Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 26 Jul 2011 07:46:02 -0700
X-IronPort-AV: E=Sophos;i="4.67,269,1309762800"; d="scan'208";a="100139140"
Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 26 Jul 2011 07:46:02 -0700
Received: from [130.129.83.90] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.323.0; Tue, 26 Jul 2011 07:46:01 -0700
Message-ID: <p06240610ca5480599784@[130.129.83.90]>
In-Reply-To: <p0624060cca546d8a1a68@[130.129.83.90]>
References: <4E2E49AC.9090207@gmail.com> <4E2E7708.3080004@pscs.co.uk> <4E2E8762.5030805@gmail.com> <p0624060cca546d8a1a68@[130.129.83.90]>
X-Mailer: Eudora for Mac OS X
Date: Tue, 26 Jul 2011 07:35:42 -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 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


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Too often, we see a failure to distinguish sufficiently clearly
between the intrinsic problems of computer science and the
difficulties resulting from the shortcomings of our various
educational systems.                       --Edsger W. Dijkstra