Popular Searches

How to Set Up a Mail Agent for Command Line Email

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.

If you’re planning on sending emails out to end users, you’ll need to configure more information with your SMTP provider. This usually means verifying your domain with DKIM and SPF authentication, which proves you own the domain and aren’t spoofing your address. You can do this with Gmail, but if you’re sending out a lot of emails, you should be using a business solution like Amazon SES.

How to Install and Configure Postfix

The simplest solution for command line email is to use Postfix as a MTA, using a free SMTP server like Gmail. Gmail is rate-limited to 100 emails per day, which is likely enough for simple email notifications. If you need more than that, you can use Amazon SES or SendGrid, which should both be drop-in replacements for Gmail’s SMTP server in this example.

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:

sudo apt-get install postfix libsasl2-modules

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:

[smtp.gmail.com]:587 username@gmail.com:password

This configures Postfix to use Google’s SMTP server and authenticate with your details.

Next, run postmap on sasl_passwd:

sudo postmap /etc/postfix/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:

sudo chown root:root /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db
sudo chmod 600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db

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:

relayhost = [smtp.gmail.com]:587

Then at the end of the file, add the following lines to configure SASL and use your password file.

# enable SASL authentication
smtp_sasl_auth_enable = yes
# disallow methods that allow anonymous authentication.
smtp_sasl_security_options = noanonymous
# where to find sasl_passwd
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
# Enable STARTTLS encryption
smtp_use_tls = yes
# where to find CA certificates
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

Save this file, then restart Postfix with systemctl:

sudo systemctl restart postfix

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:

sendmail recipient@gmail.com
FROM: youremail@gmail.com
SUBJECT: Hello from your server!
This is a test email sent from your server by Postfix.

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:

echo "email content" | mutt -s "email subject" recipient@gmail.com

And for attaching files, you’ll need to seperate the -a flag values from the recipient with a double dash “--“:

echo "email content" | mutt -s "email subject" -a /path/to/file -- recipient@gmail.com

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.

Anthony Heddings Anthony Heddings
Anthony Heddings is the resident cloud engineer for LifeSavvy Media, a technical writer, programmer, and an expert at Amazon's AWS platform. He's written hundreds of articles for How-To Geek and CloudSavvy IT that have been read millions of times. Read Full Bio »

The above article may contain affiliate links, which help support CloudSavvy IT.