Looks like a bug to me: Dovecot ignores Maildir/new timestamp

[Timo Sirainen]

> On 01 Dec 2015, at 12:30, Fredrik Roubert <fredrik at roubert.name> wrote:
> 
> Hello!
> 
> I run Debian jessie and have an issue with the interaction between
> Dovecot (2.2.13), Mutt (1.5.23) and the Android Gmail (5.8.105868218)
> IMAP client, when using Maildir:
> 
> I use Dovecot LMTP for local delivery into Maildir and access these
> files both through Dovecot IMAP from the Android Gmail IMAP client and
> also directly through the filesystem by running Mutt locally on the mail
> server.
> 
> When a new mail arrives, Dovecot LMTP will add a new file in Maildir/new
> and also update the Dovecot index cache. If I then open Mutt and just
> delete this new message, then Mutt will just delete this file from
> Maildir/new and the Dovecot index cache will be out-of-sync.
> 
> (For testing, Mutt can be cut out of the equation entirely by instead
> just running "rm Maildir/new/*" from the command line to mimic what Mutt
> does when deleting a new message, but I mention the use of Mutt here to
> show why this is a real use-case for me.)
> 
> If I after this open the Gmail app and pull down the message index to
> refresh from the Dovecot IMAP server, it'll get the cached version of
> the index, in which the new message is still present (but only the
> headers, no body will be loaded and the app will show no body snippet).
> Pulling down the message index again to force a second refresh will
> cause the new/deleted message to disappear again.
> 
> This seems to be caused by Dovecot not looking at the Maildir/new
> timestamp to determine whether the index cache is up-to-date, but
> instead only looking at the Maildir/cur timestamp.

Dovecot does check Maildir/new timestamp, but it'll only perform a "partial sync" then, which means it adds any newly found mails but it doesn't delete any mails because it can't be sure that they weren't moved to cur/. One simple fix for this would be to scan cur/ also whenever new/ changes, but that would unnecessarily make the performance worse for most people. Another fix would be to remember that the mail was in new/ and when cur's timestamp hadn't changed and the mail wasn't in new/ anymore it would be removed from index. But this would require remembering that the mail is in new/, which isn't currently done and adding it would probably cause extra disk writes.

So I don't really see a way of fixing this in any nice way.