Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 2.0.0

Request #8818 Request Option to suppress email address validation (allow RFC OK fringe cases)
Submitted: 2006-09-29 22:00 UTC
From: scottprive at gmail dot com Assigned:
Status: Open Package: Mail (version 1.1.13)
PHP Version: 5.1.4 OS: Linux Fedora
Roadmaps: (Not assigned)    
Subscription  
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes. If this is not your bug, you can add a comment by following this link. If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
2011-01-17 15:58 UTC
Package:
Bug Type:
Summary:
From: scottprive at gmail dot com
New email:
PHP Version: Package Version: OS:

 

 [2006-09-29 22:00 UTC] scottprive at gmail dot com (Scott Prive)
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] => ) ) ...

Comments

 [2006-10-05 14:54 UTC] scottprive at gmail dot com
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.
 [2006-10-05 14:59 UTC] scottprive at gmail dot com
My report was missing the package version # which was 'Mail.php,v 1.17 2006/09/15 03:41:18 jon'
 [2006-10-24 21:01 UTC] scottprive at gmail dot com
set proper version #
 [2006-12-07 10:35 UTC] natalie dot kather at northclick dot de (Natalie Kather)
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.
 [2011-01-17 15:58 UTC] alec (Aleksander Machniak)
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.