[drupal-devel] [bug] other valid emails fail too

[killes]

Issue status update for http://drupal.org/node/21067

 Project:      Drupal
 Version:      4.6.0
 Component:    base system
 Category:     bug reports
 Priority:     critical
 Assigned to:  CdnStrangequark
 Reported by:  jwells
 Updated by:   killes at www.drop.org
-Status:       active
+Status:       patch
 Attachment:   http://drupal.org/files/issues/valid_email.patch (1.31 KB)

Our intrepid Debian developer has cooked up a patch. It is based on RFC
2822 but it needs testing.




killes at www.drop.org



Previous comments:
------------------------------------------------------------------------

April 22, 2005 - 07:00 : jwells

When attemping to use a sub-domain email address for a new account, it
won't pass the syntax test. We know that its really the base - but I'm
sure a lot of end uers don't know.


newaccount at research.drupal.org - this type of address will fail, though
it is actually legal




------------------------------------------------------------------------

May 10, 2005 - 17:00 : CdnStrangequark

Not just sub-domain emails. If you have an email address of the form:
"first.last at somewhere.com" it will also fail even though this is
perfectly valid.




------------------------------------------------------------------------

May 10, 2005 - 18:30 : CdnStrangequark

After attempting to enter more emails on one of my new sites, I also
discovered that the validation fails in yet more perfectly valid cases.
For example: "myemail at somewhere.xx" where xx is the country domain code.
(like .ca, or .us).  Not all country codes are accepted.


Here is a replacement I made for the code in common.inc:
*valid_email_address($mail)* that works just great:


$user = "[-a-z0-9!#$%&'*+/=?^_`{|}~]";
$domain = "([a-z]([-a-z0-9]*[a-z0-9]+)?)";
$regex = "^$user+(\.$user+)*@($domain{1,63}\.)+$domain{2,63}$";
//Return a 1 or 0 to mimic results of preg_match
if (eregi($regex, $mail)) {
  return 1;
} else {
  return 0;
}


The only thing this doesn't do is allow for "user at localhost" but does
anyone really do that anyway? The code could be modified to do it
through an alternate check on $domain though.


PS: I left this post's status as active and unassigned cause I'm kinda
new here and don't know the process for submitting patches and bug
fixes. Hope someone can put this code in the core though cause I'm sure
we're not the only ones who have run into the problem.