Fix imapsync Migration Dates in Gmail

imapsync is the go-to tool for IMAP-to-IMAP mailbox migration, and for good reason - it handles folder mapping, flag preservation, and incremental syncing better than most alternatives. But when the destination is Gmail, date preservation becomes unreliable in ways that surprise even experienced sysadmins.

The --syncinternaldates flag is supposed to solve this. It tells imapsync to pass the source message's INTERNALDATE to the destination server during APPEND. On a standard IMAP server, this works. On Gmail? Not always. Gmail's IMAP implementation runs incoming messages through its own internal processing pipeline - spam filtering, security scanning, content indexing. During this processing, Gmail may override the requested INTERNALDATE and stamp the message with the upload timestamp instead. It also adds a Received header (typically containing "gmailapi.google.com" or the IMAP gateway identifier) dated to the upload moment.

The infuriating part: this does not happen to every message. Some emails in the migrated mailbox get the correct INTERNALDATE. Others get the upload date. There is no clear pattern - a message from 2018 might be fine while the one right next to it from the same day is stamped with the migration date. You end up with a mailbox where 30-70% of emails have wrong dates, scattered randomly across folders and time periods.

Ever tried explaining to a compliance officer why 4,200 out of 11,000 migrated emails show the wrong received date, but the other 6,800 are fine? Good luck finding a pattern in that.

Gmail's web interface actually hides the problem. Gmail web displays the Date header value, not the INTERNALDATE, so most affected emails look fine in the browser. This creates a dangerous false sense of security - the migration admin checks Gmail web, sees correct dates, and closes the ticket.

Then users start connecting Outlook, Apple Mail, and Thunderbird to their new Gmail accounts. These clients read the IMAP INTERNALDATE for their date columns. Suddenly, random emails show the migration date while others show the correct date. The inconsistency between Gmail web and desktop clients generates confused support tickets. Server-side IMAP search commands (SEARCH SINCE, SEARCH BEFORE) reference the INTERNALDATE, returning incomplete or inaccurate results. Third-party backup tools archiving via IMAP capture the corrupted dates permanently. Google Vault and Workspace compliance tools may reference the INTERNALDATE for date-based holds, potentially impacting legal discovery. Redate.io's pattern matching across migration tool signatures identifies the specific Gmail Received headers that indicate date corruption, then applies targeted metadata correction to every affected message while preserving all labels, stars, and read/unread status.