Many years ago, the "normal" way to deal with email was by way of a mail user agent, or MUA. Over time, MUAs evolved from simple command-line tools to feature-rich productivity enhancing console based dialogs such as Elm and Pine, mail readers for EMACS, and the ultimate king of MUAs: Mutt.
One thing proper MUAs have in common is that they are just user interfaces to your email. They are not intended to serve as POP and SMTP clients, and they are especially not intended to serve the role of a mail relay or MTA of any kind. Instead, MUAs rely on other tools to serve those purposes. Doing so minimizes the complexity of the tool, which helps improve both its reliability and its security.
Since the advent of the ubiquitous GUI on modern operating systems, the end user's email client application has come into being. Such applications do much more than MUAs. They often serve as word processors, specialized MTAs, mail relays (usually for spammers on infected systems), Web browsers, WYSIWYG HTML editors, contact managers, schedule managers, collaboration tools, media players, and probably a dozen other things as well. Of course, we should not forget that they also perform the basic functions of a mail user agent in the middle of all that. Along with all this inevitably comes increasing stability and security issues, decreasing performance, and sometimes a bit of information overload for the user.
Because of these issues, many users of Unix-like systems prefer to use the old-school MUA. Because standard MTAs such as Exim, Postfix, and the venerable Sendmail are all very large servers that include support for a lot of functionality the common end user does not need, smaller tools have been created to provide the functionality such users do need. Among these are dedicated SMTP clients like sSMTP, and an earlier TechRepublic article explained how to use sSMTP to send email simply and securely.
Unfortunately, sSMTP is too simple for some users. For those who have to maintain multiple email accounts, there is the option of using a separate configuration file for each account, but another tool called msmtp offers multiple account support within a single configuration file. There is some question as to whether sSMTP is even supported any longer, suggesting that msmtp might be a better choice for the long term, even if you do not need all of its capabilities.
A basic configuration file for msmtp is simple enough, including TLS/SSL support — necessary for encrypted access to mail servers, a basic email security tip that should not be neglected. The msmtp tool supports both a universal configuration file and user-specific configuration files. The user-specific file located at
$HOME/.msmtprc is usually the better option, especially on multi-user systems.
The following is an example of an
.msmtprc configuration file. In this example, anything
<surrounded by chevrons> should be replaced by information specific to your needs.
# All Accounts
# Example Account
The order of configuration options in this example configuration file is not strict. It has in this case been organized into two groups: one for all accounts managed by msmtp, and another for an account at example.com.
</path/to/cert/file> entry's value will vary from system to system. It indicates where trusted TLS/SSL certificates are stored. On FreeBSD, for instance, it is located here:
<account_label> entry is a term of your choice, used to separate the accounts from each other. Everything following that account label is particular to that account, until another account label appears in the configuration file.
The rest should be fairly self-explanatory, and will depend on your email account details. Of course, because the file contains your email password,
~/.msmtprc should have its permissions set to read and write for the owner only, to ensure that other user accounts cannot be used to read the file's contents:
chmod 600 ./msmtprc
One note needs to be made regarding installation: on FreeBSD, at least, the default port install does not have TLS/SSL support compiled in. You can work around this when installing via the ports system, using
make, with these commands:
# cd /usr/ports/mail/msmtp
# make -DWITH_OPENSSL install clean
If you use
portinstall instead, this command should install with TLS/SSL support:
# portinstall -m '-DWITH_OPENSSL' msmtp
If your Unix-like system does not include TLS/SSL support by default, similar means might be needed to include support at compile time.
Finally, you need to make sure that Mutt talks to msmtp when you want to send email. First, find where your
msmtp executable is located:
> which msmtp
Add a sendmail line to your
.muttrc file to tell it what tool to use for sending mail:
set sendmail = "/usr/local/bin/msmtp"
You will want to use these lines in your
.muttrc file, if you are not already using them, to ensure you are identified properly for your email account when sending email:
set realname = "Whatever You Want To Be Called"
set from = "email@example.com"
set use_from = "yes"
set envelope_from = "yes"
With that, you should be ready to go. Test out your configuration a couple of times by sending emails to yourself and to someone else who is willing to be your guinea pig.
Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.