colinhacks
fix: string().email() does not validate successfully where emails have Ampersand (&) in them #3913
Hello Team, Thank you for the wonderful library. I am a first timer for contribution to zod. The email address validation changed with following criteria.
A) Where & Can Appear (Local Part Only) B) The local part (before @) may include & anywhere, provided it is not: a) At the start of the local part. b) the end of the local part. c) Consecutive with itself (&&). This means & can appear in the middle of the local part multiple times, as long as the other constraints are respected.
The test case files are updated along with 'types.ts'
Please find the attached cmd output while executing yarn play after the change.
It fixes #3913
Deploy Preview for guileless-rolypoly-866f8a ready!
Built without sensitive environment variables
| Name | Link |
|---|---|
| Latest commit | d918b5a6ac96b43c46f5b359c6b4774f21eaef67 |
| Latest deploy log | https://app.netlify.com/sites/guileless-rolypoly-866f8a/deploys/6761d05a7dbb640008f2ce82 |
| Deploy Preview | https://deploy-preview-3914--guileless-rolypoly-866f8a.netlify.app |
| Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site configuration.
![netlify[bot] avatar](https://avatars.githubusercontent.com/in/13473?v=4 "Published by a pub.dev verified publisher"){kind=small}
provided it is not: a) At the start of the local part. b) the end of the local part. c) Consecutive with itself (&&).
What’s the justification for these restrictions? I don’t see such restrictions in RFC 5322.
provided it is not: a) At the start of the local part. b) the end of the local part. c) Consecutive with itself (&&).
What’s the justification for these restrictions? I don’t see such restrictions in RFC 5322.
Basically, based on practical implementation considerations and user experience concerns. some email processing tools misinterpret these as separators or special characters, leading to unexpected behavior.(Allowing & at the start or end of the local part) Yes the RFC allows multiple special characters in sequence, in practice, email addresses with consecutive '&' are rare (could easily be misinterpreted or mishandled by downstream systems) Also, this is balancing RFC flexibility with real-world usability
Still, If the maintainer believes these restrictions are unnecessary or overly conservative, I’m happy to revisit and refine them based on additional guidance!
A) Where & Can Appear (Local Part Only)
This is not part of RFC5322. The RFC allows the dot-atom token (which later resolves to allow ampersand) in both local and domain.
