Sandboxing email for a local WP site using just three lines of code!

In a local-staging-live workflow, often we have some restrictions on both local and staging / development environments. A common restriction is to disallow indexing of the development site that may introduce duplicate content in the search result, if indexing is allowed (that is not uncommon when we set up the live site and then copy it to develop further :-) ). There are lot more restrictions and workarounds in order to setup a perfect development or local environment. Here, let me share a particular solution regarding emails. Let me start with some of the use cases.

Image for Postfix

Use Case 1 – For staging environment

A staging environment sits on the internet in a host similar to your live site. A staging environment is where you can test your site on a different URL such as https://staging.example.com . Usually, this staging site is password protected so that the search engines or uninvited visitors do not see all the goodies you’d bring in the coming days. You may even test the site by publishing a new soon-to-be-popular post. However, if you have email subscribers, you’d spoil the party by sending the post by email. Usually, there is no restriction on the host to send emails. There are always some exceptions, though, such as Google Compute Engine or Vultr (both block emails in port 25). At the same time, we do not want to disable email subscription completely, either. Because, you’d want to see how the new post looks like in an email. So, basically, you’d want to send emails to selected subscribers (for example, everyone in your team).

Use case 2 – For Local Environment:

A local environment can be a Windows PC, a Mac or a virtual machine running an entire OS or a virtual machine running WordPress as an app. Here, we will have a web server (Nginx / Apache), PHP (php-fpm or HHVM) and MySQL (or MariaDB / Percona) to serve a WordPress site. This seem good overall. However, most such local WP setups will not have the ability to send emails at all. MacOS can send emails, though. I am not going to delve into how to send emails from your local computer / laptop or VM. Similar to the above use case, here, we’d want to send emails only to you (or additionally to your team mates).

How to sandbox in Postfix:

Postfix is one of the popular MTA that comes bundled by default in Ubuntu and in macOS. Debian comes with Exim by default, but can be replaced by Postfix easily (by running sudo apt-get install postfix). Postfix allows a number of modifications, including the ability to control the outgoing emails addresses. Let me provide real-life examples…

The following is what I have in my macOS at /etc/postfix/main.cf

relayhost = ...
smtp_use_tls = ...
inet_protocols = ...

header_checks = regexp:/etc/postfix/header_checks

The “header_checks” entry is the most important entry. This tells Postfix to check the header of each outgoing email and take appropriate actions that are mentioned in the file /etc/postfix/header_checks .

Here is the content of /etc/postfix/header_checks…

$ cat /etc/postfix/header_checks
/^To:.*myusername@gmail.com/ DUNNO
/^To:.*@/ DISCARD Not whitelisted in this computer!

Basically, it instructs Postfix to allow any emails sent to myusername@gmail.com and then discard all other emails with a note “Not whitelisted in this computer”.

With just three lines of code (one in /etc/postfix/main.cf and rest in /etc/postfix/header_checks or the filename of your choice), we can control the outgoing emails in Postfix.

If you belong to an organisation with unique domain name for email addresses and if you want to send emails only to that particular domains (in addition to your another work email address), you may use the following in /etc/postfix/header_checks file…

/^To:.*@example.com/ DUNNO
/^To:.*myusername@gmail.com/ DUNNO
/^To:.*@/ DISCARD Not whitelisted in this computer!

You may have noticed that I have used regex! Yes, we can use regex in this file. DUNNO indicates OK that will let the email to go through Postfix. You may also use OK as syntax. But, it will always mean DUNNO internally within Postfix.

On macOS, if you are not aware, we don’t need to restart Postfix, as it is started on demand. But, with Ubuntu and others, you certainly need to restart or reload Postfix to apply the changes.

For more information on header_checks, please head over to the official header_checks manual.

Leave a Reply

Your email address will not be published. Required fields are marked *