jonhoo / rust-imap

IMAP client library for Rust
Apache License 2.0
477 stars 80 forks source link

IDLE concurrency issue. #263

Closed lemunozm closed 1 year ago

lemunozm commented 1 year ago

Hi!

I'm in a situation where a client is sending emails continuously by SMTP. My other IMAP client connects, fetches all messages from the inbox, and starts idling for more messages. Nevertheless, if just an email is received between my program does FETCH, and IDLE, the notification of more messages (EXISTS) is lost forever.

To show it better in pseudocode:

loop {
    client.fetch(all);
    // Another client sends an email to the inbox just at this moment.
    client.idle().wait_while(); // Never receives a response to the last email sent by the other client.
}

I do not know if there is any workaround for this issue. The only idea that comes to my mind is to open 2 IMAP connections, one for idling and another for fetching. But I understand the protocol is intended to work in all scenarios using one connection.

If useful, I'm connecting the client to Gmail, not sure if it can be a wrong IDLE implementation by its side.

Thanks in advance!

jonhoo commented 1 year ago

That's a great question! And unfortunately not one I think I have a great answer to. Neither does the internet it seems. I think this may just be a fundamental limitations with IDLE. The StackOverflow answer I linked suggests that servers will eliminate this race condition on your behalf, but I don't know how true that is in practice. At least I couldn't find any references to it. The SO question also suggested maybe using 2 connections, so you may have to do so something like that unfortunately.

If you do come up with a good solution, please post it back here! Especially if there's something we can do in the imap crate to make it easier to work with.

dezyh commented 1 year ago

Not sure if useful but I found another answer that agrees with the above but provide a little extra information and some relevant sections in the RFC.

jonhoo commented 1 year ago

Yeah, it might be that these end up exposed as "unsolicited responses", which we also expose in the API. I'm going to go ahead and close this, as I don't think there's much the imap crate could do here, but if you think of something, please do let us know!