[Akonadi] [Bug 417206] KMail wrong date in IMAP APPEND command
bugzilla_noreply at kde.org
Tue Sep 8 15:32:05 BST 2020
--- Comment #12 from kernel_panic <vic.m.ivanov at gmail.com> ---
(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.
More information about the Kdepim-bugs