Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's Impossible to Validate an Email Address

elliot.land

Post reply on HN
Print view View original

61–68 of 68 posts

Re: It's Impossible to Validate an Email Address

#61

Post by mcv »

s_kilk wrote: post #36
mcv wrote: post #11

If you were to ask me for a regex, I'd say /.+@.+/. That's the easiest and most accurate way to do it by regex. Sure, some invalid addresses may still get accepted, but that is unavoidable. Even the most thorough validation[0] is going to accept nonexistent addresses. [0] Except those that validate by sending a mail to it. Sending an email is the only way to be sure.

> If you were to ask me for a regex, I'd say /.+@.+/ How about "one@two@three@four@example.com"?

Any validation is also going to allow "someonewhodoesntexist@nonexistentdomain.com", unless you send an email to it.

Re: It's Impossible to Validate an Email Address

#62

Post by mcv »

LinuxBender wrote: post #21
mcv wrote: post #11

If you were to ask me for a regex, I'd say /.+@.+/. That's the easiest and most accurate way to do it by regex. Sure, some invalid addresses may still get accepted, but that is unavoidable. Even the most thorough validation[0] is going to accept nonexistent addresses. [0] Except those that validate by sending a mail to it. Sending an email is the only way to be sure.

# get email addresses grep -EiEio '\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}\b' # censor email addresses sed -r 's/( )/\1--removed--\2/g' If email doesn't meet those, I drop them on the floor. Then again, I drop email on the floor for lesser reasons.

This would not allow email addresses with an = in them, which I've had. The point of my overly tolerant regex is exactly that: any more restrictive validation is going to drop some perfectly legal email addresses. Sending an email is the only way to be sure.

Re: It's Impossible to Validate an Email Address

#63

Post by breakingcups »

Symbiote wrote: post #33
marcosdumay wrote: post #23

Earlier quoted context omitted.

It isn't a valid address. TLDs must not resolve, so it should be impossible to make a server handle it (yet, it is mostly possible, because most DNS servers do not completely implement the RFCs - still, there's no guarantee it will work on every network).

The first one I found that does resolve: http://ai./ It has an MX record too. There is nothing wrong with this.

It is most definitely wrong, if your definition of wrong includes disallowed / not recommended by ICANN and IAB.

What is wrong with it is, amongst other things, the real-world possibility of colliding with internal hostnames.

Re: It's Impossible to Validate an Email Address

#64

Post by LinuxBender »

lstamour wrote: post #32
LinuxBender wrote: post #21

Earlier quoted context omitted.

# get email addresses grep -EiEio '\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}\b' # censor email addresses sed -r 's/( )/\1--removed--\2/g' If email doesn't meet those, I drop them on the floor. Then again, I drop email on the floor for lesser reasons.

So any new gtld longer than four characters would be dropped on the floor? E.g. .software? If you're trying to censor email addresses from a file, that doesn't work that well. :)

Yes. Actually for the longest time I rejected the connection with "Your name is too awesome!"

Re: It's Impossible to Validate an Email Address

#65

Post by LinuxBender »

Symbiote wrote: post #38
LinuxBender wrote: post #21

Earlier quoted context omitted.

# get email addresses grep -EiEio '\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}\b' # censor email addresses sed -r 's/( )/\1--removed--\2/g' If email doesn't meet those, I drop them on the floor. Then again, I drop email on the floor for lesser reasons.

So you're blocking email from your local .museum, from anyone who has an Irish name like O'Connor, all international TLDs, and most newer TLDs.

Yes.

Re: It's Impossible to Validate an Email Address

#66

Post by walterstucco »

vostok wrote: post #52

Wouldn't it be reasonable to have a sanity check that can be bypassed by the user? It is very likely to be a mistake if there's no full stop in the address, but there are exceptions [0]. I would like to see a warning if I accidentally type vostok@examplecom instead of vostok@example.com. [0] https://mail.gnome.org/archives/evolution-list/2002-January/...

your first example is a valid email

Re: It's Impossible to Validate an Email Address

#67

Post by tyingq »

thedufer wrote: post #34
tyingq wrote: post #16

If you happen to control the web page where the user is entering the email, this little piece of code has been a godsend for us: https://github.com/mailcheck/mailcheck I agree with the idea that it's impossible to validate. But, mailcheck takes the approach of seeing if the email is potentially wrong, then prompting the user with what it thinks they meant. It's usually right, but if not, it allows whatever the user w…

This kind of stuff is great - make suggestions, but allow it to go through even if you think it's wrong. For the last email validation I worked on, there were only 2 absolute blockers - there must be an @ sign, and the domain must have MX records (emails that are technically valid remain useless if we can't send them anything). There were a number of other checks (being close to yahoo.com or gmail.com or other common…

>>domain must have MX records

Technically, the RFC(5321) says MX records aren't required. You may be throwing out some small number of valid emails.

"If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR with a preference of 0"

Re: It's Impossible to Validate an Email Address

#68

Post by nradov »

kristianp wrote: post #57
nradov wrote: post #53

For anyone who would like to test their email address validation code, I wrote a fuzzer which can generate syntactically valid addresses (among other things). https://github.com/nradov/abnffuzzer

Is there ABNF for email addresses in an RFC?

Yes RFC 2822. Look for the addr-spec rule.

https://tools.ietf.org/html/rfc2822#section-3.4.1

Post reply on HN