IronPort - advanced configuration guide

Chapter 6 Using Message Filters to Enforce Email Policies
OL-25137-01
If a header was modified by a previous processing action, any subsequent header rule will evaluate
the modified header and not the original message header.
This behavior is common to both message filters and content filters.
Message Bodies vs. Message Attachments
An email message is composed of multiple parts. Although RFCs define everything that comes after a
message’s headers as a multipart “message body,” many users still conceptualize a message’s “body” and
its “attachment” differently. When you use any of the Cisco IronPort message filters named
body-variable or attachment-variable, the Cisco IronPort appliance attempts to distinguish the parts
that most users consider to be the “body” and the “attachment” in the same way that many MUAs attempt
to render these parts differently.
For the purposes of writing body-variable or attachment-variable message filter rules, everything after
the message headers is considered the message body, whose content is considered the first text part of
the MIME parts that are within the body. Anything after the content, (that is, any additional MIME parts)
is considered an attachment. AsyncOS evaluates the different MIME parts of the message, and identifies
the parts of the file that is treated as an attachment.
For example, Figure 6-1 shows a message in the Microsoft Outlook MUA where the words “Document
attached below.” appear as a plain text message body and the document “This is a Microsoft Word
document.doc” appears as an attachment. Because many users conceptualize email this way (rather than
as a multipart message whose first part is plain text and whose second part is a binary file), the Cisco
IronPort uses the term “attachment” in message filters to create rules to differentiate and act on the .doc
file part (in essence, the second MIME part) as opposed to the “body” of the message (the first, plain
text part) — although, according to the language used in RFCSs 1521 and 1522, a message’s body is
comprised of all MIME parts.
Figure 6-1 Message with “Attachment”
Because the Cisco IronPort appliance makes this distinction between the body and the attachment in
multipart messages, there are several cases you should be aware of when using the body-variable or
attachment-variable message filter rules in order to achieve the expected behavior:
If you have a message with a single text part—that is, a message containing a header of
“Content-Type: text/plain” or “Content-Type: text/html” — the Cisco IronPort appliance will
consider the entire message as the body. If the content type is anything different, the Cisco IronPort
appliance considers it to be a single attachment.
Some encoded files (uuencoded, for example) are included in the body of the email message. When
this occurs, the encoded file is treated as an attachment, and it is extracted and scanned, while the
remaining text is considered to be the body of the text.
A single, non-text part is always considered an attachment. For example, a message consisting of
only a.zip file is considered an attachment.
Cisco IronPort AsyncOS 7.6 for Email Advanced Configuration Guide
6-5