Re:PHPMailer Exploit – Remote Code Execution
by x0 on Wednesday December 28, 2016 @06:13AM
(#13269822)
That's how I do it. Check for an @. Anything past that is sendmail's problem.
Re:PHPMailer Exploit – Remote Code Execution
by nkozyra on Wednesday December 28, 2016 @07:21AM
(#13270038)
Even though it false positives some valid emails, I've always felt requiring a @ and a . is a good check for public facing validation.
Re:PHPMailer Exploit – Remote Code Execution
by Piskvorrr on Thursday December 29, 2016 @05:48AM
(#13276669)
Technically 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.
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.