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."