Dovecot supports SAVEDATE IMAP extension [1]. This is however not implemented correctly for Maildir storage.
Compared to "internal date", "save date" is supposed to be the same but well-defined for APPEND and preserved when COPY command is used.
However, for Maildir storage INTERNALDATE is implemented using mtime (modification timestamp) and SAVEDATE is implemented using ctime (status change timestamp) [2]. ctime is changed even more often than mtime. For example, chown or chmod operations on the message change its ctime, but preserve its mtime.
Dovecot should instead use btime (creation timestamp) when it is available and not implement SAVEDATE at all if there is no btime.
Just one example of the message in Maildir:
stat 1708031310.M769290P3712350.nine,S=7898,W=8002:2,Sa File: 1708031310.M769290P3712350.nine,S=7898,W=8002:2,Sa Size: 7898 Blocks: 16 IO Block: 4096 regular file Device: 9,2 Inode: 7864351 Links: 1 Access: (0600/-rw-------) Uid: ( 999/ vmail) Gid: ( 996/ vmail) Access: 2024-02-16 08:34:04.374097798 +0100 Modify: 2024-02-15 22:08:30.769813368 +0100 Change: 2024-02-21 13:39:14.878163244 +0100 Birth: 2024-02-15 22:08:30.769813368 +0100
Its Birth date (btime) and Modify date (mtime) are the same, but Change date (ctime) was changed, likely by someone doing chown/chmod manually.
You can read more in the issue [3] where we have problems with incorrect INTERNALDATE and investigated the possibility of using SAVEDATE, but found that it is not implemented correctly and is changed even more often than INTERNALDATE. According to the standard it should be the other way round, SAVEDATE should be more stable and survive COPY.
[1] https://www.rfc-editor.org/rfc/rfc8514.html [2] https://github.com/dovecot/core/blob/93eb0663336b17f66a67324de43e64bf0bc796c... [3] https://github.com/deltachat/deltachat-core-rust/issues/5339
On 19. Mar 2024, at 0.43, Alex via dovecot dovecot@dovecot.org wrote:
Dovecot supports SAVEDATE IMAP extension [1]. This is however not implemented correctly for Maildir storage.
Compared to "internal date", "save date" is supposed to be the same but well-defined for APPEND and preserved when COPY command is used.
However, for Maildir storage INTERNALDATE is implemented using mtime (modification timestamp) and SAVEDATE is implemented using ctime (status change timestamp) [2]. ctime is changed even more often than mtime. For example, chown or chmod operations on the message change its ctime, but preserve its mtime.
Dovecot should instead use btime (creation timestamp) when it is available and not implement SAVEDATE at all if there is no btime.
ctime is not perfect, but I don't think it's completely unusable either. Normally mail files aren't being chmod/chowned. More troublesome is that message flag changes result in renaming the file, which changes ctime. Also it rather depends on what the SAVEDATE is used for whether this is a problem or not. The main reason SAVEDATE exists is for Dovecot to implement mailbox { autoexpunge } setting so mails moved to Trash can be deleted N days after they were moved there. For this purpose the current implementation is okay enough.
In any case btime would not be correct, since it would not change when copying/moving mail between folders. That is its most important purpose.
I guess we could hide the SAVEDATE capability if none of the configured mailbox formats support it perfectly.
You can read more in the issue [3] where we have problems with incorrect INTERNALDATE and investigated the possibility of using SAVEDATE, but found that it is not implemented correctly and is changed even more often than INTERNALDATE. According to the standard it should be the other way round, SAVEDATE should be more stable and survive COPY.
I don't see why you say it should be more stable. INTERNALDATE is entirely stable and never changes once mail is saved, as long as someone doesn't go poking the mails directly in the filesystem. SAVEDATE always changes on COPY/MOVE.
participants (2)
-
Alex
-
Timo Sirainen