[SOLVED] CB Registration Emails in Plain Text only

Still sounds like an encoding issue on the server that we've no control over. We're working on removing our PHPMailer API entirely and switching to Joomla's. This should be available next week and that might help solve your issue. Your encoding issue seams similar to the below topic, which as a workaround is forcing the encoding to base64.

www.joomlapolis.com/forum/developer-members-support/244956-bast-way-to-block-hotmail-outlook-live-email-addresses-from-registration?start=6#329581

Thanks for the link to the encoding issue, but that's not the problem. I set PHP 8, then I edited line 65 of /libraries/CBLib/CBPHPMailer/CBPHPMailer.php, trying base64 and got total garbage in the resultant registration email. No readable text at all (using Outlook 2019 as the client). Quoted-printable, 7bit, and 8bit all give the same result I saw before:  a plain text message with various bits of code inserted throughout, as well as a faulty header that causes it to be interpreted as plain text.

If the configuration of the mail server that CB uses isn't the culprit, and it occurs only under PHP 8 (this time I tested under PHP 8.1.1) then what else can it be?

Is there some way I can switch over to use the Joomla mail process for CB registrations? I recognize that's what you're planning to do next week, and I look forward to seeing that; however, if I can do it myself temporarily, I can see if that's the problem or if it's something else associated with PHP 8.

It is not a simple task switching the mailer over so no I do not have workaround steps and this isn't guaranteed to fix the issue either as it's likely a problem with the mail server. Suggest just using PHP 7.4 for the time being unless you can convince your host to look into the mail server configuration then retry once we've replaced the mailer with Joomla's and hope that fixes it.

In the raw email source what is "Content-Type" and "Content-Transfer-Encoding" set to?

The easiest way to see what's in the raw source for content type is in the text file I attached to an earlier reply in this thread.

There is no content-transfer-encoding listed.

If you compare the top code (PHP 7) with the bottom code (PHP , you can see that the only thing that's actually changed between the two is that, under PHP 8, = signs are replaced with =3D and hyphens are replaced with -= . Also, www.w3.org is replaced with http://www.= w3.org.

This link:  www.cnsplug-ins.com/Plug-ins/SMTPit_Pro/Knowledge_Base/Frequently_Asked_Questions/Why_does_=3D_show_up_in_the_source_code_of_my_HTML_emails says that the =3D means it's using "Quoted Printable Encoding" but CBPHPMailer.php shows it's supposed to be using 8bit.

Curious.
 

If you compare the top code (PHP 7) with the bottom code (PHP , you can see that the only thing that's actually changed between the two is that, under PHP 8, = signs are replaced with =3D and hyphens are replaced with -= . Also,  www.w3.org  is replaced with http://www.= w3.org.

Correct, that is an encoding issue. Without "Content-Transfer-Encoding" I have no idea what encoding your mail client is interpreting the email as. That information should be available when using "View Source" in your mail client.

means it's using "Quoted Printable Encoding" but CBPHPMailer.php shows it's supposed to be using 8bit.

The encoding used by PHPMailer is dependent on the contents of the email. The code in our PHPMailer is perfectly valid on PHP 8.0 and even 8.1 (this has been thoroughly tested).

We're already completely removing our PHPMailer so if it is in fact the problem it won't matter come next week as its being completely removed. We can't rush the removal as we've to retest all of our emails and make sure this change doesn't break CB so the earliest I can have this released is sometime next week.

We do look forward to the modification next week.

Correction:  Earlier, I said we didn't use Joomla's email function, but it turns out we do. We use RSForms! Pro to collect registrations for organization functions. Those emails are HTML and all have worked correctly for all email clients. So, we're hopeful that switching CB to a similar email function will work.

On an aside:  We went to XAMPP with PHP 8.1.6 under Windows 11 to test the CB Registration emails that we've been having problems with. We set localhost to use "mailtodisk" function so that the output of CB Registration emails were written to disk in a plain text file. The code within that registration confirmation email is identical to the malformed emails we've seen on the live site. In addition, the code in that text file states that Content-Transfer-Encoding is quoted-printable. As we saw from a previous link, the =3D insertions are indicative of quoted-printable, even though 8bit is set in CBPHPMailer.php. Note that such an email never touches an email client for "interpretation" or modification. As best we can tell, it goes from CBPHPMailer directly to disk in a plain text file. We also noted that there are several "conditions" within CBPHPMailer.php that can automatically change the encoding to quoted-printable. There's apparently even an old function that has been removed and a deprecated function (encodeQP), both dealing with switching to quoted-printable. Maybe there's some code there that doesn't like PHP 8, if our emails met some criteria that triggered those exceptions (like the "line_max"?). Just guessing.