Re: [Dovecot] Quick question. Thunderbird/Outlook = no love.
1.0 Beta 3.
Plain authentication works. But not TLS.
I don't see anything in the configuration file that seems obvious to deny TLS authentication.
-Charlie
----- On Friday, March 31, 2006 javert42@cs.byu.edu wrote:
Are there any how-tos or documentation on getting dovecot to be
Charlie Davis wrote: thunderbird/outlook friendly?
Thunderbird can connect about 20% of the time, the other 80% of the time, I
Get the error:
"You may need to connect via SSL or TLS. Please check the account settings
for your mail server."
I have my thunderbird setup to do TLS. I've put it on the TLS if available
as well, still no love.
Dovecot logfile contains:
dovecot: Mar 31 17:25:19 Info: imap-login: Aborted login: rip=10.0.0.4,
dovecot: Mar 31 17:25:24 Info: imap-login: Aborted login: rip=10.0.0.4,
lip=10.0.0.208, TLS lip=10.0.0.208, TLS
Nothing else.
Thanks in advance!
-Charlie
I've got beta2 running on an RHEL4 box, and I've had no problems with Thunderbird (with people running anywhere from 0.7 to 1.5). Which version of dovecot are you running?
-- Topher Fischer GnuPG Fingerprint: 3597 1B8D C7A5 C5AF 2E19 EFF5 2FC3 BE99 D123 6674 javert42@cs.byu.edu
On Fri, 2006-03-31 at 18:56 -0800, Charlie Davis wrote:
1.0 Beta 3.
Plain authentication works. But not TLS.
I don't see anything in the configuration file that seems obvious to deny TLS authentication.
Set auth_verbose=yes and auth_debug=yes in dovecot.conf, maybe it shows then why it's failing?
Turns out some Anti-Virus email scanners don't support TLS.
Sorry again! Not dovecot's fault. Disabled my anti-virus' email scanner and it worked with TLS only.
Good to know for anyone else that ever has this problem. :)
-Charlie
Timo Sirainen wrote:
On Fri, 2006-03-31 at 18:56 -0800, Charlie Davis wrote:
1.0 Beta 3.
Plain authentication works. But not TLS.
I don't see anything in the configuration file that seems obvious to deny TLS authentication.
Set auth_verbose=yes and auth_debug=yes in dovecot.conf, maybe it shows then why it's failing?
Charlie Davis wrote:
Turns out some Anti-Virus email scanners don't support TLS.
Sorry again! Not dovecot's fault. Disabled my anti-virus' email scanner and it worked with TLS only.
Good to know for anyone else that ever has this problem. :)
I have seen this with F-Secure and reported it to them, no fix yet though.
Tomi
- Charlie Davis, 2006-04-01 04:56:
1.0 Beta 3.
Plain authentication works. But not TLS. I don't see anything in the configuration file that seems obvious to deny TLS authentication.
You seem to have a few things mixed up here. TLS doesn't have to do anything with _authentication_, it's a _connection/encryption_ method, like SSL.
With SSL, a connection is encrypted right from the beginning. Typically, a server needs to listen on two different ports when it supports both encrypted and unencrypted connections. With IMAP, this would be 143 for unencrypted connections, and 993 for (SSL-)encrypted connections.
With TLS, a connection starts out unencrypted, and the client and server can (but don't have to) negotiate and switch to an encrypted connection on the fly, on the _same_ port, and without having to reconnect.
That's what you configure in Thunderbird under "Secure connection" - you can have "Never" (= unencrypted connection), "TLS if available" (= try to negotiate an encrypted connection via TLS, else fall back to unencrypted), "TLS" (= use TLS, don't connect if the negotiation fails) and "SSL". On Dovecot's side, the corresponding configuration option is "ssl_disable". When set to "yes", Dovecot doesn't offer TLS negotiation (the "STARTTLS" capability), and it doesn't listen for encrypted connections on port 993.
That's one thing. Now here's the second.
In addition to that, you can tell TB to "Use secure _authentication_" - that's the single checkbox under the "Secure connection" radio buttons (I'm using TB 1.5, it might look different in earlier versions). On Dovecot's side, the corresponding configuration option is "mechanisms" in the "auth" section. This controls the "AUTH=" capabilities that Dovecot offers, see http://wiki.dovecot.org/Authentication for details. So far, the only secure (ie. non "AUTH=PLAIN") method I have found that TB accepts is CRAM-MD5 (using HMAC-MD5 hashes).
Note that you can basically have any combination of secure connections and secure authentication, provided that both client and server support it. There's nothing to stop you from using CRAM-MD5 authentication over an unencrypted connection, or PLAIN authentication over SSL (a rather common thing), or NTLM authentication via TLS, or ... you name it. Granted, not all of these combinations might make sense, but you can still use them if you want.
Sorry if I was only telling you stuff you already knew up to now, but from what I've read in your mails I'm not sure if it's the connection or the authentication that is giving you problems. ;-)
Now, there really seems to be a problem with Thunderbird and using PLAIN authentication via TLS when Dovecot is set to "disable_plaintext_auth = yes" (the default).
It looks like TB only asks for capabilities _before_ the connection is encrypted. At this point, Dovecot answers "LOGINDISABLED", because the connection is not encrypted yet, and there's no way for it to know whether TB is going to issue STARTTLS later on or not. Unless TB is set to "[x] Use secure authentication", it seems to simply give up there, thinking that "AUTH=PLAIN" is not available at all.
Now, if TB would just go ahead with the TLS negotiation, and then ask for capabilities again once the connection is encrypted, Dovecot would now answer "AUTH=PLAIN" instead of "LOGINDISABLED", and TB would be able to authenticate just fine. Alas, this doesn't happen.
There's no such problem when using SSL instead of TLS. With SSL, Dovecot offers "AUTH=PLAIN" even with "disable_plaintext_auth = yes", and TB can authenticate just fine, no matter whether "[x] Use secure authentication" is enabled or not.
To summarize, Dovecot with "disable_plaintext_auth = yes" and Thunderbird configured with ...
... secure connection = SSL, secure authentication = yes: works ... secure connection = SSL, secure authentication = no: works ... secure connection = TLS, secure authentication = yes: works ... secure connection = TLS, secure authentication = no: FAILS
When running Dovecot with "disable_plaintext_auth = no", the last variant works as well.
Note that I haven't done any detailed analysis (source code, packet sniffing) on this matter, but from what I've seen in Dovecot's logs with auth_verbose, auth_debug and auth_debug_passwords, this seems to be the problem.
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"? Is it okay for an IMAP client to assume "AUTH=PLAIN" is not available at all if it sees "LOGINDISABLED", and to not even bother to "STARTTLS" and try again? The example in RFC3501 section 6.1.1. would suggest that Dovecot is right and TB is wrong, but, as I said, I haven't done any more detailed digging.
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.) -
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.
Cheers, -jkt
-- cd /local/pub && more beer > /dev/mouth
- 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.) -
- Thomas Zajic, 2006-04-02 10:54:
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 [...]
Okay, now I'm pretty sure that the problem is somwehere in TB's code (oh great). I modified Dovecot's imap-login to always log the capabilities it sends, and this is what I got:
Apr 2 11:13:20 airframe dovecot: Dovecot v1.0.beta3 starting up Apr 2 11:13:38 airframe dovecot: imap-login: * CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS STARTTLS LOGINDISABLED AUTH=DIGEST-MD5 AUTH=CRAM-MD5: rip=192.168.1.1, lip=192.168.1.3 Apr 2 11:13:38 airframe dovecot: imap-login: * CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS AUTH=PLAIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5: rip=192.168.1.1, lip=192.168.1.3, TLS
Note how it first says "STARTTLS LOGINDISABLED", and then changes to "AUTH=PLAIN [...], TLS". So I assume that from Dovecot's side, the TLS negotiation was successful, and TB may now log in using PLAIN. Somehow, though, TB seems to think otherwise, and presents its dreaded error popup: "You cannot log in to $SERVER because the server has disabled login. You may need to connect via SSL or TLS. Please check the account seetings for your mail server."
Now, the funny thing is that even though this popup comes up every time I click on a mail, and the mail does _not_ get displayed, it _still_ gets marked as read on the server (ie. TB's fat green dot changes to a small grey one). Am I right in assuming that this shouldn't be possible at all if TB was _really_ unable to log in, or is TB tracking a mail's read/unread status locally? But even if TB was doing this, marking the mail read even though it thinks it is not logged in (and therefore unable to retrieve it from the server) would be a bug, no?
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.) -
On Sun, 2006-04-02 at 11:46 +0200, Thomas Zajic wrote:
Now, the funny thing is that even though this popup comes up every time I click on a mail, and the mail does _not_ get displayed, it _still_ gets marked as read on the server (ie. TB's fat green dot changes to a small grey one). Am I right in assuming that this shouldn't be possible at all if TB was _really_ unable to log in, or is TB tracking a mail's read/unread status locally? But even if TB was doing this, marking the mail read even though it thinks it is not logged in (and therefore unable to retrieve it from the server) would be a bug, no?
I think it's a feature. People want to be able to read messages (and have them marked as read, etc) when not connected to Internet. Next time when connection to server is successful, the flags are synced with the server.
participants (5)
-
Charlie Davis
-
Jan Kundrát
-
Thomas Zajic
-
Timo Sirainen
-
Tomi Hakala