Before getting started, I strongly suggest uninstalling sendmail and other MTAs such as postfix that might already be installed by default on your system but are not being used. This will avoid conflicts and confusion. If you’re already using postfix/sendmail, then there is no need for the following setup at all, right?
Sometimes you’re running a server to provide a specific service and you need it to send you status updates via email but do NOT need the overhead and complexity of having it run a mailserver or complicated MTA.
You just need a SIMPLE, quick and easy way to have your server send a message over SMTP via a mailserver… let’s look at msmtp.
What is msmtp?
msmtp is an SMTP client that submits mail to a server for further processing and delivery. That’s it. Nothing more, nothing less. That’s why it’s lightweight, fast and simple to get going. It allows attachments and fully supports encryption. It’s exactly what you need to just have your little server send out status updates or even a cry for help!
This is basically how it works:
- Email is generated by an app/user
- msmtp is called to submit email to a mail server using provided credentials
- the external mail server processes the message and completes the task of delivering it to the intended recipient
Ok, let’s get this program installed and then we’ll take a look at the configuration. On Debian/Ubuntu systems, you can use apt to do all the work for you.
apt install msmtp msmtp-mta ca-certificates
That’s it. msmtp is a program, not a service, so there is no systemd file or anything you need to worry about.
Unlike other full MTA solutions, the setup for msmtp is very simple and only a few lines long (for our purposes). Here’s the entire (commented) file… we’ll go through it after you bask in its brevity:
####### ### mSMTP configuration ####### ## Set defaults for all accounts defaults auth on tls on tls_trust_file /etc/ssl/certs/ca-certificates.crt logfile /var/log/msmtp.log ## Account: myserver.com account myserver.com host smtp.myserver.com port 587 from "ServerName VM" <[email protected]> user [email protected] password [email protected]$$w0rd_ ## Set default account account default: myserver.com aliases /etc/msmtp_aliases
Configuration breakdown: How it works
I’ve shown you a commented breakdown and the parameters themselves are pretty much plain-English, but I’ll go through them one at a time since I find that virtually all open-source stuff lacks decent documentation written for humans.
The ‘defaults’ section
This sets parameters for the program in general.
|6||Tell msmtp that this section contains program default settings. It is a ‘section header’ and does not have any options or anything for you to monkey-around with.|
|7||Specifies whether or not SMTP authentication is required. This is nearly always required to be ‘on’ since you need at least a username/password combination to access most any mail server. Setting this to ‘on’ tells msmtp to automatically detect and use the correct and most secure authentication method your target server supports.|
|8||This turns on TLS mode. This is also referred to as SSL by some mail providers. If your mail server supports encrypted connections (it should!) and uses port 587, then you’ll want to use this setting. If your mail provider uses port 465 it is probably using SMTP/S or SMTP tunnelling. In these cases, TLS is implied from the start so add |
|9||This specifies the location of public certificates to reference and enforces strict certificate checks. If your mail server is using a certificate from a well known public certificate authority (including Let’s Encrypt) then its public certificate is included in the list maintained in the ca-certificates package in the Debian/Ubuntu repos. You very likely do NOT need to change this line. Two notes:|
|10||Log files are important to keep track of what is using msmtp to send email and for troubleshooting purposes. This specifies where you want that log file stored. I have specified the default location on Debian systems with a meaningful filename. You may choose any location and name you like, provided the program/user invoking msmtp has write permissions to that location.|
The accounts section
Here you can list the various accounts you’d like msmtp to use. In this example, I’m only using one but you can create a few other sections if you need/want to sent mail via several accounts.
|13||Here we are specifying a name for the account profile. I like naming it after my mailserver so I remember what’s going on. So you could name it ‘gmail.com’ or ‘outlook.com’ or ‘mymailserver.com’. On the other hand, you could name it something like ‘MyMailServer’ or ‘MainProfile’… whatever has meaning to you, with no spaces.|
|14||This is the actual address of the mail server you want to use. For Gmail, for example, it’s smtp.gmail.com|
|15||The port on which your server accepts mail for relaying. Traditionally, this is port 25. Nearly ALL modern systems use port 587 for TLS encrypted connections. As noted in the previous section, your server may use port 465 if it expects SSL connections/ tunnelled connections (sometimes called SMTP/S).|
|16||Here you can get creative. In the quotes, you can write a name as you want it to appear. So for a web server VM that you are running, you might want it to show up as “Webserver VM” in the ‘from:‘ field of your email program. You can really write anything here within reason. Remember that most email clients expect something like “Firstname Lastname” so something like “Server monitor on web server” might not show up properly in mail programs. The part in <angle brackets> is the actual email address. This must be a proper email address that is authorized to relay through the server in question. In other words, a legitimate email account on the server to which you are connecting – I usually use the same account I’m using to connect in the next step.|
|17||This is the user account (or account alias) authorized to connect to the mail server in question.|
|18||This is the password associated with the account in the previous step.|
This password is in plain text! You MUST control access to this file to prevent disclosing your password to unintended third-parties. You can use tools like GNOME keyring (requires you to have GNOME installed) or GPG-tools to encrypt this password but, I find encrypting the password causes problems including prompts that require user-intervention which is useless on an unattended system. I’ll cover how to restrict file access later in this article, but if you want to use an encrypted password you’re on your own!
Specify a default account
Whether you have one or more account profiles set up in the previous section, you need to let msmtp know what to use if no sending account is explicitly specified (which will is pretty much always in our use-case).
|21||This is the profile name of the account profile in the previous section you want to use as the default. This profile’s settings will be used unless msmtp is told to use something different (using the –from or –account switches on the invoking command line… not covered in this article).|
|22||This is a pointer to a list of account aliases. We’ll cover this in more detail in the next section, but suffice to say this allows you to specify a short username and msmtp will resolve that to a proper email address. NOTE: Although we are not using sendmail in this example, you should NOT use /etc/aliases as the name of your alias file to avoid confusion with the sendmail version of the alias file. That’s why I chose the more cumbersome msmtp_aliases as my filename.|
Create the configuration file
Now that you understand what’s going on, let’s actually create the configuration file so msmtp can use it.
- Open a new file called msmtprc in your favourite text editor, I like nano:
- Construct your setup based on the example given in the previous section. You can get the most up-to-date version of my setup here and you can copy/paste. Save your configuration file.
- msmtp is NOT a service or anything, so the new configuration is read the next time (and every time) you call the program. There is no service to restart to apply changes.
The alias file
The alias file allows you to set up pointers for msmtp to map usernames to email addresses. Based on our configuration file that we just created, we’ll create this file at ‘/etc/msmtp_aliases’. This is the alias file I use in setups such as we’re doing here.
root: [email protected] default: [email protected]
You might be familiar with the aliases file used by sendmail. This is NOT the same thing. That’s why I suggest naming it something different to avoid confusion with the much more popular sendmail version of this file.
The above file (which is usually all you need) tells msmtp that if the destination address is ‘root’ then send it to [email protected]. If a name is provided that does not resolve on its own and does not match anything else in this file, then use the ‘default’ entry of [email protected] as the destination. So, you could add a line like:
Now, anytime you told msmtp to send to ‘postmaster’ it would automatically resolve that to [email protected]. If you want to set up additional aliases, that’s up to you depending on your particular setup.
msmtprc permissions and symlinking
As I mentioned earlier, your msmtprc configuration file has the email password in plain-text. This is not good. Now, most programs using msmtp to send out status reports will be running as root so you could just lock that file out to root access only. You can do that by typing the following:
chmod 600 /etc/msmtprc
This will restrict read/write access to root only and grant no permissions whatsoever to any other account. If that’s sufficient for your needs then you’re good to start testing. If you need other accounts to access msmtp to send email, then you’ll have to make a group and give it permission to read the configuration file and, thus, the email password. Here’s what you’d do:
# create a group called 'msmtp' groupadd msmtp # repeat the following for each group member usermod -aG msmtp username usermod -aG msmtp username2 ...
Now we have a group and members of that group. Let’s grant that group permission to read our configuration file:
chown root:msmtp /etc/msmtprc chmod 640 /etc/msmtprc
Now any member of the group msmtp can read the configuration file, only root can change it, and no other users can even see it.
Most programs will expect to use sendmail or some variant to send status reports (fail2ban, logwatch, etc.) They most likely are not looking for msmtp. That’s why we installed msmtp-mta in the very first step… it fools everyone into thinking sendmail is installed ;-) msmtp-mta creates a symlink to msmtp with the name ‘sendmail’ so it gets invoked whenever a program calls sendmail. For your reference, and so you can check it out for yourself, that symlink is at /usr/sbin/sendmail. You’ll see that it points to msmtp. So, why install msmtp-mta instead of just doing the symlink yourself? The best reason is because msmtp-mta tells the system that an MTA is installed. That way other programs (like logwatch) don’t try to install MTA’s like postfix or exim which is what you wanted to avoid in the first place, right?
On newer versions of Ubuntu (Ubuntu 18.04++, I think) and Debian (Debian Buster++), apparmor blocks our msmtp setup. To fix this, we need to edit the included profile a little bit. Let’s switch to the apparmor directory and make a backup first in case we screw something up:
cd /etc/apparmor.d # make a backup -- putting the backup in the same directory causes problems! cp usr.bin.msmtp /root/usr.bin.msmtp.backup
Now, open usr.bin.msmtp in your editor of choice and let’s make our changes. I’ve listed the original line (that already appears in the file) as a comment and the changes you need to make appear right after that. I suggest you follow the same convention in the actual file so it’s easy to see/undo any changes you make. Remember the commas at the end of the lines!
# /etc/aliases r, /etc/msmtp_aliases r, #/var/log/msmtp wk, /var/log/msmtp.log wk,
Save the file and close it. Now, let’s restart apparmor so it reads the updated configuration:
systemctl restart apparmor
Finally, we need to make the logfile manually so that it exists when apparmor checks paths (omit ‘sudo’ if you’re already running as root):
sudo touch /var/log/msmtp.log
That’s it! Let’s get to testing all our hard work.
Ok, nice work so far! Now it’s time to see the fruits of our labour! First, let’s do a nice simple test where everything is spelled out for msmtp:
sendmail [email protected] Subject: This is a test message This is our first test message from msmtp! <control-d>
Ok, so you’re typing the first line, replacing [email protected] with an address you can actually check, and pressing the <enter> key at the end of each line. The “Subject:” has to start with a capital “S” and include the colon and space after it. Note also the blank line after your text: this is a standard convention but not strictly required. To send your message, press <control-d> and msmtp will exit and send the message. You can confirm/check this by looking at the log file (see why it’s important to have logs?)
You should see that the message was successfully queued for delivery with exitcode=EX_OK. Now check the email account you emailed and make sure it’s delivered. All good? If so, let’s move on to another test:
sendmail root Subject: Testing aliases Another test message! <control-d>
This time, we’re asking msmtp to read our alias file and resolve ‘root’ to whatever address you entered as the destination. If it doesn’t work or throws an error, re-check your alias file. A lot of programs will simply use ‘root’ as their destination, so this alias is pretty important. Ready for the final test?
sendmail abcd Subject: Testing aliases again Yet another test message! <control-d>
Finally, we test msmtp with an alias that we didn’t define. You’ll see that it simply uses the ‘default’ entry in our aliases file and sends mail there. This is super-useful for programs that send to some account you didn’t plan for but still want to see the output.
That’s it! You have set up a simple, lightweight, mail relay system that can allow your programs to email you notifications, status updates or really anything including attachments! The configuration file (and thus, access to the program) is also secured against unauthorized users. I hope it’s useful to you, I use it on all of my mini-servers and virtual machines.
Thanks for reading my techie-thoughts on this issue. Have any comments or suggestions? Want to add your tips? Things you want me to cover in a future article? Comment below!