MimeMessageHelper seems to encode HTML multipart wrong

[lapo-luchini]

I have this example code:

import org.springframework.mail.javamail.JavaMailSenderImpl;
import org.springframework.mail.javamail.MimeMessageHelper;

import jakarta.mail.internet.MimeMessage;

public class SendMail {
    public static void main(String[] args) throws Exception {
        JavaMailSenderImpl mailSender = new JavaMailSenderImpl();
        MimeMessage message = mailSender.createMimeMessage();
        MimeMessageHelper helper = new MimeMessageHelper(message, true); // no charset specified!
        helper.setText("test: €", false);
        message.saveChanges();
        message.writeTo(System.out);
    }
}

And with plaintext multipart it works OK:

Date: Fri, 18 Apr 2025 15:07:45 +0200 (CEST)
Message-ID: <32863545.2.1744981670669@cyberone>
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_0_1447689627.1744981665679"

------=_Part_0_1447689627.1744981665679
Content-Type: multipart/related; 
	boundary="----=_Part_1_1589683045.1744981665683"

------=_Part_1_1589683045.1744981665683
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

test: =E2=82=AC
------=_Part_1_1589683045.1744981665683--

------=_Part_0_1447689627.1744981665679--

The euro symbol is encoded in UTF-8 as =E2=82=AC, which is correct.

If I change this line to HTML though:

        helper.setText("test: €", true);

the multipart is different:

------=_Part_1_1589683045.1744982134344
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

test: ?
------=_Part_1_1589683045.1744982134344--

This is with local output. When sending to a SMTP server, I one got the header declaring UTF-8 and then the content using a single high-bit value, which was actually encoded in Latin9.

[lapo-luchini]

Declaring the required charset explicitly does work around the issue:

        MimeMessageHelper helper = new MimeMessageHelper(message, true, "UTF-8");
        helper.setText("test: €", true);

gets the correct:

------=_Part_1_1589683045.1744982269159
Content-Type: text/html;charset=UTF-8
Content-Transfer-Encoding: quoted-printable

test: =E2=82=AC
------=_Part_1_1589683045.1744982269159--

but I think the default should do something proper in any case, and choose a sane default. (or, at the very least, a header and a content which are coherent with each other)

[sbrannen]

Hi @lapo-luchini,

Congratulations on submitting your first issue for the Spring Framework! 👍

Declaring the required charset explicitly does work around the issue:

I would not consider that a workaround but rather a robust way to ensure the proper encoding is used.

Encoding can be a difficult topic, and the defaults may change based on the operating system, JVM configuration, the presence of the mail.mime.charset JVM system property, etc.

If you look at the class-level Javadoc for MimeMessageHelper, you'll see that it provides an example which explicitly sets the encoding for HTML to UTF-8.

mailSender.send(new MimeMessagePreparator() {
   public void prepare(MimeMessage mimeMessage) throws MessagingException {
     MimeMessageHelper message = new MimeMessageHelper(mimeMessage, true, "UTF-8");
     message.setFrom("me@mail.com");
     message.setTo("you@mail.com");
     message.setSubject("my subject");
     message.setText("my text <img src='cid:myLogo'>", true);
     message.addInline("myLogo", new ClassPathResource("img/mylogo.gif"));
     message.addAttachment("myDocument.pdf", new ClassPathResource("doc/myDocument.pdf"));
   }
});

You might also find this Stack Overflow discussion helpful.

In light of the above, I am closing this issue.

[lapo-luchini]

Okay, thanks!
Detecting a proper charset is certainly complex and forcing UTF-8 is (IMHO) the best way anyways… but it could make sense to deprecate the method without the charset parameter to avoid future mistakes?