- Jan Kundrát, 2006-04-02 01:09:
Thomas Zajic wrote:
I also haven't done any RFC digging, so I don't know if this is TB's problem or Dovecot's. Is it okay for an IMAP server to first advertise "LOGINDISABLED", and then, after a successful TLS negotiation, change its mind and offer "AUTH=PLAIN"?
Yup. Some servers use it to prevent clients from sending plaintext passwords etc.
I went through the relevant TB sources (mailnews/imap/src/nsImapProtocol.cpp), and from a quick glance it looks like TB is prepared to handle this case just fine. TB is actually supposed to do STARTTLS if requested, no matter what, and ask for capabilities again after that. So either the code to handle this case is buggy, or TLS fails for some unknown reason. I can't imagine it's the latter, though, because TLS works fine with secure authentication, and the choice of authentication method should not influence the outcome of TLS negotiation at all.
Is there a way to get a complete unencrypted session transcript from either Dovecot or TB to find out what's going on? Even with all of Dovecot's *_debug and *_verbose options set to "yes", all I get in my log files is
Apr 2 10:46:27 airframe dovecot: Dovecot v1.0.beta3 starting up Apr 2 10:46:28 airframe dovecot: auth(default): passwd-file /usr/local/etc/dovecot-passwd: Read 1 users Apr 2 10:46:48 airframe dovecot: imap-login: Aborted login: rip=192.168.1.1, lip=192.168.1.3, TLS
Thomas
=-------------------------------------------------------------------------=
- Thomas "ZlatkO" Zajic zlatko@gmx.at Linux-2.6.16 & Thunderbird-1.5 -
"It is not easy to cut through a human head with a hacksaw." (M. C.) -