Re: POP handling commands given in wrong state

Alexey Melnikov <> Thu, 04 August 2011 15:01 UTC

Received: from (localhost []) by (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
Received: (from majordom@localhost) by (8.14.4/8.13.5/Submit) id p74F1BoM027821; Thu, 4 Aug 2011 08:01:11 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.14.4/8.14.3) with ESMTP id p74F198K027816 for <>; Thu, 4 Aug 2011 08:01:10 -0700 (MST) (envelope-from
Received: from [] ( []) by (submission channel) via TCP with ESMTPA id <>; Thu, 4 Aug 2011 16:01:26 +0100
Message-ID: <>
Date: Wed, 03 Aug 2011 16:49:29 -0400
From: Alexey Melnikov <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090303 SeaMonkey/1.1.15
To: Mykyta Yevstifeyev <>
CC: Chris Newman <>,
Subject: Re: POP handling commands given in wrong state
References: <> <> <> <> <> <> <> <> <> <83B7234709A6F65D7EC783FE@96B2F16665FF96BAE59E9B90> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: <>
List-ID: <>
List-Unsubscribe: <>

Mykyta Yevstifeyev wrote:
> 29.07.2011 17:21, Chris Newman wrote:
>> --On July 29, 2011 7:04:36 +0300 Mykyta Yevstifeyev 
>> <> 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).