bug: Valid Email address not recognised as such

[wischi-chr]

Describe the bug

The E-Mail validator is probably a bit too restrictive. I use the TLD .email for my email address (like [email protected]), but windmill reports "invalid email address".

To reproduce

1. Setup new instance
2. Enter [email protected] on the "Setup Secure Account" page
3. "invalid email address"

Expected behavior

Valid E-Mail addresses can be used during account setup

Application version

Latest docker image (Windmill Community Edition v1.423.1)

[N4v41]

It looks that the regex is parsing 2 to 4 chars in the tld of e-mail so if the tld is longer it fails the check: https://github.com/windmill-labs/windmill/blob/e4583e9b2366b90f31eb015c4dfc21f07b0bc31e/frontend/src/lib/components/StringTypeNarrowing.svelte#L70 I was trying to look at the maximum characters in a tld but i didin't find the correct rfc for that, for e-mails the maximum length is 255 per rfc3696 the domain part should not exceed 63. on rfc6927 the longest domain name for a country tld is "XN--MGBERP4A5D4AR" wich is a punycode for ("السعودية") saudi arabia domain name. on the tld list provided by iana looks like the longest tld is "XN--VERMGENSBERATUNG-PWB"("vermögensberatung"), so is quite lengthy using 25 chars.

did some tests, and increasing to 25 chars it would accept practically any current registered domain tld: but, I don't know if this would have any other negative impacts in the database for example. to be a little bit more practical, maybe 20 chars would be enough.

[dahifi]

Bumping this, I use a .digital TLD.

💡 Recommended Solution

1. Use Canonical Source for TLDs

Pull the IANA list of valid TLDs and parse it into an enum, list, or trie for validation purposes. This ensures future-proofing and standards compliance.

2. Regenerate the Regex Dynamically

During build or periodically (e.g., via GitHub action or pre-commit hook), fetch and compile the TLD list into a regex-compatible suffix list (e.g., .com|.org|.digital|...) and replace the hardcoded TLD pattern in the validation logic.

3. Improve Regex Structure

Consider replacing the existing hardcoded email regex with one that: • Uses a simplified but standards-compliant local-part rule • Dynamically matches against valid TLDs via suffix pattern or lookups • Falls back gracefully if the TLD list cannot be fetched (e.g., by allowing longer TLDs by default)

⸻

✅ Acceptance Criteria • [email protected] is accepted as valid. • Windmill email validation supports all TLDs listed in tlds-alpha-by-domain.txt. • The solution does not introduce significant latency or instability in the frontend.

[joejordan]

Bump. All valid TLDs should be accepted. My .global email address was flagged as invalid.

[wischi-chr]

Windmill email validation supports all TLDs listed in tlds-alpha-by-domain.txt.

IMHO it not necessary to validate emails (beyond a simple length check to prevent DOS attacks). E-Mails are typically used for two things.

1. as a user ID
2. to send E-Mails

For 1 you can use basically anything, so you don't have to validate anything and regarding 2 there is only one way to find out if it's a legitimate e-mail. Send an email with a confirmation link the user has to click - so again, no email validation needed, just send a link, if the user clicks it, the e-mail was valid.

My advice (not only for Windmill but basically everyone reading this): do not validate e-mail addresses, because you will (evidently) get it wrong.

Just to prove a point, this is a valid email address:
"very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@[IPv6:2001:0db8:85a3:0000:0000:8a2e:0370:7334]

[brockcaldwell]

I too, have a .digital email that is not considered valid.