Good morning everybody.
I recieve a lot of letter with
Content-Transfer-Encoding: QUOTED-PRINTABLE in the header. No other character encoding information. The message shows up with =00 - =FF strings instead of proper accented characters. For exemple it shows Ha m=E1r a men=FCv=E1laszt=E1sn=E1l tartunk instead of Ha már a menüválasztásnál tartunk Whatever I set in the options, or playing with character sets, I can not force Thunderbird to display correctly these messages. The same messages are displayed correctly in Outlook Express. Please correct this problem in the next release. Thnx.
I have a problem with mail attachements which have the Content-Transfer-Encoding „quoted-printable“.
I use an Email file myEMail.eml with an attachment (myPDF.pdf), generated with Windows Live Mail.
Content-Type: application/pdf;
name='=?utf-8?B?0JPQvtGA0LHQsNGH0ZHQsiwg0JzQuNGF0LDQuNC7INCh0LXRgNCz0LXQtQ?=
=?utf-8?B?0LLQuNGHIChPUklHSU5BTCkucGRm?='
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename='=?utf-8?B?0JPQvtGA0LHQsNGH0ZHQsiwg0JzQuNGF0LDQuNC7INCh0LXRgNCz0LXQtQ?=
=?utf-8?B?0LLQuNGHIChPUklHSU5BTCkucGRm?='
In our scenario, we remove all attachmens and store the „raw“ EML and the attachments separately.
Then if I merge the mail and add the attachments with the original attributes, the PDF is corrupted and can’t be opened.
A comparison of the original EML and the merged shows many differences at the attached PDF (but the separate stored PDF is byte indentically with the PDF from the original EML).
If I use „base64“ as Content-Transfer-Encoding, everything will be fine, of course.
But I need to restore the EML with the original attributes.
Is there anyone who knows of this beaviour?
Many thanks
Dirk
Code snippet for adding attachments
EMLDatasource ds = new EMLDatasource(tmpBlob, null,
contetType);
BodyPart messageBodyPart = new MimeBodyPart();
messageBodyPart.setDataHandler(new DataHandler(ds));
// if ('quoted-printable'.equals(transferEncoding) true) {
// transferEncoding = 'base64';
messageBodyPart.setHeader(CONTENT_TRANSFER_ENCODING,
transferEncoding);
messageBodyPart.setDescription(description);
messageBodyPart.setDisposition(disposition);
Sumita arora class 12 book pdf. To find more books about computer science sumita arora class 12, you can use related keywords: Similar Books to computer science sumita arora class 12. Copyright Disclaimer: All books are the property of their respective owners.
messageBodyPart.setHeader(CONTENT_ID, contentID);
messageBodyPart.setHeader(CONTENT_TYPE, contetType);
Multipart mp.addBodyPart(messageBodyPart);
Code snippet for storing EML
CustomizedMimeMessage message = new CustomizedMimeMessage(
null, emlBlob.getInputStream(true));
message.saveChanges();
OutputStream out = blob.getOutputStream();
try {
message.writeTo(out);
} finally {
if (out != null) {
out.close();
}
}
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?
mahimahi
1 Answer
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
Content-Transfer-Encoding header describe the rule that you've chosen to solve this problem.
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 eyeball 7bit 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 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 7bit , there's still a 1000-character line limit.
8bit , just like 7bit , 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:
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. 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.
binary is the same as 8bit , except that there's no line length restriction. You can still include any characters you want, and there's no extra encoding. Similar to 8bit , RFC 1341 states that it's not really a legitimate encoding transfer encoding. RFC 3030 extended this with BINARYMIME .
Before the
8BITMIME extension, there needed to be a way to send content that couldn't be 7bit over SMTP. HTML files (which might have more than 1000-character lines) and files with international characters are good examples of this. The quoted-printable encoding (Defined in Section 5.1 of RFC 1341) is designed to handle this. It does two things:
Content Transfer Encoding 7bit
Quoted Printable, because of the escaping and short lines, is much harder to read by a human than
7bit or 8bit , 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.
7bit is off the table. 8bit and binary 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 of base64 -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.
Craig WalkerCraig Walker
Not the answer you're looking for? Browse other questions tagged emailencodingheadertransfer or ask your own question.Comments are closed.
|