email-address-parser icon indicating copy to clipboard operation
email-address-parser copied to clipboard

Published 20 hours ago • verified publisher icon Sayan751

Possible missed test cases

Open rjcmln opened this issue 3 years ago • 2 comments

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

rjcmln avatar Apr 27 '22 23:04 rjcmln

@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

Sayan751 avatar Apr 29 '22 18:04 Sayan751

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 :smiley: 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

rjcmln avatar Apr 29 '22 19:04 rjcmln