Why imapsync Is Popular (and Why Dates Still Break)
imapsync is the go-to email migration tool for Linux system administrators, hosting providers, and anyone who prefers open-source solutions. Created by Gilles Lamiral, imapsync has been actively maintained since 2001 and has been used for millions of mailbox migrations worldwide. It supports virtually every IMAP server: Dovecot, Courier, Cyrus, Zimbra, Exchange, Gmail, and dozens more.
imapsync has a reputation for being thorough and configurable. Administrators love its granular control over which folders to migrate, how to handle duplicates, and how to map folder names between different IMAP servers. But despite all this control, one problem persists: email dates are frequently not preserved after an imapsync migration. Users open their mailbox after migration and find that every email shows the migration date. It's maddening, especially because imapsync is supposed to handle dates correctly.
How imapsync Handles INTERNALDATE
The INTERNALDATE Preservation Attempt
imapsync does attempt to preserve the INTERNALDATE of each email during migration. The INTERNALDATE is the timestamp that the IMAP server stores as metadata for each message, separate from the email headers. When imapsync copies a message from the source to the destination, it reads the INTERNALDATE from the source server and passes it to the destination server in the IMAP APPEND command.
In theory, this should preserve the original date. In practice, the result depends on the destination server's behavior and on how email clients interpret the various date-related fields in the message.
The "Received" Header Problem
Even when imapsync successfully preserves the INTERNALDATE, the destination mail server adds a new "Received" header to each message during the APPEND operation. This "Received" header contains the current timestamp, the migration date. Email clients like Outlook, Apple Mail, and Thunderbird determine the displayed "received date" by reading the topmost "Received" header, not the INTERNALDATE. So despite imapsync's effort to preserve the INTERNALDATE, the visible date in most email clients is still wrong.
This is the fundamental disconnect that causes confusion. imapsync preserves one date value (INTERNALDATE), but email clients display a different one (the "Received" header timestamp). Why do email clients ignore the INTERNALDATE? Because the "Received" header is part of the email standards, and clients are following those standards correctly. For a technical deep dive into this mechanism, see why emails show wrong dates after IMAP migration.
The imapsync FAQ Misconception
The imapsync documentation and FAQ address the date issue but frame it as an inherent limitation. The FAQ suggests that "dates may not be preserved" during IMAP migration and implies that this is just how the IMAP protocol works. While it's true that the IMAP protocol requires servers to add "Received" headers during message insertion, the FAQ creates the impression that the problem is permanent and unfixable.
That's not accurate. The "Received" headers added during migration can be identified and removed after the fact, restoring the original date display in email clients. The original "Date" header (which records when the email was originally sent) is always preserved by imapsync and serves as the reference for the correct date.
Identifying the imapsync Migration Header
What the Header Looks Like
imapsync itself does not add a "Received" header - the destination IMAP server does. The header added during an imapsync migration typically looks like a standard IMAP insertion header from the destination server. For example, if migrating to a Dovecot server, the header might look like:
Received: from localhost by mail.example.com;
Wed, 15 Jan 2025 09:14:22 +0100The key identifier is that this "Received" header is the topmost one in the chain, its timestamp matches the date the imapsync migration was run, and it typically references "localhost" or the destination server's hostname rather than an external mail server.
Comparing Dates
To confirm the issue, compare the topmost "Received" header's timestamp with the email's "Date" header. If the "Received" header shows January 2025 but the "Date" header shows March 2020, the migration "Received" header is the cause of the wrong date display. This comparison can be done by viewing the raw message source in any email client.
Why Common imapsync Options Do Not Solve the Problem
The --syncinternaldates Flag
imapsync offers the --syncinternaldates flag, which sets the INTERNALDATE on the destination server to match the "Date" header of the email. This is useful when the source server's INTERNALDATE is already wrong, but it does not prevent the destination server from adding a "Received" header. The visible date in Outlook and other clients remains the migration date no matter what the INTERNALDATE is set to.
The --addheader Option
imapsync can add custom headers to messages during migration, but it cannot prevent the destination server from adding its own "Received" header. The IMAP protocol requires servers to record the insertion timestamp, and no imapsync option can override this server-level behavior.
Post-Migration Scripts
Some administrators write custom post-migration scripts to remove the unwanted "Received" headers. This sounds reasonable, especially for the kind of person who chose imapsync in the first place (someone comfortable with the command line). But the reality is far more complex than a find-and-replace on header text. What happens when your script encounters an S/MIME signed email? Or a multipart message with nested MIME boundaries and base64-encoded attachments? Or a header with RFC 2047 encoded non-ASCII characters? A single misplaced byte in a MIME boundary can silently corrupt an entire message, destroying attachments or rendering the email unreadable. And how do you confirm that 10,000 corrected emails are all intact? For thousands of emails across multiple mailboxes, DIY scripting is a substantial risk.
Fixing imapsync Dates with Redate.io
How Redate.io Handles imapsync Migrations
Redate.io's proprietary correction engine is built specifically for this class of problem. After connecting to the mailbox, Redate.io scans every email and runs each message through a multi-stage analysis pipeline. For imapsync migrations, Redate.io detects the server-inserted "Received" header by applying pattern matching across hundreds of known migration signatures, analyzing the complete header chain, and cross-referencing timestamps against the original "Date" header.
This is not a simple header edit. The correction engine handles RFC compliance validation, message structure preservation (including multipart/alternative structures, inline attachments, and Content-Transfer-Encoding variations), and digital signature detection. Emails with S/MIME or PGP signatures are automatically identified and handled appropriately to preserve signature integrity.
What You Get After the Fix
Every corrected email displays its original received date in all email clients. Chronological order is restored. Every fix goes through integrity verification before it's finalized. The original message is moved to a "Redate.io - Originals" folder and kept for 30 days as a safety net.
Compatibility with All Destination Servers
Since imapsync is used to migrate to virtually any IMAP server, Redate.io supports the same breadth of destination platforms. Whether the imapsync migration targeted Dovecot, Courier, Cyrus, Zimbra, Google Workspace, Microsoft 365, or any other IMAP server, Redate.io connects and fixes the dates.
How to Fix Dates After an imapsync Migration
Connect to the Mailbox
Log in to Redate.io and add the mailbox. For Google Workspace or Microsoft 365, use the admin delegation option. For other IMAP servers (which are common in imapsync scenarios), enter the server address, username, and password. Redate.io connects via standard IMAP.
Free Scan
Run the free scan to identify affected emails. The scan report shows the total number of emails, how many have the wrong date, and what migration date was detected. This scan costs nothing and gives a clear picture before any commitment.
Fix and Verify
Select a plan based on the number of affected emails and start the fix. Progress is visible in real time. After completion, verify the results by checking email dates in your client. Dates should be back where they belong.
Platform-Specific imapsync Fix Guides
Frequently Asked Questions
Should I use imapsync's --syncinternaldates before using Redate.io?
It's not necessary. Redate.io sets the correct INTERNALDATE during the fix process no matter what the current value is. Whether imapsync preserved the original INTERNALDATE or not, Redate.io derives the correct value from the original "Date" header.
Can I fix dates on the source server before migrating with imapsync?
If the source server already has wrong dates (from a previous migration), Redate.io can fix them before or after the imapsync migration. But fixing dates on the destination server after migration is the most common and practical approach.
How many emails can Redate.io process?
Redate.io handles mailboxes of any size. Plans are available for up to 100,000 emails per mailbox. For organizations with many mailboxes, Redate.io offers volume pricing.
imapsync migration left dates broken? Start a free scan to see how many emails are affected and fix them with Redate.io.