Client for reading several big mailing lists

Question

I’m using Thunderbird for all my emails. I want to keep using it for regular emails, but I’d like to use a different tool for reading mailing lists.

I’ll save almost all mailing list mails, so it must not delete old mails automatically, and it should handle big amounts of mails well. Currently, I have around 18300 mails.

Must have:

• I want to keep every list in its own folder (or whichever concept the new client uses).
• Use thread view.
• Allow folding threads.
• Show the full thread (e.g., allow scrolling horizontally).
  On this screenshot, Thunderbird stops showing the subject line after 23 levels (and cuts it off much earlier), as it doesn’t allow to scroll:

Nice to have:

• Allow also writing/answering mails.
• Detect when mails are CC’ed to several lists and mark them read in all lists as soon as I have read it in one of them.
• Allow saving each mailing list’s web URL and password (for changing settings).
• Allow (manually) moving mails into correct threads.

Formal requirements

• It must be FLOSS (Free/Libre Open Source Software).
• It can be a local client (GUI or text-based) or a web app (for installation on my own server). In both cases, it must run natively on GNU/Linux.

Answer 1

I suggest you have a look at mutt. It's a text-based mail reader by design, which when coupled with a text editor, a sorting mail delivery agent and in past versions a mail transfer agent (for both sending and receiving mail) forms a highly versatile mail client.

Must have:

• I want to keep every list in its own folder (or whichever concept the new client uses). YES. Is usually done by setting up mail sorting through tools like procmail, but you can also use mutt's built-in filtering capabilities to create either on-disk or virtual folders for each mailing list.
• Use thread view. YES. Mutt has very good support for threading, including manually breaking and joining threads (at any message).
• Allow folding threads. YES, with limitations. Thread folding is supported, although you can only fold the entire thread, not fold the children of a particular message in the middle of a thread. It also unfortunately forgets the fold status when you reload or otherwise exit the mailbox.
• Show the full thread (e.g., allow scrolling horizontally). MOSTLY. Mutt does not artificially limit the width of the display, and it has a "narrow tree" option allowing more levels to fit on the screen, although it doesn't natively support horizontal scrolling. It does its best to make efficient use of limited horizontal space by offering configuration settings controlling whether related index entries are displayed in full (particularly the subject) when the context can be determined from other lines visible on the screen.

Nice to have:

• Allow also writing/answering mails. YES, with limitations. Recent versions of mutt are full-fledged email clients when used together with an external editor. With past versions you needed a mail transfer agent as well. I'd expect most people actually use it with a separate mail transfer agent such as fetchmail (for receiving) and possibly SMTP relayer (for sending) and mail delivery agent like procmail (for sorting).
• Detect when mails are CC’ed to several lists and mark them read in all lists as soon as I have read it in one of them. NO. No such functionality is built-in. However, messages in the same folder that have identical message-IDs are detected and can be handled as groups. Also see below.
• Allow saving each mailing list’s web URL and password (for changing settings). NO. Mutt is very explicitly a MUA and as such does not directly support storing supplementary metadata.
• Allow (manually) moving mails into correct threads. YES. See above about breaking/joining threads. It's also good at determining where in the thread hierarchy posts that lack complete threading information should go; it rarely places them exactly where they should go, but in my experience most of the time comes very close. Such messages are also specifically marked in the display when using threaded display mode (which is only one of the many index sort modes it supports).

Formal requirements

• It must be FLOSS (Free/Libre Open Source Software). YES. Mutt is released under GPL 2 and up, which I believe most will consider a true FLOSS license.
• It can be a local client or a web app (for installation on my own server). In both cases, it must run natively on GNU/Linux. YES. Mutt is at home on Linux, and being a text-based application should have no problem being built for other platforms. It doesn't run through a web UI, but you could probably coax it into a web-based SSH client...

Perhaps the biggest downside of Mutt is its highly non-discoverable user interface. It relies on sometimes by default quite obscure key bindings, configuration is done strictly through a text configuration file, and in general it comes with a very steep learning curve even for simply getting started. However, once you overcome the learning process, it is very fast to work with. Online help is readily available almost everywhere by pressing ? (by default, can be changed too). It is also extremely configurable, so you can basically tailor it to your own personal needs even on a per-mailbox basis.

One possible downside, depending on your usage, is that the search feature by default is pretty naiive, and this is exacerbated if you use a mailbox format that uses a single file per message such as MH or Maildir (which frankly I'd recommend). This can to some extent be mitigated by turning on header caching and/or by using specialized tools like for example mairix. Particularly header caching with the cache stored on fast media, even a RAM-backed tmpfs (as well as OS-level disk and file caching), can speed up searching through large mailboxes very much, if you are able to use header data in your search queries ("patterns" in mutt's parlace).

As for detection of duplicates and merging of their read status, I'm fairly certain that mutt has no special ability to detect duplicates between different folders; they are just two separate messages. If they are in the same mailbox, messages with duplicate message-IDs in the same thread are displayed together with an = displayed in the thread tree to indicate that they are identical; I don't know how it handles that case when there are multiple, disparate threads involved. In principle, you could write a script to parse all mailboxes outside of mutt (I imagine formail would come in handy for header extraction, though obviously repeated invocations would come at a price) and if identical messages are found in different mailboxes but with different status, merge their status according to some specific rule set. Such a script should be relatively easy to put together particularly if you are using Maildir, and could then be run either through cron at some short interval or (probably better) through a mutt folder-hook that triggers every time you enter a new mailbox.

Answer 2

I use Claws Mail for both my regular E-Mail and my Mailinglists as well.

As you can see in the following image it allows horizontal scrolling:

This image also shows the embedded body viewer on the bottom right. If you (like me) prefer to have your messages open in a separate window: Thats not a problem and works out of the box by double clicking them.

It is also a splendid Mailhandler with a working search engine that crawls through my 100k+ Mails in about 5 Seconds. A feature that I found very useful is that it doesn't display all results in one flat pane, but highlights the folders where it found something and then displays the mails only for that folder when you select it. That way you not only have filter on your search elements but on the reference topic that comes with your folder structure.

You can filter Mail on arrival by the targeted address (or any other thing, quite a mighty filtering system it has) and sort it into folders by that criteria to ensure elements for one ML only lands there.

It has one downside thats next to unimportant for me but may be bothering you: The filters are applied top to bottom in a list, so if you filter for "TARGET X" first and then "TARGET Y" and receive an email that has both (and no other criteria is applicable) than one of the filter will win over the other. So if you receive Mail that gets cross posted to different Mailinglists AND you use the same E-Mail Address on both AND there is no Header info that can distinguish them consistently you will get this E-Mail in one folder twice and in the other its missing. I'm certain that you can filter it out through the server that send it, but keep it in mind. - If you only want to read MLs just create an own receiver for each of them and filter on that.

Claws Mail allows folding, ignoring, selecting, moving etc. on threads and if you happen to have users on some lists that you never want to read AND don't care about their threads either you can create a filter rule that ignores that user AND the whole thread underneath them. (By ignore I mean that the thread is still visible in the list, but will be marked as read and unimportant automatically)

The configuration of Claws has its own design idea and needs some getting-used-to.

Image taken from this site which has some further infos on Claws Mail togther with recommended plugins, guides to encryption in Claws etc. might be a bit outdated, though.

Your dots:

• I want to keep every list in its own folder (or whichever concept the new client uses). YES
• Use thread view. YES
• Allow folding threads. YES
• Show the full thread (e.g., allow scrolling horizontally). YES

Nice to have:

• Allow also writing/answering mails. YES, with templates and stuff, but not WYSIWYG HTML Mail.
• Detect when mails are CC’ed to several lists and mark them read in all lists as soon as I have read it in one of them. No, not that I know of, but I haven't been looking
• Allow saving each mailing list’s web URL and password (for changing settings). Kinda Mail Account Data is stored. But the occational Mail from Mailman that tells you your ML password can't be structurally stored (you can have an own folder for that)
• Allow (manually) moving mails into correct threads. Kinda You can alter the Mail manually as it is stored plain on HD, but thats not what you want to do. I haven't tried anything else myself.

Formal requirements

• It must be FLOSS (Free/Libre Open Source Software). YES
• It can be a local client[...], it must run natively on GNU/Linux. YES