nmh-workers
[Top] [All Lists]

Re: Is nmh suitable for managing multiple email accounts?

2021-03-06 15:23:58
I manage 3 email accounts: my computer's mail inbox (/var/mail/me), a
work email account (work@example.org) and a personal email account
(me@example.net). Can I use nmh to manage all three accounts?

The answer to most "can I do this with nmh?" questions is usually "yes!".
With the exception of IMAP, sadly.  But the flip side is ... you usually
have to write that bit.  And we're not so great on documentation, and the
book you mention was written quite a while ago when dealing with multiple
email addresses was uncommon.  nmh has a lot of features that book doesn't
mention.

Now, with respect to others ... personally, having multiple Unix accounts
multiple email accounts, well, I would find that a HUGE pain in the ass.
All of my accounts go to a single inbox, it's been that way for over
a decade, and everything works great and I cannot imagine any other
way of doing things.

There are, basically, 4 things you have to deal with:

- How to incorporate email from multiple accounts
- How to select an appropriate value for a From: header
- How to send email 
- Minor configuration issues to deal with multiple accounts

In terms of incorporation, "inc" is the standard way of dealing with
that.  So there you either need to make sure all of your messages end
up in a single maildrop, or you'd need to write a small script to run
"inc" 3 times.  Which you'd pick is up to you.

Now for selecting the value of the "From" header, if you are using the
default components file you can use the "-from" switch to set the value
of the From header.  So you could create shell aliases like "compwork"
that was something like "comp -from 'Your Work Email <email@work>'".
You get the idea.  What I do is something a little more complicated;
I use the mh-format lanaguage to look for the value of a special
environment variable and if that is set it overrides my default From:
header.  That looks like this:

%<{from}%?(getenv MH_FROM)%|%(void(localmbox))%>%(void(width))%(putaddr From: )

Now, when dealing with REPLIES with 'repl', things get a little more
interesting.  What you'd like is to have repl figure out the correct value
of the From: header.  And ... for the most part, that is possible!  It's
just that figuring out an appropriate algorithm that fits easily into
the nmh tools can be "fun".

The components files are written in simple language called "mh-format",
and it's documented in mh-format(5).  When you are replying to a message
all of the message headers from the original message are available to
the components file used by repl (typically replcomps), so you can use
that to make decisons on how the headers of your reply will look like.
For example, my one mail provider sets a Delivered-To header when they
deliver messages to me, so if I see THAT then I use that to set the From:
header to the appropriate value.

Now, I guess I was being a bit ... generous when I described the mh-format
language as "simple".  It's simple in the fact that basically you only
have two variables (a string and an integer) and you have if/else statements
but no loops.  But the _syntax_ is a bit weird.  My advice is look at
the existing components files for help and use the provided "fmttest"
utility to see what they are doing.  And feel free to ask for help!

Now, for _sending_ email ... well, everything goes through the send(1)
command, so I'd start there.  There are basically two schools of
thought: one school says "send everything through your local MTA agent
like exim, sendmail, or postfix and configure it appropriately".  Now,
I PERSONALLY think that is ... crazy?  Like, no other MUA on the planet
requires that; nobody is telling Thunderbird users, "Ok, if you have
multiple accounts, you need to set up Postfix correctly".  And MTAs are
very complicated to configure!  I mean, if you WANT to do that, fine!
Go ahead and do that!  But I cannot recommend it to most users.

The other school of thought (and obviously the one I subscribe to) is
have nmh automatically figure out where to submit email and let it
do it for you when you run "send".  This is, of cours, assuming that
you are in a situation where you need to submit email to your email
provider's submission host; today that is very common.  There are a
bunch of ways to do that, but the simplest is to use nmh's "sendfrom"
facility.  This is documented in send(1), and the way THIS works is
nmh will automatically add specified switches to the post(8) command
when it finds an appropriate entry in your profile based on your From:
header (send(1) calls post(8) to do the actual sending).  So in your
.mh_profile, you'd have entries like:

sendfrom-user@work.com: -server smtp.work.com -user user@work.com -tls
sendfrom-user@personal.com: -server smtp.personal.com -user user -sasl

There are a lot of options to send(1) but hopefully they make sense.

The final bit is various other miscellaneous configuration you need to
do.  Right now nmh has a concept of a "primary" email address.  It takes
a guess based on your local Unix username and hostname, but in 2021 that
is almost certainly wrong, so you want to configure that using the
"localmbox" profile entry.  But for other email addresses, you want nmh
to know those are "local" email addresses so when you do things like
reply to messages it knows not to send them to you.  Those are configured
using the "Alternate-Mailboxes" profile entry.  That's really all you
need there.

--Ken


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