|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #69140 FILTER_VALIDATE_EMAIL should accept user@localhost
Submitted: 2015-02-27 17:02 UTC Modified: 2016-11-24 07:43 UTC
Avg. Score:4.4 ± 0.8
Reproduced:5 of 5 (100.0%)
Same Version:3 (60.0%)
Same OS:3 (60.0%)
From: info at linux-web-development dot de Assigned:
Status: Open Package: Filter related
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
8 + 11 = ?
Subscribe to this entry?

 [2015-02-27 17:02 UTC] info at linux-web-development dot de
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.

Test script:
var_dump(filter_var('foo@example', FILTER_VALIDATE_EMAIL));

Expected result:
string(11) "foo@example"

Actual result:


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2015-02-27 20:46 UTC]
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.
 [2015-02-27 20:50 UTC]
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).
 [2015-03-01 18:18 UTC] info at linux-web-development dot de
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.
 [2015-03-02 00:16 UTC] ppaisndud at gmail dot com
I did a bit of fixing and this could be a patch, strict to RFC 822

Some Issuses

RFC 822 - is obsolete in 2001 by 2822, 5322
RFC 2822 - is obsolete in 2008 by 5322,5321 (both of those also have conflicts)
 [2016-11-21 17:02 UTC]
-Summary: FILTER_VALIDATE_EMAIL not RFC 822 compliant +Summary: FILTER_VALIDATE_EMAIL does not accept user@localhost -Type: Bug +Type: Feature/Change Request
 [2016-11-21 17:02 UTC]
> 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[1], 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.

[1] <>
 [2016-11-21 17:02 UTC]
-Summary: FILTER_VALIDATE_EMAIL does not accept user@localhost +Summary: FILTER_VALIDATE_EMAIL should accept user@localhost
 [2016-11-22 12:12 UTC] bugs-php-net at unikorn dot me
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.
 [2016-11-24 07:43 UTC]
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
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Jul 15 05:01:29 2024 UTC