fetchmail-friends
[Top] [All Lists]

Re[2]: [fetchmail] Fetchmail 6.1.1 can't login to a server that 5.9.14 can handle?

2002-11-25 04:59:23
On Mon, 25 Nov 2002 11:39:57 +0530 Sunil Shetye 
<shetye(_at_)bombay(_dot_)retortsoft(_dot_)com> wrote:

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?

As I understand it, STARTTLS _is_ tls1.

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).

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.

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.

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.

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.

A better patch IMHO would be to try "auth password" authentication if
STARTTLS/STLS fails (when there is no "sslproto tls1" in config file).

Regards,
Nerijus


<Prev in Thread] Current Thread [Next in Thread>