Re: Buggy MUA workaround question
Andreas Aardal Hanssen <[email protected]> Sun, 15 May 2005 15:52:15 +0200 (CEST)
| Newsgroups | gmane.mail.imap.binc.devel |
|---|---|
| Message-ID | <Pine.LNX.4.61.0505151540300.5723@qfy-215-113> |
On Sun, 15 May 2005, Casey Allen Shobe wrote: >I noticed these workaround options in dovecot's configuration, and was >curious if bincimap addressed these issues, and how so if so? Hi, Casey. No; Binc IMAP doesn't work around client bugs. Where the bugs are fixed in later versions of the same software, the users should (and can) upgrade. Luckily, these bugs are very seldomly visible in practise today, and will be even less visible in the future. Working around them introduces really messy logics that are hard to deal with in server code. And since it's a burden for the majority at the benefit for the few (and declining), it's against Binc IMAP's principles to work around these bugs. Just to give you an idea of one of the workarounds, some broken Outlook clients enter IDLE mode (or simply stay quiet outside IDLE mode) and stay there forever or until one of the peers times out. To work around this problem, when 29 minutes have passed, regardless of what client is connected, the IMAP server (Dovecot, in this case) lies and claims that a new message has arrived. This immediately triggers Outlook to exit IDLE mode and check out the new message. But in the meantime, the IMAP server reports it as deleted and expunged. So Outlook goes back to sleep. Now, one UID value has been spent, and this again triggers other clients to poll the mailbox for the new (suddenly missing)message, but that's a harmless side effect. It's a nasty hack, and I'd like to keep bugs like this in the broken client's code, and not move it into Binc IMAP's code :). Andy :-) -- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | "It is better not to do something http://www.bincimap.org/ | than to do it poorly."