From MozillaZine Knowledge Base

The KB article says: "If you don't make a secure connection anybody who intercepts the network traffic can read everything, including your password. This is why some mail servers that don't support secure connections provide a secure authentication option. It provides a way to login to the mail server without sending your password in clear text, typically by sending a hash code instead of the password."

I don't see why sending a hash code instead of the password would be any safer at all, since "anybody who intercepts the network traffic can read everything" including these hash codes and use them HIMSELF/HERSELF "to login to the mail server without sending your password in clear text". --Chrizoo 19:26, 20 March 2009 (UTC)

Its actually a challenge response exchange. Replay attacks are prevented because the challenge is different every time. The mail server sends a random number or string (the challenge) that the email client uses to generate a hash code (using the password), which it sends as its response. Tanstaafl 01:00, 21 March 2009 (UTC)

thanks for clarifying. I found the article hard to understand without the information you provided here in the talk section. Maybe this should be added to the main article ? --Chrizoo 02:20, 22 March 2009 (UTC)

I updated the article. Tanstaafl 11:01, 26 March 2009 (UTC)

I'm having a problem with the recommendation that if your mail server supports both TLS and SSL you choose SSL since it's just as secure, and it will always either make a secure connection or fail, or I'm understanding it not quite right. Certainly, "TLS if available" suffers from the issue that one doesn't know whether or not the connection is secure, but if you select the unconditional TLS (STARTTLS), it would equally well either continue in an encrypted connection if STARTTLS is present in the EHLO greeting, or abor the connection if not. Thus, unless the STARTTLS protocol has other issues compared with the connection-encrypted SSL setting, it should(?) provide the same level of security. --Rsx11m 22:14, 3 April 2009 (UTC)