https://bugs.kde.org/show_bug.cgi?id=417206
--- Comment #3 from Erik Quaeghebeur <[email protected]> --- (In reply to kernel_panic from comment #2) > […] I was beginning to lose hope that this > would ever be picked up […] I think that if we want this to be picked up, it would help if we can at least point out in the code where the issue lies. This is filed in the product kmail2, but it could be an akonadi or kimap issue. I think kimap can be excluded, because it clearly provides functionality for setting the INTERNAL DATE: https://invent.kde.org/pim/kimap/-/blob/release/20.04/src/appendjob.cpp (This was also apparent from your initial report.) AFAICT from the Akonadi database structure, it only has a concept of * last access time * datetime, which seems to correspond to last *modification* time (I do not know which modifications count: flags, tags, …?). For sure changing the message's MIME structure counts, for the issue I encounter. So if I'm correct it has no concept that maps to INTERNAL DATE. That means that upon append to an IMAP store from an IMAP store, the code that appends must explicitly include a call to the original IMAP store to get the INTERNAL DATE and use it upon append. Further investigation is necessary. -- You are receiving this mail because: You are the assignee for the bug.
