NOTIFY extension and asynchronous events

> I'm currently looking into writing a tool to monitor mailboxes for status changes. The typical way for this is probably SELECT/IDLE but I have quite a lot of mailboxes that I'd like to check. I _could_ get a list of all mailboxes and check their statuses periodically but when I'm on a low-bandwidth connection with unfortunate and expensive mobile plans, that would also be a bad idea.
> Therefore, I would like to use my server's NOTIFY extension (as in [RFC5465](https://tools.ietf.org/search/rfc5465)). After authenticating, I'd issue a notify request for a set of events on a set of mailboxes, that could look like this:
> `a NOTIFY SET (personal (MessageNew MessageExpunge))`
> The server responds with `a OK NOTIFY completed.` (at least Dovecot does). After some time, additional (untagged) responses are generated asynchronously, i.e.
> ```
> * STATUS Sent (MESSAGES 1082 UIDNEXT 4821 UNSEEN 0)
> * STATUS INBOX (MESSAGES 307 UIDNEXT 13311 UNSEEN 1)
> ```
> until I either disconnect or stop them by issuing `NOTIFY NONE`.
>
> Well, the notification request can be sent by the current API. However, I don't see a way to collect those untagged status reports. One problem might be that they may be scattered through the whole connection like that (C being the client, S the server):
> ```
> C: a NOTIFY SET (personal messagenew messageexpunge)
> S: a OK NOTIFY completed.
> C: a NOOP
> S: * STATUS Foo (...)
> S: a OK NOOP completed.
> S: * STATUS Bar (...)
> ```
>
> I haven't looked into the depths of `rust-imap` but I guess that it could probably interfere with the response parsing. My uneducated guess would be that implementing something like the `IdleHandle` where all those STATUS messages are collected that are not a direct response to a STATUS command. That might be hard to detect, though, if at all possible.
>
> Do you have any ideas how to support this type of operation?

See the original issue here: https://github.com/mattnenterprise/rust-imap/issues/63