Possible missed test cases about email-address-parser

[Sayan751]

@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]

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