KB Article #169987
Setup email redirection to Secure Mailbox if outbound delivery over TLS fails
Problem
Due to company security requirements, all outbound emails must be delivered securely over TLS and in case TLS fails they must be sent through Secure Mailbox (SM) via email notifications containing private URLs (pURLs).
IMPORTANT: This article outlines two different set ups where all outbound email messages get sent securely and when all email, intended for specific domains gets sent securely. It also takes into account that Secure Mailbox feature is enabled in the license. Should you need to only send *certain* vs ALL outbound messages securely, then a second, independent MailGate server (or an alternative MTA) will be required in the deployment. This is due to the fact that the "keyword" trigger use case (use [secure] in email subject etc.) for Secure Mailbox messages will require second Policy Engine.
Please note: The policy, outlined below is prone to cause endless message loops if not set-up correctly. Please make sure to thoroughly test the policy before putting it in production and should you notice any message loops following the policies being enabled revert all changes immediately and contact Axway Global Support for further assistance.
Resolution
Setup A. Send all outbound email to a specific subset of domains securely
I. Create a new Sending Connection Policy which will be used to require TLS from the next hop relay:
1.1. Navigate to Admin UI > Relay Policies -> Connection Policies -> Sending Connection Policies.
1.2. Create a new sending connection policy with the following options checked:
+ Enable TLS
+ Require TLS
+ Do not use TLS for Secure Collaboration notifications
This sending connection policy can be assigned to either an External domain or host which will enforce the TLS requirement over that specific remote partner.
II. Create a new External Delivery Route which will be used to assure fail-over to the loopback interface (127.0.0.1) if TLS tails:
2.1. Navigate to Admin UI -> Relay Policies -> External -> Delivery Routes.
2.2. Create a new external delivery route - make sure to enable Try using DNS first and add 127.0.0.1 as mail routing host.
III. Assign the newly created delivery route to all domains/hosts for which email should be sent securely.
3.1. Go to Relay Policies > External and add all hosts/domains for which this policy applies. Make sure to select the route, created in step II, as the mail route and the policy, created in step I as the default sending policy:
IV. Creating the required custom policies
Navigate to Admin UI > Content Policies > Outbound > Delivery policies and create 3 new policies in the order, described below:
Policy 1: The goal of the policy is to redirect all emails that are sent from localhost (and were not marked as secure mail notifications before the loop) to go out as secure mail. The header outlined here is added in a later policy, so just add it as-is.
TARGET |
message |
IF |
is sent from any of the IP addresses 127.0.0.1 |
EXCEPT IF |
message contains any of the headers: 'X-SecureMailNotification' or message is a delivery status notification |
THEN |
Redirect to Secure Mailbox using 'My delivery profile' Delivery profile |
Policy 2: This policy will force looped secure notifications to go out through the default delivery profile (which doesn’t have the loopback interface added), so that if a notification cannot be delivered, it doesn’t loop endlessly.
TARGET | message |
IF | is sent from any of the addresses: secureMailer*@yourdomain.com and is sent from any of the IP addresses 127.0.0.1 and message contains any of the headers: 'X-SecureMailNotification' |
THEN | Route using the delivery route: "Default" and continue processing |
IMPORTANT: Under “Sent From: Message is sent from” condition, make sure to click the “sent from” active link and switch the header to custom, and then select both SMTP Envelope sender AND FROM header. If you do not do this, the secure message notifications for the looped messages will go into an endless loop if they cannot be delivered.
Policy 3: This policy adds a header to the secure mail notifications so these can be routed differently by Policy 2.
TARGET | message |
IF | is sent from any of the addresses: secureMailer.*@yourdomain.com |
EXCEPT IF | message contains any of the headers: 'X-SecureMailNotification' |
THEN | add the X-Headers: 'X-SecureMailNotification:YES' and continue processing |
IMPORTANT: Under “Sent From: Message is sent from” condition, make sure to click the “sent from” active link and switch the header to custom, and then select both SMTP Envelope sender AND FROM header. If you do not do this, the secure message notifications for the looped messages will go into an endless loop if they cannot be delivered.
Setup B. Send all outbound email securely
This approach is similar to the one outlined above, but you may skip listing the different external domains and instead create an additional, fourth outbound delivery policy (placed after the ones in setup A), that will redirect all outbound mail to the loopback route first.
This approach also assumes that your 'Default' sending connection policy is set to require TLS:
The policy should read:
TARGET | message |
IF | contains none of the tags: 'Secure Collaboration: PURL' |
EXCEPT IF | is sent from any of the addresses: MAILER-DAEMON and is sent from any of the IP addresses 127.0.0.1 and message is a delivery status notification or message contains any of the headers: 'X-SecureMailNotification' |
THEN | Route using the delivery route: "Loopback route" and continue processing |