Description: ------------ Requestion an option to completely suppress email address validation. The validation has its uses, but gets in the way of server testing. Two use cases: 1) Server testing (spam relay tests, destructive string tests, etc) 2) Current validation is simple and restrictive, blocking special characters even if they are used in a RFC 3696 valid context: `domain literals' "someone@example.com" possibly others. I have attempted to disable the raising of RFC822.php errors in Mail.php but have failed (I have begun studying the OO code, but my background is 'function-based' PHP). Test script: --------------- <? require 'Mail.php'; $to = "\"user name@example.com\""; #rfc 3696 valid $headers['from'] = 'do-not-reply@example.com'; $headers['subject'] = "email testing "; $headers['to'] = $to; $headers['Date'] = date('r'); $params = array( "host" => 'mail.example.com', 'port' => 25, 'localhost' => 'test.example.com', 'timeout' => 240, 'debug' => TRUE, 'persist' => FALSE, ); $body = " This is a test, which fails on Mail address validtion. "; $message =& Mail::factory('smtp',$params); $emailresult = $message->send($to, $headers, $body); print "\n RESULT CODE looks like: $emailresult\n"; print "\n RESULT OBJECT looks like:"; print_r($emailresult); ?> Expected result: ---------------- The contents of $to become (IN-cluding quotes): "user name@example.com" Personally I don't advise or support users with such gray area usernames. The purpose in feeding the RCPT TO with unusual data is to test the target mailserver to see if it is an "open relay". While the simplest test is to use mailbox@not-your-domain.com, there are another 15-20 testcases using quotes and escaping in an attempt to trick the SMTP server in accepting the email. Mail.php seems very suited (and more) for such an exercise. Actual result: -------------- RESULT OBJECT looks like:PEAR_Error Object ( [error_message_prefix] => [mode] => 1 [level] => 1024 [code] => [message] => Validation failed for: "user name@example.com" [userinfo] => [backtrace] => Array ( [0] => Array ( [file] => /usr/share/pear/PEAR.php [line] => 566 [function] => PEAR_Error [class] => PEAR_Error [object] => PEAR_Error Object *RECURSION* [type] => -> [args] => Array ( [0] => Validation failed for: "user name@example.com" [1] => [2] => 1 [3] => 1024 [4] => ) ) [1] => Array ( [file] => /usr/share/pear/Mail/RFC822.php [line] => 198 [function] => raiseError [class] => PEAR [object] => Mail_RFC822 Object ( [address] => [default_domain] => localhost [nestGroups] => [validate] => 1 [addresses] => Array ( [0] => Array ( [address] => "user name@example.com" [group] => ) ) ...

I should note that while the validation is technically inconsistent -- arguably a (non-critical) "bug", this bug report is not trying to be picky or argue for perfection. What I am saying here is, a workaround would be most excellent. I understand there's probably a way to disable this by creating an extension class that omits the validation. It gets in the way. I have already tried to suppress this in an extension class, and I attribute my failure to being new to PHP object coding. An example class that suppresses the email checking would be helpful both from the problem standpoint of these fringe-case emails (that ARE RFC valid), and beneficial as a learning tool since I have already tried to cancel the email error check myself. Cheers.

My report was missing the package version # which was 'Mail.php,v 1.17 2006/09/15 03:41:18 jon'

set proper version #

The validation function is indeed very unreliable. I've had lots of trouble because the sender "ABC e.V. <valid_email>" was erroneously not permitted - but "<same_valid_email>" was ok. I neither understand the sense of checking the sender's name nor why a harmless string consisting of letters and two dots is getting blocked. Anyway, I need to use another email class.

I don't say we don't need such feature, just want to add some comments: @Scott: RFC3696 is not good reference for e-mail addres validation. Also "name name@example.com" is not proper e-mail address specification. @Natalie: "ABC e.V. <valid_email>" is permitted in current version.