As part of the investigation, we initially verified that timeouts for DLP Email processing were occuring, such that messages were being released (sent downstream) before DLP Prevent was able to generate an incident that otherwise would have resulted in a Block or Quarantine Response.
Thus, we implemented a header add for messages that do time out, as per the following KB:
Event code 1213 "Messages timed out in detection" (broadcom.com)
The allowed us to confirm which messages were timing out, and to analyze them against the DLP Prevent logs.
DLP Network Prevent for Email
Timeout errors indicated need to tune the Email Prevent environment in response to demand.
Several steps might be taken to improve email performance due to resource constraints and volume of email traffic.
The below is a list that proved useful in this case:
ContentExtraction.ShortTimeout -- 5000 [default, in MS] ==> increased this to 30000
ContentExtraction.LongTimeout -- 30000 [default, in MS] ==> increased this to 120000
MessageChain.MaximumComponentTime -- 40000 [default, in MS] ==> increased this to 240000
MessageChain.MaximumMessageTime -- 60000 [default, in MS] ==> increased this to 240000
Note that the vaslues above need to be determined by trial and error, but the ratios given are recommended to ensure that the following relationships are preserved:
For more information on timeout values and errors, see In an overloaded environment, detection process is timing out (broadcom.com).
For more information on settings for Detection Servers, see Advanced Server Settings (broadcom.com).