Blake McBride writes:

Thanks. The current version of Thunderbird auto-detects connection parameters - presumably by trying every combination. All I give is an email address and a password. They also have a manual configuration that I spent a lot of time with. I was never able to do any better than their auto-config.

That's usually the cause of many problems I see with log entries like yours. It could happen when client and server disagree on using STARTTLS or SSL, so hardwiring your client to use whatever your server supports stops the client from fumbling around (and getting it wrong).

Given my experience with all this, I feel confident that Thunderbird is not a factor in the problem.

A network trace could clear that up, but auto-configure is problematic.

In terms of the config, I really don't know what I am doing. I think what I want is clear text passwords sent over an SSL connection. Isn't that secure? I don't know the difference between SSL and that TTSL thing. I really don't care how it is setup. I just want it to be reasonably secure and simple.

You'll need to know these things in order to understand the problem.

The essential difference, as far as your concerned, is that TLS (or STARTTLS or SSLv(some-number-I-forget)) starts out in plain text, then the client issues a command (STARTTLS) to commence the secure (encrypted) communication handshake, whereas SSL dives right in and expects the client to negotiate SSL parameters immediately. These two variations of SSL listen on two distinct ports. If you get these cross up, you'll get the above error log.

In my experiments:

SSL client -> TLS server port:  Aborted login (no auth attempts)
TLS client -> SSL server port: client hangs,
	Disconnected: Inactivity (no auth attempts in 180 secs)

SSL/TLS + clear-text password is secure. If you do not use SSL/TLS, you'll have to use CRAM-MD5 or some challenge-response authentication to defeat password snooping. You could use both, but that's overkill.

Joseph Tam <jtam.home@gmail.com>