Edit report at http://bugs.php.net/bug.php?id=50431&edit=1
ID: 50431
Comment by: vaughan dot montgomery at gmail dot com
Reported by: troy at scriptedmotion dot com
Summary: Using filter_var to filter an email address returns
incorrect result
Status: Bogus
Type: Bug
Package: Filter related
Operating System: Ubuntu
PHP Version: 5.2.11
Block user comment: N
Private report: N
New Comment:
that's true. but in the real world! we aren't dealing with local issues.
yes
t...@localhost is valid for local, but it's no good on a remote server.
i want
my users to have to enter their address as [email protected] or .co.uk or
whatever,
like everyone else out there who wants to use this filter for validating
user
email addresses. why is this so difficult to get through? what is so
wrong with
changing it or adding a filter flag to the filter for top level domains
etc?
then we have the best of both worlds.
if you won't do something about it, then this filter is pretty much
useless to
many people, i would have preferred to use it, but will have to stick to
using
the cumbersome regex method instead.
Previous Comments:
------------------------------------------------------------------------
[2010-12-20 19:56:52] [email protected]
Even if he enters [email protected] that still doesn't tell you if the email
will get
through to him. You are in the same position. The filter simply
validates the
string as a valid-looking email address. Whether or not this is the
actual user's
email address is way beyond the scope of this function. You can take it
further
and do an MX lookup on it, but that just means the host exists, it
doesn't mean
that user has an account on that box. The only way to know is to
actually deliver
an email to the address and see if the user gets it.
------------------------------------------------------------------------
[2010-12-20 02:02:29] vaughan dot montgomery at gmail dot com
ok you say that's a valid email.. but in a working user environment,
using this
filter to VALIDATE an email address is unworkable.
when users register on my site, i want to validate their email address.
if the user enters t...@test, it returns as valid. but how on earth does
my
server know that the users email address .com/.net/.co.uk/.biz etc. so
when it
tries to send the user an email to validate his email address in order
to
register on my site, he never receives the email because the server
doesn't know
where to send it.
this means i can't use this filter for its intended purpose of
validating an
email address.
back to using regex and the old PHP 4 methods.
either make the filter return as invalid, or add an extra parameter to
tell it
to validate with a top level domain.
ie. filter_var('t...@test', FILTER_VALIDATE_EMAIL, FILTER_FLAG_TOP_LEVEL)
if FILTER_FLAG_TOP_LEVEL is set, then 't...@test' returns invalid, if
not, then
return valid.
problem solved, and i'm sure many users would apreciate it.
------------------------------------------------------------------------
[2010-08-20 16:53:27] michael at squiloople dot com
The standards are actually RFC 5321 and 5322, and according to RFC 5321
(which
goes into more specific detail over domain names in email addresses),
"in the case
of a top-level domain used by itself in an email address, a single
string is used
without any dots."
------------------------------------------------------------------------
[2010-05-08 02:32:01] office at lucian0308 dot com
i see a deference
the standard is http://tools.ietf.org/html/rfc2822
this function respect the standard?
because PEAR
http://pear.php.net/manual/en/package.validate.validate.email.php
say that use RFC2822 and it works corectly
without dot and level domain shoud be a false email.
------------------------------------------------------------------------
[2009-12-09 19:02:01] [email protected]
That's a valid email address. Email addresses don't need a tld. Try
emailing r...@localhost, for example. Any locally defined host can
potentially receive email.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=50431
--
Edit this bug report at http://bugs.php.net/bug.php?id=50431&edit=1
