• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Imap connection issues

Hi Steve,

Thank you for your suggestion, i will check it out asap (i can't right now because i can't reach my clients who have this problem)

Although, i just checked their boxes via telnet, and they have both:
INBOX.Sent
and
INBOX.Sent Messages

They can create mailboxes (one client has a whole lot of them)...

At this point, i'll examine any suggestion..

Thank you (Merci)!
Peter
 
The same problem for me. All updates and microupdates installed.

IMAP conections work fine with Win or Linux, but iPhone/iPad lost conection with server and it's impossible to reconnect.
Only if users edit their accounts and change anything on server address (mail.domain.com -> domain.com) worked again, but only for a time.
All my iPad's users have me crazy.

I'd changed:
MAXDAEMONS from 40 to 80
MAXPERIP from 4 to 40
IMAP_CAPABILITY, delete "idle" parameter

But users continue with the same problem.

I need a big help!
 
I've encountered the same situation, with more than one user, in different locations. I see another thread on the Plesk forums about this too.

---------------------------------------------------------------
PRODUCT, VERSION, MICROUPDATE, OPERATING SYSTEM, ARCHITECTURE
Plesk 10.3.1
CentOS 5, Linux 2.6.18-348.6.1.el5
I'm not familiar with the microupdates.

PROBLEM DESCRIPTION
iPhone users get to a point where their phones will no longer connect. They return the unpleasant error that there's a problem with the server.

STEPS TO REPRODUCE
Own an iPhone and use IMAP.

ACTUAL RESULT
The iPhones are actually connecting and disconnecting in very rapid succession.

EXPECTED RESULT
Connect and download email without a problem.

ANY ADDITIONAL INFORMATION
I've already increased the number of connections allowed per IP, as well as the daemons. However, those errors are logged, and I'm not seeing them.

As mentioned above, it does appear that the iPhones are actually connecting (and then rapidly disconnecting).

Deleting the account and reconfiguring it resolves the problem for my clients.

I've seen references to this on the Apple forums. One possible lead is a problem with the SSL certificates.

--------------------------------------------------------------
 
indeed, SSL Certificates may have a role in this, even though the same thing happens to iPhone 4/4S using IMAP without SSL...
For info, here is what i did

Basically, the idea is to increase the number of MAXPERIP and MAXDAEMONS in the pop3d file as well as the imapd file in /etc/courier-imap/

However, this was a solution in Plesk 9, but still fails in Plesk 11 (even though all settings are similar)
 
I upgrade my Plesk version to 11.5... completed all of the microupdates and there are no updates available via yum. However, the problem still persists.

In my situation, this is not a maxperip or maxdaemons issue. Those connection rejections are recorded in the messages log, and I'm not seeing those. Also, watching the processes suggests this isn't an issue. I'm already allowing more than 100 connections.

In my log file, I'll see lots of rapid connecting and disconnecting.

Jun 23 07:19:07 mercury courier-imaps: Connection, ip=[::ffff:68.46.169.247]
Jun 23 07:19:07 mercury courier-imaps: LOGIN, user=[user removed], ip=[::ffff:68.46.169.247], port=[3717], protocol=IMAP
Jun 23 07:19:07 mercury courier-imaps: DISCONNECTED, user=[user removed], ip=[::ffff:68.46.169.247], headers=0, body=0, rcvd=100, sent=508, time=0, starttls=1
Jun 23 07:19:08 mercury courier-imaps: Connection, ip=[::ffff:68.46.169.247]
Jun 23 07:19:08 mercury courier-imaps: LOGIN, user=[user removed], ip=[::ffff:68.46.169.247], port=[3718], protocol=IMAP
Jun 23 07:19:08 mercury courier-imaps: DISCONNECTED, user=[user removed], ip=[::ffff:68.46.169.247], headers=0, body=0, rcvd=85, sent=250, time=0, starttls=1
Jun 23 07:19:09 mercury courier-imaps: Connection, ip=[::ffff:68.46.169.247]
Jun 23 07:19:09 mercury courier-imaps: LOGIN, user=[user removed], ip=[::ffff:68.46.169.247], port=[3719], protocol=IMAP
Jun 23 07:19:09 mercury courier-imaps: DISCONNECTED, user=[user removed], ip=[::ffff:68.46.169.247], headers=0, body=0, rcvd=85, sent=250, time=0, starttls=1

I've gone through the process of reinstalling my SSL on courier-imap, along with the intermediate and root certificates. That does not appear to have helped. I'm wondering if iPhones only accept some SSL certificates. Mine is issued via GeoTrust.

If the iPhone user deletes his/her account on the device, then reconfigures it, it may work indefinitely. Something happens that triggers a complete failure.

Mac computers are not having troubles. Only iPhones and iPads.

Best regards,
James
 
i do think it has something to do with SSL certificates...
as i said above, Plesk 9 worked ok after the fix i mention, but Plesk 11 still fails....
It is true that it will work for a while, then, for some reason unknown to me, it starts to fail...
 
I work for a shared hosting provider and we have the same problem with ONLY iphone/ipad customers.

The issue comes up every day from customers, imap stops connecting "cannot get mail, the mail server **** is not responding", and multiple connections/disconnections show in the logs.

Our mail logs show the same connect/disconnects as 'theywill' has supplied from his logs.

Our mail server has
MAXDAEMONS=80
MAXPERIP=150

Our certs are issued through comodo.

The only "fix" so far is to delete the account from the device and re-add it. Obviously not ideal.

I thought maybe the problem was related to having too many sub-folders that the imap connection were connecting too.
However one customer with a brand new account, and the standard folders inbox, sent, drafts, trash still had the problem.

There has to be a permanent fix?
 
It's so strange that this problem is so prevalent, yet there are very few 'intelligent' discussions on this, and no real solutions to be found yet...
I wonder if the folks at Parallels monitor these forums...
 
I'm having a similar problem, even without the iPhone issues. We've already changed the imapd config file (actually both pop3 and imapd) and restarted the mail service - to no avail.

Perhaps there is an 'override' setting in the mySql database Plesk uses (which is why we find no anomalies in the system files) - that's the only other possibility I can think of. I'll have a look later today and let you know if I find something.

Of course, any changes we make will be negated with the next Plesk update...
 
Im having all sorts of trouble with imap. Mainly with Apple products, but also with Thunderbird clients. Would love to see some resolution to this issue.
 
I upgrade my Plesk version to 11.5... completed all of the microupdates and there are no updates available via yum. However, the problem still persists.

In my situation, this is not a maxperip or maxdaemons issue. Those connection rejections are recorded in the messages log, and I'm not seeing those. Also, watching the processes suggests this isn't an issue. I'm already allowing more than 100 connections.

In my log file, I'll see lots of rapid connecting and disconnecting.

Jun 23 07:19:07 mercury courier-imaps: Connection, ip=[::ffff:68.46.169.247]
Jun 23 07:19:07 mercury courier-imaps: LOGIN, user=[user removed], ip=[::ffff:68.46.169.247], port=[3717], protocol=IMAP
Jun 23 07:19:07 mercury courier-imaps: DISCONNECTED, user=[user removed], ip=[::ffff:68.46.169.247], headers=0, body=0, rcvd=100, sent=508, time=0, starttls=1
Jun 23 07:19:08 mercury courier-imaps: Connection, ip=[::ffff:68.46.169.247]
Jun 23 07:19:08 mercury courier-imaps: LOGIN, user=[user removed], ip=[::ffff:68.46.169.247], port=[3718], protocol=IMAP
Jun 23 07:19:08 mercury courier-imaps: DISCONNECTED, user=[user removed], ip=[::ffff:68.46.169.247], headers=0, body=0, rcvd=85, sent=250, time=0, starttls=1
Jun 23 07:19:09 mercury courier-imaps: Connection, ip=[::ffff:68.46.169.247]
Jun 23 07:19:09 mercury courier-imaps: LOGIN, user=[user removed], ip=[::ffff:68.46.169.247], port=[3719], protocol=IMAP
Jun 23 07:19:09 mercury courier-imaps: DISCONNECTED, user=[user removed], ip=[::ffff:68.46.169.247], headers=0, body=0, rcvd=85, sent=250, time=0, starttls=1

I've gone through the process of reinstalling my SSL on courier-imap, along with the intermediate and root certificates. That does not appear to have helped. I'm wondering if iPhones only accept some SSL certificates. Mine is issued via GeoTrust.

If the iPhone user deletes his/her account on the device, then reconfigures it, it may work indefinitely. Something happens that triggers a complete failure.

Mac computers are not having troubles. Only iPhones and iPads.

Best regards,
James

Hello James,

I've found that maybe the thing that triggers the IMAP disconnection can be related with the amount/size of messages in the Inbox folder.
My experiment was:
Since I first posted in this thread (Jan 13th 2013), I configured an IMAP account in my personal iPhone.
I started using it, but everyday, I moved the messages o archived them in a different folder, keeping the Inbox clean and its size small.

Well here we are more than 6 months later, without a solution, but I can tell you that I didn't received any disconnection message or issue since then.
So I'm pretty sure the problem that triggers the error, is related with the Inbox size.
I still have problems with my customers, iPad, iPod, iPhone with any model and/or iOS version, and when I check their accounts, they have many messages in their inboxes.

TO PARALLELS SUPPORT TEAM

PRODUCT, VERSION, MICROUPDATE, OPERATING SYSTEM, ARCHITECTURE
Parallels Plesk 11.0.9 Microupdate #55 - CENTOS 5.8, x32 bits

PROBLEM DESCRIPTION
Alternately, an IMAP account connection doesn't work ("impossible to connect to imap.xxx.com...") with iOS devices, (ipad, iphone, ipod) any model and/or iOS version

TEMPORARY SOLUTION
The only ways to get connection again is creating a new DNS A zone (imap.domain.com) and change it in the account settings, or deleting the account and configure it again in the iOS device.
Also if the account keeps the Inbox folder clean, the problem seems not to appear.

Please help!
 
It seems that cpanel and others with this problem have switched from courier to dovecot.
Is that the only solution or can courier be fixed some how?
 
The problem only appears when SSL is activated. If you check the logs, you see that the command can not be read properly.

How it appears:

Aug 24 15:07:38 rs201444 imapd: Connection, ip=[::ffff:xx.xx.xx.xx]
Aug 24 15:07:38 rs201444 imapd: LOGIN: DEBUG: ip=[::ffff:xx.xx.xx.xx], command=...
Aug 24 15:07:38 rs201444 imapd: LOGIN: DEBUG: ip=[::ffff:xx.xx.xx.xx], command=.....(.'.........&.%.*.).............
Aug 24 15:07:38 rs201444 imapd: LOGIN: DEBUG: ip=[::ffff:xx.xx.xx.xx], command=
Aug 24 15:07:38 rs201444 imapd: LOGIN: DEBUG: ip=[::ffff:xx.xx.xx.xx], command=
Aug 24 15:07:38 rs201444 imapd: 1377349658.795150 DISCONNECTED, ip=[::ffff:xx.xx.xx.xx], headers=0, body=0, rcvd=181, sent=343, maildir=/


Aug 24 15:07:02 rs201444 imapd-ssl: Connection, ip=[::ffff:xx.xx.xx.xx]
Aug 24 15:07:03 rs201444 imapd-ssl: LOGIN: DEBUG: ip=[::ffff:xx.xx.xx.xx], command=AUTHENTICATE
Aug 24 15:07:03 rs201444 imapd-ssl: auth_psa: starting client module
Aug 24 15:07:03 rs201444 imapd-ssl: IMAP connect from @ [::ffff:xx.xx.xx.xx]DEBUG: auth_psa: ACCEPT, username [email protected]
 
I suspect that this has to do with the self-signed security certificates that Plesk uses...

One possible lead is a problem with the SSL certificates.

i do think it has something to do with SSL certificates...

The problem only appears when SSL is activated. If you check the logs, you see that the command can not be read properly.

We've been using a Trustwave SSL certificate with courier-imap and our customers that use iPhones are experiencing the same issues with IMAP so I can verify, beyond the shadow of a doubt, that this is NOT caused by the Plesk self-signed certificate. And -- judging by the sheer number of discussions related to IMAP & Gmail going on over at discussions.apple.com and over at productforums.google.com -- the problem lies with the iPhone client.
 
Back
Top