PDF(7.7 KB) View with Adobe Reader on a variety of devices
Updated:October 9, 2014
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 how to make changes to the configuration on the Cisco Email Security Appliance (ESA) when disclaimers that are intended to be included as a footer of a processed email are being shown as an attachment to the email.
Why are disclaimers in footer displayed as attachments?
Typically, a footer displayed as an attachment occurs when there is an encoding mismatch between the message body and a footer. AsyncOS attempts to encode the entire message in the same encoding as the message body so that the footer will be included in the body (inline) and not included as a separate attachment. However, if the footer cannot be combined with the body, from the ESA CLI you can use the localeconfig command to configure AsyncOS to attempt to promote, or convert, the body text to match the encoding of the footer so that the footer can be included in the body of the message.
myesa.local> localeconfig Behavior when modifying headers: Use encoding of message body Behavior for untagged non-ASCII headers: Impose encoding of message body Behavior for mismatched footer or heading encoding: Only try encoding from message body
Choose the operation you want to perform: - SETUP - Configure multi-lingual settings. > setup
If a header is modified, encode the new header in the same encoding as the message body? (Some MUAs incorrectly handle headers encoded in a different encoding than the body. However, encoding a modified header in the same encoding as the message body may cause certain characters in the modified header to be lost.) [Y]>
If a non-ASCII header is not properly tagged with a character set and is being used or modified, impose the encoding of the body on the header during processing and final representation of the message? (Many MUAs create non-RFC-compliant headers that are then handled in an undefined way. Some MUAs handle headers encoded in character sets that differ from that of the main body in an incorrect way. Imposing the encoding of the body on the header may encode the header more precisely. This will be used to interpret the content of headers for processing, it will not modify or rewrite the header unless that is done explicitly as part of the processing.) [Y]>
Disclaimers (as either footers or headings) are added in-line with the message body whenever possible. However, if the disclaimer is encoded differently than the message body, and if imposing a single encoding will cause loss of characters, it will be added as an attachment. The system will always try to use the message body's encoding for the disclaimer. If that fails, the system can try to edit the message body to use an encoding that is compatible with the message body as well as the disclaimer. Should the system try to re-encode the message body in such a case? [N]> y
Return to the main CLI prompt and commit changes to the configuration. You should then see the following settings listed from localeconfig:
Behavior when modifying headers: Use encoding of message body Behavior for untagged non-ASCII headers: Impose encoding of message body Behavior for mismatched footer or heading encoding: Try both body and footer or heading encodings