[Dovecot] [2.0] Experience in production environment
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I decided to put 2.0-pre3 in a couple of production environments with about 50 users each.
The configuration is what I consider my own standard: Dovecot, Postfix with authentication via Dovecot, postfixadmin, maildir, userbase on MySQL.
The new configuration schema is very flexible and much better than the "monolithic" file. The configuration conversion utility is very useful.
No issue to report, the logfile is clean.
The only difference between 2.0 and the previous version is the RIM server. Some users have configured their blackberry to synchronize the phone with their mailbox in IMAP. Previously RIM kept a connection open, after upgrading to 2.0, RIM opens a connection and then closes it.
This is not an issue, because the synchronization is ok, and I think that is better this way than to keep an oper socket. Just for curiosity: it happens only to me and why this happens?
Ciao, luigi
/ +--[Luigi Rosa]-- \
We believe that no race can be truly intelligent without laughter. --Delenn, "A Race Through Dark Places", Babylon 5
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxObh8ACgkQ3kWu7Tfl6ZQatQCfXmYcX7Ke1j76oV41UXr/naU1 gOcAoLw5aRqpynI3EBQW546ja35+Pxoa =tube -----END PGP SIGNATURE-----
On Tue, 2010-07-27 at 07:26 +0200, Luigi Rosa wrote:
The only difference between 2.0 and the previous version is the RIM server. Some users have configured their blackberry to synchronize the phone with their mailbox in IMAP. Previously RIM kept a connection open, after upgrading to 2.0, RIM opens a connection and then closes it.
This happens because IDLE is no longer advertised in CAPABILITY before login. This is the only widely used IMAP client I know of that has this problem now. Wonder if RIM would have any interest in fixing this themselves.. Probably not. Maybe I should just give up and put IDLE into the pre-login capability..
This is not an issue, because the synchronization is ok, and I think that is better this way than to keep an oper socket.
The reason why it keeps the connection open is to give users instantaneous notifications of new mails.
On 8/2/2010 8:15 AM, Timo Sirainen wrote:
cause IDLE is no longer advertised in CAPABILITY before login. This is the only widely used IMAP client I know of that has this problem now. Wonder if RIM would have any interest in fixing this themselves.. Probably not. Maybe I should just give up and put IDLE into the pre-login capability..
Why the change? RFC compliance? Performance?
Daniel
On 2.8.2010, at 19.04, Daniel L. Miller wrote:
On 8/2/2010 8:15 AM, Timo Sirainen wrote:
cause IDLE is no longer advertised in CAPABILITY before login. This is the only widely used IMAP client I know of that has this problem now. Wonder if RIM would have any interest in fixing this themselves.. Probably not. Maybe I should just give up and put IDLE into the pre-login capability..
Why the change? RFC compliance? Performance?
To get rid of the horrible ugly way of getting a list of capabilities at startup. Dovecot doesn't know what capabilities are available until it has loaded all plugins and loaded them and asked what capabilities those plugins added. This caused numerous problems with v1.x for many years. I doubt all of the potential problems are still fixed in latest v1.2.
Per-user capabilities aren't possible if the capability list must be the same before and after login.
So I reduced the pre-login capability list to be as minimal as it can be. Not just because of 1) and 2), but because the minimal capability list would make it obvious when a client doesn't recognize the post-login capabilities and that the client could also never support 2). Several of these clients were already found and fixed. And I knew that this worked fine with the most widely used clients. But I hadn't encountered RIM before.. Does anyone happen to know anyone in RIM's email team? :) The good thing here is that it would only require RIM to upgrade their servers to fix this, not to force thousands or millions of users to upgrade their clients..
participants (3)
-
Daniel L. Miller
-
Luigi Rosa
-
Timo Sirainen