reject zone ids and prefix lengths in IPv6 email literals - #437
Open
sahvx655-wq wants to merge 1 commit into
Open
reject zone ids and prefix lengths in IPv6 email literals#437sahvx655-wq wants to merge 1 commit into
sahvx655-wq wants to merge 1 commit into
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
mvn; that'smvnon the command line by itself.EmailValidator.isValidDomainmatches a bracketed host withIP_DOMAIN_REGEX, whose address group is(.*), and passes a tagged literal straight toInetAddressValidator.isValidInet6Address. That validator is general purpose and deliberately strips a trailing zone id (%eth0) and a CIDR prefix length (/64) before checking the address, soisValid("user@[IPv6:fe80::1%eth0]"),isValid("user@[IPv6:2001:db8::1/64]")andisValid("user@[IPv6:::1/128]")all return true. I noticed it while tracing theIPv6:tag handling from #428 through to the address check: RFC 5321 section 4.1.3 buildsIPv6-addrfrom 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 becauseisValidInet4Addressis a strict regex.The fix stays in the regex, as asked on #428: the address group becomes
[0-9a-fA-F:.]+, the same classUrlValidatoralready 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, andInetAddressValidatorkeeps 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=allis green (3300 tests, checkstyle, PMD, SpotBugs and japicmp clean).