[kmail2] [Bug 417206] KMail wrong date in IMAP APPEND command

[kernel_panic]

https://bugs.kde.org/show_bug.cgi?id=417206

--- Comment #8 from kernel_panic <vic.m.ivanov at gmail.com> ---
(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.