This website post will walk you through the steps had a need to integrate Amazon WorkMail having an email security gateway. Configuring WorkMail this real way can offer a versatile defense technique for inbound email threats.

Amazon WorkMail is really a secure, managed business calendar and email service. WorkMail leverages the e-mail receiving capabilities of Amazon Simple Email Service (Amazon SES) to scan all outgoing and incoming email for spam, malware, and viruses to greatly help protect your users from harmful email. AWS Lambda for Amazon WorkMail functions can utilize the capabilities of other AWS services to perform additional business objectives, such as for example controlling message message or delivery modification.

For most organizations, existing integrations and features with Amazon SES are sufficient because of their spam, malware, and virus detection. Other organizations might need a separate on-premise security solution either, or have other reasons to utilize yet another inspection point in the entire mail flow. A genuine amount of commercial and community-supported tools include features like special encryption capabilities, data loss prevention (DLP) content inspection engines, and embedded-hyperlink transformation features to safeguard end-user mailboxes.

Prerequisites

To implement this solution, you will need:

• A domain name and permission to improve domain name system (DNS) records in Amazon Route 53 or your existing DNS provider. This may be your organization’s existing domain (such as for example example.org), a fresh domain (such as for example example.net), or perhaps a subdomain (such as for example sub.example.org).
• Usage of an AWS account in order to configure Amazon and WorkMail SES. Optionally, you might need the capability to create &lt also;a href=”https://aws.amazon.com/lambda/” target=”_blank” rel=”noopener noreferrer”>AWS Lambda functions to integrate with WorkMail.
• Usage of configure the e-mail security gateway of one’s choosing.

How email flows having an email security gateway

Email security gateways function by handling the original ingress of email via the easy Mail Transport Protocol (SMTP). When email servers send messages to your domain’s email addresses, they look at your domain’s mail exchange (MX) record in the DNS. After processing a contact message, the e-mail security gateway delivers it to the downstream mailbox hosting service, such as for example WorkMail, through Amazon SES via SMTP. It is possible to optionally configure an&amp also;nbsp;AWS Lambda for Amazon WorkMail function to provide messages into end-user junk email folders synchronously, or even to take other actions.

The interaction points are the following:

1. The e-mail sender looks up the mail exchange (MX) record for the domain hosted by WorkMail. The domain name system (DNS) domain could be hosted along the way 53, or by another DNS hosting provider. The worthiness of the MX record provides the internet protocol (IP) address of the e-mail security gateway.
2. The e-mail sender connects to the e-mail security gateway, and sends the message utilizing the Simple Mail Transfer Protocol (SMTP)
3. The e-mail security gateway accepts, processes, and delivers the message to the ingress SMTP endpoint for WorkMail then. Amazon Simple Email Service (Amazon SES) handles inbound email receiving for WorkMail.
4. Optionally, an AWS Lambda for Amazon WorkMail function can process messages before delivery to WorkMail synchronously.
5. WorkMail receives the message for final delivery to the end-user.

The gateway assumes responsibility for inspecting incoming email, as the initial point of ingress can be an important element of a multi-layer defense strategy against email-borne threats. The gateway could refuse or quarantine risky messages, it might modify the e-mail body and subjects to include warnings noticeable to recipients, or it might append metadata to the e-mail headers for downstream processing by an AWS Lambda function.

What’s email authentication

Today smtp was built at the same time when networking was less reliable than it really is, and consequently, it had been designed to have the ability to allow any domain to store and later forward messages with respect to other domains to mitigate connection problems. While that helped at the proper time, today it presents real problems in authenticating who truly sent a note: who owns the domain, or another person claiming to function as owner just? To overcome this presssing issue, the messaging industry has adopted three protocols to greatly help verify the authenticity of a note: SPF, DKIM, and DMARC. These protocols aren’t perfect, but finding out how to use them is essential when adding new steps to your message processing workflow, since they can affect the way you receive inbound mail.

Sender Policy Framework

Sender Policy Framework (SPF) permits domain owners to declare which SMTP servers are permitted to send electronic mails claiming to be from their domain. This establishes an identity relationship between your owner of the domain and the authorized party that controls the SMTP server. When SPF can be used, a message can only just be handed faraway from a certified SMTP server directly; it can’t be relayed by way of a second, unauthorized server without changing the originating address.

DomainKeys Identified Mail (DKIM)

DomainKeys Identified Mail (DKIM) permits domain owners to market a public key a mail recipient’s system may use to verify the sender’s digital signature. This enables SMTP servers along with other downstream applications to check on the validity of the digital signature contrary to the public key of the domain which had the matching private key to generate the signature. DKIM signatures mounted on messages can remain intact through intermediary SMTP servers, but if message contents (email body or email headers) are modified by intermediary servers, the ultimate destination shall discover that the signature is not any longer valid.

Domain-based Message Authentication, Reporting and Conformance (DMARC)

Domain-based Message Authentication, Reporting and Conformance (DMARC) permits domain owners to create an insurance plan telling receiving servers how to proceed when SPF or DKIM aren’t valid, such as in case a message comes from an unauthorized server, or if it had been tampered with after being sent. DMARC checks in case a message matches what it is aware of the sender via DKIM and SPF, a process referred to as alignment. The recipient’s server can enforce the DMARC policy, for instance by quarantining or rejecting non-aligned messages.

Tying everything together

Amazon WorkMail performs DMARC enforcement for inbound messages normally, predicated on their alignment if they were received by Amazon SES. However when a contact security gateway acts being an intermediary SMTP server between your original WorkMail and sender, that breaks the partnership with the SMTP servers authorized by SPF, and when the gateway modifies the message, that invalidates the DKIM signature. For this reason it’s essential for the SMTP server at the idea of ingress to execute the evaluation of SPF, DKIM, and DMARC. The e-mail security gateway at the border ought to be made in charge of enforcing DMARC on messages that don’t align, and WorkMail DMARC enforcement ought to be disabled.

The interaction points for SPF policy enforcement are the following:

1. The e-mail sender delivers the message to the e-mail security gateway with a MAIL FROM address inside a domain the sender owns.
2. The e-mail security gateway looks up the sender’s domain’s Sender Permitted From (SPF) policy in DNS to find out if the sending mail server’s Ip is authorized.
3. The message is delivered by the e-mail security gateway to Amazon SES with exactly the same MAIL FROM address. The e-mail security gateway includes a different IP address compared to the original sending email server.
4. When Amazon SES looks up the MAIL FROM domain’s SPF, it shall not discover the email security gateway’s Ip as authorized. From the perspective of Amazon SES, and the resulting logs in Amazon Cloudwatch, the message shall look like unauthorized by the SPF policy. This total result is ignored by disabling DMARC checks in the WorkMail organization configuration.
5. The message continues delivery to WorkMail having an optional integration with AWS Lambda for Amazon WorkMail synchronous run configuration, that may analyze message headers to obtain a more complete picture of the message’s authenticity.

Choosing a contact security gateway

Many email security vendors offer software as something (SaaS) solutions. This offloads all management responsibilities to the program vendor’s platform. These solutions are long because they support the e-mail gateway features essential for this solution as depicted in Figure 2 and described in the Why point of ingress email authentication is essential section above.

If you want to build and maintain your personal email security gateway, you may deploy one available from the AWS Marketplace or add an open source application into your Amazon Virtual Private Cloud (Amazon VPC). You shall need to remove port 25 restriction from your own EC2 instance for the e-mail security gateway inside your Amazon VPC to send email to Amazon WorkMail.

How exactly to configure Amazon WorkMail

Follow this process to configure your WorkMail organization and Amazon SES Ip filters to allow the e-mail security gateway to process inbound email receiving.

To configure Amazon WorkMail

1. From the WorkMail console, select your company, navigate to Organization settings, and choose Advanced. Edit the Inbound DMARC Settings and set Enforcement enabled to Off. This means that WorkMail will not re-evaluate DMARC.

   

   Figure 3. Picture of the AWS WorkMail console showing the advanced configuration depicting Inbound DMARC enforcement disabled

2. From the Amazon SES console, navigate to Email receiving and create Ip filters to permit the Ip or IP address selection of the gateway(s).
3. Add another rule to block 0.0.0.0/0. This prevents malicious actors from bypassing your email security gateway.

   

   Figure 4. Picture of the Amazon SES console showing example Ip filters to allow the e-mail security gateway IP addresses and blocking almost every other IP Address

4. From the Route 53 console, navigate to Hosted zones, choose the domain and edit the MX record to the Ip or hostname of the gateway. This causes all email senders to provide to your gateway, of delivering right to WorkMail instead.
   Follow the instructions of one’s DNS provider if the domain’s DNS elsewhere is hosted.

   

   Figure 5. Picture of the Amazon Route 53 console showing that the DMS MX record for the domain must be configured with the Ip of the e-mail security gateway

5. From the WorkMail console, navigate to Domains, select your domain showing the Domain verification status page.
6. Copy the host name from the worthiness of the MX record type as depicted in Figure 6.

   

   Figure 6. Picture showing the portion of the MX record value to copy from the WorkMail console.

7. Configure your email security gateway with the worthiness which you copied (e.g. inbound-smtp.us-east-1.amazonaws.com) to send inbound messages to your WorkMail organization. Instructions for achieving this will vary based on which email security gateway you’re using.

Some specifics of the configuration be determined by which gateway you’re using, how it really is created for high availability, and the sort of features configured. Test thoroughly your WorkMail integration with a non-production domain before changing your production domain.

It really is normal for Amazon CloudWatch logs for WorkMail, along with the individual message headers, showing that SPF fails for several messages which traverse the gateway. Configure the e-mail security gateway to record its SPF evaluation in the message headers such that it remains designed for troubleshooting and additional processing.

Junk E-Mail folder integration

WorkMail moves spam messages in to the &lt normally;strong>Junk E-mail folder within each recipient’s mailbox. To reproduce this behavior for spam messages identified by the e-mail security gateway, use AWS Lambda for Amazon WorkMail with a synchronous run configuration to perform a function for each and every inbound message to a combined band of recipients.

To configure an AWS Lambda function for each inbound message (optional)

1. Configure the e-mail security gateway to add a spam verdict in the message headers for several incoming mail.
2. Develop a synchronous run configuration using AWS Lambda for Amazon WorkMail  to interpret the message headers and return a reply to WorkMail with type: BYPASS_SPAM_CHECK or MOVE_TO_JUNK. An example Amazon WorkMail Upstream Gateway Filter solution comes in the AWS Serverless Application Repository.

Conclusion

By integrating a contact security gateway and leveraging AWS Lambda for Amazon WorkMail, you’ll gain additional management and security control over your organization’s inbound email. To learn more, browse the Amazon WorkMail FAQs and Amazon WorkMail documentation.

When you have feedback concerning this post, submit comments in the Comments section below.

Want more AWS Security news? Follow us on Twitter.