Peter Stuge wrote:
On Fri, Jan 14, 2005 at 08:14:05AM +0100, Peter Stuge wrote:Great! You are just too fast. Haven't even got the time to look at the code (it was planned for this weekend) ;-)
On Fri, Jan 14, 2005 at 06:50:55AM +0100, Hasse Hagen Johansen wrote:
Yes it is working fine, but I cannot force users to use either
StartTLS or imaps ;-) I think I maybe can try to fix this in the
source (I believe it should be pretty simple? Even for me...some if
about reading STARTLS as the first command right?)
First find the STARTTLS command handler and see if/how it stores the fact that an SSL negotiation was successfully completed.
Then find the place where the "plain login not allowed" error message is printed, that will probably be right after the check for SSL-mode. Add the state information set by the STARTTLS handler to this condition, and it should be all done.
If the STARTTLS doesn't set any global state, perhaps look for what
the --ssl parameter leads to, and just enable that after a successful
STARTTLS. :)
I figured why not dive into the code myself. I'll file this with the tracker and include a patch in a minute.
bincimap-up doesn't allow plaintext login even after successful STARTTLS.
This is because noone ever checks session["sslmode"] after it has been set. It is only checked by the STARTTLS handler itself, to ensure noone tries to do STARTTLS more than once.
The STARTTLS handler also set session["sslmode"] to "yes" rather than "true" I fixed that and added checks for session["sslmode"] to operator-capability.cc, operator-authenticate.cc and operator-login.cc where bincimap-up checks if plain text is ok.
//Peter
/Hasse
