go to bug id or search bugs for
When trying to validate an e-mail address using FILTER_VALIDATE_EMAIL will result in several problems with correct mail addresses. So far I could find the following compliant addresses not validating:
Generally PHP should at comply with RFC 822 when validating mail addresses, otherwise the filter function is useless.
Add a Patch
Add a Pull Request
The code does actually document that comments aren't handled, but that never made it to the docs. I'll fix that.
I don't think this is worth fixing (the validation code is terrifying enough as it is, and, seriously, comments in e-mail addresses?), but I'll leave this open in case someone can provide a clean PR.
Automatic comment from SVN on behalf of aharvey
Log: Expand on what FILTER_VALIDATE_EMAIL really validates.
See also bug #69140 (FILTER_VALIDATE_EMAIL not RFC 822 compliant).
The docs are still not correct. The PHP validation is just wrong in more ways than just comments. e.g. the domain part could be a hostname without a dot, but this always comes back as false. This has real applications, e.g. under Linux when sending to [user]@localhost
There is a reason frameworks don't use this built-in function but instead resort to their own validation for e-mails. So this function should either be clearly marked as non-RFC-compatible or just work as one would expect it to work. Sorry, but not fixing this because it's hard to implement is just a lame excuse. Implement it or leave it out, but don't implement some half-working frankenvalidation.
I did a bit of fixing and this could be a patch, strict to RFC 822
RFC 822 - is obsolete in 2001 by 2822, 5322
RFC 2822 - is obsolete in 2008 by 5322,5321 (both of those also have conflicts)
> The PHP validation is just wrong in more ways than just
> comments. e.g. the domain part could be a hostname without a
> dot, but this always comes back as false.
This is a deliberate decision to avoid issues with RFC 5321, so
simply changing the behavior would cause issues. Introducing a new
flag appears to be the most reasonable solution, so I'm changing
to feature request, leaving the documentation part to bug #66553.
Related To: Bug #66553
I'm sorry, but did you seriously just change the whole topic because you can't differentiate between the RFCs for emails and their address format and a transport protocol for them?
The original bug clearly stated that there are different standards-compliant email addresses that won't work with PHPs filter_var, not only one. I'm not sure why PHP developers are this, but out in the real world, not being standards-compliant is a bug.
I understand there is use case for user@localhost. However, accepting user@localhost (or user@hostnameonly) is problematic for most applications.
Therefore, there should be additional flag for it. Problems is all flags, i.e. flag is bit flag, is used already. We can reuse some bits, though.
IMHO, current filter module's validation feature is incomplete and unusable. Instead of adding specific rare usage, it's better to have generic and extensible validator such as