Today the problem raised its head again, with a twist. A LAN client lost the DNS setting that pointed directly to the LAN address of the IMAP server, and two things happened: the LAN client could not connect to IMAP as we know, and a telephone call from the external client reported the same. When the LAN client closed Thunderbird, then the external client regained access. There were no other clients online at the same time. It turns out that the single LAN client was making enough requests to saturate dovecot's authentication service. I already described the detail with wireshark.
On Tue, May 2, 2017 at 3:46 PM, Rupert Gallagher <[email protected]> wrote: Hello, Thunderbird has been bugging us with connection errors. Dovecot is installed on a local server that carries a local IP and a public IP. When Thunderbird on a local client connects successfully, Wireshark shows a SYN request from the client's IP on LAN to the public IP of the server, followed by the ACK from the same public IP. When Thunderbird on the same local client fails to connect, Wireshark shows a SYN request from the client's IP on LAN to the public IP of the server, followed by the ACK from the server's LAN address, the client does not accept the ACK as valid and sends a new SYN request. The loop eventually leads to time-out. At the client's console, the DNS query of the IMAP server always responds with the server's public IP address. It is evident from Wireshark that the dovecot server sends ACKs from two IPs. Is it possible to instruct Dovecot to use the public IP only?
