Configuring Alpine

Attempting a simple IMAP and SMTP setup
Created: 2018-06-05
Tagged: email slackware linux howto

First, I’ve created a cheatsheet of the Forbidden Knowledge which you may find useful for the remainder of this article:

Table 1. Alpine IMAP/SMTP configuration cheatsheet
Alpine interface.pinercSyntaxExample
Personal Namepersonal-nameyour nameTaryn MacTavish
User Domainuser-domain<domain>example.com
SMTP Serversmtp-server<remote-spec>arcadia.example.com:587/tls/user=tmt
Inbox Pathinbox-path{<remote-spec>}folder{arcadia.example.com:587/tls/user=tmt}Inbox
Where <remote-spec> equals <domain>[:port][/option_1][/option_2]…​.

The quest

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.

The good

Okay, Alpine comes with Slackware and it’s rightly famous for being easy to use. (When designing a new program, you could do a lot worse than emulating (Al)Pine’s discoverability. Common command options are always visible on the screen and everything seems to more-or-less work exactly like you’d expect.)

The bad

But when it comes to actually configuring it for personal use, I got stuck real fast.

The config interface is very nice, but the naming convention for some of the most important fields was baffling to me. (What the heck is a "User Domain"?)

Follow along with me as I figure this out.

Tutorial/How-To

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:

/usr/doc/alpine-2.20/tech-notes

specifically

/usr/doc/alpine-2.20/tech-notes/config.html
/usr/doc/alpine-2.20/tech-notes/config-notes.html

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

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

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:

$ head -n20 ~/.pinerc
#
# Alpine configuration file
#
# This file sets the configuration options used by Alpine and PC-Alpine. These
# options are usually set from within Alpine or PC-Alpine. There may be a
# system-wide configuration file which sets the defaults for some of the
# variables. On Unix, run alpine -conf to see how system defaults have been set.
# For variables that accept multiple values, list elements are separated by
# commas. A line beginning with a space or tab is considered to be a
# continuation of the previous line. For a variable to be unset its value must
# be blank. To set a variable to the empty string its value should be "".
# You can override system defaults by setting a variable to the empty string.
# Lines beginning with "#" are comments, and ignored by Alpine.

# Over-rides your full name from Unix password file. Required for PC-Alpine.
personal-name=Antilles MacTavish

# Sets domain part of From: and local addresses in outgoing mail.
user-domain=example.com

...

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

personal-name

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:

personal-name=Antilles MacTavish

user-domain

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.

user-domain=example.com

smtp-server

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:

smtp-server=mail.example.com:465/user=bigwilly/tls

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".

inbox-path

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:

This specifies the name of the folder to use for the INBOX. By default this is unset and the system’s default is used. The most common reason for setting this is to open an IMAP mailbox for the INBOX. For example, {imap5.u.example.edu}inbox will open the user’s standard INBOX on the mail server, imap5.

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:

inbox-path={mail.example.com:993/user=bigwilly/tls}Inbox

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

customized-hdrs

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 @valley.arcadia.net and it looks like this when you request your username:

$ whoami
tonka

Then your email address is going to be tonka@valley.arcadia.net.

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

customized-hdrs=From: ven@valley.arcadia.net

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.

Saving the password

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:

# Configure:
CFLAGS="$SLKCFLAGS" \
./configure \
  --prefix=/usr \
  --mandir=/usr/man \
  --with-ssl-dir=/usr \
  --with-ssl-certs-dir=/etc/ssl/certs \
  --with-c-client-target=slx \
  --with-system-pinerc=/etc/pine.conf \
  --with-system-fixed-pinerc=/etc/pine.conf.fixed \
  --with-passfile=.alpine.passfile \
  --disable-debug \
  --with-debug-level=0 \
  --without-tcl \
  --program-prefix= \
  --program-suffix= \
  --build=$ARCH-slackware-linux || exit 1

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

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

$ touch ~/.alpine.passfile

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

Perserve password on DISK for next login?

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:

$ cat .alpine.passfile
<nonsense>

Troubleshooting

My first attempts did not work.

Things to check:

  • The Slackware Alpine package was built with debugging turned off, but maybe your copy doesn’t? Try requesting debugging with alpine -d 9 and see what it says. If it’s turned on, you can check for debug output at .pine-debug[1-4]
  • Your username might not be what you expect (many hosts use your entire email address as the username); your email provider should have this documented somewhere
  • Your username for SMTP may not match the username for IMAP! Try some combinations.
  • The order of the options in the "remote spec" for smtp-server and inbox-path seem to matter. I was unable to connect with this order: /user=me/tls but I was able to connect with /tls/user=me
  • Try alternative ports for SMTP. The port situation is a real historical mess (as explained by my email provider’s article on the subject). Try port 465 for TLS and fall back to 25, 26, 587 (the latter typically begin with an unencrypted connection and can then be secured with STARTTLS
  • If IMAP plus TLS port 993 doesn’t work, you can still have a secure connection with 143 and STARTTLS
  • Rule out other connection problems by using telnet:

    $ telnet smtp.example.com 587
    Trying 192.168.0.66...
    Connected to smtp.example.com.
    Escape character is '^]'.
    220 satan.example.com ESMTP Exim 4.666 Slackware Wed, 06 Jun 2018 05:03:17 +0200
    HELP
    214-Commands supported:
    214 AUTH STARTTLS HELO EHLO MAIL RCPT DATA NOOP QUIT RSET HELP
    QUIT
    221 satan.example.com closing connection
    Connection closed by foreign host.

Fellow runbox.com users

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):

a .pinerc that works with Runbox (relevant lines only)
smtp-server=mail.runbox.com:587/tls/user=username@runbox.com
inbox-path={mail.runbox.com/tls/user=username}Inbox

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