I was recently working on setting up an instance of WordPress multisite. As a matter of fact, this website is most likely being served from that very same instance, right now. In the process of setting it up, I noticed that I was not receiving any emails, like I would normally expect from WordPress. That’s strange, I thought, so I decided to pretend like I lost my password, to trigger an email. I didn’t get it. I continued to investigate, and eventually found there was a message from google, hidden away in the mail folder for the web server user. In response to the email that was sent for me to reset my password, google said the following…
Our system has detected that this message is not RFC 2822 compliant. To reduce the amount of spam sent to Gmail, this message has been blocked. Please review RFC 2822 specifications for more information
After a bit of searching google, I found a thread that said it was most likely something to do with the ‘Date’ or ‘From’ headers. So I went back to the delivery failure notification I received, to look at the original email’s headers. A-ha! The ‘From’ header looked a bit suspicious. WordPress was trying to send the email from “[email protected]*.marslender.com”.
After investigating, this comes down to the way that wp_mail() generates the ‘From’ header, when one is not explicitly provided to it. The function essentially takes the SERVER_NAME and adds a “[email protected]” before it. In addition, nginx is configured to respond to “*.marslender.com” so that any subdomain of marslender.com is directed to this site, so the SERVER_NAME had a value of “*.marslender.com” in this situation.
Luckily, WordPress provides a filter for the from email address, called ‘wp_mail_from’. I just created a mu_plugin that hooks into that filter, and removes the ‘*.’ portion of the from email, if it was present.
In addition, it looks like there is a trac ticket related to this issue, so this may be resolved in a future version of WordPress.