Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible missed test cases #7

Open
rjcmln opened this issue Apr 27, 2022 · 2 comments
Open

Possible missed test cases #7

rjcmln opened this issue Apr 27, 2022 · 2 comments

Comments

@rjcmln
Copy link

rjcmln commented Apr 27, 2022

Hi, thanks for creating this Rust crate, I started using it and I like it very much.

I was using these documents to examine intentional email addresses:
https://en.wikipedia.org/wiki/Email_address#Internationalization
https://en.wikipedia.org/wiki/International_email
and I found some cases that don't match.

  1. Marked as invalid, should be valid
    "[email protected]"

  2. Marked as valid, should be invalid
    "1234567890123456789012345678901234567890123456789012345678901234+x@example.com"
    "i_like_underscore@but_its_not_allowed_in_this_part.example.com"

  3. Suggestion: maybe non-trimmed emails should also be returned as invalid:
    " [email protected]"

Maybe these Wikipedia documents are irrelevant for your RFC 5322 and RFC 6532 definitions, but if they are - please double-check.

Thanks and keep up the great work

@Sayan751
Copy link
Owner

@rjcmln Thank you for your words of encouragement!

The email addresses that you suggest being invalid are actually valid in the broader sense of the RFCs. You can verify that from https://isemail.info/.

Are you getting the same invalidation result for the first example when you use the RC version? You can try that from here: https://crates.io/crates/email-address-parser/2.0.0-rc1

@rjcmln
Copy link
Author

rjcmln commented Apr 29, 2022

Hi @Sayan751 I did the checks you needed.

I am getting the same results with email-address-parser = "2.0.0-rc1"
as I initially got with email-address-parser = "1.0.3", for all the cases I listed.

I did the checks on https://isemail.info/ and for 2. I got "The address is only valid according to the broad definition of RFC 5322. It is otherwise invalid."
So I guess for my point 2: it's a matter of the definition, probably a false alarm.

For my point 1: https://isemail.info/ says "Address is valid", so that is probably a real issue.

For my point 3: I was thinking if leading/trailing spaces are not allowed by the definition, then maybe the caller should make sure that are trimmed out before they get to you. For " [email protected]" your result is valid and you return back the untrimmed " [email protected]". In strict terms that is not a valid email address 😃 but I'm sure all the email clients will trim it out. It's not a real problem, I just shared my thoughts on why I suggested it.

Thanks for the clarifications and let me know if you need more checks

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

No branches or pull requests

2 participants