Hi Sam, Thanks A LOT for taking your time to answer. And yes, it helps to narrow down a bit, at least that's in the old-style-kinda-deterministic approach to software which I like to attempt first...
On 12.07.10 23:09, Sam Varshavchik wrote: >> 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. Yes, as said... I believe it's a very bad client (at least by some respects. search is - when it works - much faster than thunderbird's), the problem is it's the default client on macs - a bit like making websites work with IE, it's dreadful. In addition, some mac users really stick to things with an apple on it even when it hurts. > 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. Hearing this from you is, to say the least, authoritative :-) > 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. Thanx, I'll try to track them down the pipeline server-client-database... > 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. Thanx for this brief and concise excerpt. It certainly helps understanding! One question: Is the option IMAP_ENHANCEDIDLE=1 in etc/courier/imapd likely to make things better? If yes: I had to disable it until now because of many errors in maillog/syslog (sorry for this, just can't find the exact error message right now, but it was some call to check if a maildir had changed). I'm using gamin under FreeBSD (default on the courier 0.63 port). Is fam more appropriate than gamin? Thanx a lot! Regards, Lorenzo ------------------------------------------------------------------------------ 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
