Skip to content

reject zone ids and prefix lengths in IPv6 email literals - #437

Open
sahvx655-wq wants to merge 1 commit into
apache:masterfrom
sahvx655-wq:email-ipv6-literal-zone-prefix
Open

reject zone ids and prefix lengths in IPv6 email literals#437
sahvx655-wq wants to merge 1 commit into
apache:masterfrom
sahvx655-wq:email-ipv6-literal-zone-prefix

Conversation

@sahvx655-wq

Copy link
Copy Markdown
Contributor
  • Read the contribution guidelines for this project.
  • Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
  • I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute? Claude Code (Anthropic) helped investigate the behaviour and draft the change and the test; I reviewed, ran and verified all of it before submitting.
  • Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
  • Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied.
  • Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
  • Each commit in the pull request should have a meaningful subject line and body.

EmailValidator.isValidDomain matches a bracketed host with IP_DOMAIN_REGEX, whose address group is (.*), and passes a tagged literal straight to InetAddressValidator.isValidInet6Address. That validator is general purpose and deliberately strips a trailing zone id (%eth0) and a CIDR prefix length (/64) before checking the address, so isValid("user@[IPv6:fe80::1%eth0]"), isValid("user@[IPv6:2001:db8::1/64]") and isValid("user@[IPv6:::1/128]") all return true. I noticed it while tracing the IPv6: tag handling from #428 through to the address check: RFC 5321 section 4.1.3 builds IPv6-addr from hex groups, : and the embedded IPv4 dotted form only, with no zone or prefix production, so none of those literals can name a mailbox host. Left as it is, an address that passes validation can carry a literal that a conformant SMTP parser refuses outright. The IPv4 branch is unaffected because isValidInet4Address is a strict regex.

The fix stays in the regex, as asked on #428: the address group becomes [0-9a-fA-F:.]+, the same class UrlValidator already uses for a bracketed IPv6 host, so a literal carrying % or / no longer matches the address-literal pattern and drops through to the symbolic-domain check, which rejects it. The tagged forms, including the embedded IPv4 form, parse exactly as before, and InetAddressValidator keeps its zone and prefix support for callers that want it. The regression test fails on master at its first assertion and passes with the change; the full default Maven goal with -Ddoclint=all is green (3300 tests, checkstyle, PMD, SpotBugs and japicmp clean).

EmailValidator.isValidDomain let InetAddressValidator.isValidInet6Address accept a zone id or CIDR prefix length inside a bracketed IPv6 address literal, which RFC 5321 section 4.1.3 does not allow. Restrict the address group of IP_DOMAIN_REGEX to hex digits, ':' and '.' so such literals no longer match the address-literal pattern.
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.

1 participant