2008-10-27 21:04:44 -04:00
|
|
|
<?xml version="1.0" encoding="utf-8"?>
|
2010-11-14 10:20:54 -05:00
|
|
|
<!-- Copyright (C) 2008 The Android Open Source Project
|
|
|
|
|
|
|
|
Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
you may not use this file except in compliance with the License.
|
|
|
|
You may obtain a copy of the License at
|
|
|
|
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
|
|
|
|
Unless required by applicable law or agreed to in writing, software
|
|
|
|
distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
See the License for the specific language governing permissions and
|
|
|
|
limitations under the License.
|
|
|
|
-->
|
|
|
|
|
2008-10-27 21:04:44 -04:00
|
|
|
<!--
|
|
|
|
This file is used to specify providers that we know default settings for
|
|
|
|
so that the user can set up their account by simply entering their email
|
|
|
|
address and password.
|
|
|
|
|
|
|
|
When a user starts this process, the email address is parsed, the domain
|
|
|
|
broken out and used to search this file for a provider. If one is found the
|
|
|
|
provider's settings are used to attempt to connect to the account.
|
2010-11-14 10:20:54 -05:00
|
|
|
|
|
|
|
At this time, the id and label attributes are not used. However, please include them
|
|
|
|
if you make edits to this file. id must also be completely unique. label will be shown
|
|
|
|
to the user when there are multiple options provided for a single domain (not currently
|
|
|
|
supported).
|
2008-10-27 21:04:44 -04:00
|
|
|
|
|
|
|
A provider contains the settings for setting up an email account
|
|
|
|
that ends with the given domain. Domains should be unique within
|
|
|
|
this file. Each provider should have at least one incoming section and
|
|
|
|
one outgoing section. If more than one is specified only the first
|
|
|
|
will be used.
|
|
|
|
|
|
|
|
Valid incoming uri schemes are:
|
|
|
|
imap+tls+ IMAP with required TLS transport security.
|
2014-03-05 01:10:17 -05:00
|
|
|
If TLS is not available the connection fails.
|
2008-10-27 21:04:44 -04:00
|
|
|
imap+ssl+ IMAP with required SSL transport security.
|
|
|
|
If SSL is not available the connection fails.
|
|
|
|
|
|
|
|
pop3+tls+ POP3 with required TLS transport security.
|
2014-03-05 01:10:17 -05:00
|
|
|
If TLS is not available the connection fails.
|
2008-10-27 21:04:44 -04:00
|
|
|
pop3+ssl+ POP3 with required SSL transport security.
|
|
|
|
If SSL is not available the connection fails.
|
|
|
|
|
|
|
|
Valid outgoing uri schemes are:
|
|
|
|
smtp+tls+ SMTP with required TLS transport security.
|
2014-03-05 01:10:17 -05:00
|
|
|
If TLS is not available the connection fails.
|
2008-10-27 21:04:44 -04:00
|
|
|
smtp+ssl+ SMTP with required SSL transport security.
|
|
|
|
If SSL is not available the connection fails.
|
|
|
|
|
|
|
|
The URIs should be full templates for connection, including a port if
|
2010-11-14 10:20:54 -05:00
|
|
|
the service uses a non-default port. The default ports are as follows:
|
|
|
|
imap+tls+ 143 pop3+tls+ 110 smtp+tls+ 587
|
|
|
|
imap+ssl+ 993 pop3+ssl+ 995 smtp+ssl+ 465
|
2008-10-27 21:04:44 -04:00
|
|
|
|
|
|
|
The username attribute is used to supply a template for the username
|
|
|
|
that will be presented to the server. This username is built from a
|
|
|
|
set of variables that are substituted with parts of the user
|
|
|
|
specified email address.
|
|
|
|
|
|
|
|
Valid substitution values for the username attribute are:
|
|
|
|
$email - the email address the user entered
|
|
|
|
$user - the value before the @ sign in the email address the user entered
|
2014-03-05 01:10:17 -05:00
|
|
|
$domain - the value after the @ sign in the email address the user entered
|
2010-11-14 10:20:54 -05:00
|
|
|
|
|
|
|
The username attribute MUST be specified for the incoming element, so the POP3 or IMAP
|
|
|
|
server can identify the mailbox to be opened.
|
|
|
|
|
|
|
|
The username attribute MAY be the empty string for the outgoing element, but only if the
|
|
|
|
SMTP server supports anonymous transmission (most don't).
|
2014-03-05 01:03:13 -05:00
|
|
|
|
|
|
|
While it would technically work please DO NOT add providers that don't support encrypted
|
|
|
|
connections.
|
2008-10-27 21:04:44 -04:00
|
|
|
-->
|
2010-11-14 10:20:54 -05:00
|
|
|
|
2008-10-27 21:04:44 -04:00
|
|
|
<providers>
|
2010-11-14 10:20:54 -05:00
|
|
|
|
|
|
|
<!-- Gmail variants -->
|
2008-10-27 21:04:44 -04:00
|
|
|
<provider id="gmail" label="Gmail" domain="gmail.com">
|
2010-11-14 10:20:54 -05:00
|
|
|
<incoming uri="imap+ssl+://imap.gmail.com" username="$email" />
|
2008-10-27 21:04:44 -04:00
|
|
|
<outgoing uri="smtp+ssl+://smtp.gmail.com" username="$email" />
|
|
|
|
</provider>
|
2010-11-14 10:20:54 -05:00
|
|
|
<provider id="googlemail" label="Google Mail" domain="googlemail.com">
|
2008-12-02 23:14:39 -05:00
|
|
|
<incoming uri="imap+ssl+://imap.googlemail.com" username="$email" />
|
2010-11-14 10:20:54 -05:00
|
|
|
<outgoing uri="smtp+ssl+://smtp.googlemail.com" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="google" label="Google" domain="google.com">
|
|
|
|
<incoming uri="imap+ssl+://imap.gmail.com" username="$email" />
|
2008-10-27 21:04:44 -04:00
|
|
|
<outgoing uri="smtp+ssl+://smtp.gmail.com" username="$email" />
|
|
|
|
</provider>
|
2010-11-14 10:20:54 -05:00
|
|
|
<provider id="android" label="Android" domain="android.com">
|
|
|
|
<incoming uri="imap+ssl+://imap.gmail.com" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.gmail.com" username="$email" />
|
2008-10-27 21:04:44 -04:00
|
|
|
</provider>
|
2010-11-14 10:20:54 -05:00
|
|
|
|
|
|
|
<!-- USA -->
|
2008-10-27 21:04:44 -04:00
|
|
|
<provider id="comcast" label="Comcast" domain="comcast.net">
|
|
|
|
<incoming uri="pop3+ssl+://mail.comcast.net" username="$user" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.comcast.net" username="$user" />
|
|
|
|
</provider>
|
2010-11-14 10:20:54 -05:00
|
|
|
<provider id="cox" label="Cox" domain="cox.net">
|
|
|
|
<incoming uri="pop3+ssl+://pop.east.cox.net" username="$user" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.east.cox.net" username="$user" />
|
|
|
|
</provider>
|
|
|
|
<provider id="dotmac" label=".Mac" domain="mac.com">
|
Eliminate the 'if available' connection security options
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.
2014-02-26 16:50:21 -05:00
|
|
|
<incoming uri="imap+ssl+://imap.mail.me.com" username="$user" />
|
|
|
|
<outgoing uri="smtp+tls+://smtp.mail.me.com" username="$email" />
|
2010-11-14 10:20:54 -05:00
|
|
|
</provider>
|
2013-09-13 17:36:02 -04:00
|
|
|
<provider id="live" label="Windows Live Hotmail" domain="live.com">
|
|
|
|
<incoming uri="imap+ssl+://imap-mail.outlook.com" username="$email" />
|
|
|
|
<outgoing uri="smtp+tls+://smtp-mail.outlook.com" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="hotmail" label="Hotmail" domain="hotmail.com">
|
|
|
|
<incoming uri="imap+ssl+://imap-mail.outlook.com" username="$email" />
|
|
|
|
<outgoing uri="smtp+tls+://smtp-mail.outlook.com" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="outlook" label="Outlook.com" domain="outlook.com">
|
|
|
|
<incoming uri="imap+ssl+://imap-mail.outlook.com" username="$email" />
|
|
|
|
<outgoing uri="smtp+tls+://smtp-mail.outlook.com" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="msn" label="MSN" domain="msn.com">
|
|
|
|
<incoming uri="imap+ssl+://imap-mail.outlook.com" username="$email" />
|
|
|
|
<outgoing uri="smtp+tls+://smtp-mail.outlook.com" username="$email" />
|
2008-10-27 21:04:44 -04:00
|
|
|
</provider>
|
2010-11-14 10:20:54 -05:00
|
|
|
<provider id="mobileme" label="MobileMe" domain="me.com">
|
Eliminate the 'if available' connection security options
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.
2014-02-26 16:50:21 -05:00
|
|
|
<incoming uri="imap+ssl+://imap.mail.me.com" username="$user" />
|
|
|
|
<outgoing uri="smtp+tls+://smtp.mail.me.com" username="$email" />
|
2010-11-14 10:20:54 -05:00
|
|
|
</provider>
|
2012-01-23 20:51:30 -05:00
|
|
|
<provider id="montclair.edu" label="MSU" domain="montclair.edu">
|
|
|
|
<incoming uri="imap+ssl+://mail.montclair.edu" username="$user" />
|
|
|
|
<outgoing uri="smtp+tls+://smtp.montclair.edu" username="$user" />
|
|
|
|
</provider>
|
2012-02-16 19:35:25 -05:00
|
|
|
<provider id="gmx.com" label="GMX" domain="gmx.com">
|
|
|
|
<incoming uri="imap+ssl+://imap.gmx.com" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://mail.gmx.com" username="$email" />
|
|
|
|
</provider>
|
2011-01-02 04:20:59 -05:00
|
|
|
|
|
|
|
<!-- Yahoo! Mail Variants -->
|
2010-11-14 10:20:54 -05:00
|
|
|
<provider id="yahoo" label="Yahoo" domain="yahoo.com">
|
2012-05-05 01:21:06 -04:00
|
|
|
<incoming uri="imap+ssl+://imap.mail.yahoo.com" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.mail.yahoo.com" username="$email" />
|
2010-11-14 10:20:54 -05:00
|
|
|
</provider>
|
2011-01-02 04:20:59 -05:00
|
|
|
<provider id="ymail" label="YMail" domain="ymail.com">
|
2012-05-05 01:21:06 -04:00
|
|
|
<incoming uri="imap+ssl+://imap.mail.yahoo.com" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.mail.yahoo.com" username="$email" />
|
2011-01-02 04:20:59 -05:00
|
|
|
</provider>
|
|
|
|
<provider id="rocketmail" label="Rocketmail" domain="rocketmail.com">
|
2012-05-05 01:21:06 -04:00
|
|
|
<incoming uri="imap+ssl+://imap.mail.yahoo.com" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.mail.yahoo.com" username="$email" />
|
2011-01-02 04:20:59 -05:00
|
|
|
</provider>
|
2010-11-14 10:20:54 -05:00
|
|
|
|
2013-07-11 08:41:19 -04:00
|
|
|
<!-- Australia -->
|
|
|
|
<provider id="fastmail-fm" label="Fastmail" domain="fastmail.fm">
|
|
|
|
<incoming uri="imap+ssl+://mail.messagingengine.com" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://mail.messagingengine.com" username="$email" />
|
|
|
|
</provider>
|
2010-11-14 10:20:54 -05:00
|
|
|
|
|
|
|
<!-- UK -->
|
|
|
|
<provider id="aol-uk" label="AOL" domain="aol.co.uk">
|
|
|
|
<incoming uri="imap+ssl+://imap.uk.aol.com" label="IMAP" username="$user" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.uk.aol.com" username="$user" />
|
|
|
|
</provider>
|
|
|
|
<provider id="yahoo-uk" label="Yahoo" domain="yahoo.co.uk">
|
|
|
|
<incoming uri="pop3+ssl+://pop.mail.yahoo.co.uk" username="$user" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.mail.yahoo.co.uk" username="$user" />
|
2009-11-27 23:57:05 -05:00
|
|
|
</provider>
|
|
|
|
|
2010-11-14 10:20:54 -05:00
|
|
|
<!-- Germany -->
|
2014-02-20 16:14:40 -05:00
|
|
|
<provider id="mailbox.org" label="mailbox.org" domain="mailbox.org">
|
|
|
|
<incoming uri="imap+tls+://imap.mailbox.org" username="$email" />
|
|
|
|
<outgoing uri="smtp+tls+://smtp.mailbox.org" username="$email" />
|
|
|
|
</provider>
|
2010-11-14 10:20:54 -05:00
|
|
|
<provider id="freenet" label="Freenet" domain="freenet.de">
|
2014-01-12 18:21:51 -05:00
|
|
|
<incoming uri="imap+tls+://mx.freenet.de" username="$email" />
|
|
|
|
<outgoing uri="smtp+tls+://mx.freenet.de" username="$email" />
|
2010-11-14 10:20:54 -05:00
|
|
|
</provider>
|
|
|
|
<provider id="T-Online" label="T-Online" domain="t-online.de">
|
2014-01-12 18:21:51 -05:00
|
|
|
<incoming uri="imap+ssl+://secureimap.t-online.de" username="$email" />
|
|
|
|
<outgoing uri="smtp+tls+://securesmtp.t-online.de" username="$email" />
|
2010-11-14 10:20:54 -05:00
|
|
|
</provider>
|
|
|
|
<provider id="web.de" label="Web.de" domain="web.de">
|
2014-01-12 18:21:51 -05:00
|
|
|
<incoming uri="imap+ssl+://imap.web.de" username="$user" />
|
|
|
|
<outgoing uri="smtp+tls+://smtp.web.de" username="$user" />
|
2010-11-14 10:20:54 -05:00
|
|
|
</provider>
|
2013-11-11 10:49:25 -05:00
|
|
|
<provider id="posteo" label="Posteo" domain="posteo.de">
|
|
|
|
<incoming uri="imap+tls+://posteo.de" username="$email" />
|
|
|
|
<outgoing uri="smtp+tls+://posteo.de" username="$email" />
|
|
|
|
</provider>
|
2013-08-30 10:39:41 -04:00
|
|
|
<!-- GMX variants -->
|
|
|
|
<provider id="gmx.net" label="GMX.net" domain="gmx.net">
|
|
|
|
<incoming uri="imap+ssl+://imap.gmx.net" username="$email" />
|
2014-01-12 18:21:51 -05:00
|
|
|
<outgoing uri="smtp+tls+://mail.gmx.net" username="$email" />
|
2013-08-30 10:39:41 -04:00
|
|
|
</provider>
|
|
|
|
<provider id="gmx.de" label="GMX.de" domain="gmx.de">
|
|
|
|
<incoming uri="imap+ssl+://imap.gmx.net" username="$email" />
|
2014-01-12 18:21:51 -05:00
|
|
|
<outgoing uri="smtp+tls+://mail.gmx.net" username="$email" />
|
2013-08-30 10:39:41 -04:00
|
|
|
</provider>
|
|
|
|
<provider id="gmx.at" label="GMX.at" domain="gmx.at">
|
|
|
|
<incoming uri="imap+ssl+://imap.gmx.net" username="$email" />
|
2014-01-12 18:21:51 -05:00
|
|
|
<outgoing uri="smtp+tls+://mail.gmx.net" username="$email" />
|
2013-08-30 10:39:41 -04:00
|
|
|
</provider>
|
|
|
|
<provider id="gmx.ch" label="GMX.ch" domain="gmx.ch">
|
|
|
|
<incoming uri="imap+ssl+://imap.gmx.net" username="$email" />
|
2014-01-12 18:21:51 -05:00
|
|
|
<outgoing uri="smtp+tls+://mail.gmx.net" username="$email" />
|
2013-08-30 10:39:41 -04:00
|
|
|
</provider>
|
|
|
|
<provider id="gmx.eu" label="GMX.eu" domain="gmx.eu">
|
|
|
|
<incoming uri="imap+ssl+://imap.gmx.net" username="$email" />
|
2014-01-12 18:21:51 -05:00
|
|
|
<outgoing uri="smtp+tls+://mail.gmx.net" username="$email" />
|
2013-08-30 10:39:41 -04:00
|
|
|
</provider>
|
|
|
|
|
2010-11-14 10:20:54 -05:00
|
|
|
<!-- Poland -->
|
|
|
|
<provider id="interia" label="Interia" domain="interia.pl">
|
Eliminate the 'if available' connection security options
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.
2014-02-26 16:50:21 -05:00
|
|
|
<incoming uri="pop3+ssl+://poczta.interia.pl" username="$user" />
|
|
|
|
<outgoing uri="smtp+ssl+://poczta.interia.pl" username="$user" />
|
2010-11-14 10:20:54 -05:00
|
|
|
</provider>
|
|
|
|
<provider id="o2" label="O2" domain="o2.pl">
|
Eliminate the 'if available' connection security options
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.
2014-02-26 16:50:21 -05:00
|
|
|
<incoming uri="pop3+ssl+://poczta.o2.pl" username="$user" />
|
|
|
|
<outgoing uri="smtp+ssl+://poczta.o2.pl" username="$user" />
|
2010-11-14 10:20:54 -05:00
|
|
|
</provider>
|
|
|
|
|
2010-11-20 14:44:06 -05:00
|
|
|
<!-- Japanese -->
|
2012-03-03 19:47:29 -05:00
|
|
|
<provider id="auone" label="au one" domain="auone.jp"
|
|
|
|
note="@string/provider_note_auonejp">
|
|
|
|
<incoming uri="imap+ssl+://imap.gmail.com" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.gmail.com" username="$email" />
|
|
|
|
</provider>
|
2010-11-20 14:44:06 -05:00
|
|
|
|
2011-05-11 13:57:43 -04:00
|
|
|
<!-- Korean -->
|
|
|
|
<provider id="naver" label="Naver" domain="naver.com"
|
|
|
|
note="@string/provider_note_naver">
|
Eliminate the 'if available' connection security options
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.
2014-02-26 16:50:21 -05:00
|
|
|
<incoming uri="imap+ssl+://imap.naver.com" username="$user" />
|
|
|
|
<outgoing uri="smtp+tls+://smtp.naver.com:587" username="$user" />
|
2011-05-11 13:57:43 -04:00
|
|
|
</provider>
|
|
|
|
<provider id="hanmail" label="Hanmail" domain="hanmail.net"
|
|
|
|
note="@string/provider_note_hanmail">
|
Eliminate the 'if available' connection security options
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.
2014-02-26 16:50:21 -05:00
|
|
|
<incoming uri="imap+ssl+://imap.hanmail.net" username="$user" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.hanmail.net" username="$user" />
|
2011-05-11 13:57:43 -04:00
|
|
|
</provider>
|
|
|
|
<provider id="daum" label="Hanmail" domain="daum.net"
|
|
|
|
note="@string/provider_note_hanmail">
|
Eliminate the 'if available' connection security options
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.
2014-02-26 16:50:21 -05:00
|
|
|
<incoming uri="imap+ssl+://imap.hanmail.net" username="$user" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.hanmail.net" username="$user" />
|
2011-05-11 13:57:43 -04:00
|
|
|
</provider>
|
|
|
|
|
2013-07-11 12:57:12 -04:00
|
|
|
<!-- Russia -->
|
|
|
|
<!-- Mail.Ru variants -->
|
|
|
|
<provider id="rumailmailimap" label="mail.ru" domain="mail.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.mail.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.mail.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="rumailinboximap" label="inbox.ru" domain="inbox.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.mail.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.mail.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="rumaillistimap" label="list.ru" domain="list.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.mail.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.mail.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="rumailbkimap" label="bk.ru" domain="bk.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.mail.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.mail.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<!-- Yandex.ru variants -->
|
2013-07-13 04:49:01 -04:00
|
|
|
<provider id="comyanyandeximap" label="yandex.com" domain="yandex.com">
|
|
|
|
<incoming uri="imap+ssl+://imap.yandex.com" username="$user" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.yandex.com" username="$user" />
|
|
|
|
</provider>
|
2013-07-11 12:57:12 -04:00
|
|
|
<provider id="ruyanyandeximap" label="yandex.ru" domain="yandex.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.yandex.ru" username="$user" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.yandex.ru" username="$user" />
|
|
|
|
</provider>
|
|
|
|
<provider id="ruyanyaimap" label="ya.ru" domain="ya.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.ya.ru" username="$user" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.ya.ru" username="$user" />
|
|
|
|
</provider>
|
|
|
|
<provider id="ruyannarodimap" label="narod.ru" domain="narod.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.narod.ru" username="$user" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.narod.ru" username="$user" />
|
|
|
|
</provider>
|
|
|
|
<!-- Rambler.ru variants -->
|
|
|
|
<provider id="ruramramblerimap" label="rambler.ru" domain="rambler.ru">
|
|
|
|
<incoming uri="imap+ssl+://mail.rambler.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://mail.rambler.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="ruramlentaimap" label="lenta.ru" domain="lenta.ru">
|
|
|
|
<incoming uri="imap+ssl+://mail.rambler.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://mail.rambler.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="ruramroimap" label="ro.ru" domain="ro.ru">
|
|
|
|
<incoming uri="imap+ssl+://mail.rambler.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://mail.rambler.ru" username="$email" />
|
|
|
|
</provider>
|
2013-07-23 17:28:13 -04:00
|
|
|
<!-- QIP.RU variants -->
|
|
|
|
<provider id="ruqipqipimap" label="qip.ru" domain="qip.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.qip.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.qip.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="ruqippochtaimap" label="pochta.ru" domain="pochta.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.pochta.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.pochta.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="comqipfromruimap" label="fromru.com" domain="fromru.com">
|
|
|
|
<incoming uri="imap+ssl+://imap.fromru.com" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.fromru.com" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="ruqipfrontimap" label="front.ru" domain="front.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.front.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.front.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="ruqiphotboximap" label="hotbox.ru" domain="hotbox.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.hotbox.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.hotbox.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="ruqiphotmailimap" label="hotmail.ru" domain="hotmail.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.hotmail.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.hotmail.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="suqipkrovatkaimap" label="krovatka.su" domain="krovatka.su">
|
|
|
|
<incoming uri="imap+ssl+://imap.krovatka.su" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.krovatka.su" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="ruqiplandimap" label="land.ru" domain="land.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.land.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.land.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="comqipmail15imap" label="mail15.com" domain="mail15.com">
|
|
|
|
<incoming uri="imap+ssl+://imap.mail15.com" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.mail15.com" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="comqipmail333imap" label="mail333.com" domain="mail333.com">
|
|
|
|
<incoming uri="imap+ssl+://imap.mail333.com" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.mail333.com" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="ruqipnewmailimap" label="newmail.ru" domain="newmail.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.newmail.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.newmail.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="ruqipnightmailimap" label="nightmail.ru" domain="nightmail.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.nightmail.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.nightmail.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="ruqipnmimap" label="nm.ru" domain="nm.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.nm.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.nm.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="netqippisemimap" label="pisem.net" domain="pisem.net">
|
|
|
|
<incoming uri="imap+ssl+://imap.pisem.net" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.pisem.net" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="ruqippochtamtimap" label="pochtamt.ru" domain="pochtamt.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.pochtamt.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.pochtamt.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="ruqippop3imap" label="pop3.ru" domain="pop3.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.pop3.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.pop3.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="ruqiprbcmailimap" label="rbcmail.ru" domain="rbcmail.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.rbcmail.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.rbcmail.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="ruqipsmtpimap" label="smtp.ru" domain="smtp.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.smtp.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.smtp.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="ruqip5ballovimap" label="5ballov.ru" domain="5ballov.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.5ballov.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.5ballov.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="ruqipaeternaimap" label="aeterna.ru" domain="aeterna.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.aeterna.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.aeterna.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="ruqipzizaimap" label="ziza.ru" domain="ziza.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.ziza.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.ziza.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="ruqipmemoriimap" label="memori.ru" domain="memori.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.memori.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.memori.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="ruqipphotofileimap" label="photofile.ru" domain="photofile.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.photofile.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.photofile.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="ruqipfotoplenkaimap" label="fotoplenka.ru" domain="fotoplenka.ru">
|
|
|
|
<incoming uri="imap+ssl+://imap.fotoplenka.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.fotoplenka.ru" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="comqippochtaimap" label="pochta.com" domain="pochta.com">
|
|
|
|
<incoming uri="imap+ssl+://imap.pochta.ru" username="$email" />
|
|
|
|
<outgoing uri="smtp+ssl+://smtp.pochta.ru" username="$email" />
|
|
|
|
</provider>
|
2013-12-01 07:05:20 -05:00
|
|
|
|
|
|
|
<!-- Slovakia -->
|
|
|
|
<provider id="azet.sk" label="Azet.sk" domain="azet.sk">
|
|
|
|
<incoming uri="imap+ssl+://imap.azet.sk" username="$email" />
|
2013-12-20 07:24:47 -05:00
|
|
|
<outgoing uri="smtp+ssl+://smtp.azet.sk" username="$email" />
|
|
|
|
</provider>
|
|
|
|
<provider id="outlook.sk" label="Outlook.sk" domain="outlook.sk">
|
|
|
|
<incoming uri="imap+ssl+://imap-mail.outlook.com" username="$email" />
|
|
|
|
<outgoing uri="smtp+tls+://smtp-mail.outlook.com" username="$email" />
|
2013-12-01 07:05:20 -05:00
|
|
|
</provider>
|
|
|
|
|
2010-11-14 10:20:54 -05:00
|
|
|
<!-- Developers' vanity providers -->
|
|
|
|
<provider id="fsck.com" label="Jesse's personal mail" domain="fsck.com" >
|
Eliminate the 'if available' connection security options
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.
2014-02-26 16:50:21 -05:00
|
|
|
<incoming uri="imap+ssl+://fsck.com" username="$user" />
|
|
|
|
<outgoing uri="smtp+tls+://mail.bestpractical.com:2525" />
|
2010-11-14 10:20:54 -05:00
|
|
|
</provider>
|
|
|
|
<provider id="bestpractical.com" label="Best Practical Solutions" domain="bestpractical.com" >
|
Eliminate the 'if available' connection security options
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.
2014-02-26 16:50:21 -05:00
|
|
|
<incoming uri="imap+ssl+://imap.bestpractical.com" username="$user" />
|
|
|
|
<outgoing uri="smtp+tls+://smtp.bestpractical.com:2525" />
|
2010-11-14 10:20:54 -05:00
|
|
|
</provider>
|
2008-10-27 21:04:44 -04:00
|
|
|
</providers>
|