Email attachments not detected in some messages sent with multipart/alternative MIME structure

Products

• Data Loss Prevention Network Prevent for Email

Issue/Introduction

Email attachments not detected by Network Prevent for Email, when the MIME structure of messages is not RFC-compliant.

This is not common, but is more likely to occur in "edge issues" - such as when the IBM Traveler app (a mail client for Notes clients) is installed on mobile devices, and is used to forward messages that originated from 3rd party mail clients (i.e., not Microsoft!).

N/A - as the content is not detected, there are no errors in DLP logs

Environment

The definition of the "Multipart/alternative subtype", in section 7.2.3 of RFC 1341, states that “each of the parts is an 'alternative' version of the same information”.

Examining the MIME structure of the messages (viewing EML files via text editor) reveals that attachments are not being sent correctly in the messages multipart/alternative content.

RFC-compliant messages put identical content within the "alternative" stream - so the "plain" and "html" portions of the message contains the same elements (that is, "multipart/alternative should present alternative versions of the same content).

Messages with content that is RFC-compliant can also put differing content into separate parts of a multipart/mixed or multipart/related message - meaning that attachments may be added separately (as opposed to inline, which is part of the issue).

Cause

A properly formatted SMTP message that is RFC-compliant may be composed with the following structure:

1. multipart/mixed
   • multipart/alternative
   • text/plain
   • text/html
2. application/octet-stream [location of the attachment]

In the above example, DLP will examine both the multipart/alternative and the application/octet-stream parts - and is able to detect any content that is solely present in the attachment.

 

Whereas a message that is not RFC-compliant may be sent in a format as per this example:

1. multipart/alternative
   • text/plain
   • multipart/mixed
     • text/html
     • application/octet-stream [location of the attachment]
     • text/html

In the above example, DLP will only examine the first sub-type ("text/plain") - assuming, based on the "alternative" typing at the initial boundary, that any subsequent sub-structure will include the same content. The non-compliant message above does not do that, therefore DLP does not examine or inspect the attachment - we are literally not "seeing" it.

Resolution

If DLP doesn't detect the message owing to its MIME structure as per the examples above, you may be required to contact your mail or application vendor, to confirm any known issues with the behavior of their mail clients.