Make WordPress Core

Opened 16 years ago

Closed 16 years ago

Last modified 16 years ago

#5869 closed defect (bug) (invalid)

Yet another email problem with Sender line

Reported by: nberardi's profile nberardi Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.3.3
Component: General Keywords:
Focuses: Cc:


This is the e-mail that I sent to GoDaddy after troubleshooting for 2 weeks with them regarding my e-mails not reaching my inbox when sent from WordPress. I upgraded 2.3.3 right when it came out, but it just occurred to me that the two dates of my e-mails not getting sent and my upgrade to 2.3.3 were on the same day. I tracked it down to this one line highlighted below.

Hi guys,

I found the problem. It is one line of code that looks pretty inconsequential in the WordPress source. It is part of the WordPress 2.3.3 emergency release. It doesn't even make sense why this would stop my e-mail from being sent correctly on GoDaddy. But this is probably something for you developers to look at:

WordPress 2.3.2 (/wp-includes/pluggable.php:line 227)

// Set the from name and email
    $phpmailer->From = apply_filters( 'wp_mail_from', $from_email );
    $phpmailer->Sender = apply_filters( 'wp_mail_from', $from_email ); // problem line
    $phpmailer->FromName = apply_filters( 'wp_mail_from_name', $from_name );

WordPress 2.3.3 (/wp-includes/pluggable.php:line 227)

// Set the from name and email
    $phpmailer->From = apply_filters( 'wp_mail_from', $from_email );
    $phpmailer->FromName = apply_filters( 'wp_mail_from_name', $from_name );

I don't know why not setting the Sender in the mail message would make a difference but it does when the e-mail is passing through the GoDaddy system.

Please file this bug over to your developer that work on e-mail forwarding or SMTP so they can further troubleshoot when not including the sender would stop an e-mail from being sent. Also you can close out my ticket. Everything is now working.

Change History (15)

#1 @lloydbudd
16 years ago

  • Milestone changed from 2.3.4 to 2.5
  • Priority changed from highest omg bbq to normal
  • Severity changed from critical to normal

#2 @lloydbudd
16 years ago

Danged if we do, danged if we don't see #5007 & #5273

Also see (and

The problem is that some sites do "callout verification" if the Sender line is present so the email address wordpress@… has to be present, and others if sender is not included fail :(

#3 @lloydbudd
16 years ago

  • Version set to 2.3.3

#4 @nberardi
16 years ago

  • Milestone changed from 2.5 to 2.3.4
  • Priority changed from normal to high

I found the problem. It lies in the fact that by defult in the php.ini file doesn't have a from email address set by default.

On Line 431 in class-phpmailer.php I found this line for only when Sender is set:

$old_from = ini_get("sendmail_from");
ini_set("sendmail_from", $this->Sender);

So I added the following line:

ini_set("sendmail_from", $from_email);

Right before (in pluggable.php):

// Set the from name and email
$phpmailer->From = apply_filters( 'wp_mail_from', $from_email );
$phpmailer->FromName = apply_filters( 'wp_mail_from_name', $from_name );

And everything worked. I guess PHP has some mail interfacing issues in different environments. By the way there is an undated PHPMailer out on Source Forge.

Hope I helped solve this problem. I think this one is easy enought to solve that you guys might be able to put it in under the next release.

#5 @nberardi
16 years ago

Small enhancement to what is above:


if (strlen(ini_get("sendmail_from"))< 1) {
    ini_set("sendmail_from", $from_email);

#6 @lloydbudd
16 years ago

  • Milestone changed from 2.3.4 to 2.5
  • Priority changed from high to normal
  • Severity changed from normal to major

All patches are first resolved on trunk, hence setting the milestone to 2.5 . Please leave setting the milestone to core contributors.

Please attach your changes as a patch, see the front page for some links to tips, and ask on wp-hackers if you have any questions.

I don't see how your changes will address "callout verification", which is caused by the wordpress@… not existing.

#7 follow-up: @nberardi
16 years ago

I will get some help on the patch. But this is my first one and I am not quite sure what is expected. Also this will not help on callout verification, but when the Sender was removed in the most recent version it had a side-effect of stopping the sendmail_from variable in php.ini from getting set. This will address the side effect with out needing to add the Sender back in. My original assertion about the problem in this ticket was wrong.

But there was a bug created by removing the Sender from 2.3.3. This is what the patch above will correct.

#8 in reply to: ↑ 7 @lloydbudd
16 years ago

Replying to nberardi:

But there was a bug created by removing the Sender from 2.3.3. This is what the patch above will correct.

As #5007 describes this line wasn't there until 2.3.1 . Reapplying [6265] reintroduces the callout verification issue for people.

It sounds like the tricky is deciding which is the worse problem.

#9 @nberardi
16 years ago

I understand what you are saying. The call out actually happened when the @params part of the PHP mail() method was used. It sent "-io -f wordpress@…" to the mail provider. This is what caused the call out issue.

But what I am talking about is that PHPMailer also did something in addition to what I listed above. It set the sendmail_from for php.ini. This parameter only effects Windows installs of PHP. This php.ini parameter is what my work around addresses, it does not call out for validation.

You will find the code I am talking about at to see what setting the Sender does. I am sure you have looked at it, I am just pointing it out in this ticket for anybody who hasn't.

#10 @Otto42
16 years ago

  • Summary changed from Weird GoDaddy Problem With WordPress to Yet another email problem with Sender line

Adding an ini_set line instead doesn't actually fix the problem. It's the same solution as setting the Sender, just in a different location.

Here's the thing: Some hosts work with the Sender line, some don't. Some hosts need the Sender line, some don't. Now, understand why: The Sender line sets the sendmail_from parameter. On some hosts, this parameter is necessary to make it through their mail systems. On some hosts, it's not. On yet some other hosts, setting this means that the email address you use must actually exist.

Upshot: We should always include the Sender line *and* ensure that the email address being used actually exists. This case is the only case that will pass through all email systems encountered.

Problem: We have no way to verify that an email address exists or to create our own address.

Result: We cannot use "wordpress@…" for the sender's email address anymore. We have to use a user-specified address as the Sender, an address which the administrator claims to exist.

Proposed suggestion: Use the admin's email address as the sender, from the General Options page.

#11 @nberardi
16 years ago

I think we are getting close. Instead of trying to make the e-mail address an automatic e-mail from some source. Why don't you let it get set in the config PHP file. That way it can be set to whatever people want so if somebody still wants to use wordpress@… they can or if they want to use whatever else tickles their fancy their are also able too.


#12 @djr
16 years ago

+1 for proposed solution by nberardi. I hate the wordpress@… address anyway and it's the first thing I fix on new installs.

#13 @mrmist
16 years ago

  • Keywords needs-patch dev-feedback added
  • Severity changed from major to normal

Needs either patching or closing. Can't say I've hit upon the issue.

#14 @jacobsantos
16 years ago

  • Milestone 2.9 deleted
  • Resolution set to invalid
  • Status changed from new to closed

Needs to be addressed in a plugin. There are just too many server configurations for WordPress to work on all of them. If they "fix" it for you, then they break it for others. You see how the cycle continues.

#15 @jacobsantos
16 years ago

  • Keywords needs-patch dev-feedback removed
Note: See TracTickets for help on using tickets.