[Dovecot] Deleting messages from MailDir

[Bill Cole]

At 12:25 AM -0500 2/14/08, Benjamin R. Haskell  imposed structure on 
a stream of electrons, yielding:
>On Wed, 13 Feb 2008, Bill Cole wrote:

[...]

>>Maildir DOES NOT require a timestamp in the filename, it's just common.
>>
>
>DJB's Maildir spec isn't RFC-esque (so it's not a MUST, in that 
>sense). As far as I've seen, everything does what's described below. 
>But, like you say, not a requirement. I think I skipped over the 
>second and third sentences from this excerpt from 
>http://cr.yp.to/proto/maildir.html (because of the first sentence) :
>
>[""
>Unless you're writing messages to a maildir, the format of a unique 
>name is none of your business. A unique name can be anything that 
>doesn't contain a colon (or slash) and doesn't start with a dot. Do 
>not try to extract information from unique names.
>
>Okay, so you're writing messages. A unique name has three pieces, 
>separated by dots. On the left is the result of time() or the second 
>counter from gettimeofday().
>""]
>
>Also note that that snippet expressly warns against doing what I 
>said could be done (parsing the timestamp out of the filename).

Yeah, and I did a little more research and am now less sure that it 
is *safe* to not use the timestamp. I would not be shocked if 
something out there working with Maildir/Maildir++ requires it, given 
the fuzzy spec(s)

Incidentally, some other illuminating docs are:

http://www.qmail.org/man/man5/maildir.html
http://www.inter7.com/courierimap/README.maildirquota.html



>I'm curious: do you have examples of mail software that doesn't use 
>the timestamp? (I could see some run-once script not doing it, but 
>I'd be surprised if widely-used software didn't.)

The procmailrc man page says that MSGPREFIX defaults to 'msg.' but it 
is not clear to me whether MSGPREFIX is used for Maildir delivery or 
just for MH delivery. I've played it safe and use "MSGPREFIX=`date 
+%s`" but maybe that's not needed...


>>On my system, the timestamps in the filenames match the ctime, NOT the
>>mtime:
>>
>>~/Maildir/.Tagged/cur $ ls -lcrt |tail -1
>>-rw-------   1 wkc  staff    13293 Feb 12 23:45 
>>1202877918.P26840Q0M183345.toaster.scconsult.com:2,S
>>~/Maildir/.Tagged/cur $ ls -l 
>>1202877918.P26840Q0M183345.toaster.scconsult.com\:2\,S
>>-rw-------   1 wkc  staff  13293 Feb 12 23:43 
>>1202877918.P26840Q0M183345.toaster.scconsult.com:2,S
>>~/Maildir/.Tagged/cur wkc$ uepoch 1202877918
>>1202877918 is Tue Feb 12 23:45:18 2008
>>
>>The earlier mtime matches the delivery time.
>>
>
>I think it'd generally be the case that the filename timestamp will 
>match the *initial* ctime (before any possible ctime changes), since 
>that should be synonymous with creation time. And, mtime could vary, 
>because Dovecot syncs the mtime to the delivery time.

It seems that Dovecot maintains the mtime as the original delivery 
time of the message, i.e. delivery to the INBOX.
It seems that Dovecot names files based on when the specific file 
(i.e. in that maildir folder/subdirectory) was created.

>But, I still don't quite follow your example. Call the mailfile X 
>(so I don't have to type it):
>
>ls -lc X shows 23:45 - so, ctime = 23:45
>ls -l X shows 23:43 - so, mtime = 23:43
>And, the filename timestamp == ctime.
>
>But, you say the mtime matches the delivery time.

Yes, it does.


>So, the filename timestamp is two minutes *after* the delivery time?

Yes.

>Did it take your LDA two minutes (or at least 1 min 19sec) to get 
>the message from the MTA to the Maildir?


No.

It took 2 minutes for a MUA (Eudora) to see the message and tell 
Dovecot to move it to the "Tagged" IMAP folder (i.e. the .Tagged 
subdirectory)

>Also, I think (but, maybe not on HFS+) there'd be a ctime change on 
>renaming the file from X to X,S (adding the 'Seen' flag). Do you 
>know whether that's the case?
>
>(e.g. try:)
>touch foo
>ls -lc foo
>mv foo foo,S
>ls -lc foo

No need to touch, as I had a foo hanging around with a usefully aged 
ctime that would be visible if it changed:

~ $ ls -l foo
-rwxr-xr-x   1 wkc  wkc  332 Jan 29 03:32 foo
~ $ ls -lc foo
-rwxr-xr-x   1 wkc  wkc  332 Jan 29 03:32 foo
~ $ mv foo foo,S
~ $ ls -lc foo,S
-rwxr-xr-x   1 wkc  wkc  332 Jan 29 03:32 foo,S


Again, this is *HFS+* so it's goofy.

On Solaris UFS and VxFS 'mv' changes ctime. I'd bet on ext{2,3} 
behaving similarly.


>>>>[...] 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. [... blah blah. Me blabbering...]
>>
>>Again, that is FS-specific, and HFS+ is again a counter-example.
>>
>>(one can argue that HFS+ is Bad and Wrong in many ways, but it is 
>>in widespread use...)
>>
>
>I guess the take-home message is that ctime isn't quite as 
>consistent cross-filesystem as mtime. But, I still think ctime has 
>its place in non-"Bad and Wrong" filesystems.

I think a case could be made to support the HFS+ behavior IFF you 
ignore 20 years of Unix FS behavior.
#include applebugsme.h

The diversity of timestamps is useful to support a diversity of 
reasonable policies. It seems that Dovecot works to preserve the 
initial delivery time (as mtime) and that even on a filesystem where 
rename() does not update ctime, the way Dovecot handles MUA-initiated 
message moves assures that the ctime and the (new) filename both 
reflect the move time.


>And, as Charles pointed out, in Dovecot 1.1 there's a plugin to do 
>this. Does the expunge plugin work without the user logging in, 
>though? (not that that's an enormous problem -- more curiosity)

A lot of this is mostly about curiousity...


-- 
Bill Cole                                  
bill at scconsult.com