Email Validation Test Fails for Invalid Domain

[carlos-alex]

In the Email Validation Tests using Utilities, the test case with TestId: 86 (email: [email protected]) incorrectly returns true instead of false. The domain contains an invalid character (0 in .c0m), which should fail the validation but passes as valid.

Expected:
The test should return false for an invalid domain like c0m.

Actual:
The test returns true, indicating the email is valid when it should be invalid.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

for (var testCase in testCases) {
test('TestId: ${testCase['testId']} - Testing email: ${testCase['email']}', () {
bool result = isEmailValid(testCase['email'] as String);
expect(result, testCase['expectedResult']);
});
}

final testCases = [ ...
{
'testId': 86,
'email': '[email protected]',
'expectedResult': false,
},
... ]

bool isEmailValid(String email) {
return EmailValidator.validate(email);
}

email_validator: ^3.0.0

Email Validation Tests using Utilities TestId: 86 - Testing email: [email protected] [E]
Expected:
Actual:

[fredeil]

Numbers in TLDs are valid (just look at the punycode TLDS). This library doesn't check if a TLD is an existing TLD (c0m for example), that would be up to you. There are libraries and resources online on how to verify TLDs, and there has been suggestions to add it to this library, but I've decided to not clutter this library with doesn't have anything with the email syntax to do, see these issues:

• Is there any TLD checking? #23
• 1 Letter TLD should not be valid #26
• Add TLD validation based on IANA TLD list #27

For reference, read https://stackoverflow.com/questions/9071279/number-in-the-top-level-domain.

Closing this issue for now.

[carlos-alex]

I'm not entirely convinced, but ... okay!

++++++++++++++++++++++

In RFC 1035, which deals with the Domain Name System (DNS), there is no explicit mention that numbers are disallowed in domain names. However, it provides rules for label formats and restrictions on how domain names should be structured. It specifies that domain names are built from labels, which must be between 1 and 63 characters long, and each label can contain letters, digits, and hyphens (-). Importantly, labels cannot begin or end with a hyphen, and there are no restrictions against using numbers within domain names, including top-level domains (TLDs).

This means that numbers are allowed in domain names, but numeric TLDs like .c0m are invalid because .com is the only recognized TLD in that context, and the ICANN rules prohibit creating new TLDs that deviate from their predefined list (which you can check on IANA's website).

The relevant sections of RFC 1035 outline the technical structure of DNS, but specific prohibitions about invalid TLDs (like .c0m) come from ICANN's domain registration rules​(
RFC Annotations
)​(
Free Software Foundation
).

+++++++++++++++++
The domain .c1m would also be invalid, just like .c0m. This is because .c1m is not an existing Top-Level Domain (TLD) recognized by the IANA (Internet Assigned Numbers Authority) or ICANN (Internet Corporation for Assigned Names and Numbers).

The list of valid TLDs is strictly controlled and does not include any that are a mix of letters and numbers like .c1m or .c0m. TLDs are generally either generic (e.g., .com, .org, .net) or country-code TLDs (e.g., .us, .uk, .br), and they follow specific naming conventions, usually without the inclusion of numbers in this position.
++++++++++++++++

[fredeil]

Ill reopen for discussions. Thanks for contributing @carlos-alex 😄