Issue 5734 exemplifies the problem: receive a message with an attachment
of type message/rfc822 that doesn't use base64 encoding for the body of
the attached message. K-9 Mail incorrectly stores the attached message
locally with its original headers but using base64 encoding for the body.
A discrepancy thus exists between what the headers say about the encoding
of the body versus the actual encoding used. This is obvious when
attempting to view the attachment (either by using a compatible message
viewer available on the device or by saving the attachment to a file and
viewing the file contents).
The process: When a message with an attached sub-message is received,
Message.parse puts the attachment in a new MimeMessage with the
attachment's body in a BinaryTempFileBody. LocalFolder.saveAttachment
then calls Message.writeTo (which later calls BinaryTempFileBody.writeTo)
to place the entire attachment (headers and body) in a new file that will
become a LocalAttachmentBody. Until now, BinaryTempFileBody.writeTo
could only save the message body using base64 encoding.
This commit implements BinaryTempFileBody.setEncoding and assures that the
body is written out with the same encoding that was found in its headers.
Previously, <html>, <head>, & <body> tags were
attached to messages before they were stored locally.
But now that the <head> element also needs to include
a <meta> element (for proper MessageWebView display),
it seems unecesary to store all these tags with each
message.
Now the tags are no longer stored with the messages. Instead,
MessageWebView applies the tags before displaying the message.
This also eliminates the need to upgrade an older
message database where all the old messages would have
otherwise needed to be wrapped with the new tags.
This is necessary because we save the offset and length of the user-
supplied text in the identity header. These values are then later used
to split the draft in user text and quoted message.
When calculating these values we operate on a string with LF line
endings. Ideally we want to do the reverse operation on the same
string, but when saving the message to the server LF is converted to
CRLF to create RFC-conforming messages.
This is only a hack and will probably be the cause of more trouble in
the future. A better solution would be to make the identity header more
robust or get rid of it entirely.
with an enclosed URI with a content type of application/x-k9settings.
This allows a user to bootstrap K-9 Mail configuration by email a
settings file from one device to another, perhaps using a GMail
account on the receiving end.
