Formatting issue with HTML emails and 365 smtp adding = in middle of word.

[jelle-burodeng]

We send our emails through office365 via smtp. Somehow every 70-80 characters a character gets replaced by an equal sign such as below:

Dear C=ris Thank =ou for contacting us. We app=eciate that you’ve taken the time to write. If you=eed a response, we’ll get back to you as quickly as we can.

I''ve found other users are experiencing this too:
https://expressionengine.com/forums/topic/253810/formatting-issue-with-html-emails-and-365-smtp-adding-in-middle-of-word

And i've found a possible solution here:
https://stackoverflow.com/questions/13065695/codeigniter-smtp-email-message-characters-replaced-with-equal-signs
"once I put in the "$this->email->set_crlf( "\r\n" );" it worked immediately without any issues!!!"

I have seen this issue on this site both when it was on EE5 a few months ago, but also now that it's running on EE7.3.14

I changed line 169 in /ee/legacy/libaries/email.php to public $crlf = "\r\n"; which seems to solve this

There is a sense of urgency to this one sine it's affecting orders from an ecommerce site

[nep]

Old time emails used to sometimes be set to "quoted-printable" encoded -- among other things, they'd get an automatic line break every 75-ish characters and an = sign. I don't know why Office365 is requiring this... but.

There is a config override for this:
https://docs.expressionengine.com/latest/general/system-configuration-overrides.html#email_crlf

So you don't have to edit Core, you just have to set your config differently to handle the demands of your email setup.

[jelle-burodeng]

Well... the config override for that is not working in my case.. The setting is selected both in the cp settings, as well as in the config but it's not working. After i edited the core if works as it should

[intoeetive]

@jelle-burodeng are you using an add-on to send email, or you also have the issue when sending from EE Control Panel via Communicate tool?

From what I can tell, the email_crlf config override should work, but the code needs to call ee()->email->EE_initialize() and not just initialize - could the add-on be skipping that? Also it's required to use double quotes for the config value

[jelle-burodeng]

We send emails through Freeform 3.0.5 and cartthrob 8.1. And for testing i sent a bunch through the native communicate form too.
I tried the config override too, but that seemed to have no effect.

[intoeetive]

@jelle-burodeng does it work if you also set email_newline config override to save value?

So two config overrides both pointing to "\r\n"

[jelle-burodeng]

I can't test that at this moment...

[dougblackjr]

Didn't realize this issue was here, experiencing the same thing. Looks related to line length and Microsoft's extended charset.

Slack thread here: https://eecms.slack.com/archives/C04CUNNR9/p1717090238390409

[pyrobob83]

We just ran into this too, though in our case SparkPost was denying the emails completely. Config overrides did nothing.

Only way to solve was to change public $crlf = "\n"; to public $crlf = "\r\n"; in that Email.php file.

[gilbert-hop]

@intoeetive It seems like the set_crlf method is not being called at all because there are no email_crlf settings in the backend; hence, there is no such config item.

If you change EE_initialize() in system/ee/legacy/libraries/Email.php

if (ee()->config->item('email_newline') !== false) {
            $config['newline'] = ee()->config->item('email_newline');
            $config['crlf'] = ee()->config->item('email_newline');
}

The if statement if ($this->crlf === "\r\n") in _prep_quoted_printable($str) can be properly determined.

[acutedeveloper]

Just came here to see if this was a logged issue as I had been struggling with this.

I implemented @gilbert-hop solution. As this is a core file, it would be comforting to know that something more permanent is baked in.

Though I'm presuming that because this is a legacy file change is unlikely?

[intoeetive]

Looking into this once again, @gilbert-hop - you are absolutely right, the method was not being called (unless you have a config override). So I have PRed your change. Thank you!

@robinsowell would you mind testing this (over time) on various setups to make sure it does not break anything (it should not though)