Lorenzo Perone writes:
This is: Apple Mail makes an SQLite database with metadata about messages, to display them faster. This database gets screwed up regularly, I have to delete it and let it rebuild. I'm trying to track down the problem to make an appropriate bug report and/or verify that it's not my courier configuration that has something wrong.
There's absolutely nothing in the Courier configuration that could possibly have any impact on the internal workings of an IMAP client.
The IMAP server does not read or write to this database file itself. The only application that does this, based on your description, is Apple Mail. It is the only application that reads or writes to this database file, and it's solely responsible for its contents.
I'm asking about some hints regarding the IMAP synchronisation: What are courier's message IDs based on? The Apple Mail database maintains a "remote_id" which in 90% seems to be an integer, in some it looks more like an md5, and there are even some other examples where it looks completely different.
There is no entity named "message ID" that's related to IMAP. The "Message-ID:" header in individual mail messages are set by the sending mail client. IMAP servers do not touch them, just pass them along, as is.
The protocol-specific message identifiers in IMAP -- there are two of them -- are called UID and UIDV (or UID validity). Their semantics and behavior are stricly defined by IMAP. Basically, they are numerically increasing integers.
If you are seeing something that's not an integer value, it is not an IMAP UID or UIDV.
Although I haven't seen it happen on mails hosted on other servers than courier, this must be a client problem, since it's the client's DB screwing up,
Correct, this is a key point.
So my question is: are there possible ID-concurrency scenarios in the IMAP protocol and/or in courier, which could be bad-interpreted or badly-used by $%##$(@ software like Apple Mail, in an effort to match them with a local store? Can the server filesystem play a role in this or any local server software such as fam and Co.?Thanks a lot for reading this, it's really driving me nuts lately...
It is true that in many parts of the specification, IMAP permits a great deal of leeway to both servers and clients. Mostly servers, but on the client side too, to some extents. Basically, IMAP says that the server may do this, that, or the other, in such and such situations, and IMAP clients must be prepared to handle all possibilities.
What often happens is that an IMAP client gets tested only against some particular IMAP server, and the IMAP client developer overlooked the fact that the protocol permits IMAP servers to process things differently, and due to insufficient testing does not end up working with some IMAP servers. Then, the IMAP client developer or the user blames the server: see, the client works with another IMAP server, but not with this one, so this IMAP server must be broken. Not true.
There are quite a few instances where IMAP allows both servers and clients to behave differently in this manner. I hold a belief that this is a design defect in IMAP. But that's a different conversation.
One very common grey area of this kind, for example -- and this is just one example -- has to do with one IMAP session opening a folder in a mailbox, and a second concurrent IMAP session adding a new message to the same folder. Someone who's not very familiar with IMAP might expect the new message to be immediately visible in the first session. This is not true. An IMAP server is allowed to send an untagged EXISTS message immediately to the first session, a notice that the number of messages in the folder has changed. However, this is not required, and an IMAP client may have to send a NOOP command in the first session, triggering "new mail processing", before the newly-added message is visible in the first session. An IMAP client that attempts to access the first message blindly, expecting it to be there, will then get an expected error code, and break.
I have no idea if this would be the root cause of your problems. This is just an example of a possible issues.
pgpIV5XopQEUz.pgp
Description: PGP signature
------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
