SMTP Operational Logs Show Abnormally High rtime Values on Network Prevent for Email (NPE)

Products

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

Issue/Introduction

In some environments, the SMTP operational logs on DLP Network Prevent for Email servers may show some message entries where the "rtime" value is extremely high and the "mtime" is not calculated.

For reference:

rtime = time in seconds for Network Prevent for Email to fully receive the message from the sending MTA (from the time the connection is open until we receive the "." denoting the end of the email).

mtime = the total time in seconds for Network Prevent for Email to process the message (complete time DLP handled the message until the "." is received by the downstream MTA and the connection is closed)

The affected message entries, instead of showing the actual message reception duration, the "rtime" may display a Unix epoch timestamp value.

Additionally, the log entries for the message will typically show:

sender=<>

recipient_count=0

mtime=-0sS

SmtpPrevent_operation log example:

Message complete (tid=##### cid=##### message_id=<#####@#####> dlp_id=##### size=160745 sender=<> recipient_count=0 disposition=PASS code=250 estatus=<2.6.0> text=<2.6.0 <#####@#####> [InternalId=#####, Hostname=#####] 173923 bytes in 1.896, 89.572 KB/sec Queued mail for delivery> rtime=1,771,844,125.02s dtime=2s mtime=-0s)

Environment

DLP Network Prevent for email 16.X, 25.1

Cause

This issue occurs only under very specific circumstances when the upstream SMTP server uses SMTP PIPELINING together with RSET commands within the same SMTP session.

Specifically, when a message transaction is aborted using RSET, and a new message is immediately started within the same connection using pipelining, Network Prevent for Email may fail to correctly register the new message envelope.

Impact:

Even though the logs show a null sender and zero recipients, if an incident is generated for the message, the incident snapshot may still display the sender and recipients extracted from the email headers, not from the SMTP envelope.

However, when this condition occurs, the SMTP envelope sender and recipients are not correctly registered by NPE. As a result, policy conditions that depend on envelope information may not be evaluated correctly.

For example, if a policy is configured to match or exclude sensitive messages sent to a specific recipient or domain, and the message is sent using BCC, the intended recipient will appear only in the SMTP envelope and not in the message headers.

Because NPE is unable to correctly register the envelope recipient in this scenario, policies that rely on envelope recipient information may not be evaluated correctly. This can lead to missed incidents, incorrect policy actions, or false positives, depending on the policy logic.

When this condition occurs:

The MAIL FROM and RCPT TO commands are not properly registered internally.
The message envelope appears in the smtp operational logs as sender=<> and recipient_count=0.
The timing values used to calculate rtime and mtime are not initialized correctly.

Since the detection start time remains 0, the rtime calculation becomes: current_time - 0

This results in a value that corresponds to the Unix epoch time, which appears in the logs as an abnormally large rtime value.

Because the message timing was not initialized correctly, mtime is also not calculated and is shown as: mtime=-0s

Resolution

This issue is expected to be resolved in Symantec DLP version 26.1.

Until the fix is available, the recommended workaround is to disable SMTP PIPELINING on all NPE servers. This ensures that each message is processed sequentially, avoiding the RSET timing issue.

Disabling PIPELINING has no impact on mail processing performance, because each message must still pass through the DLP detection process individually.

Steps to disable PIPELINING:

On the Enforce console, navigate to System > Servers and Detectors > Overview
Select the NPE Server.
Open Server Settings.
Locate the setting "RequestProcessor.AllowExtensions"
Remove PIPELINING from the list of allowed SMTP extensions.
Save the configuration.
Wait at least 30 seconds.
Recycle the NPE server service.

Additional Information

CRE-23376