SMTP Block events not working despite multiple incidents for one email
Article ID: 274992
Updated On:
Products
Issue/Introduction
You were experiencing issues with email messages being resent after a Block responses were recorded for an incident in DLP.
You can see as many as 8 policies may have recorded block events but the emails are neither delivered nor blocked. Instead they seem to be resent every 14-15 minutes.
At the upstream MTA, the following event is recorded:
{LED=421 4.4.0 Remote server response was not RFC conformant}
Environment
Release : All supported versions of the following components:
- DLP Cloud Service for Email
- Network Prevent for Email
- Cloud Prevent for Email
Cause
A properly recorded Block response includes a "550-5.7.0" which tells the MTA not to resend but to set the message delivery to FAIL.
If a certain number of incidents with Block response rules are triggered by a single email, a DLP CDS or Email Prevent server will try to add the "Block response to sender" for every configured Response Rule that is called.
At which point, the "Block response to sender" being sent back to the MTA is too long and the MTA may record this as a "421 4.4.0" response, which means the MTA will keep resending the message until it is successful (triggering more incidents and responses), or delivery times out (~24 hours).
Resolution
The following workarounds can be considered:
- Delimit policies such that fewer policies with a Block Response will be triggered by each email - in a sense, ensure that policies are tuned as much as possible to isolate or individuate detection and response.
- Reduce the size of the "Block message to sender" component in the Response Rule, so that the data send to the upstream MTA is smaller and doesn't trip RFCs for message text accompanying the SMTP error code.
- Alternatively, ensure that email messages sent for testing purposes will not violate more than X policies with the Block response.
- If this event was triggered via testing protocols, reconfigure the test emails such that each will only trigger 2 or 3 block responses. That way you know detection works, but don't have the issues with the block rule being applied.
Additional Information
Deep data dive for Block Response Rules: how much is too much?
The cap on these responses is ~1 Kb - but that's not the complete story on what is sent.
If a Response Rule includes a "Block message to sender", that data might be as follows:
The Customer Data Loss Prevention (DLP) solution is designed to ensure that confidential information is protected. This transmission is not permitted under Customer DLP Policy. If you have any questions, please contact [email protected]. IT Security.
That's 270 characters - roughly 270 bytes of data.
However, when the "Block response to sender" is delivered to the upstream MTA, DLP adds an SMTP code, and a space, as a prefix to every line. (This is another requirement of RFC5321; see page 49).
So, with those codes added, the message as sent for one Block Response would be more like 310 characters:
550-5.7.0 The Customer Data Loss Prevention (DLP) solution is designed to ensure that confidential information is protected.
550-5.7.0 This transmission is not permitted under Customer DLP Policy.
550-5.7.0 If you have any questions, please contact [email protected]
550 5.7.0 IT Security.
If a sent message resulted in 4 incidents being triggered, each of them having the above Block response, the total character count resulting would be 1240 characters:
550-5.7.0 The Customer Data Loss Prevention (DLP) solution is designed to ensure that confidential information is protected.
550-5.7.0 This transmission is not permitted under Customer DLP Policy.
550-5.7.0 If you have any questions, please contact [email protected]
550 5.7.0 IT Security.
550-5.7.0 The Customer Data Loss Prevention (DLP) solution is designed to ensure that confidential information is protected.
550-5.7.0 This transmission is not permitted under Customer DLP Policy.
550-5.7.0 If you have any questions, please contact [email protected]
550 5.7.0 IT Security.
550-5.7.0 The Customer Data Loss Prevention (DLP) solution is designed to ensure that confidential information is protected.
550-5.7.0 This transmission is not permitted under Customer DLP Policy.
550-5.7.0 If you have any questions, please contact [email protected]
550 5.7.0 IT Security.
550-5.7.0 The Customer Data Loss Prevention (DLP) solution is designed to ensure that confidential information is protected.
550-5.7.0 This transmission is not permitted under Customer DLP Policy.
550-5.7.0 If you have any questions, please contact [email protected]
550 5.7.0 IT Security.
That's more than 1 Kb, and is why the defect triggers a "non RFC conformant" message from the upstream MTA.
Feedback
