FAQ
Edit report at http://pear.php.net/bugs/bug.php?id=8818&edit=1

ID: 8818
Updated by: alec@alec.pl
Reported By: scottprive at gmail dot com
Summary: Request Option to suppress email address validation
(allow RFC OK fringe cases)
Status: Open
Type: Feature/Change Request
Package: Mail
Operating System: Linux Fedora
Package Version: 1.1.13
PHP Version: 5.1.4
Roadmap Versions:
New Comment:

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.


Previous Comments:
------------------------------------------------------------------------

[2006-12-07 05:35:05] natalie dot kather at northclick dot de

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.

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

[2006-10-24 17:01:40] scottprive at gmail dot com

set proper version #

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

[2006-10-05 10:59:14] 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-05 10:54:47] 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-09-29 18:00:19] scottprive at gmail dot com

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] =>
)

)
...

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

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppear-bugs @
categoriesphp
postedJan 17, '11 at 9:56a
activeJan 17, '11 at 9:56a
posts1
users1
websitepear.php.net

1 user in discussion

Alec: 1 post

People

Translate

site design / logo © 2022 Grokbase