[Users] Claws Mail Can't Connect to Internet With Specific Internet Connection

[Dustin Miller]

On Tue, 11 Oct 2022 19:38:18 +0600
Dustin Miller <dustbiz at gmail.com> wrote:

> Claws Mail (CM) 4.1.0 on Linux Mint 20.1
> 
> My system has access to two different internet connections:
> 
'LAN': Via LAN cable to a local network that has internet access.

'USB: Via a USB dongle wireless device using a SIM card to connect with
a mobile network.

CM could not access the internet via LAN for sending / receiving email,
even though other apps and the system could access it.

When I disabled LAN and connected USB, then CM and everything else could
access the internet as expected.

I used the tools telnet, openssl, traceroute, dig, and nmap on each of
the connections to note any differences in results. From what I could
tell, the traceroute, dig, and nmap results didn't show any relevant
differences and didn't include any warnings or errors. However, both
telnet and openssl (maybe it uses telnet?) seemed to give successful
results on USB but not on LAN.

The only difference I noticed is that on USB these two tools defaulted
to using IPv4 for address resolution, but on LAN they defaulted to using
IPv6, and then just stalled at trying to access the host. If I forced
them to use IPv4 on LAN, then I got the same results as with USB. Based
on the above, as well as the fact that this CM instance was built with
IPv6 enabled, my hypothesis was that the issue with CM was the same as
with these two tools.

I noted that CM can be configured to build with IPv6 disabled, but I
wanted to find an easier, less 'permanent' approach to 'forcing' IPv4
for testing purposes. What I settled on was editing the '/etc/gai.conf'
file so that there would be a (presumably) system-wide preference for
using IPv4 rather than IPv6. This solved the problems with the telnet
and openssl testing commands. It also has solved the CM problem,
although I needed to restart CM for it to take effect.

With my limited understanding of these things, my sense is that
preferring IPv4 to IPv6 is not the ideal long-term solution since IPv6
is 'the future', but that using a preference setting like this is
better than disabling IPv6 altogether. I am also not sure of the cause
of this issue -- perhaps caused by an update to my system, or a change
in settings on the local network device(s) or the ISP's equipment? At
this point, I'm also not sure if/when this solution / workaround
may/will cause an issue with one or more other apps.

I would guess that this is not a 'proper' CM bug, although if someone
thinks it smells like one, I'm happy to do some specific testing. I am
wondering though whether it might not warrant me filing an enhancement
request on the bug tracker. The basic idea I have in mind is that when
CM is trying to use IPv6 and it is not successful for whatever reason,
then instead of just stalling and timing out, it would switch to trying
to use IPv4 before then going on to time out if that isn't successful
either. I'm not sure how difficult that would be to implement or if
there's another better way to approach the issue, but if any developers
think this sounds like a reasonable enhancement request, I'm happy to go
ahead and file it.

I also welcome any input from anyone who thinks I may be missing
something in regards to this issue, or has any other relevant comments
or questions to add.

And again, thanks to each of you who took the time to help me learn
more about troubleshooting network / routing issues.

Cheers,
Dustin