Re: POP handling commands given in wrong state

Alexey Melnikov <alexey.melnikov@isode.com> Thu, 04 August 2011 15:01 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p74F1BEl027822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Aug 2011 08:01:11 -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 p74F1BoM027821; Thu, 4 Aug 2011 08:01:11 -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 rufus.isode.com (rufus.isode.com [62.3.217.251]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p74F198K027816 for <ietf-pop3ext@imc.org>; Thu, 4 Aug 2011 08:01:10 -0700 (MST) (envelope-from alexey.melnikov@isode.com)
Received: from [188.29.26.188] (188.29.26.188.threembb.co.uk [188.29.26.188]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <Tjq0RQBd6UtX@rufus.isode.com>; Thu, 4 Aug 2011 16:01:26 +0100
Message-ID: <4E39B459.9050102@isode.com>
Date: Wed, 03 Aug 2011 16:49:29 -0400
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
CC: Chris Newman <chris.newman@oracle.com>, ietf-pop3ext@imc.org
Subject: Re: POP handling commands given in wrong state
References: <4E2E49AC.9090207@gmail.com> <4E2E7708.3080004@pscs.co.uk> <4E2E8762.5030805@gmail.com> <4E2E8E10.9070209@pscs.co.uk> <4E2EBEC5.1000306@gmail.com> <4E2EC1E0.7010504@pscs.co.uk> <4E2F9AA7.80901@gmail.com> <4E2FD131.3020406@pscs.co.uk> <4E323154.8050802@gmail.com> <83B7234709A6F65D7EC783FE@96B2F16665FF96BAE59E9B90> <4E33D102.7030503@gmail.com>
In-Reply-To: <4E33D102.7030503@gmail.com>
MIME-Version: 1.0
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>

Mykyta Yevstifeyev wrote:
> 29.07.2011 17:21, Chris Newman wrote:
>> --On July 29, 2011 7:04:36 +0300 Mykyta Yevstifeyev 
>> <evnikita2@gmail.com> wrote:
>>> I would really be happy if existing POP-over-TLS implementations 
>>> adhered
>>> usual POP behavior as defined in RFC 1939, and I would be happy to
>>> describe it in the corresponding document.  However, if we want to 
>>> define
>>> the current practices, we should document the technology as-is.  If we
>>> want to give POP-over-TLs a standard definition of operations, I don't
>>> really think those implementation which used the discussed POP-over-TLS
>>> algorithm will break their behavior.
>> We have a choice to define POPS-with-client-certs based on what has 
>> been deployed or define it based on how we think it should work. The 
>> latter is an architecturally cleaner choice, but is unlikely to cause 
>> the deployed implementations with the former behavior to change.
> I actually have the same opinion, but in order to suit RFC 1939 
> requirements, I think defining the mandatory use of SASL EXTERNAL 
> mechanism after TLS-authenticated POP-over-TLS session establishment 
> should resolve the issue.  Even if the server has authenticated the 
> user upon TLS negotiation, formal authentication with RFC 5034 AUTH 
> command using EXTERNAL mechanism will be obligatory to be preformed.
I strongly prefer documenting existing behaviour for POP3S (and document 
what is broken with it, if anything).
I don't think mandatory use of SASL EXTERNAL is necessarily the current 
practice. Other SASL mechanisms can be used on pop3s ports (at least in 
some server implementations).