On Tue, Apr 8, 2008 at 1:11 AM, Oswald Buddenhagen - [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Mon, Apr 07, 2008 at 10:29:54PM -0500, [EMAIL PROTECTED] wrote: > > Any chan[c]e mbsync will join the elite list of imap clients that can > > give gmail the correct date & time? > > > maybe ... i'd appreciate it if you google for the correct > hack^Wsolution.
I tried, but I couldn't find a solution. The closest thing I could find is the info below from the RFC. If I read this right setting the date and time to the email header's date/time actually breaks the RFC? If so then I guess, while less useful, mbsync is actually correct in the way it behaves. Of course I'm still all in favor of breaking the RFC and setting the date/time to email header date/time. The append operation sounds like the most likely culprit, but I'm sure all this is nothing new to an IMAP master: http://tools.ietf.org/html/rfc3501#section-2.3.3 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. http://tools.ietf.org/html/rfc3501#section-6.3.11 If a date-time is specified, the internal date SHOULD be set in the resulting message; otherwise, the internal date of the resulting message is set to the current date and time by default. http://tools.ietf.org/html/rfc3501#section-6.4.7 The COPY command copies the specified message(s) to the end of the specified destination mailbox. The flags and internal date of the message(s) SHOULD be preserved, and the Recent flag SHOULD be set, in the copy. > > Now for something completely different. Is the project name ever > > going to be changed to mbsync? IMHO the isync name doesn't provide > > much value to a newbie. Just try googling for "isync" and see how > > many non-apple results you get. :) > > > yeah, it doesn't really help that our trademark is older ... > problem is, mbsync is sort of taken, too (at least in france). i guess > i should ask them what they think about a project rename. > maybe i should make a naming contest. dump your ideas here: > -=>> [this place] <<=- :-D How bout "realulimateimapsyncpower"? That's probably not used. :) Thanks, Jim ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel
