View Issue Details

IDProjectCategoryView StatusLast Update
0015207phpList 3 applicationAdmin Managementpublic29-04-10 06:19
Status resolvedResolutionfixed 
Product Version2.10.8 
Target VersionFixed in Version 
Summary0015207: Email validation doesn't seem to work for the local part of an email address
DescriptionA 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:

name@domain.bbb (invalid TLD), (invalid TLD) (invalid domain) (invalid domain)

A missing @ is also detected, e.g.

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: (character dot(.) is last in local part) (character dot(.) is double) (only one @ is allowed outside quotations marks)
()[]\;:,<> (none of the characters before the @ is allowed outside quotation marks)
Additional InformationProbably related to
TagsNo tags attached.


related to 0006782 resolvedmichiel Importing Invalid E-mails 
related to 0012866 resolvedmichiel Strict format checking of email and other fields prevents numerous imports, possible for mysql injection attacks 
related to 0015227 resolveduser1822 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 



24-12-08 03:25

manager   ~0050273

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"


05-02-09 17:05

manager   ~0050372

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.


05-02-09 17:38

manager   ~0050374

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.


05-02-09 20:28

manager   ~0050375

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.


09-02-09 11:43


Thanks for the research. These month we are stabilising 2.11 and I will include this as a fix for the next version.


09-03-09 13:54


fix will be in 2.11
I have also added some documentation to and moved 'Experimental Features' to it's own page.