3 ms·

I wonder why they don't provide a mitigation. It shouldn't be impossible to release a simple sanitizeAgainstCVE_2016_10045($email) function as a mitigation that

I wonder why they don't provide a mitigation. It shouldn't be impossible to release a simple sanitizeAgainstCVE_2016_10045($email) function as a mitigation that people could right now plop into their applications until phpmailer gets fixed... or is filter_var($email,FILTER_VALIDATE_EMAIL) good enough?

Piskvorrr 10y ago
For benign e-mail addresses, it is Good Enough: accepts the unusual but valid info%blah+something@info.swiss, punycode (and various other things that people usually toss out with the infamous [a-z]{2,4}), yet throws out the abovementioned monstrosity, even though it technically follows the letter of the RFC. As for "why no mitigation" - even though it abstracts the horror of mail(), a library is a power tool with sharp edges, not a nicely wrapped single-button selfie app. In other words, it already does validation; input sanitization is beyond its scope IMNSHO (this literally means that valid, insane e-mail addresses do exist), and adding that by default would nerf the library. (Also, php_filter is an extension and not installed by default)