# sup is a console mail client for people with a lot of email

> Sup is a Ruby curses email client built around threads, tags and a rich search query language, with hooks that let you script behaviour. Its own documentation is candid about the cost: changes do not always sync back to the mail source, and it plays badly with other clients.

**sup-heliotrope/sup** — A curses threads-with-tags style email client

- Repository: https://github.com/sup-heliotrope/sup
- Website: https://supmua.dev
- Stars: 971 · Forks: 99
- Language: Ruby
- License: GPL-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/sup-heliotrope-sup

## A curses client aimed at mailboxes that overwhelm a GUI

Sup is a console-based email client for people with a lot of email. The wording matters, because it sets the target: the problem is not reading mail in a terminal, it is reading a mailbox whose size makes scrolling lists and folder trees useless.

The interface is curses based, the kind of full screen terminal program that uses keyboard commands instead of a mouse. That choice puts it in a specific tradition of Unix mail tools, and it explains the rest of the design. When your mailbox holds tens of thousands of messages, the useful operations are search, tag and mute rather than browse, so those are what the feature list leads with.

The topic list names email, mua, ruby and tui, and the project describes itself as a threads-with-tags style email client. That is a fair summary of the whole idea: messages are organised by conversation thread, threads carry tags, and a tag such as mute means a thread stops asking for attention without being archived away.

The project ships as a Ruby gem, with sup.gemspec at the root of the repository, a Rakefile, a Gemfile, and the usual supporting directories of bin, lib, test, doc, contrib and devel. The home page is supmua.dev, and there is a mailing list at supmua@googlegroups.com with archives published on the same site.

## Threads, tags and muting instead of folders

The first feature in the list is GMail-like thread-centered archiving, tagging and muting. The feature list borrows Google's description deliberately, because that is the mental model it expects you to bring.

Thread centring means a conversation is the unit you act on rather than a single message. When a reply arrives, it joins the thread, and the client is responsible for grouping conversations that the message headers describe inconsistently. That grouping is where most of the practical value sits for a heavy mail user, since it collapses a dozen scattered replies into one row.

Tagging replaces the folder tree as the primary organisational device. A tag can be applied to a thread, and because tags are not locations, the same thread can carry several at once. Muting is then a status rather than a move: a muted thread stays where it is and keeps its tags, but it stops demanding attention.

The difference from a conventional client is that nothing is destroyed or moved on disk when you archive. Nothing in the project's documentation describes any physical move or copy of messages as part of archiving, tagging or muting, which is consistent with the source model discussed further below.

A smaller but telling feature is automatically tracking recent contacts. In a client whose main verb is search, having the people you correspond with surface automatically is a way of avoiding a lookup you would otherwise have to write.

## Search is the primary interface, and it has a query language

The feature list calls out blazing fast full-text search with a rich query language, and the wiki has a dedicated page on searching your mail. That combination tells you where the centre of gravity is.

Full-text search matters more here than in a GUI client because there is no scrolling window to work with. You do not browse, you ask. The query language is the interface, and it is described as rich, which in this context means you are expected to learn it rather than type a few words into a box.

The operator list is not enumerated in the project's own notes, and the wiki page is where the details live, so the practical difference between Sup and a client with a simple search box is entirely in that syntax. Anyone evaluating it should plan on spending time with the searching wiki page, because the value of the tool is only as good as the queries you can write.

The performance claim is made in the feature list without a number attached, so treat it as a design intention. What the repository layout does show is a Ruby implementation with a test directory, and the alternatives section of the project's documentation explains the technical lineage by pointing to Notmuch, which was inspired by Sup, and to mu and mu4e, which are described as a search-based email back end also implemented using Xapian.

That is a meaningful detail. It tells you the search-first model came from the Xapian based world of mail indexes, and it tells you where to look if you want a comparable architecture to compare against.

## Multiple sources and accounts, and the sync gap that comes with them

Sup handles mail from multiple mbox and Maildir sources, and it supports multiple accounts, letting you pick the right one when sending mail. Both of those are table stakes for a serious client, and both are listed as features rather than described in detail.

The limitation is stated more forcefully, and it deserves the same weight as the features.

The project's documentation states that Sup does in general not play nicely with other mail clients, and that not all changes can be synced back to the mail source. It then points to Maildir Syncback in the wiki as a recently included feature, which allows syncing back flag changes in messages and writing messages to maildir sources.

Read that carefully. The syncback is recent, it is described as recently included, and it covers flag changes and writing messages. That is narrower than full interoperability, and it means the failure mode for a shared mailbox is concrete: you flag or move a thread in Sup, and another client reading the same mailbox may not see it, and Sup itself may not be able to write the change back where the other client expects to find it.

This is why Sup and a desktop client on the same account is a setup to avoid unless you read the wiki page on using Sup with other clients first. It is also why the source support matters: mbox and Maildir behave differently, and Maildir's per-file flag storage is what makes the syncback feature possible at all.

## Ruby hooks are the extension point, and also the ceiling

Ruby-programmable hooks appear in the feature list as a feature, and then uses them again in the alternatives section. If Sup is missing a feature you are interested in, it says it might be possible to accomplish it using the powerful hooks mechanism. Otherwise, it points you to other clients.

That framing is honest in a way many projects are not. Sup is not trying to grow by absorbing every request. The hooks mechanism is the answer for the small number of things you need that it does not do, and the wiki page on hooks is where you learn what it can reach.

The consequence for an adopter is that you should read that page before you commit, not after. A hook-based workaround is fine if it is a small, stable thing. It is a bad foundation for a core workflow, because you own that code and you own its compatibility with future Sup versions, and the maintenance posture below makes clear that the direction of travel is stability rather than extension.

The Unix-centrism limitation sits in the same part of the documentation and deserves the same attention. MIME attachment handling and sendmail invocation are Unix centric, which in practice means an attachment path or a mail transfer agent assumption that will not match a Windows workstation or a deployment that does not run a local sendmail compatible binary.

## Installing Sup, and where to go when something breaks

The project's documentation does not give an installation command. It links to the wiki for installation, and that is where the steps live.

```bash
https://github.com/sup-heliotrope/sup/wiki#installation
```

The project is packaged as a Ruby gem, and the repository contains sup.gemspec, a Gemfile and a Rakefile, so a gem install is the likely shape of it, but no command is stated and I will not guess at one. Read the wiki page.

Support channels are listed in the project notes. Bugs go to the GitHub issue tracker for the project, there is a wiki, and there is a mailing list at supmua@googlegroups.com, which you can join by sending to the subscribe address and whose archives live on the project's site.

```bash
supmua+subscribe@googlegroups.com
```

That mailing list matters more than a modern project would expect, because of the maintenance posture described next. This is software whose users help each other, and the archives are likely to hold the answer to the problem you are about to hit.

The default branch is develop, which tells you where active work happens, and the repository carries History.txt and ReleaseNotes alongside HACKING and CONTRIBUTORS, a structure that comes from a project with a long history rather than a recent rewrite.

## A stable client with a GPL-2.0 licence and two credible alternatives

The documentation has a maintenance status section that is unusual in its directness. Sup is described as a mature, production-quality mail client. The maintainers are long-term users and mainly focus on preserving the current feature set. Pull requests are very welcome, especially to fix bugs or improve compatibility, and pull requests for major new features are unlikely to be merged.

That is a project telling you what it is. Fixes and compatibility work gets merged, redesigns do not, and the feature set you already know is the feature set you will keep. The last push was on 2026-10-18 and the repository is not archived, so the code is being worked on within that boundary. There are no GitHub releases, so version tracking lives in the gem and in History.txt.

The alternatives are named with their differences spelled out, which is more helpful than a bare list. Notmuch was inspired by Sup and has a wide variety of clients, with Alot described as the most similar in look and feel, also curses based, and shipping a built-in Sup theme. mu and mu4e are a search-based back end also built on Xapian, with an emacs based front end that is quite different. The choice is between a curses client that shares Sup's model, and a different front end over a similar indexing idea.

The licence is GPL-2.0, and the copyright header quoted in the documentation records both the Sup developers from 2013 onward and William Morgan for 2006 to 2009.

```text
Copyright (c) 2013--     Sup developers.
Copyright (c) 2006--2009 William Morgan.
```

GPL-2.0 is a copyleft licence, which for a client you run yourself on your own machine carries no obligation to publish anything, but it does matter if you distribute a modified build or embed Sup in something you ship. That is a question for your legal team, and this is not legal advice.

The maintenance posture is the real finding. Sup is not going to grow, and the way to extend it is Ruby and hooks, so the decision to adopt it is a decision to adopt a finished design with a scripting seam.

## Conclusion

Sup suits a person with a mailbox large enough that a GUI list is useless, who wants threads, tags and search as first class ideas and is willing to learn a query language. It does not suit a shared or multi-device setup where another client also writes to the same mailbox, because Sup does not in general play nicely with other mail clients and only recently gained Maildir Syncback for writing flag changes back. Before adopting it, read the wiki pages on adding sources and on using Sup with other clients, and check that the hooks mechanism in the wiki covers the automation you would otherwise expect from a modern client.

## FAQ

### How do I install Sup?

The project's documentation links to the wiki for installation rather than giving a command. The project is packaged as a Ruby gem, with sup.gemspec, a Gemfile and a Rakefile at the root of the repository, so the wiki page on installation is the place to get the exact steps.

### How does Sup handle threads, tags and muting?

The feature list names GMail-like thread-centered archiving, tagging and muting as the first feature. Threads are the unit you act on, tags carry organisation rather than location, and muting marks a thread so it stops asking for attention without being archived away.

### Can Sup sync changes back to my mail source?

Not in general. The documentation states that Sup does not play nicely with other mail clients and that not all changes can be synced back. A recently included feature called Maildir Syncback allows syncing back flag changes and writing messages to maildir sources, which is narrower than full interoperability.

### What can I do if Sup is missing a feature I need?

The documentation suggests trying the Ruby-programmable hooks mechanism first, and points to the wiki page on hooks. If that does not cover it, it names Notmuch with the Alot front end, and mu and mu4e, as alternatives to consider.

### Is Sup still being developed?

The last push was on 2026-10-18 and the repository is not archived, but the project's documentation states that the maintainers mainly focus on preserving the current feature set, that pull requests for major new features are unlikely to be merged, and that fixes and compatibility improvements are welcome.

### What licence does Sup use?

Sup is released under the GNU General Public License version 2, with the copyright header covering the Sup developers from 2013 onward and William Morgan for 2006 to 2009. The GPL-2.0 copyleft terms matter if you distribute a modified build rather than running it for yourself.

## Sources

- [Issues](https://github.com/sup-heliotrope/sup/issues)
- [License: GPL-2.0](https://github.com/sup-heliotrope/sup/blob/develop/LICENSE)
- [Project website](https://supmua.dev)
- [README](https://github.com/sup-heliotrope/sup/blob/develop/README.md)
- [sup-heliotrope/sup on GitHub](https://github.com/sup-heliotrope/sup)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sup-heliotrope-sup