Paul F. De La Cruz wrote:
RFC-3501 (IMAP4rev1) says...
2.3.3. Internal Date Message Attribute
The internal date and time of the message on the server. This
is not the date and time in the [RFC-2822] header, but rather a
date and time which reflects when the message was received. In
the case of messages delivered via [SMTP], this SHOULD be the
date and time of final delivery of the message as defined by
[SMTP]. In the case of messages delivered by the IMAP4rev1 COPY
command, this SHOULD be the internal date and time of the source
message. In the case of messages delivered by the IMAP4rev1
APPEND command, this SHOULD be the date and time as specified in
the APPEND command description. All other cases are
implementation defined.
So I'm figuring that means local to the server. I'm wondering if the
mail client is supposed to be dealing with the offsets or what. Seems
if it was given in GMT, then the mail client should just compensate for
the time zone the person is in? What mail client are you using Blake?
It looks likes the people who wrote the rfc assumed the server would
always be in the same time zone as the client...
We've had the same kind of trouble here, but even worse..: Apple Mail
(Mac OS X) would always display the Internal Data one hour in the future.
So a message arriving at 10:00AM would be displayed as having arrived
at 11:00AM. What seems to be the problem in this case is that Apple Mail
decided that mailservers should all have GMT internal time (we're at
GMT+1 here), and should compensate for that itself (without the
possibility of changing, unless you'd want to set the timezone zone
to GMT for your whole desktop...)
Anyway, switching to Mozilla Thunderbird fixed the problem :)
To conclude, I guess this is a pretty fundamental problem, which
cannot simply be dealt with by changing the timezone to GMT on your
server, because that will break some clients that are happily working
right now.
Ilja
