[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: POP handling commands given in wrong state
On 27/07/2011 05:57, Mykyta Yevstifeyev wrote:
Hmm, I think if you are talking about existing implementations using
a deprecated system, then trying to alter the behaviour of them is
unlikely to achieve anything...
I wouldn't say it is deprecated; POP-over-TLS is used even more often
that STLS, as I've already mentioned. We're trying to give it the
official documentation and set the standard behavior of the server/client.
It is 'discouraged' then. Also, because, as of now, there is no
standards track document saying how POP3-over-TLS should work, I think
you can safely call it non-standard. Non-standard + 'discouraged' + a
better standardised option = seems to suggest that no one should be
starting to use that system now... There is no good reason to use
POP3-over-TLS instead of STLS, so I think it needs to be made clear that
POP3-over-TLS is second-best compared to STLS (as someone who's
implemented both, I found STLS a lot easier than POP3-over-TLS to
If you are trying to specify what future servers who want to use this
'discouraged' system should do, then simply say they must start up in
the authorization stage after the TLS session has been started (just as
with STLS). Anything else is too far from the POP3 standard, and as
Randall said 'magic'.
I am not aware of any 'well known' POP3 clients which will skip the
authorization stage, so any server which requires this must just be used
for 'internal' use, and thus not really relevant for standards. Internal
use servers can do anything they want so these aren't doing
'POP3-over-TLS', they're doing 'almost-POP3-over-TLS' which is fine for
The only reason to do a POP3-over-TLS implementation nowadays should be
to allow compatibility with some popular old software which doesn't
support STLS. AFAIK, that is essentially old versions of Outlook/Outlook
Express - those use USER/PASS after connecting over TLS.
I strongly feel that the POP3 session should start in the authorization
stage, as understood by everyone who uses a standardised POP3 service
(ie one where the developer has read RFC 1939). So, USER/AUTH/APOP is
needed as one of the first commands after connecting.
As Randall suggested, use SASL EXTERNAL if you want (isn't this the
whole point of SASL EXTERNAL?), but you should need an AUTH. What's the
problem with needing that?
In our case the AUTHORIZATION is safely replaced by TLS negotiation.
It also happens directly after TCP connection, but skipping the
greeting, which is replaced by TLS ServerHello message.
Which is breaking the POP3 standard, because the greeting is specified
as a 'one line [text] greeting'
If you are just wanting to document existing behaviour, then this
doesn't matter, as neither the extended response nor standard
compliant behaviour is possible.
But if we try to unify all existing behavior, this will be great,
Well, what would be great IMHO would be to destroy all POP3-over-TLS
implementations... They should never have been done in the first place!
But, failing that, it's fairly obvious the 'most correct' implementation
is to do it as Gmail, Thunderbird, etc, etc have done, and have it as
normal RFC 1939 but with a TLS 'wrapper' around the session.
The 'broken' implementation of not needing AUTH after session
establishment is the one that needs to be fixed somehow. Either you
kludge it by having some mechanism that the client needs to understand
for the server to say 'I'm in the wrong state now', or you fix it
properly by having the server enter AUTHORIZATION state.