Sécurité : Appareil de sécurité de courriel Cisco

Pourquoi est-ce que des dénis de responsabilité dans le bas de page sont affichés comme connexions ?

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit comment apporter des modifications à la configuration sur l'appliance de sécurité du courrier électronique de Cisco (ESA) quand des dénis de responsabilité qui sont destinés pour être inclus comme bas de page d'un email traité sont affichés comme connexion à l'email.

Contribué par Kevin Luu et Robert Sherwin, ingénieurs TAC Cisco.

Pourquoi est-ce que des dénis de responsabilité dans le bas de page sont affichés comme connexions ?

Typiquement, un bas de page affiché comme connexion se produit quand il y a une non-concordance de codage entre le corps du message et un bas de page. Tentatives d'AsyncOS d'encoder le message entier dans le même codage que le corps du message de sorte que le bas de page soit inclus dans le corps (en ligne) et pas inclus comme connexion distincte. Cependant, si le bas de page ne peut pas être combiné avec le corps, de l'ESA CLI vous pouvez utiliser la commande de localeconfig de configurer AsyncOS pour tenter de favoriser, ou convertir, le corps du texte pour apparier le codage du bas de page de sorte que le bas de page puisse être inclus dans le corps du 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

Revenez à la demande principale CLI et commettez les modifications à la configuration.  Vous devriez alors voir les configurations suivantes répertoriées du 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

Informations connexes


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 118501