Content-Transfer-Encoding for Email Newsletters

I'm not sure about improving delivery or lowering spam scores but it is very important to specify this header and encode the message body accordingly.

Case in point, have you ever received an email on your iOS device which reads "This message has no content"? If you haven't, then you are in luck. I receive a couple of these a week from the several companies I follow - they help me stay current with email marketing design and trends. From my subscriptions, the most consistent offender is Email on Acid - yes, I follow them ^_^.

Since these messages are unreadable on my iOS devices, I am forced to view them (often at a later time) via Outlook on my workstation.

After tons of digging into their raw emails (I host my own email server so this is quite easy), I discovered that they consistently omit this header in the boundary header area of the text/html portion of their multipart messages. To test my finding, I sent myself test emails (using PHP) and confirmed that messages lacking the Content-Transfer-Encoding header were unreadable while messages with the header displayed as expected.

According to the spec (RFC1341), email clients are to fallback to 7bit when the Content-Transfer-Encoding header is absent. So, the finger here should be pointed at the Apple Mail implementation of the standard.

My go-to encoding scheme is quoted-printable.

This all sounds a bit off to me. At least as it concerns to deliverability. That said, I ran across this which may shed some insight https://support.microsoft.com/en-us/kb/323489

https://wordtothewise.com/ <-- pro

I don't have any concrete answers here, but will share a link and some experience. First, the reason for my interest in this is that we have been sending out transactional HTML emails (password reset, followed notifications, etc.) for a couple of years now, encoded solely in base64. Usually this works fine, but from time to time a customer will let us know that all they can see is encoded characters. Our previous developer mentioned this was likely because the message was corrupted in transit, rather than the formatting of the message itself. However, from the reading I have done:
a) it seems base64 only really makes sense for data, not text (including HTML), at least when using a standard Western character set. So quoted printable may be a safer encoding to use (i.e., supported by more systems, and also more or less human-readable, even if it does get shown to the user in raw format)
b) a good practice, it seems, is to always include a plain-text version of the message as well as an HTML version. This is possible by using multipart MIME.
I found this Litmus blog post helpful.

Hello Lemuel,

Did you get any feedback on your question?
Have you tried it to see if it improves delivery and spam score/filtering?

I just learned about this techinque and i'm wondering if it worth the time to test it...

Thanks!

So my first instinct is to say, no, that spam filtering and delivery scores are not affected by Content Transfer encoding. Because Email is an old standard, email transmissions were originally written supporting only the ASCII character set. However, HTML and the web supports much broader character sets (UTF-8/16). In order to transmit that data over a medium that only supports ASCII we usually encode the UTF8 or other codepage using one of the transfer encodings then when clients go to render the message they can decode the more complex codepage and render emoji, foreign languages, etc etc.

So my guess is that the scores for spam are going to be determined after the email is decoded and that I couldn't see a good reason why delivery/spam software would care about encoding.