Why email will never be Free…

Hello! This blog is not dead and neither am I. It’s been a long while since I’ve written anything here and the site is starting to look a bit abandoned. I’ve been seriously busy with what I refer to as ‘life stuff’ over the last few months and my ‘tech-time’ has been a bit squeezed, so I haven’t had much to write about. I’m now getting back into the swing of things and starting to think of stuff to write about.

Email. We all use it. It works, right? Well for the most part. It’s probably one of the most used and simplest forms of digital communication available today. Shame it’s so horribly complicated then.

My major task over the last couple of weeks has been getting my new server set up so that it hosts my own email and provides accounts for members of my family. I’ve actually been doing this on and off pretty much since I got the server, but with the release of CentOS 6 I decided to cut my losses and upgrade sooner rather than later.

So I set out installing Postfix and Dovecot, following the instructions on the CentOS wiki pages. I managed to get through all the configuration of Amavisd, ClamAV and Spamassasin and I installed Roundcube for webmail access. Then I started thinking about adding users for my family and came to the decision that I didn’t want to add shell users for every email account, so I would modify my set up to incorporate virtual users and domains. After following a dead end of setting this up using plain text files (which turns out to be more fiddly to administer than shell accounts) I settled on using Postfix.admin with a database based system. Then there were my adventures with sieve, managesieve and Roundcube, which turned into a whole afternoon of getting nowhere.

Now my gripe here isn’t with the software. Far from it, all the previously mentioned software is excellent. Nor is it even with the documentation, although that is lacking in some areas, usually a quick web search will find you a useful forum post. No, my problem here is that I had to do all this in the first place in order to set up a Autonomous Free Software based mail system.

Given that I did this partly for the fun of it (yes I appear to like the pain of making tea), this isn’t really a problem for me. When I changed over my DNS everything pretty much worked, but I’m not your average user. Now, I know there are things like iRedMail, which can automate all this stuff and if I hadn’t wanted to learn how a mail system works I probably would have tried it. However, I’m skeptical as to the reliability of such a system.

This brings us to the crux of the problem. Email is too complicated! Think about all those disparate components I listed above, each of which is developed separately and has to interact seamlessly in order for the system to keep going. If one breaks, you’re screwed. I think this is probably worse in a iRedMail based system as the administrator would have no expertise in the inner workings of the system.

This leads me to my actual point (finally!). This is why people use Gmail, Hotmail, etc. It’s not because they would otherwise have to provide their own hosting, it’s because these services make it easy. I think what I’m basically asking for is “WordPress for email”. Something I can just unpack point it at a database and go, without having to know an what an RBL is. Yes, this wouldn’t be as easy as Gmail, but Blogger or Tumblr are easier than self-hosted WordPress and there are still tons of WordPress blogs out there. It would put Free Software based email within the reach of the ordinary computer literate person.

My fear is that the Free Software community treats email as a largely solved problem. We have loads of great software, which works for those of us with beards. However, until we make it easy to use, simple, cohesive and pretty, email is destined to languish in the land of the non-Free.

Server move…

This is just a quick note to say that if anyone experienced any site downtime over the last day or so this is due to the site being moved to my brand-spanking new Linode VPS. The site move is complete, but I’ll still be working on it over the next few days so there may be further disruption. Also, as I write this the DNS changes may still be propagating so you may not even be able to read this! As a result of the move there may be a few glitches caused by differences in configuration between the two hosts, please contact me via the comments below if you run into any problems.

SwallowCatcher 0.1.3 Released

Download SwallowCatcher 0.1.3
Download SwallowCatcher 0.1.3

I’m again proud to announce a new release of SwallowCatcher. This is a small maintenance update which fixes some of the backwards compatibility issues which people have been experiencing with pre-Froyo versions of Android. Thanks to @diabalomarcus, @fdroid and Henrik Tunedal for their help with this issue.

As always, please check out the project page and the gitorious page where you can download the source code. Feedback and bug reports can again be submitted via identi.ca, email or via the comments on this post.

Using Android WebViews

Recently I’ve been working on show notes support for SwallowCatcher. Since most podcast feeds include their show notes in the feed as embedded HTML I decided to render this HTML to display the show notes. This turned out to be ridiculously simple thanks to Android’s WebView class. The API for rendering arbitrary HTML within your app is almost Pythonic in its simplicity. However, there are a couple of gotchas which caught me out, so I decided to cover them here.

I started out by creating a new Activity class and a layout XML file for it. The layout XML was taken almost directly from the Android WebView Tutorial page:

<?xml version="1.0" encoding="utf-8"?>
<WebView  xmlns:android="http://schemas.android.com/apk/res/android"

In my Activity class the XML is loaded as normal. We also need to import the WebView class and the URLEncoder class. Additionally, the UnsupportedEncodingException class is required:

import android.webkit.WebView;
import java.net.URLEncoder;
import java.io.UnsupportedEncodingException;

Next, we need to encode the text in the correct format. Weirdly, WebView requires that the text is URL escaped, but without spaces converted to ‘+’ symbols. I used URLEncoder to encode my content then replaced the ‘+’ symbols with spaces. This probably isn’t perfect, but for my purposes it works.

String text = "<html><head></head><body>Content goes here!</body></html>";
text = URLEncoder.encode(text, "utf-8");
text = text.replace('+', ' ');

Finally, we find the WebView from the XML and tell it to load the string as its content:

WebView web = (WebView)findViewById(R.id.shownotes);
web.loadData(text, "text/html", "utf-8");

All the above is encased in a try..catch statement for UnsupportedEncodingException, just in case the URLEncoder has a fit. That’s pretty much it. In SwallowCatcher the ShowNotesActivity is 56 lines, including all the verbose Java imports and bootstrapping and loading the content from the database via ORMLite.

As a wise action hero (and ex-Jedi) once said, “I love it when a plan comes together”.

SwallowCatcher 0.1.2 Released

Download SwallowCatcher 0.1.2
Download SwallowCatcher 0.1.2

I’m proud to announce the release of a new version of SwallowCatcher. This version follows hot on the heals of the 0.1.1 release and fixes several bugs reported to me over the last few days. Specific fixes include:

* Fixed empty description tag problem (scratched by Linux Outlaws feed) as reported by @andyc in identi.ca.
* Fixed feed missing scheme validation problem as reported by @andyc in identi.ca.
* Fixed download permissions problem as reported by @andyc in identi.ca.
* Fixed individual feed refresh problem.

Thankfully, I have managed to hold onto my encryption key this time, so upgrading from version 0.1.1 should be smooth. Remember to check out the project page and the gitorious page where you can download the source code. Feedback and bug reports can again be submitted via identi.ca, email or via the comments on this post.