Graphical e-mail programs are all pretty awful. They're heavyweight, complicated, and difficult to use. Worse, they lock you into their idea of how you should save your mail. When they change, you lose your mail archive. They're also the second most useful mechanism, after web browsers, for spreading malicious software.
nmh is none of this things. It's simple. It's very lightweight. It does only what you tell it to do. Most importantly (for me), it uses the ordinary file system for archiving e-mail. It also embodies the UNIX method of small applications each of which does one thing well; it is potentially scriptable into anything you wish via traditional UNIX command-line plumbing. If you wanted to automate your mail handling with nmh (you can) you don't need a special scripting language. Just use bash (or perl, or if you like joining religious cults, python).
nmh does depend upon using the command line. This in turn presumes that you can read. For the most part, this is the same prerequisite involved in e-mail. (As we retreat into a new medievalism, there are new image-based communications alternatives for the growing number of people who can't read. If you're in that group, nmh is not for you.)
The Arch Linux version of nmh is in the Arch User Repository (AUR) at https://aur.archlinux.org/packages/nmh/
Download the tarball from the AUR and then do a normal PKGBUILD to install it.
Once installed, you need to make and/or configure several things. Every configuration will be different, of course; here I'm just recording what works for me (mostly so that I don't lose my notes when it comes to building the next system).
You need an ".mh_profile" file in your home directory. Mine simply contains:
Path: mail Editor: /usr/bin/vim
The reason to specify "/usr/bin/vim" instead of just "vi" is that the "classic" vi distributed as standard in Arch Linux has a bug in it which causes it to return 1 rather than 0 in certain circumstances even when everything is ok. (For example, if you do an ":r" which fails because the file you are trying to incorporate doesn't exist, and then ":wq", the $? retval is 1, not 0 as it should be. This in turn causes the "whatnow" component of nmh to fail.)
vim does not hav this bug. But nmh cannot pick up on the alias of vi to vim in your .bashrc, because .bashrc detects if it's running non-interactive and doesn't take effect for non-interactive shells. Specifying vim explicitly here (I go overboard with /usr/bin/vim, just in case) solves the problem.
An alternative solution was noted in the book "MH & xmh: Email for Users & Programmers," 3rd edition (O'Reilly & Assoc., 1995). (GNU GPL; a useful copy of the relevant section is online at http://stuff.mit.edu/afs/sipb/contrib/doc/mh-book/mh/wormes.html#AbDrMe This solution creates a short bash script which replaces vi; it invokes vi but itself always exits with a 0 return value:
vi $* exit 0
But so long as vim works, and you have vim, specifying vim in your .mh_profile is cleaner.
(nmh works with editors other than vi(m), but after 30 years vi is hardwired into the musculature of my hands.)
You need a mail directory. If the "Path:" set in .mh_profile is "mail", then this is "~/mail". (The default, I think, is "Mail" - but capital letters are annoying in system filenames.)
In your mail directory, you need at least two files: "components" and "context". It's been so long since I've done a from-scratch nmh installation that I can't actually remember if they're created automagically.
The "components" file specifies the mail headers. My "components" file allows me to alias myself behind a firewall by specifying the "From" and "Reply-To" headers of my outgoing mail explicitly. This is handy.
From: yourname@yourdomain.com Reply-To: yourname@yourdomain.com To: Cc: Fcc: null Subject: --------
When you're sending mail, a copy is put where-ever "Fcc:" says. To keep a copy in a meaningful location, each time you send an e-mail specify that meaningful location. Thus, for example:
... Fcc: +friends/somebodys-name ---
The "context" file simply specifies the current directory of nmh. Usually it's the inbox, but it need not be (it's changed when you change your current directory). Again, I can't remember if this file is created automatically or not. Mine usually says:
Current-Folder: inbox
In /etc/nmh, you need to change at least one of the overall configuration files. I find that I only have to change one, "/etc/nmh/mts.conf" ("mts" = Mail Transport System). The changes I make allow me to run as a single-user system behind a firewall, masquerading my mail such that it appears to come from my system (not the firewall). Your changes are almost certainly going to be different, but here's what works for me. First, make a safe backup copy of /etc/nmh/mts.conf and then (as root via sudo) in /etc/nmh/mts.conf change the lines (or make sure that the lines read):
... mts: smtp ... localname: yourmachinehostname localdomain: yourdomain.com ... masquerade: draft_from ... servers: smtp.yourisp.net
The "mts:smtp" line means that for outgoing mail nmh won't talk to your local mail system (e.g., the "sendmail" program, which is huge and a pain to install) but instead will speak SMTP protocol directly to the SMTP mail server of your Internet Service Provider (ISP).
The "servers: smtp.yourisp.net" line gives the net address of your ISP's SMTP mail server.
This is the only configuration that I need to do for outbound mail.
Receiving mail is slightly more complicated - but not much. I use two auxiliary programs to do this: fetchmail and procmail.
fetchmail is a simple program which logs in to your ISP's mail server and downloads all of your incoming mail to a spool file. procmail is a "Mail Delivery Agent" (MDA). It takes the mail from this spool file and splits it up into individual e-mails so that when I run "inc" in nmh everything ends up in my inbox as separate messages.
To install fetchmail and procmail:
sudo pacman -S fetchmail sudo pacman -S procmail
To configure them, create a file called ".fetchmailrc" in your home directory. Make sure that it has permissions not greater than "-rwx------" (this is important; fetchmail will refuse to run if it does):
cd $HOME chmod 700 .fetchmailrc
In it, put something like this:
poll mail.yourisp.net proto pop3 user yourusername mda "/usr/bin/procmail -d %T"
These fields are documented in the fetchmail man page. Basically, my configuration tells fetchmail to go to (poll) my ISP's mail machine, to use the POP3 protocol, and to grab mail using my username there.
As configured, fetchmail will prompt me for my password. It is possible to code your mail password in .fetchmailrc. Honestly, I don't know the security implications - your mail password is going out over the net in plaintext anyway.
The final bit, with procmail, tells fetchmail to use procmail to deliver your mail. The "-d %T" bit is important, because without it your downloaded mail won't be broken up into individual messages.
To download my mail and incorporate it into my nmh inbox, then, I simply do:
fetchmail inc
E-mail consists of three kinds of components: words, attached objects, and malware (viruses, etc.)
Words are only viruses to the human mind. They are indeed dangerous, but your defense against them is up to you.
Attached objects such as images, PDF documents, LibreOffice documents, etc., once detatched from the mail system and used by themselves, are easily contained. You can indeed embed malware in them (PDF uses Postscript, which is a Turing-complete programming language), but good reading/viewing software disallows bad behavior on their part. (That isn't to say that all such software is good; you must still be on your guard here.)
The problem with malware occurs when a flaw in the mail system, sometimes in conjunction with a flaw in the reading/viewing software, is taken advantage of automatically - without your even being aware that something might be happening. This happens over and over again. It's caused untold financial damage and personal heartbreak. It will continue to happen as long as people think that they need all-singing, all-dancing automagic mail systems because actually reading words and looking at images is too hard.
nmh does indeed come with a reading program which automagically decodes attachments and falls prey to them. (The "show" program.) I don't use it. Instead, I've coded my own very simple variation ("show2"):
more $HOME/mail/inbox/$1
It simply displays the underlying raw e-mail, in ASCII characters, to the terminal. This is about as susceptible to computer viruses as a fountain pen.
To view attachments, I simply cp the e-mail in its entirety to some useful place (typically the folder I have set up to archive that particular person's e-mails) and use uudeview to unpack and decode it. This leaves me with just image/PDF/etc. files which I can then view (or not) with an appropriate (and appropriately configured) program (geequie for images, mupdf for PDFs, etc.)
It's crude-but-effective. Moreover, viewing the entire set of mail headers gives me an excellent sense of where the mail came from. The extra time taken to uudeview attachments is trivial compared to the time not lost in recovering from malware automatically executed by a fancier mail reader.
My own use of nmh is very simple (and doesn't even begin to take advantage of its many features).
fetchmail inc
To list the contents of my inbox:
scan
To read an individual e-mail by inbox number:
show2 NUMBER
To archive an individual e-mail by inbox number:
refile NUMBER +path/to/location
(The +path/to/location is relative to ~/mail )
To delete an individual e-mail by inbox number:
rmm NUMBER
comp
Example. To compose an e-mail with a PDF and a JPEG attachment, start the nmh comp program in a directory where the two attachment files are located (you can use paths, but it's easier if they're just there). Add at least one line of regular text and two lines specifying the attachments. Your draft will look like this:
From: yourname@yourdomain.com Reply-To: yourname@yourdomain.com To: Cc: Fcc: null Subject: -------- Hi there, #image/jpeg [description-string] filename.jpg #application/pdf [description-string] filename.pdf
The [description-string] will be the title of the MIME section containing the attachment (it will become the "Content-Description" field). It is optional. The filename.jpg or filename.pdf is the content to be attached. You seem to need at least one line of regular text or the next step fails.
Then save and quit your editor (:wq in vi) to get to the nmh "What now?" menu. Reply with: mime Then edit the file to complete your message. (Or you can simply compose the e-mail all in one go and then:
What now? mime What now? send
See the man page for mhbuild if you want to get fancier with MIME stuff.
All portions of this document not noted otherwise are Copyright © 2014 by David M. MacMillan and Rollande Krandall.
Circuitous Root is a Registered Trademark of David M. MacMillan and Rollande Krandall.
This work is licensed under the Creative Commons "Attribution - ShareAlike" license. See http://creativecommons.org/licenses/by-sa/3.0/ for its terms.
Presented originally by Circuitous Root®
Select Resolution: 0 [other resolutions temporarily disabled due to lack of disk space]
