We are occasionally requested to set up and deploy mail services for our clients so that their services can send reminders, notifications, billing runs, etc.  Thankfully, mail is one of our fortes.  We have built and maintained mail clusters utilizing open source software (OSS) such as postfix and dovecot with over 8 million accounts on the platform.

We can practically converse in SMTP, IMAP, and POP protocols.  TLS is making that a bit more difficult for us to use spoken word, however.

Mail is simple if you have a single server running your entire shop. You set up all of your services including Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting & Conformance (DMARC), and you don’t have to touch it again save for regular updates and patching.  Once you introduce a handful of servers, the situation becomes a bit more complex as you now have to manage and update all of those policies to account for your new server(s), and in the time of the cloud, your servers can be on completely different networks.

Host Based Relaying

In order to simplify things and centralize your mail services, there are two main infrastructure designs.  It doesn’t make sense to have every server configured as a complete mail server, so the first option is what we will call “Host Based Relaying”.  This involves each individual node having credentials to a mail service, Gmail for example, and sending messages to Google for ultimate delivery.  It would look something like Figure 1.

Figure 1: Host Based Relaying

In this scenario, each machine has a stripped down version of postfix and its sole job is to get the message to Google.  We do not have any sort of SPF, DKIM, or DMARC configured on each machine, instead, those services are configured on the Google platform.  This decreases the administrative overhead significantly.

Dedicated Relaying

Host based relaying works well with a handful of machines, but we still manage credentials on each machine.  We can further reduce our overhead and streamline our configuration by creating a dedicated relay.  The purpose of this single machine, or a load balanced pool of machines is the same as every machine in Host Based Relaying, to get the message to Google for final delivery.

Figure 2: Dedicated Relaying

In this scenario, the Dedicated Relay servers are the only machines that store the Google credentials. The configuration of all the other machines can be done with host or network based relay permissions and we eliminate most of the complexity.

Scaling and SaaS

So what happens when you have hundreds of machines?  Surely you might overstay your welcome at Google.  In that scenario, your dedicated relays become the nodes configured with SPF, DKIM, and DMARC.

There are also several Software as a Service (SaaS) solutions built specifically to handle high volumes of email.  They all have APIs so integrating with them is quite trivial.

What about Postfix and Ansible?

Now that you have a decent grasp of the options, we’ve published a basic Ansible script on our Github to configure a machine to relay via Google.  You can find the documentation and code at https://github.com/Revenni/Ansible-Postfix-GSuite-Relay.

Can you do it for us?

Absolutlely. Drop us a line.