<DKIM> Maildir -> Restore to IMAP server

[Nicolas Sebrecht]

On Mon, Dec 22, 2014 at 05:23:04PM +0800, Plutocrat wrote:

<...>

> So I looked in the FAQ and saw that the answer lay in the cached
> information. However the solution is to delete the contents of the
> maildir and cache, which is not what I want to do as this is now the
> only copy of the mail!

Not true, AFAIR. While this is the strong way, deleting the cache is
enough. It might be worth to make a backup of the maildir before
proceeding, though.

> So ... what is the correct way to get these mails from the Local
> maildir copy into the new IMAP account? The account owner is standing
> behind me tapping his foot, so I need to figure it out swiftly!

The best way is to let OfflineIMAP recreate its cache according to the
new server, from scratch.

1. Move the maildir directory to maildir.old. Create a new empty
   maildir directory.

2. Delete the cache. OfflineIMAP is now ready to start from scratch as
   if it was its first execution.

3. Run OfflineIMAP once. Now, it has a clean cache and a fresh maildir
   content.

4. Then, we want to copy the content (your raw mails) from maildir.old to
   maildir. Compare the trees between the old and new maildir before
   copying.

Depending of what was done while migrating the IMAP server, your might
find the exact same trees or not. If not, there two alternatives:
- tune your OfflineIMAP configuration to have the new tree matching the
  old one. This requires deleting the maildir and re-sync to not have
  unexpected upload sync due to changed nametrans rules or whatever.
  This is the hard way.
or
- manually copy the emails from the old maildir to the new maildir on a
  per-folder basis. This should be the easy way.

5. Re-sync. The local mails are synced back to the server.

> Is there a way to force the sync? 

No. It does not make sense to "force" a sync.

>                                   Is there a way to specify the
> direction of the sync?

Yes, but it does not match this use case. Specifying a direction is made
by turning either side as read-only. This is clearly not what you want.
This feature was introduced for other use cases.

>                        What have I mis-understood?

I don't know. Here are some general backgrounds for better
understanding. If additional explanations are required, asking is
welcome.

The cache is related to both server and local emails sync states. The
only supported changes for sync to work as expected are from a "normal"
use. This includes adding/deleting emails, change flags on them, etc.
IOW, anything expected from a usual work on _mails_. 

If an "unexpected" change happen (outside basic mail operations
described above), advanced manual steps are required. They come with
IMAP server tuning/migration, local changes like nametrans tuning (which
impact the tree of the local maildir), etc.

Emails are the raw data. Copying them from one maildir to another should
always work without loosing any data.


As a side note, I'm not surprised you've hit "weird" behavior.

OfflineIMAP is fast and flexible but it has a cost.  UID validity
problems and tree changes (from server or local) are good examples of
OfflineIMAP's limitations: the software won't run as expected with
changes of "context".

While this is true for almost any IMAP client outside, OfflineIMAP comes
a bit more limitations than others in this area.

The good point is that the OfflineIMAP's way of working is simple enough
and maildir format is well-known (and very simple, too). So, the
additional manual steps to come back to normal are not much harming with
minimal knowledge.

Have fun,

-- 
Nicolas Sebrecht