[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 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.