Cisco Cisco Email Security Appliance C170 Guia Do Utilizador

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.

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, 

 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. 

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.