[PATCH 1/1] storage: remove 500 ms debounce on IMAP IDLE notifications

[Alex]

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(>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(>to_notify_delay);
timeout_remove(>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

[Alex]

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

[Timo Sirainen]

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

[Alex]

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

[Timo Sirainen]

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

[Alex]

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

[Sami Ketola via dovecot]

> 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

[@lbutlr via dovecot]

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

[Jorge Bastos via dovecot]

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

[Jorge Bastos via dovecot]

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

[Jorge Bastos via dovecot]

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

[@lbutlr via dovecot]

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

[Sami Ketola via dovecot]

> 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

[Jorge Bastos via dovecot]

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

[LuKreme via dovecot]

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

[Jorge Bastos via dovecot]

> 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

[Aki Tuomi via dovecot]

> 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

[Jorge Bastos via dovecot]

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

[Jorge Bastos via dovecot]

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

[Jorge Bastos via dovecot]

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

[Alexander Dalloz via dovecot]

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

[Aki Tuomi via dovecot]

 
 
  
   
  
  
   
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

[Jorge Bastos via dovecot]

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

[Jorge Bastos via dovecot]

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

[Jorge Bastos via dovecot]

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

[Jorge Bastos via dovecot]

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

[@lbutlr via dovecot]

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

[Jorge Bastos via dovecot]

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

[The Doctor]

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

[Cleber @ Listas]

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 <dovecot@dovecot.org>; Cleber @ Listas 
<cleber-lis...@inetweb.com.br>
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" 
> <cleber-lis...@inetweb.com.br> 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 continu

Re: RES: Possible IMAP IDLE bug in Dovecot 2.2.18 and 2.2.25

[Aki Tuomi]

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" 
> <cleber-lis...@inetweb.com.br> 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

[Cleber @ Listas]

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

[Cleber @ Listas]

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

[Timo Sirainen]

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

[cleber-lis...@inetweb.com.br]

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 

Re: Possible IMAP IDLE bug in Dovecot 2.2.18 and 2.2.25

[Aki Tuomi]

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

[Aki Tuomi]

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

[cleber-lis...@inetweb.com.br]

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 

Re: IMAP Idle

[Joseph Tam]

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

[Joy]

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 <jtam.h...@gmail.com> wrote:

> Joy <pj.netfil...@gmail.com> 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 <jtam.h...@gmail.com>
>

Re: IMAP Idle

[Joseph Tam]

Joy <pj.netfil...@gmail.com> 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 <jtam.h...@gmail.com>

IMAP Idle

[Joy]

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?

[Steffen Kaiser]

-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?

[Steffen Kaiser]

-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?

[Robert Schetterer]

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?

[FF]

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-

[Dovecot] Managing IMAP IDLE/Push with Sieve – possible?

[FF]

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?

[Giles Coochey]

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 t...@iki.fi 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?

[Warren Baker]

On Thu, Aug 23, 2012 at 10:49 PM, Timo Sirainen t...@iki.fi 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?

[Jerry]

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?

[Matthew Powell]

On 2012-08-24, at 7.01, Jerry je...@seibercom.net 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?

[Reindl Harald]

Am 24.08.2012 13:18, schrieb Matthew Powell:
 On 2012-08-24, at 7.01, Jerry je...@seibercom.net 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?

[Warren Baker]

On Thu, Aug 23, 2012 at 8:50 PM, Timo Sirainen t...@iki.fi 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?

[Daryl Richards]

-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 t...@iki.fi 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?

[Luigi Rosa]

-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?

[Ed W]

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 pings 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?

[Timo Sirainen]

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?

[Oon-Ee Ng]

On Tue, Aug 14, 2012 at 4:18 PM, Timo Sirainen t...@iki.fi 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. :)

very-OTI for one welcome our new Dovecot overlords/very-OT

Sorry for the noise.

Re: [Dovecot] IMAP IDLE - iPhone?

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


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?

[Robin]

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?

[Robert Schetterer]

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?

[Sergey S. Kovalev]

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?

[Robert Schetterer]

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?

[Timo Sirainen]

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?

[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



signature.asc
Description: OpenPGP digital signature

Re: [Dovecot] IMAP IDLE - iPhone?

[Sergey S. Kovalev]

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?

[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

 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?

[Sergey S. Kovalev]

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?

[Timo Sirainen]

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 pings 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?

[Michael Stilkerich]

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?

[Sergey S. Kovalev]

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 pings 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?

[Reindl Harald]

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?

[Sergey S. Kovalev]

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.

[Dovecot] IMAP IDLE - iPhone?

[dovecot]

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 - iPhone?

[Timo Sirainen]

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

Re: [Dovecot] imap idle and concurrent connections

[Wolfgang Rosenauer]

Hi,

On Mon, Jul 4, 2011 at 3:40 PM, Timo Sirainen t...@iki.fi 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

[Dovecot] imap idle and concurrent connections

[Wolfgang Rosenauer]

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 and concurrent connections

[Wolfgang Rosenauer]

Hi,

On Mon, Jul 4, 2011 at 11:25 AM, Ed W li...@wildgooses.com 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

[Timo Sirainen]

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, Virtual mailboxes

[Matthijs Kooijman]

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

[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. :)

Re: [Dovecot] IMAP IDLE, Virtual mailboxes

[Ralf Hildebrandt]

* Timo Sirainen t...@iki.fi:
 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

[Timo Sirainen]

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

[Matthijs Kooijman]

 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

[Timo Sirainen]

Here: http://hg.dovecot.org/dovecot-2.0/rev/eb1f471a924d

Re: [Dovecot] IMAP IDLE, Virtual mailboxes

[Patrick Nagel]

-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

[Matthijs Kooijman]

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

[Matthijs Kooijman]

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

[Nikolay Shopik]

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

[Daniel I. Applebaum]

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

[Timo Sirainen]

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

[Patrick Nagel]

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.

[Dovecot] Slightly OT: iPhone IMAP IDLE

[Sabahattin Gucukoglu]

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] Slightly OT: iPhone IMAP IDLE

[Renaud Allard]

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

Re: [Dovecot] IMAP IDLE, Virtual mailboxes

[Patrick Nagel]

-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] IMAP IDLE, Virtual mailboxes

[Patrick Nagel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Nikolay,

On Fri, 09 Apr 2010 21:12:54 +0400, Nikolay Shopik wrote:
 On 09.04.2010 11:19, Patrick Nagel wrote:
 That's great news, thanks for the pointer!:)

 Inhttp://dovecot.org/list/dovecot/2009-August/041950.html  Timo says
 that IMAP NOTIFY is not yet supported by Dovecot - has this changed? If
 not, is there a plan to implement IMAP NOTIFY?

 Keep in mind it still need at least one connection per mailbox if I
 correctly understood RFC.

I don't think so - in chapter 1 (Overview and Rationale) it states
Also, IDLE only applies to the selected mailbox, thus requiring an
 additional TCP connection per mailbox

... and later, in chapter 3.1:

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 cannot find any indication that multiple IMAP connections are required.

 Also I don't know any client supporting IMAP
 NOTIFY yet.

Well, this is probably a chicken/egg problem ;) 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.
(http://code.google.com/p/k9mail/issues/detail?id=1255#c8)

Patrick.

- -- 
STAR Software (Shanghai) Co., Ltd.http://www.star-group.net/
Phone:+86 (21) 3462 7688 x 826 Fax:   +86 (21) 3462 7779

PGP key E883A005 https://stshacom1.star-china.net/keys/patrick_nagel.asc
Fingerprint:   E09A D65E 855F B334 E5C3 5386 EF23 20FC E883 A005
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAkvAJRQACgkQ7yMg/OiDoAUxdQCeIznGYFcEzbTQSU4OaifC8HG0
AH8AoK8VDkSrRhI7CZvUpaarxhDhiVWq
=4ABw
-END PGP SIGNATURE-

Re: [Dovecot] IMAP IDLE, Virtual mailboxes

[Nikolay Shopik]

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.

[Dovecot] IMAP IDLE, Virtual mailboxes

[Patrick Nagel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

K-9 Mail (on Android) has been mentioned on this list multiple times
recently, I think it's definitely an IMAP client on the rise. :) It
supports IMAP IDLE, and so brings push mail to Android mobile phone
users. To bring this into the context of this mailing list: I guess a
lot of people on this list are making use of server-side filtering
(using sieve), so that mails from certain persons or mailing lists end
up in the right mailboxes, right on delivery. Now, this is all great,
but there are issues when server-side filtering and IMAP IDLE come
together: Only one mailbox can be watched with one IMAP IDLE
connection. So, people who have set up elaborate server-side filtering
with say, 50 different sieve fileinto calls, will constantly have a
*lot* of IMAP IDLE connections open, if they really want to get informed
of any mail arriving in any of their mailboxes.

Keeping those 50 IMAP connections open wouldn't cost much bandwidth, and
who cares about the Internet router's connection tables getting
unnecessarily big, anyway? But then there is the problem of a mobile
phone being carried around constantly, switching physical connections
(from WLAN access point 1 to WLAN access point 2 to 3G to 2G to no
connection at all and back), every time needing to terminate* those 50
IMAP connections, and then establish 50 new ones (with SSL handshake
overhead and all). So, all in all, not an optimal solution.

*) (which does not always happen the way it should, see
http://code.google.com/p/k9mail/issues/detail?id=1255)

I see two ways to improve the situation (one of them quite dovecot-centric):
1) A new extension of the IMAP protocol: IMAP MULTI-IDLE, which somehow
allows a client to get notified of changes to more than one mailbox
within one IMAP connection. This conflicts with the basic IMAP design
though, AFAIK, and is thus not likely to be feasible.
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.

Let me explain the second one: With the help of the Virtual plugin, it
is possible to pull all those 50 mailboxes that receive incoming mail
together again, just like the INBOX of the pre-server-side-filtering
times - the user could configure a virtual mailbox to show all unread
mails from those 50 mailboxes. Now the mobile IMAP IDLE users could just
watch that one virtual mailbox, needing only one IMAP IDLE connection.
After having read the mail (directly in the virtual mailbox), it would
disappear, but of course still be in the real mailbox, determined by
the sieve filter on delivery.

Patrick.

- -- 
STAR Software (Shanghai) Co., Ltd.http://www.star-group.net/
Phone:+86 (21) 3462 7688 x 826 Fax:   +86 (21) 3462 7779

PGP key E883A005 https://stshacom1.star-china.net/keys/patrick_nagel.asc
Fingerprint:   E09A D65E 855F B334 E5C3 5386 EF23 20FC E883 A005
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAku+ydsACgkQ7yMg/OiDoAXV9ACdF+BEstnjfUeJlR/JQKFf6N7n
yxYAnAnuD2popWYLfZNCCtlpkAP4SQww
=L33A
-END PGP SIGNATURE-

Re: [Dovecot] IMAP IDLE, Virtual mailboxes

[Nikolay Shopik]

On 09.04.2010 10:31, Patrick Nagel wrote:

1) A new extension of the IMAP protocol: IMAP MULTI-IDLE, which somehow
allows a client to get notified of changes to more than one mailbox
within one IMAP connection. This conflicts with the basic IMAP design
though, AFAIK, and is thus not likely to be feasible.


That's RFC5465 IMAP NOTIFY Extension you are talking about and already 
standards track.

Re: [Dovecot] IMAP IDLE, Virtual mailboxes

[Patrick Nagel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Nikolay,

On 2010-04-09 14:51, Nikolay Shopik wrote:
 On 09.04.2010 10:31, Patrick Nagel wrote:
 1) A new extension of the IMAP protocol: IMAP MULTI-IDLE, which
 somehow allows a client to get notified of changes to more than one
 mailbox within one IMAP connection. This conflicts with the basic
 IMAP design though, AFAIK, and is thus not likely to be feasible.
 
 That's RFC5465 IMAP NOTIFY Extension you are talking about and
 already standards track.

That's great news, thanks for the pointer! :)

In http://dovecot.org/list/dovecot/2009-August/041950.html Timo says
that IMAP NOTIFY is not yet supported by Dovecot - has this changed? If
not, is there a plan to implement IMAP NOTIFY?

Patrick.

- -- 
STAR Software (Shanghai) Co., Ltd.http://www.star-group.net/
Phone:+86 (21) 3462 7688 x 826 Fax:   +86 (21) 3462 7779

PGP key E883A005 https://stshacom1.star-china.net/keys/patrick_nagel.asc
Fingerprint:   E09A D65E 855F B334 E5C3 5386 EF23 20FC E883 A005
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAku+1QMACgkQ7yMg/OiDoAWK8wCfWsRiO0K+F+3F53fkxnPfLy9t
xSMAnj1JxIYkwm/7teLE+28KkHmyA9ok
=Jxdn
-END PGP SIGNATURE-