Configuring Alpine

Attempting a simple IMAP and SMTP setup
Created: 2018-06-05
Updated: 2020-09-16 (Added alternative locations for the passfile on other distros. Promoting customized-hdrs to cheatsheet, added .pinerc to cheatsheet.)

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 .pinerc Syntax Example

Personal Name


your name

Taryn MacTavish

User Domain



SMTP Server



Inbox Path




Where <remote-spec> equals <domain>[:port][/option_1][/option_2]…​.

Customized Headers


<header>: <value>


A .pinerc containing the above examples would look like this:

personal-name=Taryn MacTavish

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.


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:




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

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:

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


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:

personal-name=Antilles MacTavish


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:

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://…​ 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:

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, {}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).



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 and it looks like this when you request your username:

$ whoami

Then your email address is going to be

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.

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:
./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.

Debian users can try ~/.pine-passfile or look in /usr/share/doc/alpine/README.Debian for the expected passfile name. Ubuntu and other distributions may use the same location. You might try grep -R passfile /usr/share/doc/alpine*/ to search for a reference. (This doesn’t reveal anything useful in Slackware, however.)

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

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:

$ chmod 600 ~/.alpine.passfile

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

  • 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 587
    Connected to
    Escape character is '^]'.
    220 ESMTP Exim 4.666 Slackware Wed, 06 Jun 2018 05:03:17 +0200
    214-Commands supported:
    221 closing connection
    Connection closed by foreign host.

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

Interestingly, IMAP authentication did not need the 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.