A lot of my "personal workflow" is built around Internet Email. Maybe it's old-fashioned, but I prefer it for a lot of reasons both technical and others.
However, as email has fallen out of favor the range and quality of email software has decreased. I thought maybe I could personally invest in the ElementaryOS Mail application (potentially in money and labor) but I'm starting to wonder if maybe it's time for me to write my own email client? Doing so would allow me to try a few things that I've always wanted in a mail client, and also means I could build it using whatever tool I want without inheriting a "tech stack", codebase, features I don't want, etc.
The first thing I would do is separate authoring and reading mail so that when I want to write a message I am not first confronted with my inbox. This sort of distraction is exactly the opposite of what I want when I'm trying to initiate a communication, but virtually every piece of communications software works this way.
The next thing I might do is decouple any sort of technical troubleshooting from the authoring process. When I send a message I don't want to be forced to immediately fight with the underlying email system if something goes wrong. Conversely, I want it to be obvious and trivial to dive-into that problem at a later time when I'm up for fighting with it. Most mail programs present a dialog when mail fails to send, and if you don't address the problem immediately, it can be very hard to find your way back after dismissing this message.
Let's consider format for a moment. Both plain text and HTML email should be possible, but both should be cleanly constructed and properly encoded. Working on Preposter.us, I've seen the "raw" form of email messages sent from many clients and the amount of nesting/nasty HTML and missing plain text is a source of frustration for me trying to parse these messages. I might even consider authoring all messages in plain text, and allow markup to be entered directly as HTML tags...
What else?
Obviously all the cleverness seen in contemporary "email" like Googles gmail are out. No AI (unless you consider spell check to be intelligent), no moving mail around automatically, etc.
Some sort of simple and obvious mechanism for moving any "local" data would be important. I'd prefer to avoid that altogether and keep any "state" in IMAP structures but minimally things like unsent mail might need to be stored locally and therefore should be easy to discover, move to another computer and access there without complex and deliberate export/import tools.
I don't think I want any anti-spam or other safety/security features in the client itself. I think those things are best left to the mail network. I'm a bit torn about handling inbound HTML email because so many nasty things can be embedded in it. My first thought is to present it raw, and make it easy to open the message in a separate web browser which can more thoroughly implement the various protections needed when opening any HTML content. I think this is both more robust and less redundant than rendering HTML inside the email application.
I don't know off-hand how I'd go about building this unless I write it as a console/terminal application. If I'm to forgo rendering HTML as described above, this might be an option. I do feel like it would be preferable to have a GUI application when such an interface is available, but right now I don't have a programming environment for GUI applications that I want to work in. I suppose I could start in the console and then re-write for the GUI if something I like comes along.
Jason J. Gullickson, 2026