So I have created an entry in my /etc/hosts file pointing a public DNS address to a local computer hosting the IMAP server. This is so that I can avoid going out to the internet and back home to connect DC desktop to my local server and use a direct LAN connection instead.
However, I don’t seem to be able to configure CD desktop to do that.
I thought it was due to leaving the host fields empty in the advanced account configuration, but even if I set them to the internal IP address of my IMAP server, DC doesn’t seem to connect through the LAN.
Mmm, maybe I didn’t explain myself… The name resolution is working at the OS level.
So, let’s say my public DNS address is myhost.mydomain.com, if I run this in my PC it resolves to the internal IP (see the 192.168. prefix) of my server:
ivan@baco:~ $ ping myhost.mydomain.com
PING zeus (192.168.1.100) 56(84) bytes of data.
64 bytes from zeus (192.168.1.100): icmp_seq=1 ttl=64 time=1.48 ms
64 bytes from zeus (192.168.1.100): icmp_seq=2 ttl=64 time=1.50 ms
^C
--- zeus ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 1.482/1.491/1.501/0.009 ms
However, DC desktop process is not connected through that address but through the public one that the real DNS (the one from Internet) is returning. See how there are no connections to 192.168.1.100 established from my PC:
ivan@baco:~ $ netstat -a | grep ESTABLISHED | grep imap
tcp 0 0 baco:41216 165.37.35.169:imaps ESTABLISHED
tcp 0 0 baco:33940 165.37.35.169:imaps ESTABLISHED
tcp 0 0 baco:33950 165.37.35.169:imaps ESTABLISHED
tcp 0 0 baco:48346 115.189.37.108:imaps ESTABLISHED
tcp 0 0 baco:47592 165.37.35.168:imaps ESTABLISHED
tcp 0 0 baco:47580 165.37.35.168:imaps ESTABLISHED
tcp 0 0 baco:36252 imap.xxxx.com:imaps ESTABLISHED
So my guess is that DC is using its own name resolution internally, instead of asking the OS. Maybe because Electron (it uses Electron, right?) does DNS resolutions on its own?
But still, if I put the real IP in the account’s advanced configuration dialog, shouldn’t DC desktop use it directly?
By the way, nmap run from my PC shows that my server (192.168.1.100) is listening to IMAP correctly.
But again, this is “irrelevant” to the question since the problem is not that DC is not connected but that it connects going out to the Internet, then back to my home, instead of through the LAN directly, as I would like.
And my bet is that DC desktop is doing name resolution without using /etc/hosts.
use sqlite browser to open the accounts db and look if your provider domain’s ip address is still cached.
Or setup a new dc account and see if it works there.
Electron’s internet is just used for the experimental map, all other things are disabled as good as we could. All other networking goes through deltachat core, also to ensure the socks5 proxy is used when the user set that.
Delta Chat core is using tokio::net::lookup_host method to resolve IMAP, SMTP and HTTP server addresses. I expect that it takes /etc/hosts into account, but have not checked it myself.
The only exception is looking up MX records which happens to detect Google Workspace domains during initial configuration. This code uses its own resolver, but this has nothing to do with connecting to IMAP servers and should not affect you.
When Delta Chat gets resolution results from system resolver, it prints logs like src/net.rs:71: Resolved testrun.org:993 into 5.1.76.52:993., appends cached addresses to the end of the list and tries to connect to resolved addresses one by one. Addresses from resolver always have higher priority than cache.
Could you check the logs in ~/.config/DeltaChat/logs/ and see if the address you added to /etc/hosts appears anywhere in the logs?
Delta Chat should use IP address if you put it directly instead of server name and rerun configuration, but it is a bad idea because then TLS certificate cannot be checked and you will run with disabled TLS domain checks. TLS certificate is issued for a domain name and not IP address, so you should use domain names everywhere if you want TLS security.
I have just tested on my Linux host, adding 127.0.0.1 testrun.org to /etc/hosts results in these errors in the log:
14.8s [i]core/event: 1 src/net.rs:71: Resolved testrun.org:587 into [::1]:587.
14.8s [i]core/event: 1 src/net.rs:71: Resolved testrun.org:587 into 127.0.0.1:587.
14.9s [w]core/event: 1 src/net.rs:186: Failed to connect to [::1]:587: connection failure: Connection refused (os error 111).
14.9s [w]core/event: 1 src/net.rs:186: Failed to connect to 127.0.0.1:587: connection failure: Connection refused (os error 111).
Then Delta Chat connected to the cached address. So /etc/hosts is taken into account as it should. I guess Delta Chat fails to connect to the address you provided it /etc/hosts for some reason and falls back to using cached address. Check the logs for connection failures.
So, I looked at the logs and found out strange things which may be OK, but I’m enumerating them just in case:
Apparently the configuration has the correct IP (192.168.1.100) but it is storing ports 144 and 588 next to the server name. Not sure what these ports are used for…
DC is resolving posteo.de and connecting to it (confirmed with netstat) even though I don’t have any posteo account configured. In fact I grepped the .config/DeltaChat folder for posteo and nothing was found apart from the logs.
Finally the address of the mail server is correctly resolved according to /etc/hosts, but it fails to connect. I’ve found that my server is not listening to imaps in the local interface, only to imap so I think that is the reason why it falls back to the external address.
So now I’m going to make the server listen to imaps and see if that fixes my issue and will report my findings.
However, even if that fixes the issue, it doesn’t explain the other issues…
Issue 1 (port 144 and 588) remains a mistery for me. Where could that ports come from?
Issue 2 is probably explained because DC configuration does not correspond to what DC desktop is showing in the UI. Meaning that DC desktop only shows one account when in .config/DeltaChat there are three accounts. I’m guessing this is because I configured more accounts in the past and they have been left there and DC core uses them even if DC desktop doesn’t care about them.
Issue 2 should probably be corrected or at least DC desktop should show the extra accounts somewhere so that we (users) get a hint about this.
Thx a lot for your help
As I said, I’ll check the imaps thingie and come back with my findings.
As to the imaps issue my configuration is OK, my server is never listening to imaps just imap and I’m relying on SSL that is set as required in my IMAP server (dovecot). So that can’t be the reason why DC desktop is connecting through the outer address.
Normally port 143 is an IMAP and 587 is SMTP submission port. 144 and 588 look like these port numbers incremnted by 1. No idea which server you use, but maybe these ports are used by a backend that is behind a reverse proxy exposing them as 143 and 587? Delta Chat never tries ports 144 and 588 automatically unless they are advertised in autoconfig XML file served over HTTPS, could be this is what your server does.
Aren’t these accounts visible in “Switch account” dialog in the sidebar menu on the left?
I have an autoconfig xml I placed for the public address so that I don’t use the standard ports (to prevent bots from connecting to my imap and SMTP servers).
But when I connect through the internal API I’m using the standard ports (it’s my router who redirects from 144 to 143 and 588 to 587), thus it fails.
Since I left the ports field empty in DC desktop it is using those ports.
Now that you say it… They are, but I didn’t see the “Switch account” link even though I looked for it several times before posting this… Sorry about that
even though I don’t have any posteo account configured. In fact I grepped the 
They are, but I didn’t see the “Switch account” link even though I looked for it several times before posting this… Sorry about that 