-
Notifications
You must be signed in to change notification settings - Fork 4
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
Comments
@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 |
Hi @Sayan751 I did the checks you needed. I am getting the same results with email-address-parser = "2.0.0-rc1" 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." 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 |
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.
Marked as invalid, should be valid
"[email protected]"
Marked as valid, should be invalid
"1234567890123456789012345678901234567890123456789012345678901234+x@example.com"
"i_like_underscore@but_its_not_allowed_in_this_part.example.com"
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
The text was updated successfully, but these errors were encountered: