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. It's not clear if fetchmail is treating "TLS" and "STARTTLS" as one in the same, but users wouldn't generally know the underlying details expressed in RFC specs. We do see some ESPs making a distinction (e.g. https://danwin1210.me/mail/) 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