Working with a customer to install SMG and Prevent for Email 11.6 using the DLP Connect feature that comes with SMG 10.5. The mail flow is as follow:
GMAIL > SMG > DLP (Reflective mode) > SMG > GMAIL.
Two response rules have been created and associated to a DLP test policy:
If high: Add header x-block; SMG action: delete message
If medium or Low: Add header x-encrypt; SMG action: redirect to encryption gateway
Send notification to sender on either action
The customer's objective is to route email back on premise to inspect content before it goes out of Gmail.
Integration works as expected the first time an email is sent; an incident is generated and actions are taken accordingly. When we tried resending the same message (go to sent folder and forwarding the message); the incident is not generated and message is delivered by SMG to the final destination.
After going through the logs with support we discovered the following header in the Prevent for Email server RequestProcessor0.log:
INFO: (SMTP_CONNECTION.1201) Connection accepted (tid=2c cid=1 local=PE server remote=x.x.x.x:50934)
Jan 29, 2015 9:45:50 AM com.vontu.mta.rp.ESMTPRequestProcessorThread connectNextHop
INFO: (SMTP_CONNECTION.1203) Forward connection established (tid=2c cid=2 local=PE server:1644 remote=x.x.x.x:25)
Jan 29, 2015 9:45:50 AM com.vontu.mta.rp.RequestProcessorHandler handleLine
FINER: RPT(2c)|S: EHLO Bypass_loop_detection
That EHLO Bypass_loop_detection is the only thing that I see different from a regular email that generates an incident but I need to identify where is this coming from, I don't think the problem is with DLP since the policy works every time a new email is sent. But there seems to be a condition somewhere to bypass DLP when the message is being resend (my working theory).
About to test two things to troubleshoot this scenario:
1. Disabling the SMG option to bypass DLP when it is not available since this is the only place I can see that a bypass function could be triggered.
2. Currently the 2 Prevent servers connected to SMG are using the same metric (they both are 1). This suppose to provide load balancing capabilities, but I am wondering if I could be running into a bug with this.
3. About to run the SMG finer logs to try to identify the source of the bypass_Loop_detection command
We also have Gmail investigating on their end.
Any feedback will be greatly appreciated.
-Leo