Introduction

Several years ago, my main workstation at work became a PowerBook G4 running Mac OS X. I tried using the included Mail.app, but I missed the flexibility of Pine, my favorite mail client. So I set to compiling and installing it on my laptop. It wasn’t initially obvious how to work around the Mac-isms, but so far I’ve been able to get most things to work as well as they do on my Linux boxes.

Since then, I’ve migrated from Pine to Alpine, its successor. At least one Pine developer has said that it’s not too much of a stretch to say that Alpine 1.0 could be considered Pine 5.0. In a standard terminal window, Alpine looks and acts pretty much like Pine, but under the hood there have been some substantial code revisions. Among other things, Alpine works and plays pretty well with UTF-8 (aka Unicode) characters and typefaces. Also, the license has been altered, making it likely that people will be able to distribute patched binary versions of Alpine—something not permitted under Pine’s license.

I should note that I don’t store any mail locally; my inboxes and folders are all on remote IMAP hosts. I assume that a local mail store on a Mac will work as expected, but I don’t have any experience with it.

Compiling

Pine had a idiosyncratic build process, but with Alpine the UW development team began to use the GNU autoconf system. The migration isn’t complete—too many legacy operating environments supported by the c-client code can’t use it—but the developers have hinted strongly that they’ll be dropping support for many older environments in the near future. The upshot is that while Alpine builds using the standard configure script, there’s still several old Pine build scripts under the hood.

To build Alpine on OS X, you’ll need to install the Xcode package. My hunch is that anyone interested in using a command-line mail client on the Mac has already done that, but stranger things have happened.

The latest versions of Alpine require OpenSSL version 1.0.0c or higher. macOS 10.13 ships with LibreSSL, so I chose to link Alpine against a third-party OpenSSL installation. I use MacPorts, but a lot of people use Homebrew. The script below assumes a MacPorts version of OpenSSL, but it’d be easy to modify for Homebrew.

#!/bin/sh

# use macports, esp. for openssl
export PATH="/opt/local/bin:/opt/local/sbin:${PATH}"

# create a build directory, or empty it if it already exists
BLDDIR=/var/tmp/alpine-build
test -d $BLDDIR || mkdir $BLDDIR
/bin/rm -rf ${BLDDIR}/*
pushd $BLDDIR

# fetch the source
git clone https://repo.or.cz/alpine.git
pushd alpine

# configure and build
CPPFLAGS="-I/opt/local/include -I/opt/local/include/openssl" \
LDFLAGS="-L/opt/local/lib -lintl" \
./configure \
  --prefix=/usr/local \
  --without-tcl
make

echo
echo "when you're ready for installation, run"
echo "  sudo make -C ${BLDDIR} install"
echo
exit

# eof

OpenSSL Certificates

If you’re connecting to your mail server using a secure SSL or TLS session, you will likely encounter Alpine’s dreaded SSL/TLS Certificate Validation Failure warning:

There was a failure validating the SSL/TLS certificate for the server

                         mail.blah.com

The reason for the failure was

         unable to get local issuer certificate (details)

You will see this message even if your server has a certificate signed by a well known Certificate Authority (CA) like VeriSign or Thawte.

Since this version of Alpine is linked against a non-system OpenSSL installation, you’ll have to figure out where it keeps its store of recognized CAs. For MacPorts, the file is off in /opt/local:

• /opt/local/share/curl/curl-ca-bundle.crt

You’ll need to add the certificate(s) you want to that file manually:

cat /path/to/your/ca.crt >> /opt/local/share/curl/curl-ca-bundle.crt

Then relaunch Alpine.

Running in Terminal

I’ve tried running Alpine both in the standard Terminal utility and in the xterm provided by X11 for Mac OS X (aka XDarwin). It works in either environment, but I prefer the Terminal because it’s got better cut-and-paste support and it seems to handle character-set issues better.

I use a larger font for mail than I do for regular Terminal sessions. For me, 12 or 13 pt. Monaco works well, and it looks even better with anti-aliasing turned on.

You can verify the antialiasing check box by navigating to Terminal -> Preferecnes… -> Profiles -> «name of profile» -> Text

The Terminal application has several different profile, each with its own colors and fonts. You’ll need to repeat the previous check for each different profile.

Helper Applications

Mac OS X makes it easy to launch helper applications for viewing URLs embedded in messages or attached files like images, PDF files, MS Word docs, or whatever. The secret lies in the open utility, which knows all about which applications you prefer for which MIME types.

Opening URLs with your default browser

Two settings need to be tweaked if you want to be able to view URLs embedded in messages sent to you. First, you need to enable enable-msg-view-urls option. Second, tell the url-viewers option about open:

url-viewers="/usr/bin/open _URL_"

Note that the quotation marks are necessary to preserve the whitespace.

That’s it! If someone sends you something with some text that even vaguely resembles a URL, it’ll appear in bold within your Terminal. Use the up or down arrows to highlight it, then press the Enter key. Your default web browser will appear and begin loading the page.

Opening URLs with a different browser

I’ve gotten to the point that I prefer opening URLs embedded in e-mail messages with Google Chrome in incognito mode rather than with my default browser, which happens to be Safari.

I was unable to configure this change completely in my .pinerc file, so I ended up writing a wrapper script and referencing that script in my alpine configuration.

The script itself is pretty simple. See the open(1) man page for details.

#!/bin/bash
/usr/bin/open -n -a "/Applications/Google Chrome.app" \
  --args --incognito --dark_muted "$*"

I installed that script as /usr/local/bin/url-viewer and then pointed alpine that way:

url-viewers="/usr/local/bin/url-viewer _URL_"

Opening attachments

Alpine relies on the system mailcap to associate any given MIME type with the application used to execute it. The Darwin build Alpine doesn’t include a default search path for mailcap, and OS X doesn’t include one anyway. Overcoming all this is pretty simple.

Modify .pinerc so that it knows how to find your mailcap:

mailcap-search-path=~/.mailcap

Create a simple ~/.mailcap file that essentially relies on open and LaunchServices for all its MIME savvy:

application/*; /usr/bin/open %s
audio/*; /usr/bin/open %s
image/*; /usr/bin/open %s
text/*; /usr/bin/open %s
video/*; /usr/bin/open %s

I also like to open HTML attachments with incognito Chrome. If you’d like to do the same, just add this line to the top of your mailcap file:

text/html; /usr/bin/open -n -a "/Applications/Google Chrome.app" --args --incognito --dark_muted %s

That does it. Alpine is now able to launch attachments without any trouble.

Printing

Wisely, Apple’s software developers tied command-line printing into the larger print system, so lpr and its ilk work as expected. Printing from Alpine is therefore just a matter of getting the output formatted according to your tastes and piped off the lpr. Personally, I like the e-mail formatting provided by enscript, which formerly was included with Darwin but is now available via MacPorts.

printer=enscript [] enscript -Email -G -j --margins=36:36:36:36

The one potential pitfall of this recipe is that it will only send output to your default printer. If you want to send mail to a different printer, then you’ll have to change your default printer before printing from Alpine, or you’ll have to set up a separate definition for each potential printer using enscript’s -P option.

Mac