Good bye K9! Sending mail is impossible when not connected to WiFi

397 views
Skip to first unread message

WK

unread,
Apr 16, 2015, 7:52:33 AM4/16/15
to k-9-...@googlegroups.com
Hello!

I am quite annoyed now, because this problem lurks around for many weeks now and hasn't even been gotten appropriate attention and hasn't been reacted to.

The problem can be described very  simply: I can not send e-mails on a ssl-encrypted connection to Port 587, when I use the mobile network. Only when my phone is connected to a WiFi, I can send messages. This is not the fault to the mobile provider, because I can use "telnet mailserver 587" in a terminal and I get a connection. So it is not the mobile provider, who is filtering this port.

Since the authors of K9 don't seem to care about this, I am switching to another mail client now. I really loved K9 as long as it worked, but I really need to send e-mails while on the road, and I will not use an unencrypted channel for sending my password to the mail server.

So it's good bye to K9!

Greg Troxel

unread,
Apr 16, 2015, 9:02:02 AM4/16/15
to WK, k-9-...@googlegroups.com

WK <wolfgang....@gmail.com> writes:

> The problem can be described very simply: I can not send e-mails on a
> ssl-encrypted connection to Port 587, when I use the mobile network. Only
> when my phone is connected to a WiFi, I can send messages. This is not the
> fault to the mobile provider, because I can use "telnet mailserver 587" in
> a terminal and I get a connection. So it is not the mobile provider, who is
> filtering this port.

That doesn't proove that they aren't doing a MITM to inspect mail.
To be sure, you need to negotiate TLS and validate the certificates.
(This is in the US more common at some wifi places vs mobile.)
https://crypto.stanford.edu/ssl-mitm/


tls to 587 works fine for me with k-9, on almost all WiFi and on mobile
data.

You should be very careful that your other client that "works" isn't
accepting a fake certificate from the mobile operator.

Richard

unread,
Apr 16, 2015, 3:05:33 PM4/16/15
to k-9-...@googlegroups.com
I don't think I would see this as a K-9 issue. K-9 is, to the best
of my knowledge, connectivity agnostic, so it shouldn't matter what
your connectivity is. As with Greg, I don't have issues with sending
(or receiving) mail, unless the connectivity is bad, and then it
doesn't matter if it's wifi or celldata.

So, a couple of debugging questions.

- What is the error that you get when sending via celldata fails?
-- in your earlier messages you said "k9 complains about not
being able to connect". Is it that it can't find the
server, that starttls fails, authentication fails, or
something else?

- Is the connectivity underlying the wifi where K-9 works
from web.de, or someone else?

- Does it work on all wifi, or just certain locations/providers?

- Are you restricting K-9's background data use when on celldata?

Comparing the protocols and ciphers offered when you connect via
wifi vs. celldata would be interesting, but I can't find an app that
will do this against a STARTTLS environment. [On my *nix machine I
would use "openssl s_client".]



Adam Tauno Williams

unread,
Apr 16, 2015, 3:40:33 PM4/16/15
to k-9-...@googlegroups.com
On Thu, 2015-04-16 at 19:05 +0000, Richard wrote:
> > That doesn't proove that they aren't doing a MITM to inspect mail.
> > To be sure, you need to negotiate TLS and validate the
> > certificates. (This is in the US more common at some wifi places
> > vs mobile.) https://crypto.stanford.edu/ssl-mitm/
> > tls to 587 works fine for me with k-9, on almost all WiFi and on
> > mobile data.
> > You should be very careful that your other client that "works"
> > isn't accepting a fake certificate from the mobile operator.
> I don't think I would see this as a K-9 issue.

+1 The inability to send e-mail is not related to K-9; you have a
setup/configuration issue.

> I don't have issues with sending
> (or receiving) mail, unless the connectivity is bad, and then it
> doesn't matter if it's wifi or celldata.

Ditto.

--
Adam Tauno Williams <mailto:awil...@whitemice.org> GPG D95ED383
Systems Administrator, Python Developer, LPI / NCLA

WK

unread,
Apr 16, 2015, 5:15:34 PM4/16/15
to k-9-...@googlegroups.com, lists-...@listmail.innovate.net
Answers to your questions:

- K9 only tells me that it can't connect to the server, sometimes I also get a java exception error. Sorry, can't tell you more, I am not an expert on that.

- K9 can contact the server "smtp.web.de" when I switch off encryption.

- I also use 3 other accounts, all with encrypted imap/smtp, and they all work fine. The only difference is to the ports that these servers use: smtp.web.de is the only server that wants to use 587.

- But, like I said before: I can "telnet smtp.web.de 587" on my phone while on cell data and I see the server's "halo".

- K9 also can connect to smtp.web.de on port 587 on three different wifi networks I have access to, all of which use different ISP.

- Background data is not restricted.

According to my kind of logic, these results yield that k9 can't establish an encrypted connection to port 587 when on cell data. It does not have this problem when on wifi.

This makes k9 unusable for me when I am not in reach of a wifi, which is 99% of my time. So I desperately need another e-mail client.

WK

unread,
Apr 16, 2015, 5:22:36 PM4/16/15
to k-9-...@googlegroups.com, awil...@whitemice.org
 > +1  The inability to send e-mail is not related to K-9; you have a setup/configuration issue.

Then, please, be so kind and tell me, where this issue is hidden, because I can't find it. I wiped the program completely and reinstalled it from scratch several times now. I even flashed a new CM version in between, so there should be no bits remaining from the previous installation.

Just in case if you're interested: I also tried Kaiten, and it gives me exactly the same error, right at the beginning, when I enter the account's details: as soon as I hit "weiter" (ready?) and Kaiten tries to check the data, it can not connect, as long as wifi is turned off.

WK

unread,
Apr 16, 2015, 5:53:08 PM4/16/15
to k-9-...@googlegroups.com, awil...@whitemice.org
I just made a screen shot of the java error. It is the same error that Kaiten complains about:



Richard

unread,
Apr 16, 2015, 6:02:35 PM4/16/15
to k-9-...@googlegroups.com


------------ Original Message ------------
> Date: Thursday, April 16, 2015 14:53:08 -0700
> From: WK <wolfgang....@gmail.com>
> To: k-9-...@googlegroups.com
> Cc: awil...@whitemice.org
> Subject: Re: [k-9-mail] Good bye K9! Sending mail is impossible
when not connected to WiFi
>
> I just made a screen shot of the java error. It is the same error
> that Kaiten complains about:
>
> <https://lh3.googleusercontent.com/-638n-ZCLOT0/VTAvInzaCiI/AAAAAA
> AAAAM/MtMYw_qHxUQ/s1600/Screenshot_2015-04-16-23-44-48.png>

You may have provided this information previously, but I don't
remember seeing it:

- version of K9

- android version

- could you give a screenshot of your k9 "outgoing server"
screen


WK

unread,
Apr 16, 2015, 6:20:51 PM4/16/15
to k-9-...@googlegroups.com, lists-...@listmail.innovate.net

Here you are:



Please forget about the previous picture: that only happens when I try to use "SSL/TLS" on port 587. That setting don't work neither on wifi nor on cell data.

The support pages of web.de state that STARTTLS and port 587 should be used. And those are the settings, that only work on wifi, but not on cell data.

WK

unread,
Apr 16, 2015, 6:24:58 PM4/16/15
to k-9-...@googlegroups.com, lists-...@listmail.innovate.net
K9 version: 5.004
Android version: CM 11

I have been using CM 11 for a long time now, and the k9 problem occurred after the last update of K9. So I am pretty sure it can't be caused by the OS.

Voytek

unread,
Apr 16, 2015, 7:08:03 PM4/16/15
to k-9-...@googlegroups.com


On 16 April 2015 11:01:58 pm AEST, Greg Troxel <g...@lexort.com> wrote:

>
>That doesn't proove that they aren't doing a MITM to inspect mail.
>To be sure, you need to negotiate TLS and validate the certificates.
>(This is in the US more common at some wifi places vs mobile.)
> https://crypto.stanford.edu/ssl-mitm/
>
>

On the subject of blocking, I was on a cell carrier's free Wi-Fi, couldn't access email,

no problem, he says, I'll use webmail, guess what:

Browser access to my mail server web host was blocked by Wi-Fi provider as my mail server had self issued certificate...


>tls to 587 works fine for me with k-9, on almost all WiFi and on mobile
>data.

Same here, works 100%, cell data, with multiple cell providers when on a trip,
(Only occasionally have problems using gratuitous Wi-Fi, as discussed)

--
Sent from Kaiten Mail. Please excuse my brevity.

WK

unread,
Apr 17, 2015, 5:47:10 AM4/17/15
to k-9-...@googlegroups.com
When I look at the start page for this group, I see lots of people complaining about exactly the same error about k9 and ssl. Do you really think that they all use "bad" mobile providers who filter port 587? This port is one of the most important ports on the net, because more and more e-mail providers use it for ssl encrypted smtp connections. Do you really believe that all those carrier providers will keep their customers from accessing their mail in an encrypted way?

Greg Troxel

unread,
Apr 17, 2015, 8:03:38 AM4/17/15
to WK, k-9-...@googlegroups.com

WK <wolfgang....@gmail.com> writes:

> When I look at the start page for this group, I see lots of people
> complaining about exactly the same error about k9 and ssl. Do you really
> think that they all use "bad" mobile providers who filter port 587? This
> port is one of the most important ports on the net, because more and more
> e-mail providers use it for ssl encrypted smtp connections. Do you really
> believe that all those carrier providers will keep their customers from
> accessing their mail in an encrypted way?

I have actually experienced SSL MITM on wifi, where one can connect to
587, but gets a manufactured certificate. So it's not inconceivable
that a carrier would do this.

Also, k-9 with outbound TLS works for a large number of people.

To answer your question, I believe that until we understand exactly
what's wrong, we don't understand. I merely suggested that you should
check to see that the "working" clients are actually working correctly
with respect to security.

Reply all
Reply to author
Forward
0 new messages