[Dovecot] Dovecot upgrades break Blackberry instant email (BIS)
Hello, Just like when upgrading to 1.2, upgrading to 2.0.1 confuses RIM's BIS servers and users don't have instant email anymore on their Blackberrys. Under normal conditions, the BIS servers keep one open connection per email account with Dovecot. They're using IMAP IDLE to monitor changes and push them to devices very quickly.
After an upgrade, all changes. The BIS servers can't maintain an idling connection anymore, they just poll the Dovecot server when they feel like it (every 2-15 minutes). There is one way to fix this on the devices: The users have to re-create the email account.
I don't find this very convenient and was wondering if there was something that could be done on the Dovecot side?
Last time it happened, I tried clearing the indexes and resetting file permissions, but nothing helped.
Cheers,
Olivier
On 2010-08-31 12:41 PM, interfaSys sàrl <interfasys@gmail.com> wrote:
After an upgrade, all changes. The BIS servers can't maintain an idling connection anymore, they just poll the Dovecot server when they feel like it (every 2-15 minutes). There is one way to fix this on the devices: The users have to re-create the email account.
That sounds like a BIS bug rather than anything to do with dovecot...
--
Best regards,
Charles
On Tue, 2010-08-31 at 17:41 +0100, interfaSys sàrl wrote:
I don't find this very convenient and was wondering if there was something that could be done on the Dovecot side?
imap_capability = +IDLE
I'm thinking about making this default.. Assuming Blackberry people don't happen to fix it themselves soon, which would be nice but maybe not that realistic to expect. Anyway, http://dovecot.org/list/dovecot/2010-April/048147.html explains what's happening.
Worked perfectly!
Is it something that can be disabled after a few days or is there no harm in keeping it in the config?
(And congrats on your work on Dovecot Timo. Great piece of software.)
On 31/08/2010 17:53, Timo Sirainen wrote:
On Tue, 2010-08-31 at 17:41 +0100, interfaSys sàrl wrote:
I don't find this very convenient and was wondering if there was something that could be done on the Dovecot side?
imap_capability = +IDLE
I'm thinking about making this default.. Assuming Blackberry people don't happen to fix it themselves soon, which would be nice but maybe not that realistic to expect. Anyway, http://dovecot.org/list/dovecot/2010-April/048147.html explains what's happening.
Well, if I change this in v2.0.2 then you don't need it anymore. If you keep it anyway, you'll get a duplicate IDLE capability (actually you get that already post-login), but I don't think that breaks anything.
On Tue, 2010-08-31 at 18:07 +0100, interfaSys sàrl - Rich Internet Applications wrote:
Worked perfectly!
Is it something that can be disabled after a few days or is there no harm in keeping it in the config?
(And congrats on your work on Dovecot Timo. Great piece of software.)
On 31/08/2010 17:53, Timo Sirainen wrote:
On Tue, 2010-08-31 at 17:41 +0100, interfaSys sàrl wrote:
I don't find this very convenient and was wondering if there was something that could be done on the Dovecot side?
imap_capability = +IDLE
I'm thinking about making this default.. Assuming Blackberry people don't happen to fix it themselves soon, which would be nice but maybe not that realistic to expect. Anyway, http://dovecot.org/list/dovecot/2010-April/048147.html explains what's happening.
On 31/08/2010 19:18, Timo Sirainen wrote:
Well, if I change this in v2.0.2 then you don't need it anymore. If you keep it anyway, you'll get a duplicate IDLE capability (actually you get that already post-login), but I don't think that breaks anything.
On Tue, 2010-08-31 at 18:07 +0100, interfaSys sàrl - Rich Internet Applications wrote:
Worked perfectly!
Is it something that can be disabled after a few days or is there no harm in keeping it in the config?
(And congrats on your work on Dovecot Timo. Great piece of software.)
On 31/08/2010 17:53, Timo Sirainen wrote:
On Tue, 2010-08-31 at 17:41 +0100, interfaSys sàrl wrote:
I don't find this very convenient and was wondering if there was something that could be done on the Dovecot side?
imap_capability = +IDLE
I'm thinking about making this default.. Assuming Blackberry people don't happen to fix it themselves soon, which would be nice but maybe not that realistic to expect. Anyway, http://dovecot.org/list/dovecot/2010-April/048147.html explains what's happening.
There seems to be another thing that bothers BIS servers.
If the subscription file is 660, then it seems the connection is dropped (No idling). When it's 770, then things are fine.
Is anybody else able to confirm this?
On Thu, 2010-09-02 at 18:21 +0100, interfaSys sàrl wrote:
If the subscription file is 660, then it seems the connection is dropped (No idling). When it's 770, then things are fine.
That doesn't really make any sense.. Subscription file doesn't need to be executable. Anything in Dovecot's logs?
On 02/09/2010 18:23, Timo Sirainen wrote:
On Thu, 2010-09-02 at 18:21 +0100, interfaSys sàrl wrote:
If the subscription file is 660, then it seems the connection is dropped (No idling). When it's 770, then things are fine.
That doesn't really make any sense.. Subscription file doesn't need to be executable. Anything in Dovecot's logs?
Nothing interesting in the logs: Sep 02 19:25:46 imap-login: Info: Login: user=<user@domain.com>, method=PLAIN, rip=68.171.236.236, lip=192.168.1.1, mpid=43792, TLS Sep 02 19:25:46 imap(user@domain.com): Info: Disconnected: Logged out bytes=39/1010
It's only a theory, I've noticed that all my personal accounts with 770 were connected and the ones with 660 were not.
On 02/09/2010 18:23, Timo Sirainen wrote:
On Thu, 2010-09-02 at 18:21 +0100, interfaSys sàrl wrote:
If the subscription file is 660, then it seems the connection is dropped (No idling). When it's 770, then things are fine.
That doesn't really make any sense.. Subscription file doesn't need to be executable. Anything in Dovecot's logs?
Indeed, changing the file permissions didn't help. Half the accounts can't stay connected. Any hints as to what to look for?
On Fri, 2010-09-03 at 18:06 +0100, interfaSys sàrl wrote:
On 02/09/2010 18:23, Timo Sirainen wrote:
On Thu, 2010-09-02 at 18:21 +0100, interfaSys sàrl wrote:
If the subscription file is 660, then it seems the connection is dropped (No idling). When it's 770, then things are fine.
That doesn't really make any sense.. Subscription file doesn't need to be executable. Anything in Dovecot's logs?
Indeed, changing the file permissions didn't help. Half the accounts can't stay connected.
So what exactly is the problem? Those Blackberries don't do IDLE, or it's broken in some worse way?
On 03/09/2010 18:18, Timo Sirainen wrote:
On Fri, 2010-09-03 at 18:06 +0100, interfaSys sàrl wrote:
On 02/09/2010 18:23, Timo Sirainen wrote:
On Thu, 2010-09-02 at 18:21 +0100, interfaSys sàrl wrote:
If the subscription file is 660, then it seems the connection is dropped (No idling). When it's 770, then things are fine.
That doesn't really make any sense.. Subscription file doesn't need to be executable. Anything in Dovecot's logs?
Indeed, changing the file permissions didn't help. Half the accounts can't stay connected.
So what exactly is the problem? Those Blackberries don't do IDLE, or it's broken in some worse way?
Let's take an example with one device Half the accounts are always connected, like before. The other half can't keep the connection open.
Same server, multiple domain names, one config.
Connections are coming from the same BIS server
On 2010-09-03, at 1:41 PM, interfaSys sàrl wrote:
On 03/09/2010 18:18, Timo Sirainen wrote:
On Fri, 2010-09-03 at 18:06 +0100, interfaSys sàrl wrote:
On 02/09/2010 18:23, Timo Sirainen wrote:
On Thu, 2010-09-02 at 18:21 +0100, interfaSys sàrl wrote:
If the subscription file is 660, then it seems the connection is dropped (No idling). When it's 770, then things are fine.
That doesn't really make any sense.. Subscription file doesn't need to be executable. Anything in Dovecot's logs?
Indeed, changing the file permissions didn't help. Half the accounts can't stay connected.
So what exactly is the problem? Those Blackberries don't do IDLE, or it's broken in some worse way?
Let's take an example with one device Half the accounts are always connected, like before. The other half can't keep the connection open.
Same server, multiple domain names, one config.
Connections are coming from the same BIS server
Just for reference; I have quite a few people with Blackberrys connecting to my server too. And, many do not do idle. I can't tell why some do and some don't. I've tried adding IDLE as a capability before auth, no help. I've tried deleting and recreating the account on the BIS servers, sometimes it helps, usually not. I've done packet captures, and raw logs from Dovecot. The ones that don't work just never try to IDLE.
It seems to be something to do with Rim's server(s), and nothing I did on my end would ever influence it.
On Fri, 2010-09-03 at 17:50 -0400, Daryl Richards wrote:
Just for reference; I have quite a few people with Blackberrys connecting to my server too. And, many do not do idle. I can't tell why some do and some don't. I've tried adding IDLE as a capability before auth, no help. I've tried deleting and recreating the account on the BIS servers, sometimes it helps, usually not. I've done packet captures, and raw logs from Dovecot. The ones that don't work just never try to IDLE.
That was before Dovecot v2.0?
On 2010-09-06, at 11:49 AM, Timo Sirainen wrote:
On Fri, 2010-09-03 at 17:50 -0400, Daryl Richards wrote:
Just for reference; I have quite a few people with Blackberrys connecting to my server too. And, many do not do idle. I can't tell why some do and some don't. I've tried adding IDLE as a capability before auth, no help. I've tried deleting and recreating the account on the BIS servers, sometimes it helps, usually not. I've done packet captures, and raw logs from Dovecot. The ones that don't work just never try to IDLE.
That was before Dovecot v2.0?
I've run versions 1.2.11 through 1.2.13, haven't tried anything with 2.0 yet..
Seriously, though, I'm pretty sure it's a weirdness on their end. When you set up an account on the BIS servers, they do a connect to the server to verify login credentials. After this, it will either connect again and go IDLE, or just connect every 15 minutes to poll. I haven't seen any difference with the initial connects, but if an account gets added and does IDLE it will also do IDLE.. If after the first connect it decides to poll, it will always poll. Deleting and re-adding the account will sometimes make it switch how it runs, but not always. Someone from RIM would have to answer how it decides whether to run IDLE/push, or polled..
On 03/09/2010 18:18, Timo Sirainen wrote:
On Fri, 2010-09-03 at 18:06 +0100, interfaSys sàrl wrote:
On 02/09/2010 18:23, Timo Sirainen wrote:
On Thu, 2010-09-02 at 18:21 +0100, interfaSys sàrl wrote:
If the subscription file is 660, then it seems the connection is dropped (No idling). When it's 770, then things are fine.
That doesn't really make any sense.. Subscription file doesn't need to be executable. Anything in Dovecot's logs?
Indeed, changing the file permissions didn't help. Half the accounts can't stay connected.
So what exactly is the problem? Those Blackberries don't do IDLE, or it's broken in some worse way?
I've tried to play with permissions and plugins, but the only way to restore the connection is still to re-create the accounts.
Is there anything else somebody could think of?
I don't know what would force the BIS servers to re-evaluate the situation.
participants (5)
-
Charles Marcus
-
Daryl Richards
-
interfaSys sàrl
-
interfaSys sàrl - Rich Internet Applicatio ns
-
Timo Sirainen