Sunil Shetye <shetye(_at_)bombay(_dot_)retortsoft(_dot_)com>:
Good implementation, bad strategy. If the user requested end-to-end
security, the correct behavior is *not* to fall back to sending a
password in clear; this might leak privileged information.
I do not think that security was requested by the user here (unless
you want to call compiling with SSL and not specifying an auth method
as that). Currently, there is no option to enable or disable TLS
OK, good point. TLS is a best-effort service.
What happened was that fetchmail probed for capabilities and found
that TLS was available. It tried to use TLS, but failed because TLS
was not really implemented leading to a socket error.
Fetchmail does great work in using capabilities which are available.
IMO, if a capability which has been probed for does not actually work,
disabling the capability without any messages is the best option in
the current scenario. In this case, changing the auth method was the
only option to disable the capability.
Agreed. This has been my strategy in similar past situations.
A real long term solution would be to have a capability structure with
four-state flags which have the values which say:
probe the first time for this capability, reset this flag accordingly
probe for this capability, use it if available
use this capability (without probing)
do not probe or use this capability
A lot of flags can come under this:
/* pop3 */ CAPA STLS
/* imap */ CAPABILITIES IDLE LOGINDISABLED STARTTLS
/* smtp */ EHLO
(Implemetation detail: not all values are meaningful with all flags.)
Then, the strategy for messages will be simpler: emit a message iff
the user has told to use this capability unconditionally.
I think this would be overengineering. But I'd look at a patch that
implemented it seriously.
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>