Version: (using KDE KDE 3.1.94) Installed from: Gentoo Packages Compiler: gcc 3.2.3 gcc version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r3, propolice) OS: Linux I configured 2 imap accounts in kmail : - first on a kolab server, only imaps port (993) is accessible (143 blocked by firewall). When I configure this account, I choose the tab security, and click "Check what the server supports", ssl is selected. And when I go back to the general tab port 993 is configured instead of 143, perfect ! - second imap account, both ports 143 and 993 are accessible. I configure the host, and under the security tab choose "check what ..." : TLS is choosed with PLAIN authentication method. Back to the general tab, port 143 is still there as the port to be used. with that setup, kmail can't access my mails in the 2nd account an shows error "Starting TLS failed". I think that if TLS is choosed by the user, port should be automatically changed into 993. Even if both ports are accessible. BTW, when clearing the port field and clicking "OK", port is set to 0, couldn't it be better ?
Sorry, but TLS uses port 143 and not 993. 993 is only used by IMAP over SSL (aka imaps). The standard port for IMAP over TLS is the standard imap port (143) and not the imaps port (993). See below. If your server is misbehaving then you can't blame KMail for that. FYI, I quote from RFC 2595 (Using TLS with IMAP, POP3 and ACAP) <quote> 7. imaps and pop3s ports Separate "imaps" and "pop3s" ports were registered for use with SSL. Use of these ports is discouraged in favor of the STARTTLS or STLS commands. A number of problems have been observed with separate ports for "secure" variants of protocols. This is an attempt to enumerate some of those problems. - Separate ports lead to a separate URL scheme which intrudes into the user interface in inappropriate ways. For example, many web pages use language like "click here if your browser supports SSL." This is a decision the browser is often more capable of making than the user. - Separate ports imply a model of either "secure" or "not secure." This can be misleading in a number of ways. First, the "secure" port may not in fact be acceptably secure as an export-crippled cipher suite might be in use. This can mislead users into a false sense of security. Second, the normal port might in fact be secured by using a SASL mechanism which includes a security layer. Thus the separate port distinction makes the complex topic of security policy even more confusing. One common result of this confusion is that firewall administrators are often misled into permitting the "secure" port and blocking the standard port. This could be a poor choice given the common use of SSL with a 40-bit key encryption layer and plain-text password authentication is less secure than strong SASL mechanisms such as GSSAPI with Kerberos 5. - Use of separate ports for SSL has caused clients to implement only two security policies: use SSL or don't use SSL. The desirable security policy "use TLS when available" would be cumbersome with the separate port model, but is simple with STARTTLS. - Port numbers are a limited resource. While they are not yet in short supply, it is unwise to set a precedent that could double (or worse) the speed of their consumption. </quote>
*** Bug 70464 has been marked as a duplicate of this bug. ***