Will using Content-Transfer-Encoding: base64 for text and html-email have any problems?

Question

I am working on an email project. For reasons that I will not do here, quoting quotes for printing in long emails is problematic in a client environment.

Performing base64 encoding in HTML and text sections of sent SMTP letters seems to be a viable option. When tested, this seems to work fine in several test clients (e.g. Gmail).

However, I am wondering if any mail clients will have any problems. From reading the RFC specs, it seems that base64 is compatible encoding for text sections, but this is unusual enough for text and html sections that I would like to know if there are any potential problems to consider.

Things that seem problematic:

• Perhaps some older or less reliable clients do not expect base64 in text or HTML email addresses and will not be able to encode it.
• Some email clients may be previewing or searching based on the original content, so recipients will see base64 instead of the actual content
• Perhaps base64 could adversely affect performance / spam?

Does anyone have experience that they can share? This seems like a good solution, but I would like to make sure that I did not miss something.

Answer 1

It is difficult to answer - yes, quoted-printable used most often because it spends less bytes and because the source text of the body part of the letter resembles decoded output. However, there is nothing that prohibits the use of base64 for the text parts of a message.

This is a fairly open question: you can never be sure that the MUA will not break hopelessly somewhere until it shows anything. There is a lot of “maybe”, and you are right, but the problem is that you will never know. If this allows you to sleep better, the following companies use base64 encoded HTML in the marketing spam I receive:

• Mellanox
• Alza.cz
• Aukro.cz
• Journal of Modern Physics

Any MUA that can display embedded images must include a base64 decoder. It is possible that MUA may explicitly refuse to use this code to decode text/plain and text/html , but in this case you are screwed up anyway.

As a fun fact, one of these companies is pleased to break the UTF-8 encoded object on the byte border, inside the multibyte character, and encode both halves of the text in separate encoded words (RFC2047 terminology here).