Opened 12 years ago
Last modified 5 years ago
#23243 new defect (bug)
wp_mail() not working with "Name <email>" format in buggy PHP versions on Windows
Reported by: | bbosh | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | minor | Version: | 3.5 |
Component: | Keywords: | needs-patch | |
Focuses: | Cc: |
Description
As a result of ticket #17305, wp_mail() accepts the $to parameter in the format "Name <email@…>".
There exists a PHP bug in versions below 5.2.11 and in 5.3, on Windows. This bug occurs when addresses are passed to the PHP mail() function in the "Name <email>" format and prevents e-mails from being sent. I believe this bug in fixed in 5.3.1 and above. (see https://bugs.php.net/bug.php?id=28038)
I don't believe this affects any core functionality, but may affect some plugins which pass $to in the above format.
I tested in PHP 5.2.4 on Windows with the following code:
wp_mail("email@ext.com", "Test", "Test"); wp_mail("Name <email@ext.com>", "Test 2", "Test 2");
The first email is received; the second isn't. When removing error suppression from the mail() calls in class-phpmailer.php, the following warning is outputted:
Warning: mail() [function.mail]: SMTP server response: 501 <Name <email@…>>: "@" or "." expected after "Name" in C:\xampplite\htdocs\wp-includes\class-phpmailer.php on line 771
Change History (5)
#3
@
12 years ago
#23291 no longer triggers an entry in the PHP error log; instead it returns a WP_Error.
#5
@
8 years ago
Not to suggest that things shouldn't be resolved to handle things correctly, but if this is a bug in PHP below 5.2.11 and in 5.3 on Windows, how necessary is a patch/fix?
WP is now recommended to use PHP 5.6, and even though WP can run on these lower versions, they are technically beyond EOL (I realize that was not the case when this ticket was opened, but it is now).
#23291 pushes any exceptions that PHPMailer throws to PHP's error_log. Since the bug was fixed in PHP two years ago, isn't triggered by core and only happens on Windows servers, then maybe the extra logging is enough?
If an actual workaround is desired, I would think it'd be more appropriate to do that upstream, rather than in WP.