sisse correo

Unidad 19: Servidor de Correo Electrónico

19.1. ObjetivosAl finalizar esta unidad Ud. estará en la capacidad de:

✔ Conocer los componentes de un sistema de correo electrónico y propósito de cada uno de ellos.✔ Saber implementar los servicios básicos POP3, IMAP y SMTP con componentes Open Source.✔ Integrar herramientas de filtrado de Spam y Virus sobre los servicios de correo existentes.✔ Implementar una herramienta de monitoreo y control de cuarentena de los correos electrónicos.✔ Realizar una instalación y configuración básica de un Webmail para los usuarios remotos.

19.2. Servidor de autenticación, POP3, IMAP y SMTP

19 .2 .1 Con cep to s bá sico s

¿Q u é e s u n s er v i d o r d e c or r e o ? Es una aplicación que nos permite enviar mensajes (correos) de unos usuarios a otros, con independencia de la red que dichos usuarios estén utilizando.Para lograrlo se definen una serie de protocolos, cada uno con una finalidad concreta:

SMTP, Simple Mail Transfer ProtocolEs el protocolo que se utiliza para que dos servidores de correo intercambien mensajes.

POP, Post Office ProtocolSe utiliza para obtener los mensajes guardados en el servidor y pasárselos al usuario.

IMAP, Internet Message Access ProtocolSu finalidad es la misma que la de POP, pero el funcionamiento y las funcionalidades que ofrecen son diferentes.

Así pues, un servidor de correo consta en realidad de dos servidores: un servidor SMTP que será el encargado de enviar y recibir mensajes, y un servidor POP/IMAP que será el que permita a los usuarios obtener sus mensajes.

Para obtener los mensajes del servidor, los usuarios se sirven de clientes, es decir, programas que implementan un protocolo POP/IMAP. En algunas ocasiones el cliente se ejecuta en la máquina del usuario (como el caso de Mozilla Thunderbird, Evolution, Microsoft Outlook). Sin embargo existe otra posibilidad: que el cliente de correo no se ejecute en la máquina del usuario; es el caso de los clientes vía web, como GMail, Hotmail, OpenWebmail, SquirrelMail o Terra. En ellos la arquitectura del servicio es más compleja:

En una máquina (A) tenemos el servidor SMTP y el servidor POP/IMAP. En otra (B) tenemos un servidor web con una aplicación cliente POP/IMAP. El usuario conecta vía WEB con (B) y entonces el cliente POP/IMAP establece una conexión POP/IMAP con el servidor de la máquina A; éste servidor le devuelve a B los mensajes del usuario, y una vez recibidos, el cliente genera una página web con los mensajes recibidos. La página web se pasa al servidor web que será el que la envíe al explorador web del usuario.

En cualquier caso, los protocolos SMTP/POP/IMAP son inseguros en cuanto a que los mensajes viajan en claro por la red, es decir, es fácil obtener nuestros mensajes y contraseñas. Para ello se suele añadir una capa SSL, es decir, un método de cifrado que puedan implementar tanto el servidor como el cliente. En el caso del correo vía web se pueden utilizar dos capas SSL: una entre A y B y otra entre el servidor web de B y el navegador web del usuario.

T e c no l og í a s u s a da s Este documento le guiará a través de los pasos a seguir para instalar y configurar un sistema de correo completo que consta de diversos componentes como los mencionados a continuación:

PostfixEl MTA o servidor SMTP para el envío y recepción de correos

Cyrus IMAPEl servidor POP/IMAP usado por los usuarios para la lectura de correos

Cyrus SASLEl servicio encargado de la autenticación

MailScannerEl filtro de contenidos para los correos que eliminará el Spam y Virus

ClamAV

El antivirus

SpamAssassinLa avanzada herramienta antispam

HordeEl Webmail completo y funcional

MailWatchEl administrador de tráfico de correo y cuarentenas

19 .2 .2 . C yru s IM AP y SA SL

C o n s i d e ra c i o n e s i n ici a l e s SASL son las siglas de Simple Authentication and Security Layer, un método para añadir soporte para la autenticación a protocolos basados en la conexión que ha sido estandarizado por la IETF (Internet Engineering Task Force). Se usa en servidores (en este caso Cyrus IMAP) para manejar las peticiones de autenticación de los clientes. Para ello, el protocolo incluye un comando para identificar y autenticar un usuario contra un servidor y para, opcionalmente, negociar la protección de las subsiguientes interacciones del protocolo. Si se negocia su uso, una capa de seguridad es añadida entre el protocolo y la conexión.La librería SASL de Cyrus también usa la librería OpenSSL para cifrar los datos. El lector encontrará más información en la página web de Cyrus SASL.

In sta la ció n d e Cyru s IM A P y SASL

En Red Hat / CentOS y derivados instalamos los paquetes:

# yum install cyrus-sasl cyrus-imapd -y

En Debian y derivados instalamos los paquetes:

# apt-get install sasl2-bin libsasl2-modules cyrus-imapd-2.2 cyrus-pop3d-2.2 cyrus-clients-2.2 cyrus-admin-2.2 -y

C o n f i g u r a c i ó n d e Cy r u s SASL La configuración de Cyrus SASL se centrará principalmente en modificar los parámetros con los que se ejecutará el demonio saslauthd. Específicamente necesitaremos que este demonio use el mecanismo de autenticación PAM, para lo cual debemos modificar algún fichero de configuración del servicio correspondiente en cada distribución Linux.

En Debian y derivados el archivo a editar es /etc/default/saslauthd y modificamos la líneas que se mencionan a continuación:

START=YES MECHANISMS="pam"

En Red Hat / CentOS y derivados el archivo a editar es /etc/sysconfig/saslauthd y modificamos la líneas que se mencionan a continuación:

MECH="pam"

C o n fi g u r a c i ó n d e C y r u s I M AP La configuración de Cyrus IMAP es bastante sencilla, en realidad no se requiere modificar nada del fichero de configuración por defecto que traen las distribuciones Linux pero procederemos a explicar algunas de las directivas que pueden resultar de interés para el lector.

configdirectoryPermite definir la ruta al directorio de la configuración IMAP del servicio. En este directorio se almacena información variada sobre los buzones de los usuarios como por ejemplo la cuota, muchos de ellos presentados como archivos binarios indexados de la base de datos Berkeley.

Sintaxis : configdirectory: archivo

Ejemplo:

configdirectory: /var/lib/imap

defaultpartitionEsta directiva permite definir la partición por defecto usada para la creación de nuevos buzones. El nombre que recibe es definido en una directiva partition-NOMBRE. Es en esta partición donde se almacena el contenido de los buzones de todos los usuarios.

Sintaxis : defaultpartition: nombre

Ejemplo:

defaultpartition: default

partition-NOMBREEsta directiva permite definir un nombre de partición que apunta a una ruta de directorio dentro del sistema de archivos.

Sintaxis : partition-NOMBRE: ruta_directorio

Ejemplo:

partition-default: /var/spool/imap

unixhierarchysepEsta directiva permite que los buzones de IMAP puedan tener el caracter punto "." como parte de su nombre. Esto es porque por defecto Cyrus IMAP usa el punto "." como delimitador de buzones en sus diversos niveles de jerarquía y asignando el valor yes a esta directiva evitará interpretaciones incorrectas respecto a dicho caracter especial.

Sintaxis : unixhierarchysep: yes|no

Ejemplo:

unixhierarchysep: yes

admins:Esta directiva define una lista de usuarios del sistema que tendrán los mayores privilegios de administrador sobre todos los servicios que ofrezca Cyrus IMAP.

Sintaxis : admins: usuario [usuario] [usuario] ...

Ejemplo:

admins: cyrus

allowplaintextEsta directiva permite que las autenticaciones se puedan dar en texto plano pues es la única forma soportada por SASL PLAIN.

Sintaxis : allowplaintext: yes|no

Asignar su valor en yes para asegurar la compatibilidad con el valor de la siguiente directiva:

allowplaintext: yes

sasl_mech_listEsta directiva especifica la lista de mecanismos SASL permitidos para que los usuarios puedan autenticarse.

Sintaxis : sasl_mech_list: mecanismo [mecanismo] [mecanismo] ...

Ejemplo:

sasl_mech_list: PLAIN

sasl_pwcheck_methodEsta directiva permite definir el método que se usará para realizar el proceso de autenticación. Algunos valores posibles son auxprop y saslauthd pero se procederá a usar el primero de ellos. El segundo puede usarse cuando se tiene la necesidad de usar mecanismos más seguros como el caso de CRAM-MD5 o DIGEST-MD5

Sintaxis : sasl_pwcheck_method: método

Ejemplo:

sasl_pwcheck_method: saslauthd

autocreatequotaEsta directiva define el valor en KB del tamaño de la cuota que será aplicado automáticamente a los buzones recién creados. Si tiene un valor no positivo entonces se asumirá que la cuota es ilimitada.

Sintaxis : autocreatequota: numero

En el ejemplo se configura una cuota de 10 MB:

autocreatequota: 10240

quotawarnEsta directiva define en qué porcentaje de la cuota de un buzón el sistema Cyrus IMAP empezará a generar advertencias.

Sintaxis : quotawarn: porcentaje

Ejemplo:

quotawarn: 90

tls_cert_fileEsta directiva la ruta del archivo de certificado global usado para todos los servicios (POP3, IMAP).

Sintaxis : tls_cert_file: archivo

Ejemplo:

tls_cert_file: /etc/cyrus-imapd/mail.newdomains.com-cert.pem

tls_key_fileEsta directiva la ruta de la llave privada que pertenece al certificado global usado para todos los servicios (POP3, IMAP).

Sintaxis : tls_key_file: archivo

Ejemplo:

tls_key_file: /etc/cyrus-imapd/mail.newdomains.com-key.pem

Impor ta n t e :Para que el soporte SSL/TLS de POP3 e IMAP sea activado, se requiere habilitar en el archivo /etc/cyrus.conf las líneas siguientes:

imaps cmd="imapd -s -U 30" listen="imaps" prefork=0 maxchild=100 pop3s cmd="pop3d -s -U 30" listen="pop3s" prefork=0 maxchild=50

Estas han sido algunas de las directivas que comúnmente requieren ser modificadas respecto a sus valores por defecto. La documentación completa de todas las demás directivas se pueden encontrar en imapd.conf(5).

I n ic i a n d o l o s s e r vic i o s Una vez configurados ambos servicios de Cyrus procederemos a iniciarlos.

En Red Hat / CentOS y derivados:

# service cyrus-imapd start

En Debian y derivados:

# invoke-rc.d cyrus2.2 startA dm i n i st r a n d o C y ru s I MA P Una vez configurado Cyrus IMAP e iniciado el servicio es necesario poder realizar una serie de operaciones administrativas como por ejemplo crear buzones, eliminar buzones, cambiar la cuota, entre otros. Esto es posible a través de la herramienta cyradm la cual debe ser invocada como sigue:

# cyradm --user cyrus localhost

En el ejemplo de arriba se especifica al usuario cyrus con el parámetro --user debido a que es esa la cuenta que se configuró con permisos de administrador en el archivo /etc/imapd.conf. La ejecución de dicho comando nos preguntará una clave que es la que tiene asignada dicho usuario en el sistema según /etc/passwd.Una vez que nos autenticamos con la contraseña correspondiente se nos presentará una shell con un prompt en el cual podremos consultar la ayuda de los comandos disponibles como sigue:

localhost> ?authenticate, login, auth authenticate to serverchdir, cd change current directory createmailbox, create, cm create mailbox deleteaclmailbox, deleteacl, dam remove ACLs from mailbox deletemailbox, delete, dm delete mailboxdisconnect, disc disconnect from current server exit, quit exit cyradmhelp, ? show commandsinfo display mailbox/server metadatalistacl, lam, listaclmailbox list ACLs on mailbox listmailbox, lm list mailboxeslistquota, lq list quotas on specified root listquotaroot, lqr, lqm show quota roots and quotas for mailbox reconstruct reconstruct mailbox (if supported) renamemailbox, rename, renm rename (and optionally relocate) mailbox server, servername, connect show current server or connect to server setaclmailbox, sam, setacl set ACLs on mailboxsetinfo set server metadatasetquota, sq set quota on mailbox or resourceversion, ver display version info of current serverAlgunos comandos los explicamos brevemente por ser los más usados:

lm [patron]Hace un listado de los buzones que coincidan con un patrón opcional expresado como wildcars. Ejemplo:

localhost> lm *rios*

lam <patron>Muestra los permisos de los buzones que coincidan con un patrón opcional expresado como wildcars. Ejemplo:

localhost> lam user.arios

sam <buzon> <usuario> <permisos>Asigna permisos a un buzón determinado. Los permisos existentes son:

l (lookup): el usuario puede ver que el buzón de correo existe r (read): el usuario puede leer el buzón de correo. El usuario puede seleccionar el

buzón, leer los datos contenidos, llevar a cabo búsquedas y copiar mensajes de ese buzón s (seen): mantiene el estado leído por usuario. Se preservan los flags Seen y Recent

para cada usuario w (write): el usuario puede modificar los flags excepto Seen y Deleted (los cuales son

controlados por otros permisos) i (insert): el usuario puede insertar mensajes en el buzón de correo p (post): el usuario puede mandar correo a la dirección de envío del buzón. Este permiso

difiere del permiso i en que el sistema de envío inserta información de seguimiento en los mensajes envíados

c (create): el usuario puede crear subcarpetas en el buzón d (delete): el usuario puede alterar el flag Deleted, expirar correos y borrar o

renombrar el buzón a (administer): el usuario puede cambiar la ACL del buzón all (todos): posee todos los permisos anteriores

Ejemplos:

localhost> sam user.arios cyrus all localhost> sam user.nposada arengifo lrsdc

cm <buzón>Crea un buzón de un usuario determinado. Especificar el separador "." si "unixhierarchysep: no"o el separador "/" si se usa "unixhierarchysep: yes". Ejemplo:

localhost> cm user.amendoza localhost> cm user/arengifo

dm <buzón>Elimina un buzón. Su uso es similar al comando cm. Ejemplo:

localhost> dm user.amendoza localhost> dm user/arengifo

lq <buzón>Muestra el estado de la cuota de un buzón especifico. Ejemplo:

localhost> lq user.jchavez

sq <buzón> [numero]Asigna una cuota en KB a un buzón específico. Si se omite el tamaño de la cuota se asignailimitado. En el primer ejemplo se asigna 15 MB de cuota y en el segundo ejemplo se le da una cuota ilimitada:

localhost> sq user.jchavez 15360 localhost> sq user.arengifo

19 .2 .3 . El MTA Po stf ix

C o n s i d e ra c i o n e s i n ici a l e s El MTA (Mail Transportation Agent) Postfix pretende ser rápido, fácil de administrar y seguro, a la vez que suficientemente compatible con Sendmail como para que los usuarios existentes no se asusten. Por lo tanto, externamente mantiene el estilo de Sendmail, mientras que internamente es completamente diferente.A diferencia de Sendmail, Postfix no es un programa monolítico, sino una combinación de pequeños programas, cada uno de los cuales lleva a cabo una función especializada. En este documento, el lector encontrará la información necesaria para tener el sistema funcionando junto a otros componentes que completan la instalación de un sistema de correo electrónico. Puede encontrarse más información sobre Postfix en la documentación online de su website.

In sta la ció n d e Po stfix

En Red Hat / CentOS y derivados instalamos los paquetes:

# yum install postfix -y

En Debian y derivados instalamos los paquetes:

# apt-get install postfix postfix-pcre -y

C o n f i g u r a c i ó n d e l M T A La configuración de Postfix se centra básicamente en los archivos /etc/postfix/main.cf y /etc/postfix/master.cf de los cuales en el

primero nos centraremos en este documento.El archivo /etc/postfix/main.cf contiene las directivas que afectan directamente a las funcionalidades de Postfix dentro de una red, tal como el dominio de correo que atenderá, las opciones de relay, la autenticación de usuarios para el servicio SMTP, entre otros. Es por ello que se mostrarán una serie de directivas que suelen ser de las más comunes a la hora de configurar un servidor de envío y recepción de correos.

mydomainEsta directiva el nombre de dominio asociado al servidor. Su valor puede ser invocado en otras secciones del archivo de configuración.

Sintaxis : mydomain = dominio

Ejemplo:

mydomain = newdomains.com

myhostnameEsta directiva define el nombre del servidor usado para el funcionamiento normal en los diálogos SMTP.

Sintaxis : myhostname = nombre_DNS

Ejemplos:

myhostname = mail.newdomains.com myhostname = mail.$mydomain

mydestinationEsta directiva define una lista de dominios que serán aceptados por el servidor como destino final válido

Sintaxis : mydestination = dominio [,dominio] [,dominio]

Ejemplo:

mydestination = $mydomain, $myhostname, localhost.$mydomain, newdomains.org, newdomains.net

myoriginEsta directiva permite definir el dominio desde el cual se aparenta que se originan los correos enviados a través del servidor.

Sintaxis : myorigin = dominio

Ejemplo:

myorigin = newdomains.net

mynetworksEsta directiva define las direcciones de red que se consideran de mayor confianza que otros clientes externos. Por lo general a los clientes que coinciden con estas redes se les permite el relay a través del servidor.

Sintaxis : mynetworks = direccion [,dirección] [,dirección]

Ejemplo:

mynetworks = 127.0.0.0/8, 192.168.1.0/24

alias_mapsEsta directiva define la fuente de alias para los buzones de correo del servidor.

Sintaxis : alias_maps = origen

En el siguiente ejemplo se general un archivo indexado (hash) a partir de /etc/aliases:

OpenSourceCollegePrimer centro de capacitación OpenSource Linux

Linux for SysAdminsPágina 390

ww w . o p e n s o u r c e c o ll e g e . c o m

alias_maps = hash:/etc/aliases

Otros tipos posibles de fuentes además de archivos indexados puede ser obtenida de la salida del comando postconf -m y el uso de cada uno de esos tipos puede ser estudiado en postconf(1).

mailbox_transportEsta directiva define un agente externo que se encargará de la entrega de los mensajes hacia el buzón correspondiente de los usuarios.

Sintaxis : mailbox_transport = aplicación

En el siguiente ejemplo se indica la ruta del socket de Cyrus IMAP el mismo que se define en el archivo /etc/cyrus.conf debido a que en este documento se asume la integración de Postfix con Cyrus IMAP:

mailbox_transport = lmtp:unix:/var/run/cyrus/socket/lmtp

smtpd_sasl_auth_enableEsta directiva permite activar la autenticación SMTP para los usuarios a la hora de intentar enviar correos a través del servidor.

Sintaxis : smtpd_sasl_auth_enable = yes|no

Ejemplo:

smtpd_sasl_auth_enable = yes

header_checksEsta directiva define la fuente desde la cual se leen una serie de condiciones y acciones a tomar sobre las cabeceras de los mensajes de correo una vez que son recibidos por el servidor pero aún no enviados al buzón de los usuarios.

Sintaxis : header_checks = origen

En el siguiente ejemplo se le dice a Postfix que cualquier mensaje recibido (saliente o entrante) sea automáticamente enviado a la cola hold del sistema de modo tal que se quede por así decirlo estancado para que luego MailScanner lo recoja, analice y envíe según su destino ya definido.

header_checks = regexp:/etc/postfix/header_checks

Siendo el contenido del archivo /etc/postfix/header_checks el siguiente:

/^Received:/ HOLD

message_size_limitEsta directiva establece el tamaño máximo en bytes que se Postfix permite recibir.

Sintaxis : message_size_limit = numero

En el ejemplo se define un tamaño límite de 20 MB:

message_size_limit 20971520

smtpd_helo_requiredEsta directiva define si es obligatorio o no que los clientes realicen la fase HELO propia del diálogo SMTP. Muchos spammers omiten este paso mientras que los servidores de correo legítimos casi nunca lo dejan de lado.

Sintaxis : smtpd_helo_required = yes|no

Ejemplo:

smtpd_helo_required = yes

http://www.opensourcecollege.com/




smtpd_client_restrictionsEsta directiva define una serie de condiciones que debe cumplir un remitente en la fase cliente para poder decidir una acción a tomar. La fase de cliente analiza la naturaleza del origen de su dirección de red (dirección IP, resolución inversa, etc.).Las condiciones se pueden especificar en una única línea o en líneas distintas cada una empezando por al menos un espacio en blanco. El orden de las condiciones según se especifican es importante pues tienen naturaleza jerárquica.

Sintaxis : smtpd_client_restrictions = condición [,condición] [,condición]

Algunas de las condiciones válidas para esta fase cliente son:

permit_mynetworksPermite el paso a los clientes que coincidan con $mynetworks

permit_sasl_authenticatedPermite el paso a los clientes autenticados por SMTP

reject_unknown_clientRechaza a los clientes que no cuenten con una resolución inversa consistente

reject_rbl_client RBLRechaza a los clientes que se encuentren en alguna de las listas negras especificadas

En el siguiente ejemplo se considera clientes de confianza a quienes estén definidos en la directiva $mynetworks o se hayan autenticado con un usuario y contraseña válidos, mientras que se rechazará a quienes pertenezcan a alguna lista negra de las indicadas debajo:

smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_rbl_client bl.spamcop.net, reject_rbl_client sbl.spamhaus.org, reject_rbl_client list.dsbl.org

smtpd_helo_restrictionsEsta directiva define una serie de condiciones que debe cumplir un remitente en la fase HELO para poder decidir una acción a tomar. En tal fase se analiza la conformidad de los parámetros usados en el comando HELO dentro del diálogo SMTP.Las condiciones se pueden especificar en una única línea o en líneas distintas cada una empezando por al menos un espacio en blanco. El orden de las condiciones según se especifican es importante pues tienen naturaleza jerárquica.

Sintaxis : smtpd_helo_restrictions = condición [,condición] [,condición]




reject_non_fqdn_hostnameRechaza a quienes usen un nombre no DNS en el HELO tal como: mail, server01, mailer u otros que carezcan de la sección host.dominio correspondiente. En Postfix 2.3 en adelante la condición es reject_non_fqdn_helo_hostname

reject_invalid_hostnameRechaza a quienes usen un nombre DNS (host.dominio) pero con valores inválidos tales como:1mail.domain.com, mail.new_domain.com, smtp.españa.com u otros que en general no califiquen como un nombre DNS válido de Internet. En Postfix 2.3 en adelante la condición es reject_invalid_helo_hostname

reject_unknown_hostnameRechaza a quienes usen un nombre DNS válido pero inexistente en Internet. En Postfix 2.3 enadelante la condición es reject_unknown_helo_hostname

En el siguiente ejemplo se considera clientes de confianza a quienes estén definidos en la directiva $mynetworks o se hayan autenticado con un usuario y contraseña válidos o usen nombres DNS válidos en el HELO:





smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_hostname, reject_invalid_hostname

smtpd_sender_restrictionsEsta directiva define una serie de condiciones que debe cumplir un cliente en la fase remitente para poder decidir una acción a tomar. En tal fase se analiza la conformidad de la dirección de correo usada como remitente en el diálogo SMTP.Las condiciones se pueden especificar en una única línea o en líneas distintas cada una empezando por al menos un espacio en blanco. El orden de las condiciones según se especifican es importante pues tienen naturaleza jerárquica.

Sintaxis : smtpd_sender_restrictions = condición [,condición] [,condición]




reject_non_fqdn_senderRechaza a quienes usen una forma incorrecta de dirección e-mail como remitente que no cuente con la sección usuario y dominio respectivo (usuario@dominio).

reject_unknown_sender_domainRechaza a quienes usen una dirección e-mail como remitente de un dominio inexistente.

En el siguiente ejemplo se rechazará en cambio a quienes no usen una dirección válida y en un dominio existente como e-mail remitente:

smtpd_sender_restrictions = reject_non_fqdn_sender, reject_unknown_sender_domain

smtpd_recipient_restrictionsEsta directiva define una serie de condiciones que debe cumplir un cliente en la fase del destinatario para poder decidir una acción a tomar. En tal fase se analiza la conformidad de la dirección de correo usada como destinatario en el diálogo SMTP.Las condiciones se pueden especificar en una única línea o en líneas distintas cada una empezando por al menos un espacio en blanco. El orden de las condiciones según se especifican es importante pues tienen naturaleza jerárquica.Esta fase permite controlar el relay a los clientes ya que es la que define si finalmente el mensaje será enviado o no a su destinatario final por lo que es donde nunca deberían faltar las restricciones mínimas.

Sintaxis : smtpd_recipient_restrictions = condición [,condición] [,condición]




reject_non_fqdn_recipientRechaza a quienes usen una forma incorrecta de dirección e-mail como destinatario que nocuente con la sección usuario y dominio respectivo (usuario@dominio)

reject_unknown_recipient_domainRechaza a quienes usen una dirección e-mail como destinatario de un dominio inexistente.

reject_unauth_destinationRechaza a quienes intenten enviar correo a alguna dirección externa, es decir a un dominio no





servido por Postfix

En el siguiente ejemplo se rechazará en cambio a quienes no usen una dirección válida y en un dominio existente como e-mail destinatario. Luego que se verifique lo primero el servidor será permisivo con los clientes que coincidan con $mynetworks o se hayan autenticado por SMTP, y finalmente se protege de ser un relay abierto al rechazar a quienes intenten enviar correo a través de nuestro servidor a un dominio externo no servido por Postfix a menos que no haya cumplido alguna de las reglas permisivas anteriores.

smtpd_sender_restrictions = reject_non_fqdn_sender, reject_unknown_sender_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

smtpd_use_tlsEsta directiva habilita el soporte opcional de TLS/SSL para la comunicación con los clientes. Esto quiere decir que el usuario puede elegir entre usar o no TLS/SSL para la comunicación entera con el servidor.

Sintaxis : smtpd_use_tls = yes|no

Ejemplo:

smtpd_use_tls = yes

smtpd_tls_auth_onlyCuando el soporte de TLS/SSL es opcional (ver directiva anterior) esta directiva permite controlar si se acepta o no la autenticación en un canal inseguro, es decir no cifrado o sin SSL/TLS.

Sintaxis : smtpd_tls_auth_only = yes|no

Ejemplo:

smtpd_tls_auth_only = yes

smtpd_tls_cert_fileEsta directiva define la ruta del archivo de certificado en formato PEM que usará Postfix para conexiones TLS/SSL de los clientes.

Sintaxis : smtpd_tls_cert_file = archivo

Ejemplo:

smtpd_tls_cert_file = /etc/postfix/ssl/mail.newdomains.com-cert.pem

smtpd_tls_key_fileEsta directiva define la ruta de la llave privada del certificado que usará Postfix para conexiones TLS/SSL de los clientes.

Sintaxis : smtpd_tls_key_file = archivo

Ejemplo:

smtpd_tls_key_file = /etc/postfix/ssl/mail.newdomains.com-key.pem

P o stf ix y C y ru s S A SL Una vez editado el archivo de configuración /etc/postfix/main.cf debe generarse un archivo adicional de configuración el cual asociará Postfix con el demonio saslauthd para las tareas de autenticación de los clientes en el momento de querer enviar correos a través del servidor.El archivo de nombre smtpd.conf por lo general debe ser creado en el directorio /usr/lib/sasl2 pero en algunas distribuciones comoDebian esto difiere siendo para este caso específico el directorio /etc/postfix/sasl. El contenido del archivo debe ser como sigue:

pwcheck_method: saslauthd mech_list: PLAIN LOGIN





loglevel: 3

Estas líneas de configuración le dice a Postfix que los mecanismos válidos a aceptar de los clientes son PLAIN y LOGIN a través del método saslauthd que representa al demonio del mismo nombre.

Definitivamente estas no son todas las directivas de configuración de Postfix ni mucho menos, pero la documentación sobre la gran mayoría de ellas puede ser encontrada en postconf(5) a donde el lector debería dirigirse a fin de complementar el estudio de algunas características específicas de su interés no cubiertas en este documento.

A dm i n i st r a ci ó n d e P o stfix A continuación se entrará en el estudio de algunas operaciones comunes de caracter administrativo que son importantes para dar mantenimiento al servidor.

Una de estas operaciones implica el manipular el estado del MTA y verificar la correcta configuración una vez que se encuentra en marcha. Para ello nos basaremos en el comando postfix el cual recibe algunos parámetros como los descritos a continuación:

checkComprueba la conformidad de los permisos y propietarios de ciertos archivos/directorios así como también su existencia

startInicia el MTA con un previo chequeo igual que el descrito arriba

stopDetiene el MTA de manera correcta y ordenada

abortDetiene el MTA de manera abrupta e inmediata

reloadRelee su archivo de configuración haciendo efectivo los cambios del mismo

flushIntenta enviar todos los mensajes que han sido encolados por errores previos diversos puestos en la cola deferred

Así el siguiente ejemplo hará un chequeo general a la consistencia de archivos/directorios respecto a sus permisos y luego hará efectivo los cambios realizados al archivo de configuración:

# postfix check# postfix reloadpostfix/postfix-script: refreshing the Postfix mail system

Información adicional sobre este comando puede ser encontrado en postfix(1).

Si el estado del MTA es correcto respecto a su configuración y entorno de trabajo con archivos y directorios no está de más poder verificar el estado de la cola de mensajes siendo esto posible con el comando mailq:

# mailq-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------A4EEC67D06B 16238 Sat Sep 1 05:06:13 [email protected](host mail.newdomains.com[/var/run/cyrus/socket/lmtp] said: 452 4.2.2 Over quota (in reply toRCPT TO command))

[email protected]

48F0A67D06C 1300 Sat Sep 1 07:54:00 [email protected](host mail.newdomains.com[/var/run/cyrus/socket/lmtp] said: 452 4.2.2 Over quota (in reply toRCPT TO command))

[email protected]

C105D67D066 1379 Sat Sep 1 02:52:43 [email protected](host mail.newdomains.com[/var/run/cyrus/socket/lmtp] said: 452 4.2.2 Over quota (in reply toRCPT TO command))

[email protected]

-- 20 Kbytes in 3 Requests.

mailto:[email protected]










En el ejemplo anterior se aprecia 3 mensajes encolados, aparentemente los buzones a los que se intentaba enviar mensajes en el dominio newdomains.com se han excedido en su cuota. Para ello sería de utilidad aumentar la cuota de dichos buzones en Cyrus y luego ejecutar postfix flush.

Entre otra de las operaciones administrativas podemos encontrar el mantenimiento de los alias del sistema de correo que permitirán crear distintos nombres para uno o más buzones en particular así como crear grupos simples de distribución. Para ello ha de modificarse el archivo /etc/aliases el cual tiene la siguiente forma:

alias: destino [,destino] [,destino] ...

La primera columna indica el nombre del alias, es decir el nombre del buzón al que originalmente estaba destinado un mensaje, y los valores especificados a la derecha indican los destinos reales a los cuales se enviará el mensaje de correo.En el siguiente ejemplo se crea una serie de alias imprescindibles los cuales son destinados finalmente al usuario root:

postmaster: root abuse: rootmailer-daemon: roothostmaster: root webmaster: root noc: root

En el ejemplo anterior se crean alias individuales destinados cada uno al usuario root solamente. Pero también es posible crear grupos que se asemejen a listas de distribución en el cual un alias permitirá enviar una copia del mensaje a más de un usuario del sistema tal como se aprecia debajo:

sistemas: achavez, rdavila, jchacon, ncespedes, postmaster ventas: rhurtado, farismendi, juanperez, gerentelima

Una vez que se hayan realizado los cambios correspondientes en el archivo de alias se requiere regenerar a partir de éste una versión indexada del mismo el cual será el que Postfix use en realidad por motivos de mejor desempeño. Este archivo indexado por lo general será "/etc/aliases.db" y se actualiza con cualquiera de los dos comandos mostrados a continuación:

# postmap hash:/etc/aliases# newaliases

Una vez que ha sido compilado y actualizado nuevamente el archivo de alias se necesita recargar Postfix como sigue:

# postfix reload

Finalmente como es normal en la administración de cualquier servicio el monitoreo de los logs es siempre una labor de gran importancia. Para esto se tiene que el registro de actividad de Postfix suele ser almacenado en archivos como /var/log/maillog, /var/ log/mail.log, /var/log/mail u otro archivo similar dependiendo de la distribución Linux con la que se trabaje, el cual debe ser constantemente vigilado como sigue:

# tail -f /var/log/mail.log





19.3. Filtro de contenidos, Antispam, Antivirus

C o m p o n en t e s n e c e s a r i o s La configuración de un servidor de mensajería no sería completo si no cuenta con alguna herramienta de filtro de contenidos, la misma que permita reducir en gran medida los correos no deseados tal como aquellos infectados por algún virus o los que contengan algún tipo de publicidad no solicitada comúnmente conocido como Spam.Es por ello que se requiere la instalación de un filtro de contenidos como MailScanner el cual se encargará de analizar cada correo entrante y saliente bajo ciertas reglas que el administrador lo configure previamente.MailScanner no es una herramienta que directamente analice y desinfecte virus, ni tampoco detecte Spam, sino son ClamAV ySpamAssassin los que realizan dichas labores respectivamente.

Sin embargo MailScanner se encargará de tomar cada correo de la cola de Postfix y evaluarlo bajo una lista de condiciones y de ser necesario invocará a SpamAssassin y/o ClamAV para completar su análisis, pudiendo luego opcionalmente tomar acciones como eliminar el mensaje, enviarlo a una cuarentena o enviarlo al destinatario final.

Respecto a ClamAV podemos agregar nada más que nos basaremos en su configuración por defecto y debemos asegurarnos que su demonio respectivo se encuentre iniciado.

19 .3 .1 . Filtro d e con ten ido s Ma ilSca nn er

I n st a l a c i ó n d e M a ilSc a n n e r MailScanner puede ser descargado desde su Web oficial:

htt p: //w ww.ma ils ca nne r.inf o

En este en la sección Downloads existen paquetes para distribuciones Red Hat, SuSE y derivados. Todos estos paquetes son untarball el cual debe ser descomprimido y desde adentro ejecutar el script install.sh como sigue:

# tar zxf MailScanner-VERSION.tar.gz# cd MailScanner-VERSION# ./install.sh

Este script se encargará de hacer todo el trabajo de instalación y configuración predeterminada de MailScanner en el sistema, colocando normalmente los binarios y otras librerías debajo de /usr y la configuración debajo de /etc/MailScanner.

Sin embargo si descargó el paquete MailScanner de la versión "Solaris / BSD / Other Linux / Other Unix" se tendrá que la instalación de manera predeterminada se hará debajo del directorio /opt/MailScanner. Asimismo se debe contemplar el hecho de crear uno mismo su script SySV en /etc/init.d para iniciar MailScanner desde su directorio de instalación.

C o n f i g u r a n d o M a ilSc a n n e r El archivo de configuración por defecto suele ser ubicado en /etc/MailScanner/MailScanner.conf. A continuación la descripción de directivas de MailScanner:

%org-name%Esta directiva define simplemente un nombre de la organización la cual administra el servicio. No debe contener espacios en blanco.

Sintaxis : %org-name% = nombre

Ejemplo:

%org-name% = NewDomains

%org-long-name%Esta directiva define un nombre largo de la organización el mismo que aparecerá como parte de la firma en los reportes generados por MailScanner. Puede contener espacios en blanco.

Sintaxis : %org-long-name% = nombres

Ejemplo:

%org-long-name% = New Domains Technologies Inc.

%web-site%


http://www.mailscanner.info/




Esta directiva define el sitio Web de la organización, el mismo que se muestra junto con el nombre largo de la organización como parte de la firma de algunos reportes.

Sintaxis : %web-site% = website

Ejemplo:

%web-site% = http://www.newdomains.com

%report-dir%Esta directiva define la ruta del directorio que contiene los reportes de MailScanner. Por lo general existe un directorio por cada idioma soportado y esta directiva pretende definir el idioma de los reportes.

Sintaxis : %report-dir% = ruta_directorio

Ejemplo:

%report-dir% = /etc/MailScanner/reports/es

Run As UserRun As GroupEstas directivas definen el usuario y grupo bajo el cual se ejecutará MailScanner.

Sintaxis : Run As User = usuarioSintaxis : Run As Group = grupo

Ejemplo:

Run As User = postfixRun As Group = mail

Incoming Queue DirEsta directiva define la ruta del directorio de donde MailScanner recogerá los correos para su posterior análisis. Considérese que debe asignarse la ruta del directorio de la cola hold de Postfix dado que éste colocará ahí cada correo recibido según la configuración anterior que se hizo en la directiva header_checks.

Sintaxis : Incoming Queue Dir = ruta_directorio

Ejemplo:

Incoming Queue Dir = /var/spool/postfix/hold

Outgoing Queue DirEsta directiva define la ruta del directorio donde MailScanner colocará los correos ya analizados. Considérese que debe asignarse la ruta del directorio de la cola incoming de Postfix dado que éste recogerá de ahí cada correo que encuentre para su envío correspondiente.

Sintaxis : Outgoing Queue Dir = ruta_directorio

Ejemplo:

Outgoing Queue Dir = /var/spool/postfix/incoming

Incoming Work DirEsta directiva define la ruta del directorio donde MailScanner temporalmente desempaqueterá los correos durante su proceso de análisis.

Sintaxis : Incoming Work Dir = ruta_directorio

Ejemplo:


http://www.newdomains.com/




Incoming Work Dir = /var/spool/MailScanner/incoming

Quarantine DirEsta directiva define la ruta del directorio de la cuarentena de MailScanner.

Sintaxis : Quarantine Dir = ruta_directorio

Ejemplo:

Quarantine Dir = /var/spool/MailScanner/quarantine

MTAEsta directiva define cuál es el MTA que se integrará con MailScanner. Su valor debe ser postfix, sendmail, exim o zmailer

Sintaxis : MTA = nombre

Ejemplo:

MTA = postfix

Incoming Work User Incoming Work Group Incoming Work PermissionsEsta directiva define los propietarios y permisos del directorio de trabajo de MailScanner definido en Incoming Work Dir.

Sintaxis : Incoming Work User = usuarioSintaxis : Incoming Work Group = grupoSintaxis : Incoming Work Permissions = permisos

Ejemplo:

Incoming Work User = postfix Incoming Work Group = mail Incoming Work Permissions = 0660

Quarantine User Quarantine Group Quarantine PermissionsEsta directiva define los propietarios y permisos del directorio de la cuarentena de MailScanner definido en Quarantine Dir.

Sintaxis : Quarantine User = usuarioSintaxis : Quarantine Group = grupoSintaxis : Quarantine Permissions = permisos

A fin de que más adelante MailWatch que es ejecutado a través de Apache sea capaz de modificar los archivos de la cuarentena se asigna el grupo de ejecución al mismo del proceso Apache, y se configura al usuario postfix como miembro de ese grupo.

Quarantine User = postfix Quarantine Group = www-data Quarantine Permissions = 0660

Hacemos miembro del grupo de Apache al usuario postfix:

# usermod -G www-data,mail,sasl postfix

Virus ScanningEsta directiva define si se analizarán o no los correos con un antivirus externo.

Sintaxis : Virus Scanning = yes|no

Ejemplo:





Virus Scanning = yes

Virus ScannersEsta directiva define el antivirus externo a usar. Algunos valores posibles válidos son clamav, sophos, mcafee, etrust, panda,trend antivir, entre otros.

Sintaxis : Virus Scanners = nombre

Ejemplo:

Virus Scanners = clamav

Allow FilenamesDeny FilenamesEsta directiva define qué tipos de archivos se permiten o se deniegan en los correos como adjuntos. Puede tomar como valor las expresiones regulares que hagan coincidencia con un tipo de archivo.

Sintaxis : Allow Filenames = regexpSintaxis : Deny Filenames = regexp

Ejemplo:

Deny Filenames = \.exe \.pif \.bat \.scr

Filename RulesEsta directiva define la ruta de un archivo donde se establecerán con mayor detalle cada uno de los tipos de archivos permitidos o denegados de manera similar a las dos directivas anteriores.

Sintaxis : Filename Rules = ruta_archivo

Ejemplo:

Filename Rules = %etc-dir%/filename.rules.conf

El archivo al cual se hace referencia debe contener 4 campos de los cuales el primero es la acción a tomar ( allow o deny), el segundo una expresión regular que coincida con el archivo, el tercer campo un mensaje de log y el cuarto campo es un mensaje que será enviado al destinatario como reporte. Los campos deben estar estrictamente separados por tabulaciones como en el siguiente ejemplo:

deny pretty\s+park\.exe$ "Pretty Park" virus "Pretty Park" virus found in attachments

Quarantine InfectionsEsta directiva decide si se enviarán a cuarentena o no los correos que contengan archivos infectados.

Sintaxis : Quarantine Infections = yes|no

Ejemplo:

Quarantine Infections = yes

Spam ChecksEsta directiva decide si se buscará o no Spam en los mensajes.

Sintaxis : Spam Checks = yes|no

Ejemplo:

Spam Checks = yes


Spam ListEsta directiva define una serie de listas negras de Internet a las cuales se consultará si pertenecen o no las direcciones IP de los remitentes. Los nombres que se definen en esta directiva están definidos en el archivo /etc/MailScanner/spam.lists.conf.

Sintaxis : Spam List = nombre [nombre] [nombre] ...

Ejemplo:

Spam List = SBL+XBL spamhaus.org spamhaus-XBL SBL+XBL spamcop.net NJABL

Spam Domain ListEsta directiva define una serie de listas negras de Internet a las cuales se consultará si pertenecen o no los dominios de los remitentes. Los nombres que se definen en esta directiva están definidos en el archivo /etc/MailScanner/spam.lists.conf.

Sintaxis : Spam Domain List = nombre [nombre] [nombre] ...

Ejemplo:

Spam Domain List = RFC-IGNORANT-DSN RFC-IGNORANT-POSTMASTER RFC-IGNORANT-ABUSE RFC-IGNORANT- BOGUSMX

Spam Lists To Be SpamEsta directiva define la cantidad de listas negras en las que debe estar presente un remitente para que su mensaje sea considerado Spam de nivel moderado.

Sintaxis : Spam Lists To Be Spam = numero

Ejemplo:

Spam Lists To Be Spam = 2

Spam Lists To Reach High ScoreEsta directiva define la cantidad de listas negras en las que debe estar presente un remitente para que su mensaje sea considerado Spam de nivel alto.

Sintaxis : Spam Lists To Reach High Score = numero

Ejemplo:

Spam Lists To Be Spam = 3

Use SpamAssassinEsta directiva define si se usará o no a SpamAssassin como herramienta de detección de Spam.

Sintaxis : Use SpamAssassin = yes|no

Ejemplo:

Use SpamAssassin = yes

Required SpamAssassin ScoreEsta directiva define el puntaje mínimo que debe tener un mensaje según la calificación de SpamAssassin para que sea considerado Spam de nivel moderado.

Sintaxis : Required SpamAssassin Score = numero

Ejemplo:

Required SpamAssassin Score = 5

High SpamAssassin ScoreEsta directiva define el puntaje mínimo que debe tener un mensaje según la calificación de SpamAssassin para que sea considerado Spam de nivel alto.

Sintaxis : High SpamAssassin Score = número

Ejemplo:

High SpamAssassin Score = 10

Max SpamAssassin SizeMax Spam Check SizeEstas directivas definen el tamaño máximo que debe tener un mensaje para que pueda ser analizado en busca de Spam porSpamAssassin y MailScanner respectivamente.Normalmente SpamAsassin no tiene un rendimiento nada óptimo analizando mensajes grandes, quizás más allá de los 300 KB de tamaño. Muchos spammers han aprendido esto y saben que generando mensajes de gran tamaño (300 KB a más) lograrán que éstos no sean analizados llegando así con más probabilidad a la bandeja de entrada del usuario.

Sin embargo MailScanner requerir analizar sólo parte de un mensaje para saber si es spam o no (Ejm: analizar sólo los primeros200 KB) sin afectar el rendimiento de SpamAsassin. Por esta razón se recomienda que el límite de tamaño que puede analizar MailScanner sea un valor alto, alrededor de 1 MB o más dependiendo del tamaño de los mensajes de spam que reciba frecuentemente, mientras que el tamaño máximo de mensajes analizados por SpamAssassin se mantenga bajo o en sus valores predeterminados.

Sintaxis : Max SpamAssassin Size = tamañoSintaxis : Max Spam Check Size = tamaño

Ejemplo:

Max SpamAssassin Size = 200kMax Spam Check Size = 1000k

Spam ActionsEsta directiva define la acción a tomar cuando se detecte Spam moderado en un mensaje.

Sintaxis : Spam Actions = acción

Algunas de las posibles acciones a tomar son:

deliverEntrega el mensaje a su destinatario de manera normal

deleteElimina el mensaje

storeAlmacena una copia del mensaje en la cuarentena

bounceEnvia un mensaje de rechazo al remitente

forward usuario@dominioReenvía una copia del mensaje a una cuenta de correo

header "nombre: valor"Agrega una cabecera al mensaje donde "nombre" no debe contener espacios

Algunos ejemplos válidos son los siguientes:

Spam Actions = forward [email protected] Actions = deliver header "X-Spam-Status: Yes"

High Scoring Spam ActionsEsta directiva define la acción a tomar cuando se detecte Spam alto en un mensaje.


Sintaxis : High Scoring Spam Actions = accion

Las acciones son las mismas descritas en la directiva anterior. Ejemplo:

High Scoring Spam Actions = store

Hasta aquí con el estudio de directivas de MailScanner, que cuenta con un gran número de opciones disponibles para cambiar a nuestro gusto pero todas las directivas se encuentran muy bien documentadas en su archivo de configuración por lo que resultará bastante sencillo al lector entenderlas.

19 .3 .2 . Ana liza do r d e Sp am Spam Assa ssin

I n st a l a c i ó n d e S p a m Ass a ss i n SpamAssassin está incluido en los repositorios de las principales distribuciones Linux. El procedimiento de instalación es directo como debajo se indica:

En Red Hat / CentOS y derivados:

# yum install spamassassin -y

En Debian y derivados:

# apt-get install spamassassin -y

A j u st e s b á si c o s d e S pam Ass a s s in Una vez configurado MailScanner sería importante hacer algunos ajustes a un archivo de configuración de SpamAssassin identificado como /etc/MailScanner/spam.assassin.prefs.conf según las directivas que se mencionan a continuación:

ok_languages ok_localesEsta directiva define la codificación y el idioma preferentemente esperados en los contenidos de los mensajes de correo. Puede ser útil si se recibe Spam en idiomas que no son los nuestros y sobre todo con codificación de caracteres que no son propios de nuestra lengua.

Sintaxis : ok_languages código [código] [código] ...Sintaxis : ok_locales código [código] [código] ...

Ejemplo:

ok_languages es en ok_locales es en

use_bayesEsta directiva permite activar el motor Bayesiano que en base a métodos estadísticos clasificará los mensajes como Spam.

Sintaxis : use_bayes 0|1

Ejemplo:

use_bayes 1

bayes_auto_learnEsta directiva permite que SpamAssassin aprenda de manera automáticamente cuando un mensaje es o no Spam en base a las estadísticas bayesianas.

Sintaxis : bayes_auto_learn 0|1

Ejemplo:

bayes_auto_learn 1

bayes_pathEsta directiva define el prefijo de los archivos de Bayes que se crearán durante el tiempo de funcionamiento.

Sintaxis : bayes_path ruta_directorio/prefijo

En el siguiente ejemplo se crearán los archivos de bayes con un prefijo de nombre "bayes" en el directorio /etc/MailScanner/bayes. Tenga cuidado que /etc/MailScanner/bayes/bayes no es ni debe ser un directorio.

bayes_path /etc/MailScanner/bayes/bayes

bayes_file_modeEsta directiva define los permisos de los archivos de Bayes.

Sintaxis : bayes_file_mode permisos

Ejemplo:

bayes_file_mode 0660

P l u g i n s d e S p am Ass a ss i n SpamAssassin es capaz de extender la funcionalidad que por defecto incluye a través del uso de plugins, los mismos que pueden ser activados (los que vienen por defecto con SpamAssassin) o descargados algún sitio Web publicado por terceros.En la Web de SpamAssassin se puede encontrar una lista de plugins personalizados de diferentes licencias (gratuitos, licenciaApache, comerciales de pago, etc), bajo la siguiente URL:

htt p: //w ik i.a pac he .org/s pa mas sa ss in/Cus tomP lugins

Estos plugins tras ser descargados, deben ser colocados en el directorio /etc/mail/spamassassin. Los plugins por lo general serán archivos de extensión .pm y sus directivas de configuración se guardan en archivos de extensión .cf.Es recomendable habilitar algunos plugins:

TextCat : Habilita la identificación de idiomas. Si se habilitan las directivas ok_languages y/o ok_locales en/etc/MailScanner/spam.assassin.prefs.conf se requiere habilitar este plugin.Para habilitarlo se debe descomentar la línea loadplugin Mail::SpamAssassin::Plugin::TextCat en el archivo/etc/mail/spamassassin/v310.pre.

SPF : Habilita la validación SPF de los dominios de los remitentes. Para habilitarlo se debe descomentar la línealoadplugin Mail::SpamAssassin::Plugin::SPF en el archivo /etc/mail/spamassassin/init.pre.

DCC : Habilita el análisis de mensajes en base a cálculos checksum (sumas de verificación) desde la base de datos DCC. Para habilitarlo se debe descomentar la línea loadplugin Mail::SpamAssassin::Plugin::DCC en el archivo /etc/mail/spamassassin/v310.pre.

DCC se puede obtener descargar desde h t t p : / / w w w . r h y o l i t e . c om/d c c / y tras ser compilado e instalado, se debe definir en el archivo /etc/MailScanner/spam.assassin.prefs.conf la ruta del binario del comando dccproc como sigue:

ifplugin Mail::SpamAssassin::Plugin::DCCdcc_path /usr/local/bin/dccprocendif

Razor2 : Habilita el análisis de mensajes en base a cálculos checksum (sumas de verificación) desde la base de datos Razor. Para habilitarlo se debe descomentar la línea loadplugin Mail::SpamAssassin::Plugin::Razor2 en el archivo /etc/mail/spamassassin/v310.pre.

Razor2 se puede obtener descargar desde h t t p : //r a zo r . s our c ef or g e .n et / y tras ser compilado e instalado, se debe definir en el archivo /etc/MailScanner/spam.assassin.prefs.conf la ruta de configuración de razor como sigue:

use_razor2 1razor_config /var/spool/MailScanner/spamassassin/razor/razor-agent.conf

Razor2 debe crear el archivo de configuración con el comando razor-admin como sigue:

# mkdir -p /var/spool/MailScanner/spamassassin/razor# razor-admin -create -config /var/spool/MailScanner/spamassassin/razor/razor-agent.conf# chown -R postfix:mail /var/spool/MailScanner/spamassassin

Relayed By Dialup : Habilita el análisis de los remitentes de correo para evaluar si provienen desde direcciones IPpúblicas fijas o dinámicas (conexiones caseras del tipo ADSL o Diaulp).

http://www.rhyolite.com/dcc/

http://www.rhyolite.com/dcc/

http://wiki.apache.org/spamassassin/CustomPlugins

Este plugin debe ser descargado desde el sitio Web de Spamassassin donde se publican los plugins personalizados (link líneas arriba mostrado).

Existen otros plugins que pueden ser instalador y habilitados a criterio del administrador. Entre ellos existen algunos que analizan archivos PDF (plugin PDFassassin), análisis de spam en imágenes (plugin Fuzzy OCR), y otros.

Muchos de estos plugins tras ser habilitados puede que requieran cumplir algunas dependencias de paquetes antes de poder funcionar correctamente. Para poder averiguar si existen dependencias incumplidas de los plugins de SpamAssassin se puede ejecutar lo siguiente:

# spamassassin --lint -D 2>&1 | less

Este comando nos arroja una salida extensa de la cual requerimos filtrar el texto 'not installed' para identificar los módulos de Perl no instalados y requeridos como dependencia:

[15810] dbg: diag: module installed: Net::SMTP, version 2.31 [15810] dbg: diag: module installed: Mail::SPF, version v2.005[15810] dbg: diag: module not installed: Mail::SPF::Query ('require' failed)[15810] dbg: diag: module not installed: IP::Country::Fast ('require' failed) [15810] dbg: diag: module not installed: Net::Ident ('require' failed)[15810] dbg: diag: module installed: IO::Socket::INET6, version 2.54[15810] dbg: diag: module not installed: IO::Socket::SSL ('require' failed)[15810] dbg: diag: module installed: Compress::Zlib, version 2.008 [15810] dbg: diag: module installed: Time::HiRes, version 1.9711[15810] dbg: diag: module not installed: Mail::DomainKeys ('require' failed) [15810] dbg: diag: module not installed: Mail::DKIM ('require' failed) [15810] dbg: diag: module installed: DBI, version 1.607

En el ejemplo arriba mostrado se puede apreciar que los siguientes módulos no están instalados:

Mail::SPF::Query IP::Country::Fast Net::Ident IO::Socket::SSL Mail::DomainKeys Mail::DKIM

Estos módulos pueden ser descargados desde:

htt p: //s ea rc h.c pa n.org

Donde podremos utilizar el buscador para cada uno de los módulos con palabras clave como 'Mail SPF Query', 'IP Country Fast','Net Ident' y así con el resto.Cada uno de estos módulos de Perl se encuentran publicados como tarballs los cuales deben ser instalados bajo un procedimiento general como el siguiente:

# tar zxf modulo-perl-VERSION.tar.gz# cd modulo-perl-VERSION# perl Makefile.PL# make# make install

Es necesario observar con atención la salida del comando perl Makefile.PL ya que éste puede advertir de la ausencia de otros módulos de Perl que son necesarios tener instalados antes de la compilación del módulo de nuestro interés.

19 . 3 . 3 . A n t i v i ru s C l am A V El antivirus puede ser instalado de algunas de las siguientes formas:

1. En Red Hat / CentOS y derivados : Se requiere tener configurado el repositorio de DAG (h t t p : / / d a g . w i e er s.c o m ) y ejecutar desde la línea de comandos lo siguiente:

# yum install clamav clamav-db clamd -y

2. En Debian y derivados : El repositorio Debian Volatile contiene las últimas versiones

# yum install clamav-daemon clamav-freshclam -y

3. Descargar desde el sitio oficial de ClamAV (h tt p :/ / w w w .cl a m a v . n et ) los instaladores para la distribución Linux que tengamos e

http://www.clamav.net/

http://dag.wieers.com/

http://search.cpan.org/

instalar los paquetes de manera individual:

# rpm -ivh clam*.rpm

19 . 3 . 4 . P r u e b a s d e f u n c i o n am i en to Finalmente cuando ya se ha culminado con la configuración de los servicios Cyrus IMAP, Postfix y MailScanner es momento de realizar las primeras pruebas de funcionamiento de todos los componentes integrados.Para eso empezaremos verificando nuestras conexiones activas debiendo constatar de tener abiertos los puertos 143, 110, y 25 principalmente:

# netstat -tnlpActive Internet connections (only servers)Proto Recv-Q Send-Q Local Address Foreign Address Statetcp 0 0 0.0.0.0:110 0.0.0.0:* LISTENtcp 0 0 0.0.0.0:143 0.0.0.0:* LISTENtcp 0 0 127.0.0.1:2000 0.0.0.0:* LISTENtcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN

Luego empezaremos a probar un diálogo SMTP con el servidor para enviarle un mensaje sencillo desde comandos telnet:

# telnet localhost 25Trying 127.0.0.1...Connected to localhost. Escape character is '^]'.220 mail.newdomains.com ESMTPHELO gsmtp163.google.com250 mail.newdomains.comMAIL FROM: <[email protected]>250 2.1.0 OkRCPT TO: <[email protected]>250 2.1.5 OkDATA354 End data with <CR><LF>.<CR><LF>Mensaje de Prueba.250 2.0.0 Ok: queued as CD4A267D083QUIT221 2.0.0 ByeConnection closed by foreign host.

Luego de eso debería haber entrado un nuevo mensaje en la cola de Postfix y éste pasarlo luego a MailScanner. Veamos algunas líneas de los logs:

Sep 2 18:38:01 localhost postfix/smtpd[17789]: 077FA67D087: client=localhost[127.0.0.1] Sep 2 18:38:06 localhost postfix/cleanup[17792]: 077FA67D087: hold: header Received: from gsmtp163.google.com (localhost [127.0.0.1])??by mail.newdomains.com (Postfix) with SMTP id077FA67D087??for <[email protected]>; Sun, 2 Sep 2007 18:37:53 -0500 (PET) fromlocalhost[127.0.0.1]; from=<[email protected]> to=<[email protected]> proto=SMTPhelo=<gsmtp163.google.com>Sep 2 18:38:06 localhost postfix/cleanup[17792]: 077FA67D087: message- id=<[email protected]>Sep 2 18:38:06 localhost MailScanner[16132]: New Batch: Scanning 1 messages, 947 bytesSep 2 18:38:06 localhost MailScanner[16132]: Spam Checks: StartingSep 2 18:38:06 localhost MailScanner[16132]: Whitelist refresh time reachedSep 2 18:38:06 localhost MailScanner[16132]: Starting up SQL WhitelistSep 2 18:38:06 localhost MailScanner[16132]: Read 0 whitelist entriesSep 2 18:38:06 localhost MailScanner[16132]: Blacklist refresh time reachedSep 2 18:38:06 localhost MailScanner[16132]: Starting up SQL BlacklistSep 2 18:38:06 localhost MailScanner[16132]: Read 0 blacklist entriesSep 2 18:38:07 localhost postfix/smtpd[17789]: disconnect from localhost[127.0.0.1] Sep 2 18:38:10 localhost MailScanner[16132]: Virus and Content Scanning: StartingSep 2 18:38:10 localhost MailScanner[16132]: Requeue: 077FA67D087.0D0E9 to 0BD5867D088Sep 2 18:38:10 localhost postfix/qmgr[8320]: 0BD5867D088: from=<[email protected]>,size=502, nrcpt=1 (queue active)Sep 2 18:38:10 localhost MailScanner[16132]: Uninfected: Delivered 1 messagesSep 2 18:38:10 localhost MailScanner[16132]: Logging message 077FA67D087.0D0E9 to SQLSep 2 18:38:10 localhost MailScanner[16132]: Config: calling custom end function SQLBlacklistSep 2 18:38:10 localhost MailScanner[16132]: Closing down by-domain spam blacklist









Sep 2 18:38:10 localhost MailScanner[16132]: Config: calling custom end functionMailWatchLoggingSep 2 18:38:10 localhost MailScanner[16132]: Config: calling custom end function SQLWhitelistSep 2 18:38:10 localhost MailScanner[16132]: Closing down by-domain spam whitelistSep 2 18:38:10 localhost MailScanner[16132]: MailScanner child dying of old ageSep 2 18:38:10 localhost cyrus/master[17799]: about to exec /usr/lib/cyrus/bin/lmtpdSep 2 18:38:10 localhost cyrus/lmtpunix[17799]: executedSep 2 18:38:10 localhost cyrus/lmtpunix[17799]: accepted connectionSep 2 18:38:10 localhost cyrus/lmtpunix[17799]: lmtp connection preauth'd as postmanSep 2 18:38:10 localhost cyrus/lmtpunix[17799]: duplicate_check:<[email protected]> user.root 0Sep 2 18:38:10 localhost MailScanner[17800]: MailScanner E-Mail Virus Scanner version 4.55.10starting...Sep 2 18:38:10 localhost MailScanner[17800]: Read 748 hostnames from the phishing whitelistSep 2 18:38:10 localhost MailScanner[17800]: Config: calling custom init function SQLBlacklistSep 2 18:38:10 localhost MailScanner[17800]: Starting up SQL BlacklistSep 2 18:38:10 localhost cyrus/lmtpunix[17799]: duplicate_check:<[email protected]> user.root 0Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: mystore: starting txn 2147485203Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: mystore: committing txn 2147485203Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: duplicate_mark:<[email protected]> user.root 1188776290 47597596182714Sep 2 18:38:10 localhost MailScanner[17800]: Read 0 blacklist entriesSep 2 18:38:10 localhost MailScanner[17800]: Config: calling custom init functionMailWatchLoggingSep 2 18:38:10 localhost MailScanner[17800]: Started SQL Logging childSep 2 18:38:10 localhost MailScanner[17800]: Config: calling custom init function SQLWhitelistSep 2 18:38:10 localhost MailScanner[17800]: Starting up SQL WhitelistSep 2 18:38:10 localhost MailScanner[17800]: Read 0 whitelist entriesSep 2 18:38:10 localhost MailScanner[17800]: Using SpamAssassin results cacheSep 2 18:38:10 localhost MailScanner[17800]: Connected to SpamAssassin cache databaseSep 2 18:38:10 localhost cyrus/lmtpunix[17799]: Delivered:<[email protected]> to mailbox: user.rootSep 2 18:38:10 localhost postfix/lmtp[17798]: 0BD5867D088: to=<[email protected]>,orig_to=<[email protected]>, relay=mail.newdomains.com[/var/run/cyrus/socket/lmtp], delay=17, delays=16/0.01/0.02/0.39, dsn=2.1.5, status=sent (250 2.1.5 Ok)Sep 2 18:38:10 localhost postfix/qmgr[8320]: 0BD5867D088: removedSep 2 18:38:10 localhost MailScanner[17800]: Enabling SpamAssassin auto-whitelistfunctionality...Sep 2 18:38:11 localhost MailScanner[17800]: Using locktype = flock

En medio de la gran cantidad de líneas puede apreciarse cual es el remitente (MAIL FROM) y el destinatario (RCPT TO), así como también como MailScanner analiza su contenido y finalmente lo devuelve a Postfix para finalmente entregarlo a Cyrus IMAP.Una forma alternativa de enviar un correo desde la línea de comandos con el mismo resultado que el anterior es como sigue:

# echo "Mensaje de prueba" | sendmail -f [email protected] -t [email protected]

Finalmente podemos probar el correcto funcionamiento de la autenticación y el servicio IMAP como sigue:

# telnet localhost 143Trying 127.0.0.1... Connected to localhost. Escape character is '^]'.* OK proxy Cyrus IMAP4 v2.2.13-Debian-2.2.13-10 server ready. LOGIN arengifo abc123. OK User logged in. LIST "" "*"* LIST (\HasChildren) "." "INBOX"* LIST (\HasNoChildren) "." "INBOX.Sent"* LIST (\HasNoChildren) "." "INBOX.Trash". OK Completed (0.000 secs 4 calls). SELECT INBOX* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)]* 3 EXISTS* 0 RECENT* OK [UIDVALIDITY 1184871996]* OK [UIDNEXT 87]. OK [READ-WRITE] Completed. FETCH 1:* (FLAGS)* 1 FETCH (FLAGS (\Seen))* 2 FETCH (FLAGS (\Seen))* 3 FETCH (FLAGS (\Seen)). OK Completed (0.000 sec). FETCH 3 body[text]









* 3 FETCH (BODY[TEXT] {6} Hola). OK Completed (0.000 sec)w* BYE LOGOUT received. OK CompletedConnection closed by foreign host.

Con esto ya se tiene un sistema de correo con los servicios SMTP, POP e IMAP protegidos por un filtro de contenidos comoMailScanner trabajando en conjunto con SpamAssassin y ClamAV.

sisse correo

Documents