Handle unsolicited "* OK Searched 91% of the mailbox, ETA 0:01" message #179
Conversation
…ce an error. Lookig into it, dovecot sometimes responds with * OK Searched 91% of the mailbox, ETA 0:01 which is not handled when expecting a response to a Fetch message. This is a small change to handle this case. I have made it quite explicit - it only handles an OK status with no code, as I'm not sure whether other messages which have an unknown code (but do contain a code) would be better handled by returning an error as is currently the case.
|
Firstly, thank you for the rust-imap crate. I have found it very useful! If it's any help, the IMAP server I see this message from is Dovecot v2.2.36 with a pretty vanilla setup. |
|
Hi! Thank you for the PR ❤️ This seems like really odd behavior. I don't think the specification allows for these kinds of random untagged |
|
Hi, I don't know the IMAP specs well, but looking at the definition of the OK response suggests it's allowed (https://tools.ietf.org/html/rfc3501#section-7.1.1)
I have had a look over the dovecot source code though as it's probably the most popular IMAP server on Linux (and the one I saw this behaviour on). I think the function responsible for these untagged OK messages is notify_ok The call I was seeing was from https://github.com/dovecot/core/blob/master/src/lib-storage/index/index-search.c#L1545, but there are some others too - they all seem to be sent when the server is taking time to complete an operation and is letting the client know in an unstructured way (this one just says "Hang in there.." https://github.com/dovecot/core/blob/master/src/lib-storage/index/maildir/maildir-sync.c#L259) Hope that helps, Paul |
|
Ah, that's helpful, thank you! In that case I'd be happy to land this. Unfortunately, it'll have to wait for the release of |
| } if imap_proto::Status::Ok == status && code.is_none() => { | ||
| unsolicited | ||
| .send(UnsolicitedResponse::Uncategorised( | ||
| information.unwrap_or("").to_string(), |
| status, | ||
| code, | ||
| information, | ||
| } if imap_proto::Status::Ok == status && code.is_none() => { |
There was a problem hiding this comment.
Is it necessary for the code to None of this to be considered informational? From what I can tell, it's enough for the response to be untagged for it to be considered unsolicited — or am I missing something?
There was a problem hiding this comment.
In which case we should include the code in the unsolicited response type.
| @@ -277,6 +277,10 @@ pub enum UnsolicitedResponse { | |||
| /// sequence numbers 9, 8, 7, 6, and 5. | |||
| // TODO: the spec doesn't seem to say anything about when these may be received as unsolicited? | |||
| Expunge(Seq), | |||
| /// An uncategorised response - one which has no code associated with it, just a text | |||
There was a problem hiding this comment.
Let's try to be a little more helpful here to potentially-confused receivers of this code. How about:
/// An unsolicited [`OK` response](https://tools.ietf.org/html/rfc3501#section-7.1.1) that
/// indicates an information-only message; the nature of the information MAY be
/// indicated by a response code.
///
/// The untagged OK is also used as one of three possible greetings
/// at connection startup. It indicates that the connection is not
/// yet authenticated and that a `LOGIN` command is needed.
Notice(String)
When fetching a large number of UIDs, rust-imap would sometimes produce an error.
Looking into it, dovecot sometimes responds with
which is not handled when expecting a response to a Fetch message.
This is a small change to handle this case. I have made it quite explicit - it only handles an OK status with no code, as I'm not sure whether other messages which have an unknown code (but do contain a code) would be better handled by returning an error as is currently the case.
This change is