I appreciate the quick response, but I have to say both of you
overlooked some of the data I presented, so I will elaborate. I was
able to workaround the bug, but there are still bugs here. Having read
the man page more times, I continue to find more anomalies than answers,
which I will elaborate here.
To be clear, fetchmail changed, not my config. This config works on
fetchmail 6.3.26 but fails on 6.4.16:
```
skip underwood-onion via 127.0.0.1
protocol imap
port 12345
username "billyikes"
fetchall
```
Nothing in your response suggests that I should expect this config to be
treated differently from the two different versions of fetchmail. But it is.
Verbose output shows that version 6.4.16 sends a "STARTTLS" even though the
config does not call for SSL/TLS in any way. That's a bug. The man page says
"sslproto auto" is a default which superficially seems reasonable until you
notice that "auto" actually imposes TLS. This is a distortion of what users
expect by the meaning of "automatic".
My first attempt at a fix for underwood was to add these lines (which fixed
some of my stanzas for other servers):
~~~
sslproto 'SSL3+'
no sslcertck
~~~
Intution suggests this means: "If the server demands SSL, then be permissive
and allow SSL3 or newer, but don't bother checking whether the cert is good or
not, just use it if the server insists". But what we find is that the behavior
is not intuitive w.r.t the options. And because it fails the rule of least
astonishment, I'm calling it a bug. Moreover, the new manpage states:
"This option has a dual use, out of historic fetchmail behaviour. It
controls both the SSL/TLS protocol version and, if --ssl is not
specified, the STARTTLS behaviour (upgrading the protocol to an SSL or
TLS connection in-band). Some other options may however make TLS
mandatory."
To say sslproto "controls STARTTLS behaviour" without fully specifying
how that behavior is controlled is a recipe for confusion. An empty
argument is said to disable STARTTLS, but that was always the case. So
there are two problems here. The first problem is that STARTTLS is
technical under-the-hood jargon that end users probably should not be
responsible for understanding. Users are basically told whether SSL/TLS
is used, not what low-level commands are being passed to make that
happen. The second problem is that auto states "require TLS", but does
not mention the low-level "STARTTLS" that the section mentioned earlier.
To developers, perhaps it is clear that "TLS" and "STARTTLS" are one in
the same, but it's not clear to users who don't know the underlying
details expressed in RFC specs. IOW, STARTTLS is mentioned just enough
to confuse, and not enough to be understandable.
Apart from the misleading & non-intuitive wording, some things are
plainly false. E.g. this statement from the man page is simply not
true:
"Only if this option [sslproto] and --ssl are both missing for a poll,
there will be opportunistic TLS for POP3 and IMAP, where fetchmail
will attempt to upgrade to TLSv1 or newer."
If that were a true statement, then the first stanza at the top of this
post would work. This is a contradiction in the man page. That is,
"sslproto auto" ironically states that TLS is mandated while
simultaneously saying "auto" is also a default, and yet this behavior is
not opportunistic. Opportunistic means: accommodate (or even
proactively request) higher levels of security, but ultimately settle
for no security at all if availability demands it.
The "sslproto ''" empty string option is bizarre because it strictly
disables STARTTLS without stating whether SSL is also disabled, apart
from saying that it's incompatible with --ssl. To expressly /force/ no
encryption can be useful but only in limited & obscure test situations.
It's still good that it exists, but what about the much more common case
of users who need opportunistic connections? The empty string denies
the opportunity for crypto while all the other sslproto options deny the
possibility of no encryption.
Even more strange is "SSL23". How often does someone want to insist on
SSL2 or SSL3, but not the higher options? There should be a "sslproto
SSL2+".
And most importantly there should be a "sslproto none+" to truly deliver
opportunistic sessions.
Regarding this suggestion:
```
poll underwood2hj3pwd.onion via 127.0.0.1
plugin "socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050"
```
which I expanded to:
```
skip underwood2hj3pwd.onion via 127.0.0.1
plugin "socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050"
protocol imap
port 143
username "billyikes"
fetchall
```
result was:
```
fetchmail: running socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050 (host
127.0.0.1 service 143)
2021/07/01 16:25:44 socat[2202] E socks: connect request rejected or failed
fetchmail: socket error while fetching from billyikes@underwood2hj3pwd.onion
fetchmail: 6.4.16 querying underwood2hj3pwd.onion (protocol IMAP) at Thu 01 Jul
2021 04:25:44 PM UTC: poll completed
fetchmail: Query status=2 (SOCKET)
```
In the end, there are three configs that work.
(config 1)
```
skip underwood-onion via 127.0.0.1
protocol imap
port 12345
username "billyikes"
sslproto ''
no sslcertck
fetchall
```
(config 2)
```
skip underwood-onion via 127.0.0.1
protocol imap
port 12345
username "billyikes"
no sslcertck
fetchall
```
(config 3)
```
skip underwood-onion via 127.0.0.1
protocol imap
port 12345
username "billyikes"
sslproto ''
fetchall
```
It's nice that at least there is a possibility to still function.
Notice that on config 2, even though there is no explicit request for
SSL, it's necessary to demand that the ssl cert is not checked. It's a
bit off that we should have to ask not to check certs despite SSL not
being explicitly requested. More importantly, Config 2 is not working
as documented, because "auto" is the default and auto *requires* TLS.
So it's a bug that config 2 works to fetch msgs from a non-TLS server.
Config 3 is the most sensible and it is not a bug, strictly speaking.
However, what if underwood were to one day begin is permit TLS? I might
like to opportunistically benefit from that, but my config forcibly
denies crypto. This means I would have to periodically try "SSL23" and
"SSL3+", because opportunistic SSL/TLS is no longer supported. And if
underwood starts requiring crypto, then later reverts back to no crypto,
I have the maintenence burden of having to edit .fetchmailrc every time.
When in fact I'm happy to rely on the builtin crypto of onion circuits -
I just need fetchmail to work at the best protocol the server supports.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1934155
Title:
fetchmail can no longer connect to underwood & gives false error msg
(TLS issues)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1934155/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
