Pregunta:

Conexiones que no son caídas como se esperaba y una del siguiente:

El filtro del mensaje está utilizando el descenso-conexión-por-tipo de archivo.

El filtro contento está utilizando Drop_Attachments_By_Filetype_Action.

Las conexiones del descenso por el tipo de archivo Filter Action (Acción de filtro) examinan las conexiones basadas en la huella dactilar del archivo, y no apenas de la extensión del nombre de archivo de la tres-carta. Hay algunas razones por las que esta exploración puede no hacer juego en un archivo como se esperaba.

Esta exploración de la huella dactilar será realizada solamente en las conexiones que están bajo tamaño máximo de la exploración como fijan en el scanconfig (del CLI).  Si la conexión es un archivo y el tamaño total del contenido extraído es mayor que el tamaño máximo de la exploración o excede la profundidad máxima de la exploración, la huella dactilar no será comprobada los archivos individuales.  La codificación de un archivo para el transporte del correo electrónico da lugar generalmente a una mayor cantidad de datos entonces cuando el archivo se guarda en el disco.  Cualquiera de estos dos elementos más recientes puede explicar porqué algunas conexiones más pequeñas que el tamaño máximo de la exploración no se están cayendo.

También pudo haber habido un error de la exploración y es posible que el tipo MIME detectado está configurado para ser saltado.  Para descubrir la causa exacta para un mensaje dado, busque los registros del correo usando el grep del CLI.  Cuando usted busca en el MEDIADOS DE, cualquier problema de la exploración será señalado sobre su propia línea.  Aquí tiene un ejemplo:

Tue Aug 3 16:36:29 2004 Warning: MID 256, Message Scanning

Problem: Continuation line seen before first header

También habrá una línea que muestra el tamaño del mensaje total en los bytes, que le darán una idea aproximada de cómo es grande es la conexión codificada

Wed Jun 16 21:42:38 2004 Info: MID 200257070 ready 24663

bytes from <someone@example.com>