0006782: Importing Invalid E-mails

(0014993)
michiel (administrator)
01-07-06 05:18

yes, that will be useful to have a closer look at

(0023103)
donkiely (reporter)
01-02-07 04:44

I've found a number of references that say that ' is a valid character:

http://en.wikipedia.org/wiki/E-mail_address [^]
http://tools.ietf.org/html/rfc2822#section-3.2.4 [^]

The Wikipaedia entry explicitly says it, and the RFC seems to back it up, unless I'm misinterpreting it.

(0028144)
msauer (reporter)
18-06-07 16:03

There is an error in the pattern for validation.
^([\&\'-_.[:alnum:]]+@)((...
should be
^([\&\'\-_.[:alnum:]]+@)((...

The dash is not escaped so all chars from ' to _ are valid.
Escaping the dash solves double @ issue and maybe some others.

(0028167)
michiel (administrator)
19-06-07 13:08

ah, nice find. Thanks!

(0028421)
michiel (administrator)
23-06-07 00:41

Hmm, that's not correct though. I just tried to validate an email with an - in it, and it failed when you escape the - in the regex.

(0028435)
msauer (reporter)
25-06-07 06:44

Yes, I had the same problem. So I changed the complete pattern to
^[-!#$%&'*+/0-9=?A-Z^_a-z{|}~](\.?[-!#$%&'*+/0-9=?A-Z^_a-z{|}~])*@[a-zA-Z](-?[a-zA-Z0-9])*(\.[a-zA-Z](-?[a-zA-Z0-9])*)+$
from http://www.email-unlimited.com/stuff/email_address_validator.htm [^]
I made a little change in the pattern: @[a-zA-Z] to @[a-zA-Z0-9] and used preg_match() instead of ereg().

The function is_email() now looks like this:
-----
function is_email($email) {
  if (isset($GLOBALS['config']) && isset($GLOBALS["config"]["dont_require_validemail"]) && $GLOBALS["config"]["dont_require_validemail"])
    return 1;

  $email = trim($email);

  # hmm, it seems people are starting to have emails with & and ' or ` chars in the name
  #'

$pattern =
"/^[-!#$%&'*+\/0-9=?A-Z^_a-z{|}~](\.?[-!#$%&'*+\/0-9=?A-Z^_a-z{|}~])*@[a-zA-Z0-9](-?[a-zA-Z0-9])*(\.[a-zA-Z](-?[a-zA-Z0-9])*)+$/";

  if(preg_match($pattern, $email))
    return(1);
  else
    return(0);
}
-----

That works fine for me.

(0028933)
bas (developer)
05-07-07 14:45

In PHPlist function is_email in userlib has been updated to support full RFC standard. new global constant EMAIL_ADDRESS_VALIDATION_LEVEL is set to define this.

(0030124)
chrschaffer (reporter)
07-08-07 08:56

Hi there,
good to hear that this issue is being resolved in 2.11.4. When is 2.11.x going to be stable officially?
Thanks,
Chris

(0030376)
michiel (administrator)
10-08-07 18:22

once our office has heating and some desks

(0031071)
bas (developer)
27-08-07 13:54

There are reasons to accept non emails. Some users use this field as a username and fax their users for instance. So checking should be optional.

Since the import functionality will be redesigned in the next version (2.11) we will not fix this issue now. In defining the requirements for the redesign we will certainly consider your remarks.

Notes
(0014993) michiel (administrator) 01-07-06 05:18	yes, that will be useful to have a closer look at

(0023103) donkiely (reporter) 01-02-07 04:44	I've found a number of references that say that ' is a valid character: http://en.wikipedia.org/wiki/E-mail_address [^] http://tools.ietf.org/html/rfc2822#section-3.2.4 [^] The Wikipaedia entry explicitly says it, and the RFC seems to back it up, unless I'm misinterpreting it.

(0028144) msauer (reporter) 18-06-07 16:03	There is an error in the pattern for validation. ^([\&\'-_.[:alnum:]]+@)((... should be ^([\&\'\-_.[:alnum:]]+@)((... The dash is not escaped so all chars from ' to _ are valid. Escaping the dash solves double @ issue and maybe some others.

(0028167) michiel (administrator) 19-06-07 13:08	ah, nice find. Thanks!

(0028421) michiel (administrator) 23-06-07 00:41	Hmm, that's not correct though. I just tried to validate an email with an - in it, and it failed when you escape the - in the regex.

(0028435) msauer (reporter) 25-06-07 06:44	Yes, I had the same problem. So I changed the complete pattern to ^[-!#$%&'+/0-9=?A-Z^_a-z{\|}~](\.?[-!#$%&'+/0-9=?A-Z^_a-z{\|}~])@[a-zA-Z](-?[a-zA-Z0-9])(\.[a-zA-Z](-?[a-zA-Z0-9]))+$ from http://www.email-unlimited.com/stuff/email_address_validator.htm [^] I made a little change in the pattern: @[a-zA-Z] to @[a-zA-Z0-9] and used preg_match() instead of ereg(). The function is_email() now looks like this: ----- function is_email($email) { if (isset($GLOBALS['config']) && isset($GLOBALS["config"]["dont_require_validemail"]) && $GLOBALS["config"]["dont_require_validemail"]) return 1; $email = trim($email); # hmm, it seems people are starting to have emails with & and ' or ` chars in the name #' $pattern = "/^[-!#$%&'+\/0-9=?A-Z^_a-z{\|}~](\.?[-!#$%&'+\/0-9=?A-Z^_a-z{\|}~])@[a-zA-Z0-9](-?[a-zA-Z0-9])(\.[a-zA-Z](-?[a-zA-Z0-9]))+$/"; if(preg_match($pattern, $email)) return(1); else return(0); } ----- That works fine for me.

(0028933) bas (developer) 05-07-07 14:45	In PHPlist function is_email in userlib has been updated to support full RFC standard. new global constant EMAIL_ADDRESS_VALIDATION_LEVEL is set to define this.

(0030124) chrschaffer (reporter) 07-08-07 08:56	Hi there, good to hear that this issue is being resolved in 2.11.4. When is 2.11.x going to be stable officially? Thanks, Chris

(0030376) michiel (administrator) 10-08-07 18:22	once our office has heating and some desks

(0031071) bas (developer) 27-08-07 13:54	There are reasons to accept non emails. Some users use this field as a username and fax their users for instance. So checking should be optional. Since the import functionality will be redesigned in the next version (2.11) we will not fix this issue now. In defining the requirements for the redesign we will certainly consider your remarks.