E-mails are being rejected with NPE in the mailpath

Products

• Data Loss Prevention Core Package
• Data Loss Prevention Network Monitor and Prevent for Email
• Data Loss Prevention Network Monitor and Prevent for Email and Web
• Data Loss Prevention Network Prevent for Email

Issue/Introduction

In an environment with the Network Prevent for E-mail DLP detection server inserted into the mailflow, some e-mails are seen to be rejected and bounced back to the sender. Other e-mails will be successfully transmitted.

There may be a pattern in which e-mails are bounced back, i.e. e-mails which have an attachment of a specific filetype are bounced. The same e-mails may eventually be successfully transmitted through the NPE and to the downstream MTA. 

You need guidance on what to look at on the NPE side to check why the e-mails are being bounced and whether NPE is the cause.

Environment

Network Prevent for E-mail detector in Forward or Reflect mode

Resolution

1. Have an example e-mail with details such as:
   • sender
   • recipient
   • timestamp of transmission
   • MessageID
2. These details can be then used to look in the NPE detector logs for a specific e-mail, to find out what was the processing outcome.
   The log to check is as follows:
   • For DLP 16.0 RU2 or older: RequestProcessor#.log (where # is the log number)
   • For DLP 16.1: SymantecDLPDetector#.log (where # is the log number)
     

     Below is an example of how a mail bounce may look in the logs:

     com.vontu.mta.rp.log.SmtpLogManager logConnectionAccepted
INFO: (SMTP_CONNECTION.####) Connection accepted (tid=## cid=Upstream-########-####-####-####-############ local=#.#.#.#:# remote=#.#.#.#:#)

     com.vontu.mta.rp.log.SmtpLogManager logForwardConnectionEstablished
INFO: (SMTP_CONNECTION.####) Forward connection established (tid=## cid=Downstream-########-####-####-####-############ local=#.#.#.#:# remote=#.#.#.#:#)

     com.vontu.mta.rp.log.SmtpLogManager logMessageError
INFO: (SMTP_MESSAGE.####) Error while processing message (tid=## cid=Upstream-########-####-####-####-############ message_id=<####@domain.dom> dlp_id=########### size=### sender=<[email protected]> recipient_count=1 disposition=PASS code=541 estatus=<> text=<5.4.1 Content blocked by Internal Firewall> rtime=5.09s dtime=0.5s mtime=<> reason=<Message not accepted by forwarder>)

3. In the log, you can first search by the message ID or the mail sender to find a specific e-mail in the logs and check whether it matches the timestamp.
   
   The example above shows a scenario in which the e-mail has actually been rejected by a firewall on the downstream MTA. The message "5.4.1 Content blocked by Internal Firewall" comes from the downstream MTA. What is important to remember is that the NPE itself is not an MTA and does not block e-mails with such a reply. But, if the downstream MTA blocks an e-mail and provides a detailed message about the cause of the block, the NPE will not complete transmission of the e-mail and will send that block message back to the upstream MTA. So to the sender, it may look as if it's the NPE that blocked the message. In reality, it's the downstream MTA.
   
   The message may be different but it's advised in the same scenario as above to reach out to the team that manages the downstream MTA and have them check why did the MTA or the firewall block the mail delivery.