Configuring Alpine

My web (and email) host back in 1997 had Pine (or was it Elm?) available for use at the command line when I would telnet into my account. I remember getting really fast at using that setup, sending quick email messages in a flurry of keystrokes. I loved it.

For long after, I used Eudora on various Windows desktops until I switched to the Opera browser’s M2 mail client (later spun off into its own product, "Opera Mail"). Then Gmail took over. But I never forgot the efficiency of that old text-based interface.

Lately, I found myself pining (ha ha) for the old days. And since I sit at this Slackware box all day long, I figured I should do something about it.

I always check the man page first. It was nicely written and lists all of the command-line options. But there’s nothing about configuration.

The web was more interested in telling me about Alpine ski resorts than configuring my email in 2018.

I finally broke down and took at a look at the Slackware alpine package and discovered this:

specifically

As it turns out, these are also currently availble to read online:

https://www.washington.edu/alpine/tech-notes/config.html

2020 update: The above link won’t work. Sometime in 2019, I believe, UW deleted or removed the alpine/ path entirely. Their built-in search reveals the same sorts of things you’ll find by doing a general Web search for the term "alpine". I find that to be pretty sad.

Since my system has these documents sitting right here in my filesystem, I can easily host them, so here we are:

The names of configuration elements in Alpine’s TUI interface have a close correspondence with their names in the configuration file (.pinerc). But in the end, I had a much better time editing the config directly. It’s actually quite freindly and is well documented:

Armed with this and the config.html document, we have what we need to figure this out.

The comments explain this one, you can leave it blank to use your full name from /etc/passwd. I went ahead and set it explicitly:

Believe it or not, this is where I got stuck in Alpine’s config interface. I couldn’t figure out what this was for. Turns out, it’s just the domain name to use for your email address. Sheesh.

My email host, Runbox, offers TLS/SSL on port 465 and STARTTLS on port 587. Their documentation indicates that 465 is prefered. As with many standard address schemes, the port number comes after a colon : character.

The syntax for smtp-server is specified under "Server Name Syntax" in config-notes.html or:

https://www.washington.edu/alpine/tech-notes/config-notes.html#server-name-syntax

I knew I needed to be authenticated as well, so this seemed useful: /user=<myname> (where <myname> is your username on the SMTP server).

And adding /tls requires a secure connection, which is what I want.

Thankfully, there is an example of using multiple parameters in the documentation. You just concatenate them all together. So here’s a try:

By the way, I’m used to calling this sort of thing a "connection string" when connecting to databases. So in my mind, I’m calling that thing a connection string, not an "address".

As near as I can tell, the closest thing we have to a standard for specifying SMTP addresses is this SMTP URL RFC. Clearly, Alpine does not follow the recommended smtp://example.com…​ format. So I’m pretty sure the smtp-server parameter is entirely Alpine’s construction. Elsewhere in the documentation, I noticed that it may be known as a "remote specification".

Okay, this is where it gets weird if you’re used to setting up standard desktop all-in-one GUI email applications. It makes way more sense if you consider the history of (Al)Pine’s original intended use.

Back when the woolly mammoths roamed the earth, users would routinely email each other on the same UNIX box. At its most primitive, mail was appended to a file which represented the recipient’s mailbox. Email client programs at the time were designed to read from the local mailbox file and display new messages, etc. To make multiple computers talk to each other, mail transfer agents like sendmail were used to update the inboxes of users on other systems over a network. But client email programs still read from a local file.

Today, you can still do that, but it’s much more common to use a host server (your ISP, webmail (Yahoo, Gmail), web host, or dedicated email host) exclusively. To keep up with the times, older clients like Alpine have added native abilities to speak IMAP, POP3, and SMTP to send and receive email directly.

Hopefully that explains why the IMAP or POP server is specified not in a logically-named config setting like "imap-server" or "pop-server" but as a path instead!

To quote the config document:

Okay, so with this background in mind, the format for specifying an inbox over an IMAP connection is {server}foldername where the {server} portion uses the same "remote specification" syntax as the smtp-server parameter above. I’m crossing my fingers and plugging in nearly the exact same info (changing only the port to make it correct for IMAP).

Example:

Again, this doesn’t follow any other known standard such as the IMAP URL Scheme RFC.

You might be wondering where the username portion of your reply ("From:") email address is specified? Right now, we’ve only set the domain portion.

The answer is that Alpine gets the username portion from UNIX.

If you set user-domain to @example.com and it looks like this when you request your username:

Then your email address is going to be tonka@example.com.

If that’s not what you want, then you can completely override the From: field in all outgoing email with the customized-hdrs parameter:

This is another instance where editing .pinerc directly is easier than using the Alpine setup interface because the option is about 351 pages down in the list. If you insist on using the interface, at least perform a search by pressing CTRL+w and enter "Customized Headers" to jump to the option.

Note that some servers will respond with an "Authentication failed" error if this is not set correctly.

Re-typing (or pasting into the console) your password for each authentication gets old real fast, especially if you have a nice, long, secure password.

First, your copy of of Alpine needs to be compiled with the ability to store passwords in the first place.

Secondly, this is a good example of how blindly following instructions on the Web doesn’t always work! I kept trying to create the wrong password file and Alpine silently laughed at me.

I finally wisened up and went straight to the source, so to speak. Here is the configuration of the alpine.SlackBuild:

The key element here was --with-passfile=.alpine.passfile.

Ah! So now we can touch the file into existence:

And upon opening Alpine and entering my password, I was delighted to see the prompt

My answer was 'y', but my words were, "awwww hellll yeaaah!"

By the way, the password is stored in encrypted form which you can confirm by displaying it:

To keep other users (on your multi-user UNIX system, of course) from snooping your password, it’s a good idea to restrict permissions to the password file:

(Thanks to Matt Roberds for the tip about locking down access to the passfile and the alternate passfile locations.)

My first attempts did not work.

Things to check:

Runbox actually has Mutt instructions but no such luck for Alpine.

I tried a huge number of settings before getting both IMAP and SMTP to work. Here’s what I got working (minus username, of course):

Interestingly, IMAP authentication did not need the @runbox.com portion of the username while the SMTP auth did.

Though it’s certainly possible to manage email at the command line (and I still harbor vague fantasies about it), I did not find it practical to deal with the modern reality of email in Alpine (or Mutt, which I also got working, but abandoned after a week). Instead, I’ve been happily running Thunderbird (comes with Slackware) for a year and haven’t looked back.

The truth is, the things you’ll be sent in email often contain HTML, attachments, and links. It’s simply more convenient (without a huge learning curve and serious configuration time) to use an X GUI application.

Having said that, I love the power and flexibility of terminal programs and I’m sure I’ll come back to this.