While sending email content, it is required to set "Content Transfer Encoding" header. I observed many headers of emails that I received. Some emails using "7bit" and some are using "8bit".
What is the difference between these two? Which is recommended? Is there any special encoding required for email body in order to set these headers?
Best Answer
It can be a bit dense to read, but the "Content-Transfer-Encoding" section of RFC 1341 has all of the details:
http://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html
The situation kinda goes from bad to worse. Here's my summary:
Background
SMTP, by definition (RFC 821), limits mail to lines of 1000 characters of 7 bits each. That means that none of the bytes you send down the pipe can have the most significant ("highest-order") bit set to "1".
The content that we want to send will often not obey this restriction inherently. Think of an image file, or a text file that contains Unicode characters: the bytes of these files will often have their 8th bit set to "1". SMTP doesn't allow this, so you need to use "transfer encoding" to describe how you've worked around the mismatch.
The values for the
Content-Transfer-Encoding
header describe the rule that you've chosen to solve this problem.7Bit Encoding
7bit
simply means "My data consists only of US-ASCII characters, which only use the lower 7 bits for each character." You're basically guaranteeing that all of the bytes in your content already adhere to the restrictions of SMTP, and so it needs no special treatment. You can just read it as-is.Note that when you choose
7bit
, you're agreeing that all of the lines in your content are less than 1000 characters in length.As long as your content adheres to these rule,
7bit
is the best transfer encoding, since there's no extra work necessary; you just read/write the bytes as they come off the pipe. It's also easy to eyeball7bit
content and make sense of it. The idea here is that if you're just writing in "plain English text" you'll be fine. But that wasn't true in 2005 and it isn't true today.8Bit Encoding
8bit
means "My data may include extended ASCII characters; they may use the 8th (highest) bit to indicate special characters outside of the standard US-ASCII 7-bit characters." As with7bit
, there's still a 1000-character line limit.8bit
, just like7bit
, does not actually do any transformation of the bytes as they're written to or read from the wire. It just means that you're not guaranteeing that none of the bytes will have the highest bit set to "1".This seems like a step up from
7bit
, since it gives you more freedom in your content. However, RFC 1341 contains this tidbit:RFC 1341 came out over 20 years ago. Since then we've gotten 8bit MIME Extensions in RFC 6152. But even then, line limits still may apply:
Binary Encoding
binary
is the same as8bit
, except that there's no line length restriction. You can still include any characters you want, and there's no extra encoding. Similar to8bit
, RFC 1341 states that it's not really a legitimate encoding transfer encoding. RFC 3030 extended this withBINARYMIME
.Quoted Printable
Before the
8BITMIME
extension, there needed to be a way to send content that couldn't be7bit
over SMTP. HTML files (which might have more than 1000-character lines) and files with international characters are good examples of this. Thequoted-printable
encoding (Defined in Section 5.1 of RFC 1341) is designed to handle this. It does two things:Quoted Printable, because of the escaping and short lines, is much harder to read by a human than
7bit
or8bit
, but it does support a much wider range of possible content.Base64 Encoding
If your data is largely non-text (ex: an image file), you don't have many options.
7bit
is off the table.8bit
andbinary
were unsupported prior to the MIME extension RFCs.quoted-printable
would work, but is really inefficient (every byte is going to be represented by 3 characters).base64
is a good solution for this type of data. It encodes 3 raw bytes as 4 US-ASCII characters, which is relatively efficient. RFC 1341 further limits the line length ofbase64
-encoded data to 76 characters to fit within an SMTP message, but that's relatively easy to manage when you're just splitting or concatenating arbitrary characters at fixed lengths.The big downside is that
base64
-encoded data is pretty much entirely unreadable by humans, even if it's just "plain" text underneath.