[Dovecot] Deleting messages from MailDir

[Benjamin R. Haskell]

On Wed, 13 Feb 2008, Rody wrote:
> Op woensdag 13 februari 2008 00:43, schreef Bill Cole:
>> Yes, but you may also care that ctime is reset when a client has
>> Dovecot move a message from one subfolder to another within a
>> Maildir. I'm not sure why Dovecot does it, but a look at the messages
>> in the non-INBOX parts of my Maildir reveals that the ctime is always
>> later than the mtime, and the contents (Received headers) makes it
>> clear that Dovecot sets the mtime of messages to the original mtime
>> (i.e. original delivery time) when copying them.
>>

I think the answer to "why Dovecot does it" is actually that Dovecot 
doesn't do anything with ctime. Under most *nix filesystems, ctime is the 
last time the inode underlying the file/dir was changed ('c' for 
"changed", not "created" -- [usually]). The inode gets changed when the 
file's moved from one directory to another.


>> Hopefully Timo will speak up on this, but I have a vague recollection
>> of him saying that Dovecot never modifies message contents as a
>> matter of principle, and it seems to me that the design of Maildir
>> assumes that the mailstore server follows that principle rigorously.
>> That should make mtime quite static for an individual file, and it
>> looks to me like Dovecot even makes an effort to preserve the
>> delivery time of a message by replicating the mtime from the original
>> file to the new one when copying a message between subfolders.

The delivery time can also be determined by the first part of the Maildir 
filename of the message:

e.g. ls -l 1202878863.24522_1.myhost:2,
--rw------- 1 user group 551 2008-02-13 00:00 1202878863.24522_1.myhost:2,

The 1202878863 part is the Unix timestamp corresponding to midnight, Feb 
13, 2008 EST. So, it's not really a requirement of Maildir's design to 
keep the mtime updated. It's just easier+quicker than parsing the number 
out of the filename (where it *is* a requirement).


> [...] It looks like the use of ctime or mtime depends on wether you want 
> the message removed x days after it was moved to say the trash folder 
> (ctime) or will be removed x days after it originally arrived in the 
> inbox (mtime). My personal opinion is currently that i would like it 
> removed x days after it was placed in a certain folder, hence i use 
> ctime.

Depends on the context for me. If it's in a spam folder, I'd rather not 
keep it around any longer than it'd take for someone to say "Hey, didn't 
you get that?". So -mtime +13 (2 weeks from receipt). (Thanks for the 
heads-up on +13 vs. +14, btw).

Trash on the other hand, seems like you'd want X to be "about a month" in: 
"Oh, no! I accidentally deleted that thing X ago!", since messages tend to 
stick around for a while in the INBOX. (Note the difference: "Oh, no! I 
accidentally deleted that thing that *arrived* X ago!".) So, -ctime +30 
(trashed more than a month ago).

Another consideration for ctime is that changing a message's flags 
(/keywords) alters its ctime (since the underlying operation is a rename, 
which alters the inode). (Not sure where that might come into play in the 
spam/trash examples, but it might be good to know.)

Best,
Ben