I just recently discovered dovecot. I am evaluating the program and several clients uses Outlook/Outlook Express.
In the clients issues section of dovecot.org is says "You should enable outlook-idle workaround"
Ok, maybe I am missing something very obvious here but I can not find any documentation on how to implement the outlook-idle workaround. Can anyone point me to an article or something with more details on this issue?
Thanks in advance.
On 5.10.2004, at 22:30, AWC Maillists wrote:
Ok, maybe I am missing something very obvious here but I can not find any documentation on how to implement the outlook-idle workaround.
Can anyone point me to an article or something with more details on this issue?
Reading through dovecot.conf would be a good idea in any case. It's there.
Timo Sirainen wrote:
On 5.10.2004, at 22:30, AWC Maillists wrote:
Ok, maybe I am missing something very obvious here but I can not find any documentation on how to implement the outlook-idle workaround.
Can anyone point me to an article or something with more details on this issue?Reading through dovecot.conf would be a good idea in any case. It's there.
Thanks... I did see the entry in dovecot.conf, but it does not exactly explain what is does to keep Outlook from doing the idle timeouts. More specifically, does this option still cause Outook to generate the annoying timeout messages? Or does it somehow trick Outlook into thinking the connection is not idle.
Also, does enabling this option cause any problems/error message with other clients?
Thanks for the prompt reply.
On 5.10.2004, at 23:28, AWC Maillists wrote:
Thanks... I did see the entry in dovecot.conf, but it does not exactly explain what is does to keep Outlook from doing the idle timeouts.
More specifically, does this option still cause Outook to generate the annoying timeout messages? Or does it somehow trick Outlook into thinking the connection is not idle. Also, does enabling this option cause any problems/error message with other clients?
Oh, you wanted just details. When this is enabled:
If after 29 minutes of IDLEing client hasn't sent anything, Dovecot behaves as if a new mail arrived and announces it to client. Usually clients react to this by stopping the IDLE and fetching information of the new mail. So, once clients stop IDLE, Dovecot says immediately that the new mail was just expunged and clients go back IDLEing. So this just "pings" the client into doing something to check if it's still there.
I think UW-IMAP does this internally always, but I thought I'd require all workarounds to be explicitly enabled so future client implementors can make sure their clients work without any of them.
On Tue, 5 Oct 2004, Timo Sirainen wrote:
Oh, you wanted just details. When this is enabled: If after 29 minutes of IDLEing client hasn't sent anything, Dovecot behaves as if a new mail arrived and announces it to client. Usually clients react to this by stopping the IDLE and fetching information of the new mail. So, once clients stop IDLE, Dovecot says immediately that the new mail was just expunged and clients go back IDLEing. So this just "pings" the client into doing something to check if it's still there.
Why is this an option? Is there a reason why someone would want to disable this workaround?
Andreas
-- Andreas Aardal Hanssen http://www.andreas.hanssen.name/gpg2
On Mon, 2004-10-11 at 11:27 +0200, Andreas Aardal Hanssen wrote:
Why is this an option? Is there a reason why someone would want to disable this workaround?
Like Timo said:
but I thought I'd require all workarounds to be explicitly enabled so future client implementors can make sure their clients work without any of them.
johannes
On Mon, 11 Oct 2004, Johannes Berg wrote:
On Mon, 2004-10-11 at 11:27 +0200, Andreas Aardal Hanssen wrote:
Why is this an option? Is there a reason why someone would want to disable this workaround? Like Timo said: but I thought I'd require all workarounds to be explicitly enabled so future client implementors can make sure their clients work without any of them.
System adminstrators have no reason to switch off a workaround in Dovecot because a bug was fixed in a certain revision of an IMAP client, and Microsoft doesn't need Dovecot to fix this bug.
Don't mean to sound pragmatic, but why make it an option?
-- Andreas Aardal Hanssen http://www.andreas.hanssen.name/gpg2
On 11.10.2004, at 12:54, Andreas Aardal Hanssen wrote:
but I thought I'd require all workarounds to be explicitly enabled so future client implementors can make sure their clients work without any of them.
System adminstrators have no reason to switch off a workaround in Dovecot because a bug was fixed in a certain revision of an IMAP client, and Microsoft doesn't need Dovecot to fix this bug.
Don't mean to sound pragmatic, but why make it an option?
Mostly because I don't want to hide all the workarounds that have been required for clients. Microsoft may not ever fix Outlook, but other client implementors might see what bugs others have had, and make sure they won't have at least the same bugs.
Maybe outlook-idle workaround could be enabled by default. Hmm. I guess I'll do that.
I am changing my linux distro .. to slackware from fendora core .. but the imapd will remain the same as dovecot so what are the steps involved in backing up all my users mailboxes & then resotring again .. i have never done this sucessfully so please help me out ..
thnaks
participants (6)
-
Andreas Aardal Hanssen
-
Andreas Aardal Hanssen
-
AWC Maillists
-
Faisal
-
Johannes Berg
-
Timo Sirainen