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.
