You are wondering about DLP Email Routing and Mail TTL
Article ID: 242979
Updated On:
Products
Issue/Introduction
You have questions about data retention specific to messages handled by the DLP Cloud Service for Email:
If emails were sent to the DLP Cloud Service for inspection and it couldn't return due for some reason, how long does the DLP Cloud Service retry and hold mail in the queue for (if at all) to be returned to our O365 mail routing instance?
Environment
Release : 15.8
Component :
Cause
You may have experienced an outage when emails sent to the DLP Cloud Service were rejected with DNS-related errors ("450 4.4.312 DNS query failed"), such as occurred earlier this year:
Resolution
About this specific question, the DLP Cloud Service does not hold messages in any queue at all.
DLP's Cloud Service for Email, much like our on-premise Network Prevent for Email, is classed as an SMTP Proxy. So - instead of holding messages in a queue, we simply hold open connections for every message being inspected:
- Accepting one connection from the upstream MTA, in this case, O365
- And opening a simultaneous connection to the downstream MTA:
- If configured in Forwarding mode, a second connection is made to the downstream MTA, which for the Cloud Service is Email Security.cloud
- In Reflecting mode, a second connection is made back to O365, upstream
We hold those connections open during the TLS handshake. If that is successful, we continue holding the connections open while we perform inspection and content extraction as needed.
When DLP inspection is complete, we close the connections, after making any suitable header modifications that might be required. As part of that, we send the final "." (dot) to the downstream MTA, by which we acknowledge the message is complete.
If the message handling fails at any point - such as during the TLS handshake - the upstream and downstream connections are dropped, although if an SMTP error was received (usually originating from the downstream MTA), we will forward that back upstream before closing the connection.
Additional Information
In the case of the specific DNS-related event linked above, of course, it was a DNS resolution failure which was occurring.
Thus, upstream MTAs were unable to resolve the address of your Detector Smarthost, (the FQDN of your Cloud Email Service, "<DetectorID>.ds.dlp.protect.broadcom.com").
As a result of this, upstream MTAs did not make any connections to the DLP Cloud Service for Email.
An RCA for this event is available from Technical Support.
Feedback
