[PATCH 1/1] storage: remove 500 ms debounce on IMAP IDLE notifications
This commit removes hardcoded 500 ms debounce from storage that delays all storage notification subscribers such as IDLE and NOTIFY commands. 500 ms debounce constant NOTIFY_DELAY_MSECS was added in 2009 [1]. Before that Dovecot was only delivering notifications when a second-resolution timer is changed by at least 1, so IDLE notifications were delayed by half a second on average. [1] https://github.com/dovecot/core/commit/56fb5d09955b6097f77b341717fd9b70e9f13e7 --- src/lib-storage/mail-storage-private.h | 2 +- src/lib-storage/mailbox-watch.c| 21 - 2 files changed, 5 insertions(+), 18 deletions(-) diff --git a/src/lib-storage/mail-storage-private.h b/src/lib-storage/mail-storage-private.h index 0cbdf4c48a..32b337d242 100644 --- a/src/lib-storage/mail-storage-private.h +++ b/src/lib-storage/mail-storage-private.h @@ -455,7 +455,7 @@ struct mailbox { /* Mailbox notification settings: */ mailbox_notify_callback_t *notify_callback; void *notify_context; - struct timeout *to_notify, *to_notify_delay; + struct timeout *to_notify; struct mailbox_notify_file *notify_files; /* Increased by one for each new struct mailbox. */ diff --git a/src/lib-storage/mailbox-watch.c b/src/lib-storage/mailbox-watch.c index 659cab3810..a56c5093fc 100644 --- a/src/lib-storage/mailbox-watch.c +++ b/src/lib-storage/mailbox-watch.c @@ -9,8 +9,6 @@ #include #include -#define NOTIFY_DELAY_MSECS 500 - struct mailbox_notify_file { struct mailbox_notify_file *next; @@ -19,9 +17,10 @@ struct mailbox_notify_file { struct io *io_notify; }; -static void notify_delay_callback(struct mailbox *box) +static void notify_callback(struct mailbox *box) { - timeout_remove(&box->to_notify_delay); + timeout_reset(box->to_notify); + box->notify_callback(box, box->notify_context); } @@ -40,18 +39,7 @@ static void notify_timeout(struct mailbox *box) } if (notify) - notify_delay_callback(box); -} - -static void notify_callback(struct mailbox *box) -{ - timeout_reset(box->to_notify); - - if (box->to_notify_delay == NULL) { - box->to_notify_delay = - timeout_add_short(NOTIFY_DELAY_MSECS, - notify_delay_callback, box); - } + notify_callback(box); } void mailbox_watch_add(struct mailbox *box, const char *path) @@ -97,7 +85,6 @@ void mailbox_watch_remove_all(struct mailbox *box) i_free(file); } - timeout_remove(&box->to_notify_delay); timeout_remove(&box->to_notify); } -- 2.43.0 ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Unconfigurable 500 ms debounce on IMAP IDLE notifications
On Fri, Dec 15, 2023 at 11:37:10AM +0200, Timo Sirainen wrote: > On 15. Dec 2023, at 1.59, Alex wrote: > > > >>> I would actually like to disable this delay completely on our server > >>> setup [6], > >>> as for chat it is common to receive multiple > >>> messages in a short period of time, > >>> e.g. when sending a message to a group and receiving multiple read > >>> receipts > >>> from currently active users. > >> > >> We could of course make this a setting, but maybe it's not necessary. > >> Would this behavior also work for you? : > >> > >> * If the current IDLE hasn't notified anything yet, send the notification > >> immediately without waiting > >> * Otherwise, send it max once per 0.5 seconds. > > > > For IDLE this would work and be indistinguishable from no delay > > as Delta Chat core always interrupts IDLE > > with DONE as soon as it receives a response (e.g. EXISTS or RECENT, but not > > keepalive). > > > > But as this delay code is a part of the storage > > (src/lib-storage/mailbox-watch.c) > > and knows nothing about IDLE, I am not sure how this could be implemented. > > There is also a plan to implement NOTIFY (RFC 5465) extension support in > > Delta Chat [1] > > where "NOTIFY SET" is executed only once and then there are incoming > > notifications > > for the rest of the IMAP session. NOTIFY uses the same callback and has the > > same 0.5 second delay as a result. > > Yeah, it would need some additional API changes to make it work that way. Maybe move this debounce out of storage and into IDLE implementation (imap/cmd-idle.c) then? Then other callers of mailbox_notify_changes will have no delay. I only see other calls to mailbox_notify_changes() in imap/imap-notify.c and plugins/virtual/virtual-storage.c. Virtual storage does not need debounce then just as the normal storage. Then if IDLE implementation manages this debounce itself and sends the first notification immediately after each IDLE resetup, that would be perfect without the need for a configuration option. As for NOTIFY, same logic cannot be implemented, but hopefully NOTIFY users are advanced enough to debounce themselves? My plan for using NOTIFY is to subscribe directly to receive message body, so in my case every notification should be immediate. > > > What could work is a change to callback immediately if there have been no > > callback call > > in the last 0.5 seconds and otherwise delay it. Then there will be no > > difference as long as two emails in a row > > do not come wihin half a second. > > I thought it would be important in those cases also? But if not, that's the > simplest fix, yes. And it could be shrunk even further from 0.5 seconds to > maybe 0.1 seconds. Yes, ideally first notification after IDLE should always be immediate. If debounce logic is moved to IDLE implementation this looks simple too. > > But I also wonder why not remove the delay completely then if there is no > > need for it? > > Debounce can always be implemented on the client side if necessary, > > if the client does not want to react to interruptions more frequently than > > once every half a second > > it can delay the reaction locally. > > There could be some performance loss if there is never any delay. For example > some offline client could connect and start issuing a bunch of flag updates, > while another IDLEing connection keeps trying to rapidly send notifications > about each of those changes separately instead of bundling them all into a > single mailbox sync. So this IDLE connection is some UI client that will be slowed down by trying to refresh the view on every change? Either the client tries to update the state and redraw the view on every incoming update or it updates the state immediately and debounces view redraws on its own. In the first case delaying IDLE/NOTIFY updates would not help as the number of redraws is not reduced. In the second case there is no need to debounce on the server side as state updates are going to be fast anyway. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Unconfigurable 500 ms debounce on IMAP IDLE notifications
On 15. Dec 2023, at 1.59, Alex wrote: > >>> I would actually like to disable this delay completely on our server setup >>> [6], >>> as for chat it is common to receive multiple >>> messages in a short period of time, >>> e.g. when sending a message to a group and receiving multiple read receipts >>> from currently active users. >> >> We could of course make this a setting, but maybe it's not necessary. Would >> this behavior also work for you? : >> >> * If the current IDLE hasn't notified anything yet, send the notification >> immediately without waiting >> * Otherwise, send it max once per 0.5 seconds. > > For IDLE this would work and be indistinguishable from no delay > as Delta Chat core always interrupts IDLE > with DONE as soon as it receives a response (e.g. EXISTS or RECENT, but not > keepalive). > > But as this delay code is a part of the storage > (src/lib-storage/mailbox-watch.c) > and knows nothing about IDLE, I am not sure how this could be implemented. > There is also a plan to implement NOTIFY (RFC 5465) extension support in > Delta Chat [1] > where "NOTIFY SET" is executed only once and then there are incoming > notifications > for the rest of the IMAP session. NOTIFY uses the same callback and has the > same 0.5 second delay as a result. Yeah, it would need some additional API changes to make it work that way. > What could work is a change to callback immediately if there have been no > callback call > in the last 0.5 seconds and otherwise delay it. Then there will be no > difference as long as two emails in a row > do not come wihin half a second. I thought it would be important in those cases also? But if not, that's the simplest fix, yes. And it could be shrunk even further from 0.5 seconds to maybe 0.1 seconds. > But I also wonder why not remove the delay completely then if there is no > need for it? > Debounce can always be implemented on the client side if necessary, > if the client does not want to react to interruptions more frequently than > once every half a second > it can delay the reaction locally. There could be some performance loss if there is never any delay. For example some offline client could connect and start issuing a bunch of flag updates, while another IDLEing connection keeps trying to rapidly send notifications about each of those changes separately instead of bundling them all into a single mailbox sync. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Unconfigurable 500 ms debounce on IMAP IDLE notifications
On Thu, Dec 14, 2023 at 07:17:16PM +0200, Timo Sirainen wrote: > > I wonder if this debounce delay was added as a workaround > > for an internal Dovecot bug or a client bug > > and is not necessary anymore. > > It does not seem to be useful for well-behaving clients because > > if necessary the client may debounce notifications on its side > > and postpone interrupting IDLE with "DONE". > > I can't really think of any situation where this would be necessary anymore. > Not sure why it was necessary back in 2009 - maybe Maildir didn't have quite > as many locks back then. Anyway now even if a change is partial at the time > the mailbox-watch triggers, it runs full mailbox syncing which will lock the > mailbox, so it waits for any previous changes to finish being written. I have only tested with Maildir, maybe it was important for some other storage at the time it was introduced. > > I would actually like to disable this delay completely on our server setup > > [6], > > as for chat it is common to receive multiple > > messages in a short period of time, > > e.g. when sending a message to a group and receiving multiple read receipts > > from currently active users. > > We could of course make this a setting, but maybe it's not necessary. Would > this behavior also work for you? : > > * If the current IDLE hasn't notified anything yet, send the notification > immediately without waiting > * Otherwise, send it max once per 0.5 seconds. For IDLE this would work and be indistinguishable from no delay as Delta Chat core always interrupts IDLE with DONE as soon as it receives a response (e.g. EXISTS or RECENT, but not keepalive). But as this delay code is a part of the storage (src/lib-storage/mailbox-watch.c) and knows nothing about IDLE, I am not sure how this could be implemented. There is also a plan to implement NOTIFY (RFC 5465) extension support in Delta Chat [1] where "NOTIFY SET" is executed only once and then there are incoming notifications for the rest of the IMAP session. NOTIFY uses the same callback and has the same 0.5 second delay as a result. What could work is a change to callback immediately if there have been no callback call in the last 0.5 seconds and otherwise delay it. Then there will be no difference as long as two emails in a row do not come wihin half a second. But I also wonder why not remove the delay completely then if there is no need for it? Debounce can always be implemented on the client side if necessary, if the client does not want to react to interruptions more frequently than once every half a second it can delay the reaction locally. > > So if you're using the same connection to always break out of IDLE after a > notification, there would be no dalays. [1] https://github.com/deltachat/deltachat-core-rust/pull/4990 ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Unconfigurable 500 ms debounce on IMAP IDLE notifications
On 14. Dec 2023, at 16.21, Alex wrote: > > Hello all, > > I have been investigating the reason for high > end-to-end email delivery delay > (>1 second to send a message to echo bot and receive a reply back) > on a Postfix+Dovecot email server setup > used to run the tests for Delta Chat core [1]. > It appeared that most of the time was spent > between the submission SMTP service accepting the mail for delivery > and receiving an IDLE wakeup on the other side. > > Looking into the Dovecot source code, > I found that all notifications from the storage > to callbacks set up by IDLE are delayed by > a debounce constant NOTIFY_DELAY_MSECS [2]. > It appears to have been added in 2009 [3], > but even before that Dovecot was only delivering > notifications when a second-resolution timer > is changed by at least 1, so IDLE notifications > probably were delayed by half a second on average > even before that. > > Commit message says > "If the notification is done immediately, > IDLE may not notice the change because it's not finished yet." > This sounds like a workaround for some internal Dovecot bug. ... > I wonder if this debounce delay was added as a workaround > for an internal Dovecot bug or a client bug > and is not necessary anymore. > It does not seem to be useful for well-behaving clients because > if necessary the client may debounce notifications on its side > and postpone interrupting IDLE with "DONE". I can't really think of any situation where this would be necessary anymore. Not sure why it was necessary back in 2009 - maybe Maildir didn't have quite as many locks back then. Anyway now even if a change is partial at the time the mailbox-watch triggers, it runs full mailbox syncing which will lock the mailbox, so it waits for any previous changes to finish being written. > I would actually like to disable this delay completely on our server setup > [6], > as for chat it is common to receive multiple > messages in a short period of time, > e.g. when sending a message to a group and receiving multiple read receipts > from currently active users. We could of course make this a setting, but maybe it's not necessary. Would this behavior also work for you? : * If the current IDLE hasn't notified anything yet, send the notification immediately without waiting * Otherwise, send it max once per 0.5 seconds. So if you're using the same connection to always break out of IDLE after a notification, there would be no dalays. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Unconfigurable 500 ms debounce on IMAP IDLE notifications
Hello all, I have been investigating the reason for high end-to-end email delivery delay (>1 second to send a message to echo bot and receive a reply back) on a Postfix+Dovecot email server setup used to run the tests for Delta Chat core [1]. It appeared that most of the time was spent between the submission SMTP service accepting the mail for delivery and receiving an IDLE wakeup on the other side. Looking into the Dovecot source code, I found that all notifications from the storage to callbacks set up by IDLE are delayed by a debounce constant NOTIFY_DELAY_MSECS [2]. It appears to have been added in 2009 [3], but even before that Dovecot was only delivering notifications when a second-resolution timer is changed by at least 1, so IDLE notifications probably were delayed by half a second on average even before that. Commit message says "If the notification is done immediately, IDLE may not notice the change because it's not finished yet." This sounds like a workaround for some internal Dovecot bug. I have nevertheless tried to compile Dovecot with this constant reduced from 500 ms to 1 ms [4] and it resulted in exceptionally fast delivery without any problems caused to the Delta Chat core online test suite which is using this Postfix+Dovecot server accounts. We are running all the tests against this server and it appears to work fine. Round trip time for sending a message to an echo bot and receiving a reply back is reduced from 1.1 s to 0.2 s, which is easily visible in a chat app [5]. I wonder if this debounce delay was added as a workaround for an internal Dovecot bug or a client bug and is not necessary anymore. It does not seem to be useful for well-behaving clients because if necessary the client may debounce notifications on its side and postpone interrupting IDLE with "DONE". I would actually like to disable this delay completely on our server setup [6], as for chat it is common to receive multiple messages in a short period of time, e.g. when sending a message to a group and receiving multiple read receipts from currently active users. [1] https://github.com/deltachat/deltachat-core-rust/ [2] https://github.com/dovecot/core/blob/93a53a9d590f0220de28600f36a969cc38c3148b/src/lib-storage/mailbox-watch.c#L12 [3] https://github.com/dovecot/core/commit/56fb5d09955b6097f77b341717fd9b70e9f13e7a [4] https://github.com/deltachat/chatmail/issues/72#issuecomment-1806645153 [5] https://delta.chat/assets/blog/nine-echo.mp4 [6] https://github.com/deltachat/chatmail Best regards, Alex ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Help with IMAP IDLE
> On 27 Jul 2019, at 13.15, Jorge Bastos via dovecot > wrote: > > Guys, > > I just discovered the reason! > > When i migrated the account from the old imap server to the new (dovecot), i > didn't removed and created the account in msoutlook, as i didn't saw any > reason to do it. > Creating the account again, IDLE works ok! May I ask you how did you do the migration in the first place? As if the account was correctly migrated then there was no reason for recreating the account. Sami
Re: Help with IMAP IDLE
On 27 Jul 2019, at 04:15, Jorge Bastos wrote: > When i migrated the account from the old imap server to the new (dovecot), i > didn't removed and created the account in msoutlook, as i didn't saw any > reason to do it. > Creating the account again, IDLE works ok! Glad you got that figured out. Seems like a weird one. -- CURSIVE WRITING DOES NOT MEAN WHAT I THINK IT DOES Bart chalkboard Ep. 2F11
RE: Help with IMAP IDLE
Guys, I just discovered the reason! When i migrated the account from the old imap server to the new (dovecot), i didn't removed and created the account in msoutlook, as i didn't saw any reason to do it. Creating the account again, IDLE works ok! Stupid outlook! Sorry for the noise, and thank you for the help, -Original Message- From: dovecot On Behalf Of Jorge Bastos via dovecot Sent: Tuesday, July 23, 2019 23:32 To: 'Dovecot Mailing List' Subject: RE: Help with IMAP IDLE Well, I've been doing some research, and it seems that msoutlook 2016 and 2019 doesn't quite have imap idle support. The odd part, is that when i had DBMail, it was IDLE'ing (i swear), Would dbmail send something different that make it work? It was an old version of dbmail, 2.3.7 i believe, from about 2012 or so. And no, it wasn't the outlook options "send/receive", i had and have that disabled, Don't have explanation, thunderbird IDLE's perfectly -Original Message- From: dovecot On Behalf Of Jorge Bastos via dovecot Sent: Tuesday, July 23, 2019 22:47 To: 'Dovecot Mailing List' Subject: RE: Help with IMAP IDLE Yes, Escape character is '^]'. * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN] > Yes, it works with other IMAP servers, why should not work with dovecot? > It was working with DBMail, and it's working with an account from my > Telco that used cirus-imap. Have you verified (with rawlogs or tcpdump) that outlook even attempts IDLE? Is your dovecot advertising IDLE support in CAPABILITY? Sami
RE: Help with IMAP IDLE
Well, I've been doing some research, and it seems that msoutlook 2016 and 2019 doesn't quite have imap idle support. The odd part, is that when i had DBMail, it was IDLE'ing (i swear), Would dbmail send something different that make it work? It was an old version of dbmail, 2.3.7 i believe, from about 2012 or so. And no, it wasn't the outlook options "send/receive", i had and have that disabled, Don't have explanation, thunderbird IDLE's perfectly -Original Message- From: dovecot On Behalf Of Jorge Bastos via dovecot Sent: Tuesday, July 23, 2019 22:47 To: 'Dovecot Mailing List' Subject: RE: Help with IMAP IDLE Yes, Escape character is '^]'. * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN] > Yes, it works with other IMAP servers, why should not work with dovecot? > It was working with DBMail, and it's working with an account from my Telco that used cirus-imap. Have you verified (with rawlogs or tcpdump) that outlook even attempts IDLE? Is your dovecot advertising IDLE support in CAPABILITY? Sami
RE: Help with IMAP IDLE
Yes, Escape character is '^]'. * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN] > Yes, it works with other IMAP servers, why should not work with dovecot? > It was working with DBMail, and it's working with an account from my Telco > that used cirus-imap. Have you verified (with rawlogs or tcpdump) that outlook even attempts IDLE? Is your dovecot advertising IDLE support in CAPABILITY? Sami
Re: Help with IMAP IDLE
On 22 Jul 2019, at 03:45, Jorge Bastos via dovecot wrote: > On Jul 21, 2019, at 11:50, Jorge Bastos via dovecot > wrote: >>> SSL/TLS is done via Stunnel > >> Dirst, others have asked but I haven’t seen an answer, do you have any >> reason to think Outlook supports IMAP idle at all? I mean, I know >> outlook.com > doesn’t support it, so maybe it just doesn’t work? >> Secondly, assuming Outlook does support IMAP idle, if you setup Dovecot to >> use SSL and not stunnel do things work? > Yes, it works with other IMAP servers, why should not work with dovecot? I’m confused by your answer, how do your dovecot settings and/or use of stunnel affect other IMAP servers? This account with a dovecot server: Jul 22 04:26:51 mail dovecot: imap(krem...@kreme.com)<15649>: Connection closed (IDLE running for 0.001 + waiting input for 465.309 secs, 2 B in + 10 B out, state=wait-input) in=1549 out=5488 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0
Re: Help with IMAP IDLE
> On 22 Jul 2019, at 12.45, Jorge Bastos via dovecot > wrote: > > On Jul 21, 2019, at 11:50, Jorge Bastos via dovecot > wrote: >> SSL/TLS is done via Stunnel > >> Dirst, others have asked but I haven’t seen an answer, do you have any >> reason to think Outlook supports IMAP idle at all? I mean, I know >> outlook.com > doesn’t support it, so maybe it just doesn’t work? > >> Secondly, assuming Outlook does support IMAP idle, if you setup Dovecot to >> use SSL and not stunnel do things work? > > Yes, it works with other IMAP servers, why should not work with dovecot? > It was working with DBMail, and it's working with an account from my Telco > that used cirus-imap. Have you verified (with rawlogs or tcpdump) that outlook even attempts IDLE? Is your dovecot advertising IDLE support in CAPABILITY? Sami
RE: Help with IMAP IDLE
On Jul 21, 2019, at 11:50, Jorge Bastos via dovecot wrote: > SSL/TLS is done via Stunnel > Dirst, others have asked but I haven’t seen an answer, do you have any reason > to think Outlook supports IMAP idle at all? I mean, I know outlook.com > > doesn’t support it, so maybe it just doesn’t work? > Secondly, assuming Outlook does support IMAP idle, if you setup Dovecot to > use SSL and not stunnel do things work? Yes, it works with other IMAP servers, why should not work with dovecot? It was working with DBMail, and it's working with an account from my Telco that used cirus-imap.
Re: Help with IMAP IDLE
On Jul 21, 2019, at 11:50, Jorge Bastos via dovecot wrote: > SSL/TLS is done via Stunnel Dirst, others have asked but I haven’t seen an answer, do you have any reason to think Outlook supports IMAP idle at all? I mean, I know outlook.com doesn’t support it, so maybe it just doesn’t work? Secondly, assuming Outlook does support IMAP idle, if you setup Dovecot to use SSL and not stunnel do things work?
RE: Help with IMAP IDLE
> I configured hibernation as suggested by Aki, and still nothing. > What may i be missing? > > I just read again the mails you sent and realized it had nothing to do with > hibernation. Sorry about that.. > > imapc_max_idle_time = 1 days > > this is related to imap client, not imap connections. it won't really matter > for your issue. > > also I note that you have disabled SSL and enabled plaintext authentication > over insecure channels, is this intentional? For debug purposes you can use > rawlogs feature, which is better for this. SSL/TLS is done via Stunnel > > https://doc.dovecot.org/admin_manual/debugging/debugging_rawlog/ > > In fact, you could use this feature to find out whether outlook even tries to > use IMAP IDLE in the first place. Let me check, it must be a reason to not be working with dovecot, when it was with DBMail, Will check and reply soon, > > Aki
RE: Help with IMAP IDLE
> On 21/07/2019 18:45 Jorge Bastos via dovecot wrote: > > > Hi again, > > I configured hibernation as suggested by Aki, and still nothing. > What may i be missing? > I just read again the mails you sent and realized it had nothing to do with hibernation. Sorry about that.. imapc_max_idle_time = 1 days this is related to imap client, not imap connections. it won't really matter for your issue. also I note that you have disabled SSL and enabled plaintext authentication over insecure channels, is this intentional? For debug purposes you can use rawlogs feature, which is better for this. https://doc.dovecot.org/admin_manual/debugging/debugging_rawlog/ In fact, you could use this feature to find out whether outlook even tries to use IMAP IDLE in the first place. Aki
RE: Help with IMAP IDLE
Hi again, I configured hibernation as suggested by Aki, and still nothing. What may i be missing? https://doc.dovecot.org/configuration_manual/hibernation/ -Original Message- From: dovecot On Behalf Of Jorge Bastos via dovecot Sent: Sunday, July 21, 2019 14:14 To: 'Dovecot Mailing List' Subject: RE: Help with IMAP IDLE Sorry... I meant to past dovecot and not postfix, doing simultaneously stuff ends up in this! Yes, i migrated from DBMail and it was working OK. Here it is: root@fastmail:/etc/dovecot# doveconf -n|grep -i idle imap_idle_notify_interval = 1 mins imapc_max_idle_time = 1 days root@fastmail:/etc/dovecot# -Original Message- From: dovecot On Behalf Of Alexander Dalloz via dovecot Sent: Sunday, July 21, 2019 13:31 To: dovecot@dovecot.org Subject: Re: Help with IMAP IDLE Am 21.07.19 um 14:24 schrieb Jorge Bastos via dovecot: > Hi, [ ... ] > How can i make IDLE work for real with MSOutlook, so that i can > receive emails when they arrive, instead of changing folder/get out > and in my account? Microsoft's Outlook is primarily meant as the client for Exchange. IMAP is been poorly implemented, across many generations of Outlook. So are you sure your Outlook even supports IMAP IDLE? And if it does, not only on the single folder you have a running connection to but for all folders? > Here's my conf, should it be reflected in postconf -n (is it the > running > conf?): Postfix has nothing to do with that, so "postconf -n" is not required. > == > > > > root@fastmail:/etc/dovecot# grep -ir idle * > > conf.d/20-imap.conf.ucf-dist:# If nothing happens for this long while > client is IDLEing, move the connection > > conf.d/20-imap.conf.ucf-dist:# IDLEing. > > conf.d/20-imap.conf.ucf-dist:#imap_idle_notify_interval = 2 mins > > conf.d/20-imap.conf:imapc_max_idle_time = 1440 mins > > conf.d/20-imap.conf:# IDLEing. > > conf.d/20-imap.conf:#imap_idle_notify_interval = 2 mins > > conf.d/20-imap.conf:imap_idle_notify_interval = 1 min > > conf.d/20-imap.conf:#imap_client_workarounds = outlook-idle > > conf.d/10-mail.conf.ucf-dist:# When IDLE command is running, mailbox > is checked once in a while to see if > > conf.d/10-mail.conf.ucf-dist:#mailbox_idle_check_interval = 30 secs > > conf.d/10-mail.conf:# When IDLE command is running, mailbox is checked > once in a while to see if > > conf.d/10-mail.conf:#mailbox_idle_check_interval = 30 secs > > root@fastmail:/etc/dovecot# postconf -n|grep -i idle "doveconf -n" would tell you which settings are effectively set. > root@fastmail:/etc/dovecot# Alexander
RE: Help with IMAP IDLE
Sorry... I meant to past dovecot and not postfix, doing simultaneously stuff ends up in this! Yes, i migrated from DBMail and it was working OK. Here it is: root@fastmail:/etc/dovecot# doveconf -n|grep -i idle imap_idle_notify_interval = 1 mins imapc_max_idle_time = 1 days root@fastmail:/etc/dovecot# -Original Message- From: dovecot On Behalf Of Alexander Dalloz via dovecot Sent: Sunday, July 21, 2019 13:31 To: dovecot@dovecot.org Subject: Re: Help with IMAP IDLE Am 21.07.19 um 14:24 schrieb Jorge Bastos via dovecot: > Hi, [ ... ] > How can i make IDLE work for real with MSOutlook, so that i can > receive emails when they arrive, instead of changing folder/get out > and in my account? Microsoft's Outlook is primarily meant as the client for Exchange. IMAP is been poorly implemented, across many generations of Outlook. So are you sure your Outlook even supports IMAP IDLE? And if it does, not only on the single folder you have a running connection to but for all folders? > Here's my conf, should it be reflected in postconf -n (is it the > running > conf?): Postfix has nothing to do with that, so "postconf -n" is not required. > == > > > > root@fastmail:/etc/dovecot# grep -ir idle * > > conf.d/20-imap.conf.ucf-dist:# If nothing happens for this long while > client is IDLEing, move the connection > > conf.d/20-imap.conf.ucf-dist:# IDLEing. > > conf.d/20-imap.conf.ucf-dist:#imap_idle_notify_interval = 2 mins > > conf.d/20-imap.conf:imapc_max_idle_time = 1440 mins > > conf.d/20-imap.conf:# IDLEing. > > conf.d/20-imap.conf:#imap_idle_notify_interval = 2 mins > > conf.d/20-imap.conf:imap_idle_notify_interval = 1 min > > conf.d/20-imap.conf:#imap_client_workarounds = outlook-idle > > conf.d/10-mail.conf.ucf-dist:# When IDLE command is running, mailbox > is checked once in a while to see if > > conf.d/10-mail.conf.ucf-dist:#mailbox_idle_check_interval = 30 secs > > conf.d/10-mail.conf:# When IDLE command is running, mailbox is checked > once in a while to see if > > conf.d/10-mail.conf:#mailbox_idle_check_interval = 30 secs > > root@fastmail:/etc/dovecot# postconf -n|grep -i idle "doveconf -n" would tell you which settings are effectively set. > root@fastmail:/etc/dovecot# Alexander
RE: Help with IMAP IDLE
Here's the full dovecot -n for you both: https://pastebin.com/C5JEJr0D From: Aki Tuomi Sent: Sunday, July 21, 2019 13:29 To: Jorge Bastos ; Jorge Bastos via dovecot Subject: Re: Help with IMAP IDLE On 21/07/2019 15:24 Jorge Bastos via dovecot mailto:dovecot@dovecot.org> > wrote: Hi, I'm becaming crazy about this! I've asked before, not no matter what i do or conf, never works. How can i make IDLE work for real with MSOutlook, so that i can receive emails when they arrive, instead of changing folder/get out and in my account? Here's my conf, should it be reflected in postconf -n (is it the running conf?): == root@fastmail:/etc/dovecot# grep -ir idle * conf.d/20-imap.conf.ucf-dist:# If nothing happens for this long while client is IDLEing, move the connection conf.d/20-imap.conf.ucf-dist:# IDLEing. conf.d/20-imap.conf.ucf-dist:#imap_idle_notify_interval = 2 mins conf.d/20-imap.conf:imapc_max_idle_time = 1440 mins conf.d/20-imap.conf:# IDLEing. conf.d/20-imap.conf:#imap_idle_notify_interval = 2 mins conf.d/20-imap.conf:imap_idle_notify_interval = 1 min conf.d/20-imap.conf:#imap_client_workarounds = outlook-idle conf.d/10-mail.conf.ucf-dist:# When IDLE command is running, mailbox is checked once in a while to see if conf.d/10-mail.conf.ucf-dist:#mailbox_idle_check_interval = 30 secs conf.d/10-mail.conf:# When IDLE command is running, mailbox is checked once in a while to see if conf.d/10-mail.conf:#mailbox_idle_check_interval = 30 secs root@fastmail:/etc/dovecot# postconf -n|grep -i idle root@fastmail:/etc/dovecot# Can you provide doveconf -n? Have you followed this https://doc.dovecot.org/configuration_manual/hibernation/ --- Aki Tuomi
Re: Help with IMAP IDLE
Am 21.07.19 um 14:24 schrieb Jorge Bastos via dovecot: Hi, [ ... ] How can i make IDLE work for real with MSOutlook, so that i can receive emails when they arrive, instead of changing folder/get out and in my account? Microsoft's Outlook is primarily meant as the client for Exchange. IMAP is been poorly implemented, across many generations of Outlook. So are you sure your Outlook even supports IMAP IDLE? And if it does, not only on the single folder you have a running connection to but for all folders? Here's my conf, should it be reflected in postconf -n (is it the running conf?): Postfix has nothing to do with that, so "postconf -n" is not required. == root@fastmail:/etc/dovecot# grep -ir idle * conf.d/20-imap.conf.ucf-dist:# If nothing happens for this long while client is IDLEing, move the connection conf.d/20-imap.conf.ucf-dist:# IDLEing. conf.d/20-imap.conf.ucf-dist:#imap_idle_notify_interval = 2 mins conf.d/20-imap.conf:imapc_max_idle_time = 1440 mins conf.d/20-imap.conf:# IDLEing. conf.d/20-imap.conf:#imap_idle_notify_interval = 2 mins conf.d/20-imap.conf:imap_idle_notify_interval = 1 min conf.d/20-imap.conf:#imap_client_workarounds = outlook-idle conf.d/10-mail.conf.ucf-dist:# When IDLE command is running, mailbox is checked once in a while to see if conf.d/10-mail.conf.ucf-dist:#mailbox_idle_check_interval = 30 secs conf.d/10-mail.conf:# When IDLE command is running, mailbox is checked once in a while to see if conf.d/10-mail.conf:#mailbox_idle_check_interval = 30 secs root@fastmail:/etc/dovecot# postconf -n|grep -i idle "doveconf -n" would tell you which settings are effectively set. root@fastmail:/etc/dovecot# Alexander
Re: Help with IMAP IDLE
On 21/07/2019 15:24 Jorge Bastos via dovecot wrote: Hi, I’m becaming crazy about this! I’ve asked before, not no matter what i do or conf, never works. How can i make IDLE work for real with MSOutlook, so that i can receive emails when they arrive, instead of changing folder/get out and in my account? Here’s my conf, should it be reflected in postconf -n (is it the running conf?): == root@fastmail:/etc/dovecot# grep -ir idle * conf.d/20-imap.conf.ucf-dist:# If nothing happens for this long while client is IDLEing, move the connection conf.d/20-imap.conf.ucf-dist:# IDLEing. conf.d/20-imap.conf.ucf-dist:#imap_idle_notify_interval = 2 mins conf.d/20-imap.conf:imapc_max_idle_time = 1440 mins conf.d/20-imap.conf:# IDLEing. conf.d/20-imap.conf:#imap_idle_notify_interval = 2 mins conf.d/20-imap.conf:imap_idle_notify_interval = 1 min conf.d/20-imap.conf:#imap_client_workarounds = outlook-idle conf.d/10-mail.conf.ucf-dist:# When IDLE command is running, mailbox is checked once in a while to see if conf.d/10-mail.conf.ucf-dist:#mailbox_idle_check_interval = 30 secs conf.d/10-mail.conf:# When IDLE command is running, mailbox is checked once in a while to see if conf.d/10-mail.conf:#mailbox_idle_check_interval = 30 secs root@fastmail:/etc/dovecot# postconf -n|grep -i idle root@fastmail:/etc/dovecot# Can you provide doveconf -n? Have you followed this https://doc.dovecot.org/configuration_manual/hibernation/ --- Aki Tuomi
Help with IMAP IDLE
Hi, I'm becaming crazy about this! I've asked before, not no matter what i do or conf, never works. How can i make IDLE work for real with MSOutlook, so that i can receive emails when they arrive, instead of changing folder/get out and in my account? Here's my conf, should it be reflected in postconf -n (is it the running conf?): == root@fastmail:/etc/dovecot# grep -ir idle * conf.d/20-imap.conf.ucf-dist:# If nothing happens for this long while client is IDLEing, move the connection conf.d/20-imap.conf.ucf-dist:# IDLEing. conf.d/20-imap.conf.ucf-dist:#imap_idle_notify_interval = 2 mins conf.d/20-imap.conf:imapc_max_idle_time = 1440 mins conf.d/20-imap.conf:# IDLEing. conf.d/20-imap.conf:#imap_idle_notify_interval = 2 mins conf.d/20-imap.conf:imap_idle_notify_interval = 1 min conf.d/20-imap.conf:#imap_client_workarounds = outlook-idle conf.d/10-mail.conf.ucf-dist:# When IDLE command is running, mailbox is checked once in a while to see if conf.d/10-mail.conf.ucf-dist:#mailbox_idle_check_interval = 30 secs conf.d/10-mail.conf:# When IDLE command is running, mailbox is checked once in a while to see if conf.d/10-mail.conf:#mailbox_idle_check_interval = 30 secs root@fastmail:/etc/dovecot# postconf -n|grep -i idle root@fastmail:/etc/dovecot#
RE: IMAP IDLE
Sorry, something more on this, I've saw the existence of outlook-idle workarround, but seems to be builtin now, so no needed: doveconf: Warning: NOTE: You can get a new clean config file with: doveconf -n > dovecot-new.conf doveconf: Warning: Obsolete setting in /etc/dovecot/conf.d/20-imap.conf:54: imap_client_workarounds=outlook-idle is no longer necessary -Original Message- From: dovecot On Behalf Of Jorge Bastos via dovecot Sent: Thursday, June 20, 2019 11:32 To: dovecot@dovecot.org Subject: RE: IMAP IDLE Hum guys, For this, i was comparing configuration from my old dbmail imap server, and i had it with time_out 30 seconds, and connection timeout 24 hours. No one will work more than 24 hours in a row.. (except for me, but i'm an idiot!) I'll set the same.. let's see the behavior. -Original Message- From: dovecot On Behalf Of Jorge Bastos via dovecot Sent: Thursday, June 20, 2019 11:04 To: dovecot@dovecot.org Subject: RE: IMAP IDLE Hi, 2.2.33.2 Well your confs are almost mine except for director_ping_idle_timeout = 30 secs submission_relay_max_idle_time = 29 mins but i think they're not imap related (i may be wrong) any other hint why is this happening? I was used to the old IMAP server than dovecot, where emails appear in the inbox, no matter if it was selected for 15m or the last 4 hours Any ideia please let me know, -Original Message- From: dovecot On Behalf Of @lbutlr via dovecot Sent: Thursday, June 20, 2019 0:20 To: dovecot@dovecot.org Subject: Re: IMAP IDLE On 19 Jun 2019, at 16:11, Jorge Bastos via dovecot wrote: > root@fastmail:/etc/dovecot# doveconf |grep -i idle default_idle_kill = > 1 mins imap_idle_notify_interval = 2 mins imapc_max_idle_time = 29 > mins mailbox_idle_check_interval = 30 secs I have: default_idle_kill = 1 mins director_ping_idle_timeout = 30 secs imap_idle_notify_interval = 2 mins imapc_max_idle_time = 29 mins mailbox_idle_check_interval = 30 secs [ A lot of idle_kill = ] submission_relay_max_idle_time = 29 mins (none of these are in doveconf -n) What version of dovecot are you running? -- Lead me not into temptation, I can find the way.
RE: IMAP IDLE
Hum guys, For this, i was comparing configuration from my old dbmail imap server, and i had it with time_out 30 seconds, and connection timeout 24 hours. No one will work more than 24 hours in a row.. (except for me, but i'm an idiot!) I'll set the same.. let's see the behavior. -Original Message- From: dovecot On Behalf Of Jorge Bastos via dovecot Sent: Thursday, June 20, 2019 11:04 To: dovecot@dovecot.org Subject: RE: IMAP IDLE Hi, 2.2.33.2 Well your confs are almost mine except for director_ping_idle_timeout = 30 secs submission_relay_max_idle_time = 29 mins but i think they're not imap related (i may be wrong) any other hint why is this happening? I was used to the old IMAP server than dovecot, where emails appear in the inbox, no matter if it was selected for 15m or the last 4 hours Any ideia please let me know, -Original Message- From: dovecot On Behalf Of @lbutlr via dovecot Sent: Thursday, June 20, 2019 0:20 To: dovecot@dovecot.org Subject: Re: IMAP IDLE On 19 Jun 2019, at 16:11, Jorge Bastos via dovecot wrote: > root@fastmail:/etc/dovecot# doveconf |grep -i idle default_idle_kill = > 1 mins imap_idle_notify_interval = 2 mins imapc_max_idle_time = 29 > mins mailbox_idle_check_interval = 30 secs I have: default_idle_kill = 1 mins director_ping_idle_timeout = 30 secs imap_idle_notify_interval = 2 mins imapc_max_idle_time = 29 mins mailbox_idle_check_interval = 30 secs [ A lot of idle_kill = ] submission_relay_max_idle_time = 29 mins (none of these are in doveconf -n) What version of dovecot are you running? -- Lead me not into temptation, I can find the way.
RE: IMAP IDLE
Hi, 2.2.33.2 Well your confs are almost mine except for director_ping_idle_timeout = 30 secs submission_relay_max_idle_time = 29 mins but i think they're not imap related (i may be wrong) any other hint why is this happening? I was used to the old IMAP server than dovecot, where emails appear in the inbox, no matter if it was selected for 15m or the last 4 hours Any ideia please let me know, -Original Message- From: dovecot On Behalf Of @lbutlr via dovecot Sent: Thursday, June 20, 2019 0:20 To: dovecot@dovecot.org Subject: Re: IMAP IDLE On 19 Jun 2019, at 16:11, Jorge Bastos via dovecot wrote: > root@fastmail:/etc/dovecot# doveconf |grep -i idle default_idle_kill = > 1 mins imap_idle_notify_interval = 2 mins imapc_max_idle_time = 29 > mins mailbox_idle_check_interval = 30 secs I have: default_idle_kill = 1 mins director_ping_idle_timeout = 30 secs imap_idle_notify_interval = 2 mins imapc_max_idle_time = 29 mins mailbox_idle_check_interval = 30 secs [ A lot of idle_kill = ] submission_relay_max_idle_time = 29 mins (none of these are in doveconf -n) What version of dovecot are you running? -- Lead me not into temptation, I can find the way.
Re: IMAP IDLE
On 19 Jun 2019, at 16:11, Jorge Bastos via dovecot wrote: > root@fastmail:/etc/dovecot# doveconf |grep -i idle > default_idle_kill = 1 mins > imap_idle_notify_interval = 2 mins > imapc_max_idle_time = 29 mins > mailbox_idle_check_interval = 30 secs I have: default_idle_kill = 1 mins director_ping_idle_timeout = 30 secs imap_idle_notify_interval = 2 mins imapc_max_idle_time = 29 mins mailbox_idle_check_interval = 30 secs [ A lot of idle_kill = ] submission_relay_max_idle_time = 29 mins (none of these are in doveconf -n) What version of dovecot are you running? -- Lead me not into temptation, I can find the way.
IMAP IDLE
Hi, With outlook 2016+ i've seen that IDLE may be missing some configuration. Almost all time, when i'm in the inbox, i don't get new emails if no activity for 1 or 2 minutes (i think), i have to get out of the account and select the inbox or click other folder in the account and go to inbox again for them to appear. My idle conf's are the defaults, the one's bellow. Is there anything else that i need to make it work always and the change folders is not needed for outlook clients? root@fastmail:/etc/dovecot# doveconf |grep -i idle default_idle_kill = 1 mins imap_idle_notify_interval = 2 mins imapc_max_idle_time = 29 mins mailbox_idle_check_interval = 30 secs
Re: Possible IMAP IDLE bug in Dovecot 2.2.18 and 2.2.25
On Wed, Aug 24, 2016 at 12:49:02PM +0300, Timo Sirainen wrote: > On 23 Aug 2016, at 15:08, cleber-lis...@inetweb.com.br wrote: > > > > Hello Guys, > > I guess that I found a bug in Dovecot 2.2.18 and 2.2.25 versions. The > > problem it's when I try to connect in a Dovecot used a proxy to another > > e-mail server (in our case it's a Smartermail Server) the DoveCot send a > > lot of IDLE commands to the destination server. With that, the LOG files > > grow and grow and grow :( > > > > I make a test with 1 connection only and if you see the log file in the > > same second the dovecot send 25, 40 IDLE commands. But, when I disconnect > > the client (outlook 2013) the dovecot continue to send the IDLE command for > > some seconds. > > After login Dovecot proxy no longer understands anything about the traffic. > It simply keeps proxying the IMAP traffic between the client and server. So > Dovecot isn't the one generating the IDLE commands, it's Outlook. > > > If I try to connect directly to Smartermail with Outlook this don't > > occurrs. > > That is stranger then. Maybe it has something to do with having a different > CAPABILITY response. You could try setting imap_capability setting to same as > what Smartermail announces. Other than that I can't really think of anything > specific that you could do or we could fix on Dovecot code. Older Outlook client software is simply just not keeping up to standard. Unless M$ cares to remove SSL2 and SSL3 support from their software, it is easier just to update your client e-mail software which is more current and compliant to recent 2015+ standarnds. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Time for the USA to hold a referendum on its republic and vote to dissolve!!
RES: RES: Possible IMAP IDLE bug in Dovecot 2.2.18 and 2.2.25
Hello Aki and Timo, I disable the IDLE at CAPABILITY in Dovecot and solved my problem: imap_capability = LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE -Mensagem original- De: Aki Tuomi [mailto:aki.tu...@dovecot.fi] Enviada em: quarta-feira, 24 de agosto de 2016 11:51 Para: Dovecot Mailing List ; Cleber @ Listas Assunto: Re: RES: Possible IMAP IDLE bug in Dovecot 2.2.18 and 2.2.25 You should probably update your proxy to provide the same capability list to your clients as your SmarterMail backend (with few extra things). That is imap_capability = IMAP4rev1 STARTTLS UIDPLUS QUOTA XLIST CHILDREN AUTH=PLAIN AUTH=LOGIN Aki > On August 24, 2016 at 5:43 PM "Cleber @ Listas" > wrote: > > > Hello Timo, > > The capability result from dovecot and Smartermail: > > Dovecot: > * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE > IDLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready. > > Smartermail: > * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 UIDPLUS QUOTA XLIST CHILDREN > > If I connect directly to Smartermail the Outlook don't send the IDLE > command (only NOOP, because the Smartermail don't send the IDLE in > CAPABILITY). > But, it's with time interval better than from Dovecot (a lot in same > second) > > 10:25:11 [201.74.248.186][57965505] connected at 24/08/2016 10:25:11 > 10:25:11 [201.74.248.186][57965505] command: 1ope CAPABILITY > 10:25:11 [201.74.248.186][57965505] command: 9mv2 LOGIN "myaccount@mydomain" > > 10:25:11 [201.74.248.186][57965505] myaccount@mydomain logged in > 10:25:11 [201.74.248.186][57965505] command: rvzd LSUB "" "*" > 10:25:11 [201.74.248.186][57965505] command: rh9g SELECT "INBOX" > 10:25:11 [201.74.248.186][57965505] response: * 919 EXISTS > 10:25:11 [201.74.248.186][57965505] response: * 0 RECENT > 10:25:11 [201.74.248.186][57965505] response: * OK [UNSEEN 904] > Message 904 is first unseen > 10:25:11 [201.74.248.186][57965505] response: * OK [UIDVALIDITY 1] > UIDs valid > 10:25:11 [201.74.248.186][57965505] response: * OK [UIDNEXT 26849] > Predicted next UID > 10:25:11 [201.74.248.186][57965505] response: * FLAGS (\Answered > \Flagged \Deleted \Seen \Draft) > 10:25:11 [201.74.248.186][57965505] response: * OK [PERMANENTFLAGS > (\Answered \Flagged \Deleted \Seen \Draft)] > 10:25:11 [201.74.248.186][57965505] response: rh9g OK [READ-WRITE] > SELECT completed > 10:25:11 [201.74.248.186][57965505] command: ve5e FETCH 919 (UID) > 10:25:11 [201.74.248.186][57965505] command: 8ixa UID FETCH 1:26848 > (UID > FLAGS) > 10:25:14 [201.74.248.186][57965505] command: t874 UID STORE 26846 > +FLAGS.SILENT (\Seen) > 10:26:32 [201.74.248.186][57965505] command: rmcb NOOP > 10:26:32 [201.74.248.186][57965505] response: rmcb OK NOOP completed > 10:28:39 [201.74.248.186][57965505] command: qs5n NOOP > 10:28:39 [201.74.248.186][57965505] response: qs5n OK NOOP Completed > 10:31:01 [201.74.248.186][57965505] command: k9v0 NOOP > 10:31:01 [201.74.248.186][57965505] response: k9v0 OK NOOP completed > 10:33:01 [201.74.248.186][57965505] command: vw8w NOOP > 10:33:01 [201.74.248.186][57965505] response: vw8w OK NOOP completed > 10:35:01 [201.74.248.186][57965505] command: qhag NOOP > 10:35:01 [201.74.248.186][57965505] response: qhag OK NOOP completed > 10:37:01 [201.74.248.186][57965505] command: so7b NOOP > 10:37:01 [201.74.248.186][57965505] response: so7b OK NOOP completed > 10:39:01 [201.74.248.186][57965505] command: wclw NOOP > 10:39:01 [201.74.248.186][57965505] response: wclw OK NOOP completed > 10:39:36 [201.74.248.186][13534103] disconnected at 24/08/2016 > 10:39:36 > > > > > > -Mensagem original- > De: dovecot [mailto:dovecot-boun...@dovecot.org] Em nome de Timo > Sirainen Enviada em: quarta-feira, 24 de agosto de 2016 06:49 > Para: cleber-lis...@inetweb.com.br > Cc: dovecot@dovecot.org > Assunto: Re: Possible IMAP IDLE bug in Dovecot 2.2.18 and 2.2.25 > > On 23 Aug 2016, at 15:08, cleber-lis...@inetweb.com.br wrote: > > > > Hello Guys, > > I guess that I found a bug in Dovecot 2.2.18 and 2.2.25 versions. > > The problem it's when I try to connect in a Dovecot used a proxy to > > another e-mail server (in our case it's a Smartermail Server) the > > DoveCot send a lot of IDLE commands to the destination server. With > > that, the LOG files grow and grow and grow :( > > > > I make a test with 1 connection only and if you see the log file in > > the same second the dovecot send 25, 40 IDLE commands. But, when I > > disconnect the client (outlook 2013) the dovecot continue to send > > the IDLE command for some seconds. > > After login Dovecot pr
Re: RES: Possible IMAP IDLE bug in Dovecot 2.2.18 and 2.2.25
You should probably update your proxy to provide the same capability list to your clients as your SmarterMail backend (with few extra things). That is imap_capability = IMAP4rev1 STARTTLS UIDPLUS QUOTA XLIST CHILDREN AUTH=PLAIN AUTH=LOGIN Aki > On August 24, 2016 at 5:43 PM "Cleber @ Listas" > wrote: > > > Hello Timo, > > The capability result from dovecot and Smartermail: > > Dovecot: > * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE > STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready. > > Smartermail: > * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 UIDPLUS QUOTA XLIST CHILDREN > > If I connect directly to Smartermail the Outlook don't send the IDLE command > (only NOOP, because the Smartermail don't send the IDLE in CAPABILITY). > But, it's with time interval better than from Dovecot (a lot in same second) > > 10:25:11 [201.74.248.186][57965505] connected at 24/08/2016 10:25:11 > 10:25:11 [201.74.248.186][57965505] command: 1ope CAPABILITY > 10:25:11 [201.74.248.186][57965505] command: 9mv2 LOGIN "myaccount@mydomain" > > 10:25:11 [201.74.248.186][57965505] myaccount@mydomain logged in > 10:25:11 [201.74.248.186][57965505] command: rvzd LSUB "" "*" > 10:25:11 [201.74.248.186][57965505] command: rh9g SELECT "INBOX" > 10:25:11 [201.74.248.186][57965505] response: * 919 EXISTS > 10:25:11 [201.74.248.186][57965505] response: * 0 RECENT > 10:25:11 [201.74.248.186][57965505] response: * OK [UNSEEN 904] Message 904 > is first unseen > 10:25:11 [201.74.248.186][57965505] response: * OK [UIDVALIDITY 1] UIDs > valid > 10:25:11 [201.74.248.186][57965505] response: * OK [UIDNEXT 26849] Predicted > next UID > 10:25:11 [201.74.248.186][57965505] response: * FLAGS (\Answered \Flagged > \Deleted \Seen \Draft) > 10:25:11 [201.74.248.186][57965505] response: * OK [PERMANENTFLAGS > (\Answered \Flagged \Deleted \Seen \Draft)] > 10:25:11 [201.74.248.186][57965505] response: rh9g OK [READ-WRITE] SELECT > completed > 10:25:11 [201.74.248.186][57965505] command: ve5e FETCH 919 (UID) > 10:25:11 [201.74.248.186][57965505] command: 8ixa UID FETCH 1:26848 (UID > FLAGS) > 10:25:14 [201.74.248.186][57965505] command: t874 UID STORE 26846 > +FLAGS.SILENT (\Seen) > 10:26:32 [201.74.248.186][57965505] command: rmcb NOOP > 10:26:32 [201.74.248.186][57965505] response: rmcb OK NOOP completed > 10:28:39 [201.74.248.186][57965505] command: qs5n NOOP > 10:28:39 [201.74.248.186][57965505] response: qs5n OK NOOP Completed > 10:31:01 [201.74.248.186][57965505] command: k9v0 NOOP > 10:31:01 [201.74.248.186][57965505] response: k9v0 OK NOOP completed > 10:33:01 [201.74.248.186][57965505] command: vw8w NOOP > 10:33:01 [201.74.248.186][57965505] response: vw8w OK NOOP completed > 10:35:01 [201.74.248.186][57965505] command: qhag NOOP > 10:35:01 [201.74.248.186][57965505] response: qhag OK NOOP completed > 10:37:01 [201.74.248.186][57965505] command: so7b NOOP > 10:37:01 [201.74.248.186][57965505] response: so7b OK NOOP completed > 10:39:01 [201.74.248.186][57965505] command: wclw NOOP > 10:39:01 [201.74.248.186][57965505] response: wclw OK NOOP completed > 10:39:36 [201.74.248.186][13534103] disconnected at 24/08/2016 10:39:36 > > > > > > -Mensagem original- > De: dovecot [mailto:dovecot-boun...@dovecot.org] Em nome de Timo Sirainen > Enviada em: quarta-feira, 24 de agosto de 2016 06:49 > Para: cleber-lis...@inetweb.com.br > Cc: dovecot@dovecot.org > Assunto: Re: Possible IMAP IDLE bug in Dovecot 2.2.18 and 2.2.25 > > On 23 Aug 2016, at 15:08, cleber-lis...@inetweb.com.br wrote: > > > > Hello Guys, > > I guess that I found a bug in Dovecot 2.2.18 and 2.2.25 versions. The > > problem it's when I try to connect in a Dovecot used a proxy to > > another e-mail server (in our case it's a Smartermail Server) the > > DoveCot send a lot of IDLE commands to the destination server. With > > that, the LOG files grow and grow and grow :( > > > > I make a test with 1 connection only and if you see the log file in > > the same second the dovecot send 25, 40 IDLE commands. But, when I > > disconnect the client (outlook 2013) the dovecot continue to send the > > IDLE command for some seconds. > > After login Dovecot proxy no longer understands anything about the traffic. > It simply keeps proxying the IMAP traffic between the client and server. So > Dovecot isn't the one generating the IDLE commands, it's Outlook. > > > If I try to connect directly to Smartermail with Outlook this don't > > occurrs. > > That is stranger then. Maybe it has something to do with having a different > CAPABILITY response. You could try setting imap_capability setting to same > as what Smartermail announces. Other than that I can't really think of > anything specific that you could do or we could fix on Dovecot code.
RES: Possible IMAP IDLE bug in Dovecot 2.2.18 and 2.2.25
Hello Timo, The capability result from dovecot and Smartermail: Dovecot: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready. Smartermail: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 UIDPLUS QUOTA XLIST CHILDREN If I connect directly to Smartermail the Outlook don't send the IDLE command (only NOOP, because the Smartermail don't send the IDLE in CAPABILITY). But, it's with time interval better than from Dovecot (a lot in same second) 10:25:11 [201.74.248.186][57965505] connected at 24/08/2016 10:25:11 10:25:11 [201.74.248.186][57965505] command: 1ope CAPABILITY 10:25:11 [201.74.248.186][57965505] command: 9mv2 LOGIN "myaccount@mydomain" 10:25:11 [201.74.248.186][57965505] myaccount@mydomain logged in 10:25:11 [201.74.248.186][57965505] command: rvzd LSUB "" "*" 10:25:11 [201.74.248.186][57965505] command: rh9g SELECT "INBOX" 10:25:11 [201.74.248.186][57965505] response: * 919 EXISTS 10:25:11 [201.74.248.186][57965505] response: * 0 RECENT 10:25:11 [201.74.248.186][57965505] response: * OK [UNSEEN 904] Message 904 is first unseen 10:25:11 [201.74.248.186][57965505] response: * OK [UIDVALIDITY 1] UIDs valid 10:25:11 [201.74.248.186][57965505] response: * OK [UIDNEXT 26849] Predicted next UID 10:25:11 [201.74.248.186][57965505] response: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 10:25:11 [201.74.248.186][57965505] response: * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft)] 10:25:11 [201.74.248.186][57965505] response: rh9g OK [READ-WRITE] SELECT completed 10:25:11 [201.74.248.186][57965505] command: ve5e FETCH 919 (UID) 10:25:11 [201.74.248.186][57965505] command: 8ixa UID FETCH 1:26848 (UID FLAGS) 10:25:14 [201.74.248.186][57965505] command: t874 UID STORE 26846 +FLAGS.SILENT (\Seen) 10:26:32 [201.74.248.186][57965505] command: rmcb NOOP 10:26:32 [201.74.248.186][57965505] response: rmcb OK NOOP completed 10:28:39 [201.74.248.186][57965505] command: qs5n NOOP 10:28:39 [201.74.248.186][57965505] response: qs5n OK NOOP Completed 10:31:01 [201.74.248.186][57965505] command: k9v0 NOOP 10:31:01 [201.74.248.186][57965505] response: k9v0 OK NOOP completed 10:33:01 [201.74.248.186][57965505] command: vw8w NOOP 10:33:01 [201.74.248.186][57965505] response: vw8w OK NOOP completed 10:35:01 [201.74.248.186][57965505] command: qhag NOOP 10:35:01 [201.74.248.186][57965505] response: qhag OK NOOP completed 10:37:01 [201.74.248.186][57965505] command: so7b NOOP 10:37:01 [201.74.248.186][57965505] response: so7b OK NOOP completed 10:39:01 [201.74.248.186][57965505] command: wclw NOOP 10:39:01 [201.74.248.186][57965505] response: wclw OK NOOP completed 10:39:36 [201.74.248.186][13534103] disconnected at 24/08/2016 10:39:36 -Mensagem original- De: dovecot [mailto:dovecot-boun...@dovecot.org] Em nome de Timo Sirainen Enviada em: quarta-feira, 24 de agosto de 2016 06:49 Para: cleber-lis...@inetweb.com.br Cc: dovecot@dovecot.org Assunto: Re: Possible IMAP IDLE bug in Dovecot 2.2.18 and 2.2.25 On 23 Aug 2016, at 15:08, cleber-lis...@inetweb.com.br wrote: > > Hello Guys, > I guess that I found a bug in Dovecot 2.2.18 and 2.2.25 versions. The > problem it's when I try to connect in a Dovecot used a proxy to > another e-mail server (in our case it's a Smartermail Server) the > DoveCot send a lot of IDLE commands to the destination server. With > that, the LOG files grow and grow and grow :( > > I make a test with 1 connection only and if you see the log file in > the same second the dovecot send 25, 40 IDLE commands. But, when I > disconnect the client (outlook 2013) the dovecot continue to send the > IDLE command for some seconds. After login Dovecot proxy no longer understands anything about the traffic. It simply keeps proxying the IMAP traffic between the client and server. So Dovecot isn't the one generating the IDLE commands, it's Outlook. > If I try to connect directly to Smartermail with Outlook this don't > occurrs. That is stranger then. Maybe it has something to do with having a different CAPABILITY response. You could try setting imap_capability setting to same as what Smartermail announces. Other than that I can't really think of anything specific that you could do or we could fix on Dovecot code.
RES: Possible IMAP IDLE bug in Dovecot 2.2.18 and 2.2.25
Hello Aki, The Smartermail don't support IDLE command at CAPABILITY: Dovecot: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready. Smartermail: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 UIDPLUS QUOTA XLIST CHILDREN In this case, would not the because Dovecot send the IDLE command to SmarterMail. -Mensagem original- De: dovecot [mailto:dovecot-boun...@dovecot.org] Em nome de Aki Tuomi Enviada em: terça-feira, 23 de agosto de 2016 13:25 Para: dovecot@dovecot.org Assunto: Re: Possible IMAP IDLE bug in Dovecot 2.2.18 and 2.2.25 On 23.08.2016 19:15, Aki Tuomi wrote: > > > On 23.08.2016 15:08, cleber-lis...@inetweb.com.br wrote: >> Hello Guys, >> I guess that I found a bug in Dovecot 2.2.18 and 2.2.25 versions. >> The problem it's when I try to connect in a Dovecot used a proxy to >> another e-mail server (in our case it's a Smartermail Server) the >> DoveCot send a lot of IDLE commands to the destination server. With >> that, the LOG files grow and grow and grow :( >> I make a test with 1 connection only and if you see the log file >> in the same second the dovecot send 25, 40 IDLE commands. But, when I >> disconnect the client (outlook 2013) the dovecot continue to send the >> IDLE command for some seconds. >> If I try to connect directly to Smartermail with Outlook this >> don't occurrs. >> > > Just to be sure, the behaviour you are expecting is that IDLE is not > used, right? > > Aki Also, looking at the code, IDLE is only used if your server claims to understand it, so could you do following: telnet backend-host backend-port a CAPABILITY a LOGIN username password a CAPABILITY a LOGOUT and provide the output. Aki
Re: Possible IMAP IDLE bug in Dovecot 2.2.18 and 2.2.25
On 23 Aug 2016, at 15:08, cleber-lis...@inetweb.com.br wrote: > > Hello Guys, > I guess that I found a bug in Dovecot 2.2.18 and 2.2.25 versions. The > problem it's when I try to connect in a Dovecot used a proxy to another > e-mail server (in our case it's a Smartermail Server) the DoveCot send a > lot of IDLE commands to the destination server. With that, the LOG files > grow and grow and grow :( > > I make a test with 1 connection only and if you see the log file in the > same second the dovecot send 25, 40 IDLE commands. But, when I disconnect > the client (outlook 2013) the dovecot continue to send the IDLE command for > some seconds. After login Dovecot proxy no longer understands anything about the traffic. It simply keeps proxying the IMAP traffic between the client and server. So Dovecot isn't the one generating the IDLE commands, it's Outlook. > If I try to connect directly to Smartermail with Outlook this don't > occurrs. That is stranger then. Maybe it has something to do with having a different CAPABILITY response. You could try setting imap_capability setting to same as what Smartermail announces. Other than that I can't really think of anything specific that you could do or we could fix on Dovecot code.
Possible IMAP IDLE bug in Dovecot 2.2.18 and 2.2.25
Hello Guys, I guess that I found a bug in Dovecot 2.2.18 and 2.2.25 versions. The problem it's when I try to connect in a Dovecot used a proxy to another e-mail server (in our case it's a Smartermail Server) the DoveCot send a lot of IDLE commands to the destination server. With that, the LOG files grow and grow and grow :( I make a test with 1 connection only and if you see the log file in the same second the dovecot send 25, 40 IDLE commands. But, when I disconnect the client (outlook 2013) the dovecot continue to send the IDLE command for some seconds. If I try to connect directly to Smartermail with Outlook this don't occurrs. Bellow the LOG FILE: 16:08:08 [192.168.202.11][21425199] connected at 22/08/2016 16:08:08 16:08:08 [192.168.202.11][21425199] command: C CAPABILITY 16:08:09 [192.168.202.11][21425199] command: L LOGIN "cle...@testdomain.com.br" 16:08:09 [192.168.202.11][21425199] cle...@testdomain.com.br logged in 16:08:09 [192.168.202.11][21425199] command: 36mc IDLE 16:08:09 [192.168.202.11][21425199] command: 2x04 ID ("name" "Microsoft Outlook" "version" "15.0.4849.1000") 16:08:09 [192.168.202.11][21425199] response: 2x04 BAD Command does not exist or is not implemented 16:08:09 [192.168.202.11][21425199] command: g4zp LSUB "" "*" 16:08:09 [192.168.202.11][21425199] command: pv81 IDLE 16:08:09 [192.168.202.11][21425199] command: 2it1 SELECT "INBOX" 16:08:09 [192.168.202.11][21425199] response: * 912 EXISTS 16:08:09 [192.168.202.11][21425199] response: * 0 RECENT 16:08:09 [192.168.202.11][21425199] response: * OK [UNSEEN 904] Message 904 is first unseen 16:08:09 [192.168.202.11][21425199] response: * OK [UIDVALIDITY 1] UIDs valid 16:08:09 [192.168.202.11][21425199] response: * OK [UIDNEXT 26830] Predicted next UID 16:08:09 [192.168.202.11][21425199] response: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 16:08:09 [192.168.202.11][21425199] response: * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft)] 16:08:09 [192.168.202.11][21425199] response: 2it1 OK [READ-WRITE] SELECT completed 16:08:09 [192.168.202.11][21425199] command: a6tj IDLE 16:08:09 [192.168.202.11][21425199] command: bn09 FETCH 912 (UID) 16:08:09 [192.168.202.11][21425199] command: 78b6 IDLE 16:08:09 [192.168.202.11][21425199] command: q13w UID FETCH 1:26829 (UID FLAGS) 16:08:09 [192.168.202.11][21425199] command: p02s IDLE 16:08:09 [192.168.202.11][21425199] command: 9de9 IDLE 16:08:09 [192.168.202.11][21425199] command: xjyf IDLE 16:08:09 [192.168.202.11][21425199] command: holb IDLE 16:08:09 [192.168.202.11][21425199] command: sfbq IDLE 16:08:09 [192.168.202.11][21425199] command: tuvb IDLE 16:08:09 [192.168.202.11][21425199] command: hv13 IDLE 16:08:09 [192.168.202.11][21425199] command: ctgw IDLE 16:08:09 [192.168.202.11][21425199] command: s00g IDLE 16:08:09 [192.168.202.11][21425199] command: 9zx1 IDLE 16:08:09 [192.168.202.11][21425199] command: dtu2 IDLE 16:08:09 [192.168.202.11][21425199] command: 1brp IDLE 16:08:09 [192.168.202.11][21425199] command: vhds IDLE 16:08:09 [192.168.202.11][21425199] command: cp9s IDLE 16:08:09 [192.168.202.11][21425199] command: hx1b IDLE 16:08:09 [192.168.202.11][21425199] command: 6thy IDLE 16:08:09 [192.168.202.11][21425199] command: 4ert IDLE 16:08:09 [192.168.202.11][21425199] command: cy32 IDLE 16:08:09 [192.168.202.11][21425199] command: z7ku IDLE 16:08:09 [192.168.202.11][21425199] command: xeqd IDLE 16:08:09 [192.168.202.11][21425199] command: gqis IDLE 16:08:09 [192.168.202.11][21425199] command: bdz2 IDLE 16:08:09 [192.168.202.11][21425199] command: zzyq IDLE 16:08:09 [192.168.202.11][21425199] command: 41do IDLE 16:08:09 [192.168.202.11][21425199] command: 7k73 IDLE 16:08:10 [192.168.202.11][21425199] command: 5989 IDLE 16:08:10 [192.168.202.11][21425199] command: lyt4 IDLE 16:08:10 [192.168.202.11][21425199] command: 8ji4 IDLE 16:08:10 [192.168.202.11][21425199] command: pt5b IDLE 16:08:10 [192.168.202.11][21425199] command: ha2s IDLE 16:08:10 [192.168.202.11][21425199] command: ay0x IDLE 16:08:10 [192.168.202.11][21425199] command: t66x IDLE 16:08:10 [192.168.202.11][21425199] command: pf4j IDLE 16:08:10 [192.168.202.11][21425199] command: 2q5x IDLE 16:08:10 [192.168.202.11][21425199] command: wdup IDLE 16:08:10 [192.168.202.11][21425199] command: ii7b IDLE 16:08:10 [192.168.202.11][21425199] command: 2g4k IDLE 16:08:10 [192.168.202.11][21425199] command: lxxg IDLE 16:08:10 [192.168.202.11][21425199] command: vilu IDLE 16:08:10 [192.168.202.11][21425199] command: ms05 IDLE 16:08:10 [192.168.202.11][21425199] command: 8ugb IDLE 16:08:10 [192.168.202.11][21425199] command: 1vfo IDLE 16:08:10 [192.168.202.11][21425199] command: s78s IDLE 16:08:10 [192.168.202.11][21425199] command: 7h2k IDLE 16:08:10 [192.168.202.11][21425199] command: 0het IDLE 16:08:10 [192.168.202.11][21425199] command: rgj7 IDLE 16:08:10 [192.168.202.11][21425199] command: myx3 IDLE 16:08:10 [192.168.202.11][21425199] command: oi5h IDLE 16:08:10 [19
Re: Possible IMAP IDLE bug in Dovecot 2.2.18 and 2.2.25
On 23.08.2016 19:15, Aki Tuomi wrote: On 23.08.2016 15:08, cleber-lis...@inetweb.com.br wrote: Hello Guys, I guess that I found a bug in Dovecot 2.2.18 and 2.2.25 versions. The problem it's when I try to connect in a Dovecot used a proxy to another e-mail server (in our case it's a Smartermail Server) the DoveCot send a lot of IDLE commands to the destination server. With that, the LOG files grow and grow and grow :( I make a test with 1 connection only and if you see the log file in the same second the dovecot send 25, 40 IDLE commands. But, when I disconnect the client (outlook 2013) the dovecot continue to send the IDLE command for some seconds. If I try to connect directly to Smartermail with Outlook this don't occurrs. Just to be sure, the behaviour you are expecting is that IDLE is not used, right? Aki Also, looking at the code, IDLE is only used if your server claims to understand it, so could you do following: telnet backend-host backend-port a CAPABILITY a LOGIN username password a CAPABILITY a LOGOUT and provide the output. Aki
Re: Possible IMAP IDLE bug in Dovecot 2.2.18 and 2.2.25
On 23.08.2016 15:08, cleber-lis...@inetweb.com.br wrote: Hello Guys, I guess that I found a bug in Dovecot 2.2.18 and 2.2.25 versions. The problem it's when I try to connect in a Dovecot used a proxy to another e-mail server (in our case it's a Smartermail Server) the DoveCot send a lot of IDLE commands to the destination server. With that, the LOG files grow and grow and grow :( I make a test with 1 connection only and if you see the log file in the same second the dovecot send 25, 40 IDLE commands. But, when I disconnect the client (outlook 2013) the dovecot continue to send the IDLE command for some seconds. If I try to connect directly to Smartermail with Outlook this don't occurrs. Just to be sure, the behaviour you are expecting is that IDLE is not used, right? Aki
Possible IMAP IDLE bug in Dovecot 2.2.18 and 2.2.25
Hello Guys, I guess that I found a bug in Dovecot 2.2.18 and 2.2.25 versions. The problem it's when I try to connect in a Dovecot used a proxy to another e-mail server (in our case it's a Smartermail Server) the DoveCot send a lot of IDLE commands to the destination server. With that, the LOG files grow and grow and grow :( I make a test with 1 connection only and if you see the log file in the same second the dovecot send 25, 40 IDLE commands. But, when I disconnect the client (outlook 2013) the dovecot continue to send the IDLE command for some seconds. If I try to connect directly to Smartermail with Outlook this don't occurrs. Bellow the LOG FILE: 16:08:08 [192.168.202.11][21425199] connected at 22/08/2016 16:08:08 16:08:08 [192.168.202.11][21425199] command: C CAPABILITY 16:08:09 [192.168.202.11][21425199] command: L LOGIN "cle...@testdomain.com.br" 16:08:09 [192.168.202.11][21425199] cle...@testdomain.com.br logged in 16:08:09 [192.168.202.11][21425199] command: 36mc IDLE 16:08:09 [192.168.202.11][21425199] command: 2x04 ID ("name" "Microsoft Outlook" "version" "15.0.4849.1000") 16:08:09 [192.168.202.11][21425199] response: 2x04 BAD Command does not exist or is not implemented 16:08:09 [192.168.202.11][21425199] command: g4zp LSUB "" "*" 16:08:09 [192.168.202.11][21425199] command: pv81 IDLE 16:08:09 [192.168.202.11][21425199] command: 2it1 SELECT "INBOX" 16:08:09 [192.168.202.11][21425199] response: * 912 EXISTS 16:08:09 [192.168.202.11][21425199] response: * 0 RECENT 16:08:09 [192.168.202.11][21425199] response: * OK [UNSEEN 904] Message 904 is first unseen 16:08:09 [192.168.202.11][21425199] response: * OK [UIDVALIDITY 1] UIDs valid 16:08:09 [192.168.202.11][21425199] response: * OK [UIDNEXT 26830] Predicted next UID 16:08:09 [192.168.202.11][21425199] response: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 16:08:09 [192.168.202.11][21425199] response: * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft)] 16:08:09 [192.168.202.11][21425199] response: 2it1 OK [READ-WRITE] SELECT completed 16:08:09 [192.168.202.11][21425199] command: a6tj IDLE 16:08:09 [192.168.202.11][21425199] command: bn09 FETCH 912 (UID) 16:08:09 [192.168.202.11][21425199] command: 78b6 IDLE 16:08:09 [192.168.202.11][21425199] command: q13w UID FETCH 1:26829 (UID FLAGS) 16:08:09 [192.168.202.11][21425199] command: p02s IDLE 16:08:09 [192.168.202.11][21425199] command: 9de9 IDLE 16:08:09 [192.168.202.11][21425199] command: xjyf IDLE 16:08:09 [192.168.202.11][21425199] command: holb IDLE 16:08:09 [192.168.202.11][21425199] command: sfbq IDLE 16:08:09 [192.168.202.11][21425199] command: tuvb IDLE 16:08:09 [192.168.202.11][21425199] command: hv13 IDLE 16:08:09 [192.168.202.11][21425199] command: ctgw IDLE 16:08:09 [192.168.202.11][21425199] command: s00g IDLE 16:08:09 [192.168.202.11][21425199] command: 9zx1 IDLE 16:08:09 [192.168.202.11][21425199] command: dtu2 IDLE 16:08:09 [192.168.202.11][21425199] command: 1brp IDLE 16:08:09 [192.168.202.11][21425199] command: vhds IDLE 16:08:09 [192.168.202.11][21425199] command: cp9s IDLE 16:08:09 [192.168.202.11][21425199] command: hx1b IDLE 16:08:09 [192.168.202.11][21425199] command: 6thy IDLE 16:08:09 [192.168.202.11][21425199] command: 4ert IDLE 16:08:09 [192.168.202.11][21425199] command: cy32 IDLE 16:08:09 [192.168.202.11][21425199] command: z7ku IDLE 16:08:09 [192.168.202.11][21425199] command: xeqd IDLE 16:08:09 [192.168.202.11][21425199] command: gqis IDLE 16:08:09 [192.168.202.11][21425199] command: bdz2 IDLE 16:08:09 [192.168.202.11][21425199] command: zzyq IDLE 16:08:09 [192.168.202.11][21425199] command: 41do IDLE 16:08:09 [192.168.202.11][21425199] command: 7k73 IDLE 16:08:10 [192.168.202.11][21425199] command: 5989 IDLE 16:08:10 [192.168.202.11][21425199] command: lyt4 IDLE 16:08:10 [192.168.202.11][21425199] command: 8ji4 IDLE 16:08:10 [192.168.202.11][21425199] command: pt5b IDLE 16:08:10 [192.168.202.11][21425199] command: ha2s IDLE 16:08:10 [192.168.202.11][21425199] command: ay0x IDLE 16:08:10 [192.168.202.11][21425199] command: t66x IDLE 16:08:10 [192.168.202.11][21425199] command: pf4j IDLE 16:08:10 [192.168.202.11][21425199] command: 2q5x IDLE 16:08:10 [192.168.202.11][21425199] command: wdup IDLE 16:08:10 [192.168.202.11][21425199] command: ii7b IDLE 16:08:10 [192.168.202.11][21425199] command: 2g4k IDLE 16:08:10 [192.168.202.11][21425199] command: lxxg IDLE 16:08:10 [192.168.202.11][21425199] command: vilu IDLE 16:08:10 [192.168.202.11][21425199] command: ms05 IDLE 16:08:10 [192.168.202.11][21425199] command: 8ugb IDLE 16:08:10 [192.168.202.11][21425199] command: 1vfo IDLE 16:08:10 [192.168.202.11][21425199] command: s78s IDLE 16:08:10 [192.168.202.11][21425199] command: 7h2k IDLE 16:08:10 [192.168.202.11][21425199] command: 0het IDLE 16:08:10 [192.168.202.11][21425199] command: rgj7 IDLE 16:08:10 [192.168.202.11][21425199] command: myx3 IDLE 16:08:10 [192.168.202.11][21425199] command: oi5h IDLE 16:08:10 [192.1
Re: IMAP Idle
The IDLE disconnection timeout is hardwired in the Dovecot code http://wiki.dovecot.org/Timeouts It's set to the RFC minimum of 30min. I am ok if connection is closed automatically after 30 min if client is not responding but connection is not being closed even after 2 days. Hmm. I can't think of why dovecot wouldn't time out. I think maybe the problem is with your webmail system -- it's not detecting when a client connection goes away and releasing all the resources associated with that user. This is not a typical problem though -- most webmail software do not keep persistent IMAP connections open during a session unless they use some IMAP proxy. Are your IMAP connections connected to the webmail server or an IMAP proxy, and is that connection active (despite webmail user disappearing)? Joseph Tam
Re: IMAP Idle
I am ok if connection is closed automatically after 30 min if client is not responding but connection is not being closed even after 2 days. On Sat, Mar 26, 2016 at 2:52 AM, Joseph Tam wrote: > Joy wrote: > > We have implement imap idle in web mail built by us to have >> push mail feature. IMAP idle working perfectly with browser notification >> and we are happy with it but having one issue with users who close the >> browser directly and never logout in that case there are number of idle >> connection which are not in use and users are unable to login once IP wise >> connection limit is reached. >> >> Dovecot is not closing connection which are not in use, is there any >> setting available which can help me to resolve this issue. >> > > I had much the same situation where a user signed up with a roaming > wireless carrier that assigned a new IP to the client whenever it got > passed from one access point to another. Good fun when this person > took a bus ride through the city, leaving orphaned connections in > its wake. > > The IDLE disconnection timeout is hardwired in the Dovecot code > > http://wiki.dovecot.org/Timeouts > > It's set to the RFC minimum of 30min. You'll have to recompile Dovecot > to lower this to a non-RFC compliant value. I'm not sure how this this > will affect clients, but 30min seems to be overly generous. > > Joseph Tam >
Re: IMAP Idle
Joy wrote: We have implement imap idle in web mail built by us to have push mail feature. IMAP idle working perfectly with browser notification and we are happy with it but having one issue with users who close the browser directly and never logout in that case there are number of idle connection which are not in use and users are unable to login once IP wise connection limit is reached. Dovecot is not closing connection which are not in use, is there any setting available which can help me to resolve this issue. I had much the same situation where a user signed up with a roaming wireless carrier that assigned a new IP to the client whenever it got passed from one access point to another. Good fun when this person took a bus ride through the city, leaving orphaned connections in its wake. The IDLE disconnection timeout is hardwired in the Dovecot code http://wiki.dovecot.org/Timeouts It's set to the RFC minimum of 30min. You'll have to recompile Dovecot to lower this to a non-RFC compliant value. I'm not sure how this this will affect clients, but 30min seems to be overly generous. Joseph Tam
IMAP Idle
Hi guys, We have implement imap idle in web mail built by us to have push mail feature. IMAP idle working perfectly with browser notification and we are happy with it but having one issue with users who close the browser directly and never logout in that case there are number of idle connection which are not in use and users are unable to login once IP wise connection limit is reached. Dovecot is not closing connection which are not in use, is there any setting available which can help me to resolve this issue.
Re: [Dovecot] Managing IMAP IDLE/Push with Sieve – possible?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 23 Jul 2013, FF wrote: Thanks, that's interesting -- two questions: 1) Why is it not possible? Just not implemented, or is there any technical reason that actually prevents it from being implemented? Because the current implementation of IDLE signals any message to the waiting client. 2) What do you mean by INBOX? Another, completely separate email account? Yes, that would be my backup plan. When your client IDLEs, it monitors just one particular mailbox, say INBOX, top.sub.sub2.box, or whatever. So, if you have your client IDLE (monitor) INBOX and have all senders delivered to yet another, newly created mailbox (mail folder, ..., _not_ another mail account), which is not monitored with IDLE, you get no PUSH for them. You have to pull them. = Did you've read Robert's answer about LEMONADE? Maybe ESEARCH and NOTIFY do what you want, because RFC5465 / sec 5.2: " If a search context is in effect as specified in [RFC5267], an ESEARCH ADDTO will also be generated, if appropriate. In this case, the EXISTS response MUST precede the ESEARCH response. Both the NOTIFY command and the SEARCH and SORT commands (see Section 7) can specify attributes to be returned for new messages. These attributes SHOULD be combined into a single FETCH response. The server SHOULD avoid sending duplicate data. The FETCH response(s) MUST follow any ESEARCH ADDTO responses." You could flag "priority" senders in Sieve and let you notify for new messages with that flag. How well or if at all Dovecot supports this (and your client ;-) ), I don't know. kind regards, -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 22 Jul 2013, FF wrote: I've been using Dovecot with Sieve for a long time already, and I'm very happy with it. Push is working fine too. I was wondering, however, whether it would be possible to define a Sieve rule (perhaps using some plug-in), such that an IMAP push message gets sent out only for specific senders etc.? I think you cannot. But you could split your INBOX into senders with PUSH (that are delivered to the INBOX) and others, that are delivered to INBOX2. - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBUe4zH13r2wJMiz2NAQLd4gf/ZcfpXHUQCOozFV5L464voasate3T+aDf W6dnk9s+jOZiYmZZzaxZPw2z14v0GA5BAJdp4h/klbFPxg7Fs9MjUdoi2kusKaw6 ofbQwCsGnGD+kxme0JKtnayWo07Vwdo1rjbhxtSSGU7K4RVtnh4Kj6wTySCYrzKN +0mPIU1XUVJqw6ir+xrJSmcWY5joOnQ1+m1TI6J4E+qIqc+QjJkX1LFOMz+1Lz0x QR05UaH0+bWQPZqknWrxEEHz0eIXZsbrTuosMDHnHjDv1jRe1RzPFi6k+JvbCXcj N4ip0MNuMuYp/tXG9ntYjRwUvjJ8Du9smwh4FE72Uv11povihr7PzA== =0Afu -END PGP SIGNATURE- - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBUfDSFl3r2wJMiz2NAQIvPQf/ajXvgPyv4tViMjSQsVeZkk9OWv8sYh/V 9+X30olLhCWCkVRrt1RBpwmulYkQtXgbKT09wiK+Ro5dZcT9Xmr2g9+mKdPIPFFY StXW3k82S/4IwyWRoaJRfIq5qM7UFWTcxSZFZbc0+Wo903VBZ+MdFHeQv2B6K8uX fR0BRDgbmgUhqK71r2Bg76d+rzovEGUdr21RNFrTui/cuR26uf2tsMHqAYwIU/V6 rdmjy5d9Zg4GCUcBQWMkRSjXN5E9q6NKdzh2AtHtt5BerCbG0gCSU7mWEXMwjVRx fHoy4Lhwx5vlKaFBV9Gd8oc+5jQ+po4N7drmLwtDrAZUBvKbR7jrkQ== =NFGc -END PGP SIGNATURE-
Re: [Dovecot] Managing IMAP IDLE/Push with Sieve – possible?
Hi, Thanks, that's interesting -- two questions: 1) Why is it not possible? Just not implemented, or is there any technical reason that actually prevents it from being implemented? 2) What do you mean by INBOX? Another, completely separate email account? Yes, that would be my backup plan. Thanks, F.F. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 22 Jul 2013, FF wrote: I've been using Dovecot with Sieve for a long time already, and I'm very happy with it. Push is working fine too. I was wondering, however, whether it would be possible to define a Sieve rule (perhaps using some plug-in), such that an IMAP push message gets sent out only for specific senders etc.? I think you cannot. But you could split your INBOX into senders with PUSH (that are delivered to the INBOX) and others, that are delivered to INBOX2. - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBUe4zH13r2wJMiz2NAQLd4gf/ZcfpXHUQCOozFV5L464voasate3T+aDf W6dnk9s+jOZiYmZZzaxZPw2z14v0GA5BAJdp4h/klbFPxg7Fs9MjUdoi2kusKaw6 ofbQwCsGnGD+kxme0JKtnayWo07Vwdo1rjbhxtSSGU7K4RVtnh4Kj6wTySCYrzKN +0mPIU1XUVJqw6ir+xrJSmcWY5joOnQ1+m1TI6J4E+qIqc+QjJkX1LFOMz+1Lz0x QR05UaH0+bWQPZqknWrxEEHz0eIXZsbrTuosMDHnHjDv1jRe1RzPFi6k+JvbCXcj N4ip0MNuMuYp/tXG9ntYjRwUvjJ8Du9smwh4FE72Uv11povihr7PzA== =0Afu -END PGP SIGNATURE-
Re: [Dovecot] Managing IMAP IDLE/Push with Sieve – possible?
Am 23.07.2013 09:39, schrieb Steffen Kaiser: > On Mon, 22 Jul 2013, FF wrote: > >> I've been using Dovecot with Sieve for a long time already, and I'm >> very happy with it. Push is working fine too. I was wondering, >> however, whether it would be possible to define a Sieve rule (perhaps >> using some plug-in), such that an IMAP push message gets sent out only >> for specific senders etc.? > > I think you cannot. > > But you could split your INBOX into senders with PUSH (that are > delivered to the INBOX) and others, that are delivered to INBOX2. > > -- Steffen Kaiser perhaps the imap lemonade extensions may do that have you investigated by that? Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: [Dovecot] Managing IMAP IDLE/Push with Sieve – possible?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 22 Jul 2013, FF wrote: I've been using Dovecot with Sieve for a long time already, and I'm very happy with it. Push is working fine too. I was wondering, however, whether it would be possible to define a Sieve rule (perhaps using some plug-in), such that an IMAP push message gets sent out only for specific senders etc.? I think you cannot. But you could split your INBOX into senders with PUSH (that are delivered to the INBOX) and others, that are delivered to INBOX2. - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBUe4zH13r2wJMiz2NAQLd4gf/ZcfpXHUQCOozFV5L464voasate3T+aDf W6dnk9s+jOZiYmZZzaxZPw2z14v0GA5BAJdp4h/klbFPxg7Fs9MjUdoi2kusKaw6 ofbQwCsGnGD+kxme0JKtnayWo07Vwdo1rjbhxtSSGU7K4RVtnh4Kj6wTySCYrzKN +0mPIU1XUVJqw6ir+xrJSmcWY5joOnQ1+m1TI6J4E+qIqc+QjJkX1LFOMz+1Lz0x QR05UaH0+bWQPZqknWrxEEHz0eIXZsbrTuosMDHnHjDv1jRe1RzPFi6k+JvbCXcj N4ip0MNuMuYp/tXG9ntYjRwUvjJ8Du9smwh4FE72Uv11povihr7PzA== =0Afu -END PGP SIGNATURE-
[Dovecot] Managing IMAP IDLE/Push with Sieve – possible?
Hello, I've been using Dovecot with Sieve for a long time already, and I'm very happy with it. Push is working fine too. I was wondering, however, whether it would be possible to define a Sieve rule (perhaps using some plug-in), such that an IMAP push message gets sent out only for specific senders etc.? Have you come across anything like that? Thanks a lot, F.F.
Re: [Dovecot] IMAP IDLE - iPhone?
On 23/08/2012 21:49, Timo Sirainen wrote: On 23.8.2012, at 23.26, Warren Baker wrote: On Thu, Aug 23, 2012 at 8:50 PM, Timo Sirainen wrote: On 14.8.2012, at 11.18, Timo Sirainen wrote: v2.2 has this now: http://hg.dovecot.org/dovecot-2.2/rev/8d7f9e2d726c Is there a reason why 172.16.0.0/12 was left out of the change ^^ ? Is it actually used? :) I've used 192.168 in my home network and all corporate networks I've seen have been 10/8. But yeah, I guess since there aren't more than those 3 I'll just add it (I thought there were more of them, but looks like they're reserved for other purposes). I specifically use 172.16.0.0/12 because others don't, I also specifically don't use 172.16.0.0/16, because if someone does use 172.16.0.0/12 they usually only use 172.16.0.0/16... It's easy for people to connect to my networks via a VPN connection, and generally not have any IP conflicts with their own RFC1918 ranges and not have to fiddle with NAT issues. -- Regards, Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk gi...@coochey.net smime.p7s Description: S/MIME Cryptographic Signature
Re: [Dovecot] IMAP IDLE - iPhone?
On 24.8.2012, at 14.18, Matthew Powell wrote: > On 2012-08-24, at 7.01, Jerry wrote: > >> I would personally recommend supporting it. If history teaches us >> anything, it is that sooner or later, and usually sooner, someone will >> require that block. Being prepared for it in advance would seem like >> the prudent thing to do. > > I wonder whether it would be better to make the exclusion list configurable. The reason for this default exclusion list is exactly to avoid behaving badly in unconfigured systems. Normally people should be using Dovecot proxies and login_trusted_networks setting configured to avoid the problem entirely.
Re: [Dovecot] IMAP IDLE - iPhone?
Am 24.08.2012 13:18, schrieb Matthew Powell: > On 2012-08-24, at 7.01, Jerry wrote: > >> I would personally recommend supporting it. If history teaches us >> anything, it is that sooner or later, and usually sooner, someone will >> require that block. Being prepared for it in advance would seem like >> the prudent thing to do. > > I wonder whether it would be better to make the exclusion list configurable. > > As I understand it, the intention is to avoid treating connections through a > load balancer or proxy as though they're the same client device i doubt the ip is generally the wrong value to define something is the same client device, there are millions of networks behind NAT out there with a lot of clients usually connecting to the same mailserver via the same public IP and many of them have a workstation beside a mobile device using the same IMAP account the same device = open connection, nothing else > The assumption that private address = proxy is a fair default in my opinion this is generally the wrong direction i do NOT like it when server software behaves different from my private LAN where services are tested than later after making the service public from the WAN signature.asc Description: OpenPGP digital signature
Re: [Dovecot] IMAP IDLE - iPhone?
On 2012-08-24, at 7.01, Jerry wrote: > I would personally recommend supporting it. If history teaches us > anything, it is that sooner or later, and usually sooner, someone will > require that block. Being prepared for it in advance would seem like > the prudent thing to do. I wonder whether it would be better to make the exclusion list configurable. As I understand it, the intention is to avoid treating connections through a load balancer or proxy as though they're the same client device. The assumption that private address = proxy is a fair default, but some sites will be using public addresses for their proxies. And that's only going to increase with IPv6. -- Matthew Powell matt...@atom.net
Re: [Dovecot] IMAP IDLE - iPhone?
On Fri, 24 Aug 2012 10:10:42 +0200 Warren Baker articulated: > Yeah as others have mentioned - also not sure whether it is worth the > effort to support IPv6's 'private' network (fc00::/7)? > I havent seen anyone making use of this for their v6 enabled sites but > others may have input here. I would personally recommend supporting it. If history teaches us anything, it is that sooner or later, and usually sooner, someone will require that block. Being prepared for it in advance would seem like the prudent thing to do. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __
Re: [Dovecot] IMAP IDLE - iPhone?
On Thu, Aug 23, 2012 at 10:49 PM, Timo Sirainen wrote: >> >> Is there a reason why 172.16.0.0/12 was left out of the change ^^ ? > > Is it actually used? :) I've used 192.168 in my home network and all > corporate networks I've seen have been 10/8. But yeah, I guess since there > aren't more than those 3 I'll just add it (I thought there were more of them, > but looks like they're reserved for other purposes). Yeah as others have mentioned - also not sure whether it is worth the effort to support IPv6's 'private' network (fc00::/7)? I havent seen anyone making use of this for their v6 enabled sites but others may have input here. thanks -- .warren
Re: [Dovecot] IMAP IDLE - iPhone?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Timo Sirainen said the following on 23/08/12 22:49: >> Is there a reason why 172.16.0.0/12 was left out of the change ^^ ? > Is it actually used? :) YES! I have a big customer (400 PCs) with 172.16.0.0/16 internal network and a subnet of 192.168.0.0 for DMZ I use it more than 192.168 when I create networks. Ciao, luigi - -- / +--[Luigi Rosa]-- \ Walk softly and carry a megawatt laser. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA3CYkACgkQ3kWu7Tfl6ZSRaQCgy1YilsGEL7JXIDabKm+zSjZN cvEAoKYqE1ZjbR/g1XTiHUvlfpPuvWAE =RSAO -END PGP SIGNATURE-
Re: [Dovecot] IMAP IDLE - iPhone?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-08-23 4:49 PM, Timo Sirainen wrote: > On 23.8.2012, at 23.26, Warren Baker wrote: > >> On Thu, Aug 23, 2012 at 8:50 PM, Timo Sirainen wrote: >>> On 14.8.2012, at 11.18, Timo Sirainen wrote: >>> >>> v2.2 has this now: http://hg.dovecot.org/dovecot-2.2/rev/8d7f9e2d726c >> >> Is there a reason why 172.16.0.0/12 was left out of the change ^^ ? > > Is it actually used? :) I've used 192.168 in my home network and all corporate networks I've seen have been 10/8. But yeah, I guess since there aren't more than those 3 I'll just add it (I thought there were more of them, but looks like they're reserved for other purposes). > Well, here's a "We use it" if you need it.. It probably just makes sense to block all out all RFC1918 addresses.. - -- Daryl Richards Isle Technical Services Inc. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA2mUMACgkQbMWpShDgLrWMSQCfY9tBtDvgVuQDMjUbbNlyGkUb yNQAn2u1tHOZkZc7dugeXaLQ/mfmBFvP =lQb3 -END PGP SIGNATURE-
Re: [Dovecot] IMAP IDLE - iPhone?
On 23.8.2012, at 23.26, Warren Baker wrote: > On Thu, Aug 23, 2012 at 8:50 PM, Timo Sirainen wrote: >> On 14.8.2012, at 11.18, Timo Sirainen wrote: >> >> v2.2 has this now: http://hg.dovecot.org/dovecot-2.2/rev/8d7f9e2d726c > > Is there a reason why 172.16.0.0/12 was left out of the change ^^ ? Is it actually used? :) I've used 192.168 in my home network and all corporate networks I've seen have been 10/8. But yeah, I guess since there aren't more than those 3 I'll just add it (I thought there were more of them, but looks like they're reserved for other purposes).
Re: [Dovecot] IMAP IDLE - iPhone?
On Thu, Aug 23, 2012 at 8:50 PM, Timo Sirainen wrote: > On 14.8.2012, at 11.18, Timo Sirainen wrote: > > v2.2 has this now: http://hg.dovecot.org/dovecot-2.2/rev/8d7f9e2d726c Is there a reason why 172.16.0.0/12 was left out of the change ^^ ? -- .warren
Re: [Dovecot] IMAP IDLE - iPhone?
On 14.8.2012, at 11.18, Timo Sirainen wrote: >> As Timo says, Dovecot tries to be clever and coalesce packets from checking >> multiple folders, but from memory there are limitations on this if you have >> multiple *accounts*? I think the hash is per email address and per IP ? > > Yes, doesn't help with multiple accounts, because the hashed username is > different (no IP). I guess this could be changed to be per IP just as well. I > think I wondered about which one to use previously but didn't see any point > in choosing IP over username, but yes, multiple accounts could be a reason, > especially after the whole world is using only Dovecot. :) v2.2 has this now: http://hg.dovecot.org/dovecot-2.2/rev/8d7f9e2d726c
Re: [Dovecot] IMAP IDLE - iPhone?
On Tue, Aug 14, 2012 at 4:18 PM, Timo Sirainen wrote: > Yes, doesn't help with multiple accounts, because the hashed username is > different (no IP). I guess this could be changed to be per IP just as well. I > think I wondered about which one to use previously but didn't see any point > in choosing IP over username, but yes, multiple accounts could be a reason, > especially after the whole world is using only Dovecot. :) I for one welcome our new Dovecot overlords Sorry for the noise.
Re: [Dovecot] IMAP IDLE - iPhone?
On 14.8.2012, at 11.04, Ed W wrote: > - Then there is tcp keepalive. Does Dovecot enable these? (Sorry, I should > look in the code...). Yes. > However, applications which enable it (eg optional in SSH) will trigger a > default (I think) 75 second network packet It's something like 2 hours by default in Linux. > As Timo says, Dovecot tries to be clever and coalesce packets from checking > multiple folders, but from memory there are limitations on this if you have > multiple *accounts*? I think the hash is per email address and per IP ? Yes, doesn't help with multiple accounts, because the hashed username is different (no IP). I guess this could be changed to be per IP just as well. I think I wondered about which one to use previously but didn't see any point in choosing IP over username, but yes, multiple accounts could be a reason, especially after the whole world is using only Dovecot. :) > But of course if your emails turn up every few seconds, then you will be > triggering wakeups every few seconds also. Maybe Dovecot could make this somehow smarter some day.. Or create a plugin that allows that.
Re: [Dovecot] IMAP IDLE - iPhone?
On 10/08/2012 10:25, Timo Sirainen wrote: how does help me "save battery" if i have a folder-structure maintained by sieve if i do not get my new mails? If you open 10 connections to IMAP server and will IDLE on them - your phone will wake up to reply for ping in every of that 10 connections. Imagine if there will 100 folders? Like mentioned previously in this thread, you can disable the "ping"s in Dovecot. And even when they happen Dovecot makes them happen at the same time. So I think the power usage difference between 1 connection and 100 connections isn't much. The battery consumption problem seems common, but understanding of it is poor... The situation is simply: - Waking up a 3G radio is expensive on power - So prefer to do it less frequently and do a chunk of stuff, rather than doing a small amount of data quite frequently - Every 30 mins is only 48 times a day. Every 15 seconds is massively more - Different 3G networks have different parameters set which will dramatically affect battery life. ie they wait longer/shorter before allowing the radio to go idle once woken up. I don't know a good online resource to see these settings, my old Nokia had a utility to investigate things... - Firewalls impose challenges on being silent for 30 mins at a time and may drop any NAT mappings - The 3G network will almost certainly have a NAT in the way which guarantees you have a (probably very short) NAT timeout (perhaps 10 mins or perhaps less) - Then there is tcp keepalive. Does Dovecot enable these? (Sorry, I should look in the code...). However, applications which enable it (eg optional in SSH) will trigger a default (I think) 75 second network packet As Timo says, Dovecot tries to be clever and coalesce packets from checking multiple folders, but from memory there are limitations on this if you have multiple *accounts*? I think the hash is per email address and per IP ? But of course if your emails turn up every few seconds, then you will be triggering wakeups every few seconds also. I think if you tune things with that in mind, it's very possible to get very low battery usage. Using tcpdump on your mobile client to help tune things is a great help. Basically every stray packet is a killer for battery, hunt them down. Cheers Ed W
Re: [Dovecot] IMAP IDLE - iPhone?
10.08.2012 16:57, Reindl Harald пишет: surely IT IS an argument on a non-iPhone you can chosse what is important your agrumentation is even one argument more against iPhone If we now talking about android vs iPhone now... Imagine Android default email client. It have no many features, that iPhone's default have (Note: i do not use iPhone, i'm not fan of Apple). Then return to thing I wanna tell in previous letter - the situation, when you really NEED to follow ALL of hundred of mail dirs. I think that battery life is the reason, why this feature is not implemented in iPhone. It will use only one IMAP connection so it is not "it's IMAP limitation" As I told - IMAP limitation is to control only one folder as proven by other devices there is no limitation Can't you distinguish the protocol itself with limitation to follow only one dir and the realization with workaround to create many connections to follow all required dirs? Just imagine that ActiveSync have no that limitation - it use only one connection for any count of mail dirs and therefore it's scalability is very good! how does help me "save battery" if i have a folder-structure maintained by sieve if i do not get my new mails? If you open 10 connections to IMAP server and will IDLE on them - your phone will wake up to reply for ping in every of that 10 connections. Imagine if there will 100 folders? Therefore IMAP really have limitation to use it on mobile devices again: how does it help me if I NEED to check them? Sure! If you NEED to check them - I guess you can find some app in Apple Store. and no, IMAP has no limitations proven by Android-client my Samsung Galaxy S3 has around 25 push folders Yes, it has. The workaround is something else, that limitation itself. no problem with K9 mail to have them in my "common inbox" including my own sent messages while on the desktop i use the folder structure and my battery has a average lifetime of 1.5 days Android's power consumption is a result of very many factors. Spherical 1.5 days is something that have no any sense.
Re: [Dovecot] IMAP IDLE - iPhone?
Am 10.08.2012 11:21, schrieb Sergey S. Kovalev: >> and that is why K9 on android let you select which folders >> are relevant for you on the mobile and which should be >> completly ignored and display the selected in "common inbox" > This is not an argument. You can have hundred of folders sorted by > sieve and really need to know if there new mail > in any of it surely IT IS an argument on a non-iPhone you can chosse what is important your agrumentation is even one argument more against iPhone >>> I think that battery life is the reason, why this feature is not implemented >>> in iPhone. It will use only one IMAP connection >> so it is not "it's IMAP limitation" > As I told - IMAP limitation is to control only one folder as proven by other devices there is no limitation >> how does help me "save battery" if i have a folder-structure >> maintained by sieve if i do not get my new mails? > If you open 10 connections to IMAP server and will IDLE on them - your phone > will wake up to reply for ping in every of that 10 connections. > Imagine if there will 100 folders? > Therefore IMAP really have limitation to use it on mobile devices again: how does it help me if I NEED to check them? and no, IMAP has no limitations proven by Android-client my Samsung Galaxy S3 has around 25 push folders no problem with K9 mail to have them in my "common inbox" including my own sent messages while on the desktop i use the folder structure and my battery has a average lifetime of 1.5 days signature.asc Description: OpenPGP digital signature
Re: [Dovecot] IMAP IDLE - iPhone?
10.08.2012 16:25, Timo Sirainen пишет: how does help me "save battery" if i have a folder-structure maintained by sieve if i do not get my new mails? If you open 10 connections to IMAP server and will IDLE on them - your phone will wake up to reply for ping in every of that 10 connections. Imagine if there will 100 folders? Like mentioned previously in this thread, you can disable the "ping"s in Dovecot. And even when they happen Dovecot makes them happen at the same time. So I think the power usage difference between 1 connection and 100 connections isn't much. I guess, there is no trick, that will change the linear complexity by traffic and by CPU usage. If you can change settings in dovecot - you can set up ActiveSync there. It's more suitable for mobile mailing.
Re: [Dovecot] IMAP IDLE - iPhone?
Hi, On 10-Aug-12 4:48, Timo Sirainen wrote: Related question that came to my mind: Does anyone know if XAPPLEPUSHSERVICE feature can be implemented by any server, or does it require cooperation between the server and the mobile network operator? I'm guessing the latter.. the Apple push service for Mail.app uses the same push notification service as all other push notifications for iOS (APNS, Apple Push Notification Service). The Device retains a persistent connection to Apple's APNS Gateway. To transmit a push notification via APNS, the sender needs a certificate issued by Apple for the receiving application (Mail.app in this case). One can get such a certificate by purchasing Lion Server, which includes such a certificate (I presume Mountain Lion Server does as well). The Lion Server uses dovecot, and Apple's patch for the XAPPLEPUSHSERVICE extension is available on http://www.opensource.apple.com/source/dovecot/dovecot-239/dovecot/src/plugins/push-notify/ It basically works as following: 1) Dovecot advertises the XAPPLEPUSHSERVICE Capability 2) When the device logs in to the IMAP server and sees that it supports this capability, it registers with the server for push notifications and provides its device id and the id of the corresponding mail account on the device. These two ids are required to route a push notification to the device. 3) The server records all registered devices for an account. Upon an incoming mail for the account, it transmits a push notification. 4) The device does not directly unregister; this is done using the feedback mechanism of APNS, which tells a service provider that a device does not wish to receive push notifications any longer. The actual transmission of the push notifications to the APNS server is not part of the dovecot patch but a separate program. One can use the Net::APNS perl module (found on cpan) to fairly easily replicate that program. Apple's original is also available: http://www.opensource.apple.com/source/dovecot/dovecot-239/dovecot.push-notify/daemon -Mike P.S.: I'm not sure if one is allowed to do this, though. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Dovecot] IMAP IDLE - iPhone?
On 10.8.2012, at 12.21, Sergey S. Kovalev wrote: >>> I think that battery life is the reason, why this feature is not implemented >>> in iPhone. It will use only one IMAP connection >> so it is not "it's IMAP limitation" > As I told - IMAP limitation is to control only one folder. Assuming NOTIFY extension isn't implemented by both. (Dovecot v2.2 hopefully will have it, and K-9 apparently is interested in adding it too after that.) >> how does help me "save battery" if i have a folder-structure >> maintained by sieve if i do not get my new mails? > If you open 10 connections to IMAP server and will IDLE on them - your phone > will wake up to reply for ping in every of that 10 connections. > Imagine if there will 100 folders? Like mentioned previously in this thread, you can disable the "ping"s in Dovecot. And even when they happen Dovecot makes them happen at the same time. So I think the power usage difference between 1 connection and 100 connections isn't much.
Re: [Dovecot] IMAP IDLE - iPhone?
10.08.2012 15:59, Reindl Harald пишет: Am 10.08.2012 10:46, schrieb Sergey S. Kovalev: 10.08.2012 15:16, Reindl Harald пишет: i have a Android with K9, a lot of folders where messages are stored by sieve-scirpts and on my phone i can actively select which folders should be used for push Sure, it can do it in two ways: open several connections to imap server (one per folder) or periodically change current directory and get changes. typically the client opens a connecton for each folder to check Sure, it's better. But any of this solution will eat battery very fast, proportionally to count of folders to check. and that is why K9 on android let you select which folders are relevant for you on the mobile and which should be completly ignored and display the selected in "common inbox" This is not an argument. You can have hundred of folders sorted by sieve and really need to know if there new mail in any of it. I think that battery life is the reason, why this feature is not implemented in iPhone. It will use only one IMAP connection so it is not "it's IMAP limitation" As I told - IMAP limitation is to control only one folder. how does help me "save battery" if i have a folder-structure maintained by sieve if i do not get my new mails? If you open 10 connections to IMAP server and will IDLE on them - your phone will wake up to reply for ping in every of that 10 connections. Imagine if there will 100 folders? Therefore IMAP really have limitation to use it on mobile devices. it's a limitation from Apple because they have not the knowledge to implement relieable mail-clients see below the removed posting on apple-support (first paragraphs german but posting and answer from Apple below in english) http://www.rhsoft.net/ I'm not fan of apple anyway, so do not interested in this discussion at all. Sergey S. Kovalev.
Re: [Dovecot] IMAP IDLE - iPhone?
Am 10.08.2012 10:46, schrieb Sergey S. Kovalev: > 10.08.2012 15:16, Reindl Harald пишет: >> i have a Android with K9, a lot of folders where messages are stored >> by sieve-scirpts and on my phone i can actively select which folders >> should be used for push >> > Sure, it can do it in two ways: open several connections to imap server > (one per folder) or periodically change current directory and get changes. typically the client opens a connecton for each folder to check > But any of this solution will eat battery very fast, proportionally > to count of folders to check. and that is why K9 on android let you select which folders are relevant for you on the mobile and which should be completly ignored and display the selected in "common inbox" > I think that battery life is the reason, why this feature is not implemented > in iPhone. It will use only one IMAP connection so it is not "it's IMAP limitation" how does help me "save battery" if i have a folder-structure maintained by sieve if i do not get my new mails? it's a limitation from Apple because they have not the knowledge to implement relieable mail-clients see below the removed posting on apple-support (first paragraphs german but posting and answer from Apple below in english) http://www.rhsoft.net/ signature.asc Description: OpenPGP digital signature
Re: [Dovecot] IMAP IDLE - iPhone?
10.08.2012 15:16, Reindl Harald пишет: Am 10.08.2012 09:08, schrieb Sergey S. Kovalev: iPhone will not notify for new mail in any folder, except INBOX - it's IMAP limitation. IMAP IDLE monitor only one selected folder. If you need notifying of new mail in copule of mail folders you shold look for ActiveSync realization. On small mailboxes it's z-push and tine20 for example - they can use IMAP server as backend. this may be a IPHONE limitation as all the apple clients are buggy like hell since years i have a Android with K9, a lot of folders where messages are stored by sieve-scirpts and on my phone i can actively select which folders should be used for push Sure, it can do it in two ways: open several connections to imap server (one per folder) or periodically change current directory and get changes. But any of this solution will eat battery very fast, proportionally to count of folders to check. I think that battery life is the reason, why this feature is not implemented in iPhone. It will use only one IMAP connection. Sergey S. Kovalev
Re: [Dovecot] IMAP IDLE - iPhone?
Am 10.08.2012 09:08, schrieb Sergey S. Kovalev: > iPhone will not notify for new mail in any folder, except INBOX - it's IMAP > limitation. > IMAP IDLE monitor only one selected folder. > If you need notifying of new mail in copule of mail folders you shold look > for ActiveSync realization. > On small mailboxes it's z-push and tine20 for example - they can use IMAP > server as backend. this may be a IPHONE limitation as all the apple clients are buggy like hell since years i have a Android with K9, a lot of folders where messages are stored by sieve-scirpts and on my phone i can actively select which folders should be used for push signature.asc Description: OpenPGP digital signature
Re: [Dovecot] IMAP IDLE - iPhone?
On 10.8.2012, at 9.31, Robin wrote: > On 8/9/2012 11:26 PM, Luigi Rosa wrote: >> I used K-9 client on Android for one year with push, but I had to remove >> it and go back to integrated email client because it drained the battery. > > It sounds like "push" was really implemented as a poll. Dovecot has by default: imap_idle_notify_interval = 2 mins So the phone needs to receive and send data every 2 minutes. Increasing this / disabling it entirely should help with power usage. But even then active TCP connections do eat up battery.
Re: [Dovecot] IMAP IDLE - iPhone?
Am 10.08.2012 09:08, schrieb Sergey S. Kovalev: > On small mailboxes it's z-push and tine20 for example - they can use > IMAP server as backend. z-push works nice here with android, also the new horde beta has now calender, abook, notes, mail sync -- Best Regards MfG Robert Schetterer
Re: [Dovecot] IMAP IDLE - iPhone?
10.08.2012 09:44, dove...@noboost.org пишет: Hi All, Probably a very common question now days. I'd like to configure our iPhones at work to go directly to my dovecot server (currently dovecot-2.0.9-2.el6_1.1.x86_64). Using the IMAP IDLE (push email) protocol. Has anyone successfully deployed this? If yes, did you have to use an app from the Apple store? For me the IMAP process works, however it's clearly not notifying the client when new email is detected on the server. cya Craig iPhone will not notify for new mail in any folder, except INBOX - it's IMAP limitation. IMAP IDLE monitor only one selected folder. If you need notifying of new mail in copule of mail folders you shold look for ActiveSync realization. On small mailboxes it's z-push and tine20 for example - they can use IMAP server as backend. Sergey S. Kovalev
Re: [Dovecot] IMAP IDLE - iPhone?
Am 10.08.2012 08:26, schrieb Luigi Rosa: > dove...@noboost.org said the following on 10/08/2012 04:44: > >> Probably a very common question now days. >> I'd like to configure our iPhones at work to go directly to my dovecot >> server (currently dovecot-2.0.9-2.el6_1.1.x86_64). Using the IMAP IDLE >> (push email) protocol. so simply do it > > I used K-9 client on Android for one year with push, but I had to remove > it and go back to integrated email client because it drained the battery. > > > > > > Ciao, > luigi > imap idle is often promoted as push mail but tec side it isnt "exactly" the same, in users eyes the result looks nearly equal yes every service which let stay you online, robs power from battery but you can sync only manuall etc ( for sure then push makes no sense anymore ) however its a human related question, if i need mails always and everywhere and in "real time" in my eyes , if its really urgent people should phone together *g -- Best Regards MfG Robert Schetterer
Re: [Dovecot] IMAP IDLE - iPhone?
On 8/9/2012 11:26 PM, Luigi Rosa wrote: I used K-9 client on Android for one year with push, but I had to remove it and go back to integrated email client because it drained the battery. It sounds like "push" was really implemented as a poll. =R=
Re: [Dovecot] IMAP IDLE - iPhone?
dove...@noboost.org said the following on 10/08/2012 04:44: Probably a very common question now days. I'd like to configure our iPhones at work to go directly to my dovecot server (currently dovecot-2.0.9-2.el6_1.1.x86_64). Using the IMAP IDLE (push email) protocol. I used K-9 client on Android for one year with push, but I had to remove it and go back to integrated email client because it drained the battery. Ciao, luigi -- / +--[Luigi Rosa]-- \ Why do we want intelligent terminals when there are so many stupid users?
Re: [Dovecot] IMAP IDLE - iPhone?
Related question that came to my mind: Does anyone know if XAPPLEPUSHSERVICE feature can be implemented by any server, or does it require cooperation between the server and the mobile network operator? I'm guessing the latter..
[Dovecot] IMAP IDLE - iPhone?
Hi All, Probably a very common question now days. I'd like to configure our iPhones at work to go directly to my dovecot server (currently dovecot-2.0.9-2.el6_1.1.x86_64). Using the IMAP IDLE (push email) protocol. Has anyone successfully deployed this? If yes, did you have to use an app from the Apple store? For me the IMAP process works, however it's clearly not notifying the client when new email is detected on the server. cya Craig
Re: [Dovecot] imap idle and concurrent connections
Hi, On Mon, Jul 4, 2011 at 3:40 PM, Timo Sirainen wrote: > On 4.7.2011, at 13.07, Wolfgang Rosenauer wrote: > >> Two telnet imap connections open and both idling on the inbox and only >> one of them gets the "1 recent" notification. > > This is how it's supposed to work according to IMAP RFC. Only one session > ever sees a message as \Recent. Both of them gets an updated EXISTS though. Is this: RFC 3501 Section 7.3.2? Examples of situations in which this is not the case are: multiple clients having the same mailbox open (the first session to be notified will see it as recent, others will probably see it as non-recent) So the implementation seems to be fine according to the RFC but it came somehow unexpected to me. It's not that this is required by the RFC though. Thanks for the information, Wolfgang
Re: [Dovecot] imap idle and concurrent connections
On 4.7.2011, at 13.07, Wolfgang Rosenauer wrote: > Two telnet imap connections open and both idling on the inbox and only > one of them gets the "1 recent" notification. This is how it's supposed to work according to IMAP RFC. Only one session ever sees a message as \Recent. Both of them gets an updated EXISTS though.
Re: [Dovecot] imap idle and concurrent connections
Hi, On Mon, Jul 4, 2011 at 11:25 AM, Ed W wrote: > On 04/07/2011 09:04, Wolfgang Rosenauer wrote: >> Hi, >> >> in my testing dovecot (1.2 in that case) seems to not notify all >> idling clients about new "recent" mails but only one of them. The >> others get usually a message about the new number of mails after some >> time but never recent ones. >> Only one client gets notified about a new mail. Is that a known issue >> or something which might be configuration specific? > > Interesting if you have a reproducible test case? this is reproduced with IMAP connections idling in a telnet session. Two telnet imap connections open and both idling on the inbox and only one of them gets the "1 recent" notification. I've reproduced on a system where I have access which is a Dovecot 1.0 as delivered in Debian Lenny but also on another system which is apparently Dovecot 1.2 (but I have no direct access to that one so cannot be sure which version runs exactly. Wolfgang
Re: [Dovecot] imap idle and concurrent connections
On 04/07/2011 09:04, Wolfgang Rosenauer wrote: > Hi, > > in my testing dovecot (1.2 in that case) seems to not notify all > idling clients about new "recent" mails but only one of them. The > others get usually a message about the new number of mails after some > time but never recent ones. > Only one client gets notified about a new mail. Is that a known issue > or something which might be configuration specific? Interesting if you have a reproducible test case? I have seen a peculiar issue for a while with Thunderbird, where in a shared inbox, my Thunderbird is set to enable it's basic "lemonade" support and very occasionally someone else using the shared mailbox marks a message read but I don't see it read on my machine (it's even tricky to get TB to resync and notice...). Also sometimes two emails arriving very close together my Thunderbird only shows one of them There are plenty of non Dovecot things which could cause these symptoms: Thunderbird bugs (probably!), NAT timeouts on the client side (I'm behind a NAT). However, I haven't been able to repro this in a consistent way... Do please consider if NAT is involved in your scenario. I have a sneaking suspicion that NAT timeouts might be at least part of the reason? Good luck Ed W
[Dovecot] imap idle and concurrent connections
Hi, in my testing dovecot (1.2 in that case) seems to not notify all idling clients about new "recent" mails but only one of them. The others get usually a message about the new number of mails after some time but never recent ones. Only one client gets notified about a new mail. Is that a known issue or something which might be configuration specific? Wolfgang
Re: [Dovecot] IMAP IDLE, Virtual mailboxes
> Well, fine.. http://hg.dovecot.org/dovecot-1.2/rev/367ce71922bf Woohoo, thanks :-) > But I don't know when 1.2.14 release will come, if ever. We'll see. For now I'm just running a patched version, but this saves me the trouble of recompiling if 1.2.14 every gets released :-) Gr. Matthijs signature.asc Description: Digital signature
Re: [Dovecot] IMAP IDLE, Virtual mailboxes
On Thu, 2010-08-05 at 16:21 +0200, Ralf Hildebrandt wrote: > > I was planning to avoid adding any changes to v1.2 that aren't bugfixes. > > (This more like a feature. :) > > Oh, come on. You even wrote "/* FIXME: maybe some day */" > :) Well, fine.. http://hg.dovecot.org/dovecot-1.2/rev/367ce71922bf But I don't know when 1.2.14 release will come, if ever.
Re: [Dovecot] IMAP IDLE, Virtual mailboxes
* Timo Sirainen : > On Thu, 2010-08-05 at 12:22 +0200, Matthijs Kooijman wrote: > > Hi Timo, > > > > > Here: http://hg.dovecot.org/dovecot-2.0/rev/eb1f471a924d > > > > Cool! I've just tested this patch on 1.2 (current hg version), and the > > patch applies cleanly and seems to work as well. I'm running it right > > now. > > > > Are there any plans to include this in 1.2 still? > > I was planning to avoid adding any changes to v1.2 that aren't bugfixes. > (This more like a feature. :) Oh, come on. You even wrote "/* FIXME: maybe some day */" :) -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: [Dovecot] IMAP IDLE, Virtual mailboxes
On Thu, 2010-08-05 at 12:22 +0200, Matthijs Kooijman wrote: > Hi Timo, > > > Here: http://hg.dovecot.org/dovecot-2.0/rev/eb1f471a924d > > Cool! I've just tested this patch on 1.2 (current hg version), and the > patch applies cleanly and seems to work as well. I'm running it right > now. > > Are there any plans to include this in 1.2 still? I was planning to avoid adding any changes to v1.2 that aren't bugfixes. (This more like a feature. :)
Re: [Dovecot] IMAP IDLE, Virtual mailboxes
Hi Timo, > Here: http://hg.dovecot.org/dovecot-2.0/rev/eb1f471a924d Cool! I've just tested this patch on 1.2 (current hg version), and the patch applies cleanly and seems to work as well. I'm running it right now. Are there any plans to include this in 1.2 still? Gr. Matthijs signature.asc Description: Digital signature
Re: [Dovecot] IMAP IDLE, Virtual mailboxes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Timo, On 2010-08-04 23:54, Timo Sirainen wrote: > Here: http://hg.dovecot.org/dovecot-2.0/rev/eb1f471a924d Thanks, that's great! Now dovecot enables people who sort server-side and want IDLE notifications for all those mailboxes, but do not want to keep "many" IDLE connections open. They can now create a virtual mailbox that contains all mail-receiving mailboxes' mail (lets call it vinbox), and put their IDLE connection on that vinbox. Neat. I'll update to 2.0 ASAP :) Patrick. - -- Key ID: 0x86E346D4http://patrick-nagel.net/key.asc Fingerprint: 7745 E1BE FA8B FBAD 76AB 2BFC C981 E686 86E3 46D4 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxaMoYACgkQyYHmhobjRtT2XQCdH1IZsNl+cLGVvLJCNaZTbf3d h5UAoIuOMMtsTAWGI76MkOU6X4yxQaS3 =xXls -END PGP SIGNATURE-
Re: [Dovecot] IMAP IDLE, Virtual mailboxes
Here: http://hg.dovecot.org/dovecot-2.0/rev/eb1f471a924d
Re: [Dovecot] IMAP IDLE, Virtual mailboxes
Hi all, it's been a while since I wrote below email. Any chance someone has some extra debugging suggestions for me? Gr. Matthijs On Thu, Apr 29, 2010 at 10:00:18AM +0200, Matthijs Kooijman wrote: > Hi Timo, Patrick, > > > > Virtual plugin does already work like that. Although there's a bug > > > where messages don't get removed from mailbox always: > > > > Oh, I see. I'll give it another try then, I believe I tried this, but > > never got notified of new mails in the virtual mailbox through the IMAP > > IDLE connection. > I'm seeing the same thing: IDLE works fine for normal mailboxes, but fails on > a virtual mailbox. Using rawlog I can confirm that the IDLE command is > received properly, but there is just no notification of the new mail at all: > > > a0026 IDLE > < + idling > < * OK Still here > < * OK Still here > ... around a hundred more of these ... > < * OK Still here > < * OK Still here > > DONE > < a0026 OK Idle completed. > > (The interleaving of the in and out messages is done by me, but I think this > should be how it went) > > During this idle period, tens of emails were delivered, but nothing shows up. > > Any suggestions on debugging this further? I'm running dovecot 1.2.9 from > backports.org (but I could compile my own and add some debbuging statements, > if that would help and you have suggestions on where to put them). > > Gr. > > Matthijs signature.asc Description: Digital signature
Re: [Dovecot] IMAP IDLE, Virtual mailboxes
Hi Timo, Patrick, > > Virtual plugin does already work like that. Although there's a bug > > where messages don't get removed from mailbox always: > > Oh, I see. I'll give it another try then, I believe I tried this, but > never got notified of new mails in the virtual mailbox through the IMAP > IDLE connection. I'm seeing the same thing: IDLE works fine for normal mailboxes, but fails on a virtual mailbox. Using rawlog I can confirm that the IDLE command is received properly, but there is just no notification of the new mail at all: > a0026 IDLE < + idling < * OK Still here < * OK Still here ... around a hundred more of these ... < * OK Still here < * OK Still here > DONE < a0026 OK Idle completed. (The interleaving of the in and out messages is done by me, but I think this should be how it went) During this idle period, tens of emails were delivered, but nothing shows up. Any suggestions on debugging this further? I'm running dovecot 1.2.9 from backports.org (but I could compile my own and add some debbuging statements, if that would help and you have suggestions on where to put them). Gr. Matthijs signature.asc Description: Digital signature
[Dovecot] OT: IMAP IDLE, Virtual mailboxes
On 15.04.2010 7:03, Daniel I. Applebaum wrote: Patrick Nagel wrote: One of the core developers of K-9 Mail says: "I've been interested in implementing IMAP NOTIFY in K-9 Mail, but will only do it once dovecot supports it." Yeah, that was me. :-) I use dovecot as the reference server for all my work on K-9 Mail, and can't think of how to develop the client side support for IMAP NOTIFY until I have a server to support it. However, I'd consider starting on it if I knew that dovecot would soon have the support, as well. Dan. Hi Dan, Thanks for K-9! If you don't mind can I ask you little off topic question feel free answer privatly. Does android advertise to app when network goes down(GSM our of range). If it so, when network goes up(like interface goes up?), do you establish new TCP connection to maintain IDLE? Or just purely rely on timeouts in connection? Thanks
Re: [Dovecot] IMAP IDLE, Virtual mailboxes
Patrick Nagel wrote: One of the core developers of K-9 Mail says: "I've been interested in implementing IMAP NOTIFY in K-9 Mail, but will only do it once dovecot supports it." Yeah, that was me. :-) I use dovecot as the reference server for all my work on K-9 Mail, and can't think of how to develop the client side support for IMAP NOTIFY until I have a server to support it. However, I'd consider starting on it if I knew that dovecot would soon have the support, as well. Dan.
Re: [Dovecot] IMAP IDLE, Virtual mailboxes
Hi Timo, great hearing from you again, hope the exams went well :) On 2010-04-13 19:01 UTC Timo Sirainen wrote: > On 9.4.2010, at 9.31, Patrick Nagel wrote: > > 2) Enhancing dovecot's Virtual plugin, so virtual mailboxes do not > > only get updated on select and expunge, but also when anything > > changes that affects the set of messages shown in the virtual > > mailbox. I guess that would have an impact on performance, and > > thus should be optional. > > Virtual plugin does already work like that. Although there's a bug > where messages don't get removed from mailbox always: > > - virtual: removed messages don't get expunged unless EXPUNGE is > issued in same session. otherwise they get forgotten and never > removed. Oh, I see. I'll give it another try then, I believe I tried this, but never got notified of new mails in the virtual mailbox through the IMAP IDLE connection. > And NOTIFY isn't implemented yet mainly because it would be > annoyingly expensive (as is virtual mailbox when it's created from > many real mailboxes). I've been planning on implementing mailbox > list indexes (or they already are implemented, but they're buggy) > that would make this much cheaper. Basically NOTIFY could just keep > watching for changes to dovecot.list.index.log file, and then read > what mailbox had changed and how and notify client about it, > possibly without even opening the mailbox itself. That sounds like a good plan - basically having "logwatch" on all IMAP operations :) I'd be happy to test once you have anything to be tested (just need to find a MUA other than telnet+brain that has IMAP NOTIFY implemented first ;) ). Patrick. -- Key ID: 0x86E346D4http://patrick-nagel.net/key.asc Fingerprint: 7745 E1BE FA8B FBAD 76AB 2BFC C981 E686 86E3 46D4 signature.asc Description: This is a digitally signed message part.
Re: [Dovecot] IMAP IDLE, Virtual mailboxes
On 9.4.2010, at 9.31, Patrick Nagel wrote: > 2) Enhancing dovecot's Virtual plugin, so virtual mailboxes do not only > get updated on select and expunge, but also when anything changes that > affects the set of messages shown in the virtual mailbox. I guess that > would have an impact on performance, and thus should be optional. Virtual plugin does already work like that. Although there's a bug where messages don't get removed from mailbox always: - virtual: removed messages don't get expunged unless EXPUNGE is issued in same session. otherwise they get forgotten and never removed. And NOTIFY isn't implemented yet mainly because it would be annoyingly expensive (as is virtual mailbox when it's created from many real mailboxes). I've been planning on implementing mailbox list indexes (or they already are implemented, but they're buggy) that would make this much cheaper. Basically NOTIFY could just keep watching for changes to dovecot.list.index.log file, and then read what mailbox had changed and how and notify client about it, possibly without even opening the mailbox itself.
Re: [Dovecot] IMAP IDLE, Virtual mailboxes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Nikolay, (I changed my dovecot mailing list subscription from my work mail account to my private mail account - I'm the guy who started this thread) On 2010-04-10 15:22, Nikolay Shopik wrote: > On 10.04.2010 11:13, Patrick Nagel wrote: >> "The client can also request notifications on other mailboxes by name >> or by a limited mailbox pattern match. Message-related notifications >> returned for the currently selected mailbox will be those specified >> by the SELECTED/SELECTED-DELAYED mailbox specifier, even if the >> selected mailbox also appears by name (or matches a pattern) in the >> command." >> > I assume this only apply if all these mailboxes are on same server. That's for sure - "mailbox" in IMAP always refers to the thing that most people call "folder". But I think it's unlikely that you need push mail for more than a couple of IMAP accounts on different servers. And in any case, there would be no way to accomplish this, with any protocol, without having a connection to all the IMAP servers. Patrick. - -- Key ID: 0x86E346D4http://patrick-nagel.net/key.asc Fingerprint: 7745 E1BE FA8B FBAD 76AB 2BFC C981 E686 86E3 46D4 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkvCtKgACgkQyYHmhobjRtT5cACgmHmfYBd995OIkIBiAdfuM77t GtEAoLZBx0bxj356+Zau5PWDQs0yQol6 =J4B+ -END PGP SIGNATURE-
Re: [Dovecot] Slightly OT: iPhone & IMAP IDLE
On 12/04/2010 02:49, Sabahattin Gucukoglu wrote: > Hi all, > > Does anybody know whether iPhone is supposed to be able to do IMAP IDLE? I > know it does "Push" but that seems to be using Apple's Mobile Me and Exchange. > Hi, The iPhone doesn't seem to support imap-idle as it closes the connection to the mailbox when you lock it. I just tested v4 beta with the redesigned mail.app, but it does not seem to support that either, at least in the bakground. It seems there are some tweaks for jailbroken devices however. Best Regards smime.p7s Description: S/MIME Cryptographic Signature
[Dovecot] Slightly OT: iPhone & IMAP IDLE
Hi all, Does anybody know whether iPhone is supposed to be able to do IMAP IDLE? I know it does "Push" but that seems to be using Apple's Mobile Me and Exchange. Cheers, Sabahattin smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] IMAP IDLE, Virtual mailboxes
On 10.04.2010 11:13, Patrick Nagel wrote: "The client can also request notifications on other mailboxes by name or by a limited mailbox pattern match. Message-related notifications returned for the currently selected mailbox will be those specified by the SELECTED/SELECTED-DELAYED mailbox specifier, even if the selected mailbox also appears by name (or matches a pattern) in the command." I assume this only apply if all these mailboxes are on same server.