Silently broken Gmail

At work, we have google apps, which comes with several gigs of gmail storage. For email, though, we use outlook server with a low quota. Rather than deleting email, I “archive” to gmail via IMAP.

One day, though, gmail IMAP silently stopped syncing. I could login, but no mail was being transfered. I tried everything — synchronizing accounts, rebuilding the mailbox, but nothing worked. I was hoping to enable some more verbose logging, when I came across an old article from eriklabs.com about Mail.app Logging.

After learning the magic incantation, I started up Mail.app to log all operations on port 993 (the SSL port that gmail IMAP uses).  A message in the logs immediately stood out:

5.1 BAD [ALERT] Message too large. http://mail.google.com/support/bin/answer.py?answer=8770

The prior message logged the timestamp of the offending email, which was over 25MB in size (the max size for Gmail).  Unfortunately, Mail.app had created a large number of copies of this email (over 1,000) and placed them in the “Recovered Items” folder.

Even after deleting all of these “recovered item” copies, Mail kept making new one.  I tracked down a copy of this file in the .OfflineBackups directory. After removing the file that gmail rejects (see http://automatica.com.au/2010/01/mail-app-and-its-offline-cache/ — I chose the file with the large file size in that directory), I was finally able to resync with gmail!

Unfortunately, mail.app was not happy that I removed a file from .OfflineBackups, and it refused to process the rest of the files in that directory.  I wrote the following python script to convert the unprocessed files in .OfflineBackups into a single .mbox file suitable for import into Mail.app.

Thankfully, in the end, everything is back to normal.