Live data from Hacker News

Stop Validating Email Addresses with Regex (2012)

davidcel.is

81–90 of 228 posts

Re: Stop Validating Email Addresses with Regex (2012)

#81
post #17

RFCs for email addresses are cool, but on the web we have our own standards! https://html.spec.whatwg.org/multipage/input.html#valid-e-ma... "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 strings in manner…

What is the significance of [a-zA-Z0-9-]{0,61}? Some special limit on 61 characters?

Domain labels are limited to 63 bytes, with the [a-z..] before and after that makes 61 + 1 + 1 = 63.

Re: Stop Validating Email Addresses with Regex (2012)

#82
post #47

Earlier quoted context omitted.

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: ^[^@\s\x00-\x1f]+@[^@\s\x00-\x1f.]+(:?\.[^@\s\x00-\x1f.]+)*$ It requires exactly one "@", disallows whitespace and control characters, prevents repeated dots in the domain name, and ensures the domain doesn't end with a dot. It catches a few typos and…

Domains ending with a dot are valid though, and it's needed sometimes. For example, someone@ai. (ai. is a TLD) is a different email than someone@ai (ai is a local hostname)

> it's needed sometimes

When is this needed in the context of a Rails app? You never want to send emails to local hosts, and emails directly on the TLD is possible, but very little will work with them in practice.

Re: Stop Validating Email Addresses with Regex (2012)

#84
post #17

RFCs for email addresses are cool, but on the web we have our own standards! https://html.spec.whatwg.org/multipage/input.html#valid-e-ma... "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 strings in manner…

Oh wow, that is awful.

Re: Stop Validating Email Addresses with Regex (2012)

#85

Does anyone on HN have any of these "surprising" email addresses that most people and developers do not expect? How does it work with common e-mail clients? How do people react when you show/tell them your email? I have a domain that uses non-ascii characters, and while I can receive emails on that domain, hosted by Fastmail, Fastmail clients refuses to _send_ emails to that domain (I can, if I type the domain as Pun…

I have my own domain and a catch-all setup, so when I sign up for a service, it's the-service-name@my-domain-name.com, if I give someone my email address, it's their-name@my-domain-name.com

It makes it easy for me to keep track of who is sending me what + who is sharing my email with third parties, but definitely confuses some people.

Re: Stop Validating Email Addresses with Regex (2012)

#86
Validate emails in a manner that is representative of the typical use of your service.

If it’s a specialist email processing tool, then you should probably follow an RFC.

If it’s a dating app, you can probably just use a regex that covers common cases to help users avoid typos.

I think the decision is similar to the one picking how modern are the browsers you are going to support. It’s a trade-off. That’s my take on it, don’t have a cow, man.

Re: Stop Validating Email Addresses with Regex (2012)

#88

This won't be popular, but: 1. An experienced dev just killed 54k stars on GitHub due to pressing a button in an auto-pilot mode. Do you think a Joe High who wants to give you $100 won't ever type '2' instead of '@'? What about an old lady? Or someone with physical difficulties? Have you personally ever made a typo in an email? 2. That code in the article is not color highlighted (rainbowed for Regex) or formatted pr…

Simple validation is easy enough to implement and will cover 99% of cases. For the rest you use verification, have the user activate their account before doing anything.

Which is a pet peeve of mine; I've got an older e-mail address that probably ended up on some list, now there's people from Thailand and the UAE registering accounts using that e-mail address. Now while my account is still secure (2FA, long password, the works), it doesn't stop people from using it. Services like this one webshop and Deezer and probably a few others do not wait for e-mail verification before allowing users to place orders or use their service, or at least the free trial part of it.

Re: Stop Validating Email Addresses with Regex (2012)

#89
post #47

Earlier quoted context omitted.

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: ^[^@\s\x00-\x1f]+@[^@\s\x00-\x1f.]+(:?\.[^@\s\x00-\x1f.]+)*$ It requires exactly one "@", disallows whitespace and control characters, prevents repeated dots in the domain name, and ensures the domain doesn't end with a dot. It catches a few typos and…

Domains ending with a dot are valid though, and it's needed sometimes. For example, someone@ai. (ai. is a TLD) is a different email than someone@ai (ai is a local hostname)

I'm pretty sure the one guy behind ai. doesn't justify that you change your regex for him. Let's not be overly pedantic.

Re: Stop Validating Email Addresses with Regex (2012)

#90
post #47

Earlier quoted context omitted.

Domains ending with a dot are valid though, and it's needed sometimes. For example, someone@ai. (ai. is a TLD) is a different email than someone@ai (ai is a local hostname)

> it's needed sometimes When is this needed in the context of a Rails app? You never want to send emails to local hosts, and emails directly on the TLD is possible, but very little will work with them in practice.

> You never want to send emails to local hosts

That's not entirely true, it depends on how your mailing infrastructure is set up.

Post reply on HN