Imap connection issues

[Eric Pretorious]

Our customers are still experiencing trouble accessing IMAP using the iPhone client so I'm wondering:

1. Was there a solution to this thread or did it just fade away?
2. Are both methods (IMAP SSL [Port 993] versus IMAP StartTLS [Port 143]) causing the same failures? Or is the problem specific to the TCP port?

 

[Eric Pretorious]

I've modify imap file with this :

MAXDAEMONS=80
MAXPERIP=40

Note that i have also increased the MAXPERIP and MAXDAEMONS variables for both imap and pop3 (i read somewhere that iPhones were using pop3 authentication for IMAP connections) -- vell, that did not resolve the issue either.

I found a really old 8.x-related thread which has a suggestion about this: http://forum.parallels.com/showthread.php?t=84532

In it, FranklinT says:

One solution is, of course, to raise MAXDAEMONS in /etc/courier-imap/imapd, but you will eventually begin to tax your server's resources unduly.

The sysadmin assures me that he set the following variables for 2 files in /etc/courier-imap/:
For imapd:
MAXDAEMONS=300 and MAXPERIP=200
For pop3d:
MAXDAEMONS=40 and MAXPERIP=4

I've noticed that everyone seems to be making changes to /etc/courier-imap/imapd but there are actually three different configuration files related to IMAP in /etc/courier-imap/:

[root@www log]# find /etc/courier-imap/ -maxdepth 1 -type f -name 'imap*' | grep -v 'saved_by_plesk'
/etc/courier-imap/imapd-ssl
/etc/courier-imap/imapd
/etc/courier-imap/imapd.cnf

...and I've noticed that most people agree that none of the changes fix the problem:

Note that i have also increased the MAXPERIP and MAXDAEMONS variables for both imap and pop3 (i read somewhere that iPhones were using pop3 authentication for IMAP connections) -- vell, that did not resolve the issue either.

Could it be possible that the changes should be made in one of the other two configuration files (i.e., /etc/courier-imap/imapd-ssl or /etc/courier-imap/imapd.cnf)? i.e., Has anyone actually checked to verify the changes had the intended effect?

[root@www log]# ps ax | grep imap | grep ssl
 1881 ?        SN     0:00 /usr/lib/courier-imap/couriertcpd -address=0 -stderrlogger=/usr/sbin/courierlogger -stderrloggername=imapd-ssl [COLOR="#FF0000"]-maxprocs=40 -maxperip=4[/COLOR] -pid=/var/run/imapd-ssl.pid -nodnslookup -noidentlookup 993 /usr/bin/couriertls -server -tcpd /usr/sbin/imaplogin /usr/lib/courier-imap/authlib/authpsa /usr/bin/imapd Maildir
 1883 ?        SN     0:00 /usr/sbin/courierlogger imapd-ssl
 1898 ?        SN     0:01 /usr/lib/courier-imap/couriertcpd -address=0 -stderrlogger=/usr/sbin/courierlogger -stderrloggername=pop3d-ssl [COLOR="#FF0000"]-maxprocs=40 -maxperip=4[/COLOR] -pid=/var/run/pop3d-ssl.pid -nodnslookup -noidentlookup 995 /usr/bin/couriertls -server -tcpd /usr/sbin/pop3login /usr/lib/courier-imap/authlib/authpsa /usr/bin/pop3d Maildir

 

[Nikolay.]

the problem lies with the iPhone client.

I agree that it's the most plausible explanation. Provided Apple platforms are quite closed it's only fair to assume they intentionally or inadvertently caused incompatibility with certain IMAP servers. It also always strikes me how hungry Apple mobile mail clients are for server connections.

I guess switching to Dovecot might really help here since I heard Apple's own IMAP software in their server OS was based on Dovecot.

Has anybody attempted to wireshark failing connections? Each exchange is small enough, so it could be analyzed. Is it confirmed that this issue happens only with SSL port or STARTTLS?

 

[Nikolay.]

there are actually three different configuration files related to IMAP in /etc/courier-imap/:

[root@www log]# find /etc/courier-imap/ -maxdepth 1 -type f -name 'imap*' | grep -v 'saved_by_plesk'
/etc/courier-imap/imapd-ssl
/etc/courier-imap/imapd
/etc/courier-imap/imapd.cnf

...

Could it be possible that the changes should be made in one of the other two configuration files (i.e., /etc/courier-imap/imapd-ssl or /etc/courier-imap/imapd.cnf)? i.e., Has anyone actually checked to verify the changes had the intended effect?

imapd.cnf is Courier-IMAP own default template (configuration file) for generating self-signed SSL certificates. Therefore it's not relevant.
Both imapd and imapd-ssl are sourced as configuration files for IMAP SSL process. Also imapd-ssl has neither MAXDAEMONS, nor MAXPERIP options in it by default. This is at least correct for Plesk 11.5 - I don't remember for sure how it is done in previous versions, but AFAIK it's quite similar.

So this shouldn't be a problem.

 

[Eric Pretorious]

I guess switching to Dovecot might really help here since I heard Apple's own IMAP software in their server OS was based on Dovecot.

Hm. I'm not so sure that I want to start making changes based on that loose association. Besides, I read "somewhere" that Dovecot has the same issues with iPhone clients.

 

[Nikolay.]

Hm. I'm not so sure that I want to start making changes based on that loose association. Besides, I read "somewhere" that Dovecot has the same issues with iPhone clients.

Oh no, please don't make changes based on this claim. I never meant that one should really manually switch to Dovecot to fix the problem at hand! I just implied that the problem might get a workaround when (and if) Dovecot support is implemented in Plesk.

 

[zconsulting]

Hello,
i haven't checked this thread in a long time, and came back out of desperation...
as i stated before, i doubt this particular issue has anything to do with MAXPERIP and MAXDAEMONS variables (once they have been raised to reasonable levels)..
Has anyone made any progress on this?
Luckily, i've only ever known this problem to affect the iPhone 4S (not the 4 or 5 -- haven't tested the 5c or 5s yet)...

Cheers!

 

[Frater]

imapd.cnf is Courier-IMAP own default template (configuration file) for generating self-signed SSL certificates. Therefore it's not relevant.
Both imapd and imapd-ssl are sourced as configuration files for IMAP SSL process. Also imapd-ssl has neither MAXDAEMONS, nor MAXPERIP options in it by default. This is at least correct for Plesk 11.5 - I don't remember for sure how it is done in previous versions, but AFAIK it's quite similar.

So this shouldn't be a problem.

EDIT: some conclusions in this post turned out to be incorrect... Read on!!


It is similar, but it's not the same.
Because I was aware of this ludicrous setting in Plesk for imap and pop3 I patch my Plesk servers before they go into production.
I recently (3 months ago) installed a new Plesk 11.5 and patched both /etc/courier-imap/imapd and /etc/courier-imap/pop3d so they both contain MAXDAEMONS=80 and MAXPERIP=40

I recently moved a heavy IMAP from an old Plesk 10.5 server to this Plesk 11.5 server and they developed problems using imap.
My colleague found out there were no problems when using port 143.
They were using Apples and when I choose for SSL I always take straight SSL (on port 993) instead of TLS (on port 143).


When I did a "ps aux | grep courier" I noticed that both the MAXDAEMONS= and MAXPERIP= parameters show in the ps list.
I then noticed that port 993 and port 995 still had the default values of merely 4 IP's and 40 daemons...

I checked my old server and there all processes had the increased value (ports 110, 143, 993 and 995).
I never patched /etc/courier-imap/imapd/imapd-ssl on that old server, so I never did this on my new server.. I thought I had me a "set and forget thing"
It seems as if the old server takes the value out of /etc/courier-imap/imapd which is strange behaviour in itself.
The courier developers must have corrected this.

There are no MAXDAEMONS= and MAXPERIP= values set in /etc/courier-imap/imapd/imapd-ssl nor are there example settings.
I added these values in there and now everything is fine.

Make sure you now set 4 files in /etc/courier-imap for a "sane server"
And Plesk should be improved so it (at least on a virgin installation) sets these parameters.

# grep 'MAX.*=' /etc/courier-imap/*
/etc/courier-imap/imapd:MAXDAEMONS=80
/etc/courier-imap/imapd:MAXPERIP=40
/etc/courier-imap/imapd-ssl:MAXDAEMONS=80
/etc/courier-imap/imapd-ssl:MAXPERIP=40
/etc/courier-imap/pop3d:MAXDAEMONS=80
/etc/courier-imap/pop3d:MAXPERIP=40
/etc/courier-imap/pop3d-ssl:MAXDAEMONS=80
/etc/courier-imap/pop3d-ssl:MAXPERIP=40

The configuration of /etc/courier-imap/imapd is clearly not sourced anymore for the ssl process
It's the same for pop3
Especially the MAXPERIP setting will give you problems when you have more than 4 clients behind 1 IP (which is quite normal nowadays)

Bottom line....

On older servers one merely needed to change /etc/courier-imap/imapd and /etc/courier-imap/pop3d.
Now you also need to change /etc/courier-imap/imapd-ssl and /etc/courier-imap/pop3d-ssl

 

[Nikolay.]

The configuration of /etc/courier-imap/imapd is clearly not sourced anymore for the ssl process
It's the same for pop3

Oh, but they are! Just checked and they are sourced, at least on clean installation. You probably have other parts patched that interfere or forgot to restart all services (there are 5 Courier services in Plesk 11.5 instead of just 1).

 

[Nikolay.]

BTW, did anybody try Plesk 12 preview to see if problem is still there with Dovecot instead of Courier-IMAP?

I haven't checked for this specific problem, but overall Dovecot integration in Plesk 12 seems quite good and thoughtful.

 

[zconsulting]

@Frater: i never even thought that courier-imap-ssl (the courier-imaps service) would use other limits for MAXPERIP and MAXDAEMONS.
Just in case, i added these limits and restarted the service...
we'll see if it makes any changes.

As i've said before, this is an issue i've only ever observed on the iPhone4S (not on any other iPhone from the iPhone 3 to the 5s)

I am glad to see some movement on this forum as this is still an issue that i see happen even on the most-up-to-date 11.5 panel..

 

[/dev/null]

I checked so far only the Demo version. I believe i saw something to control the setting in the Plesk 12 version under
'mail server settings' line number of connections etc . So I think in the next version we do not need to change this from the shell.

 

[Frater]

Oh, but they are! Just checked and they are sourced, at least on clean installation. You probably have other parts patched that interfere or forgot to restart all services (there are 5 Courier services in Plesk 11.5 instead of just 1).

I wanted to prove you wrong because I was rather thorough in my tests.
It turned out you are right.

I do know now what happened...

That server never restarted.
I patched these 2 files and merely invoked "/etc/init.d/courier-imapd stop && /etc/init.d/courier-pop3d stop" and "/etc/init.d/courier-imapd start && /etc/init.d/courier-pop3d start" afterwards.

I never thought of restarting the "courier-imaps" service and "courier-pop3s"
That service didn't exist in Plesk 10.5


"End conclusion": Do not forget to restart all 4 services after patching /etc/courier-imap/imapd/imapd and /etc/courier-imap/imapd/pop3d

#
MAXDAEMONS=80
MAXPERIP=40

cp -p /etc/courier-imap/imapd /etc/courier-imap/imapd.`date +%Y.%m.%d`
cp -p /etc/courier-imap/pop3d /etc/courier-imap/pop3d.`date +%Y.%m.%d`
cp -p /etc/courier-imap/imapd-ssl /etc/courier-imap/imapd-ssl.`date +%Y.%m.%d`
cp -p /etc/courier-imap/pop3d-ssl /etc/courier-imap/pop3d-ssl.`date +%Y.%m.%d`

grep -q "^MAXDAEMONS=${MAXDAEMONS}" /etc/courier-imap/imapd || sed -i "s/^MAXDAEMONS=.*/MAXDAEMONS=${MAXDAEMONS}/g" /etc/courier-imap/imapd
grep -q "^MAXPERIP=${MAXPERIP}" /etc/courier-imap/imapd || sed -i "s/^MAXPERIP=.*/MAXPERIP=${MAXPERIP}/g" /etc/courier-imap/imapd

grep -q "^MAXDAEMONS=${MAXDAEMONS}" /etc/courier-imap/pop3d || sed -i "s/^MAXDAEMONS=.*/MAXDAEMONS=${MAXDAEMONS}/g" /etc/courier-imap/pop3d
grep -q "^MAXPERIP=${MAXPERIP}" /etc/courier-imap/pop3d || sed -i "s/^MAXPERIP=.*/MAXPERIP=${MAXPERIP}/g" /etc/courier-imap/pop3d


/etc/init.d/courier-imapd stop
/etc/init.d/courier-imaps stop
/etc/init.d/courier-pop3d stop
/etc/init.d/courier-pop3s stop

/etc/init.d/courier-imapd start
/etc/init.d/courier-imaps start
/etc/init.d/courier-pop3d start
/etc/init.d/courier-pop3s start
#

 

[Nikolay.]

I wanted to prove you wrong because I was rather thorough in my tests.

I expected nothing less. Thanks

BTW, there's also /etc/init.d/courier-authdaemon - it's an authentication service for Courier. Though it has a separate config.

 

[RobinL]

Has anyone had any updates regarding the IMAP connection issues? We have a Plesk server running version 11.5.3 and have experienced the same issue with Apple devices for a number of months. I have experienced it first hand with an iPad Air and we have had a few customers who have had issues with iPhones. Our server providers put the blame onto Apple but I just can't decide if this is the case or not.

We don't have SSL certificates for the domains that we host emails with, therefore we use port 143 and STARTTLS. When using desktop applications such as Thunderbird, the dialog box to confirm the parallel plesk security certificate appears the first time the mail box is set up. My only thought is that for some reason these self signed certificates are expiring on Apple devices and never informing the user to accept a new certificate, causing the device to never connect. I could be completely wrong but I don't have any other thoughts on why it would happen.

When I experienced the issue on my iPad, I deleted the account, re-entered the details and received the same connection error as before, then I clicked details and a dialog box appeared to confirm the parallel plesk certificate. Once accepted, the connection worked fine. Again, I am not sure if this is the root of the problem but I would be interested to hear everyone's thoughts.

 

[zconsulting]

Hi RobinL,
i would very strongly recommend you install some valid SSL certificates; it's very easy, but it does require that your domain be on its own IP address.
i posted elsewhere on this forum how to do this, and also posted this to a blog here: https://zconsulting.net/blog/ -- it's the only entry for now.
it's really easy to do, for imap/pop3, and just requires a slight modification for postfix (SMTP)
You can get free SSL certificates at startssl that work just fine for these purposes..
Note: once you do install the certificates, delete the accounts from the iPhones, and re-create them, otherwise you will still get problems with SSL certificates mis-match on the iPhone clients..
i hope this helps...

 

[RobinL]

Hi RobinL,
i would very strongly recommend you install some valid SSL certificates; it's very easy, but it does require that your domain be on its own IP address.
i posted elsewhere on this forum how to do this, and also posted this to a blog here: https://zconsulting.net/blog/ -- it's the only entry for now.
it's really easy to do, for imap/pop3, and just requires a slight modification for postfix (SMTP)
You can get free SSL certificates at startssl that work just fine for these purposes..
Note: once you do install the certificates, delete the accounts from the iPhones, and re-create them, otherwise you will still get problems with SSL certificates mis-match on the iPhone clients..
i hope this helps...

Hi there,

Thank you for the reply. How should we be doing the emails for domains? We host around 50 separate domains on our server at the moment. We surely can't have 50 separate IP addresses and certificates for each domain. That would be too expensive and make the hosting uncompetitive? At the moment each domain connects to, mail.THEREDOMAIN.com to access their emails, should everyone be channeled through mail.standardemailserver.com so that we only need one ssl and ip for everyone emails on the server?

Thanks

 

[zconsulting]

Hi RobinL,

You may want to try it for one or 2 domains -- pick the most problematic ones -- and see how it goes...
i pay $1 per year per IP at knownhost (i really, really like them, and no, i'm not affiliated with them, aside from being a client). That doesn't seem like a huge hit to me..
Having each domain on its own IP has other advantages too (like MX reputation issues, just to name one)

Note: if you go with free startssl certificates, you can only list the top-level + one subdomain. i.e.: domain.com + mail.domain.com
so that leaves out using imap.domain.com or smtp.domain.com...

For my part, i've taken to configuring mail clients to use domain.com for simplicity's sake: really, the only reason you'd want to use specific subdomains in email clients is if those sub-domains were on different IPs or different servers... Neither being the case, just stick with domain.com

 

[DustenH]

So we are having the same problem with out VPS running Plesk 11.5.30 Update #47, Fully patched fully updated. we have had this same issue for over two years. Has anyone found a permanent solution to this issue yet?

 

[zconsulting]

@DustenH,

I think you should try putting one of the domains on its own IP, and install some security certificates as i mention above (see here)..
if that proves ok, then do so for each domain...
This seems to have solved the problem for me (note that some iPhone may experience this issue when you first switch to the valid certificates)...