Having your server send you emails is a simple way to get notifications from bash scripts, applications, and cron jobs. Command line email works similarly to personal email, and is easy to configure and use.
How Does Command Line Email Work?
When email is traveling down the tubes of the Internet, it’s usually being sent over the Simple Mail Transfer Protocol, or SMTP. The server that handles sending mail is called an SMTP server, and many free email providers (Gmail, Yahoo, etc.) provide SMTP servers for free. This is great for this use case, as you will only need to configure the command line app that does the sending.
This app is called a Mail Transfer Agent (MTA), and handles communicating with the SMTP server. You’ll need to authenticate the MTA with the SMTP server, which is usually as simple as giving it your password or key. Then, the MTA will be able to act as you, and send emails from your account.
How to Install and Configure Postfix
Postfix can also run its own SMTP server, but it’s it’s harder to configure, and less compatible with external recipients unless you configure domain verification.
Install Postfix and libsasl2-modules, a package for managing SMTP authentication, from your distro’s package manager. For Debian based systems like Ubuntu, that would be:
As Postfix installs, it will prompt you for configuration. At the first screen, select “Internet Site,” which will configure Postfix to use SMTP.
The next prompt will ask for your domain name. You don’t need a domain name to use Postfix, but you will need one to have your emails sent from that domain name. In this example, without specifying the domain name, your emails will come from the Gmail account you have configured for Postfix.
Next, you’ll need to authenticate Postfix. You can use your account’s Gmail password, which is fine if you create a new account just for Postfix, but if you’re using your personal account, you’ll want to create an app password. This way, the password can be revoked at any time. Note that you will need two factor authentication turned on to use app passwords.
Postfix stores authentication details in /etc/postfix/sasl/sasl_passwd. This file may not be there by default, so you may have to create it with touch. Open it up, and paste your information in:
This configures Postfix to use Google’s SMTP server and authenticate with your details.
Next, run postmap on sasl_passwd:
This will generate a sasl_passwd.db file used by Postfix. Both of these files store your app password in plaintext, so you’ll want to restrict them to root by running chown and chmod:
Postfix should now be ready to go, but you’ll need to configure Postfix’s main configuration file to use SMTP relay and your SASL credentials. Open up /etc/postfix/main.cf in your favorite text editor, and find the “relayhost” option. Change this to use Gmail’s SMTP server:
Then at the end of the file, add the following lines to configure SASL and use your password file.
Save this file, then restart Postfix with systemctl:
Postfix should now be fully configured, and set as the default mail handler on your system. You can test it using Postfix’s own sendmail command:
Check your inbox (or outbox), and you should see a new email. You can run sudo tail -f /var/log/mail.log (or mail.err) to check the mail logs.
Postfix will configure itself as your server’s default mail handler. Any app or program that needs to do emailing should now use Postfix by default, such as PHP (which uses Postfix’s sendmail). Some may need extra configuration, which is usually just telling the app to use Postfix.
If you don’t want to use sendmail (as it is a little clunky) you can install another mail client. A good client is mutt, which supports sending files as attachments, and will use Postfix by default. The syntax for simple sending is:
And for attaching files, you’ll need to seperate the -a flag values from the recipient with a double dash “–“:
Which will show up in your inbox with the file attached, presuming it doesn’t hit any file size limits imposed by the SMTP server:
Whichever mail client you choose, any of them should be usable from within shell scripts, cron jobs, and anywhere else you can configure to run Unix commands.
