default 'from' hostname

[lonnylot]

The logic used to create the hostname portion of default e-mail address when calling wp_mail doesn't make sense.

Lines 384-392 of wp-includes/pluggable.php read:

	if ( !isset( $from_email ) ) {
		// Get the site domain and get rid of www.
		$sitename = strtolower( $_SERVER['SERVER_NAME'] );
		if ( substr( $sitename, 0, 4 ) == 'www.' ) {
			$sitename = substr( $sitename, 4 );
		}

		$from_email = 'wordpress@' . $sitename;
	}

We assume that if www. is in the sitename that it is not part of the e-mail address. I reviewed a few RFCs and have not found where 'www.' is prohibited from the hostname portion of an e-mail address. I concede that john.smith@ www.sitename.com is now common, but it is still a legal name.

Additionally, if the $_SERVER[ 'SERVER_NAME' ] is a sub-domain such as blogs.sitename.com the e-mail is going to send from john.smith@ blogs.sitename.com.

For consistency I suggest we either remove all nth level domain names above the first or remove none. This way it will be more obvious when people need to use the wp_mail_from filter and not just appear to be random.

[dd32]

We assume that if www. is in the sitename that it is not part of the e-mail address. I reviewed a few RFCs and have not found where 'www.' is prohibited from the hostname portion of an e-mail address. I concede that john.smith@ www.sitename.com is now common, but it is still a legal name.

In general, 90% of hosts add www. as a add-on domain, and many simply skip it, it's just a generic subdomain.. in the majority of cases, user@domain.com is going to be more correct than user@www.domain.com, for the simple fact that the 'www.' is a generic domain for Web Hosting.

Additionally, if the $_SERVER[ 'SERVER_NAME' ] is a sub-domain such as blogs.sitename.com the e-mail is going to send from john.smith@ blogs.sitename.com.

That would be the expected behaviour for a a few reasons, the main one that sticks out to me is:

• http://username.webhost.com/ => wordpress@webhost.com would be wrong

I don't see that anything here should change, it's not about what is legal in a email address, it's about what the majority of WordPress users expect/host supports.

[toscho]

There should be at least a check for domains like www.eu/com/net to avoid addresses like wordpress@com.

[hakre]

Thanks for reporting, it's obvioous that it can be done better than that. +1

[lonnylot]

dd32,

I do not think it is about what the majority of WordPress users expect/host supports. I am not trying to open up a can of worms, but if it was about what users expect/host supports than we wouldn't have WordPress default to wordpress@ hostname.com for things like the registration e-mail.

Sending an e-mail from wordpress@ hostname.com is no more user friendly than sending it from wordpress@ www.hostname.com or removing all subdomains by default and always sending it from wordpress@ hostname.com.

Again, I'm not trying to open this discussion up to that particular discussion. I am just trying to make a point that the handling isn't related to what users expect/hosts support.

Just Googling around it seems the amount of issues that people have with e-mails being rejected from the receiver are fairly high. The more I think about this I would rather do nothing with the hostname ($_SERVER[ 'SERVER_NAME' ]) than do something random.

I just wanted to give my 2 cents on this. Thanks for taking the time to review this bug. Please let me know if anyone has suggestions on implementation or anything you would like me to create anything such as a patch.

[lonnylot]

Is there a place to create a WP RFC for this?

[SergeyBiryukov]

Related: #25239

[isdampe]

Please see attached patch to remove reliance on $_SERVER[ 'SERVER_NAME' ].

[SergeyBiryukov]

#29175 was marked as a duplicate.

[cbutlerjr]

@SergeyBiryukov has noted that #25239 is closely related to this and there is a recommended solution in that ticket. It addresses the issue of removing the use of $_SERVER['SERVER_NAME'] but in a more comprehensive way (it's actually used in the mail process in a few locations).

I suggest closing this as the fully implemented solution there should also resolve this.

[SergeyBiryukov]

Duplicate of #25239.