Migrate emails to new server but prevent Outlook from re-downloading them

0

I have a sendmail server that is nearing end-of-life. I need to move all email accounts to a new server (postfix), but I don't want Outlook users to re-download all their existing messages after the migration the next time they hit Send/Receive.

TEST CASE: As a test, I created a mail account on old server, sent some messages to it, then connected using Outlook (POP) and downloaded the messages. Then I closed Outlook and ensured the outlook.exe process was NOT running.

Next I created an identical email account on the new server (same email address, username, and password) and used imapsync to synchronize with old server.

I added an entry in the c:\windows\system32\drivers\etc\hosts file on the box running outlook, to point the domain to the new server.

I reopened Outlook and hit send/receive. Outlook re-downloaded all the messages, so they appear as duplicates in the Outlook inbox.

TL;DR: How can I prevent Outlook re-downloading existing messages after migrating the mailboxes to the new server?

Any help appreciated!

Ryan Griggs

Posted 2016-04-01T03:24:04.537

Reputation: 682

It seems you didn't do research on proper migration and just winging it by creating a new one http://serverfault.com/questions/61555/migrating-sendmail-mailboxes-to-postfix

– SeanClt – 2016-04-01T03:59:05.453

I don't want to keep the old MBOX single-file structure. The new server is not actually new: it is already running postfix with lots of mail accounts in the Maildir format. So I want to import the mailboxes from the old server, converting them to maildir format. Obviously there's some sort of identifier that Outlook uses to determine if the message has been downloaded already, but I don't know what this is. Can you assist? – Ryan Griggs – 2016-04-01T04:16:30.040

FYI imapsync seems to be the recommended method of mailbox migration. So I'm simply trying to understand why Outlook re-downloads all the messages... IMAP works fine, including folders and read/unread status. – Ryan Griggs – 2016-04-01T05:02:51.950

I'm looking into dovecot dsync but since the two servers are running different versions of Dovecot, I'm not sure that will work. It looks like the UIDL must be preserved on each imported message. See http://wiki2.dovecot.org/Migration/Dsync

– Ryan Griggs – 2016-04-01T06:05:45.127

Also it says you need dovecot 2.1.4+ and the newer server is only running 2.0.x, without a clear upgrade path to 2.1 (Centos 6). – Ryan Griggs – 2016-04-01T06:07:50.857

Ask Outlook to sync the mailbox with the server. You first use POP3 protocol to download some messages, you leave them on the server I suppose. Then you use IMAP to sync this account. It seems you confound SMTP protocol (sendmail, postfix) and POP IMAP protocols, all are different. Can you make your context clearer? – Gilles LAMIRAL – 2016-04-01T09:11:19.703

Hi Gilles, the old server contains many email boxes. They are in MBOX format, and using Dovecot as the POP/IMAP server. Our customers are connecting to these mailboxes through Outlook. Some customers use IMAP and some use POP, leaving messages on server per Outlook settings. I do not want customers to have to reconfigure their Outlook settings after the transfer. I want it to continue working seamlessly. I don't want Outlook to re-download all messages currently left on the server. So I must ensure their UIDs stay the same. (See POP UIDL command) – Ryan Griggs – 2016-04-01T18:56:15.950

UIDs are given by servers so you can't fix them with any client. – Gilles LAMIRAL – 2016-04-01T21:51:29.717

According to the Dovecot documentation, the dsync utility preserves UIDs to avoid re-download by Outlook. Please see this page: http://wiki2.dovecot.org/Migration/Dsync A direct quote: "The pop3-migration plugin is used to preserve POP3 UIDLs"

– Ryan Griggs – 2016-04-02T21:32:12.980

I figured out how to do this. See my answer here http://serverfault.com/questions/768580/migrate-dovecot-0-99-to-dovecot-2-x-and-preserve-pop-uids/774855

– Ryan Griggs – 2016-05-04T17:13:52.563

No answers