User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Build Identifier: version 1.5.0.2 (20060308) and older
Thunderbird tries to log on using username/password before asking for encryption. This results in Thunderbird not being able to communicate with server if server requires encryption.
Tested with other e-mail client (Eudora on Mac) and it managed to communicate by TLS using same server/port etc.
Error message: You cannot log in to imap.uio.no because the server has disabled login.
Reproducible: Always
Steps to Reproduce:
1. Choose Account Setting -> Server Settings -> TLS/143 (not TLS if available)
2. Turn off any unencrypted communication on mail server
Actual Results:
You no longer receive e-mail/get error message because Thunderbird tries to log on using username/password before asking for encryption.
Expected Results:
Asked for encrypted line before tring to log on using username/password
Tested on Thunderbird 1.0.2 -> 1.5.0.2 on several hundreds of users (unintended)

(In reply to comment #4)
> All I see in that log is us trying STARTTLS and it failing - did we actually
> successfully logon in that session?
No. It looks as if Thunderbird try to log in using username/passowrd anyway, before asking to turn encryption on.
So logon fails (unless imap-server accepts unencrypted logon, but then it succeeds without encryption, and that was not what was wanted).
Only problem when starting Thunderbird. If you start Thunderbird and then turn unecrypted authentiction off on the imap-server everything works well. So it's looks like the problem is in the sequence of actions (ask for encryption first, then authenticate. Not the other way around)

Can you attach a log showing that? This log, as I said, just shows STARTTLS failing over and over again, and no actual logon attempt, successful or otherwise. Or else I'm missing something - do you see an actual logon in that log?

I've checked in the last patch in bug 311939 - if you want to try a trunk build from tomorrow or later and let me know what shows up in our imap protocol log in this situation, that would be very helpful. That patch detects an ssl level error doing starttls and aborts the connection if it gets such an error. I've added the error value to the log as well. Thx!
http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

a Thunderbird protocol log from that build would still be interesting to me, because I could see what error you're getting - I'm glad it's working for you, but I doubt we're putting up an appropriate error message in your situation, and that's what I'd like to try to do.

(In reply to comment #11)
> JarrE, do you still see this problem?
> If so, log needs analysis
The problem was fixed (Thunderbird failed if imap-server demanded encrypted line, since it first tried unencrytpted and received error message).
What remained was fixing error-messages since messages and errors were uncorrect.
So severity is no minor, but it should be fixed so that it is easier to understand what failes based on error-messages...
Mvh/
JarrE

Uncertain what you mean.
It looks as if 347995 and 376252 is the same bug as what remains of this. Main problem (if I have understood and remeber correctly) is that there is an incorrect mapping of errors and messages...
Do not think there exists a description for what's left to do except sort of 'check mapping between errors and messages'

Hi JarrE. what I mean is, do those bugs describe ALL of what is you think is still incorrect - as stated in comment 12? If not, please file a new bug.
As for this bug, I suggest the original problem as described is done - fixed by bug 311939 as you state in comment 8. duping to bug 311939.

Status: ASSIGNED → RESOLVED

CC: mkmelin+mozilla

Last Resolved: 11 years ago

Keywords: qawanted

Resolution: --- → DUPLICATE

Summary: TLS not working as intended → TLS not working as intended - Thunderbird tries to log on using username/password before asking for encryption

To me, this sounds like an edge-case situation, especially as I believe we haven't seen other reports of it. Therefore not blocking 3.0.x at the moment. If more information comes to light then we can reconsider.

Your server is dropping the connection during the STARTTLS process, according to that log. That implies a configuration issue on the server, or unhappiness perhaps with a client cert. Is there an ssl cert installed on the client? The fix for bug 549457, which landed yesterday, makes us tell the user when there was an error doing starttls.

Same profile and user on different computers. Win32 (XP & Vista) fails. Linux & Windows 7 (64-bit) works.
Sounds like the problem follows the OS, not the server (we have 14000 computers (laptops etc excluded) and tested on many of those. No exceptions in behaviour so far). And no certs installed (tried clean installations of OSs with no other programs installed)

Problem found, solved and it was ours (embarrased now).
You can close the bug.
For the record the bug existed because of a misconfigured anti-virus server which checked traffic on port 143, delaying it til it used to much time for communication to work.
Thank you for all time used trying to understand the problem and trying to solve it...
Regards/
JarrE