Hacker News Reader

Comment by bshimmin | Hacker News Reader

Utterly pointless. An email regex tells you that the email address (probably) conforms to a pattern that means it might be a valid email address (for now, until new weird TLDs emerge and the patterns have to change...), but it has no way of telling you whether that address can actually receive mail. `foo@bar` fails these regular expressions and `foo@bar.invalid` passes them, but neither will receive mail.

As I have told people for many years: if you must do this, check at most if there's an @ and (perhaps) a dot somewhere after the @, which is enough to stop someone who has accidentally put their name in the email address field, or a similar user error. Anything else is a waste of brainwidth and will result in more problems than it solves.

View on HN

The dot isn't mandatory either... There are also local (for example company internal) email services.

Completely useful, as part of a two step process:1

1. Filter with the regex - what's left has a valid format, making step 2 much saner.

2. Extract and validate the domain name - super simple now, because the domain component is known to be sane.

(Optional but good idea 3: Handle exceptions....)

Step 1 is almost always the hardest part, now it's mostly done.

The assumption here is "0. create a regex that does not have false negatives". You seem to be taking the author's word for the "99.9% Works" part - based on what? (Exactly.)

Correctness and utility are two different things, feel free to investigate the former whilst we discuss the latter....

Well thank you, I doubt I would have come to such conclusion by myself. Are you saying that "turn away 0.1% of your customers" is a useful approach? Well, your call, I guess.

Whoa, there: You're shifting your argument. Are you now accepting that it is 99+% correct? Your original objection was as to the correctness of the regex.

If it is 80% good, then, yeah, your underlying assertion is likely good: Too little coverage to be all that useful. But 99+% coverage? For a quick pass filter? That's pretty good, we can work with those numbers.

After all, one could have multiple layers of progressively more accurate but progressively slower filters. Not an uncommon or unusual approach.

Besides, the JS version could be very useful as a quick pass usability check, validating whether the user made a silly mistake. And adding some logic to record the bogus entry, compare it to what they write next, pass it to the server if need be, can all be very useful.

> `foo@bar` fails these regular expressions and `foo@bar.invalid` passes them, but neither will receive mail.

foo@bar could still receive email, if you had a host in your DNS domain named bar, with a user named foo.

It's a very good offline check. If that's not enough, you have to do online checking (DNS, RCPT TO, actual mail with confirmation link, etc.)

It's excellent to extract email addresses from a text.

Reply on news.ycombinator.com