Looking at the IMAP4rev1 protocol (RFC 2060), we have the following definition:
INTERNALDATE The internal date of the message. 2.3.3. Internal Date Message Attribute
The internal date and time of the message on the server. This is not the date and time in the [RFC-822] header, but rather a date and time which reflects when the message was received. In the case of messages delivered via [SMTP], this SHOULD be the date and time of final delivery of the message as defined by [SMTP]. In the case of messages delivered by the IMAP4rev1 COPY command, this SHOULD be the internal date and time of the source message. In the case of messages delivered by the IMAP4rev1 APPEND command, this SHOULD be the date and time as specified in the APPEND command description. All other cases are implementation defined.
How could any implementation of this protocol possibly use a file system time stamp to represent that important piece of meta-data, no matter where the file lives? It seems totally reasonable that this is what Outlook uses for the Received date (and I rarely defend Microsoft).
This seems like a real design flaw in the dovecot implementation. I am fairly new to dovecot (and like many aspects of it over uw-imap), but having to really be careful with my mail store's mtimes borders on the absurd. I realize it is "implementation defined", but the intent of the definition surely does not refer to file system time stamps. Any chance this can be reconsidered? Is this an actual dovecot issue or a more general Maildir issue?
On Fri, 2008-07-18 at 02:00 -0700, dovecot-request@dovecot.org wrote:
Message: 4 Date: Thu, 17 Jul 2008 23:12:55 +0300 From: Timo Sirainen tss@iki.fi Subject: Re: [Dovecot] changing INTERNALDATE or similar To: richs@whidbey.net Cc: Dovecot Mailing List dovecot@dovecot.org Message-ID: 1216325575.31765.349.camel@hurina Content-Type: text/plain; charset="utf-8"
On Thu, 2008-07-17 at 13:04 -0700, richs@whidbey.net wrote:
I believe it's still true that any mail files that are IMAP STORE'd (uploaded)
You mean IMAP APPENDed.
to Dovecot by a client will have a current mtime, rather than the "Date" in the message. That means might need to compare mtime's to "Date" headers for new files that appear too.
This is only because the client doesn't specify the date to APPEND command.
Here we just patched Dovecot to treat "INTERNALDATE" the same as the "Date" header. Constantly verifying mtime's became too much of a chore for those clients that rely on it (although this technically is against the RFC).
Would probably have been better to set the default INTERNALDATE based on the Date: header in APPEND command. Should be pretty easy to do with Maildir I think.