Sometimes when I'm traveling, I have trouble sending email from my devices that typically connect to my ISP at home via hardwire or WiFi. This is because some ISPs do not like outbound email to leave their network unless it is routed through their own email servers. But you need to have an account with the ISP in order to send outbound email through their servers.
This intentional blocking of outbound port 25 for email is usually aimed at preventing hijacked hosts from acting as spambots and sending email over the ISP's network. Such a situation could result in the ISP being flagged as a source of spam and added to spam-blocking websites, thus preventing legitimate email from reaching its proper destination.
To eliminate the issue of blocked outbound email, I wanted to use an email client that I could run as an email user on my own email server. In other words, I would use SSH login to access my email server anywhere, anytime. Once logged in, I would simply start the email client and receive and send email directly from my own email server, this eliminating any outbound port 25 blocking issues.
I have used many different open source email clients over the years, from recent options with graphical interfaces, like KMail and Thunderbird, to text-mode email clients such as mailx, Mutt, and Pine. Of the latter three, I preferred Pine because it seemed to best fit my style of working.
I also remembered that Pine, which I used about 15 years ago, supported what I was trying to do to overcome the blocked email problem, so I thought I would give it another try.
Unfortunately, Pine, which was written at the University of Washington in 1992, is no longer supported and has not been updated since 2005. It has been replaced by Alpine, also written at UW, which was intended to be a complete rewrite and a replacement for Pine. I decided to try Alpine version 2.21, which was released in March 2017, as it was the newest release available.
Setting up the user account
Although Alpine can be used to remotely access an email server, I wanted to install it directly on the server and use it there. This means that the user must log into the mail server remotely using a valid login ID. This brings up an issue because email accounts are generally not login accounts. A typical email account uses the nologin shell to prevent the user from logging into the mail server.
student:x:1008:1008:Student email account:/home/student:/sbin/nologin
This shows the /etc/passwd entry for a typical email user, student. The /sbin/nologin shell is used to prevent the user from logging into the email server as a regular user. Here is what I got when I tried to log in with the nologin shell:
This account is currently not available.
Connection to bh closed.
To convert the student account to a login account, change the shell to any regular login shell. I like Bash, so, as you can see below, that is what I changed the user shell to. This change doesn't affect the use of the account for email. Here is the user account after I changed the default shell to Bash:
student:x:1008:1008:Student email account:/home/student:/bin/bash
Working as root, I could have used the chsh command to change the user shell for student, but I prefer to directly edit the /etc/passwd file using a text editor. When creating a new email account, the default shell for Linux is Bash, so no changes were needed. I tested my new email account by using it to log into the email server.
I then configured the email server to add the student account. I use SendMail, so I added the line below to the /etc/mail/virtusertable file. To activate the new email address, I ran the make command from within the /etc/mail directory and restarted SendMail. (Other email servers may use different methods to add a new email user.)
I sent a test message to the student user to verify that the account could receive emails. You can check this without using an email client by looking at the content of the /var/spool/mail/student file to verify that the test message is there. All the files in the /var/spool/mail directory are inboxes for email users.
Installing and configuring Alpine
Alpine is easy to install on CentOS (which is my preferred server distro, although I sometimes use Fedora as a server). Alpine for CentOS is located in the Extra Packages for Enterprise Linux (EPEL) repository, so you may need to install the EPEL package if it is not already there. Alpine is located in the standard Fedora repositories, so you don't need to add an additional repo to your system if you use Fedora. I used the command below to install Alpine on my CentOS email server.
yum -y install alpine
I could have downloaded the source and built it myself, but using the packaged version is so much faster and easier.
To begin using Alpine, I logged into the email server as the student user. I typed the command alpine to start the email client. The first thing I saw was a message indicating that Alpine was creating the ~/mail subdirectory to store its mail. This might create a conflict with other email clients, but it is easily resolved, as I will explain below.
Next, Alpine displayed a Welcome page, which happens only the first time Alpine runs. On the Welcome page, the maintainers ask that you press the Return or Enter key to automatically send an email to the Alpine developers so they know how many people are using the software. (I always do that so they know that there is enough interest to continue to maintain it.)
Navigating the menus
After I pressed the Enter key, Alpine's main menu displayed, as shown here:
ALPINE 2.21 MAIN MENU Folder: INBOX 1 Message
? HELP - Get help using Alpine
C COMPOSE MESSAGE - Compose and send a message
I MESSAGE INDEX - View messages in current folder
L FOLDER LIST - Select a folder to view
A ADDRESS BOOK - Update address book
S SETUP - Configure Alpine Options
Q QUIT - Leave the Alpine program
For Copyright information press "?"
? Help P PrevCmd R RelNotes
O OTHER CMDS > [Index] N NextCmd K KBLock
Alpine starts up with the inbox as the default folder. The inbox is actually the file /var/spool/mail/student that contains all the mail for the account's inbox. Email that is moved from the inbox to another folder is stored in the corresponding directory in ~/home/mail.
Note in the code above that there is already one email in the student inbox. At the bottom of each page, there are two lines with commands pertinent to the current menu page. Some commands can be issued from almost any menu by typing the corresponding letter. Be careful, as sometimes different commands use the same letter shortcut, depending upon which menu page you are on. Be sure to check out other commands available in each menu screen by typing the character O.
To view a list of the emails in the inbox, either type I (message index), or use the arrow keys to highlight MESSAGE INDEX and press the Enter key.
To open a specific email, highlight it and press the Enter key. Then type < to return to the inbox and M to return to the main menu.
To get to the configuration menu, type S (setup) then C (configuration). Very little needs to change here, because Alpine is running local to the server, but I did set the signature to my name. It is not necessary to configure an outbound SMTP server because the localhost is used by default. I also changed the default location for sent messages from sent-messages to Sent, which is where Thunderbird stores them.
Resolving email location conflicts
Next I needed to fix other problems with the client's email location. Clients like Thunderbird store email in folders located in the user's home directory (~). By default, Alpine stores email in folders it creates in ~/mail, except for the inbox. Because I wanted to be able to switch between Thunderbird and Alpine, I needed to ensure both could access the email folders.
This issue can't be solved with the Alpine or Thunderbird configuration options. Specifying the user's home directory (~) for the default Collection List (group of folders) results in Alpine trying to create the user's home directory, which already exists, and causes the change to fail. There is no option to change the default folder location without attempting to create it.
Linux provides a simple solution: creating hard links in the ~/mail directory to each existing email folder in the home directory. See "A user's guide to links in the Linux filesystem" for details on how to create them. Soft (symbolic) links also work, but I think that hard links are best for this type of situation.
This way both Thunderbird and Alpine are happy because they each get to use their own default locations for mail folders. And I am happy because, after doing the research, I don't have to spend a lot of time trying to hack those email clients. Now I only need to remember to create a new hard link if I create a new folder using either client.
Pros and cons
Alpine is easy for me to use with its clean, simple interface and extensive features. It is very fast because it doesn't try to download and display graphics. It's limited to plain text only, so it renders HTML as plain text, but it can't be used to generate and send HTML. That is not a bad thing.
Alpine—at least how I am using it—doesn't deal well with attachments; it usually doesn't know what to do with attachments that require a graphical application such as LibreOffice.
Setting it up and maintaining it also takes a little work if new folders are needed. Even so, I find it well worth the effort because I can log in from my laptop, my Android phone, or my Kindle using SSH, view my mail quickly, and respond where necessary.
There are other alternatives to working around the problem of an ISP blocking outbound email on port 25. For example, my mobile phone works well as a wireless hotspot, and my mobile provider, doesn't block outbound email, so that also works for me.
If you want to learn how to use Alpine, the software has a good man page and a nice built-in help feature. Those should get you started.
Do you use Alpine or another text-mode email client? Let us know about your experience and recommendations in the comments.