onion sites inaccessible due to internal DNS lookup

[Bill Yikes]

Fetchmail works over Tor but only if the server is a clearnet host. So for example a Yahoo config might look like this:
```
poll imap.mail.yahoo.com
        plugin "socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050"
        protocol imap
        port 993
        interval 3
        username "billyikes"
        ssl
        sslcertck
        sslfingerprint "6F:C8:F1:EB:A0:55:3D:35:5B:2E:31:7F:6B:F8:A3:B4"
        fetchall
```
If the server is an onion server, it's a disaster because fetchmail attempts to resolve the hostname internally and it can't handle *.onion hosts. The following gives an error like "cannot resolve":
```
poll underwood2hj3pwd.onion
        plugin "socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050"
        protocol imap
        port 993
        username "billyikes"
        fetchall
```
The documentation does not state that hostnames must be clearnet hostnames. So at the very minimum that limitation should be documented. But really, Tor should be supported officially and ideally without the "plugin" hack. This is the workaround:
```
skip underwood-onion via 127.0.0.1
        protocol imap
        port 12345
        username "billyikes"
        fetchall
```
run:

socat TCP4-LISTEN:12345,reuseaddr,fork SOCKS4A:127.0.0.1:underwood2hj3pwd.onion:110,socksport=9050 &

then run "fetchmail underwood-onion". It's a nasty hack.. makes daemon mode problematic because a socat tunnel can't just be left up indefinitely. We should be able to write something like:
```
poll underwood2hj3pwd.onion
        socks4a 127.0.0.1:9050"
        protocol imap
        port 993
        username "billyikes"
        fetchall
```

[Matthias Andree (matthias-andree)]

Bill, fetchmail relies on the system resolver so if that cannot resolve .onion hosts, that's bound to fail. You are not telling fetchmail to avoid name resolution.

Please provide information how exactly and which fetchmail version fails in your << poll underwood2hj3pwd.onion plugin "socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050" >> scenario (logging and/or transcript from the console), see https://www.fetchmail.info/fetchmail-FAQ.html#G3

We may then decide if it's a Ubuntu or upstream issue to be filed to the Debian or Gitlab project issues.

[Bill Yikes (yik3s)]

///scenario 1: using torsocks///

With this configuration:
```
poll uw via underwood2hj3pwd.onion
        protocol imap
        port 993
        username "billyikes"
        fetchall
```
the terminal output is:
```
$ torsocks fetchmail uw
1618601733 ERROR torsocks[16571]: Unable to resolve. Status reply: 4 (in socks5_recv_resolve_reply() at socks5.c:683)
gethostbyname failed for myhost
Non-recoverable failure in name resolutionCannot find my own host in hosts database to qualify it!
Trying to continue with unqualified hostname.
DO NOT report broken Received: headers, HELO/EHLO lines or similar problems!
DO repair your /etc/hosts, DNS, NIS or LDAP instead.
fetchmail: can't poll specified hosts with another fetchmail running at 15369.
```
and the log output is:
```
1618602068 ERROR torsocks[17358]: Connection refused to Tor SOCKS (in socks5_recv_connect_reply() at socks5.c:549)
fetchmail: Connection errors for this poll:
name 0: connection to underwood2hj3pwd.onion:993 [127.42.42.0/993] failed: Connection refused.
fetchmail: IMAP connection to uw failed: Connection refused
```

///scenario 2: using plugin for socat///

With this configuration:
```
poll uw via underwood2hj3pwd.onion
        plugin "socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050"
        protocol imap
        port 993
        username "billyikes"
        fetchall
```
the terminal had no output:
```
$ fetchmail uw
```
and the log output is:
```
fetchmail: starting fetchmail 6.3.26 daemon
fetchmail: couldn't find canonical DNS name of uw (underwood2hj3pwd.onion): Name or service not known
fetchmail: Query status=11 (DNS)
```

/// Version info ///

Abridged output of "env LC_ALL=C fetchmail -V":
```
This is fetchmail release 6.3.26+GSS+NTLM+SDPS+SSL-SSLv3+NLS+KRB5.

Copyright (C) 2002, 2003 Eric S. Raymond
Copyright (C) 2004 Matthias Andree, Eric S. Raymond,
                   Robert M. Funk, Graham Wilson
Copyright (C) 2005 - 2012 Sunil Shetye
Copyright (C) 2005 - 2015 Matthias Andree
Fetchmail comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. For details,
please see the file COPYING in the source or documentation directory.
This product includes software developed by the OpenSSL Project
for use in the OpenSSL Toolkit. (http://www.openssl.org/)

Fallback MDA: (none)
Linux cypher 4.9.0-15-amd64 #1 SMP Debian 4.9.258-1 (2021-03-08) x86_64 GNU/Linux
Taking options from command line and /home/user/.fetchmailrc
Poll interval is 1800 seconds
Logfile is /home/user/logs/fetchmail.log
Idfile is /home/user/.fetchids
Fetchmail will forward misaddressed multidrop messages to user.
Options for retrieving from billyikes@uw:
  Mail will be retrieved via underwood2hj3pwd.onion
  True name of server is underwood2hj3pwd.onion.
  Protocol is IMAP (using service 993).
  All available authentication methods will be tried.
  SSL trusted certificate directory: /etc/ssl/certs
  Server nonresponse timeout is 300 seconds (default).
  Default mailbox selected.
  All messages will be retrieved (--all on).
  Fetched messages will not be kept on the server (--keep off).
  Old messages will not be flushed before message retrie...

[Bill Yikes (yik3s)]

///scenario 3: using mapaddress (requires root or tor controller access)///

With this configuration:
```
poll uw via 10.40.40.46
        protocol imap
        port 993
        username "billyikes"
        fetchall
```
/etc/tor/torrc:
```
mapaddress 10.40.40.46 underwood2hj3pwd.onion
```

the terminal output is nothing:
```
$ fetchmail -v uw
```
and the log output is:
```
fetchmail: starting fetchmail 6.3.26 daemon
fetchmail: 6.3.26 querying uw (protocol IMAP) at Fri 16 Apr 2021 04:20:37 PM EDT: poll started
fetchmail: Trying to connect to 10.40.40.46/993...connection failed.
fetchmail: connection to 10.40.40.46:993 [10.40.40.46/993] failed: Connection timed out.
fetchmail: Connection errors for this poll:
name 0: connection to 10.40.40.46:993 [10.40.40.46/993] failed: Connection timed out.
fetchmail: IMAP connection to uw failed: Connection timed out
fetchmail: 6.3.26 querying uw (protocol IMAP) at Fri 16 Apr 2021 04:22:48 PM EDT: poll completed
fetchmail: Query status=2 (SOCKET)
```

[Robie Basak (racb)]

Thank you for your report.

This does not seem likely to be a bug in Ubuntu's packaging of fetchmail to me, so since there is unlikely to be any action to take in Ubuntu itself on this, I'm marking the bug task representing the fetchmail package in Ubuntu as Won't Fix to make this clear. Rather, it seems to me that you're hitting a limitation of fetchmail in that the usual techniques to redirect a non-Tor-aware app into Tor do not work with it. It seems like a reasonable request to me for fetchmail to support this. But as it seems likely to me that this isn't related to how fetchmail is packaged in Ubuntu, and upstream fetchmail built from source would have the same issue, you're probably best checking that and, if confirmed, contacting fetchmail upstream about this.

If this is resolved upstream, then Ubuntu will adopt the change in time and we can update the status accordingly.

Alternatively if you think my interpretation is wrong, please feel free to explain and reopen.

[Bill Yikes (yik3s)]

"Wontfix" is probably the most fitting status of the possibilities that are given.

I would have reported upstream if it didn't require using gitlab.com (which pushes CAPTCHAs). Upstream forges often appear in unusable or controversial places like github or gitlab.com, which actually discourages bug reporting (https://infosec.exchange/@bojkotiMalbona/104637098084869887).

We need another status: "reportUpstream". Bugs could sit in a "reportUpstream" state until someone with access to the upstream bug tracker mirrors the report, at which point it could transition to wontfix or invalid.