When I'm writing BaSH or SHell scripts - especially when it comes to scripts designed to monitor operational processes - I often find it useful to setup an automated alert system via email. I use Gmail exclusively for my personal email use, and have my account mirrored across multiple devices. So, when something occurs that I need to know about, it's a straight-forward and simple way to get my attention. But, how does one get an Ubuntu server to send email to one's Gmail account? Unfortunately, that is not so straight-forward.
Out-of-the-box, Ubuntu servers don't come with pre-installed, public-facing email services. Furthermore, any mail server software you do install will not natively facilitate sending email via your Gmail account. If you want to setup an email server for a domain name that you have control over, you'll need to configure a service to run a Simple Network Management Protocol (SNMP) service. But, what if you want to leverage some pre-existing email service that you're subscribed to - such as Gmail - and utilize that service to redirect email messages from your Ubuntu server to whoever? For that, you need to setup an email Internet Relay.
Mail Relays
By default, SNMP servers use port 25 to send email messages. This is the industry standard port number, designated for out-bound email messages originating from a given server. Even so, many ISPs (Internet Service Providers) block port 25 due to the proliferation of email spamming servers and bots throughout the Internet. On the odd chance your ISP allows port 25 traffic, this is pertinent if you want to create an out-bound mail server on your LAN that talks to the rest of the world, but what if you just want to leverage an existing mail server operating somewhere else? What if you just want to piggy-back on that existing mail server somewhere, and use it to send out-bound messages from your Ubuntu server to whoever, wherever? What if you don't actually want to create a new email server, but simply leverage an existing one? You need an email relay.
Postfix
There are several different email services you could use that are capable of relaying or redirecting emails from your server to Gmail. I recommend Postfix because it is one of the most straightforward to implement, and supports SSL and TLS. This article will go over the basic configuration process and provide some examples of execution. This process works on Ubuntu 16.04 and later, though there is some additional complexity if you're using Ubuntu 22.04 (see below). If you're running a more traditional Debian server, the process is very similar and an experienced user can likely deduce any necessary tweaks.
The Postfix package in Ubuntu incorporates a trove of email tools. For the purpose of this exercise, the goal is to implement a command-line driven mail execution method embedded within a script. One advantage of Postfix is its native support for SSL and TLS keys. There are internal utilities baked into Postfix which leverage SSL keys for hashing various pieces of information. This saves time and effort, and obviates the need to create and keep track of your own self-signed SSL certs or independent hashing exclusive of mail server/client payloads, which may be required with some other solutions. Postfix takes care of much of this heavy lifting for you.
Install Postfix
Installing Postfix is simple and straightforward.
sudo apt-get install postfix
A minor, but notable drawback to Postfix is its set of potentially cumbersome, required GUI pop-ups during installation (especially headless server environments); though they will appear via terminal access or via a remote terminal client (such as Putty).
During installation, you will need to deal with two (2) prompts (unless you're using Ubuntu 22.04 or later, see below):
- Select "Internet site"
- Specify your server's Fully Qualified Domain Name (FQDN).
Note: It doesn't matter if you provide current FQDN hostname or not. If you want to skip this step, remove any pre-existing value and leave it blank/empty.
Ubuntu 22.04+
Installing Postfix on Ubuntu 22.04 adds a bit more complexity. There are more interactive prompts to respond to during the installation of Postfix, and the installer expects the user to provide more granular guidance. As of this writing, there is a good guide on Digital Ocean that describes the purpose of the additional prompts and provides minimal guidance on how to answer the additional contextual questions.
Say Goodbye to Gmail's Less-Secure App Support
Google recently (May 2022) sunset it's "less secure applications" support in Gmail. Previously, it was necessary to activate an optional feature on your Gmail account that allowed 3rd party applications to use your Gmail account as an email relay. This created obvious security vulnerabilities, even though it was also very convenient. It is refreshing to see that Google has now implemented an innovative solution that lowers the risk profile of using 3rd party apps with your Gmail account, though it is still less secure to use either of these methods at all versus only allowing 2-factor authentication capable devices to access your account.
Two-Factor Authentication
Google actively encourages all users to take advantage of multi-factor authentication in order to reduce the risk of compromised accounts and fraud. If you are using 2-factor authentication on your Gmail account, can you still use Postfix? Yes. Thankfully, Google thought about this and created an ingenious method for allowing third-party applications access to certain Google applications without forcing those apps to pass a 2-factor authentication challenge they cannot meet.
If your Gmail account is not setup for 2-factor authentication, you may skip the next section and proceed to Configuring Postfix, or you may proceed and create a unique Application password anyway (though the primary benefit of following that process is for users utilizing 2-factor auth).
What If My Gmail Uses 2-Factor Authentication?
Your Google account has an option to support Application-Specific Passwords.
This feature works regardless of whether or not you have 2-step authentication enabled (though you should). What you are effectively doing is creating a specific-use password for your account that may be allowed or revoked on a case-by-case basis. It allows you to grant access to your email account via any 3rd party application without compromising your actual account password. This also means you may revoke access to your email account for that specific application alone, whenever you like by simply disqualifying the corresponding password.
How To Create an Application-specific Password for Gmail
Google provides options to follow this process for certain non-email applications (e.g. YouTube), but doing so for email / Gmail purposes is the most common reason.
- Sign in to your Google account
- Go to Settings
- Select Account, under the drop-down choice of graphical icons
- Select Security along the left, vertical navigation menu
- Under "Signing in to Google" select "App passwords"
- Login to your Google account
- Create a new App specific password
- Click on the hyperlink, "Manage third-party access"
- Under the "Select app" dropdown, choose "Mail"
- Under the "Select device" dropdown, select "Other (Custom name)"
- Type the name of your app (e.g. "Ubuntu 20.04 Email Test")
- Select the "Generate" button
- Write down the app password provided. You will need it shortly.
During its creation is the only time you'll be able to view the limited-access account password you just created.
Be sure to make a note of it somewhere, until you have completed setting up Postfix and successfully tested your application.
Configure Postfix
Out-of-the-box, Postfix will not natively work with Gmail. This is because Postfix defaults to the standard SMTP port 25. Many ISPs now block that port on their network in an effort to prevent spam servers from using their networks. Regardless of the reason, quite some time ago Google switched its public-facing SSL based email servers to port 587. Thus, you will need to configure Postfix to use this port either way.
Postfix requires revealing the login credentials (including password) of any email server that you want to leverage. Since this is what you'll be doing... leveraging Google's gmail server... you'll need to share your account credentials with your server. This is why the steps above are utilized to create a one-off password that you can change or disable at will, without needing to reset your primary Gmail account password should that become necessary in the future, for any reason.
Now, it's finally time to configure Postfix, where you will bring all these pieces together to create a robust email relay for your server-side applications. Implement the following steps:
sudo nano /etc/postfix/sasl/sasl_passwd
Add this line at the top of the file:
[smtp.gmail.com]:587 This email address is being protected from spambots. You need JavaScript enabled to view it.:your_app_password
sudo postmap /etc/postfix/sasl/sasl_passwd
sudo chown root:root /etc/postfix/sasl/sasl_passwd /etc/postfix/sasl/sasl_passwd.db
sudo chmod 0600 /etc/postfix/sasl/sasl_passwd /etc/postfix/sasl/sasl_passwd.db
sudo nano /etc/postfix/main.cf
Insert this line:
relayhost = [smtp.gmail.com]:587
In between these two lines:
mydestination = ...
{ new line goes here }
mynetworks = ...
# Enable SASL authentication
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl/sasl_passwd
smtp_tls_security_level = encrypt
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
sudo systemctl restart postfix
- Create a new file to store your Gmail credentials for Postfix. This file will only have one (1) line, which will contain your Gmail account login information, utilizing your new app-specific password for your account.
- Create a SSL hashed version of your Gmail credentials.
- Secure the access permissions of your hashed file.
- Edit the Postfix configuration file so that Postfix is able to utilize your credentials.
- Add the following lines to the end of file /etc/postfix/main.cf
- Restart Postfix so that your changes take effect.
Test Server Email Sending Capability
Finally, use the sendmail command to send a test email.
There are numerous ways to do this.
Method 1: Piping the Whole Enchilada
sendmail is saavy enough to deduce the email Subject, From, and To email addresses by parsing the first lines of a text string or file piped to it via a Linux SHell, such as BaSH. This method works well in a SHell script.
(
echo "From: A Server
" echo "To: This email address is being protected from spambots. You need JavaScript enabled to view it."
echo "Subject: test sendmail email"
echo "This is a test of sendmail."
) | sendmail -t
Method 2: Email the Contents of a File
This method is similar to the first. However, while the first method can work well in a script, when sending email from the command line it's often easier to first compile the email details in a text file, and then tell sendmail to extract the recipient (To) address, subject, and body from the file.
- Create a file and populate it with the relevant information.
- Execute a sendmail command to send the email.
- Confirm the email was received.
Create a new file.
nano filename.txt
Populate the file contents with the email subject and body. Note the last line must be a period (".") by itself. This signifies to sendmail that it has reached the end of the body of the email. The lone period will not be included in the email message to the recipient.
Subject: Email subject goes here on first line
Email Body Line 1
Email Body line 2
.
Parse and send the email.
sendmail This email address is being protected from spambots. You need JavaScript enabled to view it. < filename.txt
Nerd Facts
- HTML formatting may be embedded in the sendmail body (text string) argument. Provided you are certain the email will be viewed in a Web browser, this is an option.
- As of this writing, the most recent version of sendmail is v8.17.1, released 17 August 2021.
- The most recent documentation for sendmail is for version 8.12, but the majority of the information is useful for later versions.