108.3 Lección 1

Las cuentas de usuario tradicionales en máquinas conectadas a la red constituyen el escenario de intercambio de correo electrónico más sencillo, en este cada, nodo de la red ejecuta su propio demonio MTA y no se requiere ningún otro software aparte del MTA para enviar y recibir mensajes de correo electrónico. En la práctica, sin embargo, es más común utilizar una cuenta de correo electrónico remota y no tener un servicio MTA local activo (es decir, utilizar una aplicación cliente de correo electrónico para acceder a la cuenta remota).

A diferencia de las cuentas locales, una cuenta de correo electrónico remota --también llamada buzón remoto-- requiere la autenticación del usuario para concederle acceso al buzón y al MTA remoto (en este caso, llamado simplemente servidor SMTP). Mientras que el usuario que interactúa con un buzón y un MTA locales ya está identificado por el sistema, un sistema remoto debe verificar la identidad del usuario antes de manejar sus mensajes a través de IMAP o POP3.

Cuando se ejecuta un demonio MTA en el sistema local, los usuarios locales pueden enviar un correo electrónico a otros usuarios locales o a usuarios de una máquina remota, siempre que su sistema también tenga un servicio MTA que acepte conexiones de red. El puerto TCP 25 es el estándar para la comunicación SMTP, pero también se pueden utilizar otros puertos, dependiendo del esquema de autenticación y/o cifrado que se utilice (si lo hay).

Dejando de lado las topologías que implican el acceso a buzones remotos, se puede implementar una red de intercambio de correo electrónico entre cuentas de usuario ordinarias de Linux siempre que todos los nodos de la red tengan un MTA activo que sea capaz de realizar las siguientes tareas:

Normalmente, las direcciones de correo electrónico especifican un nombre de dominio como ubicación, por ejemplo, lpi.org en info@lpi.org. En este caso, el MTA del remitente consultará al servicio DNS el registro MX correspondiente. El registro DNS MX contiene la dirección IP del MTA que gestiona el correo electrónico para ese dominio. Si el mismo dominio tiene más de un registro MX especificado en el DNS, el MTA debe intentar ponerse en contacto con ellos según sus valores de prioridad. Si la dirección del destinatario no especifica un nombre de dominio o el dominio no tiene un registro MX, la parte que sigue al símbolo @ se tratará como el host del MTA de destino.

Hay que tener en cuenta los aspectos de seguridad si los hosts del MTA van a ser visibles para los hosts de Internet. Por ejemplo, es posible que un usuario desconocido utilice el MTA local para hacerse pasar por otro usuario y enviar correos electrónicos potencialmente dañinos. Un MTA que retransmite ciegamente un correo electrónico se conoce como retransmisión abierta, cuando puede ser utilizado como intermediario para disfrazar potencialmente el verdadero remitente del mensaje. Para evitar estos usos indebidos, la recomendación es aceptar conexiones sólo de dominios autorizados e implementar un esquema de autenticación seguro.

Además, hay muchas implementaciones diferentes de MTA para Linux, cada una de las cuales se centra en aspectos específicos como la compatibilidad, el rendimiento, la seguridad, etc. Sin embargo, todos los MTAs seguirán los mismos principios básicos y proporcionarán características similares.

El MTA tradicional disponible para los sistemas Linux es Sendmail, un MTA de propósito general muy flexible utilizado por muchos sistemas operativos tipo Unix. Otros MTA comunes son Postfix, qmail y Exim. La razón principal para elegir un MTA alternativo es implementar características avanzadas más fácilmente, ya que configurar servidores de correo electrónico personalizados en Sendmail puede ser una tarea complicada. Además, cada distribución puede tener su MTA preferido, con configuraciones predefinidas. Todos los MTA pretenden ser sustitutos de Sendmail, por lo que todas las aplicaciones compatibles con Sendmail deberían funcionar independientemente del MTA que se utilice.

Si el MTA está funcionando pero no acepta conexiones de red, sólo podrá entregar mensajes de correo electrónico en la máquina local. Para el MTA sendmail, el archivo /etc/mail/sendmail.mc debe ser modificado para aceptar conexiones no locales. Para ello, la entrada sera la siguiente:

Debe modificarse a la dirección de red correcta y el servicio debe reiniciarse. Algunas distribuciones de Linux, como Debian, pueden ofrecer herramientas de configuración para ayudar a poner en marcha el servidor de correo electrónico con un conjunto predefinido de características de uso común.

Una vez que el MTA está funcionando y aceptando conexiones de la red, los nuevos mensajes de correo electrónico se le pasan comandos SMTP que se envían a través de una conexión TCP. El comando nc — una utilidad de red que lee y escribe datos genéricos a través de la red — puede utilizarse para enviar comandos SMTP directamente al MTA. Si el comando nc no está disponible, se instalará con el paquete ncat o nmap-ncat, dependiendo del sistema de gestión de paquetes que se utilice. Escribir comandos SMTP directamente al MTA le ayudará a entender mejor el protocolo y otros conceptos generales del correo electrónico, pero también puede ayudar a diagnosticar problemas en el proceso de entrega del correo.

Si, por ejemplo, el usuario emma en el host lab1.campus quiere enviar un mensaje al usuario dave en el host lab2.campus, entonces puede usar el comando nc para conectarse directamente al MTA lab2.campus, asumiendo que está escuchando en el puerto TCP 25:

Una vez establecida la conexión, el MTA remoto se identifica y está listo para recibir comandos SMTP. El primer comando SMTP del ejemplo, HELO lab1.campus, indica que lab1.campus es el iniciador del intercambio. Los dos siguientes comandos, MAIL FROM: emma@lab1.campus y RCPT TO: dave@lab2.campus, indican el remitente y el destinatario. El mensaje de correo electrónico propiamente dicho comienza después del comando DATA y termina con un punto en una línea por sí mismo. Para añadir un campo subject al correo electrónico, debe estar en la primera línea después del comando DATA, como se muestra en el ejemplo. Cuando se utiliza el campo de asunto, debe haber una línea vacía que lo separe del contenido del correo electrónico. El comando QUIT termina la conexión con el MTA en el host lab2.campus.

En el host lab2.campus, el usuario dave recibirá un mensaje similar a You have new mail in /var/spool/mail/dave tan pronto como entre en una sesión de shell. Este archivo contendrá el mensaje de correo electrónico en bruto enviado por emma así como las cabeceras añadidas por el MTA:

La cabecera Received: muestra que el mensaje de lab1.campus fue recibido directamente por lab2.campus. Por defecto, los MTAs sólo aceptan mensajes a destinatarios locales. El siguiente error probablemente ocurrirá si el usuario emma intenta enviar un correo electrónico al usuario henry en el host lab3.campus, pero utilizando el MTA lab2.campus en lugar del MTA apropiado lab3.campus:

Los números de respuesta SMTP que empiezan por 5, como el mensaje Relaying denied, indican un error. Hay situaciones legítimas en las que la retransmisión es deseable, como cuando los hosts que envían y reciben correos electrónicos no están conectados todo el tiempo: se puede configurar un MTA intermedio para que acepte los correos electrónicos destinados a otros hosts, actuando como un servidor SMTP de retransmisión que puede reenviar mensajes entre MTAs.

La posibilidad de enrutar el tráfico de correo electrónico a través de servidores SMTP intermedios desaconseja el intento de conectarse directamente al host indicado por la dirección de correo electrónico del destinatario, como se muestra en los ejemplos anteriores. Además, las direcciones de correo electrónico suelen tener un nombre de dominio como ubicación (después de la @), por lo que el nombre real del host MTA correspondiente debe ser recuperado a través de DNS. Por lo tanto, se recomienda delegar la tarea de identificar el host de destino apropiado al MTA local o al servidor SMTP remoto, cuando se utilizan buzones remotos.

Sendmail proporciona el comando sendmail para realizar muchas operaciones relacionadas con el correo electrónico, incluyendo la asistencia en la composición de nuevos mensajes. También requiere que el usuario escriba las cabeceras del correo electrónico a mano, pero de una forma más amigable que utilizando los comandos SMTP directamente. Así que un método más adecuado para que el usuario emma@lab1.campus envíe un mensaje de correo electrónico a dave@lab2.campus sería:

También en este caso, el punto en una línea por sí mismo termina el mensaje. El mensaje debería ser enviado inmediatamente al destinatario, a menos que el MTA local no se haya podido contactar con el MTA remoto. El comando mailq, si es ejecutado por root, mostrará todos los mensajes no entregados. Si, por ejemplo, el MTA de lab2.campus no ha respondido, el comando mailq mostrará el mensaje no entregado y la causa del fallo:

La ubicación por defecto de la cola de salida es /var/spool/mqueue/, pero diferentes MTAs pueden utilizar diferentes ubicaciones en el directorio /var/spool/. Postfix, por ejemplo, creará un árbol de directorios en /var/spool/postfix/ para gestionar la cola. El comando mailq es equivalente a sendmail -bp, debe estar presente independientemente del MTA instalado en el sistema. Para asegurar la compatibilidad con versiones anteriores, la mayoría de los MTAs proporcionan estos comandos tradicionales de administración de correo.

Si el host principal de destino del correo electrónico — cuando se proporciona desde un registro DNS MX para el dominio — es inalcanzable, el MTA intentará ponerse en contacto con las entradas con menor prioridad (si hay alguna especificada). Si ninguna de ellas es alcanzable, el mensaje permanecerá en la cola de la bandeja de salida local para ser enviado más tarde. Si se configura para ello, el MTA puede comprobar periódicamente la disponibilidad de los hosts remotos y realizar un nuevo intento de entrega. Si se utiliza un MTA compatible con Sendmail, se realizará inmediatamente un nuevo intento con el comando sendmail -q.

Sendmail almacenará los mensajes entrantes en un archivo con el nombre del propietario de la bandeja de entrada correspondiente, por ejemplo /var/spool/mail/dave. Otros MTA, como Postfix, pueden almacenar los mensajes de correo electrónico entrantes en ubicaciones como /var/mail/dave, pero el contenido del archivo es el mismo. En el ejemplo, el comando sendmail se utilizó en el host del remitente para crear el mensaje, por lo que las cabeceras de los mensajes sin procesar muestran que el correo electrónico siguió pasos adicionales antes de llegar al destino final:

De abajo a arriba, las líneas que comienzan con Received: muestran la ruta seguida por el mensaje. El mensaje fue enviado por el usuario emma con el comando sendmail dave@lab2.campus emitido en lab1.campus, como se indica en la primera cabecera Received:. A continuación, todavía en lab1.campus, el MTA utiliza ESMTPS — un superconjunto del SMTP, que añade extensiones de cifrado — para enviar el mensaje al MTA en lab2.campus, como se indica en la última cabecera (superior) Received:.

El MTA termina su trabajo una vez que el mensaje se guarda en la bandeja de entrada del usuario. Es habitual realizar algún tipo de filtrado del correo electrónico, como el bloqueo de spam o la aplicación de reglas de filtrado definidas por el usuario. Estas tareas son ejecutadas por aplicaciones de terceros, que trabajan conjuntamente con el MTA. El MTA podría, por ejemplo, llamar a la utilidad SpamAssassin para marcar los mensajes sospechosos utilizando sus funciones de análisis de texto.

Aunque es posible, no es conveniente leer el archivo del buzón directamente. Se recomienda utilizar en su lugar un programa cliente de correo electrónico (por ejemplo, Thunderbird, Evolution o KMail), que analizará el archivo y gestionará adecuadamente los mensajes. Estos programas también ofrecen funciones adicionales, como accesos directos a acciones comunes, subdirectorios de la bandeja de entrada, etc.

Es posible escribir un mensaje de correo electrónico directamente en su formato crudo, pero es mucho más práctico utilizar una aplicación cliente — también conocida como MUA (Agente de Usuario de Correo) — para acelerar el proceso y evitar errores. El MUA se encarga del trabajo bajo el capó, es decir, el cliente de correo electrónico presenta y organiza los mensajes recibidos y maneja la comunicación adecuada con el MTA después de que el usuario compone un correo electrónico.

Hay muchos tipos distintos de agentes de usuario de correo. Las aplicaciones de escritorio como Mozilla Thunderbird y Evolution de Gnome soportan cuentas de correo electrónico tanto locales como remotas. Incluso las interfaces de Webmail pueden considerarse un tipo de MUA, ya que interviene la interacción entre el usuario y el MTA subyacente. Sin embargo, los clientes de correo electrónico no se limitan a las interfaces gráficas. Los clientes de correo electrónico de consola se utilizan ampliamente para acceder a los buzones no integrados en una interfaz gráfica y para automatizar las tareas relacionadas con el correo electrónico dentro de los scripts del shell.

Originalmente, el comando mail de Unix sólo estaba pensado para compartir mensajes entre usuarios del sistema local (el primer comando mail se remonta a la primera edición de Unix, lanzada en 1971). Cuando los intercambios de correo electrónico en red se hicieron más importantes, se crearon otros programas para hacer frente al nuevo sistema de entrega y sustituyeron gradualmente al antiguo programa mail.

Hoy en día, el comando mail más utilizado es el proporcionado por el paquete mailx, que es compatible con todas las características modernas del correo electrónico. En la mayoría de las distribuciones de Linux, el comando mail es sólo un enlace simbólico al comando mailx. Otras implementaciones, como el paquete GNU Mailutils, proporcionan básicamente las mismas características que mailx. Sin embargo, existen ligeras diferencias entre ellas, especialmente en lo que respecta a las opciones de la línea de comandos.

Independientemente de su implementación, todas las variantes modernas del comando mail funcionan en dos modos: modo normal y modo de envío. Si se proporciona una dirección de correo electrónico como argumento al comando mail, éste entrará en el modo de envío, de lo contrario entrará en el modo normal (lectura). En el modo normal, los mensajes recibidos se listan con un índice numérico para cada uno, de modo que el usuario puede referirse a ellos individualmente cuando escribe comandos en el prompt interactivo. El comando print 1 puede utilizarse para mostrar el contenido del mensaje número 1, por ejemplo. Los comandos interactivos pueden ser abreviados, por lo que comandos como print, delete o reply pueden ser reemplazados por p, d o r, respectivamente. El comando mail siempre considerará el último mensaje recibido o el último visto cuando se omita el número de índice del mensaje. El comando quit o q terminará del programa.

El modo send mode es especialmente útil para enviar mensajes de correo electrónico automatizados. Puede utilizarse, para enviar un correo electrónico al administrador del sistema si un script de mantenimiento programado no realiza su tarea. En el modo de envío, mail utilizará el contenido de la entrada estándar como cuerpo del mensaje:

En este ejemplo, se añadió la opción -s para incluir un campo de asunto al mensaje. El cuerpo del mensaje fue proporcionado por la redirección Hereline a la entrada estándar, pero el contenido de un archivo o la salida de un comando también podría ser canalizado a la stdin del programa. Si no se proporciona ningún contenido mediante una redirección a la entrada estándar, el programa esperará a que el usuario introduzca el cuerpo del mensaje. En este caso, la pulsación de la tecla Ctrl+D finalizará el mensaje. El comando mail saldrá inmediatamente después de que el mensaje se añada a la cola de salida.

Por defecto, las cuentas de correo electrónico en un sistema Linux están asociadas a las cuentas estándares del sistema. Por ejemplo, si el usuario Carol tiene el nombre de usuario carol en el host lab2.campus entonces su dirección de correo electrónico será carol@lab2.campus. Esta asociación uno a uno entre las cuentas del sistema y los buzones de correo puede ser extendida por métodos estándares proporcionados por la mayoría de las distribuciones de Linux, en particular el mecanismo de enrutamiento de correo electrónico proporcionado por el archivo /etc/aliases.

Un alias de correo electrónico es un destinatario de correo electrónico “virtual” cuyos mensajes recibidos se redirigen a buzones locales existentes o a otros tipos de destinos de almacenamiento o procesamiento de mensajes. Los alias son útiles, por ejemplo, para colocar los mensajes enviados a postmaster@lab2.campus en el buzón de Carol, que es un buzón local ordinario en el sistema lab2.campus. Para ello, se debe añadir la línea postmaster: carol al fichero /etc/aliases en lab2.campus. Después de modificar el archivo /etc/aliases, se debe ejecutar el comando newaliases para actualizar la base de datos de alias del MTA y hacer efectivos los cambios. Los comandos sendmail -bi o sendmail -I también pueden utilizarse para actualizar la base de datos de alias. Los alias se definen por línea, con el formato <alias>: <destino>. Además de los buzones locales ordinarios, indicados por el nombre de usuario correspondiente, existen otros tipos de destino:

Un usuario local sin privilegios puede definir alias para su propio correo electrónico editando el archivo .forward en su directorio personal. Como los alias sólo pueden afectar a su propio buzón, sólo es necesaria la parte de <destination>. Para reenviar todos los correos electrónicos entrantes a una dirección externa, por ejemplo, el usuario dave en lab2.campus podría crear el siguiente archivo ~/.forward:

Reenviará todos los mensajes de correo electrónico enviados a dave@lab2.campus a emma@lab1.campus. Al igual que con el fichero /etc/aliases, se pueden añadir (una por línea) otras reglas de redirección a .forward. Sin embargo, el archivo .forward debe ser escribible sólo por su propietario y no es necesario ejecutar el comando newaliases después de modificarlo. Los archivos que comienzan con un punto no aparecen en los listados de archivos habituales, lo que podría hacer que el usuario no conociera los alias activos. Por lo tanto, es importante verificar si el archivo existe cuando se diagnostican problemas de entrega de correo electrónico.