3 ms·
>I know it is tough to validate all addresses according to RFC Understatement of the year! If you were to try and actually validate according to the RFC, chan
by neotek 10y ago
>I know it is tough to validate all addresses according to RFC
Understatement of the year!
If you were to try and actually validate according to the RFC, chances are you'll introduce new vectors of attack in your code simply because of the complexity of what you're trying to achieve.
Honestly, the email address RFC is a litany of insane choices and kludged-together standards to account for the wild west free-for-all that existed before the modern internet emerged, and most of it has no bearing on the reality of how people use and create email addresses today. Better to just check if the address supplied has an @ in it somewhere and be done with it.
- x0 10y agoThat's how I do it. Check for an @. Anything past that is sendmail's problem.
- nkozyra 10y agoEven though it false positives some valid emails, I've always felt requiring a @ and a . is a good check for public facing validation.
- Piskvorrr 10y agoTechnically valid e-mail addresses - but nonsensical ones. I haven't seen an e-mail without a domain cross a network in decades ("cross a network" excepts "user@localhost", and I'm not old enough to have seen any IP-adressed mails ;)). So yes, I believe that in 2016, a match on ^[^@]+@([^.@]+\.)+[^.@]+\.?$ does not have any actual false negatives, although allowing false positives. That's not entirely helpful in this CVE, though.