postfix

Instalación y mantenimiento de Servicios de Internet CFGM “Explotación de sistemas informáticos” IES “Inca Gracilazo” Montilla

Ángel Delgado Herrador 1

Tema 6: Correo en linux. Correo SMTP

• SMTP: Simple Mail Transfer Protocol • Es el protocolo estándar para transferir correo entre ordenadores, y está definido en el RFC

821. • Ha sido el más utilizado de los protocolos de la familia TCP/IP • SMTP normaliza el conjunto de caracteres del mensaje al conjunto ASCII de 7 bits. • El correo lo crea un agente de correo en la máquina del usuario, y cada mensaje consta de

una cabecera (que incluye la dirección o direcciones de correo electrónico del destino) y un cuerpo (que contiene el mensaje a enviar)

• Los mensajes pasan a una cola de espera, que es la entrada al Emisor SMTP, y los transmite al computador destino vía transacciones SMTP.

• El protocolo SMTP se limita al diálogo entre el Emisor SMTP y el Receptor SMTP. • Un ordenador puede tener múltiples Emisores SMTP activos simultáneamente si tiene gran

cantidad de correo de salida, y también tiene la capacidad de crear Receptores SMTP si hay una gran cantidad de correo de entrada

• El Emisor SMTP debe prever varios errores (que el ordenador destino sea inalcanzable, que esté desconectado, que la conexión TCP falle durante la transferencia, etc.)

• SMTP intenta proporcionar un funcionamiento seguro, pero no garantiza recuperar los mensajes perdidos

• No devuelve confirmación extremo-a-extremo al que origina un mensaje indicando la entrega con éxito, y tampoco se garantiza una indicación de error

• El Emisor SMTP es responsable del mensaje hasta el instante en que el Receptor SMTP indica que la transferencia se ha completado

• Esto sólo significa que el mensaje ha llegado hasta ahí, pero no que ha sido entregado y leído por el destinatario

• El Receptor SMTP acepta cada mensaje que llega y lo sitúa en el buzón de correo del usuario correspondiente

• En la mayoría de los casos, los mensajes van directamente desde la máquina que origina el mensaje hasta la máquina destino a través de una única conexión TCP



Arquitectura de Postfix

Los procesos que conforman Postfix se comunican a través de sockets que se crean, por razones de seguridad, en un directorio de acceso restringido. La información que intercambian los diversos procesos es la mínima posible, limitándose en la mayoría de los casos a la referencia de la entrada en una cola y la relación de destinatarios, o a un simple identificador de estado.

La siguiente figura proporciona una visión global de los elementos que componen Postfix:

Postfix basa su funcionamiento en cuatro colas: maildrop, incoming, active y deferred

(cuadrados coloreados en verde). Maildrop queue. El correo que es entregado localmente en el sistema es aceptado por la

cola Maildrop. El correo se chequea para formatearlo apropiadamente antes de ser entregado a la cola Incoming.

Incoming queue. Esta cola recibe correo de otros hosts, clientes o de la cola Maildrop. Mientras sigue llegando correo y Postfix no puede manejarlo, en esta cola se quedan los correos.

Active queue. Es la cola utilizada para entregar los mensajes. La Active queue tiene un tamaño limitado, y los mensajes solamente serán aceptados si hay espacio en ella. Esto quiere decir que las colas Incoming y Deferred tienen que esperar hasta que la cola Active pueda aceptar más mensajes.

El correo que se genera de forma local se deposita en maildrop para su posterior proceso. El proceso pickup toma los mensajes que llegan a maildrop y los pasa a cleanup, que analiza las cabeceras de los mensajes y deposita éstos en la cola incoming.

En la cola active se encuentran aquellos mensajes que están en fase de encaminamiento, y en deferred los mensajes que por diversas causas no se pueden encaminar o están pendientes de reintentar su encaminamiento.

El proceso qmgr es el encargado de tratar los mensajes que llegan a la cola incoming, depositarlos en active y lanzar el proceso adecuado para su encaminamiento, como pueden ser local, smtp o pipe.

El correo procedente de otros sistemas se atiende a través del proceso smtpd, utilizando el protocolo SMTP, pudiendo utilizar accesos a servidores de RBL o tablas internas para aplicar las políticas de acceso a cada mensaje entrante.

Coloreadas de azul aparecen las tablas que, creadas por el administrador, sirven a los diferentes procesos para concretar el tratamiento que debe darse a cada mensaje. Se usan seis tablas: access, aliases, canonical, relocated, transport y virtual. Aunque no es obligatoria la existencia ni utilización de todas ellas.

La tabla access permite definir una relación explícita de sistemas a los que se les deben aceptar o rechazar sus mensajes. La utiliza el proceso smptd.

La tabla aliases, al igual que en Sendmail, define una serie de nombres alternativos a usuarios locales, y la consulta el proceso local.

El proceso cleanup, mediante la tabla canonical establece relaciones entre nombres



alternativos y nombres reales, ya sean usuarios locales o no. El proceso qmgr utiliza la tabla relocated para devolver los mensajes de usuarios que han

cambiado de dirección: “User has moved to new-email”. Con la tabla transport, que es utilizada por el proceso trivial-rewrite, se define la política de

encaminamiento por dominios, subdominios e incluso por dirección concreta de usuario. Para la gestión y soporte de dominios virtuales el proceso cleanup utiliza la tabla virtual. En

ella se establecen las relaciones entre usuarios virtuales y reales, e incluso de dominios completos. Todas estas tablas pueden usar alguno de los siguientes tipos de formato de base de datos:

- Fichero binario indexado (btree, hash, dbm, etc). - Fichero de texto basado en expresiones regulares ( regexp). - Sistema externo de base de datos (NIS, LDAP, MySQL, etc).

Para conocer qué tipos de formato de base de datos soporta nuestra instalación, se puede

usar la directiva /usr/sbin/postconf –m Para indicar a Postfix el método de acceso a un determinado fichero se antepone al nombre

del mismo el método de acceso. Así por ejemplo hash:/etc/postfix/tabla indica que /etc/postfix/tabla es un fichero en formato db.

Para crear los ficheros binarios indexados, Postfix dispone de la directiva: postmap. Por ejemplo, para generar el correspondiente binario del fichero anterior se usaría la directiva postmap /etc/postfix/tabla, con lo que se crearía el fichero /etc/postfix/tabla.db .

En el caso particular de la tabla aliases, existe la directiva /usr/sbin/newaliases . Los ficheros que contienen expresiones regulares se tratan directamente desde Postfix

(regexpr).

Arranque o parada del servicio

• Antes de arrancar se puede ver si el fichero de configuración está correcto:

/etc/rc.d/init.d/postfix check

• Posteriormente iniciamos el fichero con la opción start o restart. /etc/rc.d/init.d/postfix {start | stop | restart | reload | status | ...}

o bien

service postfix {start | stop | restart | reload | status | ...}

• Para activar postfix cuando arranque linux en el runlevel 3, 4 y 5 ejecutamos

chkconfig postfix on

Comandos SMTP • El funcionamiento de SMTP se lleva a cabo por medio de una serie de comandos



intercambiados entre emisor y receptor • La iniciativa la lleva el Emisor SMTP, que establece la conexión TCP, y tras esto envía órdenes

a través de la conexión • Cada orden genera exactamente una respuesta del Receptor SMTP • Una orden consta de una única línea de texto , y comienza con un código de orden de 4 letras ,

seguida a veces por un campo de argumentos • La mayoría de las respuestas son también de una única línea, y comienza con un código de 3

dígitos que puede ir seguido de información adicional • El primer dígito indica la categoría de la respuesta • Respuesta de finalización afirmativa : acción completada satisfactoriamente • Repuesta intermedia positiva : orden aceptada, pero acción suspendida y pendiente de recibir

más información • Respuesta de finalización negativa transitoria : orden no aceptada y acción no realizada (pero se

puede solicitar de nuevo) • Respuesta de finalización negativa permanente : ídem, pero sin solicitar otra • Comandos cliente MTA y servidor MTA

#telnet ipservidor 25 HELO servername MAIL FROM: correo_del_enviador RCPT TO: dirección_destino DATA xxxxxx (datos a enviar) . (final de los datos es un punto) QUIT

Fase de Establecimiento : − El Emisor abre una conexión TCP con el Receptor − El Receptor se identifica a sí mismo con “220 Service Ready” − El Emisor se identifica a sí mismo con la orden HELO



− El Receptor acepta la identificación del Emisor con “250 OK” − Si el servicio de correo no está disponible en el destino, el computador de destino

devuelve “421 Service Not Available”

Fase de Transferencia de Correo : − Una orden MAIL identifica el que originó el mensaje. Si el receptor está preparado

devuelve “250 OK” ; en caso contrario, un código de error − La orden RCPT identifica los destinatarios del mensaje, y el receptor devuelve una

respuesta por cada orden RCPT − La orden DATA inicia la transferencia del mensaje

Fase de Cierre : − El Emisor envía QUIT , e inicia el cierre TCP − El Receptor responde a QUIT, e inicia el cierre TCP

Respuestas servidor MTA a Cliente MTA 220 Recipient server is Ready 221 Recipient server is closing TCP connection 250 Command carried out successfully 354 Indicates the recipient server is ready to receive message 421 Service request declined Error responses:

450 Mailbox unavailable . . .



551 Addressed user is not here

Transferencia de ficheros binarios (MIME).

• No puede transferir ficheros ejecutables u otros objetos binarios • Se utilizan una serie de esquemas para convertir ficheros binarios a formato texto (ej:

UUencode/UUdecode), pero ninguno es estándar • No puede transferir ficheros de texto que incluyan caracteres de códigos de ocho bits (sólo

estará limitado a siete) • Los servidores SMTP pueden rechazar mensajes de correo a partir de un cierto tamaño • Las pasarelas SMTP que traducen de ASCII a EBCDIC no utilizan un conjunto consistente de

correspondencias, lo que da lugar a problemas de traducción • MIME (Ampliación de Correo Internet Multiobjetivo) está pensado para solventar estos

problemas Configuración del DNS

Para que funcione correctamente el servicio de correo electrónico debemos configurar el servidor DNS indicando el intercambiador de correo (servidor que gestiona el correo del dominio) e indicar la resolución inversa de dicho servidor.

El intercambiador de correo no debe ser un alias sino un host. Por ejemplo para el dominio “casa.edu” cuyos hosts se encuentran en la red 172.26.0.0/24

debemos configurar el fichero /etc/named.conf incluyendo la zona directa e inversa: zone "inca.edu" IN { type master;



file "inca.edu.zone"; allow-update { none; }; }; zone "0.26.172.in-addr.arpa" IN { type master; file "inversa.zone"; allow-update { none; }; };

El fichero inca.edu.zone que define la zona directa se creará en el directorio /var/named/chroot/var/named: $TTL 86400 @ IN SOA ns1.inca.edu. root.inca.edu. ( 2005103001 ; serial 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum IN NS ns1 IN A 172.26.0.2 IN MX 10 smtp.inca.edu. IN MX 20 smtp2.inca.edu. ns1 IN A 172.26.0.2 smtp IN A 172.26.0.5 smtp2 IN A 172.26.0.6 correo IN CNAME smtp pop3 IN CNAME smtp imap IN CNAME smtp correo2 IN CNAME smtp2

En este ejemplo se definen dos intercambiadores de correo para el dominio “inca.edu” utilizando el registro MX, uno en la máquina smtp (el de mayor prioridad 10) y otro en la máquina smtp2 (de menor prioridad 20) Observe que los intercambiadores de correo deben ser hosts (registro A) y no alias (registro CNAME).

En la zona inversa se debe agregar los registros (según la configuración de named.conf será el fichero /var/named/chroot/var/named/inversa.zone): 2 IN PTR ns1.inca.edu. 5 IN PTR smtp.inca.edu. 6 IN PTR smtp2.inca.edu.



Configuración básica de POSTFIX

El fichero de configuración /etc/postfix/master.cf: Indica los procesos que utiliza el servidor. No se suele cambiar excepto para una configuración más avanzada.

El fichero de configuración fundamental es /etc/postfix/main.cf. Podemos cambiar las siguientes directivas en el supuesto de tener el servidor smtp.inca.edu y encontrarse en la red 172.26.0.0/24:

myhostname= smtp.inca.edu mydomain = inca.edu myorigin=$mydomain inet_interfaces = all mydestination = $myhostname, localhost.localdomain, $mydomain mynetworks = 172.26.0.0/24 message_size_limit= 1024000 mailbox_size_limit = 5120000

Las directivas más importantes son las siguientes:

• queue_directory: Especifica la localización de la cola de Postfix. • daemon_directory: Especifica la localización de todos los demonios de Postfix • myhostname: Especifica el nombre de host en internet para este sistema de correo. Por

defecto se utiliza el FQDM obtenido con gethostname(). Este parámetro se utiliza posteriormente dentro de otros parámetros.

• mydomain: Especifica el nombre de dominio local. Por defecto se utiliza el valor de $myhostname menos el primer componente. Este parámetro se utiliza posteriormente dentro de otros parámetros.

• myorigin: Especifica el dominio que aparece en los correos locales como origen. Por defecto se utiliza $myhostname, aunque en el caso de utilizar un dominio con múltiples máquinas debe usarse $mydomain.

• inet_interfaces: interface de red por las que puede recibir el correo. • mydestination: Especifica la lista de dominios para los que esta máquina se considera

destino final. • mynetworks_style: Especifica la lista de clientes SMTP en los que se confía y a los que

se les permite el envío de correo a través de Postfix. Mediante el uso de los valores subnet, class y host se permite el acceso a los clientes pertenecientes a la subred, clase o únicamente al host local respectivamente.

• mynetworks: Especifica el direccionamiento para el cual se permite el reenvío de correo a través de Postfix. En caso de definir este parámetro se ignora lo definido en $mynetworks_style.

• relay_domains: Especifica los dominios para los que está permitido el reenvío de correo.

• relayhost: Especifica el host hacia el que se envía el correo y que hace de reenviador en caso de que no esté directamente conectado a internet.

• alias_maps: Especifica la lista de base de datos de alias para el reenviador de correo local.

• alias_database: Especifica la base de datos de alias que se genera cada vez que se ejecuta newaliases.

• home_mailbox: Especifica la ruta, relativa al directorio $HOME, del fichero con el buzón de correo. Por defecto es /var/spool/mail/user o /var/mail/user. Si se especifica Maildir/ se utilizará el formato utilizado por qmail.



• mail_spool_directory: Especifica la ruta donde se almacenan los buzones con formato Unix mailbox.

• header_checks: Especifica una tabla de patrones con la que se compara las cabeceras de los mensajes.

• message_size_limit: tamaño del mensaje en bytes. Esta directiva es opcional. • mailbox_size_limit: tamaño del buzón en bytes. Esta directiva es opcional.

Existe una directiva para chequear las cabeceras de los mensajes (antispam) y evitar que se

envíen ciertos mensajes:

header_checks = regexp:/etc/postfix/header_checks

donde '/etc/postfix/header_checks' es un fichero que contiene expresiones regulares que indican los mensajes a rechazar. Por ejemplo (el fichero regexp_table es un ejemplo).

# EXAMPLE HEADER FILTER MAP # # These were once common in junk mail. /^Subject: make money fast/ REJECT /^To: friend@public\.com/ REJECT

Rechazan los correos con asunto “make money fast” o los que vayan a la dirección de correo “[email protected]”.

Puede encontrar más información en los ficheros ejemplos de la documentación de postfix

que se encuentran en el directorio ‘/usr/share/doc/postfix.a.b.c/samples’ (a.b.c indica la versión). Fichero aliases

• Indica alias para ocultar el verdadero nombre de la cuenta de correo electrónico. • El fichero /etc/postfix/aliases sustituye al fichero /etc/aliases • Debe especificarse en /etc/postfix/main.cf

alias_map=hash:/etc/postfix/aliases • Indica que se utiliza una tabla de hash (aliases.db) generada con postmap. • Posteriormente se edita el fichero /etc/postfix/aliases y se agrega al final una línea con el

siguiente formato: nuevoalias: usuario

Ejemplo:

nuevo: root • Ejecutar: 'postmap aliases' para crear la tabla de hash: 'aliases.db'. • Ejecutar newaliases (no es necesario si utilizamos /etc/postfix/aliases en lugar de

/etc/aliases) • Reiniciamos el servicio: 'service postfix restart'. • Se puede enviar un correo a [email protected] y lo recibirá [email protected].

Fichero transport



• Se utiliza para indicar el tratamiento local de correos • El fichero /etc/postfix/transport se utiliza para configurarlo. Ejemplo:

inca.edu local: localhost.localdomain local: garcilaso.edu smtp:[smtp2.inca.edu]

• En el ejemplo se indica que para el dominio inca.edu y localhost.localdomain se tratará

el correo localmente (en la propia máquina) y para el dominio garcilaso.edu se envía el correo al host smtp2.inca.edu

• Posteriormente se crea la tabla de hash transport.db postmap transport

• Reiniciamos el servidor: service postfix restart • En el fichero main.cf se indica el fichero transport que se utiliza

Características diversas del correo postfix.

• /var/log/maillog: ficheros log de incidencia en el envío • mailq: mensajes encolados sin enviar. • sendmail: cliente de correo a modo comando para enviar correo. Ejemplo:

sendmail [email protected]

'texto del correo' . (finaliza el correo con un punto)

• /var/mail/: Directorio donde se encuentran los buzones de correo del servidor. • mail: cliente de correo en modo comando. Cuando se lee un correo se quita del

directorio /var/mail/'nombreusuario' y se guarda en el directorio $HOME del usuario en el fichero mbox.

• /var/spool/postfix: colas de correo. • mailq: Mensajes encolados sin enviar.

Servicio POP3 con POPPER

El significado de las siglas POP es Protocolo de Oficina de Correos ("Post Office Protocol") El servidor de correo electrónico debe mantener almacenado el correo en sus casillas y enviarlo a los clientes cuando se conecten y lo soliciten. Este es el objetivo para el cual se creó el protocolo POP.

En la actualidad, se utiliza el protocolo SMTP para el envío de correo y para la recepción de correo se utiliza el protocolo POP, el cual, ya está en su tercera versión desde su aparición (POP3), la cual no posee grandes novedades con respecto al original, ya que básicamente, sigue permitiendo la descarga de los mensajes llegados a la casilla del usuario. Para instalar el servicio:

• Descargar el fichero desde ftp://ftp.qualcom.com/eudora/servers/unv/popper/qpopper4.0.5.tar.gz



• Descomprimir el fichero: tar xvf qpopper4.0.5.tar.gz • Nos vamos al directorio donde se ha descomprimido el fichero: cd qpopper4.0.5 • Configuramos el entorno antes de compilar

./configure --prefix=/usr/local mandir=/var/share/man • Compilamos el programa

make all • Instalamos el programa

make install • Si el fichero ya lo tenemos en binario (popper) no es necesario el compilarlo e

instalarlo, lo podemos copiar en el directorio /usr/local/sbin y darle permisos de ejecución con 'chmod a+x popper'.

• Posteriormente creamos el fichero /etc/xinetd.d/qpopper. Podemos coger por ejemplo el

fichero telnet del mismo directorio, copiarlo como qpopper y modificarlo. Es importante cambiar la línea 'disable=no' para que cuando se arranque xinetd (por ser un demonio no solitario) lo active.

Service pop3 {

flags = REUSE sockect_type = stream wait = no user = root server = /usr/local/sbin/popper instances = 50 per_source = 10 log_on_failure += USERID disable = no

} • Reiniciar el servidor xinetd puesto que el servicio popper depende de xinetd

(superdemonio de internet) al ser un demonio no solitario: service xinetd restart

• El servicio POP3 utiliza el puerto 110 • Podemos comprobar el funcionamiento:

telnet nombremáquina 110 • Tiene 3 estados:

1. Autorización: envío usuario y contraseña. 2. Transacción: bloquea el buzón para impedir su modificación. Espera comandos

usuario hasta QUIT 3. Actualización: Elimina los mensajes marcados para borrar. Finaliza conexión y

desbloquea buzón (se hace al pulsar QUIT)

Comandos POP3

• Las respuestas del servidor pueden ser:



+OK: El comando funcionó correctamente. +ERR: El comando falló. • Comandos de autorización:

USER usuario PASS contraseña QUIT

• Comandos transacción LIST [Nº de mensaje] DELE nº de mensaje NOOP : no operación. Mantiene conexión con el servidor. RETR nº_mensaje: recuperar un mensaje. RSET: anula marca borrado de mensajes STAT: resumen del contenido del buzón

• Otros comandos APOP usuario claveencriptada: conexión encriptada. TOP nº_mensaje nº_líneas: ver las líneas de un mensaje. UIDL [nº_mensaje]: ver identificador mensaje.

Servidor IMAP

• IMAP tiene ciertas ventajas con respecto a POP3. 1. Posibilidad de dejar en el servidor el correo leído. 2. Gestión de correo en el servidor (carpetas)

• Redhat dispone de un servidor IMAP: dovecot. • Para iniciar el servicio

service dovecot restart Gestión de listas de correo con Mailman

• Permite gestionar listas de correo a través del servidor web. • Para comprobar si lo tenemos instalado

rpm -qa | grep mailman, o bien rpm -q mailman

• Para saber dónde está instalado rpm -ql mailman

• Directorio de los binarios de mailman: /var/mailman/bin: Fedora Core 2 /usr/lib/mailman: Fedora Core 3

• Directorio de documentación /usr/share/doc/mailman

• Debemos cambiar en el fichero 'mm_cfg.py' situado en el directorio /var/mailman/Mailman (fedora Core 2): Las dos primeras líneas no son necesarias a partir de Fedora Core 3:

DEFAULT_URL_HOST = 'smtp.inca.edu' DEFAULT_EMAIL_HOST= 'smtp.inca.edu' DEFAULT_SERVER_LANGUAGE='es'

• Poner una contraseña a todo el dominio, ejecutar desde el directorio donde están los binarios

de mailman:



mmsitepass • Crear la lista mailman

newlist mailman • Añadir la salida por pantalla al fichero /etc/postfix/aliases • Ejecutar newaliases (no es necesario, sólo en caso de utilizar /etc/aliases) • Reiniciar el servidor: service postfix restart • Configurar apache: • Cambiar en el fichero /etc/httpd/conf.d/mailman.conf el nombre de nuestro servidor en la

directiva RedirectMatch: RedirectMatch ^/mailman[/]*$ http://www.inca.edu/mailman/listinfo

pipermail son los históricos de los mensajes de la lista.

• Arrancar apache y mailman service httpd restart service mailman restart

• Acceder con el navegador: http://www.inca.edu/mailman

• Para crear más listas de correo:

1. newlist nombrelista 2. Añadir la salida a /etc/postfix/aliases 3. Ejecutar ‘postmap /etc/postfix/aliases’ 4. Reiniciar el servidor postfix ‘service postfix restart’ 5. Acceso: http://www.inca.edu/mailman/listinfo/'nombrelista'

Webmail con Squirrelmail

• Las últimas versiones de redhat tiene instalado un webmail por defecto y configurada apache para acceder a él.

• Para comprobar si tenemos instalado squirrelmail rpm -q squirrelmail



• En el directorio /etc/httpd/conf.d existe el fichero squirrelmail.conf con el siguiente

contenido.

# # SquirrelMail is a webmail package written in PHP. # Alias /webmail /usr/share/squirrelmail

• Nos crea un alias en apache de nombre webmail que apunta al directorio /usr/share/squirrelmail, que es donde se encuentra el programa realizado en PHP.

• Debemos tener instalado un servidor imap, en este caso se puede utilizar dovecot. • Debemos tener arrancados el servidor smtp postfix y el servidor imap dovecot

service postfix restart service dovecot restart

• La configuración de la herramienta se encuentra en el fichero /etc/squirrelmail/config.php.

Veamos sus características principales:

<?php /** * SquirrelMail Configuration File * Created using the configure script, conf.pl



*/ global $version; $config_version = ’1.4.0’; $config_use_color = 1; $org_name = "SquirrelMail"; $org_logo = SM_PATH . ’images/sm_logo.png’; $org_logo_width = ’308’; $org_logo_height = ’111’; $org_title = "SquirrelMail $version"; $signout_page = ’ ’; $frame_top = ’_top’; $provider_uri = ’http://www.squirrelmail.org/’; $provider_name = ’SquirrelMail’; $motd = ""; //$squirrelmail_default_language = ’en_US’; $squirrelmail_default_language = ’es_ES’; Cambiamos a es_ES para que nos aparezca en castellano. $domain = ’localhost’; $imapServerAddress = ’localhost’; $imapPort = 143; $useSendmail = true; $smtpServerAddress = ’localhost’; $smtpPort = 25; $sendmail_path = ’/usr/sbin/sendmail’; $pop_before_smtp = false; $imap_server_type = ’other’; Configuramos el dominio de correo y los servidores IMAP y SMTP y puertos a los que se conecta. Con la configuración por defecto, funcionar´ýa directamente sobre la misma máquina en la que está el servidor web, aunque podr´ýa ser otro servidor distinto. $invert_time = false; $optional_delimiter = ’/’; $default_folder_prefix = ’mail/’; $trash_folder = ’Trash’; $sent_folder = ’Sent’; $draft_folder = ’Drafts’; $default_move_to_trash = true; $default_move_to_sent = true;

Contiene opciones de las carpetas por defecto. Existen más opciones, pero normalmente no las tocaremos.

• También podremos configurar nuestro sistema SquirrelMail mediante menús con el comando ‘/usr/share/squirrelmail/config/conf.pl’.

• Se pueden utilizar muchos webmail, uno de ellos que admite servidores pop3 e imap

indistintamente es iloha. Es un servidor hecho en php y se puede encontrar en http://ilohamail.org. Se puede instalar simplemente siguiendo los pasos de la instalación y descomprimiendo los ficheros hechos en php en un directorio accesible desde apache. En este caso se ha instalado en el directorio /var/www/html/ilo en el servidor y se accede a través de http://localhost/ilo.



Luchemos contra el SPAM y los virus: amavisd-new, spamassassin y ClamAV

Amavisd-new es una interfaz entre el MTA y uno o mas filtros de contenidos, como puede ser un antivirus o un módulo antispam, como ClamAV y SpamAssassin. Está escrito en Perl y se comunica con el MTA vía SMTP, LMTP, o mediante el uso de otros programas. No existen problemas de sincronización en su diseño que pudieran causar pérdidas de correos.

Cuando está habilitado el uso de SpamAssassin (SA), se llama a SA una sola vez por mensaje (independientemente del número de destinatarios).

SpamAssassin es un filtro de correo que trata de identificar el spam mediante el análisis del texto y el uso en tiempo real de algunas listas negras a través de Internet. A partir de su base de datos de reglas, utiliza un amplio abanico de pruebas heurísticas en las cabeceras y el cuerpo de los correos para identificar el spam, también conocido como correo electrónico comercial no solicitado. Una vez identificado, el correo puede ser opcionalmente marcado como spam y más tarde filtrado usando el cliente de correo del usuario. SpamAssassin normalmente identifica acertadamente entre un 95 y un 99% del spam, dependiendo del tipo de correo que se reciba.

La mejor forma de proteger nuestra red frente a estos correos con virus, es que ni siquiera lleguen a entrar. El que nuestro servidor de correo disponga un mecanismo de detección y eliminación de virus nos protegerá de infinidad de peligros.

Para ello utilizaremos ClamAV, que es un detector de virus con licencia GPL y que integraremos con nuestro agente de transporte de correo para rechazar los mensajes con virus.

El propósito principal de este software es tanto la integración con los servidores de correo (escaneo de datos adjuntos) como el escaneo de sistemas de ficheros que puedan contener virus (p. ej. un servidor samba para clientes windows).

En un sistema antivirus es muy importante la actualización de los ficheros de firmas y de los

motores antivirus para adaptarse a las mutaciones y apariciones de nuevos virus. ClamAV dispone de una herramienta para actualizarse automáticamente desde Internet (freshclam).



El sitio principal de este antivirus es http://www.clamav.net, donde podremos ampliar información.

El modo de funcionamiento será el siguiente: primero Postfix, nuestro agente de transporte, recibirá los correos y a continuación se los pasará a Amavis para que detecte si contiene virus (dándole el trabajo a Clamav) o es un spam (en este caso el currito será Spamassassin).

Debemos instalar los paquetes de los tres servicios y configurarlos para que funcionen con postfix, podéis obtener más información en los ficheros pdf del curso de thales (entrega 3 y 6). No se comentan en este tema por no extenderlo excesivamente.

postfix

Documents