Re: POP handling commands given in wrong state

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