https://bugs.kde.org/show_bug.cgi?id=417206
--- Comment #12 from kernel_panic <[email protected]> --- (In reply to Erik Quaeghebeur from comment #10) > (In reply to kernel_panic from comment #8) > > 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. […] > > I think there is a misunderstanding. The INTERNAl DATE is *not* the same as > the Date header value and it should not be according to the RFC. (Usually, > it will be close, but can differ significantly[*] if message delivery is > delayed.) Please read https://tools.ietf.org/html/rfc3501#section-2.3.3 for > a description. > > GMail does follow the RFC here AFAICT and uses the ‘REFS’ threading option. > (As does, e.g., Fastmail.) > > [*] So that order of mails in a thread differs based on INTERNAL DATE or > Date header. I was aware of the difference, though admittedly I may have been using "internal" a bit more loosely then I should have - it has been a while since I last properly referred to the RFC. Thanks for pointing this out. In any case, as I mentioned, the RFC does not seem to specify how clients ought to pick the timestamp they supply to the APPEND command - if they wish to do so. I suspect, from an IMAP client perspective, the "internal" date can only be inferred from the "Received" header for the final destination. Alternatively, the "Date" header ought to suffice. -- You are receiving this mail because: You are the assignee for the bug.
