is-email-address method incorrectly validates invalid email addresses

[RaviSadam]

Description

Description

The is-email-address method in the lib/@ stdlib /assert/ module is incorrectly returning true for invalid email addresses.

Related Issues

When attempting to validate email addresses using the is-email-address method, we are encountering unexpected results. For example, when providing the following inputs:

@
@gmail.com
abc@gmail
abc@

The validation does not behave as expected.

Questions

I would like to work on these issue!!

Demo

No response

Reproduction

- We need to modify the regular expression used for validating email addresses.

Expected Results

false
false
false
false

Actual Results

true
true
true
true

Version

^0.6.0

Environments

Node.js

Browser Version

No response

Node.js / npm Version

v22.11.0 / 10.9.0

Platform

Windows 11

Checklist

• Read and understood the Code of Conduct.
• Searched for existing issues and pull requests.

[stdlib-bot]

👋 Hi there! 👋

And thank you for opening your first issue! We will get back to you shortly. 🏃 💨

[kgryte]

@RaviSadam See the package's notes: https://github.com/stdlib-js/stdlib/tree/develop/lib/node_modules/%40stdlib/assert/is-email-address#notes. The current behavior is intentional.

[RaviSadam]

@kgryte Yaa. But the regex using to check the email address is /@/ ,which only checks if the "@" symbol is present in the string. It doesn’t validate the full email format like characters before/after the "@" or the domain name.
Please look into attached code and output.

const isEmail=require('@stdlib/assert/is-email-address');
const email_address=[["abc@gmail.com",true],["abc",false],["@",false],["abc@com",false]]
for(const arr of email_address){
    const actual=isEmail(arr[0]);
    console.log(`email address: ${arr[0]},actual: ${actual}, expected:${arr[1]}`)
}

Wrong Regex: file

[kgryte]

As I stated, read the notes and the associated linked reference. From there, feel free to read RFC 2822: https://datatracker.ietf.org/doc/html/rfc2822. Coming up with a robust regexp to validate an e-mail address is a fool's errand. Most e-mail validators are broken. According to the RFC, abc@com is valid, etc.

[RaviSadam]

@kgryte
According to the RFC, an email address like abc@com is considered valid. However, I don't believe the @ symbol is inherently valid according to the RFC. While creating a robust regular expression to fully validate an email address is a challenging task, we can still write a regular expression that validates common email patterns at least.

[RaviSadam]

Here few sample tests where the is-email-address is failing

const isEmail=require('@stdlib/assert/is-email-address');
const email_address=[["@gmail.com",false],["abc@",false],["@",false],["abc@gmail@com",false]]
for(const arr of email_address){
    const actual=isEmail(arr[0]);
    console.log(`email address: ${arr[0]},actual: ${actual}, expected:${arr[1]}`)
}

output

email address: @gmail.com,actual: true, expected:false
email address: abc@,actual: true, expected:false
email address: @,actual: true, expected:false
email address: abc@gmail@com,actual: true, expected:false

[kgryte]

If you think you can succeed where all others have failed and can develop a regular expression that perfectly satisfies the RFC, by all means, feel free to submit a PR.

We spent a lot of time looking into this previously and came away with the belief that almost all validation approaches lead to erroneous false negatives. Happy to be proven wrong. However, note that we will expect full RFC 2822 compliance and any associated changes should be accompanied by a comprehensive associated test suite.

[RaviSadam]

I completely understand the challenges associated with achieving full RFC 2822 compliance, particularly given the complexity of the specification. I truly appreciate the effort your team has already put into exploring this issue. I was able to come up with a regex that perfectly aligns with common email patterns, and I’ll build on this to ensure compliance with the full specification. I’ll also ensure that any changes are accompanied by a comprehensive test suite to validate compliance and account for potential edge cases, minimizing erroneous false negatives.
If you’re okay with this approach, I’d be happy to open a PR for this issue and begin working collaboratively toward a solution.
Thank you😊

[kgryte]

@RaviSadam Based on your response, please do not submit a PR for a regexp generated by an LLM. It is nearly 100% guaranteed to be wrong.