cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4155
Views
0
Helpful
2
Replies

DLP Attachment Scanning - Size Limitations

David Owens
Level 1
Level 1

Is it documented anywhere what the attachment file size limitations are for DLP scanning?  In the ESA Configuration documentation I read:

"To scan attachments, the content scanning engine extracts the attachment for the RSA Email DLP scanning engine to scan." 

Can you identify what scanning engine is referenced by "content scanning engine" and what is the maximum attachment size it can process?  Also are those settings modifiable and some indcation of performance impact if they are increased to a maximum of 50 MB per attachment?

I know you can make some modifications in the DLP policy, however it is our desire to DLP scan every document sent up to our allowable maximum email size.

If large attachments cannot be scanned we may be forced to reduce our maximum message/attachment file size. 

We are currently using Async O/S 7.5.1-102 and will be moving to 7.6.0 when it comes GA.

1 Accepted Solution

Accepted Solutions

Jeronimo Orona
Level 1
Level 1

Hello David,

The content scanning engine in reference is the same AsyncOS scanning engine responsible or Message and Content Filter scanning. The maximum size of attachment to scan for this scanning engine is controlled by your 'scanconfig' setttings, as configured in the IronPort CLI. The default 'maximum size of attachment to scan' is 5MB.

--

IronPort1.example.com>scanconfig

There are currently 6 attachment type mappings configured to be SKIPPED.

Choose the operation you want to perform:

- NEW - Add a new entry.

- DELETE - Remove an entry.

- SETUP - Configure scanning behavior.

- IMPORT - Load mappings from a file.

- EXPORT - Save mappings to a file.

- PRINT - Display the list.

- CLEAR - Remove all entries.

- SMIME - Configure S/MIME unpacking.

[]> setup

1. Scan only attachments with MIME types or fingerprints in the list.

2. Skip attachments with MIME types or fingerprints in the list.

Choose one:

[2]>

Enter the maximum depth of attachment recursion to scan:

[5]>

Enter the maximum size of attachment to scan:

[5242880]>

<...>

--

Any message that is larger than this limit will be skipped by the scanning engine. This would mean that pertinent DLP policys and filters would not match that same message. Naturally, allowing larger messages to be scanned will result in performance risks, as more system resources would be required to complete the content scanning.

Regards,

-Jerry

View solution in original post

2 Replies 2

Jeronimo Orona
Level 1
Level 1

Hello David,

The content scanning engine in reference is the same AsyncOS scanning engine responsible or Message and Content Filter scanning. The maximum size of attachment to scan for this scanning engine is controlled by your 'scanconfig' setttings, as configured in the IronPort CLI. The default 'maximum size of attachment to scan' is 5MB.

--

IronPort1.example.com>scanconfig

There are currently 6 attachment type mappings configured to be SKIPPED.

Choose the operation you want to perform:

- NEW - Add a new entry.

- DELETE - Remove an entry.

- SETUP - Configure scanning behavior.

- IMPORT - Load mappings from a file.

- EXPORT - Save mappings to a file.

- PRINT - Display the list.

- CLEAR - Remove all entries.

- SMIME - Configure S/MIME unpacking.

[]> setup

1. Scan only attachments with MIME types or fingerprints in the list.

2. Skip attachments with MIME types or fingerprints in the list.

Choose one:

[2]>

Enter the maximum depth of attachment recursion to scan:

[5]>

Enter the maximum size of attachment to scan:

[5242880]>

<...>

--

Any message that is larger than this limit will be skipped by the scanning engine. This would mean that pertinent DLP policys and filters would not match that same message. Naturally, allowing larger messages to be scanned will result in performance risks, as more system resources would be required to complete the content scanning.

Regards,

-Jerry

Thanks you, this confirms what I believed to be the answer.  It does however mean we will need to re-evaluate our DLP and attachment policy regarding email delivery.