https://bugs.kde.org/show_bug.cgi?id=417206
--- Comment #8 from kernel_panic <[email protected]> --- (In reply to Erik Quaeghebeur from comment #5) > TBH, I cannot reproduce your issue. When I move messages between IMAP > accounts on different servers, they keep their INTERNAL DATE. I've tried > with related(plain,image) and > alternative(plain,related(html,image,image,image)) messages. I think whether the issue is de-facto observed is also dependent on the implementation of the server and its RFC compliance. For example, GMail uses the timestamp provided in the APPEND command to store, index, and display messages in its web interface. This timestamp may be different to the one provided in the message header. However, it appears that this timestamp is stored separately (presumably in some indexing database) since the original message's Date header is left intact and showing the correct timestamp. Consequently, the messages with their correct timestamps in a mail client (e.g. KMail or Thunderbird) which use the Date headers for indexing, but are completely messed up in GMail's web interface. On my private mail server, which uses Postfix and a simple Mbox format for storage and indexing, the message's internal Date header is always used. I don't recall explicitly configuring this but it appears that it is interpreting the "SHOULD" clauses in the RFC slightly differently. Going back to the RFC section quoted above, I think I may have misinterpreted what it actually means. Notably, it only concerns mail /servers/ and not mail clients. It seems that if a timestamp has been specified in the APPEND command the server SHOULD use that timestamp and it SHOULD supersede any internal message timestamp (e.g. Date header). Moreover, it SHOULD overwrite said internal timestamp. Likewise, if a timestamp is not provided, the server SHOULD use the current date/time and set the message's internal timestamp to that one. So, in that regard, it would appear GMail's implementation is at least partially conformant wrt its web interface and how it indexes the messages there. But I don't see any section of the RFC that concerns clients issuing the APPEND command. In either case, my view is that it would make sense for clients, by default, to use the message's internal timestamp - if present - in all instances so as to avoid the above issue. From my mini-analysis, Thunderbird does that. And KMail also does this in most cases. So it seems it's only the small set of cases where this isn't done that are of concern. I'll see if I can narrow down when else this might occur. So far, the easiest way to consistently reproduce the issue is with filters (e.g. PGP encrypt and/or decrypt) which pushes an encrypted copy of the message to the IMAP server before deleting the old copy from the IMAP server. -- You are receiving this mail because: You are the assignee for the bug.
