Facebook
Twitter
-
If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
CentOS2Alma discussion
Imap connection issues
- Thread starter ErwanG
- Start date
Does it have to have its own dedicated IP for this to work? MediaTemple said they can install an SSL on the email of our primary domain on the server and we can route all mail through that connection and we don't have to had a dedicated IP to do that. because having a dedicated IP for each domain 130 domains x $10 a month would be very expensive and they are being very stingy with IPV4 addresses with the limit they have for them I don't think they would give us that many.
There's no need for a dedicated IP and SSL for each domain.
The idea is that you have only one domain (e.g. yourhostingcompany.tld) with a dedicated IP and SSL certificate (which is then configured to be used for email as well as web).
Then (and this is the crucial bit), you tell your clients to use yourhostingcompay.tld as the IMAP server address and also the SMTP server address instead of theirhosteddomain.tld/mail.theirhosteddomain.tld or whatever they would normally use.
You need to emphasise that they only use it for the IMAP (or pop3 I suppose) server address and SMTP server address. They still need to use [email protected] as their email address and username.
Somewhere at the back of my mind a little bell is ringing to say that some email clients might complain about an address mismatch ... but I can't put my finger on it.
As was mentioned previously, an SSL certificate from any provider, including the cheap ones you can get from the likes of www.c1-domains.com (disclosure: this is our reseller account), godaddy.com, comodo and all the others should work fine. As long as it works for a website without giving errors, it will work for email.
One thing to keep in mind if you are not familiar with SSL certificates: They are very specific. For example, if you purchase a certificate for www.yourhostingcompany.tld then if you visit yourhostingcompany.tld (without the www) you'll get an SSL certificate error as the certificate is for the www. domain. The same goes for email - if the certificate is for www.domain.tld and the customer enters domain.tld (without the www) as the IMAP/POP3/SMTP server address and selects the SSL option, there will be a certificate error.
So if you want a certificate that works for www., no www., mail. and anything. then you either buy what's known as a wildcard certificate, which is somewhat more expensive than a normal certificate and which matches *.domain.tld. Or you need to purchase individual certificates - e.g. one for www. for Plesk and your hosting company domain, and one without the www for email.
Of course you could use only one (either with www or without www) but I don't like that option. It is only my opinion, but I feel that ideally you don't want to tell customers to enter "www.yourhostingcompany.tld" as the IMAP server address, as the "www" might cause them confusion, and similarly you don't want to tell customers to login to plesk via https://domain.tld:8443 because some people automatically add a www no matter what you tell them. We use wildcard certificates to get around the problem because it works out cheaper for us in our particular situation, but this may not be the case for you.
Whew! I hope I've not caused more confusion than good with this post. And I really hope someone will chime in (pun intended) regarding the mental warning bell I mentioned regarding domain mismatches when using a different server address domain to the email address domain. I don't have an apple device so I can't test/check this right now. The bottom line is please wait for someone to check or confirm what I'm suggesting will work, without problems, before anybody goes out and purchases an SSL certificate! !!!
This is vitally important because (as far as I'm aware) you are unlikely to get a refund from any provider for an SSL certificate on the basis of "it doesn't work".
The idea is that you have only one domain (e.g. yourhostingcompany.tld) with a dedicated IP and SSL certificate (which is then configured to be used for email as well as web).
Then (and this is the crucial bit), you tell your clients to use yourhostingcompay.tld as the IMAP server address and also the SMTP server address instead of theirhosteddomain.tld/mail.theirhosteddomain.tld or whatever they would normally use.
You need to emphasise that they only use it for the IMAP (or pop3 I suppose) server address and SMTP server address. They still need to use [email protected] as their email address and username.
Somewhere at the back of my mind a little bell is ringing to say that some email clients might complain about an address mismatch ... but I can't put my finger on it.
As was mentioned previously, an SSL certificate from any provider, including the cheap ones you can get from the likes of www.c1-domains.com (disclosure: this is our reseller account), godaddy.com, comodo and all the others should work fine. As long as it works for a website without giving errors, it will work for email.
One thing to keep in mind if you are not familiar with SSL certificates: They are very specific. For example, if you purchase a certificate for www.yourhostingcompany.tld then if you visit yourhostingcompany.tld (without the www) you'll get an SSL certificate error as the certificate is for the www. domain. The same goes for email - if the certificate is for www.domain.tld and the customer enters domain.tld (without the www) as the IMAP/POP3/SMTP server address and selects the SSL option, there will be a certificate error.
So if you want a certificate that works for www., no www., mail. and anything. then you either buy what's known as a wildcard certificate, which is somewhat more expensive than a normal certificate and which matches *.domain.tld. Or you need to purchase individual certificates - e.g. one for www. for Plesk and your hosting company domain, and one without the www for email.
Of course you could use only one (either with www or without www) but I don't like that option. It is only my opinion, but I feel that ideally you don't want to tell customers to enter "www.yourhostingcompany.tld" as the IMAP server address, as the "www" might cause them confusion, and similarly you don't want to tell customers to login to plesk via https://domain.tld:8443 because some people automatically add a www no matter what you tell them. We use wildcard certificates to get around the problem because it works out cheaper for us in our particular situation, but this may not be the case for you.
Whew! I hope I've not caused more confusion than good with this post. And I really hope someone will chime in (pun intended) regarding the mental warning bell I mentioned regarding domain mismatches when using a different server address domain to the email address domain. I don't have an apple device so I can't test/check this right now. The bottom line is please wait for someone to check or confirm what I'm suggesting will work, without problems, before anybody goes out and purchases an SSL certificate! !!!
This is vitally important because (as far as I'm aware) you are unlikely to get a refund from any provider for an SSL certificate on the basis of "it doesn't work".
Last edited:
WOW!!! Thank you SO very much this is exactly what I needed to know. My hosting provider (Media Temple) can handle the setup of the SSL and everything for me and all we will need to do is direct others to use these settings.
I am so happy that we can finally get everything working on our email and get rid of this issue.
You guys Rock!!!
I will wait to see if anyone knows if an issue with the differing domains as you suggest, I have done something like this before to setup mail accounts while waiting for dns settings to propagate and have not seen an issue with it but that does not mean it wont cause possible issues being flagged as spam.
I am so happy that we can finally get everything working on our email and get rid of this issue.
You guys Rock!!!
I will wait to see if anyone knows if an issue with the differing domains as you suggest, I have done something like this before to setup mail accounts while waiting for dns settings to propagate and have not seen an issue with it but that does not mean it wont cause possible issues being flagged as spam.
Last edited:
zconsulting
Basic Pleskian
Faris Raouf is right.
Just to add to the list of SSL certificate providers, you can also use the free certificates at startssl.com.
their certificates cover the top-level plus one subdomain, so i use: yourdomain.tld and mail.yourdomain.tld
As Faris mentioned, you don't want to use www.yourdomain.tld as your server address, if only because it may raise some red flags with spf verification.
Speaking of which, if you do ask your clients to use a separate and single domain for mail services, such as mail.primarydomain.tld , make sure that you mention this on the spf entry of each client domain, so that it looks something like this:
v=spf1 +ip:[your mailserver ip] +a:mail.primarydomain.tld +mx:mail.primarydomain.tld ?a
Overzealous spam protection on the recipient's server can be a real hazard for atypical mail server configurations on the sender side... You also want to make sure that none of your clients are engaging in mass-mailers; even legitimate ones can get your ip blacklisted.
You may want to consider setting up a mail server on a separate domain and ip for mass-mailers if your clients need them.
Finally, i think $10 per month per ip is completely outrageous!! I pay $1 per ip per month at knownhost; that seems like a much more fair price...
Just to add to the list of SSL certificate providers, you can also use the free certificates at startssl.com.
their certificates cover the top-level plus one subdomain, so i use: yourdomain.tld and mail.yourdomain.tld
As Faris mentioned, you don't want to use www.yourdomain.tld as your server address, if only because it may raise some red flags with spf verification.
Speaking of which, if you do ask your clients to use a separate and single domain for mail services, such as mail.primarydomain.tld , make sure that you mention this on the spf entry of each client domain, so that it looks something like this:
v=spf1 +ip:[your mailserver ip] +a:mail.primarydomain.tld +mx:mail.primarydomain.tld ?a
Overzealous spam protection on the recipient's server can be a real hazard for atypical mail server configurations on the sender side... You also want to make sure that none of your clients are engaging in mass-mailers; even legitimate ones can get your ip blacklisted.
You may want to consider setting up a mail server on a separate domain and ip for mass-mailers if your clients need them.
Finally, i think $10 per month per ip is completely outrageous!! I pay $1 per ip per month at knownhost; that seems like a much more fair price...
Last edited:
O Thank you! we have not implemented this yet its on our list of items to make adjustments to down the road.
I was mistaken on the IP cost thats their old pricing structure. They are not just a flat $75 annually and they install them for you. In my opinion thats seems like a very fair price to me.
I totally did not think about adjusting the spf records thats very helpful.!
I was mistaken on the IP cost thats their old pricing structure. They are not just a flat $75 annually and they install them for you. In my opinion thats seems like a very fair price to me.
I totally did not think about adjusting the spf records thats very helpful.!
zconsulting
Basic Pleskian
@DustenH,
you're very welcome, happy to help..
On a more general note, has anyone found that the solution proposed here solves the iPhone imap connection issues?
just to sum up, the solution proposed is to use a valid SSL certificate, regardless of whether it is on a 'central' mail server domain or whether each domain gets its own certificate and ip address...
Again, for me, it seems to have worked...
can anyone else comment on the success or failure of this solution?
Cheers all,
Peter
you're very welcome, happy to help..
On a more general note, has anyone found that the solution proposed here solves the iPhone imap connection issues?
just to sum up, the solution proposed is to use a valid SSL certificate, regardless of whether it is on a 'central' mail server domain or whether each domain gets its own certificate and ip address...
Again, for me, it seems to have worked...
can anyone else comment on the success or failure of this solution?
Cheers all,
Peter
Ok I have a status update.
I purchased an SSL certificarte and had it installed on my mail server(mail.vermillionclients.com) I then took a few users and set their iphones to use the mail.vermillionclients.com instead of their mail.mydomain.com and enabled the use of SSL.
I am actually getting a much more severe problem with the server going into a "server not responding" mode much more frequently when the iphone is setup on the mail.vermillionclients.com than if they used their domain. It works for a couple hours before it quits. Where as previously it was only about once or twice a month it would error out.
All of the domains are on the same server with the same IP so mail.vermillionclients.com resolves to the same location as all of the other domains.
Are there any other settings that I'm missing or that could correct this issue?
MediaTemple suggested changing the mail handler program from qmail to another more common mail handler, but when we did that transition we actually had a ton of emails not being delivered to our server and just seemed to be disappearing so we switched it back.
I purchased an SSL certificarte and had it installed on my mail server(mail.vermillionclients.com) I then took a few users and set their iphones to use the mail.vermillionclients.com instead of their mail.mydomain.com and enabled the use of SSL.
I am actually getting a much more severe problem with the server going into a "server not responding" mode much more frequently when the iphone is setup on the mail.vermillionclients.com than if they used their domain. It works for a couple hours before it quits. Where as previously it was only about once or twice a month it would error out.
All of the domains are on the same server with the same IP so mail.vermillionclients.com resolves to the same location as all of the other domains.
Are there any other settings that I'm missing or that could correct this issue?
MediaTemple suggested changing the mail handler program from qmail to another more common mail handler, but when we did that transition we actually had a ton of emails not being delivered to our server and just seemed to be disappearing so we switched it back.
zconsulting
Basic Pleskian
@DustenH
Make sure you install the SSL cert properly..
There are 4 places where it must be installed:
1 - in the panel, you must install it as the default cert for your IP, and your vermillionclients.com domain MUST be the default domain for that IP (this is in the main server config area).
2 - you must install it for postfix (or whatever milter you're using) (see the link to my blog for more info)
3 - you must install it for IMAP and POP (one copy for each), that happens in /usr/share/ in the following formats: imapd.pem.xxx.xxx.xxx.xxx and pop3d.pem.xxx.xxx.xxx.xxx
4 - for good measure, install it on the site via the panel, this happens in the hosting portion of your domain in the panel (this doesn't really affect email service, but why not be thorough)...
Here's the link to my blog (there's just one entry right now): https://zconsulting.net/blog/
i hope this helps!
Make sure you install the SSL cert properly..
There are 4 places where it must be installed:
1 - in the panel, you must install it as the default cert for your IP, and your vermillionclients.com domain MUST be the default domain for that IP (this is in the main server config area).
2 - you must install it for postfix (or whatever milter you're using) (see the link to my blog for more info)
3 - you must install it for IMAP and POP (one copy for each), that happens in /usr/share/ in the following formats: imapd.pem.xxx.xxx.xxx.xxx and pop3d.pem.xxx.xxx.xxx.xxx
4 - for good measure, install it on the site via the panel, this happens in the hosting portion of your domain in the panel (this doesn't really affect email service, but why not be thorough)...
Here's the link to my blog (there's just one entry right now): https://zconsulting.net/blog/
i hope this helps!
tkalfaoglu
Silver Pleskian
After plesk 12 upgrade I am plagued by iphone/ipad users not being able to send mail.
Is that still handled by courrier-imap or do I have to look at qmail+xinetd for this?
Is that still handled by courrier-imap or do I have to look at qmail+xinetd for this?
U
UFHH01
Guest
Hi tkalfaoglu,
in order to get a decent answer, please consider to add errors from your error - log, because an error description like "I am plagued by iphone/ipad users not being able to send mail." doesn't really point to your issue. Please cosnider as well to open an own thread in the "right" forum section ( Plesk 11 is not Plesk 12 ), because the resolutions may vary from version to version, depending to your issue.
in order to get a decent answer, please consider to add errors from your error - log, because an error description like "I am plagued by iphone/ipad users not being able to send mail." doesn't really point to your issue. Please cosnider as well to open an own thread in the "right" forum section ( Plesk 11 is not Plesk 12 ), because the resolutions may vary from version to version, depending to your issue.
Pagemakers
Silver Pleskian
I have a similar problem that the IMAP server can’t be found only when I’m at home on wifi. Happens only on iOS devices and only on wifi. If I turn wifi off the issue goes away immediately.
While on wifi it works 70% of the time - then fails.
Been connected to the same wifi network for YEARS and with the same server configuration.
While on wifi it works 70% of the time - then fails.
Been connected to the same wifi network for YEARS and with the same server configuration.
tkalfaoglu
Silver Pleskian
Oh yes, there is no error message, they just get a connection error..
Pagemakers
Silver Pleskian
How do I disable IDLE here…
IMAP_CAPABILITY="IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA AUTH=CRAM-MD5 AUTH=CRAM-SHA1 AUTH=CRAM-SHA256 AUTH=PLAIN IDLE"
IMAP_CAPABILITY="IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA AUTH=CRAM-MD5 AUTH=CRAM-SHA1 AUTH=CRAM-SHA256 AUTH=PLAIN IDLE"
U
UFHH01
Guest
Hi Pagemakers,
to remove this "IDLE" setting, just leave out the part and restart COURIER-IMAP:
Before:
After:
Be informed, that you could as well raise the "MAXDAEMONS" setting in "../courier-imap/imapd", even if that might increase your server load a bit
( I think that you want to change your IDLE - settings, because you might experience COURIER-IMAP running out of daemons, due to several all-time connected clients?! )
to remove this "IDLE" setting, just leave out the part and restart COURIER-IMAP:
Before:
Code:
IMAP_CAPABILITY="IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA AUTH=CRAM-MD5 AUTH=CRAM-SHA1 AUTH=CRAM-SHA256 AUTH=PLAIN IDLE"After:
Code:
IMAP_CAPABILITY="IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA AUTH=CRAM-MD5 AUTH=CRAM-SHA1 AUTH=CRAM-SHA256 AUTH=PLAIN"Be informed, that you could as well raise the "MAXDAEMONS" setting in "../courier-imap/imapd", even if that might increase your server load a bit
( I think that you want to change your IDLE - settings, because you might experience COURIER-IMAP running out of daemons, due to several all-time connected clients?! )
Pagemakers
Silver Pleskian
Thank you. It appears to be a problem with iOS devices only.
websavers
Regular Pleskian
We, too, have continually encountered this problem. The weird part is that it seems to occur after an indefinite amount of time. Specific data requested below.
---------------------------------------------------------------
PRODUCT, VERSION, MICROUPDATE, OPERATING SYSTEM, ARCHITECTURE
Plesk 12.0.18 Update #64, last updated at Sept 9, 2015 04:03 AM
CentOS 6.7 Final on x86_64 architecture.
PROBLEM DESCRIPTION
After an indeterminate amount of time, those using iOS only (no other device users have reported this problem) are suddenly unable to authenticate with the following error in the maillog:
Sep 8 04:57:48 {SERVERNAME OBSCURED} courier-imaps: Connection, ip=[::ffff:{IPv4 OBSCURED}]
Sep 8 04:57:48 {SERVERNAME OBSCURED} courier-imaps: LOGIN FAILED, user={EMAIL ADDRESS OBSCURED}, ip=[::ffff:{IPv4 OBSCURED}]
Sep 8 04:57:48 {SERVERNAME OBSCURED} courier-imaps: authentication error: Input/output error
STEPS TO REPRODUCE
This is the tricky part. There are none since it occurs randomly. The closest I can come up with would be:
1) Configure a mail account in Plesk 12.0.x
2) Set it up on an iPhone with latest iOS as noted above
3) Use it as normal and continue doing so for weeks or months until this issue occurs.
ACTUAL RESULT
Eventually, you'll randomly start getting the errors as described above.
EXPECTED RESULT
Mail connectivity continues as normal without any authentication errors.
ANY ADDITIONAL INFORMATION
There is no correlation with iOS version in that this issue was occurring years ago when iOS was at version 5 or 6 and it continues now with the latest iOS v8.4.1 installed. There is no correlation in terms of Plesk version in that it has occurred with v11, 11.5 and now 12.0.
Since this has occurred on Plesk 12 where we can configure MAX_DAEMONS and MAX_PER_IP via the GUI, we have always had those set to very high values like 500 and 80 respectively. When this very same server was running Plesk 11.0 and 11.5 we manually configured those values. Plesk appears to apply those values to both /etc/courier-imap/imapd and /etc/courier-imap/imapd-ssl with version 12.
We make use of our own purchased wildcard SSL certificate that matches the server name (so there is no mismatch error when clients connect).
It may be important to note that we have never seemingly encountered this issue for those connecting via port 143 and using STARTTLS. The logs that I've seen thus-far indicate it ONLY occurs when using port 993 (seemingly without STARTTLS). My own iPhone, for example, connects on 143 with STARTTLS and I've never personally encountered this problem.
At this time we use CSF firewall. Port 993 and 143 are most definitely allowed through (otherwise we'd get no logging at all and all devices wouldn't be capable of connecting). We encountered this issue years ago before we even started using CSF firewall.
As others have reported, removing the account from the iPhone and re-adding it resolves the problem each time. Yet a reboot of the iOS device doesn't change anything. Neither does attempting to reconfigure the account with the known-good settings; it just keeps failing until you completely remove the account and re-create it.
My guess (purely conjecture) as to what's happening is that iOS suddenly finds its unable to connect to the server (for reasons unknown at this time) and attempts to renegotiate the authentication paramaters. Perhaps since it thinks the initial settings aren't an option (as they were failing) it never cycles back to try them again, but of course other combinations of ports and authentication mechanisms fail as well as the server doesn't support them.
Another possibly related situation is that we've encountered similar behaviour in the past with Apple Mail on OS X 10.10 where the app randomly attempts to reconfigure the mail connection to resolve an unknown connectivity issue (it never tells me when it does this, so I don't know what that issue is; it happens in the background). To prevent this from happening, I had to Uncheck the box under "Advanced" that says "Automatically detect and maintain account settings". Unfortunately this isn't an available option on iOS.
--------------------------------------------------------------
POSSIBLE SOLUTIONS:
As some have suggested in this thread, I have now disabled IDLE from the list of IMAP_CAPABILITIES. I don't know if this will solve the problem, time will tell.
I have made one other change that I believe may be the real source of the issue (but it's purely a hunch). Since this problem seems to affect authentication and number of connections, I discovered the following config value in /etc/courier-imap/authlib/authdaemonrc : daemons=5
I have increased this value to 15 (arbitrary) simply to see if iOS may be maxing out the number of simultaneous authentication connections. The comments in the config file DO indicate:
Which sounds a lot like what we're experiencing. My only hesitation in this being the solution is that one would imagine this issue would occur across devices and OS versions and not be limited to just iOS.
---------------------------------------------------------------
PRODUCT, VERSION, MICROUPDATE, OPERATING SYSTEM, ARCHITECTURE
Plesk 12.0.18 Update #64, last updated at Sept 9, 2015 04:03 AM
CentOS 6.7 Final on x86_64 architecture.
PROBLEM DESCRIPTION
After an indeterminate amount of time, those using iOS only (no other device users have reported this problem) are suddenly unable to authenticate with the following error in the maillog:
Sep 8 04:57:48 {SERVERNAME OBSCURED} courier-imaps: Connection, ip=[::ffff:{IPv4 OBSCURED}]
Sep 8 04:57:48 {SERVERNAME OBSCURED} courier-imaps: LOGIN FAILED, user={EMAIL ADDRESS OBSCURED}, ip=[::ffff:{IPv4 OBSCURED}]
Sep 8 04:57:48 {SERVERNAME OBSCURED} courier-imaps: authentication error: Input/output error
STEPS TO REPRODUCE
This is the tricky part. There are none since it occurs randomly. The closest I can come up with would be:
1) Configure a mail account in Plesk 12.0.x
2) Set it up on an iPhone with latest iOS as noted above
3) Use it as normal and continue doing so for weeks or months until this issue occurs.
ACTUAL RESULT
Eventually, you'll randomly start getting the errors as described above.
EXPECTED RESULT
Mail connectivity continues as normal without any authentication errors.
ANY ADDITIONAL INFORMATION
There is no correlation with iOS version in that this issue was occurring years ago when iOS was at version 5 or 6 and it continues now with the latest iOS v8.4.1 installed. There is no correlation in terms of Plesk version in that it has occurred with v11, 11.5 and now 12.0.
Since this has occurred on Plesk 12 where we can configure MAX_DAEMONS and MAX_PER_IP via the GUI, we have always had those set to very high values like 500 and 80 respectively. When this very same server was running Plesk 11.0 and 11.5 we manually configured those values. Plesk appears to apply those values to both /etc/courier-imap/imapd and /etc/courier-imap/imapd-ssl with version 12.
We make use of our own purchased wildcard SSL certificate that matches the server name (so there is no mismatch error when clients connect).
It may be important to note that we have never seemingly encountered this issue for those connecting via port 143 and using STARTTLS. The logs that I've seen thus-far indicate it ONLY occurs when using port 993 (seemingly without STARTTLS). My own iPhone, for example, connects on 143 with STARTTLS and I've never personally encountered this problem.
At this time we use CSF firewall. Port 993 and 143 are most definitely allowed through (otherwise we'd get no logging at all and all devices wouldn't be capable of connecting). We encountered this issue years ago before we even started using CSF firewall.
As others have reported, removing the account from the iPhone and re-adding it resolves the problem each time. Yet a reboot of the iOS device doesn't change anything. Neither does attempting to reconfigure the account with the known-good settings; it just keeps failing until you completely remove the account and re-create it.
My guess (purely conjecture) as to what's happening is that iOS suddenly finds its unable to connect to the server (for reasons unknown at this time) and attempts to renegotiate the authentication paramaters. Perhaps since it thinks the initial settings aren't an option (as they were failing) it never cycles back to try them again, but of course other combinations of ports and authentication mechanisms fail as well as the server doesn't support them.
Another possibly related situation is that we've encountered similar behaviour in the past with Apple Mail on OS X 10.10 where the app randomly attempts to reconfigure the mail connection to resolve an unknown connectivity issue (it never tells me when it does this, so I don't know what that issue is; it happens in the background). To prevent this from happening, I had to Uncheck the box under "Advanced" that says "Automatically detect and maintain account settings". Unfortunately this isn't an available option on iOS.
--------------------------------------------------------------
POSSIBLE SOLUTIONS:
As some have suggested in this thread, I have now disabled IDLE from the list of IMAP_CAPABILITIES. I don't know if this will solve the problem, time will tell.
I have made one other change that I believe may be the real source of the issue (but it's purely a hunch). Since this problem seems to affect authentication and number of connections, I discovered the following config value in /etc/courier-imap/authlib/authdaemonrc : daemons=5
I have increased this value to 15 (arbitrary) simply to see if iOS may be maxing out the number of simultaneous authentication connections. The comments in the config file DO indicate:
Which sounds a lot like what we're experiencing. My only hesitation in this being the solution is that one would imagine this issue would occur across devices and OS versions and not be limited to just iOS.
Last edited:
Pagemakers
Silver Pleskian
Disabling IDLE didn't fix anything for me
Similar threads
