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.h...@gmail.com>
