We now no longer parse the exception message in MessagingController to find
out if it was a permanent SMTP failure.
Overall the code is still a mess, but the error handling should be a little
bit better and more readable now.
Opening such messages during download will display "No text" and (probably
due to a bug) might lead to the synchronization process being aborted. Instead
of fixing the UI issue we now don't write these incomplete messages to the
database. This has the potential to massively speed up the sync process. But
it will take longer for messages to show up in the message list, especially
with slow connections.
#619 "Add android wear support"
No reply with voice yet (as requested in the ticket).
No user-configurable actions yet, just delete+archive+spam
No stacked notification for multiple messages yet.
1a20ca06f1 connected a WebViewClient
to the WebView. But as soon as a client is connected, the WebView
stops handling links itself and tries to display everything on
its own.
Override shouldOverrideUrlLoading() and replicate what Android's
default WebView does if no WebViewClient is connected to work
around this.
This fixes#587.
Throughout the code we make the assumption that onPrepareActionMode() is
called right after starting the action mode. However, this is not the case on
Android 5.1.
With this change we call ActionMode.invalidate() right after starting the
action mode which causes onPrepareActionMode() to be invoked.
Throughout the code we make the assumption that onPrepareActionMode() is
called right after starting the action mode. However, this is not the case on
Android 5.1.
With this change we call ActionMode.invalidate() right after starting the
action mode which causes onPrepareActionMode() to be invoked.
simplify and add logging
simplify
use == for enum comparison to avoid type mistakes
enum name needs to match previous constant
simplify
Address review comments - formatting, and remove superfluous comment
Shorten DeletePolicy values since not used in settings strings; import enums to reduce clutter
fix whitespace
remove comment per review
address review comment
review comments
remove another superfluous qualification
Last changes
- onPrepareActionMode must be called before computeBatchDirection
because computeBatchDirection ends up referencing mMarkAsRead /
mMarkAsUnread and mFlag / mUnflag which could be null otherwise.
Before downloading we show the encoded size of attachments. After download we
strip the transport encoding to find out the size of the decoded content.
This will correctly set the MIME type of the part containing the body.
Otherwise multiparts end up having a content type of text/plain (default)
in the database... oops.
Using
<meta http-equiv="Refresh" content="1; URL=http://example.com/">
in a HTML message causes WebView to load the URL in the default browser.
Overriding WebViewClient.shouldOverrideUrlLoading() allows us to cancel
loading this URL. Sadly, I found no way to find out whether the method was
called because of a meta refresh or because the user clicked on a link.
So now we're using HtmlCleaner to parse the HTML and remove all "meta" elements
containing an "http-equiv" attribute with a value of "refresh".
We have been throwing away all attachments already, so it doesn't make
too much sense to keep local messages. And when we're not keeping local
messages we can remove all entries from the 'threads' table.
This change breaks all kinds of things, e.g.
- deleting messages
- updating messages
- downloading attachments
- deleting attachments
- searching in message bodies
946565347a passed 'this' to
getTextFromPart() which could be a multipart. This caused
all multipart messages to show 'No text' as the body.
Fix it by passing it the correct 'part' that was found.
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.
Add vector versions for some notification icons (yay Illustrator)
Add comments reminding people to add their settings to GlobalSettings.
<plurals> support for notification_new_messages_title
Not sure why #ffffffff is resulting in black with targetSdk 17.
An interrupted connection attempt to the server yields an SSLException
as well, like this:
E/k9 ( 6937): Caused by: javax.net.ssl.SSLHandshakeException: Connection closed by peer
E/k9 ( 6937): at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(Native Method)
E/k9 ( 6937): at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:302)
E/k9 ( 6937): at com.android.org.conscrypt.OpenSSLSocketImpl.waitForHandshake(OpenSSLSocketImpl.java:598)
E/k9 ( 6937): at com.android.org.conscrypt.OpenSSLSocketImpl.getInputStream(OpenSSLSocketImpl.java:560)
E/k9 ( 6937): at com.fsck.k9.mail.store.ImapStore$ImapConnection.open(ImapStore.java:2459)
We don't want the user to notify of 'certificate problems' in that case.
Fix it by checking whether the SSLException was actually triggered by a
CertificateException.
First we try the original MIME type unless it's application/octet-stream.
Then we try the MIME type inferred from the attachment's file extension.
Then we fall back to application/octet-stream.
In all cases we first try the content:// URI, then a file:// URI.
In order for Android to find apps that are capable of opening an attachment for
viewing the ACTION_VIEW Intent needs to contain an appropriate MIME type.
Ideally, we'd use the MIME type specified for the attachment in the message.
But often the supplied MIME type is wrong/useless. So we look at the file
extension to try to come up with a sensible MIME type on our own. We then go
on to ask Android which of the two MIME types leads to more apps claiming to
be able to open our attachment for viewing and use that one.
Without this building with Gradle adds a 'maxSdkVersion' attribute to the manifest. This seems to cause the targetSdkVersion value being ignored. And with a targetSdkVersion value lower than 16 the permissions READ_CONTACTS/WRITE_CONTACTS imply READ_CALL_LOG/WRITE_CALL_LOG. But we don't need/want those permissions.
This bug was present in the Gallery app shipped with Android 2.0.
The time has come to say good-bye. We will never forget you! But only because you're part of our Git history.
Caching is beneficial because it can eliminate redundant cryptographic
computations and network traffic when re-establishing a connection to
the same server, thus saving time and conserving power.
SslHelper has been removed, and its functionality has been transferred
into TrustedSocketFactory. The added layer of indirection wasn't really
simplifying anything. It's now easier to see what happens when
createSocket() is invoked.
A new instance of SecureRandom is no longer passed to SSLContext.init().
Instead, null is passed.
The (default) provider of the TLS SSLContext used is OpenSSLProvider,
which provides an SSLSocket instance of type OpenSSLSocketImpl. The only
use of SecureRandom is in OpenSSLSocketImpl.startHandshake(), where it is
used to seed the OpenSSL PRNG with additional random data. But if
SecureRandom is null, then /dev/urandom is used for seeding instead.
Meanwhile, the default provider for the SecureRandom service is
OpenSSLRandom, which uses the OpenSSL PRNG as its data source. So we were
effectively seeding the OpenSSL PRNG with itself. That's probably okay
(we trust that the OpenSSL PRNG was properly initialized with random data
before first use), but using /dev/urandom would seem like a better source
(or at least as good a source) for the additional seed data added with
each new connection.
Note that our PRNGFixes class replaces the default SecureRandom service
with one whose data source is /dev/urandom for certain vulnerable API
levels anyway. (It also makes sure that the OpenSSL PRNG is properly
seeded before first use for certain vulnerable API levels.)
For support of the dark and light themes.
Also:
Redefine mFolded and call it mIsFolded. Previously,
the view started with mFolded = false (which implies to me
the initial state is unfolded) and yet the view
started in a folded state, which seemed contradictory.
Create updateFoldedState() with code from onClick() (In
preparation for subsequent commit.)
It only applied to pre-ICS devices.
ConnectivityManager.ACTION_BACKGROUND_DATA_SETTING_CHANGED is no longer
broadcast.
ConnectivityManager.getBackgroundDataSetting() always returns true.
This was dead code. The exception message will always start with either
"SMTP response is 0 length" from checkLine() or else "Negative SMTP reply"
from NegativeSmtpReplyException().
The problem originated from way back before 4.904.
The constructor now saves the certificate chain, so the code to retrieve
it again or to perform any additional error checking in
getCertificateChain() is no longer needed.
The constructor now retrieves and saves the private key so that any
resulting errors are detected sooner.
Methods that retrieve the alias perform checks to assure that the client
cert. satisfies the requested issuers and key type. It's known that
Sendmail may provide a list of issuers in its certificate request, but
then may authenticate against a much larger set of CAs, but then later
reject the mail because the client certificate was not acceptable.
Vetting against the issuer list helps detect such certificate problems
sooner (upon connection) rather than later (upon transmission of mail).
Earlier error detection is necessary so that errors may be presented to
the user during account setup.
Portions of these modifications are based on code from KeyManagerImpl:
https://android.googlesource.com/platform/external/conscrypt/+/master/src/main/java/org/conscrypt/KeyManagerImpl.java
Move KeyChainKeyManager to com.fsck.k9.net.ssl because it is used by
SslHelper and because the class extends X509ExtendedKeyManager, which is
in javax.net.ssl.
The problem can be observed if, when modifying the outgoing server
settings, you change the state of the mRequireLoginView check box,
then change the screen orientation.
This is necessary because the OnCheckChanged listener (which
normally updates the view visibility) is not yet set. (The listeners
are set up after view initialization so that they only fire on
user input.)
It should not be triggered when the instance state is restored
with an AuthType spinner selection of EXTERNAL.
The logic here for the AuthType spinner is similar to that of
the parent commit for the SecurityType spinner.
The problem: begin modifying the server settings by changing the security
type (which will change the port to a default value), then change the port
to a custom value, then change screen orientation. The default port value
is restored, wiping out the custom value.
When onRestoreInstanceState() is called, the custom port value is
restored. But the spinner doesn't actually restore its state at that
time. Instead, it waits until View.layout(), at which time it posts a
runnable to call onItemSelected() if the restored state doesn't match the
state initialized in onCreate(). When onItemSelected() is eventually run
sometime later, it wipes out the custom port value that was restored.
The solution is to keep track of the spinner state ourselves and only
revert the port to a default when we see the spinner state changed by the
user.
This problem goes back to 4.904 and before.
For convenience. Implemented in onCheckChanged().
As a consequence, onCheckChanged() must not be triggered when the instance
state is restored (would occur if the check box state was checked when
saved), otherwise the certificate chooser would pop up once the state was
restored. Therefore, all listeners have been moved into
initializeViewListeners() which is invoked after the state has been
restored.
Because onCheckChanged() is no longer triggered in
onRestoreInstanceState(), updateViewVisibility() was implemented to
restore the view visibility.
This is done when the SASL EXTERNAL mechanism isn't advertised (indicating
the possibility that the server did not accept the client certificate) or
when the command for authenticating with SASL EXTERNAL fails.
The CertificateValidationException will trigger a notification to the user
that there's an authentication problem that needs addressing.
Also, there were instances where CertificateValidationException was being
thrown with a new CertificateException as the cause for the purpose of
notifying the user when STARTTLS is not available. This has been slightly
simplified by eliminating the need to include a new CertificateException
as a cause.
If the alias is empty or null, don't bother using KeyChainKeyManager.
If the alias is not empty, confirm that it is associated with a
certificate, otherwise throw a CertificateValidationException
which will notify the user of the problem and ask the user to
check the server settings.
Likewise, the user is notified if the client certificate was
not accepted by the server.
If the user chooses client certificate authentication,
immediately pop up the certificate chooser.
If the user chooses password authentication, move the focus to the
password View.
With this commit, KeyChainKeyManager no longer throws the exception and
AccountSetupCheckSettings no longer catches it.
It was being thrown when the server requested a client certificate but no
client certificate alias had been configured for the server.
The code was making the incorrect assumption that the server would only
request a client certificate when such a certificate was *required*.
However, servers can be configured to accept multiple forms of
authentication, including both password authentication and client
certificate authentication. So a server may request a certificate without
requiring it. If a user has not configured a client certificate, then
that should not be treated as an error because the configuration may be
valid and the server may accept it.
The only indication that a certificate is *required* is when a
SSLProtocolException is thrown, caused by a SSLHandshakeException
resulting from a fatal handshake alert message received from the server.
Unfortunately, such a message is fairly generic and only "indicates that
the sender was unable to negotiate an acceptable set of security
parameters given the options available." So there is no definitive way to
know that a client certificate is required.
Also, KeyChainKeyManager.getCertificateChain() and getPrivateKey() no
longer throw IllegalStateException(). These methods are permitted to
return null, and such a response is appropriate if the user has deleted
client certificates from the device. Again, this may or may not cause the
server to abort the connection, depending on whether the server *requires*
a client certificate.
The app's minSdkVersion = 15 (Android 4.0.3, Ice Cream Sandwich MR1),
so there's no need to test the API level.
This also removes '@SuppressLint("TrulyRandom")'. I find no
documentation for it, nor do I find any additional lint errors
with its removal.
The user may toggle the checkbox, and then decide to toggle it again.
This also fixes a problem when restoring the activity state. When the
checkbox was restored as checked, the listener was firing and wiping the
the restored alias.
Previously, with settings of Security=SSL and authentication=certificate,
attempting to change Security=None would (of course) be blocked. So
Security would remain SSL. But the authentication options would then
include "Password, transmitted insecurely", whereas the option should
have remained as "Normal password" (because the security remained SSL).
The problem could have been fixed with a simple shuffling in
updatePortFromSecurityType() so that updateAuthPlainTextFromSecurityType()
was invoked before mPortView.setText(), but the logic for requiring that
ordering was not plain to see. (Although no longer necessary, the
shuffling was done as well.)
Add test for username == "".
Without it, the mRequireLoginView remains checked, and the empty username
and password boxes are not hidden.
The problem occurs if importing an SMTP server that has an
authenticationType, but no username or password (i.e., no authentication
required).
That's the way settings were exported in 4.904 and before.
Occurs when the SMTP server doesn't require authentication
(authenticationType == null).
The javadoc for ServerSettings says that both authenticationType and
connectionSecurity may be null.
The referenced issue states that it is only applicable to Android < 4.2
(testing confirms the problem on 4.1.2, but not on 4.2.2).
A test was added for the version code, primarily as a finder's aid for a
day when K-9 Mail no longer supports Android < 4.2 and the work-around can
be removed.
The referenced issue also states that it is only necessary to hold a
reference to the first PrivateKey retrieved. (Testing indicates that the
problem is avoided so long at least one reference is always maintained to
a PrivateKey -- it doesn't actually need to be a continuous reference to
the first PrivateKey.)
From my understanding, a normal class loader never unloads a class, so the
static reference can be safely kept privately in KeyChainKeyManager.
This only changes the vertical display order of the widgets.
The user will likely review the settings from top to bottom, but
the way they were previously arranged, settings lower on the list
were affecting things higher on the list.
Generally show top to bottom:
Server
security type
port (affected by security type above)
require login checkbox (SMTP only, affects everything below)
user
auth. type (affected by security type above, affects everything below)
password (affected by auth. type above)
client cert (affected by auth. type above)
In response to Issue 1794,
- add a configuration option in the account preferences to show
notifications only for 1st/2nd/etc class folders
- add an option in the folder preferences to set the notification class
as 1st, 2nd or inherited from the folder's push class
The default behaviour remains unchanged.
E/AndroidRuntime(25655): FATAL EXCEPTION: main
E/AndroidRuntime(25655): Process: com.fsck.k9, PID: 25655
E/AndroidRuntime(25655): java.lang.NullPointerException
E/AndroidRuntime(25655): at com.fsck.k9.view.MessageOpenPgpView.handleError(MessageOpenPgpView.java:385)
E/AndroidRuntime(25655): at com.fsck.k9.view.MessageOpenPgpView.access$3(MessageOpenPgpView.java:384)
E/AndroidRuntime(25655): at com.fsck.k9.view.MessageOpenPgpView$DecryptVerifyCallback.onReturn(MessageOpenPgpView.java:357)
E/AndroidRuntime(25655): at org.openintents.openpgp.util.OpenPgpApi$OpenPgpAsyncTask.onPostExecute(OpenPgpApi.java:195)
E/AndroidRuntime(25655): at org.openintents.openpgp.util.OpenPgpApi$OpenPgpAsyncTask.onPostExecute(OpenPgpApi.java:1)
E/AndroidRuntime(25655): at android.os.AsyncTask.finish(AsyncTask.java:632)
E/AndroidRuntime(25655): at android.os.AsyncTask.access$600(AsyncTask.java:177)
E/AndroidRuntime(25655): at android.os.AsyncTask$InternalHandler.handleMessage(AsyncTask.java:645)
E/AndroidRuntime(25655): at android.os.Handler.dispatchMessage(Handler.java:102)
E/AndroidRuntime(25655): at android.os.Looper.loop(Looper.java:136)
E/AndroidRuntime(25655): at android.app.ActivityThread.main(ActivityThread.java:5128)
E/AndroidRuntime(25655): at java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime(25655): at java.lang.reflect.Method.invoke(Method.java:515)
E/AndroidRuntime(25655): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:795)
E/AndroidRuntime(25655): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:611)
E/AndroidRuntime(25655): at dalvik.system.NativeStart.main(Native Method)
Specifically, warn and block them when attempting to configure Client
Certificate Authentication in combination with Connection Security = None.
If this were not made obvious to the user, they might not understand why
they are not permitted to tap "Next".
Also, move the initialization of all view listeners out of onCreate() into
initializeViewListeners() which is then called near the end of onCreate(),
helping to assure that the listeners won't be triggered during the
initialization of views inside onCreate().
Previously, it was possible to have "Require sign-in" unchecked and a
"Security = None" setting for the outgoing server and still not be able to
tap "Next" because of a hidden (and irrelevant) "Authentication = Client
certificate" setting.
Check that the user has actually chosen a client certificate in
AccountSetupOutgoing.validateFields().
Also, there's no need to clear the password and certificate fields when
hiding them. The user may accidentally change settings and want to change
them back without wiping out the existing settings.
Leave the hostname == null checks so we can fall back if a hostname is not
found. Also convert message-id to upper case to match Apple Mail (for
privacy).
I wrote this fix to avoid obviously specifying that I am using a mobile device
to reply to an email.
Others want this for ease of filtering messages from their host by Message-ID.
E/StrictMode(9278): A resource was acquired at attached stack trace but never released. See java.io.Closeable for information on avoiding resource leaks.
E/StrictMode(9278): java.lang.Throwable: Explicit termination method 'close' not called
E/StrictMode(9278): at dalvik.system.CloseGuard.open(CloseGuard.java:184)
E/StrictMode(9278): at android.os.ParcelFileDescriptor.<init>(ParcelFileDescriptor.java:179)
E/StrictMode(9278): at android.os.ParcelFileDescriptor.<init>(ParcelFileDescriptor.java:168)
E/StrictMode(9278): at android.os.ParcelFileDescriptor.createPipe(ParcelFileDescriptor.java:362)
E/StrictMode(9278): at org.openintents.openpgp.util.ParcelFileDescriptorUtil.pipeFrom(ParcelFileDescriptorUtil.java:34)
E/StrictMode(9278): at org.openintents.openpgp.util.OpenPgpApi.executeApi(OpenPgpApi.java:222)
E/StrictMode(9278): at org.openintents.openpgp.util.OpenPgpApi$OpenPgpAsyncTask.doInBackground(OpenPgpApi.java:189)
E/StrictMode(9278): at org.openintents.openpgp.util.OpenPgpApi$OpenPgpAsyncTask.doInBackground(OpenPgpApi.java:1)
E/StrictMode(9278): at android.os.AsyncTask$2.call(AsyncTask.java:288)
E/StrictMode(9278): at java.util.concurrent.FutureTask.run(FutureTask.java:237)
E/StrictMode(9278): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
E/StrictMode(9278): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
E/StrictMode(9278): at java.lang.Thread.run(Thread.java:841)
E/AndroidRuntime(24914): FATAL EXCEPTION: main
E/AndroidRuntime(24914): Process: com.fsck.k9, PID: 24914
E/AndroidRuntime(24914): java.lang.NullPointerException
E/AndroidRuntime(24914): at org.openintents.openpgp.util.OpenPgpServiceConnection.<init>(OpenPgpServiceConnection.java:35)
E/AndroidRuntime(24914): at com.fsck.k9.view.MessageOpenPgpView.updateLayout(MessageOpenPgpView.java:115)
E/AndroidRuntime(24914): at com.fsck.k9.view.SingleMessageView.setMessage(SingleMessageView.java:623)
E/AndroidRuntime(24914): at com.fsck.k9.fragment.MessageViewFragment$Listener$2.run(MessageViewFragment.java:602)
E/AndroidRuntime(24914): at android.os.Handler.handleCallback(Handler.java:733)
E/AndroidRuntime(24914): at android.os.Handler.dispatchMessage(Handler.java:95)
E/AndroidRuntime(24914): at android.os.Looper.loop(Looper.java:136)
E/AndroidRuntime(24914): at android.app.ActivityThread.main(ActivityThread.java:5081)
E/AndroidRuntime(24914): at java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime(24914): at java.lang.reflect.Method.invoke(Method.java:515)
E/AndroidRuntime(24914): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:791)
E/AndroidRuntime(24914): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:607)
E/AndroidRuntime(24914): at dalvik.system.NativeStart.main(Native Method)
This gives the openpgp-api-library an Eclipse
project name consistent with the names used for
the other plugins. This helps with initial
project setup and avoids project naming collisions.
* max-instatement-indent:
The valid value is 40 thru 120.
* brackets=attach:
We should change the brackets options to the style option in v2.02 or later.
For more detail, see the http://astyle.sourceforge.net/news.html.
Change the translated strings files to a format similar to what
Transifex exports. This should make it easier to see the content changes
when translations are pulled from Transifex for the first time.
Instead of interpreting a "-" at the beginning of a line as
an error response, consider the absence of a "+" at the
beginning of a line as an error response.
This is what Thunderbird does.
http://hg.mozilla.org/releases/comm-esr24/file/55e96a433bd1/mailnews/local/src/nsPop3Protocol.cpp#l1177
The problem arises with godaddy servers spewing additional
lines of data upon login failure. The login was being
interpreted as successful, and a STAT commanded was subsequently
being sent, resulting in a dialog saying 'Cannot connect to
server. (Invalid int: "auth_error:")'.
$ openssl s_client -quiet -crlf -connect pop.secureserver.net:995
...
+OK <24984.1394317012@pop.secureserver.net>
user testuser
+OK
pass testpass
testuser not found in the auth database
warning: auth_error: authorization failed (no such object)
-ERR authorization failed Check your server settings.
Some IMAP servers are broken and don't correctly handle string
literals with the LOGIN command.
This switches to using quoted strings instead.
This is what Thunderbird does.
Error messages were not being put in the folder because of a problem with
how loopCatch was being handled.
It looks like this problem goes back to commit 5aea9e7.
Additional device info has been added to the error messages.
Also, now the feature is only enabled in debug mode.
getName() shows the user's name from the first identity for the account.
What we really want is getDescription(), which is the account name that
shows in the account list.
If an error occurs while connecting for push (for example, if the server's
certificate fails authentication), several more attempts will be made to
connect, then finally all attempts will cease.
This commit makes it so that pushers are restarted if the user goes in and
edits the server settings (presumably because the user was notified of a
problem and is attempting to fix it). Without this, the user could fix
the problem and would still not receive email via push.
These options originated in the AOSP email client from which K-9 Mail was
forked. They provide an odd combination of 2 features:
1. Don't bother to authenticate the server's certificate (applies to both
SSL/TLS and STARTTLS); i.e., blindly accept all certificates. This is
generally a bad security policy which is susceptible to MITM attacks.
2. If STARTTLS is selected but the server doesn't claim to support
STARTTLS, then proceed without using encryption. This, too, is a bad
security policy which is susceptible to MITM attacks.
Since the time that K-9 Mail was forked, a couple things have changed:
> K-9 Mail has implemented the ability for users to review and permanently
accept individual certificates that would otherwise fail authentication.
With this ability, there is no need for a user to subject themselves to
the ongoing risks of feature 1. above. Hence, this commit removes feature
1.
> The AOSP email client has changed its behavior and no longer permits a
security downgrade to an unencrypted connection if the server doesn't
claim to support STARTTLS (i.e., they eliminated feature 2. above). K-9
Mail should do the same. It's unlikely that a server is going to provide
STARTTLS on an intermittent basis, so providing a contingency for such
unusual behavior is an unnecessary risk. Hence, this commit removes that
feature as well.
Effect on existing users:
If the old connection security setting was "SSL/TLS (if available)" (which
now gets remapped to "SSL/TLS"), and the server does not provide a
certificate that can be authenticated, then a "Certificate error for
<account name>" notification is generated telling the user to check their
server settings. Tapping the notification takes the user to the relevant
server settings, where the user can tap "Next" to review the certificate
and choose to permanently accept it. This process would occur during the
first syncing of folders after application upgrade or (in the case of
SMTP) during the first attempt to send a message.
If the connection security setting was "STARTTLS (if available)" (which
now gets remapped to "STARTTLS"), and the server does not provide a
certificate that can be authenticated, then the same process as above
would occur.
If the old connection security setting was "STARTTLS (if available)", and
the server doesn't claim to support STARTTLS, then the user would get a
certificate error notification which would lead them to the server's
settings. There they would need to choose a different connection security
-- most likely "NONE". If they didn't change anything but instead just
tapped "Next", the server settings would be checked again and a dialog
would pop up saying, "Cannot connect to server. (STARTTLS connection
security not available)". (The implementation of notifications when
STARTTLS is not available is not actually included here -- it's in the
commit that follows.)
Regarding the changes to providers.xml: in cases where the scheme ended
with "+ssl", the schemes were simply updated by appending "+". In cases
where the scheme ended with "+tls", a check of the server was made to
assure that STARTTLS was available before appending "+" to the scheme.
Domains paran.com and nate.com failed the check and were removed because
no current information could be found. Domains me.com and mac.com also
failed and were updated based on http://support.apple.com/kb/ht4864.
Previously, if a server's certificate failed authentication while
connecting for push (if, for example, the certificate had expired), then
the attempt to connect would fail, and another attempt would be tried
later. After a certain number of failed attempts, no further attempts
would be made. Meanwhile, the user is oblivious to the failures, and it
could be quite some time before the user realizes that they are not
getting email. Even when they do realize it, they would not know the
cause.
With this commit, users receive a notification when such failures occur
while connecting for push. (These notifications are already generated
with failures while polling.) Tapping the notification will take the user
to the relevant server settings where they can choose to accept the
certificate.
Applicable for strings not intended for user consumption.
A %d string format code can generate eastern-arabic numerals
for users with an arabic locale.
V/k9 (20763): conn1103774136>>> 5 UID SEARCH ٦٤٦:٦٧٠ NOT DELETED
V/k9 (20763): conn1103774136<<<#5# [BAD, Invalid Search criteria]
E/k9 (20763): synchronizeMailbox
E/k9 (20763): com.fsck.k9.mail.store.ImapStore$ImapException: Command: UID SEARCH ٦٤٦:٦٧٠ NOT DELETED; response: #5# [BAD, Invalid Search criteria]
When sending a command it would be sent like this:
PKG1: 1 STARTTLS
PKG2: \r\n
Some imap proxys (maybe from Fortinet?) don't accept commands across packets:
PKG1: 1 STARTTLS\r\n
The naturalize tool detected that using "identity" is more consistent
with the current codebase state:
* "identity" in SettingsImporter is 78.46% probable ("identitiy" 21.54%)
The naturalize tool detected that using "tokenizer" is more consistent
with the current codebase state:
* "tokenizer" in MessageCompose is 60.40% probable ("tokens" 39.60%)
The naturalize tool detected that using "localFolder" is more consistent
with the current codebase state:
* "localFolder" in MessageListFragment is 76.31% probable ("local_folder" 23.69%)
The naturalize tool detected that using "sizeParam" is more consistent
with the current codebase state:
* "sizeParam" in LocalStore is 22.89% probable ("s" 10.52%)
The naturalize tool detected that using "uee" is more consistent with
the current codebase state:
* "uee" in LocalStore is 28.47% probable ("usee" 5.01%)
* "uee" in TextBody is 45.02% probable ("usee" 9.10%)
If the user chooses a connection security option which assures the use of
encryption, then the PLAIN auth. option is labeled "Normal password",
otherwise it is labeled "Password, transmitted insecurely".
This is similar to Thunderbird's behavior.
The server settings for IMAP and POP3 have no such AUTOMATIC setting.
(Nor does Thunderbird have any such setting.)
The AUTOMATIC option is no longer offered to users as a choice. A
pre-existing setting will continue to be honored, but only to the extent
that it doesn't result in insecure password transmission. Users in such a
situation will get a "Failed to send some messages" notification
containing the exception text that says to update their outgoing server
authentication setting.
One of the problems with "AUTOMATIC" is that users may not fully
understand its security implications. For example, a MITM attack could
mask a server's support for STARTTLS and CRAM-MD5, resulting in password
disclosure in certain configurations.
This commit also makes changes to the SMTP authentication process. No
attempt is made to authenticate using methods that the server does not
profess to support in its EHLO response. This is the same behavior as
found in Thunderbird.
The LOGIN option is no longer offered to users as a choice. This does
*not* eliminate the SASL LOGIN authentication mechanism. Any pre-existing
LOGIN setting or any imported LOGIN setting will still be recognized. In
all cases, a user setting of either "Normal password" or "LOGIN" will
result in the SASL PLAIN mechanism being tried first if available,
otherwise SASL LOGIN will be tried if available.
This mirrors similar behavior that exists for IMAP.
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)
Changes:
Extract code and create login() and authCramMD5() methods.
Implement the SASL PLAIN authentication mechanism. Its primary benefit is
the explicit support for UTF-8. If the user has configured "PLAIN"
authentication, then SASL PLAIN will be used, if available, otherwise
login() will be used.
Implement POP3 APOP authentication (issue 3218). If the user has
configured "CRAM_MD5" authentication (a future commit will change this
user option to a localized string "Encrypted password"), then SASL
CRAM-MD5 will be used, if available, otherwise the availability of POP3
APOP will be checked and used (per RFC 2449, there is no APOP
"capability").
Extend getCapabilities() to check for available authentication methods by
sending the "AUTH" command with no arguments
(http://tools.ietf.org/html/draft-myers-sasl-pop3-05). This never became
a standard, but there are servers that support it, and Thunderbird
includes this check.
The SASL PLAIN and CRAM-MD5 authentication methods are not attempted
unless the server professes to have the appropriate capability.
(Previously, CRAM-MD5 was tried regardless of capability.) No check is
made for the USER capability prior to use of that method. All this is the
same behavior as in Thunderbird.
Eliminate the testing for capabilities in cases where the test results are
never used (PIPELINING, USER).
Change when getCapabilities() is called. It is called once upon
connection. If STARTTLS is negotiated (POP3 STLS), then
getCapabilities() is called again after the connection is encrypted (and
the server is authenticated), but before user authentication is attempted.
In AccountSetupCheckSettings.onCreate(Bundle), the account settings are
checked.
If an AuthenticationFailedException occurs, A dialog saying "Username or
password incorrect." pops up. We don't want to say this if the cause is
not related to an incorrect user name or password. Instead we want to say
the more generic "Cannot connect to server" which pops up for other
exception types.
This commit attempts to eliminate the use of AuthenticationFailedException
in instances where it could not be due to "Username or password
incorrect."
Previously, the user name and password were being transmitted as IMAP (RFC
3501) quoted strings.
The problem is that quoted strings are only permitted to carry 7-bit
(ASCII) data, whereas user names and passwords entered in K-9 Mail may not
be ASCII, so K-9 was violating the RFC by sending them as quoted strings.
The solution is to transmit the credentials as IMAP literal strings, which
are permitted for user names and passwords, and which permit the
transmission of 8-bit data.
This is only a partial attempt for fixing the LOGIN command for users with
non-ASCII credentials. The problem is that IMAP permits 8-bit data for
user names and passwords (if transmitted as literals), but the RFC says
nothing about the character encoding for 8-bit data. This commit encodes
them as UTF-8.
The RFC author's comments on the subject:
http://mailman2.u.washington.edu/pipermail/imap-protocol/2008-February/000822.html
Ideally, users should avoid the LOGIN command and use the SASL PLAIN
mechanism (within TLS) which explicitly permits UTF-8. (K-9 Mail always
chooses PLAIN over LOGIN, when PLAIN is available.)
CRAM-MD5 (RFC 2195) permits 8-bit data but does not identify its encoding.
Since ASCII does not permit 8-bit data, this commit changes the encoding
to UTF-8.
There is an expired Internet-Draft that proposed that the RFC be changed
to explicitly require UTF-8 encoding of user names and shared secrets.
(But then there's also an expired draft proposing that CRAM-MD5 be retired
to historic status.)
Instead of CRAM-MD5, a better option for users is the SASL PLAIN mechanism
(within TLS) which explicitly permits UTF-8.
See Issue 4492
This method made way too many assumptions about server responses and
should not have been attempting to read and parse them. That should be
left to ImapResponseParser.
Changes:
Implement the PLAIN SASL mechanism. IMAPv4rev1 assures its availability
so long as the connection is encrypted. The big advantage of PLAIN over
IMAP "LOGIN" is that PLAIN uses UTF-8 encoding for the user name and
password, whereas "LOGIN" is only safe for 7-bit US-ASCII -- the encoding
of 8-bit data is undefined.
(Note that RFC 6855 says that IMAP "LOGIN" does not support UTF-8, and
clients must use IMAP "AUTHENTICATE" to pass UTF-8 user names and
passwords.)
Honor the "LOGINDISABLED" CAPABILITY (RFC 2595) when the server declares
it. There's no sense transmitting a password in the clear when it is
known that it will be rejected.
No attempt is made to try CRAM-MD5 if the server doesn't profess to
support it in its CAPABILITY response. (This is the same behavior as
Thunderbird.)
Extract code from ImapConnection.open into new method
ImapConnection.login.
Extract code from ImapConnection.executeSimpleCommand into new method
ImapConnection.readStatusResponse.
Related issues: 6015, 6016
All \r and \n codes have been replaced with <br />, so the patterns in
these replacements don't match anything.
This problem has existed for some time -- since commits 1ea27d7 and
e12dd32.
No attempt is made here to reimplement the replacements because users are
now used to the current behavior without much apparent complaint, and such
replacements are never perfect and can occasionally fail to work as
desired without additional tweaking for special cases.
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 loop extracted keys from `folderMap` and then called
`folderMap.get(...)` for every key. If both the key and the value needs
to be iterated on, `Map.entrySet()` is a more efficient solution as it
doesn't require O(n) Map lookups.
Since id is a Long, Long.valueOf(long) unboxed the Long to a primitive
long, then reboxed it into a Long instance, which was again unboxed to
allow it to be set as an element of the array of longs. This commit
reduces the number of boxings from 3 to 1.
Under certain circumstances it's possible that the 'push state' isn't
updated to contain the most recent 'UIDNEXT' value. In that case
ImapFolderPusher.start() would execute the same code path through its
main loop over and over again, preventing the device from going to
sleep.
Rather than changing the code to update the 'push state' in the corner
case that triggers the behavior described above, this commit introduces
another mechanism to track the 'UIDNEXT' value. This should also catch
as of yet unknown cases where the 'push state' isn't properly updated.
At some point in the future I hope we get to a point where we only
persist the 'push state' when we manually stop/restart the service.
During normal operation there's no need to read from/write to storage
all the time.
Fixes issue 4907
When message viewing and tap the next icon, menu icons (previous, next, delete and replys) disappears for an instant.
But a compose icon remains, then tap it accidentally.
Eliminate the invocation of
WebSettings.setBlockNetworkImage(boolean flag),
thus maintaining the the default setting of "false".
On Android versions prior to KitKat, this setting has no
effect on inline image attachments loaded with content:
URIs. Such images would load regardless.
With KitKat, this setting does have an effect -- a
setting of "true" will block image attachments loaded
with content: URIs.
By removing this call, K-9 Mail behaves the same on KitKat
as on earlier Android versions, and the behavior on earlier
versions is unchanged.
The minSdkVersion was recently increased from 8 to 15.
WebSettings.setBlockNetworkLoads has been publicly available
since API level 8 (Froyo).
StrictMode has been publicly available since API level 9
(Gingerbread).
Also, include the sent-date in the header when using
the "prefix" quote style. "Be like mutt" (and gmail,
and thunderbird)
Also, the quoteOriginalHtmlMessage method was using the mSourceMessage
field in various places when it should be using its originalMessage
parameter.
Related issues: 2249, 3456
There were a number of preferences that were not being removed
from the preferences DB when an account was deleted, so they
would remain there forever.
There were a few attempts to remove preference keys from the DB where
the keys were obsolete and not in use for some time.
Certain obsolete preferences were not modified:
mUuid + ".name"
mUuid + ".email"
mUuid + ".signature"
mUuid + ".signatureUse"
These were in use before implementing multiple identities, and are still used
as a fallback for old accounts without multiple identities configured.
The properties currently therein are duplicates of those in
project.properties.
The build.xml file first loads properties from ant.properties, then from
project.properties, so ant.properties is redundant.
The file's existance was a maintenance issue. The past couple times
when the property "target" was updated in project.properties, the
property was overlooked in ant.properties, so ant builds would fail when
Eclipse builds would succeed.
Ignore auto-generated files that result from
"android update lib-project" (which is invoked within "ant debug").
Some of the plugins (library projects) already have their own
.gitignore file which includes the exclusions made here. This
commit assures that the exclusions are applied to *all* plugins,
regardless.
This, of course, has no effect on files that have already been
intentionally checked into the git repository (such as the main
build.xml).
Technically, the code still supports SDK 8. But we don't want users to get stuck
on a 4.9xx version when we do remove compatibility with old Android versions.
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.
Blacklist a couple of weak ciphers, bring known ones in a defined order and sort unknown
ciphers at the end. Also re-enable SSLv3 because it's still used a lot.
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.
Implement an "upgrade" capability for the key store file,
and then use it to delete the old file.
The existing certs in the old file are not a security
risk, but they are now useless because the format of
their aliases was changed in commit a4440b4. They now are
just taking up storage space and memory.
Users will need to re-accept *ALL* certificates that they had
previously accepted and are still using. (Actually, this requirement
was effective with commit 4b57d79a. Before that, certificates whose
Subject matched did not require re-accepting.)
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.
Proper host name validation was not being performed for certificates
kept in the local keystore. If an attacker could convince a user to
accept and store an attacker's certificate, then that certificate
could be used for MITM attacks, giving the attacker access to all
connections to all servers in all accounts in K-9.
This commit changes how the certificates are stored. Previously, an
entire certificate chain was stored for a server (and any of those
certificates in the chain were available for validating signatures on
certificates received when connecting). Now just the single
certificate for the server is stored.
This commit changes how locally stored certificates are retrieved.
They can only be retrieved using the host:port that the user
configured for the server.
This also fixes issue 1326. Users can now use different certificates
for different servers on the same host (listening to different ports).
The above changes mean that users might have to re-accept certificates
that they had previously accepted and are still using (but only if the
certificate's Subject doesn't match the host that they are connecting
to).
This commit modifies AccountSetupBasics so that it now calls
AccountSetupCheckSettings twice -- once for checking the incoming
settings and once for the outgoing settings. Otherwise, an exception
could occur while checking incoming settings, the user could say
continue (or the user could accept a certificate key), and the
outgoing settings would not be checked. This also helps with
determining if a certificate exception was for the incoming or
outgoing server, which is needed if the user decides to add the
certificate to the keystore.
The TrustedSocketFactory, which provides goodies like better cipher suites and
TLSv1.2, was only being used for tunnelled connections. Use it for STARTTLS
connections as well.
Implement methods missing in API 7
Fix coordinate reference frame mismatch. Touch events are
relative to the view display, whereas view children are relative
to the view.
Revert "Only Jelly Bean seems to have the auto-scroll issue"
This reverts commit a3802a7a8e.
Revert "Hack around WebView's initial auto-scrolling past the message header"
This reverts commit 8dcc769c50.
Conflicts:
src/com/fsck/k9/view/MessageWebView.java
This implements the AOSP Email solution for incorporating
a Webview inside a ScrollView, while still being able to
scroll diagonally.
This replaces the functionality of TitleBarWebView (which
is now removed).
As Georg Lukas wrote in his blog post about how Android handles TLS
handshake (http://op-co.de/blog/posts/android_ssl_downgrade/), an
explicit order of cipher suites and TLS versions must be supplied to
avoid having the weak (presumably broken) RC4 cipher at the top of the
preference list.
This commit adds the list included in the blog post to every TLS socket
creation, including IMAP, POP3 and SMTP, see Wireshark screenshots done
during testing at http://vsza.hu/k9mail-tls-hardening/
This string resource is used in two places -- both with and without the
linefeed at the end. Instead of having a linefeed in the string and
having the code remove it if not needed, the linefeed is now omitted from
the string and the code adds it if needed.
Also, the line ending is changed from \n to \r\n.
Also, the string in the DE and FR locales had linefeeds at the start that
were removed so they match all the other locales.
(The string in the zh-rTW locale was left alone, since it had no
linefeeds. It looks like that file has numerous instances where \n was
replaced with actual newlines, which is probably not correct.)
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.
Even with the fix in the parent commit, the X-K9mail-Identity header can
become invalid if, for example, a user creates a draft in K-9 Mail, then
edits the draft outside of K-9 Mail, then opens the draft again in K-9
Mail.
This commit assures that an invalid X-K9mail-Identity header will not
result in an IndexOutOfBoundsException.
The problem:
Configure the account (just an example -- problems can occur in other
configurations as well):
Message Format: HTML
Reply quoting style: Prefix
Quote message when replying: yes
Reply after quoted text: yes
Reply to a message that has a large quantity (20+) of \r\n scattered in
the body of its HTML version (not an unusual scenario).
Add a reply. Save the message as a draft. Go back & open the draft
again. A fatal IndexOutOfBoundsException occurs.
The cause:
When the draft was saved, the X-K9mail-Identity header was computed and
added to the message, then the text of the message was processed with
MimeUtility.fixDraftTextBody, replacing all occurrences of \r\n with \n in
the quoted message before being saved in LocalStore, thus invalidating the
X-K9mail-Identity header.
The fix:
Remove MimeUtility.fixDraftTextBody and implement
MessageCompose$EolConvertingEditText instead. Any message text placed in
an EolConvertingEditText widget is assured to have \n line endings. Any
message text extracted from an EolConvertingEditText widget is assured to
have \r\n line endings. The X-K9mail-Identity header will always be
computed correctly.
Issues thought to be related: 4782, 5010, 5634, 5725
As noted in some of the referenced issues, errors didn't always result in
a fatal exception, but instead with mixed up text.
Ref: commit f9a35aeaee
Clear out old/unrelated (previously bound) contactBadge info in
MessageListAdapter.bindView that could otherwise be displayed
when tapping on a contactBadge with no counterpartyAddress (may
require scrolling the message list up and down first before the
bug becomes evident).
Fixes assignment problems for emails sent by some issue tracking
systems, which send out mails with a fixed mail address on behalf of
different people.
Update LocalStore code to handle the newly introduced temporary files
for attachments
Conflicts:
res/values/strings.xml
src/com/fsck/k9/activity/MessageCompose.java
Android allows other apps to access protected content of an app without requesting the
necessary permission when the app returns an Intent with FLAG_GRANT_READ_URI_PERMISSION.
This regularly happens as a result of ACTION_GET_CONTENT, i.e. what we use to pick content
to be attached to a message. Accessing that content only works while the receiving activity
is running. Afterwards accessing the content throws a SecurityException because of the
missing permission.
This commit changes K-9 Mail's behavior to copy the content to a temporary file in K-9's
cache directory while the activity is still running.
Fixes issue 4847, 5821
This also fixes bugs related to the fact that K-9 Mail didn't save a copy of attached content
in the message database.
Fixes issue 1187, 3330, 4930
"wiederherstellen" actually means "to restore", which does not
apply here, and makes people think these options are some sort of
backup/restore operation.
use the proper translation of "re-create" -> "neu erstellen" instead.
In addition to a couple of custom ROMs linking /dev/urandom to a non-writable
*random version, now Samsung's SELinux policy also prevents apps from opening
/dev/urandom for writing. Since we shouldn't need to write to /dev/urandom anyway
we now simply don't.
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.
Deleting a message creates an entry in EmailProviderCache so
EmailProviderCacheCursor can skip the Cursor row during the time
it takes to update the database.
Previously EmailProviderCacheCursor.isLast() returned the wrong
result when the last row in the wrapped Cursor was hidden. This
lead to the crash in MergeCursor.
Fixes issue 5820
Effective with earlier commit e2c5229e85,
messages are wrapped with <html> tags at display time, rather than
when messages are saved.
For consistency, this commit removes tags from a status message, because
they, too, will be added back at display time.
Closes pull request 286.
Publishes the changelog on github using a gh-pages branch.
This implementation changes back and forth between git
branches without updating the working tree. This should
be faster because the branches are unrelated so updating
the tree would require removing and recreating all the files.
Gmail style user pics, 2nd try
* sfuhrm/gmail-style-user-pics:
Changed the fallback char from 'K' to '?'. The riddler was here ;).
Using Android proposed colors as contact color palette now: http://developer.android.com/design/style/color.html
Fixed NPE found by blackbox87 ... thanks pal!
Added more finer characters as proposed by cketti
Caching also the calculated anonymous bitmap as proposed by maniac103. This removes a lot of code for special handling unknown contacts.
Bugfix for negative modulo result indexing the palette array
Changed hash based color calc to a hash indexed palette as discussed in the pull request.
GMail-app-style generated colorful one-letter contact pictures for pictureless contacts
Conflicts:
src/com/fsck/k9/activity/misc/ContactPictureLoader.java
src/com/fsck/k9/fragment/MessageListFragment.java
java.lang.NullPointerException
at com.fsck.k9.controller.MessagingController.actOnMessages(MessagingController.java:5602)
at com.fsck.k9.controller.MessagingController.deleteThreads(MessagingController.java:3986)
at com.fsck.k9.fragment.MessageListFragment.onDelete(MessageListFragment.java:1311)
at com.fsck.k9.fragment.MessageListFragment.onDelete(MessageListFragment.java:1306)
at com.fsck.k9.fragment.MessageListFragment.onContextItemSelected(MessageListFragment.java:1506)
at android.support.v4.app.Fragment.performContextItemSelected(Fragment.java:1583)
at android.support.v4.app.FragmentManagerImpl.dispatchContextItemSelected(FragmentManager.java:1992)
at android.support.v4.app.FragmentActivity.onMenuItemSelected(FragmentActivity.java:370)
at com.actionbarsherlock.app.SherlockFragmentActivity.onMenuItemSelected(SherlockFragmentActivity.java:211)
at com.android.internal.policy.impl.PhoneWindow$DialogMenuCallback.onMenuItemSelected(PhoneWindow.java:4038)
at com.android.internal.view.menu.MenuBuilder.dispatchMenuItemSelected(MenuBuilder.java:735)
at com.android.internal.view.menu.MenuItemImpl.invoke(MenuItemImpl.java:149)
at com.android.internal.view.menu.MenuBuilder.performItemAction(MenuBuilder.java:874)
at com.android.internal.view.menu.MenuDialogHelper.onClick(MenuDialogHelper.java:193)
at com.android.internal.app.AlertController$AlertParams$3.onItemClick(AlertController.java:934)
at android.widget.AdapterView.performItemClick(AdapterView.java:301)
at android.widget.AbsListView.performItemClick(AbsListView.java:1287)
at android.widget.AbsListView$PerformClick.run(AbsListView.java:3078)
at android.widget.AbsListView$1.run(AbsListView.java:4161)
at android.os.Handler.handleCallback(Handler.java:615)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4921)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1038)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:805)
at dalvik.system.NativeStart.main(Native Method)
This will display the preference title vertically centered. Some
translations still had text for the summary, so their preference title
might need to be changed to adjust for possible loss of information.
This patch makes sure actions started via the context menu operate on
the correct message even when the message list changes and the 'adapter
position' accessible via the menu object points to another message.
When the message the menu was opened for is deleted the context menu
will be closed.
Previously the app crashed when upgrading the database failed. Now we
reset the database version and run the upgrade code again (recreating
all tables).
java.lang.RuntimeException: Unable to start activity ComponentInfo{com.fsck.k9/com.fsck.k9.activity.UpgradeDatabases}: java.lang.NullPointerException
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2117)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2155)
at android.app.ActivityThread.access$700(ActivityThread.java:139)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1248)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:5062)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:795)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:558)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.NullPointerException
at android.app.Instrumentation.execStartActivity(Instrumentation.java:1409)
at android.app.Activity.startActivityForResult(Activity.java:3389)
at android.app.Activity.startActivityForResult(Activity.java:3350)
at android.app.Activity.startActivity(Activity.java:3562)
at android.app.Activity.startActivity(Activity.java:3528)
at com.fsck.k9.activity.UpgradeDatabases.launchOriginalActivity(UpgradeDatabases.java:183)
at com.fsck.k9.activity.UpgradeDatabases.onCreate(UpgradeDatabases.java:109)
at android.app.Activity.performCreate(Activity.java:5058)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1079)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2081)
... 11 more
Market reported NPE:
java.lang.NullPointerException
at com.fsck.k9.view.MessageHeader.showAdditionalHeaders(MessageHeader.java:186)
at com.fsck.k9.view.MessageHeader.onShowAdditionalHeaders(MessageHeader.java:318)
at com.fsck.k9.fragment.MessageViewFragment.onToggleAllHeadersView(MessageViewFragment.java:300)
at com.fsck.k9.activity.MessageList.onOptionsItemSelected(MessageList.java:867)
at android.support.v4.app.Watson.onMenuItemSelected(Watson.java:119)
at com.actionbarsherlock.ActionBarSherlock.callbackOptionsItemSelected(ActionBarSherlock.java:603)
at com.actionbarsherlock.internal.ActionBarSherlockNative.dispatchOptionsItemSelected(ActionBarSherlockNative.java:78)
at com.actionbarsherlock.app.SherlockFragmentActivity.onMenuItemSelected(SherlockFragmentActivity.java:205)
at com.android.internal.policy.impl.PhoneWindow.onMenuItemSelected(PhoneWindow.java:1047)
at com.android.internal.view.menu.MenuBuilder.dispatchMenuItemSelected(MenuBuilder.java:735)
at com.android.internal.view.menu.MenuItemImpl.invoke(MenuItemImpl.java:149)
at com.android.internal.view.menu.MenuBuilder.performItemAction(MenuBuilder.java:874)
at com.android.internal.view.menu.ListMenuPresenter.onItemClick(ListMenuPresenter.java:180)
at android.widget.AdapterView.performItemClick(AdapterView.java:301)
at android.widget.AbsListView.performItemClick(AbsListView.java:1276)
at android.widget.AbsListView$PerformClick.run(AbsListView.java:3067)
at android.widget.AbsListView$1.run(AbsListView.java:3963)
at android.os.Handler.handleCallback(Handler.java:615)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4898)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1006)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:773)
at dalvik.system.NativeStart.main(Native Method)
java.lang.RuntimeException: Unable to start activity ComponentInfo{com.fsck.k9/com.fsck.k9.activity.MessageList}: java.lang.NullPointerException
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1970)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1995)
at android.app.ActivityThread.access$600(ActivityThread.java:128)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1161)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4517)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:993)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:760)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.NullPointerException
at com.fsck.k9.activity.MessageList.decodeExtras(MessageList.java:368)
at com.fsck.k9.activity.MessageList.onCreate(MessageList.java:216)
at android.app.Activity.performCreate(Activity.java:4470)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1053)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1934)
k
This reverts commit bbdec62e37.
Aside from being the incorrect solution for fixing the problem
described in pull request 211, the patch generates 'Dead code'
warnings inside the if(){} statements on lines 46 and 47.
The correct fix for the problem was already implemented in commit
5678786c97.
Although the logcat in the pull request was generated after the fix,
line numbers in the log indicate that it was based on an outdated
version of MimeUtility.java from before the fix.
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.
After reinstalling K-9 on my new mobile, I observed some misinterpretations and I fixed them.
I hope this translation makes it in the stable version 4.400.
Enjoy
for NAME in "status_lock_closed""status_lock_error""status_lock_open""status_signature_expired_cutout""status_signature_invalid_cutout""status_signature_revoked_cutout""status_signature_unknown_cutout""status_signature_unverified_cutout""status_signature_verified_cutout"