php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #49576 Filter var for validating email is not validating emails correctly
Submitted: 2009-09-17 08:53 UTC Modified: 2012-08-16 18:01 UTC
Votes:6
Avg. Score:4.5 ± 0.8
Reproduced:5 of 5 (100.0%)
Same Version:4 (80.0%)
Same OS:2 (40.0%)
From: mparkin at de-facto dot com Assigned: rasmus
Status: Wont fix Package: *General Issues
PHP Version: 5.* OS: *
Private report: No CVE-ID:
Have you experienced this issue?
Rate the importance of this bug to you:

 [2009-09-17 08:53 UTC] mparkin at de-facto dot com
Description:
------------
Filter_Var does not validate emails accurately enough, and false positives are made. The regex needs improving - the regex we are using in kohanaphp framework (with preg_match) is more accurate.

some more reading could be done here:

http://fightingforalostcause.net/misc/2006/compare-email-regex.php

Reproduce code:
---------------
http://codepad.org/UIrhI5ep

Expected result:
----------------
All emails in $valid are valid, all emails in $invalid are invalid.

A far more accurate regex can be found here:

http://dev.kohanaphp.com/projects/kohana2/repository/entry/trunk/system/helpers/valid.php#L20

Actual result:
--------------
There are false positives and non failures.



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-04-02 07:40 UTC] rasmus@php.net
-Status: Open +Status: Assigned -Package: Feature/Change Request +Package: *General Issues -Assigned To: +Assigned To: rasmus
 [2010-04-02 07:40 UTC] rasmus@php.net
Finally having a look at this.  Some of your cases are actually incorrect 
according to RFC3696/RFC5322

For example.  IPInsteadOfDomain@127.0.0.1 is not a valid email address according 
to the RFC.  IPs in an email address must be in square brackets.  So it should 
be IPInsteadOfDomain@[127.0.0.1] for that one to be valid.  This is valid under 
both RFC822 and RFC2822, but RFC3696 and RFC5322 updates those RFCs.  And you 
can't have a port in it, so IPAndPort@127.0.0.1:25 is invalid as well, even if 
you added the square brackets.  Also we do not validate domains, so your 2 
examples of invalid TLDs are not relevant.

I'll have an update of the baked in regex soon, but it sounds like you need to 
update the Kohana one as well.
 [2010-04-02 19:56 UTC] rasmus@php.net
Automatic comment from SVN on behalf of rasmus
Revision: http://svn.php.net/viewvc/?view=revision&revision=297350
Log: Update the FILTER_VALIDATE_EMAIL filter to fix bug #49576
 [2010-04-02 19:57 UTC] rasmus@php.net
-Status: Assigned +Status: Closed
 [2010-04-02 19:57 UTC] rasmus@php.net
A much better RFC-compliant regex has been committed now.
 [2010-08-05 16:41 UTC] alexsander dot rosa at gmail dot com
The format "username@box" for local networks IS allowed when the mail() method is used. I quote RFC 5321: "local aliases MUST NOT appear in any SMTP transaction." They say NOTHING about mail() method in the RFC.
 [2010-08-14 20:48 UTC] kalle@php.net
-Status: Closed +Status: Re-Opened
 [2010-08-14 20:48 UTC] kalle@php.net
Re-opened, the last comment seems quite valid to me, don't you think so Rasmus?
 [2010-08-14 21:10 UTC] grangeway at hotmail dot com
Additionally:

1) at the moment, I believe the current regex does not allow fred@com as an 
email address. Albeit, it's going back almost 10 years now - I'm pretty sure  I 
received an email from someone @tld, complaining that a regex  did not allow 
their valid email address to sign up.

2) The issue the user hit is the phpmailer class contains the following code to 
validate email addresses against FILTER_VALIDATE_EMAIL regardless of whether 
SMTP or mail() is the sending method.

550  public static function ValidateAddress($address) {
551    if (function_exists('filter_var')) { //Introduced in PHP 5.2
...
else 
 regex
 [2010-08-15 02:09 UTC] pajoye@php.net
-Status: Re-Opened +Status: Feedback -PHP Version: 5.*, 6 +PHP Version: 5.*
 [2010-08-15 02:09 UTC] pajoye@php.net
Have you tried with 5.2.14 or 5.3.3?
 [2010-08-17 21:34 UTC] michael at squiloople dot com
You might find this useful, taken directly from my article on E-mail address 
validation, in deciding whether or not to allow single-label domain names:

"There is some confusion over whether or not single-label domain names are 
allowed — michael@squiloople, for example. People often cite the following 
section in RFC 5321 to argue that they are not allowed:

"'Only resolvable, fully-qualified domain names (FQDNs) are permitted when 
domain names are used in SMTP. In other words, names that can be resolved to MX 
RRs or address (i.e., A or AAAA) RRs (as discussed in Section 5) are permitted, 
as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs. 
Local nicknames or unqualified names MUST NOT be used.'

"The implicit premise here is that TLD-only domain names cannot be resolved to 
MX RRs. This is simply untrue: both checkdnsrr('ai', 'MX') and getmxrr('ai', 
$array) return true, showing that single-label domain names can, and do, resolve 
to MX RRs. Additionally, http://www.to/ is a valid, and active, domain. 
Therefore, michael@squiloople is valid (although in this example, ‘squiloople’ 
is not a TLD).

"And as an extra note, here’s another excerpt from RFC 5321:

"'In the case of a top-level domain used by itself in an email address, a single 
string is used without any dots.'"
 [2012-08-16 16:48 UTC] damien dot regad at merckgroup dot com
Going back to what grangeway posted 2 years ago, the filter still does not accept single-domain addresses:

php > var_export( filter_var( 'user@localhost', FILTER_VALIDATE_EMAIL ) );
false

I tested with PHP 5.3.10-1ubuntu3.2 with Suhosin-Patch (cli) on Ubuntu 12.04

However, if I understand well the ABNF[1] in the RFC specification [2], this should in fact be allowed (see sections 3.4.1 and 3.2.3 for details):

addr-spec       =   local-part "@" domain
domain          =   dot-atom / domain-literal / obs-domain
dot-atom        =   [CFWS] dot-atom-text [CFWS]
dot-atom-text   =   1*atext *("." 1*atext)

The last bit (dot-atom-text) says that there must be 1 or more chars followed by zero or more groups of ("." followed by 1 or more chars).

It would be nice to have this fixed. Thanks in advance !

[1] http://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_Form
[2] http://tools.ietf.org/html/rfc5322
 [2012-08-16 18:01 UTC] rasmus@php.net
-Status: Feedback +Status: Wont fix
 [2012-08-16 18:01 UTC] rasmus@php.net
I am not disagreeing that local domains are invalid per the RFC, but I do think 
that in most cases Web apps probably don't have a use for these cases since they 
don't resolve outside of the local environment. I suppose some Intranet web apps 
would find this useful, but the bulk of Internet apps would need to add a second 
check to make sure that it wasn't a non external SMTP-able address that 
validated. I would suggest that the few cases where you do want local single-
domain addresses to validate you add a simple check in front of filter_var. They 
are easy to check for.
 [2012-08-16 19:03 UTC] levim@php.net
Honestly, why can't we have an option to FILTER_VALIDATE_EMAIL to not require a 
TLD?  I do write intranet applications and it would be useful. Adding an option 
does not break BC at all.
 [2012-08-17 07:09 UTC] damien dot regad at merckgroup dot com
@rasmus, Thanks for your response.

> I suppose some Intranet web apps would find this useful

That's my point exactly.

> I would suggest that the few cases where you do want local 
> single-domain addresses to validate you add a simple check 
> in front of filter_var. 

Not an option here, as we rely on PHPMailer for our mail sending which only uses filter_var() and what you suggest requires a code change in the upstream library.

I understand your point about "SMTP-able address", but there are cases where this restriction does not apply (e.g. sendmail).

@levin's suggestion sounds like a good approach to me.
 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Thu Apr 24 19:01:53 2014 UTC