-
Oddly, I had this expectation confounded just today, when Birkbeck’s submissions system didn’t send me any confirmations about the pieces that I submitted for assessment. ↩︎
-
And probably plenty of other mail clients. ↩︎
OffMail
I just got an invite/reminder email about a service called OnMail. I must have signed up to be notified when it became available. Could have been months ago: they apologise for it taking so long.
They should apologise for being bad for the email infrastructure that binds the world together.
I’m exaggerating, but only a bit. Email remains the most important thing on the internet aside from the web. Whenever you sign up for a service, or order something online, you expect to get an email confirmation.1
Without reliable email, a lot of things would fall apart.
A while back I wrote about Hey, the new email service from Basecamp. There, I was bothered by it not being based on the standard, open protocols that underlie email, at least to the extent that you can’t get your Hey email using a third-party, standard client.
OnMail seems both visually and functionally similar to Hey, and it’s got exactly the same problem.
This trend is bad for email, bad for people who use email. It should be possible to give us the kind of powerful, automated controls over our inboxes that these services offer, without stopping us from using the apps we prefer. It is possible to do that, as companies like SaneBox show.
I do not like this trend.
HEY, Ho, Let's Not Go
This has been sitting around in my drafts folder for about a month, so it’s long past time to get it out there.
HEY (they always capitalise it, which I don’t care for) is a new email service from Basecamp, makers of fine (I’m told) collaboration software for teams. The video walkthrough lasts about half an hour, but/and gives you a good overview of what it’s like.
Hey was also in the news recently over the way Apple was treating it regarding App Store rules. Apple were clearly in the wrong, and things have been sorted out now.
But that’s all another story. I want to talk about Hey, and why I think it is bad for users. Even at the same time that it’s probably good for users. A company, a service, can — like a person — contain multitudes.
The Good
If you watch that video you’ll see that Hey looks like an unusually interesting and capable email client: good for organising mail, getting the unimportant stuff out of your way until you want to look at it, and making the important things highly visible. It’s both powerful at automatically helping the user, and attractive to look at.
The Bad
But it’s built on a proprietary platform. Email’s biggest strength since its invention has been that it was built on open standards. Whether you were using a Unix command-line client at a university in the early days, or Gmail, Outlook, or another IMAP provider today — none of that matters. If you know someone’s email address, you can contact them, and they you. And more importantly for this discussion: if you want to use different email client software, you can.
That’s because email is built on open protocols: SMTP, POP, and IMAP. Not that you have to understand those – or even know about them – to use email, any more than you have to understand an internal combustion engine to drive a car.
More importantly, if you want to change from one email provider to another, you can do so. This is harder than it should be because the culture of people having their own domain never really caught on. All those josmith1989@gmail.com and hazy_harriet@hotmail.com type of addresses could, instead, have been jo@josmith1989.net and harri@hazyharriet.org.
They still could be, in fact. And when they are, then you can change the underlying email provider without anyone other than yourself having to know or care. To take a not-made-up example, martin@devilgate.org used to go by a complex combination of Gmail (for the spam filtering and search) and 5quidhost.co.uk and its eventual purchaser, TSOHost, because that’s what I used for web hosting, as much as anything else. But a few years ago I switched it to Fastmail. No-one I correspond with had to know anything about the change.
But Hey’s email service does not use the open protocols — principally IMAP — that makes all that possible. Instead they have their own proprietary system. If you move your email into Hey’s service, you might not find it too easy to move it out again.
Secondly, right now they don’t support custom domains, so your correspondents will certainly have to know. While josmith@hey.com might be available right now, if they have any success we’ll soon be back to appending birth years or random numbers to the end of common names, just like on Gmail, Hotmail, etc. Though they have said they intend to support custom domains, so there’s scope for a better solution there.
The Alternatives
Andrew Canion had the same thought I did when I watched the video: you can do most of this in MailMate.1 At least the viewing, the ‘The Feed’ kind of thing. Though he had the added experience of using SaneBox to automatically file and sort your emails.
Andrew also went further than I did: instead of just thinking, ‘I could do that with MailMate,’ he went ahead and did it, and documented the process (with a tiny bit of help from yours truly).
I had heard of SaneBox through its sponsoring of various podcasts, so I was familiar with the idea, but I hadn’t tried it. I’m now trying it out, along with some of Andrew’s suggestions, and it’s altogether a pretty good setup. Now, all that comes into my main inbox — the only things that appear on unread counts, and hence activate icon badges — are actual emails that I want to see. All the newsletters, receipts, confirmations, and other stuff that isn’t spam but that I don’t want appearing in my inbox, and especially in my unread count — those are all there, but tidily away in other mailboxes, where I can deal with them at my leisure.
That said, SaneBox is not free (though it’s cheaper than Hey), and I don’t get that much annoying email. So I don’t think I’ll continue with this exact setup when the free trial ends. But it’s worth knowing that there are good ways — and standards-compliant ways — to achieve similar functionality to Hey’s.
We Built This City on IMAP
What this all shows is that there’s nothing in Hey’s service that you couldn’t create by building on top of IMAP, except the user interface – and that doesn’t have to know about the underlying protocols in any case. It’s possible that is exactly what they have done: implemented it on top of IMAP. In fact, doing anything else would mean giving themselves a lot of extra work, as they would have to effectively reinvent IMAP in any case.
If I were going to build a service like Hey, I’d start with an off-the-shelf IMAP service, probably open source, and build the filtering rules and all that around it.
So I hope that’s what they have done, and that at some point in the future they make their service available to ordinary email clients via IMAP.
Beware of Email Apps Storing Passwords
Email apps, especially ones that offer advanced services like “send later,” may be storing our usernames and passwords on their servers.
To be clear what that means: if you use Gmail, for example, you put your Google username and password into the app when you set it up. You expect the app to store them securely on your device. But some apps may also be storing that username and password — your keys to all the Google services in this example — on computers owned by the company that makes the app. Computers over which neither you nor Google has any control.
I’m not suggesting that the company I talk about below, or any other, is doing anything nefarious. They need to be able to log in to your mail server in order to send your mail later. But I hadn’t realised until now what that means, and I’m guessing neither will a lot of people. And to my mind they don’t make what they’re doing clear enough.
Worst of all, having passwords stored on unknown servers — at the very least, that’s worrying.
Background
On episode194 of the Connected podcast, Myke Hurley and Federico Viticci were reviewing the latest version of the iOS (and Mac) app Spark. It’s a fine email app, which I was using on my iPhone and iPad. So I was alarmed when they mentioned in passing that mail handled by the app is routed through Readdle’s servers. That didn’t seem likely at first. Spark is an email client. You tell it what servers handle your mail, and it connects to them to receive and send. The servers belonging to the company that makes the app have no business getting involved in that.
I did some digging. Whether or not Myke was right™ about mail going through their servers, the reality turned out to be much worse.
Digging
I tweeted at the Spark account. Here’s what happened:
@SparkMailApp Hi, I was listening to a podcast today on which it was suggested that if I use Spark, then my email is routed through your servers. Is that true?
— Martin McCallion (@devilgate) May 25, 2018
Which podcast said that?
— Terry Blanchard (@terryblanchard) May 25, 2018
The latest episode of Connected, with Myke Hurley and Federico Viticci.
— Martin McCallion (@devilgate) May 25, 2018
The only time Spark servers access your email is to create a push notification (to create sender, subject, and message snippet) The content is cached until the notification is sent, but removed after that.
— Terry Blanchard (@terryblanchard) May 25, 2018
OK, seems fair. Thanks. Probably all a misunderstanding, either by them or me. Just out of interest, is the “send later” feature done on the client?
— Martin McCallion (@devilgate) May 25, 2018
Ah, forgot about that one! We will store it on our server until the send later time, then we send it through your email server and it is removed from our server.
— Terry Blanchard (@terryblanchard) May 25, 2018
OK. Isn’t that a problem, in that you must be storing your users’ mail server credentials on your servers? I’m pretty sure it doesn’t say that in your Ts&Cs.
— Martin McCallion (@devilgate) May 25, 2018
It’s the second item that we mention in our privacy policy. https://t.co/WpQSIDGPgx
— Terry Blanchard (@terryblanchard) May 25, 2018
I had already found their privacy policy:
OAuth login or mail server credentials: Spark requires your credentials to log into your mail system in order to receive, search, compose and send email messages and other communication. Without such access, our Product won’t be able to provide you with the necessary communication experience. In order for you to take full advantage of additional App and Service features, such as “send later”, “sync between devices” and where allowed by Apple – “push notifications” we use Spark Services. Without using these services, none of the features mentioned above will function.
The wording “Spark requires your credentials to log into your mail system in order to receive, search, compose and send email messages” suggests that Spark the app needs to log into your server, which it does. But nothing about that says that your credentials will be stored on their servers.
Further down, in point 4, “How Long Personal Data is Stored For,” in a table that includes “Type of information,” we see (emphasis mine) :
Email address, email content for Spark Services, mail server credentials
So there it is. They do store your username and password on their servers, and they do tell you; though only if you read well into the kind of document that notoriously goes unread.
Final Thoughts
For features like “send later” they need to store the fact that you want to send an email at a specific time, and log in to your server in order to send it. And to be fair, I’m sure they can’t be alone in keeping that kind of data. Lots of clients offer “send later” and similar services, and all of them will have to log in to your mail server to work. So they have to store your credentials on their servers to do it.
And consider, if you use Gmail, that means your username and password not just for Gmail, but for all Google’s services, are now stored on somebody else’s servers. Their security might be great, but how do we know?
The more I think about this, the more concerned I become. Passwords should only be stored in one place: a secure, trusted password manager. But above all, these services need to be much clearer about the fact that they’re storing our passwords.
The Strange Case of the Lost Reply
I’ve tried various email clients on iOS, but for quite a while now my favourite has been Dispatch from Clean Shaven Apps. As well as the many integrations and efficient handling of archiving and deleting emails, I like it because it is one of the only apps that lets you order mail in the One True Way.
Which in case you’re wondering is oldest at the top. Newest at the top is fine for blogs and similar news-based things, but it’s not right for anything else. Call me old-fashioned, but that was the default in Eudora and probably in Mutt and Elm and all those too, and it was and remains the best way.
Even Outlook lets you order it oldest-first. Though disturbingly few people take advantage of it.
Anyway, that’s not the point. The point is that today Dispatch let me down. I was typing a reply on my iPad this morning. The reply composition window looks like this:
I did something — I’m not sure what — that made the composition window slide off to the right. Part of it was still visible, so I tried tapping on it. And it disappeared.
There was no prompt, and nothing in my drafts folder. All that I had typed was gone, like tears in rain.
I’ve just been trying to reproduce it, and I can, up to a point: if you slide the compose window to the right it goes off out of the way, like this:
Which is actually quite useful, because it makes the compose window non-modal and lets you interact with your other messages. But somehow something can go wrong, even though I can’t make it happen now.
Not the end of the world. I retyped the mail. But that’s not good enough, Dispatch. You have to be able to trust your email client.