Immigrationdotcom
Member
The emails that go out from xenforo such as email activation on registration, password reset, new thread posted emails etc have a bunch of characters in there, even though actual content is there, it is not being parsed correctly. See the effort made by xenforo support and rackspace hosting company suppoty to resolve the issue. If you are able to help with this, we can hire you.
--------------------------------------------------------
FROM XENFORO
Hi,
I have debugged the entire handling of the email within XF. It is correct the entire way through the sending process until it is handed off to your mail server. Therefore the problem exists outside of XF and is likely some bad configuration in your mail server.
There are two transport options:
Admin CP -> Home -> Options -> Email Options -> Email Transport Method
You are currently using Default which points to your server's own mail server. For this method you will need to contact your host or server admin regarding bad handling of emails by their mail server.
Alternatively you can specify a SMTP server on this page if you have one you can use. Using a SMTP server would avoid the problem which apparently exists within your default mail server.
I debugged (temporarily modified) the code relating to sending emails so I could carefully check the content of the email before it gets sent. The email is perfect before it gets sent. The content inside of XenForo and the database is not corrupt. It is the mail server that is apparently corrupting the email.
You can see the completed email before it gets sent by viewing this debug file I created:
/disk2/v/apache/htdocs/VIRTUAL/community.immigration.com/public_html/internal_data/ZendMail_1501437825_864822349.tmp
That is the email produced when I request a password reset for my account. You can see that it is not base64 and it is not corrupt. But when XenForo passes this email to your mail server it becomes corrupt.
------------------------------
----------
RACKSPACE RESPONSE
Greetings Monica,
After investigating this issue further and with assistance from a Senior tech, we were able to prove that there is nothing wrong with the mail server (ie Postfix). We took the example email that was created before sending to the mail server (ZendMail_1501437825_864822349.tmp), changed the "To" address, removed the "X-To-Validate" (because it wasn't necessary), and piped it straight to Postfix:
#########
sendmail -i -t < html_email_test_william_2
#########
Doing it this way bypassed your application and ensured Postfix received the entire email exactly as your application configured it. We received the email successfully and it was indeed properly formatted. This points towards the problem being somewhere in your application and how it's actually passing the formatted email to the mail server.
I also wanted to point out that the emails being received aren't "corrupt", it's more-so that by the time Postfix receives it, it doesn't seem to know that it's HTML. Essentially the email appears to be being processed as plain-text, so the email being sent isn't corrupt, but just showing the raw, plain-text email, which is why you see all the "<html>" code in the email. I would recommend letting the Xenforo developers know that the emails aren't corrupt, but instead are plain-text instead of HTML formatted, which is why they look so weird. I'd also let them know that if we pass the email directly to sendmail (as mentioned above), the emails are sent properly formatted.
---------------------------------------------------------------
RESPONSE BY XENFORO
Hi Monica,
It is worth mentioning this may be related in the hand off between XenForo, and the PHP mail function.
Obviously calling sendmail directly from the command line is not going to invoke that hand off as it is calling the function directly.
The outputted file above is what is generated by XenForo.
That file is then sent via the PHP mail function, if the function directly is working, and the file being generated is also correct, it would suggest the issue lies somewhere in that hand off. It may be worth asking your sysadmins to look into that aspect.
To verify the file being output by XenForo, you can have your admins add the following to the /library/config.php file:
XenForo_Mail::setupTransport(new Zend_Mail_Transport_File(array(
'path' => realpath(dirname(__FILE__) . '/../internal_data')
)));
and then performing a password reset, this will output the email file to the internal_data directory. This will show the email is being generated is correctly formatted.
You can then run the sendmail command line to verify that part runs correctly.
If you remove the above code from the config.php file, and perform a password reset, rather than being written out to the file, the email will be handed off to the php mail function.
I suspect this is where things are going wrong.
---------------------------------------
RESPONSE BY RACKSPACE
Hello Monica,
Thank you for calling in today,
As per our conversation I did take a closer look at the issue however as my colleagues discerned earlier there does not appear to be an issue on the sendmail side of things.
If the issue is indeed happening in the handoff to the php mail function this still indicates an issue with code as this handoff basically consists of defining the variables for the mail function and sending said variables through it.
More information on the php mail function:
http://docs.php.net/manual/da/function.mail.php
If up to this point everything looks good then the issue may be with what variables are set to in the code that makes the final call to this function.
--------------------------------------------------------
FROM XENFORO
Hi,
I have debugged the entire handling of the email within XF. It is correct the entire way through the sending process until it is handed off to your mail server. Therefore the problem exists outside of XF and is likely some bad configuration in your mail server.
There are two transport options:
Admin CP -> Home -> Options -> Email Options -> Email Transport Method
You are currently using Default which points to your server's own mail server. For this method you will need to contact your host or server admin regarding bad handling of emails by their mail server.
Alternatively you can specify a SMTP server on this page if you have one you can use. Using a SMTP server would avoid the problem which apparently exists within your default mail server.
I debugged (temporarily modified) the code relating to sending emails so I could carefully check the content of the email before it gets sent. The email is perfect before it gets sent. The content inside of XenForo and the database is not corrupt. It is the mail server that is apparently corrupting the email.
You can see the completed email before it gets sent by viewing this debug file I created:
/disk2/v/apache/htdocs/VIRTUAL/community.immigration.com/public_html/internal_data/ZendMail_1501437825_864822349.tmp
That is the email produced when I request a password reset for my account. You can see that it is not base64 and it is not corrupt. But when XenForo passes this email to your mail server it becomes corrupt.
------------------------------
----------
RACKSPACE RESPONSE
Greetings Monica,
After investigating this issue further and with assistance from a Senior tech, we were able to prove that there is nothing wrong with the mail server (ie Postfix). We took the example email that was created before sending to the mail server (ZendMail_1501437825_864822349.tmp), changed the "To" address, removed the "X-To-Validate" (because it wasn't necessary), and piped it straight to Postfix:
#########
sendmail -i -t < html_email_test_william_2
#########
Doing it this way bypassed your application and ensured Postfix received the entire email exactly as your application configured it. We received the email successfully and it was indeed properly formatted. This points towards the problem being somewhere in your application and how it's actually passing the formatted email to the mail server.
I also wanted to point out that the emails being received aren't "corrupt", it's more-so that by the time Postfix receives it, it doesn't seem to know that it's HTML. Essentially the email appears to be being processed as plain-text, so the email being sent isn't corrupt, but just showing the raw, plain-text email, which is why you see all the "<html>" code in the email. I would recommend letting the Xenforo developers know that the emails aren't corrupt, but instead are plain-text instead of HTML formatted, which is why they look so weird. I'd also let them know that if we pass the email directly to sendmail (as mentioned above), the emails are sent properly formatted.
---------------------------------------------------------------
RESPONSE BY XENFORO
Hi Monica,
It is worth mentioning this may be related in the hand off between XenForo, and the PHP mail function.
Obviously calling sendmail directly from the command line is not going to invoke that hand off as it is calling the function directly.
The outputted file above is what is generated by XenForo.
That file is then sent via the PHP mail function, if the function directly is working, and the file being generated is also correct, it would suggest the issue lies somewhere in that hand off. It may be worth asking your sysadmins to look into that aspect.
To verify the file being output by XenForo, you can have your admins add the following to the /library/config.php file:
XenForo_Mail::setupTransport(new Zend_Mail_Transport_File(array(
'path' => realpath(dirname(__FILE__) . '/../internal_data')
)));
and then performing a password reset, this will output the email file to the internal_data directory. This will show the email is being generated is correctly formatted.
You can then run the sendmail command line to verify that part runs correctly.
If you remove the above code from the config.php file, and perform a password reset, rather than being written out to the file, the email will be handed off to the php mail function.
I suspect this is where things are going wrong.
---------------------------------------
RESPONSE BY RACKSPACE
Hello Monica,
Thank you for calling in today,
As per our conversation I did take a closer look at the issue however as my colleagues discerned earlier there does not appear to be an issue on the sendmail side of things.
If the issue is indeed happening in the handoff to the php mail function this still indicates an issue with code as this handoff basically consists of defining the variables for the mail function and sending said variables through it.
More information on the php mail function:
http://docs.php.net/manual/da/function.mail.php
If up to this point everything looks good then the issue may be with what variables are set to in the code that makes the final call to this function.