A valid email address is a string that matches the email production of the following ABNF, the character set for which is Unicode.
- This ABNF implements the extensions described in RFC 1123. ABNF RFC5322
- RFC1034 RFC1123
email = 1*( atext / "." ) "@" label *( "." label )
-label = let-dig [ [ ldh-str ] let-dig ] ; limited to a length of 63 characters by RFC 1034 section 3.5
-atext = < as defined in RFC 5322 section 3.2.3 >
-let-dig = < as defined in RFC 1034 section 3.5 >
-ldh-str = < as defined in RFC 1034 section 3.5 >email = localpart "@" domain
+localpart = 1*( utext / "." )
+utext = ALPHA / DIGIT / "!" / ; unreserved printable ASCII
+ "#" / "$" / "%" / "&" / "'" / "*" / ; as defined in RFC5322 section 3.2.3
+ "+" / "-" / "/" / "=" / "?" / "^" /
+ "_" / "`" / "{" / "|" / "}" / "~" /
+ %80-D7FF / %E000-10FFFF ; or any other non-ASCII Unicode
+domain = < a "valid domain string", see URL section 3.4 >This definition supports internationalized email addresses ("SMTPUTF8"), including + non-ASCII values in both the localpart (the mailbox name or "left hand side") and the domain + portions of the address. The domain is required to be a + valid domain string. Because of the details + for encoding non-ASCII domain names, it is not possible to describe the domain portation of an + address in a simple regular expression. The number and range of Unicode characters permited are + interdependent and somwhat variable. The URL spec, + Section 3.5 describes how the domain is validated. URL
+This requirement is a willful violation of RFC 5322, which defines a syntax for email addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, whitespace characters, and quoted @@ -143425,6 +143438,9 @@ INSERT INTERFACES HERE