Quoting from Nerijus Baliunas's mail on Mon, Nov 25, 2002 at 01:59:11PM +0200:
As I understand it, STARTTLS _is_ tls1.
Ok.
No, it did not ignore sslproto - STARTTLS is used only after trying
other ssl protocols if specified. And there is an option to not use
STARTTLS - auth password.
I think there is some confusion here.
I think, STARTTLS is only used when connecting to the imap port. There
is no question of using other ssl protocols here. When connecting to
the simap port, STARTTLS is not used at all. There are two disjoint
cases.
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.
auth password helps.
I am not sure this should be the case. STARTTLS is something that is
done in addition to authentication. Linking it to the auth method
reduces the flexibility.
For example, if the CAPABILITY includes STARTTLS and AUTH=CRAM-MD5, it
is not possible to use STARTTLS with 'auth password'. If you specify
'auth password', STARTTLS will not be done. If you do not specify
'auth password', autoprobing will use STARTTLS with 'auth cram-md5'.
That's bad. STARTTLS is good because it does not need any configuration
on a client side, and it would be nice if it was used when STARTTLS/STLS
is in capabilities - communications would be more secure by default.
IMO, it is better to specify sslproto explicitly. Otherwise, this is
equivalent (conceptually) to trying to connect to simap port first
when protocol is imap just to have more security by default. If the
option 'ssl' is explicitly required to connect to simap port, then the
option 'sslproto tls1' too should be explicitly required to use
STARTTLS.
Sunil Shetye.