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.
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.
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]
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%)
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 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)
