Connexions n'étant pas relâché comme prévues et un de ce qui suit :
Le filtre de message utilise le baisse-connexion-par-filetype.
Le filtre satisfait utilise Drop_Attachments_By_Filetype_Action.
Les connexions de baisse par action de filtre de Filetype examine des connexions basées sur l'empreinte digital du fichier, et pas simplement de l'extension de nom du fichier de trois-lettre. Il y a quelques raisons pour lesquelles ce balayage peut ne pas s'assortir sur un fichier comme prévu.
Ce balayage d'empreinte digital sera seulement exécuté sur les connexions qui sont sous la taille maximum de balayage comme placent dans le scanconfig (du CLI). Si la connexion est des archives et la taille totale du contenu extrait est plus grande que la taille maximum de balayage ou dépasse la profondeur maximum de balayage, l'empreinte digital ne sera pas vérifiée les fichiers individuels. Encoder un fichier pour le transport d'email a généralement comme conséquence plus de données puis quand le fichier est enregistré sur le disque. L'un ou l'autre de ces deux derniers éléments peut expliquer pourquoi quelques connexions plus petites que la taille maximum de balayage ne sont pas abandonnées.
Il a pu également y avoir eu une erreur de balayage et il est possible que le type MIME détecté soit configuré pour être ignoré. Pour découvrir la cause précise pour un message donné, recherchez les logs de messagerie utilisant le grep du CLI. Quand vous recherchez sur le MID, toutes les questions de balayage seront signalées sur leur propre ligne. Voici un exemple :
Tue Aug 3 16:36:29 2004 Warning: MID 256, Message Scanning
Problem: Continuation line seen before first header
Il y aura également une ligne qui affiche la taille globale de message dans les octets, qui te donneront une idée approximative de la façon dont grand la connexion encodée est
Wed Jun 16 21:42:38 2004 Info: MID 200257070 ready 24663
bytes from <someone@example.com>