Joe Steele 77407eb5b7 Don't base64 encode attachments of type message/rfc822. ... The problem: Receive a message with an attachment of type message/rfc822 and forward it. When the message is sent, K-9 Mail uses base64 encoding for the attachment. (Alternatively, you could compose a new message and add such an attachment from a file using a filing-picking app, but that is not 100% effective because the app may not choose the correct message/rfc822 MIME type for the attachment.) Such encoding is prohibited per RFC 2046 (5.2.1) and RFC 2045 (6.4). Only 8bit or 7bit encoding is permitted for attachments of type message/rfc822. Thunderbird refuses to decode such attachments. All that is shown is the base64 encoded body. This commit implements LocalAttachmentBody.setEncoding. If an attachment to a newly composed message is itself a message, then setEncoding("8bit") is called, otherwise setEncoding("base64") is called for the attachment. Similar behavior occurs when an attachment is retrieved from LocalStore. The setEncoding method was added to the Body interface, since all implementations of Body now declare the method. The problem here differs from that in the preceding commit: Here, the encoding problem occurs on sending, not on receipt. Here, the entire message (headers and body) is base64 encoded, not just the body. Here, the headers correctly identify the encoding used; it's just that the RFC does not permit such encoding of attached messages. The problem here could in fact occur in combination with the preceding problem.		2013-09-03 19:52:11 -04:00
..
fsck/k9	Don't base64 encode attachments of type message/rfc822.	2013-09-03 19:52:11 -04:00
nobu_games/android/view/web	Replace tabs with spaces	2013-08-21 13:23:52 +02:00