I and several of my clients are using Gmail to access email accounts on our IW 7 server (which is using Dovecot and Qmail). Over the past few months, we have been getting sporadic error messages when Gmail attempts to log in via POP3 via port 995 like this:
Connection Error. Mail from this account has not been retrieved since… xx:xx View Details
The “details” say:
Connection Error. Server returned error “Connection timed out: There may be a problem with the settings you added. Ple…”
I know the settings for these accounts in Gmail are correct because it’s possible to send and receive email with the accounts.
Since this is a relatively recent problem, I thought it might be because more and more clients are using Gmail to access their IW email accounts, and Gmail might be using the same IP(s) via POP3 to connect to multiple accounts, bumping into the default Dovecot “Max pop3 connections by user ip” setting of 10. I increased the setting to 25 and restarted Dovecot, but it didn’t improve things. I also checked through the dovecot.log at the times when a Gmail connection failed, and there were no entries about failed connections at the times indicated by the errors in Gmail, so I’m not even sure the login attempts are reaching Dovecot.
Clients who are using other email clients, like Thunderbird, aren’t reporting any connection issues.
The server is cruising along with low CPU and memory usage, so it doesn’t seem likely it’s due to resource issues.
I found this post on Serverfault which seems to be similar to my issue, but our server has no IPv6 DNS records and has no IPv6.pools. I found a post in the Google Support groups regarding Gmail connection timeouts with POP3 accounts, and it also mentioned IPv6.
Do you mean gmail is used as primary email for client and gmail connects to your IW email to collect
Have you set IPv6 as disabled in NIC config (sorry if I appear to be trying to teach you to suck eggs - just double checking)
We had issues with IPv6 until we fully set IPv6 to disabled in NIC config and restarted server (could just restart network though) as until disabled, it would attempt to use IPv6 first
Does gmail have same issues if you use IMAP as a test
I think you are correct and gmail is not getting through to your server - have you checked firewall - I think you use CSF as we do, and if so, check the settings for DDoS attacks etc… it could be at this level where there are been dropped
What I’m trying to say, but not doing a very good job of it, is that in Gmail’s web UI, the IW accounts are added as additional POP3 accounts in Settings > See All Settings > Accounts and Import > “Check mail from other accounts.” It is not possible to set them up as IMAP, apparently. Gmail only gives the option of using POP3.
You definitely are not teaching me to suck eggs. I am clueless, so I’m open to any information you can pass on.
I’m on a CentOS 7 server, and if I run:
ifconfig eth0
I do see an inet6 address, so I guess that means IPv6 is still enabled.
I am using CSF. LF_DISTATTACK and LT_POP3D are disabled and RESTRICT_SYSLOG is set to 3.
I am running Imunify360, but its DDoS capability is disabled because I’m running CSF, and I didn’t see any POP3-connection-related settings in it.
I’m going to reach out to my hosting provider and see what they say about disabling IPv6. I don’t know why they left it enabled when they provisioned a server which to my knowledge doesn’t use it, but I don’t want to break anything. I will let you know what I find out.
I got in touch with my web host, and the tech (Steven L.) found the problem. I can’t believe I didn’t think of it.
He found six different IPs belonging to google.com blocked in CSF.
Now that I know, it’s easy to understand what might have happened. Sometime, one or more of our users incorrectly configured POP3 access in Gmail–which is easy to do because Gmail defaults to the wrong host name for our server–and LFD ended up adding the IP address Gmail was using at the time to the deny list. Whenever Gmail tried to use that IP address in the future for the same or another account, it was blocked and the connection timed out. When it used a different IP, it was able to connect, thus the intermittent nature of the failed connections that were making me crazy.
I found a list of the IPs that Google uses, and added the range the blocked and the successfully connected IPs were in to csf.ignore, so I think the problem is solved, at least until Google starts using a different IP range.