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

[kernel_panic]

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

--- 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.