Tag: e-mail

Posted on
by

I installed delta.chat on my phone, to play with, nudged by Frank’s posting. It’s a E2E encrypted chat application with a twist: it uses e-mail as infrastructure. You set it up like an e-mail client, giving it access to one of your e-mail accounts. It will then use your e-mail account to send PGP encrypted messages.

So it’s actually a tool that brings you encrypted mail without the usual hassle of PGP set-up. Because it uses mail, you can find your messages in your regular mail archive (but encrypted), and you can contact anyone from the app if you have an e-mail address. The first message you send will be unencrypted (because you nor the app knows if the receiver has delta.chat installed), afterwards it will be encrypted as the app will have exchanged public encryption keys. Using e-mail means it’s robust, it doesn’t suffer from ‘there’s noone on here’ and there’s no silo lock-in. It also doesn’t need your phone number. It does ask for access to your contacts, which I denied as it is not at all a given that people will run delta.chat with the e-mail addresses they normally use.

I’ve tied it to my gmail address for now (ton dot zijlstra at gmail, ping me on delta.chat if you use it), because I wanted to have an easy interface to check what is going on in my inbox, and I have gmail on my phone anyway (even if I don’t use it for anything). I may switch over to a dedicated e-mail address later.

Some screenshots to illustrate:


How my initial exchange with Frank looked in Delta.chat


How my message to Frank looked in my mail. As it’s the first message it was unencrypted.


How I received Frank’s reply, which has an encrypted attachment.


The encrypted attachment when opened in a text editor shows it’s PGP.

I haven’t explored whether I can export my keys from Delta.chat. If you can’t, without Delta.chat I have no way of opening them. It’s a local tool only, so I suspect I might be able to get access to the keys outside of the app.

Posted on
by

Leaving Gmail, a tough question
In the past two years I have been slowly reconfiguring my online routines to increase privacy safeguards, and bring more of my data under my own control, while avoiding making my work routines more difficult and thus less routine. How to create an e-mail workflow that does not rely on Gmail has been the hardest part of this effort. I think I now finally have figured out how to do it without loss of convenience, and hope to have made the switch after I finish exporting all e-mail data Google has from me.

mailinbox
After 12 years this will no longer be a familiar sight for me

Previous steps I took
Some things I already did to increase my control over my own data are:

Not that I don’t use anything but my own stuff now, I also am still a heavy user of various services, like Evernote for instance, or my Android phone. But the usage of third party services has become more varied and spread-out, reducing the impact of losing any one of them.

Why I want to leave Gmail
The net is a distributed place, and our information strategies and routines should embrace that distributedness. In practice however we often end up in various silos and walled gardens, because they are so very convenient to use, although they actually decrease our own control and/or introduce single points of failure. If your Facebook account gets suspended can you still interact with others? If your Google account gets suspended, do you still know how to reach people? Using Gmail also means all of my stuff resides on servers falling under the not very privacy sensitive US laws.

Since July 2004 I have however completely relied on Gmail. It is an easy way to combine the various e-mail addresses I use into 1 single inbox ( or rather multiple inboxes on the basis of follow-up actions), and it has great tagging, search and filtering so that you never need to file anything or sort into folders. I have used Gmail as my central inbox for everything. Since 2004 I have accumulated about 770.000 emails in 249.000 conversations, for a total of 21GB. Gmail is therefore the largest potential single point of failure in my information processing.

The issues to solve
To wean myself off Gmail there were several things for which I needed a similarly smooth working alternative:

  • All the mail addresses I use need to come together into a single mailbox, and conversations need to be threaded
  • Availability across devices, and via webmail. Especially on the road I use my phone for quick e-mail triage, and as alternative for phone calls. Webmail is my general purpose access point on my laptop while traveling
  • Having access to my full mail archive for search and retrieval
  • Excellent tagging and filtering possibilities

The steps I took to leave Gmail
Finding a path away from Gmail took two realisations, one about process and one about technology.

Changing my process
Concerning process I realized that Gmail allows me, or even invites me, to be very lazy in my e-mail processing routines. Because of the limitless storage I merely needed to be able to find things back (through the use of tags for instance), and never needed to really decide what to do with an e-mail.

This means for instance that lots of attachments only live on in my mailbox, without me adding them to relevant project documentation etc. Likely I spent hours in the past years searching for slide decks in my mountain of e-mail, in stead of spending half a minute once to store and archive an attachment in a more logical place where I’m more likely to find it with desktop search, or serendipitously bump into it, and then throw the mail message out. So mail processing has to become a much less lazy process with a few more active decisions in handling messages. E.g. attachments into a project folder, contact info into contacts, book keeping related messages to bookkeeping (and no longer going through all mail tagged bookkeeping every quarter to do my taxes), tasks and actions to my Things todo application. I already wrote several Apple Scripts to let my todo app and Evernote talk to various other software packages (like Tinderbox), but it is now likely I will write a few more to automate mail message processing further (because I prefer to still keep my process as lazy as possible).

Changing my tools
A second key realization was that my original reasons for staying within webmail had meanwhile been solved with better technology: it used to be that only Gmail provided the cross-device access to all my mail accounts simultaneously, something I could not easily do in 2004 with a desk/laptop mail client in combination with a mobile mail client. Now, with much broader IMAP support (not just by my software tools, but also by hosting companies) this is much easier, increasing the range of possible alternatives. Threading mail conversations is now also a more universal feature.

This now allowed me to start using Thunderbird mail client, including PGP encryption, on my laptop (I never intensively used a mail client before on my laptop), in combination with the open source K9 Android mail app (replacing the Gmail app for me), also with encryption options. Both allow tagging of messages, and Thunderbird allows filtering for not just incoming mail but also when sending and when archiving, which is really useful.

As an alternative to piping all my mail accounts into Gmail, I now use all the real inboxes of those mail accounts where they’re originally hosted, and use IMAP to combine into one user interface on my laptop and mobile. Those separate mailboxes do have lower storage limits (usually 500MB), so it is more likely I bump into limits, and that is the reason I need a much less lazy mail processing routine (especially concerning larger attachments), in which I can regularly archive older mail.

Separately I also now use a different webmail provider, Protonmail in Switzerland, that comes with default encryption. I’ve attached a domain name to it (zylstra.eu).

The archiving issue
The above shows how leaving Gmail moving forward from the here and now, by solving the one-inbox and the multiple device issues can be done by changing process and tools. That leaves the question of how to deal with the 21GB of mail archive from the past 12 years. Leaving it all in Gmail, and use that as archive might be a work-around for old mail, but doesn’t help me for future mail. I could add it as a local folder to the Thunderbird mail client, but that thought did not appeal to me and feels clunky. I find that I never use my mail archive from my mobile, so the archive does not need to be cloud based per se. So, I opted to keep my mail archive local, by storing it in a mysql database. This allows for query based searches, and even text mining, without it clogging up my mail client itself. Gmail can export your archive in a single MBOX file, and I used Mailsteward Pro to transform it into a mysql database. (More on that set-up in the next posting Archiving mail in mysql with MAMP and Mailsteward). With the archive now locally stored, the database is backed up to both my NAS drive and my VPS.

What remains
With the basic set-up for leaving Gmail now in place, there is still work te be done over the coming months. Clearing out the archive at Gmail is one step, once I feel comfortable with searching my new mysql archive. Creating more filters in my mail client, and writing a few scripts to integrate my mail processing with the other tools I use is another. There are also likely a whole bunch of things (accounts, subscriptions etc) that use my gmail address, which I will change as I go along.

My longtime blogging friend Roland Tanglao suggested to mine my mail archive for things that could be published, contact data, harvest old ideas that can feed into my work now etc. This sounds appealing but needs some contemplation and then a plan. Having the archive in mysql makes it a lot easier to come up with a plan though.

Beyond mail, there are of course more Google services I use heavily, especially Calendar, which are tied to my gmail address. I could move that to my Owncloud as well. I will keep my Google account, as this isn’t about ditching Google but about reducing risks and taking more control. Apart from Calendar there are no other single points of failure in the way I use my Google account. Beyond Google, Evernote is another silo I’m heavily invested in, and the content I keep there is arguably more valuable to me than my Gmail. So that is a future change to think about and seek alternatives for.


I reached Inbox -1 on Gmail once in 2009 🙂

[Find the outline and slides of my Koppelting session on leaving Gmail in the follow-up posting at https://tzyl.eu/leavegarden. You can use the shortlink https://tzyl.eu/gmail to refer to this posting.

Posted on
by

Today I changed the way we use e-mail addresses for identification on-line.

Over time my e-mail address(es) has (have) become the carrier of a lot of important stuff. It’s not just a way to communicate with others, but also serves as generic user name on countless website accounts. And likely quite a few of those have had their security breached over time, or are unscrupulous (or even malicious) in their own right.

As part of a talk on privacy by Brenno de Winter (Dutch investigative journalist) that we went to this weekend (see previous posting), he mentioned using unique e-mail addresses (and pw’s of course) for every site you use. Or disposable e-mail addresses for sites you visit only once. That way when one site gets compromised there is no risk of your user credentials being used elsewhere, and if one site sells your email addresses on it is immediately apparent to you who did that.

I have been aware of this advice for a long time, but never saw an easy way to act on it:

  • Most disposable e-mail address (DEA) services offer a temporary e-mail address, usually enough to quickly confirm an e-mail address, after which it gets deleted automatically. This is useful for one time visits / registration at a website, but not for using unique addresses for services you use more often.
  • Some sites do not accept e-mail addresses that are clearly created by DEA type services
  • I own multiple domains, which I could theoretically use for unique mail addresses, but in practice that is much more unlikely. I would need to either create mail addresses before using them to register somewhere, through the domain’s administration panel, or use a catch-all that would simply accept any incoming mail on that domain, including tons of automatic spam flung out to randomly generated e-mail addresses.

    • What I actually need is:

  • The ability to create new e-mail addresses on the fly, simply by using them
  • The ability to both have more permanent unique addresses, as well as single use addresses
  • Using a domain that is not perceived as a DEA service and not easily associated to me (e.g. by visiting its website)
  • Using a domain that I control so I cannot get cut off from unique addresses connected to important user accounts
  • The ability to recognize any of these unique addresses in my regular inbox
  • Something that still filters out spam, while accepting any incoming address

    • So today I decided to investigate further and act on it.
    This is the solution I came up with:

  • I found 33mail.com, built by Andrew Clark (in Dublin/Ireland so under EU regulations), that allows you to create addresses on the fly, and then through a dashboard simply block the ones that get misused at some point. It also forwards to one of your actual e-mail addresses, including letting you (anonymously) reply from the unique address.
  • 33mail.com allows you to connect any other domain to their service, so that instead of using something@myaccount.33mail.com I can use something@myrandomdomain while still using 33mail. This is very useful as it helps to prevent being filtered out because of using a DEA service domain, and keeps the addresses under my control.
  • I registered two new domains, one for me, one for Elmine, and set up their MX DNS records to point to 33mail. So that anything@ourtwodomains.tld goes to 33mail. These domains are, apart from the records at the registrar, not otherwise easily associated to us.
  • I provided two unique email addresses for 33mail to forward to at two other domains I own and use.
  • I set up two auto-forwards for those addresses that 33mail forwards to, which makes it end up in one of my or Elmine’s regular inboxes. In our inbox we have filters that pick up on anything that comes from those forwarding addresses 33mail sends stuff to.

    • This is not a free solution, but it is cheap. The registration of two domains, plus a service package so I can set my own DNS settings, with our regular hoster comes to 45 Euro or so. 33mail charges 8 or 9 Euros for a premium account, which is needed to add your own domain name to their service, and I created a premium account for each of us, as we will be using two seperate domain names. Total cost: 65 Euro/yr.

    Here’s a drawing of the full set-up:

    33mail