Don't convert the content-type to lower case in
MimeMessage.getContentType. The content-type may have optional parameters
that are case sensitive (boundary, name).
In removing the lower-case conversion from getContentType, a review was
made for inappropriate case-sensitive comparisons which use data obtained
with getContentType. The only ones found were in isMimeType in both
Message and MimeBodyPart.
Case-sensitive instances of isMimeType were made case-insensitive. Also,
isMimeType was moved from Message to MimeMessage for symmetry with
MimeBodyPart (MimeMessage & MimeBodyPart are similar and contain a good
bit of duplication such as this).
The unit test required fixing now that the case of the boundary text is
preserved.
References:
Commits 2c5186 and dc4002 added the toLowerCase to getContentType in
MimeMessage & MimeBodyPart (Issue 94).
Later, commit 50cd60 removed the toLowerCase addition from MimeBodyPart
(Issue 1289).
Fix the unit test to match.
All line endings in the unit test are now the same.
(Just for consistency. Not a big deal, since such problems are fixed when
the messages are run through EOLConvertingOutputStream.)
The preceding commit resulted in attachments of type message/rfc822 being
sent with 8bit encoding even when the SMTP server did not support
8BITMIME. This commit assures that messages will be converted to 7bit
when necessary.
A new interface CompositeBody was created that extends Body, and classes
Message and Multipart were changed from implementing Body to
CompositeBody. Additional classes BinaryTempFileMessageBody and
LocalAttachmentMessageBody were created (by extending BinaryTempFileBody
and LocalAttachmentBody, respectively), and they too implement
CompositeBody.
A CompositeBody is a Body containing a composite-type that can contain
subparts that may require recursive processing when converting from 8bit
to 7bit. The Part to which a CompositeBody belongs is only permitted to
use 8bit or 7bit encoding for the CompositeBody.
Previously, a Message was created so that it was 7bit clean by default
(even though that meant base64 encoding all attachments, including
messages). Then, if the SMTP server supported 8BITMIME,
Message.setEncoding("8bit") was called so that bodies of type TextBody
would been transmitted using 8bit encoding rather than quoted-printable.
Now, messages are created with 8bit encoding by default. Then, if the
SMTP server does not support 8BITMIME, Message.setUsing7bitTransport is
called to recursively convert the message and its subparts to 7bit. The
method setUsing7bitTransport was added to the interfaces Part and
CompositeBody.
setEncoding no longer iterates over parts in Multipart. That task belongs
to setUsing7bitTransport, which may in turn call setEncoding on the parts.
MimeUtility.getEncodingforType was created as a helper function for
choosing a default encoding that should be used for a given MIME type when
an attachment is added to a message (either while composing or when
retrieving from LocalStore).
setEncoding was implemented in MimeBodyPart to assure that the encoding
set in the Part's headers was the same as set for the Part's Body. (The
method already existed in MimeMessage, which has similarities with
MimeBodyPart.)
MimeMessage.parse(InputStream in, boolean recurse) was implemented so that
the parser could be told to recursively process nested messages read from
the InputStream, thus giving access to all subparts at any level that may
need to be converted from 8bit to 7bit.
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.
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.
Currently, K-9 Mail detects if an SMTP server supports 8BITMIME (RFC
6152), and if so, TextBody parts are sent with content-transfer-ecoding =
8bit. Otherwise, they are sent using quoted-printable.
This adds the required "BODY=8BITMIME" parameter to the MAIL command when
sending messages to servers that support 8BITMIME.
This isn't the best solution. Most of the developers agree that a right-aligned
triangle or arrow would be a better fit for such an indicator. But we currently
don't have the time to write the code to do it.
Personally, I think we should try to get rid of submenus altogether.
The build.xml script was failing if there wasn't already a gh-pages
branch in the local git repo.
Changes:
Fetch the origin/gh-pages branch.
Create a temporary "gh-pages-tmp" branch using origin/gh-pages as the
starting point. And then as before, copy the changelog to the branch,
push the branch back to origin, and finally delete the temporary branch.
Added more comments to the script.
Ref: comments on Github attached to commit k9mail/k-9@09c27d9.
The new method is a little bit janky, but a little bit of jank is better than 2n
heavy SQL count queries per folder before we even show the folder list.
On my 200 folder account, display of the folder list activity drops from 10+s to
< 1s
If you attempted to use SSL to connect to a server that speaks
STARTTLS, you should get an SSL protocol error. Instead, you
were likely to get an "Unrecognized Certificate" error that shows
you an unrelated certificate chain and asks you to accept it or
reject it. Neither action would work because the actual problem
had nothing to do with certificates. The unrelated certificate
chain that popped up had been statically stored when validating
a prior connection to a different server.
With this patch, certificate chains are no longer stored statically
when validating server connections.
Issue 5886 is an example of a user experiencing this problem.
