-
Notifications
You must be signed in to change notification settings - Fork 181
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
\*
is not a valid IMAP flag
#633
Comments
By the way, do you know if any "real" servers respond with |
oops... I accidentally tapped the close button there! |
* Motivated by greenmail-mail-test/greenmail#633. * Fixes #228.
Thx alot for the detailed bug report, @nevans . Regarding you question: I can not say anything about 'real' mail servers, unfortunately. |
Interesting: The SELECT FLAGS result (availableFlags) is more or less ignored in JakartaMail reference implementation ... |
* Motivated by greenmail-mail-test/greenmail#633. * Fixes #228.
* Motivated by greenmail-mail-test/greenmail#633. * Fixes #228.
* Motivated by greenmail-mail-test/greenmail#633. * Fixes #228.
The workaround for #241 (PR #246) also applies to #228. I haven't seen any evidence of any "real" servers with this exact error yet. And the upstream issue (greenmail-mail-test/greenmail#633) was fixed promptly (thanks!). So I don't feel that it's critical to be compatible with it... But we _do_ need this workaround for #241. So it makes sense to at least document this issue in our test fixtures, for posterity.
The workaround for #241 (PR #246) also applies to #228. The upstream issue (greenmail-mail-test/greenmail#633) was fixed promptly (thanks!). Also, greenmail is a testing fake server and I haven't seen any evidence of any "real" servers with this exact error yet. So I don't feel that it's critical to be compatible with it... But we _do_ need this workaround for #241. So it makes sense to at least document this issue in our test fixtures, for posterity.
The workaround for #241 (PR #246) also applies to #228. The upstream issue (greenmail-mail-test/greenmail#633) was fixed promptly (thanks!). Also, greenmail is a testing fake server and I haven't seen any evidence of any "real" servers with this exact error yet. So I don't feel that it's critical to be compatible with it... But we _do_ need this workaround for #241. So it makes sense to at least document this issue in our test fixtures, for posterity.
The workaround for #241 (PR #246) also applies to #228. The upstream issue (greenmail-mail-test/greenmail#633) was fixed promptly (thanks!). Also, greenmail is a testing fake server and I haven't seen any evidence of any "real" servers with this exact error yet. So I don't feel that it's critical to be compatible with it... But we _do_ need this workaround for #241. So it makes sense to at least document this issue in our test fixtures, for posterity.
The default
FLAGS
response for theSELECT
command sends\*
, which is valid forPERMANENTFLAGS
but not forFLAGS
. See RFC3501 or RFC9051:(emphasis is mine)
The relevant formal syntax (note that
*
is not a validATOM-CHAR
):And the relevant code is here (I think):
greenmail/greenmail-core/src/main/java/com/icegreen/greenmail/imap/commands/SelectCommand.java
Line 50 in 2aa14fc
Perhaps a
mailbox.getFlags()
method could be added that simply filters out\*
frommailbox.getPermanentFlags()
?The text was updated successfully, but these errors were encountered: