Network SMTP incident doesn't retain attachment from original e-mail

Products

• Data Loss Prevention Network Protect
• Data Loss Prevention
• Data Loss Prevention Network Monitor and Prevent for Email
• Data Loss Prevention Network Prevent for Email

Issue/Introduction

An e-mail which originally contained an attachment was sent through the Network Prevent for E-mail detection server and generated a Network SMTP incident.

However, the incident does not contain the attachment from the e-mail. It's possible to download the original e-mail from the incident using the Open Original Message link, and the attachment can be then seen in that downloaded e-mail. The problem is that it has not been stored in the DLP incident which was generated. 

Cause

The Network Prevent for E-mail DLP detector will recognize an attachment to an e-mail if the e-mail is a MIME-formatted message, using multipart/mixed Content-Type. In such a scenario, the e-mail structure will be divided into separate parts, each representing a different component of the e-mail. These components will be the mail body and all attachments, listed out as separate parts of the multipart message. 

Below is an example header structure of a MIME multipart e-mail with attachment:

From: sender@domain
To: recipient@domain
Subject: subject
Date: Fri, 31 Oct 2025 14:43:33 +0100
Message-ID: MessageID_value
MIME-Version: 1.0
Content-Type: multipart/mixed;
    boundary="----=_NextPart_000_0019_01DC4A74.C775A530"

This is a multipart message in MIME format.

------=_NextPart_000_0019_01DC4A74.C775A530
Content-Type: multipart/alternative;
    boundary="----=_NextPart_001_001A_01DC4A74.C775CC40"

Later on there's a part where the mail body is stored, which may begin as below:

------=_NextPart_001_001A_01DC4A74.C775CC40
Content-Type: text/html;
    charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

And then a part where the attachment and its subheaders are stored:

------=_NextPart_000_0019_01DC4A74.C775A530
Content-Type: application/octet-stream;
    name="test.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
    filename="test.zip"

When such MIME-formatted e-mail generates a Network SMTP incident on the NPE detector, the incident will by default include the attachment extracted from the original e-mail. The NPE is able to locate and extract the attachment from the e-mail because the multipart formatting ensures that the components are separated from each other and extractable. 

E-mails that do not follow this formatting structure may produce incidents where the NPE was unable to extract the attachment, due to an inability to find it inside the e-mail. Below is an example of an incorrectly formatted e-mail which will see this problem:

From: sender@domain
To: recipient@domain
Subject: subject
Date: Fri, 31 Oct 2025 14:43:33 +0100
Message-ID: MessageID_value
MIME-Version: 1.0
Content-Type: application/octet-stream;
    name="test.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="test.zip"

The problem with that e-mail is that it doesn't use the standard MIME format and doesn't have its top Content-Type set to multipart/mixed. Instead, the mail itself uses the Content-Type application/octet-stream as its top Content-Type. Details about the attachment are also included in the message's top headers.
As a result, the NPE will interpret the e-mail structure as if the attachment was placed directly in the mail body. In such a scenario, the NPE will not be able to extract the attachment from the e-mail to store it in the Network SMTP incident. 

Resolution

The requirement on the NPE side is that the e-mail has to follow a standard MIME format and use a multipart Content-Type, in a way that each of the e-mail's components (body and all attachments) is stored within the mail structure as a separate subitem. The mail formatting itself is fully controlled by the entity sending the e-mail, which could be either an end user, or an automated system which generates e-mails i.e. with reports. It may be then required to adjust the MTA or application that sends the e-mails so that the messages use the MIME multipart formatting to allow DLP to successfully retain attachments from the e-mails in Network SMTP incidents. 

Additional Information

NOTE: there could also be other reasons why a Network SMTP incident is missing attachments. Below KB article covers some of these possible scenarios:

The original message in a DLP SMTP Incident is missing several attachments.