nmh-workers
[Top] [All Lists]

Re: Is nmh suitable for managing multiple email accounts?

2021-03-06 20:59:42
I assume you want to keep the email from each account separate?

Yes, that is correct.

I've been an MH user going on 33yrs.

I'm curious: what did people commonly use for reading mail when MH was
just invented? Was it the Unix "mail" program?

Start with the realization the nmh is *not* a monolithic email client as
Mutt/Elm/pine.  Each command within the nmh suite is a separate command 
line executable.  nmh uses standard unix file structure for folders (which
are directories) and messages (which are stored as files).  There is no
IMAP support, so the email must be received locally to your machine.

In my case, I use fetchmail, and every 5 minutes it downloads my email from
two different servers that I use for my personal email.  Those emails are
co-mingled, so I don't know which email actually received them unless I look
at the headers (which are not displayed by default).  Since you mentioned a 
work account, I would think you want to keep those emails separate.

I use a GUI front-end for nmh, called Sylpheed (found at
https://sylpheed.sraoss.jp/en/) and have been quite happy with it for over
a decade.

Okay, I will take a look at these in more detail. I am currently
experimenting with fetchmail. I will try to experiment with the others
too.

Using different UNIX accounts ensures 100% separation. You can do
everything under one ID in theory, but you'll spend a lot of effort/time
switching email IDs via different profiles. My opinion is that this will be
error prone unless one has a lot of self discipline.

And I'll second the suggestion.  It is the easiest, cleanest solution and
avoids any possible confusion where you sent a work email via a personal
account *or* sent something personal via your work email.

I understand that this ensures that the accounts stay separate, but
managing multiple user accounts is not exactly light work. I guess the
use of separate UNIX accounts may be appropriate for particular use cases,
but I do not need such a strict separation at the moment.

<Prev in Thread] Current Thread [Next in Thread>