Quoting from Nerijus Baliunas's mail on Mon, Nov 25, 2002 at 04:23:19AM +0200:
I don't know for POP3, but for IMAP it may be caused by server
misconfiguration (it happened to me). BTW, imap code used tls1
if there was STARTTLS in capabilities, and it is the last tried
login methon, so why did you remove it? For example, if ctl->sslproto
is ssl2 or ssl3, but other ssl methods failed, will it use
TLS then (i.e. will ctl->sslproto be equal "tls1" then)?
If it won't, maybe it's better to leave imap code as is and
change pop3 code according to imap?
I am not really conversant with the issues involved in STARTTLS.
However, from what I could make from the code and the comments
(previous to the patch), STARTTLS supports only tls1. The other ssl
protocols ssl2, ssl3, and the default ssl23 do not work with STARTTLS.
Could somebody confirm this? Is the situation similar for pop3?
The problem was that it ignored the sslproto option completely and
attempts to use STARTTLS with tls1 just because STARTTLS is in the
capabilities. There is no option for the user to say whether STARTTLS
should be done or not (other than to recompile without ssl).
This is the main source of the problem in this thread as STARTTLS
implementation in the imap server was buggy and leading to socket
error and fetchmail refused to try this without STARTTLS.
All that the patch ensures is that fetchmail will do STARTTLS with
imap (and STLS with pop3) only if you explicitly specify 'sslproto
tls1' in your config file.
Sunil Shetye.