EmailΒΆ

To anyone at all familiar and comfortable on an internet-connected desktop, email is an old hat. You write your messages and send them through the web and those from others are in turn sent to you.

Typical expectations of email comes in two varieties: web applications and local clients. Web applications, like Google GMail, are equally functional on any operating system. In the realm of local applications, graphical email clients ship standard on most all spins of Fedora Workstation, including,

  • Thunderbird
  • Evolution
  • Claws Mail

In these chapters, neither graphical clients nor web apps are covered. Both are covered extensively elsewhere and strive for an intuitive user experience. Instead the focus holds to a third category, which might be described as a stack solution.

Stacks vs. Apps

When users open Thunderbird, what they expect from the application is a complete and feature rich graphical email client. For instance, it should send and receive email, it should provide a viewer so that they can read their messages and allow them to write messages, maintain an address book, provide search and notification functionality. It should also do whatever other features that its competitors offer.

By contrast, a stack provides none of these things. That is to say, instead of expecting everything from a single application, you determine what features you do need and implement solutions to provide them. For instance,

Application Description
OfflineIMAP Download messages
IMAPFilter Filter messages
mutt Read messages
vim Write messages
Msmtp Send messages
BBDB Address book

When the user starts their system, systemd units running OfflineIMAP and msmtp handle sending and receiving emails, mutt provides the reader and vim the writer while BBDB the address book. In combination, you have all the base features of a graphical email client like Thunderbird managed through a stack of lower level applications.

Reason for Stack Solutions

Question: Why use a stack solution? The standard graphical client is certainly easier to work with and set up, so why go through the trouble of individually configuring a half-dozen applications to reach the same goal?

It’s similar to the concept of a block and tackle. Where, by stringing a rope through several blocks, you gain in strength at the expense of travel time. Building a stack solution from lower level utilities does require a higher skill-level in the user and time in terms of research, configuration and implementation, but for all that you gain efficiency, power and control.

To wit, the more decisions you have to make the greater control you have over what it does.

For instance, most graphical clients provide the user with an interface for filtering messages. This is usually something in the settings where you can use a series of context menus to define what messages you want to filter and then use a similar series to define what you want Thunderbird to do with the messages once it finds a match.

The limitation in this case is what the developer provides you. Alternatively, in a stack-based email solution, you might use IMAPFilter to handle the same job. But, where in Thunderbird you use a series of menus, in IMAPFilter you script the filters using the Lua programming language, which provides you with an overwhelming superiority in both match granularity as well as what it does in response to matches.

< Prev Next >