Description: ------------ The email validation in the Validate PEAR package doesn't work correctly. This is because the '&' symbol though valid in emails such as: "Joe & Mac"@example.com isn't accepted by the email parser. This is caused by the simple fact that the __stringToUtf7() routine doesn't recognize any string with a '&' sign as valid UTF7. This is despite the fact that the '&' character is valid UTF7 as defined by RFC 2152 as I read it: http://www.faqs.org/rfcs/rfc2152.html In the __stringToUtf7() routine the following substitution is made for the '&' character: elseif ($char == '&') { $return .= '&-'; } Thus when the UTF7 "return" string is returned it doesn't match the original string passed to the UTF7 routine and all '&' characters are replaced by '&-'. Its not clear why this substitution is made at all. Especially since this routine is only used from within the email parser. In any case the result is that the following test in __emailRFC822() fails with emails like "Joe & Mac"@example.com: if (Validate::__stringToUtf7($email) != $email) { return false; } Leading to the email parser returning that emails like "Joe & Mac"@example.com are invalid email addresses when in fact they are valid. Test script: --------------- Script 1: (fails when should succeed) $Email = '"Joe & Mac"@example.com'; $Options = 0; assert( Validate::__emailRFC822( $Email, $Options ) ); Script 2: (fails when should succeed) $string = '&'; assert( __stringToUtf7($string) == $string ); Expected result: ---------------- Scripts fail when they should succeed Actual result: -------------- Scripts faile.

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.

I looked at the CVS source at: http://cvs.php.net/viewvc.cgi/pear/Validate/Validate.php?revision=1.126&content-type=text%2Fplain&pathrev=1.126 I'm still fairly new to PEAR. But, assuming that is the right place to look it seems that the only change was to remove the __stringToUtf7() routine call from the RFC2152 email validation. Was that the only change? Perhaps I'm misinformed or looking in the wrong place in the CVS source and there were other changes I am not aware of? I would have to guess that routine call and the UTF7 check is necessary since if an address contained non-UTF7 characters I doubt it would be a legal email address. Also, that routine is considered private and if removed from the RFC2152 email validation then it is used nowhere in the validate module nor any other module making it unused overall and just dead code. Again I think I must be misinformed as to what the change is. Thanks. :)

You looked at the absolutely right place :) The UTF7 encoder I wrote is for encoding IMAP mailboxes, but not securing strings (email addresses in this case), so I removed the call for now, we need to write another UTF7 encoder.