On 03/14/2012 02:11 PM, Paul J Stevens wrote:
The problem is that dbmail don't assign UID according to UIDNEXT
prediction, so imapsync's cache is wrong, and if I rerun the
synchronization the old messages and deleted and transferred again.
So imapsync is broken! Look at this excerpt from RFC3501, and especially
the Note:
Unless the unique
identifier validity also changes (see below), the next unique
identifier value MUST have the following two characteristics. First,
the next unique identifier value MUST NOT change unless new messages
are added to the mailbox; and second, the next unique identifier
value MUST change whenever new messages are added to the mailbox,
even if those new messages are subsequently expunged.
Note: The next unique identifier value is intended to
provide a means for a client to determine whether any
messages have been delivered to the mailbox since the
previous time it checked this value. It is not intended to
provide any guarantee that any message will have this
unique identifier. A client can only assume, at the time
that it obtains the next unique identifier value, that
messages arriving after that time will have a UID greater
than or equal to that value.
You're right, but there is any particular reason to not assign the UID
as predicted?
By the way, offlineimap works correctly with UID, it add a string
"X-OfflineIMAP" to the header of the original message, and after the
message has been transferred it ask the server to know the UID of the
message containing such string, so the transferred message is not
identical to the original...
Thanks,
Emiliano
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail