Re: POP handling commands given in wrong state

[Paul Smith <[e-mail]>]

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 
implement).

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 
internal use.

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, 
> won't it?

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.