Parsing failure: Strict whitespace handling on FETCH responses (extra space before closing parenthesis)

[rustmailer]

I’m currently using imap-proto for a mail archiving project and have encountered a parsing issue with FETCH responses. It seems the parser is strictly rejecting responses that contain a space before the closing parenthesis in certain fields.

#[test]
fn test_fetch2222() {
    parse_response(b"* 11784 FETCH (UID 87567 INTERNALDATE \"06-May-2023 18:48:30 +0200\" RFC822.SIZE 5799845 )\r\n").unwrap();
}

The parser fails on this pattern:
RFC822.SIZE 5799845 )

If I remove the space (RFC822.SIZE 5799845), it parses correctly.

#[test]
fn test_fetch2222() {
    parse_response(b"* 11784 FETCH (UID 87567 INTERNALDATE \"06-May-2023 18:48:30 +0200\" RFC822.SIZE 5799845)\r\n").unwrap();
}

It appears the grammar definition is strictly expecting the closing ) immediately after the value. However, we have observed that some real-world IMAP servers include this space.

Is this strictness intentional per the RFC? If so, would you be open to a PR that makes the parser more tolerant of optional whitespace in these response structures to improve compatibility with real-world servers?

Thanks for your time and for maintaining this library!

[djc]

It is intentional but I'm open to targeted lenience. Please submit a PR including a comment.

[rustmailer]

@djc
I’ve submitted a small PR to address the whitespace issue. The change is very targeted—it simply introduces a minor lenience for trailing whitespace before the closing parenthesis.

I’ve verified that all existing unit tests pass, so this change should not have any negative impact on other parsing logic. When you have a moment, could you please take a look?

Thanks again for your guidance!