[jcrawfordor]

A very traditional way to run a mail system is to have the mailserver store the user's mail in their home directory, typically in either maildir or mbox format. Mail clients can then read mail directly from the same place the mail server stores it, rather than having to maintain their own copy. This is a very handy optimization and a lot of "traditional" (read: TUI) mail clients fully support and, indeed, were primarily designed to be used this way. Common TUI mail clients tend to assume a local maildir or mbox, and accessing mail boxes via IMAP is a feature bolted on later, sometimes a bit awkwardly.

A major advantage is that it allows all of the mail tools you might use to operate on the same working copy of your inbox, saving a lot of time synchronizing things. This was a lot more important historically when a typical Unix user would probably have a few different tools they used for mail, like a full-on TUI mailbox viewer and a couple of CLI tools.

I don't find it very compelling that Thunderbird needs to add this functionality, because that's a pretty old-fashioned way of running mail that you probably won't see outside of technical universities and other institutions with a very "traditional" approach to their systems. That's the use-case, though, and I do see that if you are in an environment where your mail is already present in your home directory, or you use multiple mail clients, it would be annoying that Thunderbird can't operate this way when a lot of its contemporaries can.

It's practically more of an issue, though, because Thunderbird kind of supports it, it's just incomplete. That makes it feel less like a feature Thunderbird doesn't have and more like a bug.

[eru]

One nice thing about maildir is that eg command line grep just works.

[anthk]

Also reading maildirs it's much faster than an mbox file.

[eru]

Yes, if you have a good enough filesystem, that doesn't mind reading thousands of tiny files. Or housing tens of thousands of files in a directory.

(I suspect that wasn't always the case. Especially over NFS or so?)

[anthk]

Yes, over NFS it's slow, but nowadays everyone has local devices or they just login via SSH or virtualize whole desktops.

Still, if you have over 100k emails, mbox will be slow to parse for obvious reasons as it has to parse every line with often having mboxes as huge as 500MB if not more. Your FS and VFS layers will do a far better task on reading the first lines of thousands of files. In such case your mail client will parse the headers to generate the inbox layout in a much faster way.

[jcranmer]

> Still, if you have over 100k emails, mbox will be slow to parse for obvious reasons as it has to parse every line with often having mboxes as huge as 500MB if not more.

No, you don't. You store in your metadata database what the offset of the message in the mbox file is. If you don't have such a metadata database, then you're going to be very slow no matter what the storage is.

[anthk]

Load a GB sized mbox into mail(1) and then say that again.

Mbox it's just a literal

cat mail/*.msgs >> mbox

setup.

Reading will be slow, and file locking will be hell.

Unix should've switched to maildir long ago. Since 1999 storage and inodes are not a problem any more.