[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 <evnikita2@xxxxxxxxx> 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).