It can be a bit dense to read, but the "Content-Transfer-Encoding" section of RFC 1341 has all of the details:
The situation kinda goes from bad to worse. Here's my summary:
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 header describe the rule that you've chosen to solve this problem.
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 , 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, 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 eyeball content and make sense of it. The idea here is that if you're just writing in "plain English text" you'll be fine.
Use the Shell to configure the content transfer encoding method for the organization
But that wasn't true in 2005 and it isn't true today.
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 with , there's still a 1000-character line limit.
, just like , 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 , since it gives you more freedom in your content. However, RFC 1341 contains this tidbit:
As of the publication of this document, there are no standardized Internet transports for which it is legitimate to include unencoded 8-bit or binary data in mail bodies. Thus there are no circumstances in which the "8bit" or "binary" Content-Transfer-Encoding is actually legal on the Internet.
RFC 1341 came out over 20 years ago.
What is Base64?
Since then we've gotten 8bit MIME Extensions in RFC 6152. But even then, line limits still may apply:
Note that this extension does NOT eliminate the possibility of an SMTP server limiting line length; servers are free to implement this extension but nevertheless set a line length limit no lower than 1000 octets.
is the same as , except that there's no line length restriction.
You can still include any characters you want, and there's no extra encoding.
Please Whitelist This Site?
Similar to , RFC 1341 states that it's not really a legitimate encoding transfer encoding. RFC 3030 extended this with .
Before the extension, there needed to be a way to send content that couldn't be over SMTP.
HTML files (which might have more than 1000-character lines) and files with international characters are good examples of this.
The encoding (Defined in Section 5.1 of RFC 1341) is designed to handle this.
It does two things:
- Defines how to escape non-US-ASCII characters so that they can be represented in only 7-bit characters. (Short version: they get displayed as an equals sign plus two 7-bit characters.)
- Defines that lines will be no greater than 76 characters, and that line breaks will be represented using special characters (which are then escaped).
Quoted Printable, because of the escaping and short lines, is much harder to read by a human than or , but it does support a much wider range of possible content.
If your data is largely non-text (ex: an image file), you don't have many options.
is off the table.
and were unsupported prior to the MIME extension RFCs. would work, but is really inefficient (every byte is going to be represented by 3 characters).
What do you need to know before you begin?
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 of -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 -encoded data is pretty much entirely unreadable by humans, even if it's just "plain" text underneath.
answered Feb 15 '15 at 22:03
40.5k4444 gold badges142142 silver badges194194 bronze badges