Is Alpine still getting security updates? UW doesn't maintain it anymore, like at all. It exists as git repo out in the ether [1]

I'd probably run it in a non-privileged container.

Infact, I should be doing that for Mutt ...

[1] http://repo.or.cz/alpine.git

"I'd probably run it in a non-privileged container."

Does mutt talk to the network or have a daemon or run as a service ? I don't know the answer to that but I know that for my own use-case, pine is basically a text editor. It executes no programs or code and does not talk to anything but the local SMTP daemon.

How much sanity checking and bounds checking does sendmail (or postfix or whatever) do on email ? That's the question, I think, because again, in my case, the threat vector is very limited - basically an arbitrary (weird) email or piece of an email that somehow breaks pine.

So no, I don't run it in a container - in fact, I run it as the user whose mail spool is the highest sensitivity asset that user owns ... so a container wouldn't help. If you get the mail spool, you get everything - at least or that user...

When I used Alpine, it was talking to IMAP and definitely segfaulted a couple times. But an RCE in Alpine != RCE in Postfix (great architecture). I dunno MUAs are so personal, they feel like a perfect place to target and handle more edge cases than upstream processes.

The last commit to that git repo was a couple days ago, and looking at the log, it gets a new commit every week or so. It may be under different stewardship now, but it definitely seems maintained. The last stable release was last year, but development seems to be proceeding nicely. The full site is at http://alpine.x10host.com/alpine/.

> But here is a different, and I hope very provocative, reason that you should consider a terminal email client:

> Local mail delivery does not traverse the Internet, or any network.

The implication here being that you are running the clients on the email server. Wouldn't you effectively get the same security by tunneling IMAP over SSH?

> The implication here being that you are running the clients on the email server.

That's a common scenario, but most linux/BSD distros ship with some mail server software installed and configured to run out of the box, even if also set to not allow external connections, as that's how the system delivers messages to users (e.g. cron output, etc). So almost every linux/BSD is a mail server, even if it may not be the mail server. If there's a main box that people in your company connect to as a terminal, email to local accounts on that box is essentially a internal messaging system. Hell, you could throw an IRC server on there with no outside access and use terminal IRC clients to have your own private chat channel as well. Who needs slack?

Unix have all kinds of funny things if all happens within a single box.

If you want to send someone a message, there is write (if the person have mesg set to yes). There is also talk, but it requires its own daemon.

Seriously, _nix started out in the mainframe era. Meaning that the basic assumption was multiple terminals hooked up to a single computer, with a different user on each terminal.

Sadly we have a generation or more that grew up with single user computers, and seems to insist on turning _nix into that rather than embrace what it can offer.

Multiseat is a bit complex under X11, but certainly possible today. What do you see as the advantages of thin clients, though?

I think the point wasn't to specifically lament the lack of thin clients, but the lack of knowledge about how the systems are really designed be multi-user, and actually multi-concurrent-user, as opposed to systems like windows which eventually gained multi-user capabilities, and even then concurrent use isn't exactly the common case (and I'm not sure how well it works in practice, but I imagine with RDP it works well enough on the server products).

All of these tools and capabilities still exist; there's probably still some Unix beards hanging out on Nyx and SDF. Yet here we all are having a discussion on HN instead.

> All of these tools and capabilities still exist

Yes... that's the point of the discussion. They exist, but there is (or is perceived to be) lack of knowledge about their existence and how to make use of them from some newer users, either because of the push for desktop linux, or for whatever reason.

> Yet here we all are having a discussion on HN instead.

I have no idea what you're trying to imply here. I suspect maybe we are discussing similar, but ultimately different, things.

I'm implying that multi-user systems were supplanted by web applications, because multi-user systems did not offer good value, and do not scale. Neither do I see these systems being advanced in this thread based on their utility.

Multiseat is a dirty hack. It is about using software to build a terminal out of a random collection of screens and input devices. All it has really done is give us yet another "session" to mentally track, in the form of consolekit/logind, on top of the kernel and X provides ones.

And it is not about thin clients, thin clients btw is yet another Windows-ism, it is about the concepts embedded in the unix concept that current day devs seems to either sidestep or downplay while building house of cards in userspace that poorly replicate said concepts.

You're not really explaining what it is that you think is missing from modern computing. From my perspective, none of this technology has gone away, but some things see very little use for good reasons.

IT IS NOT THAT IT HAS GONE AWAY, IT IS THAT THE CURRENT GENERATION IS IMPLEMENTING CRAP CLONES OUT OF IGNORANCE AND HUBRIS!!!

You are not entitled to speak to anyone like that, and neither wisdom nor correctness increase with volume. This is a comment which can only be dismissed. I am sure that you have much better arguments at your disposal, if you would condescend to employ them.

Any time you run the mail server and the clients connect directly to the mail server via encrypted paths (IMAP/S, SSH tunnel, VPN...) the Internet is not traversed, but the local network is.