Mark Constable writes:
On 02/04/15 09:52, Sam Varshavchik wrote: > Next, someone pointed out the fact that the client should not assume that > the client will get a UIDNEXT. This was explicitly documented: "If this is > missing, the client can not make any assumptions about the next unique > identifier value". So clients should be prepared to deal, gracefully, with > the absence of the additional messages. >> After this was pointed out there were two basic options: 1) Deal with it, 2)> Reach out and inquire about the possibility of implementing the additional > messages. The option chosen was a variation of doing #1, and then throwing > an temper tantrum.No doubt a lack of IMAP expertise on their end and that the Kolab folks (where there is some expertise) seem to depend on cyrus, and most other people seem to use the postfix/dovecot combination. So are you saying if they tried 2) above that you may have been responsive with either workaround suggestions (for them) or even some future potential courier-imap modifications? If so then may I point to this thread in a KDE bugreport?
I don't really know how to respond to that. It's rather obvious starting a thread with "look, RFC 3501 added some additional SHOULD responses to SELECT", would've probably solved this problem a long time ago.
But IMAP, historically, has always attracted some hard-headed, opinionated characters. Myself included. My flamewars with Crispin, circa 15-20 years ago, are some of my fond memories. It's really funny how the more things change, the more they stay the same. History is repeating itself.
But another thing to consider here is that it's just as likely that adding the new messages would break some other client, that's not expecting to see them. This gets down to the real problem, which is IMAP itself. It's not an accident that of all the core protocols related to mail, IMAP is the one with a disproportionately higher history of these kinds of interoperability problems. More than all the others, combined, and I place the blame squarely on IMAP's fundamental design. That's what's really at fault here.
So the capsule summary is really that one doesn't really realize what a minefield IMAP is until one's worked with it for some time. So, what happens time and time again, is that someone ramps up on writing an IMAP client, and, based on the cursory look, comes up with what they think is the implementation they want, without realizing that it depends on either specific server behavior, or optional bits of the protocol that are not completely mandatory to be done that way by the server. Realization sets in that it was the wrong way to go, and it's naturally upsetting. I've observed this happen time, and time again, for years. Nothing's new under the sun.
So, they wrote new code relying on the server sending back a UIDNEXT. I didn't look why. There's really no reason for it (see below). The caution in RFC 3501, that some servers may not send them, was easily missed. This broke many people's servers, the bug reports came flooding in. They started blaming the server. Halfway down the bug report, someone pointed out that UIDNEXT was not required, due to the awkward wording of RFC 3501. Feelings were hurt, a workaround was cobbled together, with a snarky message. Nothing's new under the sun.
And to close the loop, I always understood that stuff said on a public list is always, well, open to the public. Anyone's free to link to any public discussion, for any reason at all.
I completely missed this because I have been using Thunderbird for a few years explicitly because their akonadi IMAP backend has been unusable. I only noticed a day or so ago on a fresh Kubuntu 15.04 install when I tried kmail/akonadi for a test to see if things have improved (as I have done 2 or 3 times a year for the last 3 or 4 years.) It has improved slightly but akonadi downloads all headers everything I change folders so it's still unusable. Kmail used to be a truly excellent client before they introduced this separate akonadi backend system.
What I just said. This is IMAP's ugly side. There's only one, very specific way, to implement IMAP on the client that has any reasonable chance of working with every IMAP server in existence. And it's not very obvious what it should be, not obvious at all. You can't rely on UIDNEXT. You can't rely on half the stuff in RFC 3501, because you don't have a lot of guarantees to go on.
pgp5jt_IuTp0O.pgp
Description: PGP signature
------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
