What's the proper netiquette for this? Zap the replies deeper than 2 or 3 '>'s or just keep leaving notes at the top that the real message is at the end of the yellow brick road? Perhaps we could all agree to reply on top... ;-)
Aaron ""Paul F. De La Cruz"" <[EMAIL PROTECTED]> said: > > reply below.. :D > > On Sat, Mar 20, 2004 at 10:38:06AM -0000, Aaron Stone wrote: > > Ilja Booij <[EMAIL PROTECTED]> said: > > > > > > > > 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 > > > > Is it possible that the times can all be marked as GMT, and that local > > server > > time, when used to stamp received messages, also be converted to GMT? That > > way, it becomes entirely encumbent upon the mail client to show the GMT date > > in the user's local time. IIRC, the time format specified by RFC 2/822 has > > an > > optional time zone field (haven't read it recently, though). > > > > Aaron > > Yep, GMT is specified as +0000 hmm... interesting idea. > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > --
