Unidad 19: Servidor de Correo Electrnico

19.1. Objetivos
Al finalizar esta unidad Ud. estar en la capacidad de:

Conocer los componentes de un sistema de correo electrnico y propsito de cada uno de ellos. Saber implementar los servicios bsicos 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 electrnicos. Realizar una instalacin y configuracin bsica de un Webmail para los usuarios remotos.

19.2. Servidor de autenticacin, POP3, IMAP y SMTP

19.2.1 Conceptos bsicos Quesunservidordecorreo? Es una aplicacin que nos permite enviar mensajes (correos) de unos usuarios a otros, con independencia de la red que dichos usuarios estn utilizando. Para lograrlo se definen una serie de protocolos, cada uno con una finalidad concreta:

SMTP, Simple Mail Transfer Protocol Es el protocolo que se utiliza para que dos servidores de correo intercambien mensajes. POP, Post Office Protocol Se utiliza para obtener los mensajes guardados en el servidor y pasrselos al usuario. IMAP, Internet Message Access Protocol Su 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 mquina 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 mquina del usuario; es el caso de los clientes va web, como GMail, Hotmail, OpenWebmail, SquirrelMail o Terra. En ellos la arquitectura del servicio es ms compleja: En una mquina (A) tenemos el servidor SMTP y el servidor POP/IMAP. En otra (B) tenemos un servidor web con una aplicacin cliente POP/IMAP. El usuario conecta va WEB con (B) y entonces el cliente POP/IMAP establece una conexin POP/IMAP con el servidor de la mquina A; ste servidor le devuelve a B los mensajes del usuario, y una vez recibidos, el cliente genera una pgina web con los mensajes recibidos. La pgina web se pasa al servidor web que ser el que la enve 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 fcil obtener nuestros mensajes y contraseas. Para ello se suele aadir una capa SSL, es decir, un mtodo de cifrado que puedan implementar tanto el servidor como el cliente. En el caso del correo va 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.

Tecnologas usadas Este documento le guiar a travs de los pasos a seguir para instalar y configurar un sistema de correo completo que consta de diversos componentes como los mencionados a continuacin:

Postfix El MTA o servidor SMTP para el envo y recepcin de correos Cyrus IMAP El servidor POP/IMAP usado por los usuarios para la lectura de correos Cyrus SASL El servicio encargado de la autenticacin MailScanner El filtro de contenidos para los correos que eliminar el Spam y Virus ClamAV

El antivirus

SpamAssassin La avanzada herramienta antispam Horde El Webmail completo y funcional MailWatch El administrador de trfico de correo y cuarentenas

19.2.2. Cyrus IMAP y SASL Consideracionesiniciales SASL son las siglas de Simple Authentication and Security Layer, un mtodo para aadir soporte para la autenticacin a protocolos basados en la conexin 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 autenticacin de los clientes. Para ello, el protocolo incluye un comando para identificar y autenticar un usuario contra un servidor y para, opcionalmente, negociar la proteccin de las subsiguientes interacciones del protocolo. Si se negocia su uso, una capa de seguridad es aadida entre el protocolo y la conexin. La librera SASL de Cyrus tambin usa la librera OpenSSL para cifrar los datos. El lector encontrar ms informacin en la pgina web de Cyrus SASL. InstalacindeCyrusIMAPySASL 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

ConfiguracindeCyrusSASL La configuracin de Cyrus SASL se centrar principalmente en modificar los parmetros con los que se ejecutar el demonio saslauthd. Especficamente necesitaremos que este demonio use el mecanismo de autenticacin PAM, para lo cual debemos modificar algn fichero de configuracin del servicio correspondiente en cada distribucin Linux. En Debian y derivados el archivo a editar es /etc/default/saslauthd y modificamos la lneas que se mencionan a continuacin: START=YES MECHANISMS="pam"

En Red Hat / CentOS y derivados el archivo a editar es /etc/sysconfig/saslauthd y modificamos la lneas que se mencionan a continuacin: MECH="pam"

Configuracin de Cyrus IMAP La configuracin de Cyrus IMAP es bastante sencilla, en realidad no se requiere modificar nada del fichero de configuracin por defecto que traen las distribuciones Linux pero procederemos a explicar algunas de las directivas que pueden resultar de inters para el lector. configdirectory Permite definir la ruta al directorio de la configuracin IMAP del servicio. En este directorio se almacena informacin 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

defaultpartition Esta directiva permite definir la particin por defecto usada para la creacin de nuevos buzones. El nombre que recibe es definido en una directiva partition-NOMBRE. Es en esta particin donde se almacena el contenido de los buzones de todos los usuarios. Sintaxis : defaultpartition: nombre Ejemplo: defaultpartition: default

partition-NOMBRE Esta directiva permite definir un nombre de particin que apunta a una ruta de directorio dentro del sistema de archivos. Sintaxis : partition-NOMBRE: ruta_directorio Ejemplo: partition-default: /var/spool/imap

unixhierarchysep Esta 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 jerarqua 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 tendrn los mayores privilegios de administrador sobre todos los servicios que ofrezca Cyrus IMAP. Sintaxis : admins: usuario [usuario] [usuario] ... Ejemplo: admins: cyrus

allowplaintext Esta 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_list Esta 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_method Esta directiva permite definir el mtodo que se usar para realizar el proceso de autenticacin. 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 ms seguros como el caso de CRAM-MD5 o DIGEST-MD5 Sintaxis : sasl_pwcheck_method: mtodo Ejemplo: sasl_pwcheck_method: saslauthd

autocreatequota Esta directiva define el valor en KB del tamao de la cuota que ser aplicado automticamente a los buzones recin 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

quotawarn Esta directiva define en qu porcentaje de la cuota de un buzn el sistema Cyrus IMAP empezar a generar advertencias. Sintaxis : quotawarn: porcentaje

Ejemplo: quotawarn: 90

tls_cert_file Esta 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_file Esta 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

Importante: Para que el soporte SSL/TLS de POP3 e IMAP sea activado, se requiere habilitar en el archivo /etc/cyrus.conf las lneas siguientes: imaps pop3s cmd="imapd -s -U 30" listen="imaps" prefork=0 maxchild=100 cmd="pop3d -s -U 30" listen="pop3s" prefork=0 maxchild=50

Estas han sido algunas de las directivas que comnmente requieren ser modificadas respecto a sus valores por defecto. La documentacin completa de todas las dems directivas se pueden encontrar en imapd.conf(5).

Iniciandolosservicios 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 start AdministrandoCyrusIMAP 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 travs 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 parmetro --user debido a que es esa la cuenta que se configur con permisos de administrador en el archivo /etc/imapd.conf. La ejecucin de dicho comando nos preguntar una clave que es la que tiene asignada dicho usuario en el sistema segn /etc/passwd. Una vez que nos autenticamos con la contrasea 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 server chdir, cd change current directory createmailbox, create, cm create mailbox deleteaclmailbox, deleteacl, dam remove ACLs from mailbox deletemailbox, delete, dm delete mailbox disconnect, disc disconnect from current server exit, quit exit cyradm help, ? show commands info display mailbox/server metadata listacl, lam, listaclmailbox list ACLs on mailbox listmailbox, lm list mailboxes listquota, 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 mailbox setinfo set server metadata setquota, sq set quota on mailbox or resource version, ver display version info of current server Algunos comandos los explicamos brevemente por ser los ms usados: lm [patron] Hace un listado de los buzones que coincidan con un patrn opcional expresado como wildcars. Ejemplo: localhost> lm *rios* lam <patron> Muestra los permisos wildcars. Ejemplo: de los buzones que coincidan con un patrn opcional expresado como

localhost> lam user.arios sam <buzon> <usuario> <permisos> Asigna permisos a un buzn determinado. Los permisos existentes son:

l (lookup): el usuario puede ver que el buzn de correo existe r (read): el usuario puede leer el buzn de correo. El usuario puede seleccionar el buzn, leer los datos contenidos, llevar a cabo bsquedas y copiar mensajes de ese buzn s (seen): mantiene el estado ledo 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 buzn de correo p (post): el usuario puede mandar correo a la direccin de envo del buzn. Este permiso difiere del permiso i en que el sistema de envo inserta informacin de seguimiento en los mensajes envados c (create): el usuario puede crear subcarpetas en el buzn d (delete): el usuario puede alterar el flag Deleted, expirar correos y borrar o renombrar el buzn a (administer): el usuario puede cambiar la ACL del buzn all (todos): posee todos los permisos anteriores Ejemplos: localhost> sam user.arios cyrus all localhost> sam user.nposada arengifo lrsdc

cm <buzn> Crea un buzn 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 <buzn> Elimina un buzn. Su uso es similar al comando cm. Ejemplo: localhost> dm user.amendoza localhost> dm user/arengifo lq <buzn> Muestra el estado de la cuota de un buzn especifico. Ejemplo: localhost> lq user.jchavez sq <buzn> [numero] Asigna una cuota en KB a un buzn especfico. Si se omite el tamao de la cuota se asigna ilimitado. 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 Postfix Consideracionesiniciales El MTA (Mail Transportation Agent) Postfix pretende ser rpido, fcil 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 monoltico, sino una combinacin de pequeos programas, cada uno de los cuales lleva a cabo una funcin especializada. En este documento, el lector encontrar la informacin necesaria para tener el sistema funcionando junto a otros componentes que completan la instalacin de un sistema de correo electrnico. Puede encontrarse ms informacin sobre Postfix en la documentacin online de su website. InstalacindePostfix 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

ConfiguracindelMTA La configuracin de Postfix se centra bsicamente 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 autenticacin de usuarios para el servicio SMTP, entre otros. Es por ello que se mostrarn una serie de directivas que suelen ser de las ms comunes a la hora de configurar un servidor de envo y recepcin de correos. mydomain Esta directiva el nombre de dominio asociado al servidor. Su valor puede ser invocado en otras secciones del archivo de configuracin. Sintaxis : mydomain = dominio Ejemplo: mydomain = newdomains.com

myhostname Esta directiva define el nombre del servidor usado para el funcionamiento normal en los dilogos SMTP. Sintaxis : myhostname = nombre_DNS Ejemplos: myhostname = mail.newdomains.com myhostname = mail.$mydomain

mydestination Esta directiva define una lista de dominios que sern aceptados por el servidor como destino final vlido Sintaxis : mydestination = dominio [,dominio] [,dominio] Ejemplo: mydestination = $mydomain, $myhostname, localhost.$mydomain, newdomains.org, newdomains.net

myorigin Esta directiva permite definir el dominio desde el cual se aparenta que se originan los correos enviados a travs del servidor. Sintaxis : myorigin = dominio Ejemplo: myorigin = newdomains.net

mynetworks Esta 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 travs del servidor. Sintaxis : mynetworks = direccion [,direccin] [,direccin] Ejemplo: mynetworks = 127.0.0.0/8, 192.168.1.0/24

alias_maps Esta 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:

alias_maps = hash:/etc/aliases Otros tipos posibles de fuentes adems 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_transport Esta directiva define un agente externo que se encargar de la entrega de los mensajes hacia el buzn correspondiente de los usuarios. Sintaxis : mailbox_transport = aplicacin 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 integracin de Postfix con Cyrus IMAP: mailbox_transport = lmtp:unix:/var/run/cyrus/socket/lmtp

smtpd_sasl_auth_enable Esta directiva permite activar la autenticacin SMTP para los usuarios a la hora de intentar enviar correos a travs del servidor. Sintaxis : smtpd_sasl_auth_enable = yes|no Ejemplo: smtpd_sasl_auth_enable = yes

header_checks Esta 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 an no enviados al buzn de los usuarios. Sintaxis : header_checks = origen En el siguiente ejemplo se le dice a Postfix que cualquier mensaje recibido (saliente o entrante) sea automticamente 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 enve segn 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_limit Esta directiva establece el tamao mximo en bytes que se Postfix permite recibir. Sintaxis : message_size_limit = numero En el ejemplo se define un tamao lmite de 20 MB: message_size_limit 20971520

smtpd_helo_required Esta directiva define si es obligatorio o no que los clientes realicen la fase HELO propia del dilogo SMTP. Muchos spammers omiten este paso mientras que los servidores de correo legtimos casi nunca lo dejan de lado. Sintaxis : smtpd_helo_required = yes|no Ejemplo: smtpd_helo_required = yes

OpenSourceCollege
Primer centro de capacitacin Open Source Linux

www.opensourcecollege.com

Linux for SysAdmins

Pgina 390

smtpd_client_restrictions Esta directiva define una serie de condiciones que debe cumplir un remitente en la fase cliente para poder decidir una accin a tomar. La fase de cliente analiza la naturaleza del origen de su direccin de red (direccin IP, resolucin inversa, etc.). Las condiciones se pueden especificar en una nica lnea o en lneas distintas cada una empezando por al menos un espacio en blanco. El orden de las condiciones segn se especifican es importante pues tienen naturaleza jerrquica. Sintaxis : smtpd_client_restrictions = condicin [,condicin] [,condicin] Algunas de las condiciones vlidas para esta fase cliente son: permit_mynetworks Permite el paso a los clientes que coincidan con $mynetworks permit_sasl_authenticated Permite el paso a los clientes autenticados por SMTP reject_unknown_client Rechaza a los clientes que no cuenten con una resolucin inversa consistente reject_rbl_client RBL Rechaza a los clientes que se encuentren en alguna de las listas negras especificadas En el siguiente ejemplo se considera clientes de confianza a quienes estn definidos en la directiva $mynetworks o se hayan autenticado con un usuario y contrasea vlidos, 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_restrictions Esta directiva define una serie de condiciones que debe cumplir un remitente en la fase HELO para poder decidir una accin a tomar. En tal fase se analiza la conformidad de los parmetros usados en el comando HELO dentro del dilogo SMTP. Las condiciones se pueden especificar en una nica lnea o en lneas distintas cada una empezando por al menos un espacio en blanco. El orden de las condiciones segn se especifican es importante pues tienen naturaleza jerrquica. Sintaxis : smtpd_helo_restrictions = condicin [,condicin] [,condicin] Algunas de las condiciones vlidas para esta fase cliente son: permit_mynetworks Permite el paso a los clientes que coincidan con $mynetworks permit_sasl_authenticated Permite el paso a los clientes autenticados por SMTP reject_non_fqdn_hostname Rechaza a quienes usen un nombre no DNS en el HELO tal como: mail, server01, mailer u otros que carezcan de la seccin host.dominio correspondiente. En Postfix 2.3 en adelante la condicin es reject_non_fqdn_helo_hostname reject_invalid_hostname Rechaza a quienes usen un nombre DNS (host.dominio) pero con valores invlidos tales como: 1mail.domain.com, mail.new_domain.com, smtp.espaa.com u otros que en general no califiquen como un nombre DNS vlido de Internet. En Postfix 2.3 en adelante la condicin es reject_invalid_helo_hostname reject_unknown_hostname Rechaza a quienes usen un nombre DNS vlido pero inexistente en Internet. En Postfix 2.3 en adelante la condicin es reject_unknown_helo_hostname En el siguiente ejemplo se considera clientes de confianza a quienes estn definidos en la directiva $mynetworks o se hayan autenticado con un usuario y contrasea vlidos o usen nombres DNS vlidos en el HELO:

OpenSourceCollege
Primer centro de capacitacin Open Source Linux

www.opensourcecollege.com

Linux for SysAdmins

Pgina 391

smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_hostname, reject_invalid_hostname

smtpd_sender_restrictions Esta directiva define una serie de condiciones que debe cumplir un cliente en la fase remitente para poder decidir una accin a tomar. En tal fase se analiza la conformidad de la direccin de correo usada como remitente en el dilogo SMTP. Las condiciones se pueden especificar en una nica lnea o en lneas distintas cada una empezando por al menos un espacio en blanco. El orden de las condiciones segn se especifican es importante pues tienen naturaleza jerrquica. Sintaxis : smtpd_sender_restrictions = condicin [,condicin] [,condicin] Algunas de las condiciones vlidas para esta fase cliente son: permit_mynetworks Permite el paso a los clientes que coincidan con $mynetworks permit_sasl_authenticated Permite el paso a los clientes autenticados por SMTP reject_non_fqdn_sender Rechaza a quienes usen una forma incorrecta de direccin e-mail como remitente que no cuente con la seccin usuario y dominio respectivo (usuario@dominio). reject_unknown_sender_domain Rechaza a quienes usen una direccin e-mail como remitente de un dominio inexistente. En el siguiente ejemplo se rechazar en cambio a quienes no usen una direccin vlida y en un dominio existente como e-mail remitente: smtpd_sender_restrictions = reject_non_fqdn_sender, reject_unknown_sender_domain

smtpd_recipient_restrictions Esta directiva define una serie de condiciones que debe cumplir un cliente en la fase del destinatario para poder decidir una accin a tomar. En tal fase se analiza la conformidad de la direccin de correo usada como destinatario en el dilogo SMTP. Las condiciones se pueden especificar en una nica lnea o en lneas distintas cada una empezando por al menos un espacio en blanco. El orden de las condiciones segn se especifican es importante pues tienen naturaleza jerrquica. 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 deberan faltar las restricciones mnimas. Sintaxis : smtpd_recipient_restrictions = condicin [,condicin] [,condicin] Algunas de las condiciones vlidas para esta fase cliente son: permit_mynetworks Permite el paso a los clientes que coincidan con $mynetworks permit_sasl_authenticated Permite el paso a los clientes autenticados por SMTP reject_non_fqdn_recipient Rechaza a quienes usen una forma incorrecta de direccin e-mail como destinatario que no cuente con la seccin usuario y dominio respectivo (usuario@dominio) reject_unknown_recipient_domain Rechaza a quienes usen una direccin e-mail como destinatario de un dominio inexistente. reject_unauth_destination Rechaza a quienes intenten enviar correo a alguna direccin externa, es decir a un dominio no

OpenSourceCollege
Primer centro de capacitacin Open Source Linux

www.opensourcecollege.com

Linux for SysAdmins

Pgina 392

servido por Postfix En el siguiente ejemplo se rechazar en cambio a quienes no usen una direccin vlida 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 travs 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_tls Esta directiva habilita el soporte opcional de TLS/SSL para la comunicacin con los clientes. Esto quiere decir que el usuario puede elegir entre usar o no TLS/SSL para la comunicacin entera con el servidor. Sintaxis : smtpd_use_tls = yes|no Ejemplo: smtpd_use_tls = yes smtpd_tls_auth_only Cuando el soporte de TLS/SSL es opcional (ver directiva anterior) esta directiva permite controlar si se acepta o no la autenticacin 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_file Esta 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_file Esta 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

PostfixyCyrusSASL Una vez editado el archivo de configuracin /etc/postfix/main.cf debe generarse un archivo adicional de configuracin el cual asociar Postfix con el demonio saslauthd para las tareas de autenticacin de los clientes en el momento de querer enviar correos a travs del servidor. El archivo de nombre smtpd.conf por lo general debe ser creado en el directorio /usr/lib/sasl2 pero en algunas distribuciones como Debian esto difiere siendo para este caso especfico el directorio /etc/postfix/sasl. El contenido del archivo debe ser como sigue: pwcheck_method: saslauthd mech_list: PLAIN LOGIN

OpenSourceCollege
Primer centro de capacitacin Open Source Linux

www.opensourcecollege.com

Linux for SysAdmins

Pgina 393

loglevel: 3

Estas lneas de configuracin le dice a Postfix que los mecanismos vlidos a aceptar de los clientes son PLAIN y LOGIN a travs del mtodo saslauthd que representa al demonio del mismo nombre. Definitivamente estas no son todas las directivas de configuracin de Postfix ni mucho menos, pero la documentacin sobre la gran mayora de ellas puede ser encontrada en postconf(5) a donde el lector debera dirigirse a fin de complementar el estudio de algunas caractersticas especficas de su inters no cubiertas en este documento.

AdministracindePostfix A continuacin 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 configuracin una vez que se encuentra en marcha. Para ello nos basaremos en el comando postfix el cual recibe algunos parmetros como los descritos a continuacin:
check Comprueba la conformidad de los permisos y propietarios de ciertos archivos/directorios as como tambin su existencia start Inicia el MTA con un previo chequeo igual que el descrito arriba stop Detiene el MTA de manera correcta y ordenada abort Detiene el MTA de manera abrupta e inmediata reload Relee su archivo de configuracin haciendo efectivo los cambios del mismo flush Intenta 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 configuracin: # postfix check # postfix reload postfix/postfix-script: refreshing the Postfix mail system Informacin adicional sobre este comando puede ser encontrado en postfix(1). Si el estado del MTA es correcto respecto a su configuracin y entorno de trabajo con archivos y directorios no est de ms 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 sunilb@ajantapharma.com (host mail.newdomains.com[/var/run/cyrus/socket/lmtp] said: 452 4.2.2 Over quota (in reply to RCPT TO command)) info@newdomains.com 48F0A67D06C 1300 Sat Sep 1 07:54:00 giveitup39090@ingraham.org (host mail.newdomains.com[/var/run/cyrus/socket/lmtp] said: 452 4.2.2 Over quota (in reply to RCPT TO command)) tcastro@newdomains.com C105D67D066 1379 Sat Sep 1 02:52:43 ootakei@kmc-usa.com (host mail.newdomains.com[/var/run/cyrus/socket/lmtp] said: 452 4.2.2 Over quota (in reply to RCPT TO command)) ellanos@newdomains.com -- 20 Kbytes in 3 Requests.

OpenSourceCollege
Primer centro de capacitacin Open Source Linux

www.opensourcecollege.com

Linux for SysAdmins

Pgina 394

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 sera 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 permitirn crear distintos nombres para uno o ms buzones en particular as como crear grupos simples de distribucin. 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 buzn 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: root mailer-daemon: root hostmaster: root webmaster: root noc: root En el ejemplo anterior se crean alias individuales destinados cada uno al usuario root solamente. Pero tambin es posible crear grupos que se asemejen a listas de distribucin en el cual un alias permitir enviar una copia del mensaje a ms 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 versin indexada del mismo el cual ser el que Postfix use en realidad por motivos de mejor desempeo. Este archivo indexado por lo general ser "/etc/aliases.db" y se actualiza con cualquiera de los dos comandos mostrados a continuacin: # 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 administracin 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 distribucin Linux con la que se trabaje, el cual debe ser constantemente vigilado como sigue: # tail -f /var/log/mail.log

OpenSourceCollege
Primer centro de capacitacin Open Source Linux

www.opensourcecollege.com

Linux for SysAdmins

Pgina 395

19.3. Filtro de contenidos, Antispam, Antivirus

Componentes necesarios La configuracin de un servidor de mensajera no sera 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 algn virus o los que contengan algn tipo de publicidad no solicitada comnmente conocido como Spam. Es por ello que se requiere la instalacin 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 y SpamAssassin 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 anlisis, pudiendo luego opcionalmente tomar acciones como eliminar el mensaje, enviarlo a una cuarentena o enviarlo al destinatario final. Respecto a ClamAV podemos agregar nada ms que nos basaremos en su configuracin por defecto y debemos asegurarnos que su demonio respectivo se encuentre iniciado.

19.3.1. Filtro de contenidos MailScanner InstalacindeMailScanner MailScanner puede ser descargado desde su Web oficial: http://www.mailscanner.info En este en la seccin Downloads existen paquetes para distribuciones Red Hat, SuSE y derivados. Todos estos paquetes son un tarball 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 instalacin y configuracin predeterminada de MailScanner en el sistema, colocando normalmente los binarios y otras libreras debajo de /usr y la configuracin debajo de /etc/MailScanner. Sin embargo si descarg el paquete MailScanner de la versin "Solaris / BSD / Other Linux / Other Unix" se tendr que la instalacin 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 instalacin. ConfigurandoMailScanner El archivo de configuracin por defecto suele ser ubicado en /etc/MailScanner/MailScanner.conf. A continuacin la descripcin de directivas de MailScanner: %org-name% Esta directiva define simplemente un nombre de la organizacin 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 organizacin 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%

OpenSourceCollege
Primer centro de capacitacin Open Source Linux

www.opensourcecollege.com

Linux for SysAdmins

Pgina 396

Esta directiva define el sitio Web de la organizacin, el mismo que se muestra junto con el nombre largo de la organizacin 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 User Run As Group Estas directivas definen el usuario y grupo bajo el cual se ejecutar MailScanner. Sintaxis : Run As User = usuario Sintaxis : Run As Group = grupo Ejemplo: Run As User = postfix Run As Group = mail

Incoming Queue Dir Esta directiva define la ruta del directorio de donde MailScanner recoger los correos para su posterior anlisis. Considrese que debe asignarse la ruta del directorio de la cola hold de Postfix dado que ste colocar ah cada correo recibido segn la configuracin 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 Dir Esta directiva define la ruta del directorio donde MailScanner colocar los correos ya analizados. Considrese 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 envo correspondiente. Sintaxis : Outgoing Queue Dir = ruta_directorio Ejemplo: Outgoing Queue Dir = /var/spool/postfix/incoming

Incoming Work Dir Esta directiva define la ruta del directorio donde MailScanner temporalmente desempaqueter los correos durante su proceso de anlisis. Sintaxis : Incoming Work Dir = ruta_directorio Ejemplo:

OpenSourceCollege
Primer centro de capacitacin Open Source Linux

www.opensourcecollege.com

Linux for SysAdmins

Pgina 397

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

Quarantine Dir Esta directiva define la ruta del directorio de la cuarentena de MailScanner. Sintaxis : Quarantine Dir = ruta_directorio Ejemplo: Quarantine Dir = /var/spool/MailScanner/quarantine

MTA Esta directiva define cul 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 Permissions Esta directiva define los propietarios y permisos del directorio de trabajo de MailScanner definido en Incoming Work Dir. Sintaxis : Incoming Work User = usuario Sintaxis : Incoming Work Group = grupo Sintaxis : Incoming Work Permissions = permisos Ejemplo: Incoming Work User = postfix Incoming Work Group = mail Incoming Work Permissions = 0660

Quarantine User Quarantine Group Quarantine Permissions Esta directiva define los propietarios y permisos del directorio de la cuarentena de MailScanner definido en Quarantine Dir. Sintaxis : Quarantine User = usuario Sintaxis : Quarantine Group = grupo Sintaxis : Quarantine Permissions = permisos A fin de que ms adelante MailWatch que es ejecutado a travs de Apache sea capaz de modificar los archivos de la cuarentena se asigna el grupo de ejecucin 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 Scanning Esta directiva define si se analizarn o no los correos con un antivirus externo. Sintaxis : Virus Scanning = yes|no Ejemplo:

OpenSourceCollege
Primer centro de capacitacin Open Source Linux

www.opensourcecollege.com

Linux for SysAdmins

Pgina 398

Virus Scanning = yes

Virus Scanners Esta directiva define el antivirus externo a usar. Algunos valores posibles vlidos son clamav, sophos, mcafee, etrust, panda, trend antivir, entre otros. Sintaxis : Virus Scanners = nombre Ejemplo: Virus Scanners = clamav

Allow Filenames Deny Filenames Esta 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 = regexp Sintaxis : Deny Filenames = regexp Ejemplo: Deny Filenames = \.exe \.pif \.bat \.scr

Filename Rules Esta directiva define la ruta de un archivo donde se establecern 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 accin a tomar ( allow o deny), el segundo una expresin 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 Infections Esta directiva decide si se enviarn a cuarentena o no los correos que contengan archivos infectados. Sintaxis : Quarantine Infections = yes|no Ejemplo: Quarantine Infections = yes

Spam Checks Esta directiva decide si se buscar o no Spam en los mensajes. Sintaxis : Spam Checks = yes|no Ejemplo: Spam Checks = yes

OpenSourceCollege
Primer centro de capacitacin Open Source Linux

www.opensourcecollege.com

Linux for SysAdmins

Pgina 399

Spam List Esta 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 estn 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 List Esta 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 estn 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-IGNORANTBOGUSMX

Spam Lists To Be Spam Esta 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 Score Esta 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 SpamAssassin Esta directiva define si se usar o no a SpamAssassin como herramienta de deteccin de Spam. Sintaxis : Use SpamAssassin = yes|no Ejemplo: Use SpamAssassin = yes

Required SpamAssassin Score Esta directiva define el puntaje mnimo que debe tener un mensaje segn la calificacin de SpamAssassin para que sea considerado Spam de nivel moderado. Sintaxis : Required SpamAssassin Score = numero Ejemplo: Required SpamAssassin Score = 5

High SpamAssassin Score Esta directiva define el puntaje mnimo que debe tener un mensaje segn la calificacin de SpamAssassin para que sea considerado Spam de nivel alto. Sintaxis : High SpamAssassin Score = nmero Ejemplo: High SpamAssassin Score = 10

Max SpamAssassin Size Max Spam Check Size Estas directivas definen el tamao mximo que debe tener un mensaje para que pueda ser analizado en busca de Spam por SpamAssassin y MailScanner respectivamente. Normalmente SpamAsassin no tiene un rendimiento nada ptimo analizando mensajes grandes, quizs ms all de los 300 KB de tamao. Muchos spammers han aprendido esto y saben que generando mensajes de gran tamao (300 KB a ms) lograrn que stos no sean analizados llegando as con ms probabilidad a la bandeja de entrada del usuario. Sin embargo MailScanner requerir analizar slo parte de un mensaje para saber si es spam o no (Ejm: analizar slo los primeros 200 KB) sin afectar el rendimiento de SpamAsassin. Por esta razn se recomienda que el lmite de tamao que puede analizar MailScanner sea un valor alto, alrededor de 1 MB o ms dependiendo del tamao de los mensajes de spam que reciba frecuentemente, mientras que el tamao mximo de mensajes analizados por SpamAssassin se mantenga bajo o en sus valores predeterminados. Sintaxis : Max SpamAssassin Size = tamao Sintaxis : Max Spam Check Size = tamao Ejemplo: Max SpamAssassin Size = 200k Max Spam Check Size = 1000k

Spam Actions Esta directiva define la accin a tomar cuando se detecte Spam moderado en un mensaje. Sintaxis : Spam Actions = accin Algunas de las posibles acciones a tomar son: deliver Entrega el mensaje a su destinatario de manera normal delete Elimina el mensaje store Almacena una copia del mensaje en la cuarentena bounce Envia un mensaje de rechazo al remitente forward usuario@dominio Reenva 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 vlidos son los siguientes: Spam Actions = forward admin@newdomains.com Spam Actions = deliver header "X-Spam-Status: Yes"

High Scoring Spam Actions Esta directiva define la accin 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 nmero de opciones disponibles para cambiar a nuestro gusto pero todas las directivas se encuentran muy bien documentadas en su archivo de configuracin por lo que resultar bastante sencillo al lector entenderlas. 19.3.2. Analizador de Spam SpamAssassin InstalacindeSpamAssassin SpamAssassin est incluido en los repositorios de las principales distribuciones Linux. El procedimiento de instalacin 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

AjustesbsicosdeSpamAssassin Una vez configurado MailScanner sera importante hacer algunos ajustes a un archivo de configuracin de SpamAssassin identificado como /etc/MailScanner/spam.assassin.prefs.conf segn las directivas que se mencionan a continuacin: ok_languages ok_locales Esta directiva define la codificacin 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 codificacin de caracteres que no son propios de nuestra lengua. Sintaxis : ok_languages cdigo [cdigo] [cdigo] ... Sintaxis : ok_locales cdigo [cdigo] [cdigo] ... Ejemplo: ok_languages es en ok_locales es en

use_bayes Esta directiva permite activar el motor Bayesiano que en base a mtodos estadsticos clasificar los mensajes como Spam. Sintaxis : use_bayes 0|1 Ejemplo: use_bayes 1

bayes_auto_learn Esta directiva permite que SpamAssassin aprenda de manera automticamente cuando un mensaje es o no Spam en base a las estadsticas bayesianas. Sintaxis : bayes_auto_learn 0|1 Ejemplo: bayes_auto_learn 1

bayes_path Esta directiva define el prefijo de los archivos de Bayes que se crearn durante el tiempo de funcionamiento. Sintaxis : bayes_path ruta_directorio/prefijo

En el siguiente ejemplo se crearn 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_mode Esta directiva define los permisos de los archivos de Bayes. Sintaxis : bayes_file_mode permisos Ejemplo: bayes_file_mode 0660

PluginsdeSpamAssassin SpamAssassin es capaz de extender la funcionalidad que por defecto incluye a travs del uso de plugins, los mismos que pueden ser activados (los que vienen por defecto con SpamAssassin) o descargados algn sitio Web publicado por terceros. En la Web de SpamAssassin se puede encontrar una lista de plugins personalizados de diferentes licencias (gratuitos, licencia Apache, comerciales de pago, etc), bajo la siguiente URL: http://wiki.apache.org/spamassassin/CustomPlugins Estos plugins tras ser descargados, deben ser colocados en el directorio /etc/mail/spamassassin. Los plugins por lo general sern archivos de extensin .pm y sus directivas de configuracin se guardan en archivos de extensin .cf. Es recomendable habilitar algunos plugins:

TextCat : Habilita la identificacin 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 lnea loadplugin Mail::SpamAssassin::Plugin::TextCat en el archivo /etc/mail/spamassassin/v310.pre. SPF : Habilita la validacin SPF de los dominios de los remitentes. Para habilitarlo se debe descomentar la lnea loadplugin Mail::SpamAssassin::Plugin::SPF en el archivo /etc/mail/spamassassin/init.pre. DCC : Habilita el anlisis de mensajes en base a clculos checksum (sumas de verificacin) desde la base de datos DCC. Para habilitarlo se debe descomentar la lnea loadplugin Mail::SpamAssassin::Plugin::DCC en el archivo /etc/mail/spamassassin/v310.pre. DCC se puede obtener descargar desde http://www.rhyolite.com/dcc/ 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::DCC dcc_path /usr/local/bin/dccproc endif

Razor2 : Habilita el anlisis de mensajes en base a clculos checksum (sumas de verificacin) desde la base de datos Razor. Para habilitarlo se debe descomentar la lnea loadplugin Mail::SpamAssassin::Plugin::Razor2 en el archivo /etc/mail/spamassassin/v310.pre. Razor2 se puede obtener descargar desde http://razor.sourceforge.net/ y tras ser compilado e instalado, se debe definir en el archivo /etc/MailScanner/spam.assassin.prefs.conf la ruta de configuracin de razor como sigue: use_razor2 razor_config 1 /var/spool/MailScanner/spamassassin/razor/razor-agent.conf

Razor2 debe crear el archivo de configuracin 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 anlisis de los remitentes de correo para evaluar si provienen desde direcciones IP pblicas fijas o dinmicas (conexiones caseras del tipo ADSL o Diaulp).

Este plugin debe ser descargado desde el sitio Web de Spamassassin donde se publican los plugins personalizados (link lneas 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), anlisis de spam en imgenes (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 mdulos de Perl no instalados y requeridos como dependencia: [15810] [15810] [15810] [15810] [15810] [15810] [15810] [15810] [15810] [15810] [15810] [15810] dbg: dbg: dbg: dbg: dbg: dbg: dbg: dbg: dbg: dbg: dbg: dbg: diag: diag: diag: diag: diag: diag: diag: diag: diag: diag: diag: diag: module module module module module module module module module module module module installed: Net::SMTP, version 2.31 installed: Mail::SPF, version v2.005 not installed: Mail::SPF::Query ('require' failed) not installed: IP::Country::Fast ('require' failed) not installed: Net::Ident ('require' failed) installed: IO::Socket::INET6, version 2.54 not installed: IO::Socket::SSL ('require' failed) installed: Compress::Zlib, version 2.008 installed: Time::HiRes, version 1.9711 not installed: Mail::DomainKeys ('require' failed) not installed: Mail::DKIM ('require' failed) installed: DBI, version 1.607

En el ejemplo arriba mostrado se puede apreciar que los siguientes mdulos no estn instalados:

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

Estos mdulos pueden ser descargados desde: http://search.cpan.org Donde podremos utilizar el buscador para cada uno de los mdulos con palabras clave como 'Mail SPF Query', 'IP Country Fast', 'Net Ident' y as con el resto. Cada uno de estos mdulos 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 atencin la salida del comando perl Makefile.PL ya que ste puede advertir de la ausencia de otros mdulos de Perl que son necesarios tener instalados antes de la compilacin del mdulo de nuestro inters. 19.3.3. Antivirus ClamAV 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 (http://dag.wieers.com) y ejecutar desde la lnea 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 (http://www.clamav.net) los instaladores para la distribucin Linux que tengamos e

instalar los paquetes de manera individual: # rpm -ivh clam*.rpm

19.3.4. Pruebas de funcionamiento Finalmente cuando ya se ha culminado con la configuracin 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 -tnlp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address tcp 0 0 0.0.0.0:110 tcp 0 0 0.0.0.0:143 tcp 0 0 127.0.0.1:2000 tcp 0 0 0.0.0.0:25

Foreign Address 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* 0.0.0.0:*

State LISTEN LISTEN LISTEN LISTEN

Luego empezaremos a probar un dilogo SMTP con el servidor para enviarle un mensaje sencillo desde comandos telnet: # telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mail.newdomains.com ESMTP HELO gsmtp163.google.com 250 mail.newdomains.com MAIL FROM: <angelrengifo@gmail.com> 250 2.1.0 Ok RCPT TO: <postmaster@newdomains.com> 250 2.1.5 Ok DATA 354 End data with <CR><LF>.<CR><LF> Mensaje de Prueba . 250 2.0.0 Ok: queued as CD4A267D083 QUIT 221 2.0.0 Bye Connection closed by foreign host. Luego de eso debera haber entrado un nuevo mensaje en la cola de Postfix y ste pasarlo luego a MailScanner. Veamos algunas lneas 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 id 077FA67D087??for <postmaster@newdomains.com>; Sun, 2 Sep 2007 18:37:53 -0500 (PET) from localhost[127.0.0.1]; from=<angelrengifo@gmail.com> to=<postmaster@newdomains.com> proto=SMTP helo=<gsmtp163.google.com> Sep 2 18:38:06 localhost postfix/cleanup[17792]: 077FA67D087: messageid=<20070902233801.077FA67D087@mail.newdomains.com> Sep 2 18:38:06 localhost MailScanner[16132]: New Batch: Scanning 1 messages, 947 bytes Sep 2 18:38:06 localhost MailScanner[16132]: Spam Checks: Starting Sep 2 18:38:06 localhost MailScanner[16132]: Whitelist refresh time reached Sep 2 18:38:06 localhost MailScanner[16132]: Starting up SQL Whitelist Sep 2 18:38:06 localhost MailScanner[16132]: Read 0 whitelist entries Sep 2 18:38:06 localhost MailScanner[16132]: Blacklist refresh time reached Sep 2 18:38:06 localhost MailScanner[16132]: Starting up SQL Blacklist Sep 2 18:38:06 localhost MailScanner[16132]: Read 0 blacklist entries Sep 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: Starting Sep 2 18:38:10 localhost MailScanner[16132]: Requeue: 077FA67D087.0D0E9 to 0BD5867D088 Sep 2 18:38:10 localhost postfix/qmgr[8320]: 0BD5867D088: from=<angelrengifo@gmail.com>, size=502, nrcpt=1 (queue active) Sep 2 18:38:10 localhost MailScanner[16132]: Uninfected: Delivered 1 messages Sep 2 18:38:10 localhost MailScanner[16132]: Logging message 077FA67D087.0D0E9 to SQL Sep 2 18:38:10 localhost MailScanner[16132]: Config: calling custom end function SQLBlacklist Sep 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 function MailWatchLogging Sep 2 18:38:10 localhost MailScanner[16132]: Config: calling custom end function SQLWhitelist Sep 2 18:38:10 localhost MailScanner[16132]: Closing down by-domain spam whitelist Sep 2 18:38:10 localhost MailScanner[16132]: MailScanner child dying of old age Sep 2 18:38:10 localhost cyrus/master[17799]: about to exec /usr/lib/cyrus/bin/lmtpd Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: executed Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: accepted connection Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: lmtp connection preauth'd as postman Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: duplicate_check: <20070902233801.077FA67D087@mail.newdomains.com> user.root 0 Sep 2 18:38:10 localhost MailScanner[17800]: MailScanner E-Mail Virus Scanner version 4.55.10 starting... Sep 2 18:38:10 localhost MailScanner[17800]: Read 748 hostnames from the phishing whitelist Sep 2 18:38:10 localhost MailScanner[17800]: Config: calling custom init function SQLBlacklist Sep 2 18:38:10 localhost MailScanner[17800]: Starting up SQL Blacklist Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: duplicate_check: <20070902233801.077FA67D087@mail.newdomains.com> user.root 0 Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: mystore: starting txn 2147485203 Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: mystore: committing txn 2147485203 Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: duplicate_mark: <20070902233801.077FA67D087@mail.newdomains.com> user.root 1188776290 47597596182714 Sep 2 18:38:10 localhost MailScanner[17800]: Read 0 blacklist entries Sep 2 18:38:10 localhost MailScanner[17800]: Config: calling custom init function MailWatchLogging Sep 2 18:38:10 localhost MailScanner[17800]: Started SQL Logging child Sep 2 18:38:10 localhost MailScanner[17800]: Config: calling custom init function SQLWhitelist Sep 2 18:38:10 localhost MailScanner[17800]: Starting up SQL Whitelist Sep 2 18:38:10 localhost MailScanner[17800]: Read 0 whitelist entries Sep 2 18:38:10 localhost MailScanner[17800]: Using SpamAssassin results cache Sep 2 18:38:10 localhost MailScanner[17800]: Connected to SpamAssassin cache database Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: Delivered: <20070902233801.077FA67D087@mail.newdomains.com> to mailbox: user.root Sep 2 18:38:10 localhost postfix/lmtp[17798]: 0BD5867D088: to=<root@newdomains.com>, orig_to=<postmaster@newdomains.com>, 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: removed Sep 2 18:38:10 localhost MailScanner[17800]: Enabling SpamAssassin auto-whitelist functionality... Sep 2 18:38:11 localhost MailScanner[17800]: Using locktype = flock En medio de la gran cantidad de lneas puede apreciarse cual es el remitente (MAIL FROM) y el destinatario (RCPT TO), as como tambin 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 lnea de comandos con el mismo resultado que el anterior es como sigue: # echo "Mensaje de prueba" | sendmail -f angelrengifo@gmail.com -t postmaster@consultorianet.com Finalmente podemos probar el correcto funcionamiento de la autenticacin y el servicio IMAP como sigue:
# telnet localhost 143 Trying 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 Completed Connection 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 como MailScanner trabajando en conjunto con SpamAssassin y ClamAV.