The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes the differences between the drop-attachments-by-name, -type, -filetype, and -mimetype message filter actions on the Cisco Email Security Appliance (ESA).
Messages that are sent using MIME can have labels assigned to various body parts, which are often called attachments. These labels can (and do) conflict with each other in the information they provide. In addition, a body part might have its own characteristics. For example, a user might take a JPEG image, attach it to a mail message, give it a MIME type of text/html, and mark it with a MIME filename of jan.mp3. All of these labels conflict with the reality of what the attachment is.
For example, consider this message header:
Content-type: application/msword; name="eval form.doc"
Content-disposition: attachment; filename="eval form.doc"
Content-description: eval form.doc
In this case, the MIME filenames and MIME types are all consistent and might or might not match the actual format of the body part (attachment). However, in this header, there are inconsistencies:
Content-type: image/jpeg; name="eval form.doc"
Content-disposition: attachment; filename="evaluation.zip"
Content-description: These are the latest warez, d00d.
For well-formed messages, implementing policy is fairly easy. But in the case of someone either intentionally or unintentionally trying to bypass policy, additional flexibility is required.
Network managers often want to drop attachments of a particular type, such as all MP3 files. However, implementing this policy means that you have to decide which of the labels you want to pay attention to (if any of them). AsyncOS gives you the flexibility to look at the MIME type (such as text/html), the MIME filename (such as jan.mp3), and to actually fingerprint the attachment in order to try and determine what the true format is. When implementing your policy using message filters or content filters, you might want to use one or more of these labels.
Here are the message filter action descriptions: