fix: string().email() does not validate successfully where emails have Ampersand (&) in them #3913

[SunilChackoPS]

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

[netlify]

✅ Deploy Preview for guileless-rolypoly-866f8a ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	d918b5a
🔍 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.

[andersk]

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.

[SunilChackoPS]

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!