Depending on whether a Body implements RawDataBody (which indicates the class
retains the original encoding) the helper method either strips the transfer
encoding or simply returns the result of Body.getInputStream().
This should restore the original functionality. So saving messages in the
database should work fine again.
AUTOMATIC = "Automatic"
PLAIN = "Normal password"
CRAM_MD5 = "Encrypted password"
SMTP also uses LOGIN. No localized text was associated with that because
a future commit will remove that option.
(The text is similar to that of Thunderbird's)
There's currently a bug in linkifyText() that can lead to a
StringIndexOutOfBoundsException when the text contains a
bitcoin URI and a "web" URI near the end of the text.
The error reporting assures an exception is thrown if
setKeyStoreFile(null) is called without a prior call to
setKeyStoreLocation(String directory).
Also, fix TrustManagerFactoryTest indentation.
Instead, have K9.onCreate initialize the location of the key
store file (similar to what is done with
BinaryTempFileBody.setTempDirectory).
Also, LocalKeyStore.getInstance has been changed so that it
no longer needs to be synchronized.
The classes are just as much related to com.fsck.k9.mail.transport
as com.fsck.k9.mail.store, so having them in
com.fsck.k9.mail.store doesn't seem appropriate.
Move LocalKeyStore to com.fsck.k9.security
Move TrustManagerFactory and TrustedSocketFactory to com.fsck.k9.net.ssl
Also, implement the ability to configure an alternate key store
file location. This permits the running of unit tests without
clobbering the live key store file.
Also, add a test to confirm that the key store file is being written
out and reread correctly.
Right now we happily accept every certificate in our local key store as long as
the hostname matches the certificate DN. So this test fails.
It's not a huge deal since the user accepted the certificate at one point. But we
want to do this right.
This builds upon the efforts started 2 commits back where \r\n is used for
all message text and \n is only used when the text is inside an
EolConvertingEditText widget.
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.)
Create .project files for all the Ecplipse projects
so they will all have project names and can
all be brought into Ecplipse together with a single
'File -> Import -> Android ->
Existing Android Code Into Workspace'.
(Not bothering to remove the .project exclusion from
all .gitignore files. Once the .project files are
checked in, they will no longer be ignored.)
Modify the top .project file so that Eclipse knows
k9mail's dependence on it plugins, and thus will
build everything in the correct order.
With the latest Android SDK Rev. 22, the top .classpath file
needs modification or else K9 will not run (see parent commit 53fcdd1).
But the initial import of k9mail into Eclipse works more cleanly if the
.classpath file doesn't exist on import, in which case Eclipse creates it
automatically. So rather than modify the .classpath file, remove it
from git and leave it untracked.
(For an existing Eclipse project, this commit will remove the file from
the working directory. A corrected version can be restored with:
git checkout 53fcdd1 .classpath
git rm --cached .classpath)
Add .classpath to the top .gitignore, now that no
.classpath files are being tracked (with one exception,
see below).
Create a tests/.classpath so that Java can find the k9mail
project in order to build the k9mail-tests project.
Dynamically generate the CSS style for <pre> elements
for inclusion in the HTML <head> element when messages
are displayed.
This permits a user to change their font-family preference
for plain text messages and see the results immediately.
Obviously any old locally-stored messages that had their
font-family stored with them will continue to display using
that font-family, irrespective of the user's current
preference setting.
