Mejorando la seguridad del correo electrónico con Procmail
Configurando el Sanitizer
Documento original en: http://www.juanmaria.com/sanitizer/configurando.rtf

Última revisión 01 de enero de 2006

Nota sobre la traducción:
En este texto se utiliza una nomenclatura muy particular que solo tiene sentido en referencia a éste software. En particular me refiero a tres expresiones, defanging, mangling y poisoning. He estado considerando no traducirlas, pero al final me he decidido por hacerlo.
Defanging literalmente quiere decir eliminar los colmillos, por tanto se refiere a eliminar la parte peligrosa de un mensaje. Me he decidido a utilizar la palabra desarmar al traducir las frases que utilizan dicha expresión.
Mangling se refiere a mutilar o desfigurar, para este texto he escogido ésta última expresión.
Poisoning lo he traducido de forma literal como envenenar.
Algunas palabras técnicas las he dejado en inglés, no soy partidario de traducir palabras como “script” o “relay”.

El propósito principal del Sanitizer es procesar los mensajes entregados en el mismo servidor de correo donde se encuentran los buzones de los usuarios. Esto es llamado entrega local, “local delivery”. En este caso, probablemente, Procmail es el agente de entrega por defecto y añadir el Sanitizer es muy sencillo.
Ejecutar el Sanitizer en un servidor de correo que pase mensajes a otro servidor para su entrega final es llamado “mail relay”. El correo pasando desde distintos dominios en Internet hasta el servidor o servidores de su red local que soporta uno o unos pocos dominios (Ej. desde el gateway público con Sendmail hasta el servidor corporativo con Microsoft Exchange) es llamado “inbound relay”. Cuando el correo se origina en su red local y es enviado hacia diferentes dominios en Internet se le llama “outbound relay”.
Es posible “sanitizar” ambos tipos de relay, inbound y outbound, al igual que el correo que se entrega localmente. Lea las “instructions for configuring filtering on a relay/instrucciones para configurar el filtrado en un relay” para ambos tipos de relay y, además, las “instructions for outbound filtering/instrucciones para el filtrado outbound” para un relay del tipo outbound.
Tenga en cuenta que las instrucciones para el filtrado outbound se refieren al caso de dos servidores. La configuración del Sanitizer para el correo entrante y saliente en un solo servidor está aun en fase de pruebas. (Si alguien tiene montado algo parecido háganmelo saber, por favor)

La operativa del Sanitizer está controlada por variables de entorno y por archivos de políticas. Las variables de entorno deben ser definidas antes de la ejecución del script del Sanitizer. Normalmente esto se hace en /etc/procmailrc, el archivo de configuración global de Procmail.
Todas las prestaciones de Procmail siguen estando disponibles y pueden ser utilizadas para extender y mejorar el comportamiento del Sanitizer.
Este es un ejemplo de un archivo de configuración /etc/procmailrc : 
PATH="/usr/bin:$PATH:/usr/local/bin"
SHELL=/bin/sh
POISONED_EXECUTABLES=/etc/procmail/poisoned
STRIPPED_EXECUTABLES=/etc/procmail/stripped
SECURITY_NOTIFY="postmaster, security-dude"
SECURITY_NOTIFY_VERBOSE="virus-checker"
SECURITY_NOTIFY_SENDER=/etc/procmail/local-email-security-policy.txt
SECRET="CHANGE THIS"
SECURITY_POISON_WINEXE=YES
# Este fichero debe existir y tener los permísos apropiados (rw--w--w-):
SECURITY_QUARANTINE=/var/spool/mail/quarantine
# Alternativamente puede guardar los mensajes en cuarentena por usuario de esta forma:
SECURITY_QUARANTINE=$HOME/quarantine
POISONED_SCORE=25
# Este fichero debe existir y tener los permísos apropiados (rw--w--w-):
SCORE_HISTORY=/var/log/macro-scanner-scores
# Alternativamente, puede usar logs de puntuación de macros por usuario
SCORE_HISTORY=$HOME/macro-scanner-scores
DROPPRIVS=YES
# Este fichero debe existir y tener los permísos apropiados (rw--w--w-):
LOGFILE=$HOME/procmail.log
# Alternativamente, puede usar logs por usuario
:
LOGFILE=$HOME/procmail.log
# Terminada la configuración, ahora a lanzar el sanitizer...
INCLUDERC=/etc/procmail/html-trap.procmail
# Borramos algunas variables para evitar fugas de información hacia
# los usuarios...
POISONED_EXECUTABLES=
SECURITY_NOTIFY=
SECURITY_NOTIFY_VERBOSE=
SECURITY_NOTIFY_SENDER=
SECURITY_QUARANTINE=
SECRET=
Esta es una configuración muy básica. 
Por supuesto, si ya tiene un archivo de configuración /etc/procmailrc tendrá que incorporar en él la configuración de arriba y la llamada INCLUDERC=/etc/procmail/html-trap.procmail junto a lo que ya tiene en dicho archivo. 

Opciones de configuración del Sanitizer 
Las siguientes variables de entorno son reconocidas por el Sanitizer: 
•	MANGLE_EXTENSIONS: Lista de extensiones de nombres de archivos para desfigurar y, posiblemente, envenenar. 
Esta lista de extensiones debe seguir un formato específico. Si no fuese correcto podrían ocurrir cosas indeseables, entre ellas que el Sanitizer entrase en un bucle infinito. El formato de esta string es: 
ext|ext|ext|ex[ts]|etc 
Incluye las extensiones de nombre de archivo, sin el punto, separadas por barras verticales. NO ponga una barra vertical al principio o al final de la lista y NO ponga dos barras verticales juntas sin nada en medio. 
Si desease incluir una lista de extensiones similares, por ejemplo DOC para documentos del Word y DOT para plantillas del Word, puede mezclarlas de la siguiente forma: do[ct] Esto significa "DOC o DOT". 
Tenga en cuenta que la lista MANGLE_EXTENSIONS que introduzca debe estar contenida en una sola línea. 
El Sanitizer desfigurará el nombre de cualquier archivo adjunto cuyo nombre termine en una de esas extensiones. Hay dos razones para hacer esto: 
1.	Se evita que el receptor ejecute un archivo adjunto simplemente haciendo doble clic sobre el. Este tipo de ejecución puede saltarse el control de su antivirus. Si el receptor tiene que guardar en archivo adjunto y cambiarlo de nombre antes de ejecutarlo le estamos dando al antivirus más oportunidades de explorarlo.
2.	Al cambiar el nombre del archivo adjunto dificultamos la tarea de algún script malicioso que esté buscando ese mismo nombre de archivo para ejecutarlo automáticamente.

No es necesario especificar ninguna lista MANGLE_EXTENSIONS. El Sanitizer incluye por defecto una lista con las extensiones de los archivos peligrosos más comunes. Puede sustituir esta lista por defecto por su propia lista personal simplemente definiendo la variable MANGLE_EXTENSIONS con su nueva lista. Tenga en cuenta que lo que indique en su lista personal reemplazará totalmente la lista por defecto. Dicha lista es: 
    MANGLE_EXTENSIONS='html?|exe|com|cmd|bat|pif|sc[rt]|lnk|dll|ocx|do[ct]|xl[swt]|p[po]t|rtf|vb[se]?|hta|p[lm]|sh[bs]|hlp|chm|eml|ws[cfh]|ad[ep]|jse?|md[abew]|ms[ip]|reg|as[dfx]|c[ip]l|pps|wm[avszdf]|vcf|nws|wsz|\{[-0-9a-f]+\}'  
Como puede ver, la lista por defecto de MANGLE_EXTENSIONS es extensiva, por tanto con la instalación por defecto el Sanitizer se comportará de forma bastante paranoica. Si estuviese utilizando el Sanitizer en un entorno de ISP probablemente deseará respetar los documentos de Office y las extensiones .EML, .VCF y .HTML. 
MANGLE_EXTENSIONS puede ser personalizada para obtener diferentes niveles de seguridad o para diferentes propósitos. Por ejemplo, podría desear respetar los documentos de Word o Excel que hayan sido enviadas desde dentro de su dominio pero, en cambio, desfigurar las que vengan de Internet. 
Para hacer esto debería añadir algo como lo siguiente a su archivo de configuración /etc/procmailrc antes de la llamada INCLUDERC=/etc/procmail/html-trap.procmail : 
:0
* ^From:.*<[a-z0-9]+@midominio.com>
* ^To:.*<[a-z0-9]+@midominio.com>
{
    MANGLE_EXTENSIONS='html?|exe|com|cmd|bat|pif|sc[rt]|lnk|dll|ocx|dot|xl[wt]|p[po]t|rtf|vb[se]?|hta|p[lm]|sh[bs]|hlp|chm|eml|ws[cfh]|ad[ep]|jse?|md[abew]|ms[ip]|reg|as[dfx]|c[ip]l|pps|asx|wm[avszdf]|vcf|nws|wsz|\{[-0-9a-f]+\}' }
Tenga en cuenta que "doc" y "xls" no aparecen en esta lista personalizada de MANGLE_EXTENSIONS. 
Este tipo de configuraciones pueden llegar a ser tan complejas como desee, especificando diferentes listas basadas en cualquier número de fuentes o destinos de mensajes o cualquier otro criterio. 
En la versión actual del Sanitizer solo se considerarán para su envenenamiento o eliminación las extensiones de archivo definidas en la lista. La eliminación de una extensión de dicha lista significa que ya no podrá envenenar ni eliminar ningún fichero con esa extensión. 
NOTA: Algunas extensiones son “especiales” y siempre son candidatas a envenenamiento o eliminación sin importar si están en la lista de desfiguración (MANGLE). Los archivos de Microsoft Office (.DOC, .DOT, .XLS, .RTF, etc.) y los archivos comprimidos con formato ZIP o RAR (.ZIP, .RAR) seguirán siendo considerados para su posible envenenamiento o eliminación incluso si no están incluidos en la lista  MANGLE. Nunca añada extensión “ZIP” o “RAR” a la lista MANGLE.
NOTA: Este modelo cambiará  pronto algún día para hacerlo más flexible y fácil de personalizar. Consulte the Future Directions document  para más información. 
NOTA IMPORTANTE: La coincidencia CLSID "\{[-0-9a-f]+\}" NO DEBE ser usada con Sanitizers anteriores a la versión 1.130 – esto provocará el fallo del script. Si quisiera desfigurar/envenenar archivos con nombres CLSID, debe actualizar a la versión 1.130 o superior. 
Hay disponible un preprocesador "opt-out" que simplifica la configuración de MANGLE_EXTENSIONS. Por favor  échele un vistazo si está utilizando el Sanitizer en un entorno ISP o en alguna aplicación donde los usuarios deban ser capaces de escoger su propio nivel de seguridad. Si alguien quisiera crear un interface web para esto estoy seguro que un montón de gente estaría muy agradecida… 

•	POISONED_EXECUTABLES: Nombre del fichero de políticas que contiene las especificaciones de los ficheros a envenenar. 
Esta variable especifica el nombre del fichero que contendrá la lista de archivos adjuntos que consideraremos “envenenados”. Estos nombres podrán contener comodines. Vea la discusión SECURITY_QUARANTINE para saber como son tratados los mensajes infectados. 
Los nombres de ficheros pueden ir seguidos de comentarios. Separe los comentarios de los nombres usando espacios o TABs. Si desea incluir espacios en un nombre de fichero, utilice el símbolo “\s” en lugar del carácter espacio. Para asegurar la compatibilidad con futuras versiones debería comenzar el texto a comentar con el carácter “#” (sintaxis estándar de comentarios de la shell). Vea los ejemplos de más abajo. 
La versión actual del Sanitizer solo utiliza la lista de ficheros envenenados si la extensión del fichero está incluida en la lista MANGLE_EXTENSIONS. Los archivos cuyas extensiones no aparezcan en la lista MANGLE_EXTENSIONS no podrán ser envenenados, a excepción de los ficheros de Microsoft Office, que son "especiales". Vea la discusión de MANGLE_EXTENSIONS. 
El contenido recomendado de este fichero puede ser descargado. Un breve ejemplo: 
*.asd
*.bat
*.chm # Compiled help files - scriptable
*.com
*.dll
*.exe
*.ocx
*.hlp # Help files - scriptable
*.hta
*.js
*.pif # Program Information Files - like shortcuts
*.scr # Screen saver programs
*.shb
*.shs
*.vb
*.vbe
*.vbs # Microsoft Visual BASIC (Beginner's All-purpose Symbolic Infection Code)
*.wsf
*.wsh
IBMls.exe
anti_cih.exe
antivirus.exe
aol4free.com # Trojan horse
avp_updates.exe # Trojan horse
babylonia.exe
badass.exe
buhh.exe
jesus.exe
list.doc
lovers.exe
navidad.exe
navidad[0-9]+.exe
path.xls
photos17.exe
picture.exe
pretty park.exe
prettypark.exe
qi_test.exe
seicho_no_ie.exe
serialz.hlp
setup.exe
story.doc
suppl.doc
surprise!.exe
x-mas.exe
y2kcount.exe
yahoo.exe
zipped_files.exe
A medida que se van anunciando nombres de virus o gusanos, esos nombres pueden ser añadidos a la lista de ficheros envenenados. Si quiere configurar la recepción automática de la lista de ficheros envenenados que mantengo, está en http://www.impsec.org/email-tools/poisoned-files (por favor, utilice su mirror mas cercano.) 
El formato de comodines es el de la sintaxis estándar Regular Expression ligeramente modificado para parecerse más al formato general: un punto se considera un punto explícito y no un símbolo “cualquier carácter”; una interrogación es el símbolo “cualquier carácter” y un asterisco es el símbolo de “cualquier número de caracteres”. Esto lleva a conseguir expresiones familiares como “*.*” y “*.exe”, pero también soporta expresiones mas complicadas "happy[0-9]+.exe" y "*.[a-z][a-z][a-z]". 
La construcción (?...) de Perl se soporta desde la versión 1.131. Vea la lista recomendada de ficheros envenenados para encontrar ejemplos de como esto puede ser utilizado para hacer coincidir todos los nombres excepto aquellos con unas extensiones determinadas. Vea también el manual de expresiones regulares de Perl (man perlex). 
En la lista de ficheros envenenados  no se distingue entre mayúsculas y minúsculas: "IBMLS.EXE" es lo mismo que "ibmls.exe". 
Ejemplo: 
POISONED_EXECUTABLES="/etc/procmail/poisoned" 
NOTA: Este modelo cambiará próximamente para hacerlo mas flexible y fácil de modificar. 

•	STRIPPED_EXECUTABLES: Nombre del fichero de políticas que contiene las especificaciones de los ficheros a eliminar. 
Esta variable especifica el nombre del fichero que contendrá la lista de archivos adjuntos que consideraremos “envenenados”. Estos nombres podrán contener comodines de la misma forma que en la lista de ficheros envenenados. 
Los nombres de ficheros pueden ir seguidos de comentarios. Separe los comentarios de los nombres usando espacios o TABs. Si desea incluir espacios en un nombre de fichero, utilice el símbolo “\s” en lugar del carácter espacio. Para asegurar la compatibilidad con futuras versiones debería comenzar el texto a comentar con el carácter “#” (sintaxis estándar de comentarios de la shell). Vea los ejemplos de más abajo. 
La versión actual del Sanitizer solo utiliza la lista de ficheros a eliminar si la extensión del fichero está incluida en la lista MANGLE_EXTENSIONS. Los archivos cuyas extensiones no aparezcan en la lista MANGLE_EXTENSIONS no podrán ser eliminados, a excepción de los ficheros de Microsoft Office, que son "especiales". Vea la discusión de MANGLE_EXTENSIONS. 
La eliminación se realizará antes del envenenamiento y la eliminación de un archivo adjunto no envenena el mensaje. 
Los archivos adjuntos eliminados son irrecuperables. 
En la lista de ficheros a eliminar  no se distingue entre mayúsculas y minúsculas: "IBMLS.EXE" es lo mismo que "ibmls.exe". 
Ejemplo: 
STRIPPED_EXECUTABLES="/etc/procmail/stripped" 

•	SECURITY_POISON_WINEXE: Busca strings mágicas de Windows y las envenena si las encuentra. 
Algunas herramientas de Windows cuando se encuentran con un archivo cuyo nombre o tipo MIME no refleja con exactitud el tipo real del archivo (p.ej. un archivo llamado "ALGO.WAV" – cuyo nombre implica que es un archivo de sonido – que es realmente un programa ejecutable) buscarán en el fichero unas “strings mágicas” para identificar el tipo de archivo y lo ejecutarán si se tratase de un programa. 
El Sanitizer incorpora un buscador simple de strings mágicas de ejecutables Windows que puede ser activado como una capa más de seguridad. Si los archivos adjuntos de un mensaje no fuesen envenenados por las extensiones de sus nombres pueden ser analizados para ver si contienen strings mágicas de ejecutables Windows y envenenarlos si contuviesen alguna. Este analizador se activa definiendo SECURITY_POISON_WINEXE con cualquier valor. 
Tenga en cuenta que si estuviese permitiendo el envío de archivos ejecutables para ciertos remitentes también debería desasignar SECURITY_POISON_WINEXE para esos mismos remitentes. 
Ejemplo: 
SECURITY_POISON_WINEXE=YES

:0
* ^From: trusted@partner.example.com
{
    POISONED_EXECUTABLES=/etc/procmail/poison-list-for-trusted-senders
    SECURITY_POISON_WINEXE=
}

•	DISABLE_MACRO_CHECK: Deshabilita la búsqueda de macros peligrosas en los archivos adjuntos de Microsoft Office. 
El Sanitizer contiene un explorador rudimentario que chequea los archivos adjuntos de Microsoft Office  (documentos de Word, hojas de cálculo de Excel, presentaciones de PowerPoint, etc.) y busca macros VBA incrustadas que puedan realizar alguna acción discutible – por ejemplo, modificar parámetros de seguridad, hacer cambios en el registro, o escribir macros en la plantilla de documentos estándar. 
Aunque las extensiones de los documentos no aparezcan en la lista MANGLE_EXTENSIONS todos los archivos adjuntos de Office serán procesados. Esto significa que puede eliminar las extensiones .DOC y .XLS de la lista MANGLE_EXTENSIONS para hacer felices a los usuarios y, al mismo tiempo, seguir protegido contra los ataques basados en macros.  
Si no desea que se realice el chequeo de las macros, defina DISABLE_MACRO_CHECK con cualquier valor. También puede utilizar la versión sin explorador de macros del Sanitizer. Esto último puede ser ligeramente más rápido ya que evitaremos la compilación de esa parte del código al procesar cada mensaje. 
Para poder chequear las macros de los documentos adjuntos necesitará instalar dos utilidades más: 
1.	mimencode, que forma parte del paquete metamail. (vea USE_CPAN más adelante) 
2.	mktemp, de OpenBSD software archives. (vea USE_CPAN más adelante) 
Ambas utilidades se suministran con la mayoría de las distribuciones Linux. Con otros sistemas operativos tendrá que descargar el código fuente y compilarlo. 
Aparentemente muchos antivirus comerciales no eliminan las macros maliciosas si no que las desfiguran lo suficiente como para inhabilitarlas y las dejan en su sitio. Es muy posible que el Sanitizer detecte suficientes fragmentos peligrosos como para considerar el documento como infectado. Si ocurriese esto, sugiera al remitente del mensaje que envíe el documento en un formato que no permita macros, como por ejemplo Rich Text (RTF). Alternativamente, el remitente puede comprimir el documento utilizando Winzip o gzip o cualquier otro compresor. El antivirus del destinatario tendrá una oportunidad de chequear el documento cuando éste sea descomprimido. 
Agradecería sugerencias de elementos a considerar peligrosos dentro de una macro así como muestras de documentos infectados por macros. 
Ejemplo: 
DISABLE_MACRO_CHECK=YES 

•	POISONED_SCORE: Puntuación del explorador de macros a partir de la cual consideraremos envenenado el documento. 
La cuenta de puntos que mantiene el explorador se incrementará en una cantidad variable por cada fragmento sospechoso de código de macro. Cuando la exploración haya terminado el documento se considerará envenenado si la puntuación obtenida superase POISONED_SCORE. 
El valor mínimo de POISONED_SCORE es 5, lo cual es muy bajo. El valor por defecto es 25. La mayoría de los virus de macro generan un valor de 100 o más. 
Ejemplo: 
POISONED_SCORE=25 

•	SCORE_HISTORY: Donde se guardarán los logs de las puntuaciones explorador de macros. 
Si desease mantener un histórico de las puntuaciones obtenidas por las distintas macros para comprobar si ha definido POISONED_SCORE con unos valores razonables, defina SCORE_HISTORY con el nombre de un fichero. La puntuación de cada documento procesado será guardada en dicho fichero. 
Éste fichero ha de existir con los permisos rw--w--w- de tal forma que todos los usuarios puedan registrar sus puntuaciones. El Sanitizer baja los privilegios antes de explorar un mensaje, por tanto el fichero de log ha de tener permisos universales. 
Ejemplo: 
SCORE_HISTORY="/var/spool/mail/macro-scanner-scores" 

•	SCORE_DETAILS: ¿Cómo fueron calculadas las puntuaciones del explorador de macros? 
Si quisiese saber como fueron calculadas las puntuaciones del explorador de macros, defina SCORE_DETAILS con cualquier valor. Los detalles de cada parte de la puntuación se guardarán en el mensaje. Si pone en cuarentena los mensajes envenenados tendrá que mirar en el buzón de cuarentena. 
Ejemplo: 
SCORE_DETAILS=YES 

•	SCORE_ONLY: Explorar solo para puntuar, no envenenar basándose en la puntuación. 
Si desease explorar y registrar las puntuaciones, pero no envenenar los mensajes, defina SCORE_ONLY con cualquier valor. 
No recomendamos esta práctica ya que dejará pasar los gusanos y virus de macro. En su lugar, defina POISONED_SCORE con un valor alto (de 75 a 100), que atrapará los documentos con infecciones obvias y le dejará valorar los documentos que se encuentren en el límite. 
Ejemplo: 
SCORE_ONLY=YES 

•	SECURITY_OFFICE_EMBED_SCORE: Puntuación a asignar a los archivos y URLs incrustadas 
Los archivos de Microsoft Office  (documentos de Word y hojas de cálculo de Excel) pueden incluir referencias a archivos externos y a URLs. Algunas referencias ocultas a archivos externos podrían ser usadas para robar archivos de su ordenador., y algunas referencias a URLs pueden ser utilizadas como si de un microtransmisor espía se tratase para trazar la localización de quien abre el archivo. 
El explorador de macros busca archivos y URLs incrustados y les asigna una puntuación. Dicha puntuación es de 99 por defecto, lo cual es suficiente en la mayoría de los casos para envenenar el documento. Si Vd. desease reducir el nivel de paranoia del explorador, asigne a SECURITY_OFFICE_EMBED_SCORE un valor menor de 99. 
Ejemplo: 
SECURITY_OFFICE_EMBED_SCORE=20 

•	SECURITY_QUARANTINE: Donde se guardarán los documentos envenenados. 
Esta variable de entorno especifica un fichero en el gateway de correo. Si un mensaje tuviese archivos adjuntos envenenados (tanto si son envenenados por la exploración de macros como por el nombre del archivo adjunto), dicho mensaje será entregado en el fichero definido en esta variable en lugar de al destinatario del mismo. 
Al utilizar la cuarentena de mensajes evitamos la entrega de mensajes con archivos adjuntos envenenados al destinatario al que iban dirigidos. Este es el único caso en el cual el Sanitizer actúa como una “receta de entrega” - en todos los demás casos actúa, simplemente, como un filtro. 
Como el Sanitizer baja todos los privilegios antes de explorar un mensaje, éste fichero debe de existir (el Sanitizer no puede crearlo sobre la marcha con fiabilidad) y debe tener los permisos rw--w--w-. 
Este fichero es un buzón estándar Berkeley-format y puede ser manipulado utilizando cualquier programa de correo de Unix, o editado con un editor de textos, para recuperar mensajes desfigurados o en cuarentena. 
Si prefiriese ver los mensajes en cuarentena como un mensaje por fichero defina la variable SECURITY_QUARANTINE para que apunte a un directorio en lugar de a un fichero. El directorio ha de existir y debe tener permisos rwx-wx-wx. 
Si no se hubiese definido SECURITY_QUARANTINE los mensajes se entregarán a los destinatarios a los que iban dirigidos aunque contengan archivos adjuntos peligrosos. Esto no parece una buena idea a no ser que Vd. sea un ISP. 
Ejemplo: 
SECURITY_QUARANTINE=/var/spool/mail/quarantine 

•	SECURITY_QUARANTINE_OPTIONAL: Si la puesta en cuarentena de un mensaje fallase, que no rebote. 
Si por alguna razón fallase la puesta en cuarentena de un mensaje envenenado, el mensaje rebotará y la lista SECURITY_NOTIFY será notificada del fallo. 
Si fallase la puesta en cuarentena de un mensaje envenenado y SECURITY_QUARANTINE_OPTIONAL estuviese definido con cualquier valor, el mensaje será entregado al destinatario en lugar de rebotar. 
Ejemplo: 
SECURITY_QUARANTINE_OPTIONAL=YES 

•	SECURITY_QUARANTINE_LOCKFILE: Cuando se esté escribiendo un mensaje en cuarentena utilizar un archivo de bloqueo diferente al archivo por defecto. 
Si por alguna razón el fichero de bloqueo por defecto de cuarentena no pudiera ser creado (p. Ej. que los usuarios normales no tengan permiso de escritura en el directorio) y aparecen avisos como "Lock failure on /var/spool/mail/security.lock" en el archivo de log de procmail, puede especificar un fichero de bloqueo en un directorio con permisos universales definiéndolo en SECURITY_QUARANTINE_LOCKFILE. 
Ejemplo: 
SECURITY_QUARANTINE_LOCKFILE="/var/tmp/quarantine.lock" 

•	SECURITY_NOTIFY: A quien se notifica cuando se detecta un ataque. 
Esta variable de entorno contiene una lista separada por comas con las direcciones de email a las cuales se les enviará una breve notificación cuando se capture un mensaje envenenado. 
La notificación incluirá las cabeceras del mensaje capturado. 
Asegúrese de usar comillas si pone espacios en la lista de nombres. 
La lista SECURITY_NOTIFY es notificada también cuando falla la puesta en cuarentena de un mensaje envenenado. 
Ejemplo: 
SECURITY_NOTIFY="postmaster, dilbert@ejemplo.com" 

•	SECURITY_NOTIFY_VERBOSE: A quien se notifica cuando se detecta un ataque. 
SECURITY_NOTIFY_VERBOSE es igual que SECURITY_NOTIFY, con la excepción de que se incluirá íntegramente en la notificación el mensaje envenenado y no solo las cabeceras. 
Esto podría ser utilizado en lugar de un archivo de cuarentena pero el formato no es tan cómodo. 
Ejemplo: 
SECURITY_NOTIFY_VERBOSE="wally@ejemplo.com, phb@ejemplo.com" 

•	SECURITY_NOTIFY_SENDER: ¿Debería ser notificado el remitente del mensaje atacante? 
Si se definiese SECURITY_NOTIFY_SENDER con cualquier valor, se enviará un mensaje de aviso a la persona que originó el mensaje envenenado. Para que esto sea así también debe estar definida SECURITY_NOTIFY. 
Si desease definir un mensaje de aviso personalizado en lugar del incluido en el Sanitizer, defina SECURITY_NOTIFY_SENDER con el nombre del fichero que contiene el texto del su mensaje de aviso personalizado. En él podría explicar la política de seguridad de su sistema y dar una dirección de contacto para resolver cualquier duda. 
Como el Sanitizer espera encontrar un nombre de fichero en SECURITY_NOTIFY_SENDER, hay que tener un cuidado especial con esta variable. Si quiere notificar al remitente pero no desea personalizar el mensaje, asegúrese que cualquiera que sea el valor que defina en SECURITY_NOTIFY_SENDER no represente un fichero existente en el sistema. 
"SECURITY_NOTIFY_SENDER=YES" está bien. "SECURITY_NOTIFY_SENDER=/etc/passwd" sería una mala elección. 
Si desease suprimir la notificación al remitente de forma expresa, defina SECURITY_NOTIFY_SENDER con la cadena vacía: 
SECURITY_NOTIFY_SENDER="" 
Estando habilitada la opción “Smart Reply Suppression” y con la información apropiada en SECURITY_TRUSTED_MTAS debería ser seguro habilitar esta opción sin generar demasiados mensajes falsos a causa de las direcciones de retorno falsificadas. No obstante asegúrese que está utilizando al menos la versión 1.140 del Sanitizer. 

Ejemplo: 
SECURITY_NOTIFY_SENDER=YES 
SECURITY_NOTIFY_SENDER="/etc/procmail/policy-note.txt" 

Aquí tiene un ejemplo de mensaje de notificación al remitente  que Vd. Puede usar o modificar como necesite. 

•	SECURITY_NOTIFY_SENDER_POSTMASTER: ¿Debería ser notificado el  postmaster del dominio del remitente? 
Si SECURITY_NOTIFY_SENDER_POSTMASTER se define con cualquier valor, también se notificará al postmaster del dominio del remitente. Esto puede ser práctico si los mensajes proceden de una empresa pero posiblemente no tenga sentido si el mensaje proviene de un gran proveedor de servicios como MSN, Terra o AT&T. 
Ejemplo: 
SECURITY_NOTIFY_SENDER_POSTMASTER=YES 

•	SECURITY_NOTIFY_SENDER_ABUSE: ¿Debería ser notificado abuse@ en el dominio del remitente? 
Si SECURITY_NOTIFY_SENDER_POSTMASTER y SECURITY_NOTIFY_SENDER_ABUSE son definidos con cualquier valor también se notificará al postmaster y a abuse@ del dominio del remitente. Esto puede ser práctico si los mensajes proceden de una empresa pero posiblemente no tenga sentido si el mensaje proviene de un gran proveedor de servicios como MSN, Terra o AT&T. Tenga en cuenta que  SECURITY_NOTIFY_SENDER_ABUSE necesita que SECURITY_NOTIFY_SENDER_POSTMASTER sea definida. 
Ejemplo: 
SECURITY_NOTIFY_SENDER_ABUSE=YES 

•	SECURITY_DISABLE_SMART_REPLY: ¿Debería ser deshabilitada la respuesta inteligente? 
Muchos mensajes atacantes falsifican la dirección del remitente para oscurecer el origen del ataque y hacer más dificultosa la limpieza de los equipos infectados. Enviar una notificación alguien que no tenga nada que ver con el ataque no ayuda a nada y, de hecho, incrementa la carga de la red generada por el gusano. 
Para reducir la probabilidad de enviar una notificación a una dirección falsificada o inapropiada, la dirección del remitente es comparada con la lista de dominios en la cadena Received de la cabecera. Si no se encuentra justificación de la dirección del remitente dentro de esta cadena o si el mensaje viene de una lista de correo se suprimirá la notificación al remitente.  
Además, si parece que el mensaje proviene de una lísta de correo, también se suprimirá la notificación.
Si desease notificar al remitente sin importar si la dirección del mismo parece correcta o si proviene de una lista de correo, defina SECURITY_DISABLE_SMART_REPLY con cualquier valor. No se recomienda hacer esto ya que los gusanos suelen falsificar las direcciones de retorno y con nuestras respuestas podríamos alertar a personas que no tienen nada que ver con el mensaje.
Ejemplo: 
SECURITY_DISABLE_SMART_REPLY=YES 

•	SECURITY_TRUSTED_MTAS: ¿En que cabeceras ‘Received:’ se basará la Respuesta Inteligente? (1.140+) 
Muchos mensajes atacantes falsifican la cabecera ‘Received:’ para ocultar el origen del ataque. Las únicas cabeceras ‘Received:’ en las que puede confiar son aquellas que hayan sido insertadas por las MTAs bajo su control, o bajo el control de aquellos en los que confía (como su IPS). 
La lista SECURITY_TRUSTED_MTAS incluye aquellas MTAs en las que se confía que las cabeceras ‘Received:’ sean correctas. Si no se selecciona nada se toma por defecto el sistema en el que el Sanitizer está ejecutándose. Si el MTA que recibe su email desde Internet fuese un sistema diferente (p.ej. un host de defensa o un servidor de correo de un ISP), incluya el nombre de dicho sistema en la lista SECURITY_TRUSTED_MTAS. 
Mire en sus cabeceras ‘Received:’ para determinar el/los nombre/s a incluir en dicha variable. Por ejemplo, si sus cabeceras ‘Received:’ fuesen estas (ejemplo tomado de un mensaje atacante de un gusano): 
Received: from localhost (IDENT:root@localhost [127.0.0.1])
	by gypsy.impsec.org (8.9.3/8.8.8) with ESMTP id NAA04022
	for ; Mon, 26 Jan 2004 13:21:35 -0800
Received: from localhost
	by localhost with POP3 (fetchmail-5.2.4)
	for jhardin@localhost (single-drop); Mon, 26 Jan 2004 13:21:35 -0800 (PST)
Received: from sylmic.com (rtss13.ssss.gouv.qc.ca [199.243.239.13])
	by hq.impsec.org (8.11.6/8.9.3) with ESMTP id i0QLKq827621
	for ; Mon, 26 Jan 2004 13:20:54 -0800
...debería incluir "hq.impsec.org" en su variable SECURITY_TRUSTED_MTAS. Ese es el sistema de confianza más próximo a Internet. (Observe como el nombre de dominio HELO y el nombre proporcionado por la resolución inversa en la cabecera ‘Received:’ hq.impsec.org no coinciden. Este mensaje parece ser una falsificación y no será respondido.) 
Notas sobre el formato: 
1.	Use la barra invertida como carácter de escape  en los puntos del nombre del host: \. 
2.	Separe los diferentes nombres de host con barras verticales: | 
3.	No incluya espacios en blanco. 
4.	La línea no debe comenzar ni finalizar con una barra vertical. 
No es necesario configurar esta variable si el Sanitizer está ejecutándose en al MTA que recibe el correo directamente de Internet. El Sanitizer por defecto confía en el sistema en el que se está ejecutando. 
Ejemplo: 
SECURITY_TRUSTED_MTAS="hq\.impsec\.org|mail\.myisp\.com" 

•	SECURITY_LOCAL_POSTMASTER: Se utiliza en lugar de la dirección "from" en los mensajes de notificación. 
Por defecto, los mensajes de notificación son de "postmaster". El Sanitizer deja fuera el dominio porque asume que el MTA local añadirá el dominio local cuando procese los mensajes de notificación. 
Si desease saltarse esa dirección de remite por defecto, por ejemplo para que los mensajes vengan de "abuse@sudominio.com" en lugar de  "postmaster@sudominio.com" o para indicar explícitamente un nombre de dominio, defina SECURITY_LOCAL_POSTMASTER con la dirección “from” deseada. No se requiere indicar un nombre de dominio ya que este será añadido por el MTA si fuese omitido. 
Por favor, no especifique un nombre de dominio del que no sea responsable. 
Ejemplo: 
SECURITY_LOCAL_POSTMASTER="abuse"
SECURITY_LOCAL_POSTMASTER="postmaster@bighostingcompany.com" 

•	SECURITY_NOTIFY_RECIPIENT: ¿Debería ser notificado el destinatario del mensaje atacante? 
Si desease notificar al destinatario de un mensaje que éste fue envenenado o puesto en cuarentena, defina SECURITY_NOTIFY_RECIPIENT con cualquier valor. Dicho valor también puede ser el nombre de un fichero en la misma forma que con SECURITY_NOTIFY_SENDER. 
SECURITY_NOTIFY_RECIPIENT no ha sido probado bien en un  “sanitizing relay”, por tanto si la máquina donde se encuentra el Sanitizer es un relay (no entrega el correo localmente), no debería utilizar SECURITY_NOTIFY_RECIPIENT. 
Ejemplo: 
SECURITY_NOTIFY_RECIPIENT="/etc/procmail/quarantined.txt" 

•	SECURITY_STRIP_MSTNEF: Elimina los archivos adjuntos MS-TNEF completamente. 
Microsoft Outlook y Microsoft Exchange soportan el envío de correo utilizando un formato llamado "Outlook Rich Text". Entre otras cosas este formato empaqueta los archivos adjuntos y otros datos en un formato de fichero adjunto propietario de Microsoft, normalmente con el nombre "WINMAIL.DAT". Este formato es llamado "MS-TNEF", y generalmente no puede ser interpretado por programas de correo ajenos a Microsoft. 
Los archivos adjuntos en formato MS-TNEF no pueden ser explorados ni saneados y pueden incluir contenidos peligrosos que el Sanitizer no podrá detectar o desfigurar. También se incluye información del ordenador del remitente en el archivo "WINMAIL.DAT" lo cual puede filtrar información privada del usuario. 
Microsoft recomienda que solo se utilice este formato dentro de la propia compañía y no para el correo de Internet. 
Si define SECURITY_STRIP_MSTNEF con cualquier valor, estos archivos adjuntos serán eliminados del mensaje y el resto del mensaje será entregado al destinatario con una nota explicativa. El mensaje no será envenenado. Los archivos adjuntos no son recuperables. 
Vea http://support.microsoft.com/support/kb/articles/Q241/5/38.ASP, http://support.microsoft.com/support/kb/articles/Q138/0/53.ASP y http://www.microsoft.com/TechNet/exchange/2505ch10.asp para más información.
Ejemplo: 
SECURITY_STRIP_MSTNEF=YES 

•	STRIPPED_WARNING: Texto a incluir cuando los archivos adjuntos (excepto MS-TNEF) son eliminados 
La eliminación de archivos adjuntos no envenena el mensaje, por tanto el destinatario seguirá recibiendo el mismo. Esta variable contiene la nota de aviso que se insertará en el mensaje en lugar del archivo adjunto eliminado y puede ser definida para utilizar otros idiomas o para dar información sobre su política de seguridad. 
Ejemplo: 
STRIPPED_WARNING="
¡AVISO DE SEGURIDAD!

Archivo eliminado del mensaje y desechado.
Si desea seguir recibiendo archivos adjuntos lleve donuts a su postmaster ahora mismo.
"

•	POISONED_WARNING: Texto a incluir cuando los archivos adjuntos son envenenados
Si no está poniendo en cuarentena los archivos envenenados, el receptor recibirá el mensaje con el archivo adjunto desfigurado. El texto descriptivo que por defecto aparece antes del archivo adjunto desfigurado puede ser cambiado para utilizar otros idiomas, para dar información sobre su política de seguridad o para informar al usuario sobre como reaccionar ante un archivo desfigurado. 
Ejemplo: 
POISONED_WARNING="
¡AVISO DE SEGURIDAD!

¡Alguien le está atacando!
¡Corra en círculos! ¡Grite y chille!
"

•	TNEF_WARNING: Texto a incluir cuando los archivos adjuntos de tipo MS-TNEF son eliminados
Si está eliminando los archivos adjuntos de tipo MS-TNEF el destinatario recibirá una nota advirtiéndole que el archivo ha sido eliminado. Esta variable contiene la nota de aviso que se insertará en el mensaje en lugar del archivo adjunto eliminado y puede ser definida para utilizar otros idiomas o para dar información sobre su política de seguridad.

Ejemplo: 
TNEF_WARNING="
¡AVISO DE SEGURIDAD!

TNEF es la semilla del Diablo.
"

•	SECURITY_DEFANG_SIGNED: Desarmar mensajes firmados 
Algunos mensajes pueden ser firmados criptográficamente para detectar posibles alteraciones. El Sanitizer no tiene medios para poder firmar de nuevo un mensaje, por tanto para evitar avisos de firmas erróneas no intentará desarmar el contenido de de los mensajes firmados. 
Si está dispuesto a aceptar avisos de chequeos de firma erróneos con tal de mejorar la seguridad puede indicar al Sanitizer que desarme también los mensajes firmados. 
Ejemplo: 
SECURITY_DEFANG_SIGNED=Y 

•	SECURITY_TRUST_HTML: Confiar en el código HTML de los mensajes 
Deshabilita el proceso de seguridad del contenido HTML. No se desarmarán los scripts ni los web bugs ni las style tags. 
Ejemplo: 
SECURITY_TRUST_HTML=Y 

•	DEFANG_WEBBUGS: Deshabilitar las imágenes y sonidos inline. 
"Web bugs" son pequeñas imágenes (normalmente de un solo píxel) que son utilizadas para seguir la pista de un mensaje de email. En la URL de la imagen se incluye información identificativa y cuando un programa de mail con HTML habilitado intenta visualizar el mensaje, la localización del mismo puede ser averiguada (ya que el cliente de correo intentará obtener la imagen del servidor web indicado en la URL del webbug) y registrada. 
Una utilización común de esta técnica es para determinar si un mensaje de SPAM ha llegado a una persona real, de esta forma las direcciones de email podrán ser validadas para que el spammer las pueda seguir usando. Otra es seguir la pista de la propagación de un mensaje a medida que va siendo reenviado de una a otra persona. 
Lo mismo puede ser conseguido utilizando archivos de sonido de fondo y a través de enlaces de imagen incrustados en documentos de Microsoft Office. 
Si Vd. Considera esto como una violación de su privacidad, puede definir DEFANG_WEBBUGS con cualquier valor y el Sanitizer desarmará todos los tags <IMAGE> y <BGSOUND> para evitar esto. Vd. Puede seguir obteniendo la URL del cuerpo del mensaje y decidir si desea ver la imagen u oír el sonido. 
Desafortunadamente esto no eliminará los webbugs de los documentos de Office. En un futuro el Sanitizer podría incluir esta función. 
Ejemplo: 
DEFANG_WEBBUGS=YES 

•	SECURITY_TRUST_STYLE_TAGS: Deshabilita el desarmado de las style tags. 
Las tags <STYLE> permiten al autor un control fino de la apariencia del contenido HTML cuando es visualizado. Son ampliamente utilizadas por los programas de correo con HTML habilitado, pero pueden ser una posible fuente de ataques mediante la inclusión de scripts en el lugar de definiciones de apariencia. 
Por defecto el Sanitizer desarma las tags <STYLE>, pero esto puede podría dejar tags de fin de comentario ("-->") visibles en el cuerpo del mensaje. Podría ser que le interesase confiar en los tags <STYLE> de los mensajes generados localmente y seguir desarmando las que vienen de Internet. 
No se recomienda confiar en las tags <STYLE> de los emails recibidos de Internet. 
Ejemplo: 
:0
* ^From:.*@midominio.com>
* ^To:.*@midominio.com>
{
    SECURITY_TRUST_STYLE_TAGS=YES
}

•	SECURITY_NONOTIFY_LONGSUBJECT: No notificar sobre asuntos excesivamente largos 
Si no le importa cuando alguien le envía un correo con un asunto excesivamente largo defina ésta variable con cualquier valor. La cabecera Subject seguirá siendo truncada pero no se producirán notificaciones. 
Ejemplo: 
SECURITY_NONOTIFY_LONGSUBJECT=Y 

•	SECRET: Una cadena corta (unos 20 caracteres o así) elegida al azar. 
Esta es una cadena corta de texto elegida al azar (letras y números, evite signos de puntuación) que es utilizada en un par de sitios para dificultar que un mensaje falso pueda colarse por ciertas partes del Sanitizer. 
Cuando instale el Sanitizer defina la variable SECRET con algún galimatías aleatorio y cámbielo de vez en cuando. 
Esta no es una función crítica. 
Ejemplo: 
SECRET="hgsfd9734965q34o2ldgbl" 

•	LOGFILE: Donde se guardarán los mensajes de log del Sanitizer. 
Una vez mas, como el Sanitizer baja los privilegios antes de explorar los mensajes, este fichero ha de ser escribible por el receptor del mensaje, se define típicamente como "$HOME/procmail.log" (lo que lo coloca en el directorio de inicio del destinatario), pero también se puede definir un fichero de log centralizado donde irán los logs de todos los usuarios. Para hacer eso asegúrese que el fichero existe y que los permisos son rw--w--w-. 
Si coloca el fichero de log en el directorio de inicio del usuario, incluya  DROPPRIVS=YES antes de la línea LOGFILE= ya que procmail abre el fichero de log en cuanto se le indica el destino del mismo, y si tuviese que ser creado  debería hacerse con los permisos del usuario. 
Ejemplo: 
DROPPRIVS=YES
LOGFILE="$HOME/procmail.log" 

•	DEBUG: Habilita la salida de alguna información de depuración del Sanitizer. 
Ejemplo: 
DEBUG=YES 

•	DEBUG_VERBOSE: Habilita el modo de depuración del Sanitizer. 
Esto es equivalente a indicar "VERBOSE=YES" en /etc/procmailrc. Como la bajada de privilegios reinicializa el modo de depuración de procmail es necesario definir DEBUG_VERBOSE con cualquier valor para indicar al Sanitizer que reconecte el depurador después de bajar los privilegios. 
Ejemplo: 
DEBUG_VERBOSE=YES 

•	POISONED_WARNING: Cambia el texto de aviso por defecto para los “mensajes envenenados”
Cuando el Sanitizer envenena un archivo adjunto, dicho archivo es desfigurado para dificultar la utilización del mismo por parte del destinatario. También se inserta un mensaje de aviso. Si Vd. Define POISONED_WARNING con una cadena multilínea separada por comillas, ésta reemplazará el texto por defecto que es: 
SECURITY WARNING! 
The mail system has detected that the following attachment may contain hazardous program code, is a suspicious file type, or has a suspicious file name. Do not trust it. Contact your system administrator immediately. 
Puede utilizar esta opción para personalizar el mensaje de contacto, para apuntar a un documento que describa como des-desfigurar los ajuntos o para traducir el aviso a otro idioma. 
Ejemplo: 
POISONED_WARNING="
¡AAAG! ¡Ha sido detectado un gusano pegajoso de Microsoft Outlook! ¡Apague su ordenador AHORA MISMO!" 

•	TNEF_WARNING: Cambia el texto de aviso por defecto para los archivos adjuntos MS-TNEF eliminados.
Cuando el Sanitizer elimina un archivo adjunto MS-TNEF, dicho archivo es reemplazado por un mensaje de aviso. Si Vd. Define TNEF_WARNING con una cadena multilínea separada por comillas, ésta reemplazará el texto por defecto que es: 
SECURITY NOTICE: 
The mail system has removed a Microsoft attachment for security reasons. The sender should disable sending Rich Text format in Outlook and disable sending TNEF to the Internet from their Microsoft Exchange gateway. 
See http://support.microsoft.com/support/kb/articles/Q241/5/38.ASP and http://www.microsoft.com/TechNet/exchange/2505ch10.asp for more information. 
Ejemplo: 
TNEF_WARNING="
MS-TNEF es la semilla del diablo." 

•	MTA_FLAGS_CMDLN: Define los flags de la línea de comando del MTA para el modo "obtención de direcciones desde la línea de comando".
El Sanitizer ha sido diseñado y probado con una versión antigua de Sendmail haciendo de MTA. Si está usando una versión más moderna de Sendmail o un MTA diferente es posible que tenga que ajustar las opciones pasadas en la línea de comandos al programa de envío de correo que el Sanitizer utilice para sus mensajes de notificación. 
El Sanitizer genera dos tipos de mensajes: aquellos en los que los destinatarios son explícitamente especificados en la línea de comandos y aquellos otros en los cuales los destinatarios han de ser obtenidos de las cabeceras del mensaje que está siendo enviado. Las opciones de línea de comandos para estos dos modos pueden ser diferentes. 
Para cambiar las opciones de línea de comandos utilizadas para enviar un mensaje con las direcciones de los destinatarios obtenidas de la línea de comandos del programa de correo defina MTA_FLAGS_CMDLN con los valores apropiados para su MTA. Para especificar "sin opciones", utilice una cadena vacía " " en lugar de una cadena nula "". 
Ejemplo: 
MTA_FLAGS_CMDLN="-U"
MTA_FLAGS_CMDLN=" " (no se necesitan opciones) 

•	MTA_FLAGS_HDRS: Define los flags de la línea de comando del MTA para el modo "obtención de direcciones desde el mensaje". 
Para cambiar las opciones de línea de comandos utilizadas para enviar un mensaje con las direcciones de los destinatarios obtenidas de las cabeceras del mensaje que está siendo enviado  la línea de comandos del programa de correo defina MTA_FLAGS_HDRS con los valores apropiados para su MTA. 
Tenga en cuenta que todo esto solo se utiliza cuando se genera un mensaje de notificación al remitente. Si quisiera especificar explícitamente la dirección “from” del sobre y necesitase una opción de línea de comando para hacerlo incluya esta opción aquí. 
Ejemplo: 
MTA_FLAGS_HDRS="-oi -t -f$SECURITY_LOCAL_POSTMASTER" 

•	SECURITY_MSGID_LOG: Registra en el log los ID de los mensajes envenenados. 

Si desea mantener un log de los Message-ID de los mensajes envenenados defina SECURITY_MSGID_LOG de tal forma que apunte a un archivo con permisos de escritura universales. 

Esto puede ser práctico para cosas en las que no quiera estar indagando a través de los ficheros de cuarentena o de log para ver que está pasando. Por ejemplo, le podría interesar hacer un "wc -l" a este fichero cada cinco minutos para que MRTG le generase un gráfico del tráfico de mensajes envenenados. 

Ejemplo: 

SECURITY_MSGID_LOG="/var/log/poisoned.log" 

•	ZIPPED_EXECUTABLES: Nombre del fichero de políticas que contendrá las especificaciones de los ficheros comprimidos en formato ZIP o RAR que se pondrán en cuarentena. (1.141+) 
Esta variable especifica el nombre de un fichero que contendrá una lista de nombres de fichero que se considerarán “envenenados” siempre que aparezcan dentro de un archivo adjunto de tipo ZIP o RAR. Vea en el apartado POISONED_EXECUTABLES la sintaxis de los comodines. Vea como se tratan los mensajes envenenados en el tema SECURITY_QUARANTINE.
Los archivos ZIP o RAR que contengan ficheros envenenados solamente podrán ser puestos en cuarentena. No se eliminarán los adjuntos tipo ZIP o RAR basándose en su contenido, pero ahora los archivos ZIP y RAR son “especiales” de la misma forma que lo son los de Microsoft Office – puede envenenar o eliminar el archivo ZIP o RAR entero basándose en su nombre (el nombre del archivo adjunto, no los nombres de los ficheros contenidos dentro de él). Esto significa que si pone “*.zip” en sus ficheros POISONED_EXECUTABLES o STRIPPED_EXECUTABLES no recibirá ningún archivo adjunto de tipo ZIP.
Solo se explora el primer nivel en los archivos adjuntos comprimidos, la exploración no es recursiva.
La cláusula MANGLE_EXTENSIONS NO SE APLICA al contenido de los archivos comprimidos – puede incluir cualquier especificación en la lista ZIPPED_EXECUTABLES. 
Si no se definiese ZIPPED_EXECUTABLES, se tomará por defecto el mismo valor de POISONED_EXECUTABLES (de esta forma se proporciona una configuración por defecto segura en lugar de una insegura). 
Se recomienda encarecidamente que se configure una política ZIPPED_EXECUTABLES separada y que se añadan, al menos, las extensiones "*.html?", "*.eml" y "*.msg" a ella. Hay gusanos que se basan en múltiples capas de ofuscación: un archivo adjunto comprimido que contiene una página HTML que, a su vez, contiene un archivo .EXE codificado en base-64 y el mensaje original contendría un HTML activo que abriría automáticamente el archivo .ZIP.
Pueden descargarse los contenidos recomendados para este fichero.
Si desea explorar los archivos adjuntos tipo ZIP y RAR, necesitará instalar cuatro  utilidades extra: 
1.	mimencode, que es parte del paquete metamail. (vea USE_CPAN más adelante) 
2.	mktemp, de OpenBSD software archives. (vea USE_CPAN más adelante) 
3.	unzip.
4.	unrar.  
Todas estas herramientas, excepto unrar, se incluyen en la mayor parte de las distribuciones Linux. Para otros sistemas operativos será necesario descargar los fuentes y compilarlos. 
Si quisiera aceptar ejecutables comprimidos procedentes de fuentes conocidas (p.ej. ficheros .DLL de un consultor) entonces debería crear una lista aparte que no incluya "*.dll" y utilizarla en ZIPPED_EXECUTABLES si el mensaje proviniese de dichas fuentes. 
Ejemplo: 
ZIPPED_EXECUTABLES=/etc/procmail/zipped_poison

:0
* ^From: trusted@partner.example.com
{
     ZIPPED_EXECUTABLES=/etc/procmail/trusted_zipped_poison
}

•	DISABLE_ZIP_SCAN: Deshabilita la exploración de archivos adjuntos ZIP. (1.141+) 
Si no desease realizar la exploración de los archivos tipo ZIP, defina DISABLE_ZIP_SCAN con cualquier valor. 
Ejemplo: 
DISABLE_ZIP_SCAN=YES 

•	ZIPPED_WARNING: Cambia el mensaje de aviso por defecto para los archivos adjuntos tipo ZIP envenenados por su contenido. (1.141+) 
Cuando el Sanitizer envenena un archivo adjunto ZIP basándose en los ficheros que contiene se inserta un texto de aviso dentro del mensaje. Si define ZIPPED_WARNING con una cadena entrecomillada de varias líneas, ésta reemplazará el texto por defecto: 
SECURITY WARNING! 
The mail system has detected that the preceding ZIP archive attachment contains suspicious files. Do not trust it. Contact your system administrator immediately. 
The suspicious files in the archive are: 
Ejemplo: 
ZIPPED_WARNING="
Se ha frustrado un intento de traspasar la seguridad con un archivo ZIP. Este archivo contenía:
" 
Tenga en cuenta que la lista de nombres de archivos comprimidos dentro del ZIP que coincidan con la lista ZIPPED_EXECUTABLES se añadirá al final del texto, por tanto debe terminar su mensaje con el texto indicativo apropiado. 

•	ZIP_MAGIC_WARNING: Cambia el aviso por defecto para los archivos adjuntos ZIP falsos. (1.141+) 
Cuando el Sanitizer intenta explorar un archivo ZIP, primero verifica la existencia de una cadena de identificación correcta. Si no se encontrase dicha cadena se considerará que el archivo ZIP es falso, se envenenará el mensaje y se insertará un mensaje de aviso en el mismo. Si define ZIP_MAGIC_WARNING con una cadena entrecomillada de varias líneas, ésta reemplazará el texto por defecto: 
SECURITY WARNING! 
The mail system has detected that the preceding attachment claims to be a ZIP archive, but it does not have a valid ZIP archive signature. Do not trust it. Contact your system administrator immediately. 
Ejemplo: 
ZIP_MAGIC_WARNING="
Se ha frustrado un intento de traspasar la seguridad con un archivo ZIP falso.”

•	DISABLE_RAR_SCAN: Deshabilita la exploración de archivos adjuntos RAR. (1.149+)
Si no desease realizar la exploración de los archivos tipo RAR, defina DISABLE_RAR_SCAN con cualquier valor. 
Ejemplo: 
DISABLE_RAR_SCAN=YES 

•	RARRED_WARNING: Cambia el mensaje de aviso por defecto para los archivos adjuntos tipo RAR envenenados por su contenido. (1.149+)
Cuando el Sanitizer envenena un archivo adjunto RAR basándose en los ficheros que contiene se inserta un texto de aviso dentro del mensaje. Si define RARRED_WARNING con una cadena entrecomillada de varias líneas, ésta reemplazará el texto por defecto: 
SECURITY WARNING! 
The mail system has detected that the preceding RAR archive attachment contains suspicious files. Do not trust it. Contact your system administrator immediately. 
The suspicious files in the archive are: 
Ejemplo: 
RARRED_WARNING="
Se ha frustrado un intento de traspasar la seguridad con un archivo RAR. Este archivo contenía:
" 
Tenga en cuenta que la lista de nombres de archivos comprimidos dentro del RAR que coincidan con la lista ZIPPED_EXECUTABLES se añadirá al final del texto, por tanto debe terminar su mensaje con el texto indicativo apropiado.

•	RAR_MAGIC_WARNING: Cambia el aviso por defecto para los archivos adjuntos RAR falsos. (1.149+) 
Cuando el Sanitizer intenta explorar un archivo RAR, primero verifica la existencia de una cadena de identificación correcta. Si no se encontrase dicha cadena se considerará que el archivo RAR es falso, se envenenará el mensaje y se insertará un mensaje de aviso en el mismo. Si define RAR_MAGIC_WARNING con una cadena entrecomillada de varias líneas, ésta reemplazará el texto por defecto: 
SECURITY WARNING! 
The mail system has detected that the preceding attachment claims to be a RAR archive, but it does not have a valid RAR archive signature. Do not trust it. Contact your system administrator immediately. 
Ejemplo: 
RAR_MAGIC_WARNING="
Se ha frustrado un intento de traspasar la seguridad con un archivo RAR falso.”

•	BAD_BASE64_WARNING: Cambia el aviso por defecto para los archivos adjuntos ZIP con codificaciones base64 hostiles. (1.144+) 
Cuando el sanitizer intenta explorar un archivo ZIPo RAR, primero decodifica el código base64 del fichero binario. Si la codificación base64 es incorrecta leída línea a línea (p.e. hay líneas de menos de 3 caracteres), se envenena el mensaje y se inserta un mensaje de aviso en el mismo. Un adjunto codificado por un cliente de correo legítimo no debería tener ese tipo de líneas.  the message is poisoned and a warning is inserted into the message. An attachment encoded by a legitimate email client will not have such very short lines. Si define BAD_BASE64_WARNING con una cadena entrecomillada de varias líneas, ésta reemplazará el texto por defecto: 

SECURITY WARNING! 

The mail system has detected that the preceding attachment was encoded in a manner intended to bypass security filtering. Do not trust it. Contact your system administrator immediately. 

Ejemplo: 

BAD_BASE64_WARNING="
Codificación BASE64 hostil en un archivo ZIP atrapada."

•	DISABLE_JPEG_SCAN: Deshabilita la exploración de los archivos adjuntos de imágenes JPEG. (1.147+)

Si no desease explorar las imágenes JPEG, defina DISABLE_JPEG_SCAN con cualquier valor.

Ejemplo:

    DISABLE_JPEG_SCAN=YES 

Para poder examinar los archivos de imágenes JPEG necesitará instalar tres utilidades más:

1.	mimencode, que forma parte del paquete metamail. (o consulte más adelante USE_CPAN)
2.	mktemp, de OpenBSD software archives. (o consulte más adelante USE_CPAN)
3.	libjpeg (en especial, la utilidad rdjpgcom).

	Estas utilidades están incluidas en la mayoría de las distribuciones Linux. Para otros sistemas operativos será necesario descargarse los fuentes y compilarlos.

•	BAD_JPEG_WARNING: Cambia el texto incorporado de advertencia ante archivos JPEG sospechosos de contener un ataque de desbordamiento de buffer. (1.147+)

Si define BAD_ JPEG_WARNING con una cadena entrecomillada de varias líneas, ésta reemplazará el texto por defecto: 

SECURITY WARNING! The mail system has detected that the preceding attachment appears to be a JPEG image containing a Microsoft buffer overflow attack. Do not trust it. Contact your system administrator immediately.

Ejemplo:

    BAD_JPEG_WARNING="
    ¡Archivo adjunto JPEG corrupto o infectado atrapado! " 

•	SECURITY_POISON_WMF: Configura el envenenamiento de los archivos adjuntos de imágenes WMF. (1.149+)

Si desea envenenar todos los archivos adjuntos de imágenes WMF, defina SECURITY_POISON_WMF con cualquier valor.

Sería muy recomendable actuvar esta opción debido al gran peligro que presentan los ficheros .WMF. No se trata de ficheros tradicionales que contienen mapas de bits sino, mas bien, algo capáz de contener un script, y cualquier lenguaje de script podría contener un ataque.

Ejemplo:

    SECURITY_POISON_WMF=YES 

Para poder utilizar esta opción necesitará instalar unas utilidades adicionales:
1.	mimencode, que forma parte del paquete metamail. (vea USE_CPAN más adelante) 
2.	mktemp, de OpenBSD software archives. (vea USE_CPAN más adelante) 
3.	El programa de volcado octal /usr/bin/od – debe ser una versión que soporte las opciones -N y -t.
Estas utilidades suelen venir incluídas en la mayoría de las distribuciones Linux, si su sitema no las incluye deberá descargar los fuentes y compilarlos.

•	WMF_WARNING: Cambia el texto incorporado de advertencia ante archivos WMF (1.149+)

Si define WMF_WARNING con una cadena entrecomillada de varias líneas, ésta reemplazará el texto por defecto: 

SECURITY WARNING! The mail system has detected that the preceding attachment appears to be a WMF image. It has been blocked for security reasons. Contact your system administrator immediately.

Ejemplo:

    WMF_WARNING="
    Archivo adjunto WMF atrapado." 

•	MACRO_WARNING: Cambia el aviso por defecto para los archivos adjuntos de Microsoft Office envenenados (1.141+) 
Cuando el Sanitizer envenena un archivo adjunto de Microsoft Office por una puntuación alta del explorador de macros inserta un texto de aviso dentro del mensaje. Si define MACRO_WARNING con una cadena entrecomillada de varias líneas, ésta reemplazará el texto por defecto: 
SECURITY WARNING! 
The mail delivery system has detected that the preceding document attachment appears to contain hazardous macro code.
Macro Scanner score: 
Ejemplo: 
MACRO_WARNING="
¡Macros malignas en este archivo adjunto de Office! Puntuación: " 
Tenga en cuenta que la puntuación del explorador de macros se añadirá al final, por tanto debe terminar su mensaje con el texto apropiado. 

•	SECURITY_TRUST_MS_DOWNLOAD: Confiar en adjuntos con tipo MIME del tipo APPLICATION/X-MSDOWNLOAD (1.151+)

A partir de la versión 1.151, el sanitizer envenenará automáticamente todos los adjuntos con tipos MIME APPLICATION/X-MSDOWNLOAD y APPLICATION/X-MS-DOWNLOAD. Para desconectar esta opción defina SECURITY_TRUST_MS_DOWNLOAD con cualquier valor.

Este es un remedio provisional hasta que se implemente el manejo completo de los tipos MIME; es posible que este comportamiento pase a ser el comportamiento por defecto una vez que esté lista esta parte.

Ejemplo:

    SECURITY_TRUST_MS_DOWNLOAD=Y 

•	USE_CPAN: Utiliza los módulos Perl CPAN en lugar de programas externos para explorar los archivos adjuntos. (1.141+) 
El Sanitizer puede utilizar CPAN modules MIME::Base64 y File::MkTemp para reemplazar los programas externos "mimencode" y "mktemp". Defina USE_CPAN con cualquier valor para hacer esto. (Nota: Tenga en cuenta que seguirá necesitando el programa externo "unzip" para explorar los archivos adjuntos ZIP; la utilización de un módulo CPAN para ficheros ZIP es una característica prevista para el futuro.) 
Consulte the CPAN FAQ para más información, particularmente: how to install CPAN Perl modules. 
Ejemplo: 
USE_CPAN=YES 

•	PVT_CPAN: Especifica un directorio de librería CPAN privado (no del sistema). (1.141+) 
Si no dispusiese de privilegios de administrador en el sistema donde se ejecuta el Sanitizer (p.ej. se está ejecutando en el servidor de correo de su ISP y disponemos de una cuenta shell), probablemente no podrá instalar los módulos Perl CPAN en los directorios de librerías del sistema. 
Si no puede conseguir que el administrador se los instale, entonces podría instalarlos en un directorio sobre el que tenga derechos y poner el nombre de ese directorio en PVT_CPAN. El nombre de directorio definido en PVT_CPAN se añadirá a la ruta de búsqueda de la librería Perl antes de enlazar los módulos CPAN. 
Ejemplo: 
PVT_CPAN="$HOME/my_cpan" 

Nota importante: Cuando en las instrucciones anteriores se dice “defina nombre-de-variable con cualquier valor”, cualquier valor habilitará la función que dicha variable controla. En particular, esto significa que definiendo la variable con el valor “NO” no deshabilitará la función. Si desea deshabilitar una función defina explícitamente la variable a nada: 
DEBUG_VERBOSE="" 
o 
DEBUG_VERBOSE= 
También debería leer las páginas de man de Procmail para ver que variables de entorno controlan el comportamiento de procmail en si mismo. Algunas de estas variables son reconocidas también por el Sanitizer. 
•	man procmail 
•	man procmailrc 
•	man procmailex 

Implementando políticas de seguridad múltiples
El fichero procmailrc anterior aplica la misma política de seguridad a todos los mensajes que atraviesan el sistema. Puede ser que esto no sea lo que necesita; por ejemplo, podría interesarle relajar ciertos controles para los mensajes procedentes de su dominio, por ejemplo no desfigurar documentos de Word que sus usuarios se envíen unos a otros. 
La forma de implementar esto es proporcionando diferentes definiciones de las variables de configuración basándose en el mensaje que está siendo procesado. Por ejemplo, si quisiera suprimir la desfiguración de los documentos de Word dentro de su propio dominio, podría añadir lo siguiente en cualquier parte antes de la línea INCLUDERC=html-trap.procmail que pone en marcha el Sanitizer: 
:0
* ^From:.*<[a-z0-9]+@midominio.com>
* ^To:.*<[a-z0-9]+@midominio.com>
{
     MANGLE_EXTENSIONS='html?|exe|com|cmd|bat|pif|sc[rt]|lnk|dll|ocx|dot|xl[wt]|p[po]t|rtf|vb[se]?|hta|p[lm]|sh[bs]|hlp|chm|eml|ws[cfh]|ad[ep]|jse?|md[abew]|ms[ip]|reg|asd|cil|pps|asx|wm[szdf]|vcf|nws|\{[-0-9a-f]+\}'
}

Tenga en cuenta que la cabecera "From:" de un email es muy fácil de falsificar. Si deseáse implementar una política menos restrictiva para el correo interno sería preferible basar la regla "source" en la IP correspondiente a su red local tal y como aparece en la cabecera “Received:”. Por ejemplo, si su red local fuése del tipo 10.20.30.nn, debería hacer algo parecido a lo siguiente: 
:0
* ^Received:[^(]+\([^ ]+ +\[10\.20\.30\.[0-9]+\]
* ^To:.*<[a-z0-9]+@mydomain.com>
{
    MANGLE_EXTENSIONS='html?|exe|com|cmd|bat|pif|sc[rt]|lnk|dll|ocx|dot|xl[wt]|p[po]t|rtf|vb[se]?|hta|p[lm]|sh[bs]|hlp|chm|eml|ws[cfh]|ad[ep]|jse?|md[abew]|ms[ip]|reg|asd|cil|pps|asx|wm[szdf]|vcf|nws|\{[-0-9a-f]+\}'
    SECURITY_TRUST_HTML=Y
    etc...
}
El formato exacto de su cabecera local “Received:” dependerá del software que utilice como MTA. Revise las cabeceras de mensajes reales de su red local para determinar el formato correcto. 

Si quisiera proporcionar al administrador los medios para saltarse completamente el Sanitizer, por ejemplo, para facilitar la recuperación de mensajes puestos en cuarentena y entregarlos al destinatario al que iban dirigidos puede reemplazar la línea INCLUDERC=html-trap.procmail con: 
:0
* ! ^From:.*<root@midominio\.com>
* ! ^X-Security: bypass sanitizer 954kJF64ljf8o6r
{
    INCLUDERC=/etc/procmail/html-trap.procmail
}
Utilice una cadena de galimatías diferente a ésta para su cabecera "bypass sanitizer" de tal forma que alguien que haya leído esta página no sepa como saltarse su Sanitizer. Si quisiera que personas de fuera fuesen capaces de saltarse el Sanitizer omita el chequeo de la cabecera From: . 

Implementando filtros de seguridad personalizados
Es posible aprovechar las facilidades de cuarentena y notificación que el Sanitizer le proporciona para sus propias reglas de seguridad específicas y personalizadas. Las funciones de notificación y cuarentena del Sanitizer son activadas mediante cabeceras X-Content-Security insertadas en el mensaje. Vd. Puede hacer esto con sus propias reglas de procmail y, de esta forma, provocar que el Sanitizer notifique o ponga en cuarentena. 

Está disponible un  script ejemplo de reglas locales que se actualiza más a menudo que los ejemplos que siguen. Utilice preferéntememte ese script en lugar de los ejemplos de más abajo que solo deberían usarse como aclaración.
Por Ejemplo, una de las variantes de un gusano actual se envía a si mismo como un archivo adjunto de nombre aleatorio en un mensaje sin asunto. Para crear una regla personalizada para que el Sanitizer detecte y capture este ataque sin tener que envenenar todos los .exe adjuntos podría hacer lo siguiente: 
Ponga lo siguiente en /etc/procmail/local-rules.procmail (owner root, group root, mode 644) 
# Detección de Hybris cuando se envía como mensaje anónimo.
#
:0
* > 20000
* < 40000
* !^From:
* !^Subject:
* ^Content-Type:.*multipart/mixed;
{
        :0 B hfi
        * ^Content-Disposition:.*\.EXE
        * ^Content-Type:.*\.EXE
        * ^TVqQAAMAAAAEAAAA
        * ^SiXLG3Lv\+wdKT1hwcrOTfD7rduGAY5LvseJ7
        * ^D4TKBAAAUFVQ/1QkSAEs
        | formail -A "X-Content-Security: [$HOST] NOTIFY" \
                  -A "X-Content-Security: [$HOST] QUARANTINE" \
                  -A "X-Content-Security: [$HOST] REPORT: Gusano anónimo Hybris capturado" 
}
Cambie su fichero /etc/procmailrc  donde dice: 
INCLUDERC=/etc/procmail/html-trap.procmail
por: 
INCLUDERC=/etc/procmail/local-rules.procmail
INCLUDERC=/etc/procmail/html-trap.procmail

Si el gusano anónimo es detectado las cabeceras X-Content-Security serán insertadas en el mensaje. Entonces el Sanitizer es ejecutado normalmente; saneará el mensaje e, incluso si no encuentra nada malo en el mensaje, lo pondrá en cuarentena. 

Nota: El ejemplo anterior es muy específico y como el gusano Hybris puede ser modificado por el autor a medida que se propaga, este ejemplo no es lo suficientemente fiable para una instalación real.

Pueden especificarse reglas y acciones específicas por médio de las cabeceras X-Content-Security: 
Palabra Clave	Acción	
NOTIFY 	Envía un mensaje de notificación a la lista $NOTIFY y al remitente si fuese correcto. 	
NONOTIFY 	Envía un mensaje de notificación al remitente si fuese correcto pero no envía nada a la lista $NOTIFY. 	
SPOOFED_SENDER 	Suprime la notificación al remitente porque la dirección de remite se ha detectado como falsa. Tenga en cuenta que especificando NONOTIFY y SPOOFED_SENDER a la vez no se enviará nada, en su lugar mejor no ponga ninguna opción de  notificación. 	
REPORT: xxxxx 	Añade un tecto a la línea REPORT en los mensajes de notifiación. Se permiten varias líneas REPORT. 	
QUARANTINE 	Envenena el mensaje, éste será puesto en cuarentena si hemos configurado que los mensajes evenenados sean puestos en cuarentena. 	
DISCARD 	Desecha el mensaje. 	

Puede poner cuantas reglas personales de seguridad desee en /etc/procmail/local-rules.procmail - por ejemplo, para atrapar todos los archivos.EXE anónimos añada: 
# Los mensajes con adjuntos.EXE han de tener una línea de asunto
#
:0
* > 20000
* !^Subject:
* ^Content-Type:.*multipart/mixed;
{
        :0 B hfi
        * ^Content-Disposition:.*\.EXE
        * ^Content-Type:.*\.EXE
        | formail -A "X-Content-Security: [$HOST] NOTIFY" \
                  -A "X-Content-Security: [$HOST] QUARANTINE" \
                  -A "X-Content-Security: [$HOST] REPORT: .EXE anónimo capturado" 
}
Esto es mucho más seguro que intentar buscar un ejecutable específico como en el ejemplo del Hybris anónimo. 
Para capturar el gusano SirCam basándose en un trocito de código podría añadir: 
# Captura SirCam (firma del 08/01/2001)
#
:0
* > 130000
* ^Content-Type:.*multipart/mixed;
{
        :0 B hfi
        * ^Content-Disposition: attachment;
        * ^Content-Transfer-Encoding: base64
	* AAAAGgU0NhbTMyABCDTUlN|AAAAAaBTQ2FtMzIAEINNSU1F|ABkAAAABoFNDYW0zMgAQg01J
        | formail -A "X-Content-Security: [$HOST] NOTIFY" \
                  -A "X-Content-Security: [$HOST] QUARANTINE" \
                  -A "X-Content-Security: [$HOST] REPORT: Gusano SirCam atrapado - Vea http://www.symantec.com/avcenter/venc/data/w32.sircam.worm@mm.html"
}
Aquí tiene un detector de BadTrans: 
# Captura BadTrans (Firma del 12/03/2001)
#
:0
* > 40000
* < 50000
* ^Subject: Re:
* 1^1 ^Content-Type:.*multipart/.*boundary="====_ABC1234567890DEF_===="
* 1^1 ^Content-Type:.*multipart/.*multipart/
{
        :0 B hfi
	* ^Content-Type: audio/x-wav;
        * ^Content-ID: 
        * ^Content-Transfer-Encoding: base64
        | formail -A "X-Content-Security: [$HOST] NOTIFY" \
                  -A "X-Content-Security: [$HOST] QUARANTINE" \
                  -A "X-Content-Security: [$HOST] REPORT: Gusano BadTrans atrapado - Vea http://securityresponse.symantec.com/avcenter/venc/data/w32.badtrans.b@mm.html"
}
Aquí tiene un detector para algunas variedades de Klez: 
# Captura Klez (firma del 04/26/2002)
#
:0
* > 100000
* ^Content-Type:.*multipart/alternative;
{
        :0 B hfi
        * \<i?frame +src=(3D)?cid:.* height=(3D)?[0-9] +width=(3D)?[0-9]>
        * ^Content-Type:.*audio/
        * ^Content-ID:.*<
        * ^Content-Transfer-Encoding: base64
        * ^TVqQAAMAAAAEAAAA
        | formail -A "X-Content-Security: [$HOST] NOTIFY" \
                  -A "X-Content-Security: [$HOST] QUARANTINE" \
                  -A "X-Content-Security: [$HOST] REPORT: Posible gusano Klez atrapado - Vea http://securityresponse.symantec.com/avcenter/venc/data/w32.klez.removal.tool.html"
}
Nuevas características en versión 1.132: Si no quisiera mantener copias en cuarentena de los mensajes capturados de esta forma cambie la acción de QUARANTINE a DISCARD. Si no quisiera ser notificado pero si que lo sea el remitente cambie donde dice NOTIFY por NONOTIFY. Por Ejemplo: 
        | formail -A "X-Content-Security: [$HOST] NONOTIFY" \
                  -A "X-Content-Security: [$HOST] DISCARD" \
Esto mantendrá libres sus buzones de cuarentena y postmaster de los cientos de mensajes de aviso tras un ataque por un gusano conocido. Si no quisiera ponerlo en cuarentena, ni ser notificado, ni notificar al remitente, entonces simplemente elimine el mensaje enviándolo a /dev/null. Tendrá que eliminar el flag "filter" del test interno: 
        :0 B hi

Pueden contactar conmigo en <jhardin@impsec.org> - También pueden visitar mi página web. 

Traducción al español: Juan Maria Gil <yo@juanmaria.com>