[
https://issues.apache.org/jira/browse/VALIDATOR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17842719#comment-17842719
]
Philippe Cloutier edited comment on VALIDATOR-487 at 5/2/24 3:12 AM:
---------------------------------------------------------------------
Thank you very much Michael, but I'm sorry to report the title I proposed is
quite misleading. I just had a look at EmailValidator's source (the latest
version), and I'm afraid the code is way dumber than I imagined. The code just
isn't strict enough, which does cause "Internationalized addresses" to be
accepted whether or not the developer prefers RFC 6530 or 5321, but likely
other addresses invalid even per RFC 6530 too. I am not familiar enough with
the RFCs to say more though:
[https://github.com/apache/commons-validator/blob/master/src/main/java/org/apache/commons/validator/routines/EmailValidator.java#L170]
What is clear is that validation is based on a blacklist, so new characters are
automatically "supported". In other words, {*}support for RFC 6530 is purely
accidental{*}. The code appears to be based on an old amateurish algorithm
which probably wasn't meant to end up in an Apache project. This limitation is
acknowledged in the class's description:
{quote}This implementation is not guaranteed to catch all possible errors in an
email address.
{quote}
Unfortunately, the _isValid_ method's specification does not have such a
disclaimer.
I recommend to:
# Document the code (give at least 1 example of a string which matches each
pattern)
# Rewrite it to support RFC 6530 validation
# Add EmailValidator constructors with an extra argument to indicate whether
or not "internationalized addresses" should be allowed.
# Deprecate current constructors to direct developers to the new constructors
# Move the credit out of the JavaDoc description. It could go in a @author tag.
# Remove the mention of
[https://javascript.internet.com,|https://javascript.internet.com,/] which is
broken
Could someone (perhaps [~michael-o]) please:
# Retitle this to something like: "EmailValidator insufficiently strict
("internationalized addresses" always pass as valid)"
# Add version 1.8 as affected
was (Author: chealer):
Thank you very much Michael, but I'm sorry to report the title I proposed is
quite misleading. I just had a look at EmailValidator's source (the latest
version), and I'm afraid the code is way dumber than I imagined. The code just
isn't strict enough, which does cause "Internationalized addresses" to be
accepted whether or not the developer prefers RFC 6530 or 5321, and likely
other addresses even invalid per RFC 5321 too. I am not familiar enough with
the RFCs to say more though:
[https://github.com/apache/commons-validator/blob/master/src/main/java/org/apache/commons/validator/routines/EmailValidator.java#L170]
What is clear is that validation is based on a blacklist, so new characters are
automatically "supported". In other words, {*}support for RFC 6530 is purely
accidental{*}. The code appears to be based on an old amateurish algorithm
which probably wasn't meant to end up in an Apache project. This limitation is
acknowledged in the class's description:
{quote}This implementation is not guaranteed to catch all possible errors in an
email address.
{quote}
Unfortunately, the _isValid_ method's specification does not have such a
disclaimer.
I recommend to:
# Document the code (give at least 1 example of a string which matches each
pattern)
# Rewrite it to support RFC 6530 validation
# Add EmailValidator constructors with an extra argument to indicate whether
or not "internationalized addresses" should be allowed.
# Deprecate current constructors to direct developers to the new constructors
# Move the credit out of the JavaDoc description. It could go in a @author tag.
# Remove the mention of
[https://javascript.internet.com,|https://javascript.internet.com,/] which is
broken
Could someone (perhaps [~michael-o]) please:
# Retitle this to something like: "EmailValidator insufficiently strict
("internationalized addresses" always pass as valid)"
# Add version 1.8 as affected
> EmailValidator insufficiently strict ("internationalized addresses" always
> pass as valid)
> -----------------------------------------------------------------------------------------
>
> Key: VALIDATOR-487
> URL: https://issues.apache.org/jira/browse/VALIDATOR-487
> Project: Commons Validator
> Issue Type: Bug
> Affects Versions: 1.6, 1.8.0
> Reporter: Michael Osipov
> Priority: Major
>
> Coming from https://github.com/everit-org/json-schema which uses
> {{EMailValidator}} to validate JSON schema type:
> {noformat}
> {
> "type": "string",
> "format": "email"
> }
> {noformat}
> The problem is that the following email is returned as valid although
> according to rfc5321#section-4.1.2 local-part/dot-string/atom/atext
> (https://mailarchive.ietf.org/arch/msg/ietf-smtp/QlSTxHlY6cP6_Xwl6CpDvL5PQLo/)
> it must only contain ASCII printable chars:
> {{др.живаго@example.com}}.
> I'd expect that one could validate standard addresses and IDN ones.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
