Describe the issue
In [SMTPMessageImpl.Codeunit.al], procedure ConvertBase64ImagesToContentId() parses the HTML body into an XmlDocument and re-serializes it via Document.WriteTo(WriteOptions, DocumentSource) whenever the body contains at least one ![]()
element (e.g. inline base64 images). The AL XmlWriteOptions type only exposes PreserveWhitespace() and offers no way to suppress the XML declaration or control its encoding. As a result, the serialized string always starts with , regardless of the actual wire encoding. This string becomes the new MimeBodyBuilder.HtmlBody, which MimeKit then transmits as Content-Type: text/html; charset="utf-8" with Content-Transfer-Encoding: quoted-printable. The in-document XML declaration therefore contradicts the actual MIME charset. Outlook's Word-based rendering engine gives precedence to the (wrong) in-document declaration over the MIME charset, interprets the UTF-8 bytes as UTF-16, and the resulting garbled text gets misclassified as Japanese by Outlook's language/encoding auto-detection.
Expected behavior
An HTML body that is embedded as a MIME text/html part must never contain an XML declaration/prolog — it's an HTML fragment, not a standalone XML document, and any declaration inserted by XmlDocument.WriteTo cannot reliably reflect the actual transport encoding chosen later by MimeKit. The prolog should be stripped from DocumentSource before it is assigned to MimeBodyBuilder.HtmlBody
Steps to reproduce
Send an email via the SMTP connector/API with SetBody(HtmlBody, true) where HtmlBody contains at least one ![]()
.
Inspect the raw .eml of the sent message.
The text/html MIME part's body starts with even though the part is declared and transferred as charset="utf-8" / quoted-printable.
Open the email in Outlook the message language can be auto-detected as Japanese even if the language of the mail is e.g. german
Additional context
Original HTML body of the mail with the base64 image
HTMLMaiBodylWithBase64Image.txt
Received Mail from OWA (Downloaded .eml file)
Mail.eml
I will provide a fix for a bug
Describe the issue
In [SMTPMessageImpl.Codeunit.al], procedure ConvertBase64ImagesToContentId() parses the HTML body into an XmlDocument and re-serializes it via Document.WriteTo(WriteOptions, DocumentSource) whenever the body contains at least one![]()
element (e.g. inline base64 images). The AL XmlWriteOptions type only exposes PreserveWhitespace() and offers no way to suppress the XML declaration or control its encoding. As a result, the serialized string always starts with , regardless of the actual wire encoding. This string becomes the new MimeBodyBuilder.HtmlBody, which MimeKit then transmits as Content-Type: text/html; charset="utf-8" with Content-Transfer-Encoding: quoted-printable. The in-document XML declaration therefore contradicts the actual MIME charset. Outlook's Word-based rendering engine gives precedence to the (wrong) in-document declaration over the MIME charset, interprets the UTF-8 bytes as UTF-16, and the resulting garbled text gets misclassified as Japanese by Outlook's language/encoding auto-detection.
Expected behavior
An HTML body that is embedded as a MIME text/html part must never contain an XML declaration/prolog — it's an HTML fragment, not a standalone XML document, and any declaration inserted by XmlDocument.WriteTo cannot reliably reflect the actual transport encoding chosen later by MimeKit. The prolog should be stripped from DocumentSource before it is assigned to MimeBodyBuilder.HtmlBody
Steps to reproduce
Send an email via the SMTP connector/API with SetBody(HtmlBody, true) where HtmlBody contains at least one![]()
.
Inspect the raw .eml of the sent message.
The text/html MIME part's body starts with even though the part is declared and transferred as charset="utf-8" / quoted-printable.
Open the email in Outlook the message language can be auto-detected as Japanese even if the language of the mail is e.g. german
Additional context
Original HTML body of the mail with the base64 image
HTMLMaiBodylWithBase64Image.txt
Received Mail from OWA (Downloaded .eml file)
Mail.eml
I will provide a fix for a bug