In January of this year I wrote about t-mobile’s apparent policy of actively looking for and blocking any TLS-secured SMTP sessions over their network. At the time I believed this to be a cockup rather than a deliberate policy. I still prefer to believe that, but the episode left a rather sour taste in my mouth. So this month I took the opportunity presented by the end of my contract to shift to another provider. Of course, in doing so I gained a nice shiny new ‘phone which meant that I could spend a fun few hours setting it up the way I wanted it and nailing it down as much as possible so that it didn’t leak all my data to google. This is unnecessarily difficult, and much harder than it should be (and I know that people like Peter H will simply tell me that I shouldn’t be using an android ‘phone in the first place). But that is not the point of this post.
Like most people these days, I use my ‘phone to pick up email. The standard email client on my last ‘phone was pretty uninspiring so I used K-9 mail in its place. K-9 is a pretty good application, but it has a silly little bug in it which is still not sorted properly. This bug manifests itself in a rather odd, and unpredictable way – K-9 seems to “forget” the X509 certificate used to protect the authentication process if that certificate is self-signed, or otherwise not verifiable by an external CA. The cure, such as it is, is to simply refresh the certificate by reloading the account settings and accepting the cert when K-9 warns you that “TrustAnchor found but validation failed”. The length of time between accepting the cert and K-9 “forgetting” it again seemed random to me, so I got into the habit of refreshing my account settings whenever I noticed that I hadn’t received any mail for a while. Annoying, but not ultimately a deal breaker for using what was otherwise a pretty good application.
So, the first application I looked at on my new mobile was, of course, email. The default mail client on this new phone looks a lot slicker than the old one on my previous phone, but then it is a much newer ‘phone, from a different manufacturer and the android version is much newer too, so no real surprise there. The setup seemed to have no problem with my self signed certs so I thought I might stay with the default to see if it would solve my annoying little problem with K-9.
Unfortunately not.
Whilst I had no problem with incoming mail over my IMAPS connection, all attempts to send mail failed. On checking my server logs I found the following (real details changed or obfuscated):
Mar 20 20:45:57 pipe postfix/smtpd[7594]: NOQUEUE: reject: RCPT from home.baldric.net[12.34.56.78]: 504 5.5.2 <localhost>: Helo command rejected: need fully-qualified hostname; from=<null@baldric.net> to=<noone@baldric.net> proto=ESMTP helo=<localhost>
Aha! My postfix configuration is set up to reject hosts which do not have valid hostnames or do not announce themselves with fully qualified domain names (i.e. names of the form “host.domain”). Now since I use SASL authentication in my postfix configuration the fix is relatively easy; just ensure that the stanza “permit_sasl_authenticated” appears in both “smtpd_sender_restrictions” and “smtpd_helo_restrictions” before “reject_non_fqdn_hostname” – thusly:
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_non_fqdn_hostname, reject_invalid_hostname
smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain
(In fact, this episode highlighted an error in my postfx configuration because my helo restriction was inadequate. By now checking the authentication before the helo restriction kicks in I am still well protected, but mail from valid authenticated users is permitted.)
I am in that (very) small minority of people who run their own mail servers and are able to change server side configurations. But, and this is a big but. I should not have to change the server side configuration to accommodate a broken client and the vast majority of people will not be able to do so anyway. Almost all well set up mail servers will reject mail where the client connection announces itself in the helo exchange as “localhost”. That is normally an indication of a spammer, indeed spamassassin will allocate a high score to any mail which is so flagged. This means that there will be a huge, and growing, number of people who cannot send mail from their android ‘phones.
If this is the default android mail behaviour, then google need to fix it now. Meanwhile, K-9 is looking attractive again.
7 comments
Skip to comment form
I had been thinking about running my own mailserver again, but it was a bit too much work (got enough to do as it is :-). However, I then stumbled across the need of a number of people for such services so I ended up building a service with someone who I trust and who gets audited to smithereens by his clients (read: I have the benefit of that auditing without paying for it myself – and I know who is doing it :). The challenge is not getting it secure technically – the hard work is the legal side.
As for your use of Android – you’re at least one of the few people who can thwart the relentless data collection. Did you notice how little of the platform works unless you set up a Google account so they can associate all activity with one identity? Interesting little mail bug, though.
BTW, read point 47 of Google’s response to the Canadian Information Commissioner regarding the Streetview debacle and their future source of WiFi gathering.. Just FYI :)
Author
Hi Peter. I guessed you’d comment :-)
Yes, I know that it is almost impossible to use an android phone without a google account, but the account I have set up only exists on that phone (OK, and on my Archos tablet, but that is configured in the same way). I do not allow the phone to synchronise the calendar or the contacts to that account – so that data exists only on the phone. I do not use gmail, and I do not use the google search or the standard browser. The dolphin browser I do use is set to refuse cookies and its default search engine is set to bing (I know, but it isn’t google, and if I could add ixquick to the list I would). I also turn off location and other stupid settings in the browser. I do not have a dolphin account. The phone settings refuse location based tracking by both GPS and wifi (well, the check boxes are unticked anyway….) and I refuse backup/restore to/from google servers.
But all of this is ridiculously tiresome because the settings are all over the place. There should be a single checkbox on the first setup of the phone saying “surrender your privacy to google – yes/no” with the default being no.
And yes, I have read point 47.
My problem is I’m as susceptible to the “ooooh shiny” factor as anyone else. I want the functionality offered by the whizzy technology – but I hate apple’s approach to DRM and its ludicrous pricing model so I won’t have an iphone. Nokia have sold out to microsoft and there is no way I’ll have windows on a phone. My N900 is now a dead end and actually looks (and feels) like a dinosaur compared to the galaxy S2 I now have in my shirt pocket.
Mick
I have an iPhone – a decision simply made by balancing out risk/benefit like any technical person who knows how easy it is to blow a budget :), and Apple has as yet not really abused client data (not that they get much from me, but it was a factor that counted).
Sure, I fall prey to the shiny factor too, but it’s at least not driven by any herd instinct – I have no need to “belong” to a club (it was actually an initial barrier to buy an iPhone, but the benefits just tipped the scale). I was fed up dragging too many devices around, which would include an iPod. That’s also why I installed Tomtom navigation on it (instead of feeding all my location queries to either Google or Microsoft) – I have used Android but I just don’t like the user interface, and the constant coaxing to feed it a Google account before much of the functionality became available got on my nerves..
Author
Peter
Many of my friends (including some highly technical and competent people) also have iphones. Some also have android devices. You pays your money… Personally I’m disappointed that Nokia went the way they did and dumped Maemo. That had real promise at one time.
One interesting point I have just found (which I may post about soon) is that it is impossible to use the GPS navigation application on an android phone without a data connection (to google of course). A naive view would be that a GPS connection would be all that was necessary, but not so. I have just re-purposed my old HTC wildfire with a pay-as-you go sim which I have had for some years as a backup to my main account. That sim has voice and text only so there is no data connectivity at all. I tried yesterday to get the wildfire to act as a satnav (as I used to do when it was my main ‘phone). No joy whatsoever. I got an error message saying that the ‘phone could not connect to my google account (which you know you have to have to get any real functionality from an android device). Fascinating.
Mick
Author
Update.
I’ve now found a free, off-line, android navigation app called Navfree. This app uses no data connection once the maps have been downloaded. Further, it uses openstreetmap maps and not google’s maps. So I /can/ now use my old HTC as a satnav.
You may find this link interesting: https://research.nq.com/?p=402
They have found (yet another) bit of Android malware, but this one is SMS controlled. It appears to have quite a feature set..
I have an Android phone somewhere in a cupboard. It only comes out when I go to London and need a mobile access point (pay as you go SIMs are *very* handy :). The rest of the phone is not used *at all*..
Regards, Peter
Author
Yes Peter, but as I said in my email, nq.com are selling a product which “protects” against the malware they are discussing. Classic AV company behaviour (they all do it) – talk about a threat, then offer a cure. And this company is based in an interesting part of the world too.