We have an open ticket on this now, and here is what we've uncovered. Not sure if it will help you all or not. Still waiting on the full resolution from the SM team, but we have a workaround in place.
We were on 8797 and migrated to 8832. At this point, any HTML email that we sent from SmarterMail to Gmail, O365 and some other random email servers was mangled.
When we set up archiving and looked at the eml from SmarterMail, everything looked normal. On another SmarterMail server, when receiving the email, everything also looked normal. When looking at the resulting .eml at Google or O365, we noticed these headers:
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
But then in the body of the email, it was escaping = with =3D and the like.
What we did, was we changed our outbound emails to have mixed parts, a plain text and html version. The plain text was just a simple one liner that said "Your client does not support HTML emails" or something like that.
Now, in Gmail and O365, they received it as a multipart email. The plain text had headers:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
And the html had headers:
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
And the usual escaping of the body. This made everything render like normal.
TLDR: We changed our HTML only emails to be multipart, leaving the same HTML but including a plain text part and that has done the trick temporarily.