View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0015207||phpList 3 application||Admin Management||public||23-12-08 21:41||29-04-10 06:19|
|Target Version||Fixed in Version|
|Summary||0015207: Email validation doesn't seem to work for the local part of an email address|
|Description||A number of forum users reported the 'find users who have an invalid email' option in ver. 2.10.7 and 2.10.8 fails to find invalid emails.|
I ran some tests with 2.10.8 and it looks like validation of the TLD and domain part of an email address is working fine. For instance, when using the 'find users who have an invalid email' (lists/admin/?page=reconcileusers&option=invalidemail) the following addresses were identified as invalid:
firstname.lastname@example.org (invalid TLD)
email@example.com, (invalid TLD)
name@domain..com (invalid domain)
name@-domain.com (invalid domain)
A missing @ is also detected, e.g. name.domain.com
However, validation of the local part of an email address does not seem to be working correctly, since the following addresses were not identified as invalid:
Abc.@example.com (character dot(.) is last in local part)
Abc..firstname.lastname@example.org (character dot(.) is double)
A@b@email@example.com (only one @ is allowed outside quotations marks)
()\;:,<>@example.com (none of the characters before the @ is allowed outside quotation marks)
|Additional Information||Probably related to http://mantis.phplist.com/view.php?id=6782|
|Tags||No tags attached.|
|related to||0006782||resolved||michiel||Importing Invalid E-mails|
|related to||0012866||resolved||michiel||Strict format checking of email and other fields prevents numerous imports, possible for mysql injection attacks|
|related to||0015227||resolved||Actually 2.10.9 - Marking Most Users Invalid !!|
|related to||0013966||new||"Fix emails for users who have an invalid email" (reconcile users) does not seem to work with special characters|
I just realized I ran the above tests on a *v.2.10.5* test installation by mistake, instead of using my 2.10.8 test installation... Sorry about that.
So I did a second test, making sure I was using my v.2.10.8 sandbox this time: *None* of the invalid email addresses were detected.
A look at the code in userlib.php showed the email validation function is_email() has been significantly modified since 2.10.5. It now allows to set different email validation levels in config.php.
The validation level can be set by adding this line in config.php:
Possible values appear to be:
0 No email address validation.
1 [TLD & domain validation. Relaxed or no local part validation]
2 RFC821 email validation without escaping and quoting of local part
3 RFC821 email validation.
Apparently email validation is disabled by default if undefined in config.php.
My preliminary tests indicate all validation levels work fine, i.e. level 1 found all invalid tld's and domains; level 2 and 3 found all 14 invalid email addresses.
I'm happy with the added validation functionality, though it would be useful to have its settings documented somewhere.
I guess the original issue should be reformulated as follows: "Email validation levels setting is missing in the configuration file"
In v2.10.9, a fall back setting has been included in admin/lib.php
If validation level is undefined in config.php, it will now default to validation level 3. So, that seems to have been resolved.
One possible issue remains: email addresses having uppercase characters in the top level domain (e.g. .COM or .Com instead of .com) are apparently considered invalid. I wonder whether that actually is RFC compliant. I'm not sure, since I can't find anything definite on that question.
RFC 821 does not seem to make a distinction between the TLD and the actual domain and just refers to 'the domain part', which is case insensitive if I understand this citation correctly:
"Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
and extension name keywords) are not case sensitive, with the sole
exception in this specification of a mailbox local-part (SMTP
Extensions may explicitly specify case-sensitive elements). That is,
a command verb, an argument value other than a mailbox local-part,
and free form text MAY be encoded in upper case, lower case, or any
mixture of upper and lower case with no impact on its meaning. This
is NOT true of a mailbox local-part."
If this can be confirmed, then I guess the validation function should be modified to accept uppercase characters in TLD's.
Ah yes, one other issue: the EMAIL_ADDRESS_VALIDATION_LEVEL setting is still missing in config.php (v2.10.9).
I suppose it would be useful to add the setting to config.php, and include some comments on its use.
Well, had a quick look at the code of lists/admin/commonlib/lib/userlib.php (v2.10.9):
Line 448 defines valid TLDs in the variable $topLevelDomain
All listed TLDs are lowercase now and should be made case insensitive (either lowercase, uppercase or a mix), if this is confirmed to comply with RFC 821.
|Thanks for the research. These month we are stabilising 2.11 and I will include this as a fix for the next version.|
fix will be in 2.11
I have also added some documentation to http://docs.phplist.com/PhpListEmailValidation and moved 'Experimental Features' to it's own page.