-
Notifications
You must be signed in to change notification settings - Fork 307
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v1: serialization of SELECT / FETCH flags allows for empty strings #544
Comments
well, now i realised that same RFC has actual grammar rules in section 9, which say:
which would mean that the serialization of flags is wrong, either in go-imap or maddy, and the other clients are just being overly flexible with parsing those |
aaand attaching a debugger to maddy reveals that it's indeed passing an empty string to both
while i think this should be a scenario that's being handled a little differently by this library, it's a maddy issue after all, so feel free to close it if there's no desire to fix this in some other way |
the same issue exists with |
FWIW, go-imap v2's server would error out in this situation: go-imap/internal/imapwire/encoder.go Line 201 in 38838c5
|
The error originally comes from alps commit
652ea9c7
, usinggo-imap v2.0.0-alpha.6
.Tracing the connection reveals the following exchange:
I assume the issue lies in the two spaces between
\Draft
and$Label1
- however, that's being generated bygo-imap v1.2.2-0.20220928192137-6fac715be9cf
, running with maddy commitd9920f07
.For the record, RFC 9051 specifies a parenthesized list to be "delimited by space", which might be interpreted ambiguously... but seeing how Thunderbird, Evolution or other mail clients have no issue parsing that response, I imagine it's been assumed that it's valid grammarThe text was updated successfully, but these errors were encountered: