<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>Biganon</author><text>I&amp;#x27;m pretty sure the one guy behind ai. doesn&amp;#x27;t justify that you change your regex for him. Let&amp;#x27;s not be overly pedantic.</text><parent_chain><item><author>easrng</author><text>Domains ending with a dot are valid though, and it&amp;#x27;s needed sometimes. For example, someone@ai. (ai. is a TLD) is a different email than someone@ai (ai is a local hostname)</text></item><item><author>hathawsh</author><text>I tried using that expression for a while, but then a user with a valid email address containing upper unicode characters showed up. I switched to a simpler expression:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    ^[^@\s\x00-\x1f]+@[^@\s\x00-\x1f.]+(:?\.[^@\s\x00-\x1f.]+)*$
&lt;/code&gt;&lt;/pre&gt;
It requires exactly one &amp;quot;@&amp;quot;, disallows whitespace and control characters, prevents repeated dots in the domain name, and ensures the domain doesn&amp;#x27;t end with a dot. It catches a few typos and I think it allows every real email address I&amp;#x27;ve heard of.</text></item><item><author>dchest</author><text>RFCs for email addresses are cool, but on the web we have our own standards!&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;html.spec.whatwg.org&amp;#x2F;multipage&amp;#x2F;input.html#valid-e-mail-address&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;html.spec.whatwg.org&amp;#x2F;multipage&amp;#x2F;input.html#valid-e-ma...&lt;/a&gt;&lt;p&gt;&amp;quot;This requirement is a willful violation of RFC 5322, which defines a syntax for email addresses that is simultaneously too strict (before the &amp;quot;@&amp;quot; character), too vague (after the &amp;quot;@&amp;quot; character), and too lax (allowing comments, whitespace characters, and quoted strings in manners unfamiliar to most users) to be of practical use here.&amp;quot;&lt;p&gt;The regex is:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  &amp;#x2F;^[a-zA-Z0-9.!#$%&amp;amp;&amp;#x27;*+\&amp;#x2F;=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$&amp;#x2F;

&lt;/code&gt;&lt;/pre&gt;
Every browser implements this regex for &amp;lt;input type=&amp;quot;email&amp;quot;&amp;gt;.&lt;p&gt;Chromium:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;source.chromium.org&amp;#x2F;chromium&amp;#x2F;chromium&amp;#x2F;src&amp;#x2F;+&amp;#x2F;main:third_party&amp;#x2F;blink&amp;#x2F;renderer&amp;#x2F;core&amp;#x2F;html&amp;#x2F;forms&amp;#x2F;email_input_type.cc;l=46-53;bpv=0;bpt=1&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;source.chromium.org&amp;#x2F;chromium&amp;#x2F;chromium&amp;#x2F;src&amp;#x2F;+&amp;#x2F;main:thi...&lt;/a&gt;&lt;p&gt;WebKit:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;WebKit&amp;#x2F;WebKit&amp;#x2F;blob&amp;#x2F;0d7afc5a45c140c44497a81e92416f01306be877&amp;#x2F;Source&amp;#x2F;WebCore&amp;#x2F;html&amp;#x2F;EmailInputType.cpp#L38&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;WebKit&amp;#x2F;WebKit&amp;#x2F;blob&amp;#x2F;0d7afc5a45c140c44497a8...&lt;/a&gt;&lt;p&gt;Yes, do verify email addresses by sending a confirmation link if you bind users to their email addresses, though. Don&amp;#x27;t confuse validation with verification.</text></item></parent_chain></comment><story><title>Stop Validating Email Addresses with Regex (2012)</title><url>https://davidcel.is/posts/stop-validating-email-addresses-with-regex/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>hathawsh</author><text>Good to know. I guess I&amp;#x27;ll simplify again. Besides, I wonder whether the expression is vulnerable to catastrophic backtracking.</text><parent_chain><item><author>easrng</author><text>Domains ending with a dot are valid though, and it&amp;#x27;s needed sometimes. For example, someone@ai. (ai. is a TLD) is a different email than someone@ai (ai is a local hostname)</text></item><item><author>hathawsh</author><text>I tried using that expression for a while, but then a user with a valid email address containing upper unicode characters showed up. I switched to a simpler expression:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    ^[^@\s\x00-\x1f]+@[^@\s\x00-\x1f.]+(:?\.[^@\s\x00-\x1f.]+)*$
&lt;/code&gt;&lt;/pre&gt;
It requires exactly one &amp;quot;@&amp;quot;, disallows whitespace and control characters, prevents repeated dots in the domain name, and ensures the domain doesn&amp;#x27;t end with a dot. It catches a few typos and I think it allows every real email address I&amp;#x27;ve heard of.</text></item><item><author>dchest</author><text>RFCs for email addresses are cool, but on the web we have our own standards!&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;html.spec.whatwg.org&amp;#x2F;multipage&amp;#x2F;input.html#valid-e-mail-address&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;html.spec.whatwg.org&amp;#x2F;multipage&amp;#x2F;input.html#valid-e-ma...&lt;/a&gt;&lt;p&gt;&amp;quot;This requirement is a willful violation of RFC 5322, which defines a syntax for email addresses that is simultaneously too strict (before the &amp;quot;@&amp;quot; character), too vague (after the &amp;quot;@&amp;quot; character), and too lax (allowing comments, whitespace characters, and quoted strings in manners unfamiliar to most users) to be of practical use here.&amp;quot;&lt;p&gt;The regex is:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  &amp;#x2F;^[a-zA-Z0-9.!#$%&amp;amp;&amp;#x27;*+\&amp;#x2F;=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$&amp;#x2F;

&lt;/code&gt;&lt;/pre&gt;
Every browser implements this regex for &amp;lt;input type=&amp;quot;email&amp;quot;&amp;gt;.&lt;p&gt;Chromium:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;source.chromium.org&amp;#x2F;chromium&amp;#x2F;chromium&amp;#x2F;src&amp;#x2F;+&amp;#x2F;main:third_party&amp;#x2F;blink&amp;#x2F;renderer&amp;#x2F;core&amp;#x2F;html&amp;#x2F;forms&amp;#x2F;email_input_type.cc;l=46-53;bpv=0;bpt=1&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;source.chromium.org&amp;#x2F;chromium&amp;#x2F;chromium&amp;#x2F;src&amp;#x2F;+&amp;#x2F;main:thi...&lt;/a&gt;&lt;p&gt;WebKit:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;WebKit&amp;#x2F;WebKit&amp;#x2F;blob&amp;#x2F;0d7afc5a45c140c44497a81e92416f01306be877&amp;#x2F;Source&amp;#x2F;WebCore&amp;#x2F;html&amp;#x2F;EmailInputType.cpp#L38&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;WebKit&amp;#x2F;WebKit&amp;#x2F;blob&amp;#x2F;0d7afc5a45c140c44497a8...&lt;/a&gt;&lt;p&gt;Yes, do verify email addresses by sending a confirmation link if you bind users to their email addresses, though. Don&amp;#x27;t confuse validation with verification.</text></item></parent_chain></comment><story><title>Stop Validating Email Addresses with Regex (2012)</title><url>https://davidcel.is/posts/stop-validating-email-addresses-with-regex/</url></story>