IMAP Issues

[SethDW]

Hello,

I'm running panel 11.0.9 on CentOS 6.2. I am not a Linux power-user. This server is a dedicated machine through Codero.

One of my IMAP mail users is experiencing a problem I can't figure out. With this one particular account everything is fine if I access it from a computer (Mac OS Mavericks with default Mac email app, or PC with Mozilla Thunderbird) or from a webmail service.

However, if accessed from iOS (tried with three clients thus far -- default mail app, Sparrow, and Boxer email clients) the full IMAP message index isn't being loaded. For example, this user has just over 20 messages today, and only eight of them show on the mobile mail apps. Ironically, it's the same 8 that show on all three clients, and the same 12-ish are missing.

I tried restarting the plesk IMAP service and no change. I moved the maildirsize file out of the directory (/var/qmail/mailnames/hartmancox.com/[user]/Maildir) and no change. I ran mchk (http://kb.parallels.com/en/944) which regenerated the maildirsize file. Still no change.

There are two other files there -- courierimapsubscribed and courierimapuiddb. Should I delete all three of those files and then run mchk again?

Any ideas?

Thanks.

 

[Nikolay.]

courierimapsubscribed file maintains a list of "subscribed" folders, i.e. IMAP folders that clients see. courierimapuiddb maintains a list of identifiers for messages when accessed via IMAP (or only POP3, I don't remember exactly). mchk (mail_restore) will restore neither of these files, as Plesk doesn't manage them. However, Courier-IMAP would restore them automatically on first access.

So, if you remove courierimapsubscribed you will lose existing subscriptions and will need to fix them manually in mail client (so this probably wouldn't help you at all). If you remove courierimapuiddb then all messages will be treated as new and will be forced to be re-downloaded by mail clients, AFAIK. So the latter option might help you.

Also note that iOS clients are known to have problems with Courier-IMAP. They are at least very greedy for server connections. Sometimes increasing number of allowed connections helps, sometimes it doesn't. This KB might help.

 

[SethDW]

OK, thanks for the information. I deleted the -uiddb file and, the desktop-based clients responded exactly as you said -- treated all messages as new and re-indexed the folder. It had no effect on the iOS clients. Given that three clients are all missing the same messages, it seems as if it's something at the core IMAP process implemented by iOS and used by all three clients.

I've already increased the number of connections which fixed other iOS issues.

As you noted, there seems to be an issue with IMAP implementation in iOS -- there are similar complaints in this discussion.