Feature: Expand email builder API to support selective Content-Transfer-Encoding, like quoted-printable, base64, 7BIT and others

[HoaiDang-work]

Hi,

I can base64 encode an HTML email without attachments by adding header Content-Transfer-Encoding: base64. However, when having attachment, header Content-Transfer-Encoding: base64 does not affect, the body part still has Content-Type: text/html; charset="UTF-8" and Content-Transfer-Encoding: quoted-printable while the attachment part has Content-Type: image/jpeg; filename=6145256529176145767_121.jpg; name=6145256529176145767_121.jpg and Content-Transfer-Encoding: base64.

Can you advise on how to set Content-Transfer-Encoding for the body part to base64 in this case?

[bbottema]

I'm not familiar with base64 encoding in emails, really, so I can't help you there. I'm not even sure what the use case is here. What are you trying to accomplish and why?

[HoaiDang-work]

When I tried to create Email then set header "Content-Transfer-Encoding" : "base64", for the plain text Email or HTML email, the email's content (EML file) is encoded without me doing any extra coding.

However, when I built an Email with attachment, the EML file is partially encoding (The attachment is encoded, but not the email's content)

I read that for the case of Content-Type: multipart/mixed; (any types of mutipart contentType), the Content-Transfer-Encoding is supposed to be set on the individual parts instead of the message, but I failed to see a way to set Header for part using simple-java-mail. When Content-Transfer-Encoding is not set on the parts, javax-mail tried to infer the header's values itself and returned unexpected result.

I'm not sure what should be the proper fix because I'm not familiar with MimeMessage specs, which headers are supposed to be set on children parts, which are not, but one dirty fix I can think of is maintaining a list of HEADERs to be propagated to sub-parts and set them during populateMimeMessageMultipartStructure

[bbottema]

Ahh, that makes sense, thanks for the clear explanation and it's clear you to found the right place already where to fix it somehow. I have some idea where to put the header, but I would like to be a little bit more selective as to which headers should be propagated to the text/html content (iCalendar?).

Do you know of other headers that might be relevant specifically to the content? Encoding seems to be the big one and might very well be the only relevant one.

[bbottema]

I've updated the Email builder api so you can now do this:

myEmailBuilder.withContentTransferEncoding(ContentTransferEncoding.BASE_64);

You can now also use one of the others encoders. If this works for your use case, then will release this in 7.2.0

[HoaiDang-work]

As long as the content transfer encoding propagates to the parts, I think it will work for my use case. Thanks a lot! Do you have a tentative release date for 7.2.0? :)

[bbottema]

Yes, I'm planning to release it today. It's already tested.

[bbottema]

Released in 7.2.0