5 ms·

"The guy is absolutely right. Mutt is not a gimmick like ascii video on terminal." I personally use (al)pine and I could not agree more. But here is a differe

by rsync 8y ago

"The guy is absolutely right. Mutt is not a gimmick like ascii video on terminal." I personally use (al)pine and I could not agree more. 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. So, for instance, when I send an email to one of my engineers at rsync.net, even though it is sent in plaintext, it is a private communication and cannot be intercepted by either an ISP or some global observer. It's nothing but a local file operation between two mailspools... Further, it would be extremely difficult to phish someone who is viewing their email in the terminal. The effort that it takes to view and copy a URL is greater than the discernment required to identify it as suspicious - so you'll catch them every time.

zokier 8y ago
> 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?
- dsr_ 8y ago
  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.
- kbenson 8y ago
  > 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?
  - digi_owl 8y ago
    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.
    - canhascodez 8y ago
      Multiseat is a bit complex under X11, but certainly possible today. What do you see as the advantages of thin clients, though?
      - kbenson 8y ago
        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).
        canhascodez 8y ago
        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.
        kbenson 8y ago
        > 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.
sitkack 8y ago
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 http://repo.or.cz/alpine.git
- kbenson 8y ago
  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/ http://alpine.x10host.com/alpine/.
- rsync 8y ago
  "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...
  - sitkack 8y ago
    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.

by rsync 8y ago

zokier 8y ago

> 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?

dsr_ 8y ago
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.
kbenson 8y ago
> 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?
- digi_owl 8y ago
  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.
  - canhascodez 8y ago
    Multiseat is a bit complex under X11, but certainly possible today. What do you see as the advantages of thin clients, though?
    - kbenson 8y ago
      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).
      - canhascodez 8y ago
        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.
        kbenson 8y ago
        > 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.

sitkack 8y ago

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 http://repo.or.cz/alpine.git

kbenson 8y ago
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/ http://alpine.x10host.com/alpine/.
rsync 8y ago
"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...
- sitkack 8y ago
  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.