Q: IMAP support broken in iOS 7?

From curiosity -- where did you capture this log exchange for the iphone?

tried this process last night.   this morning, ipad w/ os7 is again refusing to delete properly.

The bottom line is it worked prior to iOS 7.

A bit of regression testing might be in order by Apple

pwlees - you're saying that you went into your server, locked the spool file, deleted the dummy message, and still had issues?

My admin tried this process and it made no difference.  Wish it had!  Still can only delete the newest email properly.

That's too bad.

A few questions:

1. did your admin do it in /var/spool or in your ~/mbox?  I think it needs to happen in /var/ spool
2. what IMAP are you using?  We're on UW-IMAP
3. the OTHER thing we did (which didn't seem to apply) was recompile UW-IMAP so that it defaults to ~/mail instead of the homedir
4. were you certain that ALL of your clients were closed when the admin cut the file, and then created a NEW iPhone account?  Maybe I didn't mention that you have to create a new iPhone account...

It was a catagorical fix for us -- clear and straightforward.  But perhaps the ~/mail compile helps as well.

My theory is that when iPhone first comes in, it tries to map all of your homedir, then corrupts its internal database - making it useless for sync.  Restating your path SHOULD overwrite the internal database, but it does not - so the state remains corrupt.

Our recompile FORCES the iPhone to only map the mail directory ... so it never collapses ... and then the removal of the dummy file further forces a redefine of the state and a sync (since NOBODY has the state data).

The compile change is in the docs on UW-IMAP ... it's NOT a scary fix (it's a config file).  I have the notes on THAT if you want them. 

This REALLY works on our system - which is UW-IMAP, BSDOS (UNIX), sendmail

mgmead - thank you so much for your work on this, really appreciated.

I use UW-IMAP with IOS and the fault has been quite a serious problem for the efficient processing of the hundreds of (UW) e-mails received every day. I want to ask if the changes made to the UW-IMAP work flow have corrected mapping for all users, or does it have to be applied for each individual account?

Again, thank you for engaging so actively.

We use UW-IMAP and he did it in both the user and in /var/spool.

After receiving your post, I deleted my mail account, powered off all my devices and we recompiled UW-IMAP as directed.  Recreated the account on the iPAD, leaving all other devices powered off. Still the same problem and all other devices are off!

I was so hoping this was the solution.

I made the remedy suggested by mgmead last Sunday and so far all is well and the iDevice mail problem is gone. I'm using uw-imap and the latest IOS. My account receives about 400 msgs per day. I also reviewed my procmail rules and found one that handles about 1/3 of the total email that didn't set the lock file although I've never had any mangled msgs created by competing procmail deliveries. I don't have any IMAP server core dumps.

Becuase its my own server with few users I was able to just turn off SMTP and IMAP before making the change. I did not bother turning off the 4 devices that check mail since IMAP was down. I then edited out the dummy message at the top of the mail file and started everything back up. Prior to change, iPhone and iPad could only cleanly delete or move the first message in the inbox. Afterwards, no problems regardless of message location in inbox. It was not necesary to reconfigure anythinig on my iPhone and iPad.

Thx.

johnsbramhall

The deletion of the dummy message is per-user related.

The re-compile of UW-IMAP affects all users ... what it does is stop the user's IMAP client from seeing ABOVE the newly targeted location.

So, for example - when I hit email even with Thunderbird (not iPhone), the IMAP subscription tool displays the contents of my HOME dir (~mgmead).  But with the recompile of UW-IMAP makes it so that Thunderbird only offers the contents of ~/mail ... and doesn't even SEE ~mgmead anymore.  That change is universal for all users.

Does that answer your question?

Flowington

What is your system configuration?  What OS?

The ONLY other thing I can think about is that there MIGHT be a second DUMMY message in the spool (Pat said that the DUMMY message does not have to be at the top).  Can you search on DUMMY message text?

Also - small thought - did you delete the empty line that was between the DUMMY message and the first message?

The first line of your spool should be:

                                                               <<<< this line isn't here

From: different@user.com                         <<<< this is the first line now

Subject: this is an actual email

.

.

.

Mgmead,

I tried your fix (deleting the default "FOLDER INTERNAL DATA" message) and after a few days it has continued to work for me!  I did delete the blank line between that message and the first real message.  On our mail server the inbox is in /var/mail/username, and /var/spool contains various mail queues.

So basically if this forces the phone (and other email clients?) to reindex the inbox file, then it seems like something broke between moving/restoring an account from iOS 6 to iOS 7, or upgrading a phone to iOS 7.  I didn't reread this whole thread but was it an issue on new iOS 7 devices also, where nothing was restored?

That also raises the question of whether other folders' indexes were corrupted.  My guess is few people delete lots of messages out of folders other than their inbox, so maybe no one noticed...?

On my email account on the phone, I had the Advanced setting IMAP Path Prefix set to "mail" which should accomplish the same thing as the discussion of recompiling IMAP.  However on our server the inbox is in

/var/mail/username as I said, and other folders are in /home/username/mail.

It will be interesting to see if this is a permanent fix, or if it is just working until the phone re-corrupts its index.

Hi,

This still is a problem Apple must fix. It started when the iOS was updated from 6 to 7. I use a commercial IMAP-mail service and as an end user I can not do the above tricks on the mail server side. I use my IMAP account with Outlook 2010 on Windows7 laptop, Outlook 2013 on Windows 8.1 desktop, Nokia Lumia 1020 and with iPAD and iPhone. Only the iDevices have problems now.

Now have it working but gave up on UW-IMAP. We installed a new IMAP Dovecot version and all works perfectly. Thank you for your assistance as we would not have tried another IMAP without your pinpoint of the server as the issue.  I realize this working for us is not a viable solution for those using a major service provider. Is it possible that our install forced a complete reload of all messages and removed all the prior issues?

Flowingon wrote:

 

Is it possible that our install forced a complete reload of all messages and removed all the prior issues?

Changing mail servers would likely trigger reindexing.  The corollary to POP accounts is that if one has "leave messages on server" checked, the client will redownload all messages.

Dovecot I think also defaults to maildir format which will also trigger a reindex of all messages.