Hacker News Reader

I prefer to do email suggestion rather than validation - The only validation I have is that it should contain an @. And then use something like http://getmailcheck.org/ to suggest spelling corrections for common domains. We saw a massive reduction in bad emails just by implementing this without having to annoy users with incorrectly implemented validation rules.

> You cannot validate email addresses for shape and form. The sole invariant is that there be at least three characters one of which is @. Everything beyond that is in the hands of the DNS and the domain's MTA. You cannot predict every fashion in which they will behave. You should not try to.

I used to agree with this viewpoint, but now I'm having some doubts.

Suppose I enter the email address "geofft@example.net@example.com". It validates according to your rule. Where does it go?

Suppose, furthermore, that I upgrade my servers and they start parsing it differently. They're allowed to do that, right? Maybe my old MTA sent a confirmation email to example.net, and the new one is now sending emails to a user named "geofft@example.net" at example.com. Haven't I just done something very wrong by allowing a user to trick me into sending emails to an unvalidated address? Isn't this both a violation of the Postel principle ("conservative in what you send to others") and a security hole?

It seems like it would be better for my application to parse the email address and validate what it's doing, and store only unambiguously-parseable addresses.

Or maybe they're not allowed to parse it differently. Maybe there's a single consistent way to parse geofft@example.net@example.com, and every single email application I might use will get it right. What is this esoteric lore that email applications know that my application cannot? If they can parse it, can't I?

>Suppose I enter the email address "geofft@example.net@example.com". It validates according to your rule. Where does it go?

Slight word charge on the rule. "..one and only one of which is @..." with characters within quotations ("") not being counted. Quotations need to be considered because this is a valid email address: [0]

`"very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com`

>Suppose, furthermore, that I upgrade my servers and they start parsing it differently. They're allowed to do that, right? Maybe my old MTA sent a confirmation email to example.net, and the new one is now sending emails to a user named "geofft@example.net" at example.com.

If you upgrade your servers and they parse incorrectly by inserting quotations where there were no quotations entered, then the parsing is bugged. Although the validation was bugged to begin with for allowing two delimiters in an email address.

Furthermore, if anyone uses an email that is so heavily eccentric just because it is "technically valid" I'm sure they don't expect their email to work most of the time.

[0] https://en.wikipedia.org/wiki/Email_address

Aha. Well, now we're approaching something more complex than /@/, aren't we? :)

I will fully agree with the claim that a regex is the wrong way to validity-check an email, and I will easily believe that implementing the check you describe takes 5 kilobytes of regex. But a rule like "Exactly one un-quoted @ sign" or "Exactly one un-quoted @ sign, and the string on the right needs to be a well-formed domain name" or something is pretty simple in normal code.

"Well-formed domain name" is an existing concept: one or more labels separated by dots, each of which contains only ASCII letters, digits, or hyphens, cannot start or end with a hyphen, and cannot be more than 63 characters long, and no more than 253 characters total. Again, not something I'd do with a regex, but a small number of lines of code.

I'm not the original person you were speaking with - sorry for any confusion.

Although you have me curious how you would check with code without using regex.

> It validates according to your rule.

No. Read the rule again.

Did you mean "exactly one of which is @"?

That's not the rule that 'Freak_NL posted, which is why I read your rule as "at least one of which is @".

And, besides, as others have pointed out, "exactly one of which is @" is incorrect. Valid email addresses can have multiple @ characters.

I am not Freak_NL. I am also not interested in participating in the deviancy of people who choose to use email addresses containing quoted strings which themselves contain @s. Anyone who wishes to engage in such self-abuse is entirely free to do so. I don't feel myself constrained to play along.

Well, okay, but you've now stepped away from the goal of allowing all valid email addresses, and are now restricting email addresses that don't fit your personal opinion of what a good email address is, which is at odds with what the actual rules for valid email addresses are.

Your opinion might have a lot of reasons to support it, but it does not seem to be consistent with the position you were advocating. I am interested in not validating email addresses, because of your convincing argument that I should not. And now you want me to validate them.

Where did I claim that as my goal? If somebody just has to be a wiseass, that's fine, but I don't mind making him unhappy, because trying to make him happy along with everybody else will make me very unhappy indeed. If I can keep from making myself unhappy, and keep from making unhappy anyone who doesn't just have to be a wiseass, I'm willing to call it a day.

The Perl regex is also incorrect, since it assumes that comments were stripped beforehand. It also requires you to have backend processing that knows that <a . (kidding) b @ example.com>, <"a.b"@example.com>, and <a.b@example.com> all refer to the same email address. It would help if people knew that you need to look at RFC 821(/2821/5321) to figure out what constitutes a valid email address instead of RFC 822.