Rssgoemail 1.0.0

In the end after some work we released rssgoemail 1.0.0.

Announcement

This post wants to explain a bit the rationale behind writing such tool. There are already good feed readers out there, right? Well, it depends. In theory I could have used rss2email to achieve the same thing, but it had some problems:

It's written in Python.

It's written in Python, with way too many external dependencies.

It does not support the gemini protocol.

Rssgoemail have external dependencies, of course. It didn't make any sense for me to re-invent the wheel when I could have concentrated only on what was missing: parsing gemsub pages in search for links. Also, I strongly prefer to deploy a small binary, compared to the clusterfuck that are python's venvs and such.

The tool is written in Go and you can, pretty much, deploy the binary almost anywhere and have it work.

Why did I create it?

I created rssgoemail out of a bit of frustration. I love RSS/Atom and I tend to have quite some feeds that track. The problem is, in this days and age, it's quite common for me to read stuffs both from my computer, phone, e-book reader and whatnot. But there is no standardized protocol to share a feed implemented by some common open source application. Sure, I could have made a webapp, downloaded and shared the xml files or similar, but why not use the most widespread tools, present in every UNIX-like system?

Being also an OpenBSD user, my choice was quite limited and, for some time, i used the RSS plugin for claws-mail. Of course that approach didn't scale with my need to share feeds across devices.

In the end, /usr/sbin/sendmail is everywhere.

How does it work

Rssgoemail needs only one external program, /usr/sbin/sendmail and the USER environment variable. Simply put, every item feed fetched by rssgoemail is delivered to USER's local mailbox, by piping a properly crafted message to the sendmail binary.

In essence, how the e-mail is finally delivered to the user, is totally a matter of the local MTA. What does this mean, in practice? It means that you could have many different setups, where rssgoemail simply acts as a "feeder" to the e-mail subsystem. Everything else, from filtering, to delivering, to consulting, is responsibility of all the other programs in the chain (MTAs, MDAs, IMAP or POP servers etc..).

My personal setup involves fetching the feeds on my mail server, with all of the items delivered to my ~/Maildir, every day at 7AM. I later consult my feeds either from my computer or my phone via IMAP:

My setup

Of course, another kind of setup may be totally local, so that you can read your feeds from your computer, as they are delivered to either your Maildir or your user classic mail spool file:

A canonical setup

In every case, the flexibility provided by a properly configurable MTA let you setup things as you wish.

Features

What are the rssgoemail main features and in what case should you care? Rssgoemail is, as far as I know, the only tool where support for the gemini protocol and for gemsub links are first class and that's one of the main reasons behind me writing my own thing. In particular:

Ability to fetch RSS/Atom feeds via HTTP[S] and Gemini.

Ability to fetch Gemsub links fro Gemini.

Custom SMTP headers, to let you decide if and how to automatically organize your feeds.

Caching of already fetched entries. This way we reduce feeds repetition.

And that's pretty much it! There are some annoying things that I would like to fix in the future, but those are not a big deal, like stripping the embedded HTML from the description field of an RSS, or generating the e-mails with proper MIME parts, to let clients render HTML properly.

But for now, it's good enough :)

Should you use it?

Rssgoemail was made for myself first, another bunch of people joined me and convinced me and added the gemini and gemsub support. If you are like us, and you want to comfortably consume your feeds, without any proprietary application, then rssgoemail is for you.

Cheers, and enjoy!