Skip to content

Parse rfc6532 addresses - #3130

Open
chibenwa wants to merge 27 commits into
apache:masterfrom
chibenwa:parse-rfc6532-addresses
Open

Parse rfc6532 addresses#3130
chibenwa wants to merge 27 commits into
apache:masterfrom
chibenwa:parse-rfc6532-addresses

Conversation

@chibenwa

Copy link
Copy Markdown
Contributor

No description provided.

chibenwa and others added 26 commits September 3, 2026 10:56
This changes the handling of some noncompliant IMAP clients, which James
would not tolerate before.
Application-layer code often assumes that addresses can be compared using
String.equalsIgnoreCase(), and some also uses regular expressions or
substring matching on addresses. This commit provides addresses to
upper-layer code in their UTF8 form, so that kind of code continues to
work.

This might also have security implications: If upper-layer code can be
confused about whether two addresses are the same, that sounds as if an
attacker could exploit the confusion. This change should block the
possibility.
RFC 6532 says we SHOULD do this and JAMES is generally very careful, so I
did this as well.
…etc.

This should not make a difference, but a sufficiently inventive attacker
might combine it with something to confuse some code...
Once the server advertises UTF8=ACCEPT, angus-mail enables it and then takes
its supportsUtf8() branch in IMAPProtocol.search(), which passes a null charset
down to Argument.writeString(String) and encodes the search strings with
ASCIIUtility.getBytes() -- one truncated byte per char. "天天向上" reaches the
server as 29 29 11 0A, so the criterion is destroyed client-side before it hits
the wire and no server-side decoding can recover it. Same in angus-mail 2.0.5,
and there is no property to keep the client from enabling the capability.

Send the RFC 6855 wire form ourselves instead: UTF-8 octets in literals, plus a
quoted-string variant. These fail against consumeLiteral()'s former US-ASCII
decoding, so they cover the gap they were written for.
@chibenwa
chibenwa force-pushed the parse-rfc6532-addresses branch from 2a4b7ca to 1e8e1e4 Compare September 3, 2026 08:56
@chibenwa

chibenwa commented Sep 3, 2026

Copy link
Copy Markdown
Contributor Author

(
Simple master rebase, no changes.
The ci failed with build compilation.
I suppose this is due to recent master changes causing compilation issue atop this branch: conflicts but without merge conflict.
)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants