Linux nerd alert: When I closed the static website, I knew there would be some loose ends. One is that folks keep coming here looking for links to a tutorial I had on setting up multiple accounts on Alpine, a console email client. What follows is the quick-n-dirty tutorial I wrote.
**********
Alpine with Multiple Accounts
This is a brief tutorial on configuring Alpine to handle all your various email accounts as a full-featured email client.
First, you may know Alpine does not have built-in POP access. However, it can be made to mimic this, which is a primary feature we need for multiple accounts. What we are doing is persuading Alpine to treat your inbox on the provider’s server the same as a local inbox. But we give Alpine a local inbox into which it copies the contents, then erases it from the distant server. We call the local a “drop folder.”
I came upon this information from another party, but their page has disappeared from the Net. Unable to duplicate their excellent tutorial, I offer here a quick and dirty configuration guide via direct editing of your Alpine configuration file (~/.pinerc). Start Alpine one time from the command line and you’ll probably have that configuration file.
Incoming Drop Box
Dropping down to around line 400, you’ll find a reference to “List of incoming msg folder” — we need to begin our first additions here. All I can do is offer a sample line and parse it so you can modify it to meet your needs. Everything is appended to the line which begins:
incoming-folders=
I’m using my Cox Cable line as an example. Please note this line is wrapped here in this plain text format, but is a single long line in the config file:
Cox "#move {pop.cox.net:995/novalidate-cert/user=user00/pop3/ssl}Inbox Cox"
The first “Cox” is my name for the local role name. This allows me to separate the various SMTP servers by role so that I can select which role account I want to use for a particular message, either in composing or replying. You can call it what you like, but I prefer to keep things simple.
There is a space following this drop folder name, and the rest is inside double quotation marks. The next item is the command for Alpine to move whatever follows into that drop folder — #move. There is another space following.
In curly brackets is the information necessary to access that remote folder on your provider’s server. In this case, pop.central.cox.net is what my provider tells me is the correct server address. This is secure POP, so the port is 995; the colon is standard notation. This portion is closed by a forward slash.
Because of frequent mismatches between the security certificates on most servers and the actual machine name, we add a setting to tell Alpine to ignore this — novalidate-cert followed by another slash.
Then we have the user name which must be passed to the server for access to the correct mail box — user=. Please be careful to use the proper format required by your provider. In some cases, it would be the entire email address. For the likes of GMX in Europe, it’s easier to use the account number they issue when you open the account. This is followed by another slash.
We next tell Alpine which protocol to use for communicating with the server; in this case it’s pop3. And it’s secure, so after another slash we mark the ssl protocol. It’s rare to see a mail server not using it these days. This part of the statement is finished, so we close with the other curly bracket.
Finally, we tell Alpine the name of the inbox, which is separate from the built-in Alpine INBOX. Indeed, the drop folders are in my home directory, a mail file simply named “Cox” in this case. I can view it using the ‘less’ command (or with any editor) without having to open Alpine. Finally, close the whole thing with the final quotation mark.
To add any other accounts after this, I simply add a comma to this line, and each additional line that is not the last line. After the first line, subsequent lines should be indented with a TAB character, not spaces.
SMTP Roles and Accounts
Alpine handles SMTP connections natively, so this is less complicated in one sense, but the configuration line is longer. We have to be sure the incoming role name matches with an outgoing role name. We drop down to below line 530 or so, and find the item which begins with “Patterns and their actions…”
Again, the sample is from my Cox account, and is line-wrapped for this explanation, but all on one line in your .pinerc. This part is written differently because it relies on internal controls Alpine already understands, whereas the drop box business is passing an argument which Alpine sends literally to the distant server. This is one long line:
LIT:pattern="/NICK=Cox/FLDTYPE=SPEC/FOLDER=Cox" action="/ROLE=1/FROM=First Last /SMTP=smtp.cox.net:465\/novalidate-cert\/ssl\/user=user00/RTYPE=NC/FTYPE=YES/CTYPE=NO"
Each line like this must begin with the LIT:pattern= portion so Alpine knows what to do with it. Everything which follows is between two pairs of double quotation marks. Next is the label NICK= and mine is Cox again, noting the role name. Next is a slash and the marker FLDTYPE=SPEC which is simply internal labels for Alpine to match this to the previous configuration for incoming drop boxes. It’s followed by another slash, then the label FOLDER= to match this role to my Cox incoming drop folder. Close this portion with the other double quotation mark, then insert a space.
Next, we tell Alpine what to do with this information: action=. The rest of the line is all inside another pair of double quotation marks. We are matching this role from incoming mail above to a similar role for sending. Drop in a slash, then ROLE=1 to match one for one. Another slash and we identify the role by the FROM= label.
In this case it’s your common name, a space and a fake address to remind you to use your own, but this time the full format which needs to appear in the headers of your outgoing messages. Thus, the email address is in angle brackets as you often see in email messages.
We place another slash followed by SMTP= for the server name your provider tells you to use. As before, we use a colon to mark the standard SSL secured SMTP port of 465.
Then we must place a backslash because that’s how Alpine parses this portion of the configuration line. It “escapes” for the next forward slash — \/. Then we have the novalidate-cert because, as above, most servers hold a certificate which does not match all the various aliases to which it answers. Another double slash and we tell Alpine this requires the SSL secure connection.
Then we add another double slash and give the login user name your provider requires.
We drop the double slash business now. The rest is internal labeling for Alpine’s use, and is required: /RTYPE=NC/FTYPE=YES/CTYPE=NO and close it with another double quotation mark. As before, each subsequent added line for a separate account must have a TAB character prefixed, because that’s how Alpine knows to process this as an additional account.
For the rest, you can probably figure out how to configure Alpine to your tastes by exploring the opening menu. Don’t forget, you can tell Alpine to use various display colors, but on the console, you only get 16 colors, so far as I can discern. See Menu > SETUP > Kolor (or type sk at the menu prompt). There are more options under ‘SETUP > Configure’ than you’ll ever need. Each one is explained if you hit the ‘?’ mark while the cursor rests on the option in question, but I can’t guarantee you’ll understand it.
Also note, some distros (such as Red Hat/Fedora) compile with a standard password file Alpine can use to save your passwords. Yes, this is a security risk if you aren’t the only one using your machine, but the passwords are saved in a hashed format not be easily deciphered. I believe RHEL and clones use .alpine.passfile, while Debian and clones use .pine-passfile.
Have fun with Alpine!
(This tutorial is public domain.)
