Sending emails natively from Google Cloud Pub/Sub events

Overview

Google Cloud normally recommends using tools such as SendGrid to send emails from Cloud Functions triggered by Cloud Pub/Sub. Some organizations for business reasons may not wish to use a third-party for sending emails. Also, you may want your emails to come from a static IP address which would require the use of a higher level tier of such services that comes with additional costs.

pubsub_sendmail is a Google Cloud Function that can be triggered by a Google Cloud Pub/Sub which then sends an email using Python smtplib to the desired recipient. You can also have the email come from a static IP address by using a VPC Access Connector along with Cloud NAT.

pubsub_sendmail is configured using environment variables in the deployment shell script. These environment variables are described in a later section of this document. Revisions or bug fixes are welcome. You can also of course adapt the code to any use cases that are not covered.

Services such as SendGrid offer many production level features at various service tiers and are supported by the service vendors. If your mail volume is relatively low but you need send email from a static IP, using a native Cloud Function like pubsub_sendmail is another option. The tradeoff is that you must implement and support the Cloud Function. The pubsub_sendmail function supports the use of a static IP using the VPC Access Connector along with Cloud NAT.

Diagram

Here is a diagram of how a message issued from Cloud Pub/Sub would travel through the Cloud Function and then generate an e-mail.

Encryption

You can configure pubsub_sendmail to use forced, opportunistic, or no encryption. With forced encryption (also called implicit), the entire session with the mail server is encrypted from start to end. Nothing is in plaintext. With opportunistic encryption (also called explicit) the session begins in plaintext but is subsequently elevated to encrypted by sending a STARTTLS command. Said differently, if encryption is allowed (but not required) by the server it is opportunistic. If it is required by the server it is forced. When no encryption is supported, the entire session is in plaintext (highly unlikely).

Want to learn more?

For additional information including configuration and troubleshooting steps, please consult the GitHub repository. If you want to make enhancements, please feel free to submit a pull request.