Servidores de correo

El propósito principal de SMTP es transferir correo electrónico entre servidores de correo. Sin embargo, es también crítico para los clientes de correo electrónico. Para enviar correo electrónico, el cliente envía el mensaje a un servidor de correo saliente, que después contacta con el servidor de correo de destino para su entrega. Por esta razón es necesario especificar un servidor SMTP cuando se configura un cliente de correo electrónico.

Bajo Fedora, un usuario puede configurar un servidor SMTP en la máquina local para manejar la entrega de correo. Sin embargo, también es posible configurar servidores SMTP remotos para el correo saliente.

Un punto importante a saber sobre el protocolo SMTP es que no requiere autenticación. Esto permite a cualquiera en la Internet enviar correo electrónico a cualquier otro e incluso a grandes grupos de personas. Es esta característica de SMTP la que hace posible el correo basura o spam. La imposición de restricciones de retransmisión impide que los usuarios aleatorios de Internet envíen correos electrónicos a través de su servidor SMTP a otros servidores de Internet. Los servidores que no imponen estas restricciones son llamados servidores de retransmisión abierta.

Fedora proporciona los programas SMTP Postfix y Sendmail .

El servidor POP predeterminado bajo Fedora es Dovecot y se proporciona por el paquete dovecot.

Cuando se utiliza un servidor POP los mensajes de correo electrónico son descargados por las aplicaciones de clientes de correo electrónico. De modo predeterminado la mayoría de los clientes de correo electrónico `POP`están configurados para borrar automáticamente el mensaje del servidor de correo electrónico una vez que ha sido transferido con éxito, sin embargo este ajuste normalmente puede ser cambiado.

POP es totalmente compatible con los estándar de mensajería más importantes de Internet,como Multipurpose Internet Mail Extensions (MIME), que permite los adjuntos de correo electrónico.

POP trabaja mejor para los usuarios que tiene un sistema que permite leer correo electrónico. Trabaja también bien con los usuarios que no tiene una conexión continua a Internet o a la red en la que está el servidor de correo. Desafortunadamente para aquellos con conexiones de red lentas, POP requiere programas clientes después de la autenticación para descargar el contenido de cada mensaje. Esto puede llevar mucho tiempo si el mensaje tiene grandes adjuntos.

La versión más actual del protocolo estándar POP es POP3.

Hay, sin embargo, diversas variantes del protocolo POP menos usadas:

Para añadir seguridad es posible usar encriptación Secure Socket Layer (SSL) para la autenticación del cliente y las sesiones de transferencia de datos. Esto se puede habilitar usando el servicio pop3s o usando la aplicación stunnel. Para más información sobre el aseguramiento de la comunicación de correo electrónico vea Asegurando la Comunicación.

El servidor IMAP predeterminado bajo Fedora es Dovecot que es proporcionado por el paquete dovecot. Vea en POP información sobre como instalar Dovecot.

Cuando se utilizar un servidor de correo IMAP los mensajes de correo electrónico permanecen en el servidor donde los usuarios pueden leerlos o borrarlos. IMAP también permite a las aplicaciones cliente crear, renombrar o borrar directorios de correo en el servidor para organizar y almacenar el correo electrónico.

IMAP es particularmente útil para los usuarios que acceden a su correo electrónico desde múltiples máquinas. El protocolo es también conveniente para los usuarios que se conectan al servidor de correo por medio de una conexión lenta, puesto que solo se descarga la cabecera del mensaje hasta que se abre, ahorrando ancho de banda. El usuario tiene también la capacidad de borrar mensajes sin verlos o descargarlos.

Para mayor comodidad, las aplicaciones clientes IMAP son capaces de almacenar en caché copias de los mensajes localmente, de modo que el usuario puede navegar antes de leer los mensajes cuando no está conectado directamente al servidor IMAP.

IMAP, como POP, es totalmente compatible con importantes estándar de mensajería en Internet, como MIME, que permite los adjuntos para correo electrónico.

Para añadir seguridad, es posible utilizar encriptación SSL para la autenticación del cliente y las sesiones de transferencia de datos. Esto se puede habilitar utilizando el servicio imaps o usando el programa stunnel. Para más información sobre el aseguramiento de la comunicación de correo electrónico, vea Asegurando la Comunicación.

Hay otros servidores IMAP disponibles, tanto libres como comerciales, muchos de los cuales extiende el protocolo IMAP y proporcionan funcionalidades adicionales.

Los procesos imap-login y pop3-login que implementan los protocolos IMAP y POP3`son engendrados por el demonio maestro `dovecot incluido en el paquete dovecot. El uso de IMAP y POP se configura a través del archivo de configuración /etc/dovecot/dovecot.conf; de modo predeterminado dovecot ejecuta IMAP y POP3 juntos con sus versiones seguras utilizando SSL. Para configurar dovecot para usar POP, complete los siguientes pasos:

A diferencia de SMTP, tanto IMAP como POP3 requieren que los clientes que se conecten se autentiquen con nombre de usuario y contraseña. De modo predeterminado las contraseñas para ambos protocolos se pasan por la red sin encriptar.

Para configurar SSL sobre dovecot:

Más detalles sobre dovecot se puede encontrar en línea en https://www.dovecot.org.

El ejecutable de Postfix es postfix. Este demonio lanza todos los procesos relacionados necesarios para manejar la entrega de correo.

Postfix almacena sus ficheros de configuración en el directorio /etc/postfix/. Lo siguiente es una lista de los archivos usados más comúnmente:

El archivo aliases se puede encontrar en el directorio /etc/. Este archivo es compartido entre Postfix y Sendmail. Es una lista configurable requerida por el protocolo de correo que describe los alias de ID de usuario.

Reinicie el servicio postfix después de cambiar cualquier opción en los archivos de configuración del directorio /etc/postfix con el objetivo de que los cambuios tengan efecto. Para hacerlo, ejecute el siguiente comando como root:

De modo predeterminado, Postfix no acepta conexiones de red que vengan de cualquier otro host que no sea el host lolcal. Lleve a cabo los siguientes pasos, como root para habilitar la entrega de correo a otros hosts en la red:

Una vez que se han completado estos pasos, el host acepta correo electrónico de fuera para su entrega.

Postfix tiene una gran variedad de opciones de configuración. Una de las mejores maneras de aprender a configurar Postfix es leer los comentarios dentro del archivo de configuración /etc/postfix/main.cf. Recursos adicionales incluyendo información sobre la configuración Postfix, integración de SpamAssassin o descripciones de los parámetros de /etc/postfix/main.cf están disponibles en línea en el enlace http://www.postfix.org/.

Postfix puede usar un directorio LDAP como fuente de diversas tablas de búsqueda (p.ej.: aliases, virtual, canonical, etc.). Esto permite a LDAP almacenar información jerárquica de usuario y a Postfix solo se da el resultado de las consultas LDAP cuando las necesita. Al almacenar esta información localmente los administradores pueden mantenerlo fácilmente.

Lo que sigue es un ejemplo básico del uso de LDAP para buscar en el archivo /etc/aliases. Compruebe que su archivo /etc/postfix/main.cf contiene lo siguiente:

Crear un archivo a /etc/postfix/ldap-aliases.cf si no tiene uno ya y compruebe que tiene lo siguiente:

donde ldap.example.com, example y com son parámetros que necesitan ser reemplazados con la especificación de un servidor LDAP existente disponible.

Para más información sobre LDAP,vea OpenLDAP.

Es importante tener en cuenta lo que Sendmail es y lo que hace, como oposición a lo que no. En esto días de aplicaciones monolíticas que cumplen múltiples papeles, Sendmail puede parecer la única aplicación necesaria para correr un servidor de correo electrónico en una organización. Técnicamente, esto es verdad, puesto que Sendmail puede poner en cola el correo en el directorio de cada usuario y entregar correo saliente para los usuarios. Sin embargo, la mayoría de los usuarios requieren actualmente mucho más que una sencilla entrega de correo electrónico. Los usuarios normalmente desean interactuar con su correo electrónico usando una MUA, que usa POP o IMAP, para descargar sus mensajes a su máquina local. O, pueden preferir una interfaz Web para tener acceso a su buzón de correo. Estas otras aplicaciones pueden trabajar en colaboración con Sendmail, pero actualmente existen por diferentes razones y pueden trabajar separadamente unos de otros.

Está más allá del alcance de esta sección ir hacia todo lo que Sendmail debería o podría estar configurado para hacer. Con, literalmente, cientos de diferentes opciones y conjuntos de reglas, se han dedicado volúmenes enteros a ayudar a explicar todo lo que se puede hacer y como corregir las cosas que van mal. Vea en Recursos Adicionales funa lista de los recursos de Sendmail.

Esta sección revisa los archivos instalados con Sendmail de forma predeterminada y revisa los cambios básicos de configuración, incluyendo como para correo electrónico no deseado (spam) y como e4xtender Sendmail con Lightweight Directory Access Protocol (LDAP).

Con el objetivo de usar Sendmail, compruebe primero que el paquete sendmail está instalado en su sistema ejecutando como root:

Con el objetivo de configurar Sendmail, compruebe que el paquete sendmail-cf está instalado en su sistema ejecutando como root:

Para más información sobre la instalación de paquetes con DNF, vea Instalando Paquetes.

Antes de usar Sendmail, se debe conmutar el MTA predeterminado desde Postfix. Para más información sobre conmutar el MTA predeterminado vea Agentes de Transporte de Correo.

El ejecutable de Sendmail es sendmail.

El archivo de configuración largo y detallado de Sendmail es /etc/mail/sendmail.cf. Evite editar el archivo sendmail.cf directamente. Para hacer cambios en la configuración de Sendmail, edite el archivo /etc/mail/sendmail.mc, copia de seguridad del archivo /etc/mail/sendmail.cf original y utilice las siguientes alternativas para generar un nuevo archivo de configuración:

Más información sobre la configuración de Sendmail se puede encontrar en Cambios de Configuración Comunes en Sendmail.

Diversos archivos de configuración de Sendmail están instalados en el directorio /etc/mail/ incluyendo:

Varios de los archivos de configuración en el directorio /etc/mail/, como access, domaintable, mailertable y virtusertable, deben actualmente almacenar su información en archivos de base de datos antes de que Sendmail pueda usar cualquier cambio de configuración. Para incluir cualquier cambio hecho en estas configuraciones en su archivo de base de datos, ejecute los siguiente comandos como root:

Esto actualizará virtusertable.db, access.db, domaintable.db, mailertable.db, sendmail.cf y submit.cf.

Para actualizar todos los archivos de base de datos listados arriba y para actualizar un archivo de base de datos personal, use un comando con el siguiente formato:

donde name representa el nombre del archivo de base de datos personal a ser actualizado.

Para actualizar una única base de datos, use un comando con el siguiente formato:

donde name.db representa el nombre del archivo de base de datos a ser actualizado.

También puede reiniciar el servicio sendmail para que los cambios tengan efecto ejecutando:

Por ejemplo para tener todos los correos electrónicos dirigidos al dominio example.com entregados a bob@other-example.com, añada la siguiente línea al archivo virtusertable:

Para finalizar el cambio, el archivo virtusertable.db debe ser actualizado:

Al usar la opción all conseguirá que virtusertable.db y access.db sean actualizados a la vez.

Cuando se altera el archivo de configuración de Sendmail, es mejor no editar un archivo existente sino generar jun archivo `/etc/mail/sendmail.cf`enteramente nuevo.

Para añadir la funcionalidad deseada a Sendmail, edite el archivo /etc/mail/sendmail.mc como root. Una vez haya terminado. reinicie el servicio sendmail y si está instalado el paquete m4, el procesador de macro m4 generará automáticamente un nuevo archivo de configuración sendmail.cf:

La configuración predeterminada en Fedora trabaja con la mayoría de los sitios solo SMTP. Sin embargo, no trabaja para los sitios UUCP (UNIX-to-UNIX Copy Protocol). Si está usando transferencias de correo UUCP, se debe volver a configurar el archivo /etc/mail/sendmail.mc y se debe generar un nuevo archivo /etc/mail/sendmail.cf.

Consulte el archivo /usr/share/sendmail-cf/README antes de editar cualquier archivo en los directorios bajo el directorio i`/usr/share/sendmail-cf/` ya que puede afectar a la futura configuración del archivo /etc/mail/sendmail.cf.

Un configuración común de Sendmail es tener una única máquina actuando como pasarela de correo para todas las máquinas en la red. Por ejemplo, una compañía puede desear tener una máquina llamada mail.example.com que maneja todo su correo electrónico y asigna una dirección de devolución consistente a todo el correo saliente.

En esta situación, el servidor Sendmail debe enmascarar los nombres de las máquinas en la red de la compañía de manera que su dirección de retorno es user@example.com en lugar de user@host.example.com.

Para hacer esto añada las siguientes líneas a /etc/mail/sendmail.mc:

Después genere un nuevo archivo sendmail.cf usando el procesador de macro m4, esta configuración hace que todo el correo de dentro de la red aparezca como si fuera enviado desde example.com.

El correo spam puede ser definido como correo electrónico innecesario y no deseado recibido por un usuario que nunca ha pedido la comunicación. Es un abuso disruptivo, costoso y generalizado de los estándares de comunicación de Internet.

Sendmail hace relativamente fácil bloquear las nuevas técnicas de spam que están siendo empleadas para enviar correo electrónico no deseado. Incluso bloquea muchos de los métodos más usuales de spam de forma predeterminada. Las principales funciones antispam disponibles en sendmail son header checks, relaying denial (predeterminado desde la versión 8.9), access database y sender information checks.

Por ejemplo, el reenvío de mensajes SMTP, también llamado retransmisión, ha sido deshabilitado de forma predeterminada desde Sendmail versión 8.9. Antes de que sucediera este cambio, Sendmail dirigia todo el correo del host (x.edu) a aceptar mensajes de una parte (y.com) y enviarlo a una parte diferente (z.net). Ahora, sin embargo, Sendmail debe ser configurado para permitir que cualquier dominio retransmita correo a través del servidor. Para configurar dominios de retransmisión edite el archivo /etc/mail/relay-domains y reinicie Sendmail

Sin embargo los usuarios pueden también enviar spam desde los servidores en Internet. En estos casos, las funciones de control de acceso de Sendmail disponibles a través del archivo /etc/mail/access se pueden usar para evitar conexiones desde equipos no deseados. El siguiente ejemplo ilustra como este archivo puede ser usado para bloquear y permitir específicamente el acceso al servidor Sendmail:

Este ejemplo muestra que cualquier correo electrónico enviado desde badspammer.com es bloqueado con un error 550 compatible con el RFC-821, con un mensaje enviado de vuelta. El correo electrónico enviado desde el subdominio tux.badspammer.com es aceptado. La última línea muestra que cualquier correo electrónico enviado desde la red 10.0.. se puede retransmitir a través del servidor de correo.

Ya que el archivo /etc/mail/access.db es una base de datos, use el comando makemap para actualizar cualquier cambio. Haga esto usando el siguiente comando como root:

El análisis de la cabecera del mensaje le permite rechazar correo en base a los contenidos de la cabecera. Los servidores SMTP almacenan información sobre el recorrido del correo electrónico en la cabecera del mensaje. Como el mensaje viaja de un MTA a otro, cada uno pone una cabecera Recibido bajo las demás cabeceras Recibido. Es importante tener en cuenta que esta información puede ser alterada por los spammers.

Los ejemplos de arriba son una pequeña parte de lo que Sendmail puede hacer en términos de permitir o bloquear el acceso. Vea en el archivo /usr/share/sendmail-cf/README más información y ejemplos.

Dado que Sendmail llama al MDA de Procmail al entregar el correo, también posible usar un programa de filtrado de spam, como SpamAssassin, para identificar y archivar spam para los usuarios. Vean en Filtros de Spam más información sobre el uso de SpamAssassin.

Usar LDAP es una manera muy rápida y poderosa de encontrar información específica sobre un usuario concreto en un grupo mucho más grande. Por ejemplo, se puede usar un servidor LDAP`para buscar una dirección de correo electrónico concreta dentro de uin directorio corporativo común por el apellido del usuario. En esta clase de implementación, `LDAP`está en gran medida separado de Sendmail, con `LDAP almacenando información jerárquica del usuario y a Sendmail solo se le proporciona el resultado de las consultas LDAP en mensajes de correo electrónico con dirección previa.

Sin embargo, Sendmail soporta una mucho mayor integración con LDAP, cuando se usa LDAP para reemplazar archivos que se mantienen separadamente, como /etc/aliases y /etc/mail/virtusertables, en diferentes servidores de correo que trabajan juntos para soporta una organización de nivel medio a empresarial. En resumen, LDAP abstrae el nivel de enrutamiento de correo de Sendmail y sus archivos de configuración separado a un poderoso cluster LDAP que puede ser aprovechado por muchas aplicaciones diferentes.

La actual versión de Sendmail contiene soporte para LDAP. Para extender el servidor Sendmail usando LDAP, obtenga primero un servidor LDAP, como OpenLDAP, corriendo y configurado apropiadamente. Después edite /etc/mail/sendmail.mc para incluir lo siguiente:

Después, recree el archivo /etc/mail/sendmail.cf ejecutando el macro procesador m4 y reinicie otra vez Sendmail. Vea instrucciones en Cambios Comunes de Configuración de Sendmail.

Para más información sobre LDAP,vea OpenLDAP.

A pesar de que es posible pasar todas las opciones necesarias desde la línea de comandos para comprobar si hay correo electrónico en un servidor remoto cuando se ejecuta Fetchmail, usar un archivo .fetchmailrc es mucho más fácil. Coloque las opciones de configuración deseadas en el archivo .fetchmailrc para aquellas opciones que se usarán cada vez que se envíe el comando fetchmail. Es posible anular estas en el momento en que Fetchmail está corriendo especificando esa opción en la línea de comandos.

Un archivo .fetchmailrc de usuario contiene tres clases de opciones de configuración:

Las opciones globales aparecen en la parte superior del archivo .fetchmailrc, seguido por uno o más opciones de servidor, cada una de las cuales designa a un servidor de correo electrónico diferente que Fetchmail debería comprobar. Las opciones de usuario siguen a las opciones de servidor por cada cuenta de usuario que está comprobando ese servidor de correo electrónico. Al igual que las opciones de servidor, se pueden especificar múltiples opciones para su uso con un servidor concreto así como para comprobar múltiples cuentas de correo electrónico en el mismo servidor.

Las opciones de servidor se ponen en servicio en el archivo .fetchmailrc mediante el uso de un verbo de opción especial, poll o skip, que precede a cualquier información del servidor. La acción poll le dice a Fetchmail que use esta opción de servidor cuando está corriendo, la cual comprueba el correo electrónico usando las opciones de usuario especificadas. Cualquier opción de servidor después de una acción skip, sin embargo, no será comprobado a menos que el nombre de equipo del servidor sea especificado cuando se llama a Fetchmail. La opción skip es útil cuando se prueban configuraciones en el archivo .fetchmailrc porque solo comprueba los servidores omitidos cuando se llaman específicamente y no afecta a ninguna de las configuraciones de trabajo en uso.

A continuación un ejemplo de un archivo .fetchmailrc:

En este ejemplo, las opciones globales especifican que el usuario recibe un correo electrónico como último recurso (opción postmaster) y todos los errores de correo electrónico se envían al administrador de correo (opción bouncemail). La acción set dice a Fetchmail que esta línea contiene una opción global. Después se especifican dos servidores de correo electrónico, uno establecido para comprobar usando POP3, el otro intentando diversos protocolos hasta que encuentre uno que funcione. Dos usuarios están comprobando usando la segunda opción del servidor, pero todo el correo electrónico encontrado es enviado a la cola de correo del user1. Esto permite que múltiples buzones de correo sean comprobados sobre múltiples servidoress, mientras aparece una sola bandeja de entrada de MUAx. Cada información específica de usuario empieza con la acción user.

Fetchmail tiene numerosas opciones globales, de servidor y locales. Muchas de stas opciones se utilizan raramente o solo se emplean en situaciones muy específicas. La página de manual de fetchmail explica cada opción en detalle pero las más comunes se listan en las siguientes tres secciones.

Cada opción global debería ponerse en una única línea después de una acción set.

Las opciones de servidor se deben colocar en su propia línea en .fetchmailrc después de una acción poll o skip.

Las opciones de usuario se pueden colocar en sus propias líneas debajo de una opción de servidor o en las mismas líneas que la opción de servidor. En cualquier caso, las opciones definidas deben seguir a la opción user (definida a continuación).

La mayoría de las opciones de Fetchmail usadas en la línea de comando cuando ejecuta el comando fetchmail reflejan las opciones de configuración de .fetchmailrc. De este modo, Fetchmail puede ser usado con o sin un archivo de configuración. Estas opciones no son usadas en la línea de comandos por la mayoría de los usuarios porque es más fácil dejarlas en el archivo .fetchmailrc.

Puede haber momentos en que es deseable ejecutar el comando fetchmail con otras opciones para un propósito concreto. Es posible emitir opciones de comando para anular temporalmente un ajuste de .fetchmailrc que está originando un error. ya que cualquier opción especificada en la línea de comandos anula las opciones del archivo de configuración.

Ciertas opciones usadas después del comando fetchmail pueden proporcionar información importante.

Estas opciones son ocasionalmente útiles para anular los valores predeterminados que a menudo se encuentran en el archivo .fetchmailrc.

Se pueden encontrar más comandos y opciones de .fetchmailrc en la página de manual de fetchmail.

The action used if the recipe matches a particular message determines whether it is considered a delivering or non-delivering recipe. A delivering recipe contains an action that writes the message to a file, sends the message to another program, or forwards the message to another email address. A non-delivering recipe covers any other actions, such as a nesting block. A nesting block is a set of actions, contained in braces { }, that are performed on messages which match the recipe’s conditions. Nesting blocks can be nested inside one another, providing greater control for identifying and performing actions on messages.

When messages match a delivering recipe, Procmail performs the specified action and stops comparing the message against any other recipes. Messages that match non-delivering recipes continue to be compared against other recipes.

Flags are essential to determine how or if a recipe’s conditions are compared to a message. The egrep utility is used internally for matching of the conditions. The following flags are commonly used:

For a detailed list of additional flags, see the procmailrc man page.

Lockfiles are very useful with Procmail to ensure that more than one process does not try to alter a message simultaneously. Specify a local lockfile by placing a colon (:) after any flags on a recipe’s first line. This creates a local lockfile based on the destination file name plus whatever has been set in the LOCKEXT global environment variable.

Alternatively, specify the name of the local lockfile to be used with this recipe after the colon.

Special characters used before Procmail recipe conditions and actions change the way they are interpreted.

The following characters may be used after the asterisk character (*) at the beginning of a recipe’s condition line:

The following characters are used to perform special actions:

If no special character is used at the beginning of the action line, Procmail assumes that the action line is specifying the mailbox in which to write the message.

Procmail is an extremely flexible program, but as a result of this flexibility, composing Procmail recipes from scratch can be difficult for new users.

The best way to develop the skills to build Procmail recipe conditions stems from a strong understanding of regular expressions combined with looking at many examples built by others. A thorough explanation of regular expressions is beyond the scope of this section. The structure of Procmail recipes and useful sample Procmail recipes can be found at various places on the Internet. The proper use and adaptation of regular expressions can be derived by viewing these recipe examples. In addition, introductory information about basic regular expression rules can be found in the grep(1) man page.

The following simple examples demonstrate the basic structure of Procmail recipes and can provide the foundation for more intricate constructions.

A basic recipe may not even contain conditions, as is illustrated in the following example:

The first line specifies that a local lockfile is to be created but does not specify a name, so Procmail uses the destination file name and appends the value specified in the LOCKEXT environment variable. No condition is specified, so every message matches this recipe and is placed in the single spool file called new-mail.spool, located within the directory specified by the MAILDIR environment variable. An MUA can then view messages in this file.

A basic recipe, such as this, can be placed at the end of all rc files to direct messages to a default location.

The following example matched messages from a specific email address and throws them away.

With this example, any messages sent by spammer@domain.com are sent to the /dev/null device, deleting them.

The following recipe grabs email sent from a particular mailing list and places it in a specified folder.

Any messages sent from the tux-lug@domain.com mailing list are placed in the tuxlug mailbox automatically for the MUA. Note that the condition in this example matches the message if it has the mailing list’s email address on the From, Cc, or To lines.

Consult the many Procmail online resources available in Additional Resources for more detailed and powerful recipes.

Because it is called by Sendmail, Postfix, and Fetchmail upon receiving new emails, Procmail can be used as a powerful tool for combating spam.

This is particularly true when Procmail is used in conjunction with SpamAssassin. When used together, these two applications can quickly identify spam emails, and sort or destroy them.

SpamAssassin uses header analysis, text analysis, blacklists, a spam-tracking database, and self-learning Bayesian spam analysis to quickly and accurately identify and tag spam.

The easiest way for a local user to use SpamAssassin is to place the following line near the top of the ~/.procmailrc file:

The /etc/mail/spamassassin/spamassassin-default.rc contains a simple Procmail rule that activates SpamAssassin for all incoming email. If an email is determined to be spam, it is tagged in the header as such and the title is prepended with the following pattern:

The message body of the email is also prepended with a running tally of what elements caused it to be diagnosed as spam.

To file email tagged as spam, a rule similar to the following can be used:

This rule files all email tagged in the header as spam into a mailbox called spam.

Since SpamAssassin is a Perl script, it may be necessary on busy servers to use the binary SpamAssassin daemon (spamd) and the client application (spamc). Configuring SpamAssassin this way, however, requires root access to the host.

To start the spamd daemon, type the following command:

To start the SpamAssassin daemon when the system is booted, run:

Vea en Servicios y Demonios más información sobre como configurar servicios en Fedora.

To configure Procmail to use the SpamAssassin client application instead of the Perl script, place the following line near the top of the ~/.procmailrc file. For a system-wide configuration, place it in /etc/procmailrc:

Most Linux MUAs designed to check email on remote servers support SSL encryption. To use SSL when retrieving email, it must be enabled on both the email client and the server.

SSL is easy to enable on the client-side, often done with the click of a button in the MUA’s configuration window or via an option in the MUA’s configuration file. Secure IMAP and POP have known port numbers (993 and 995, respectively) that the MUA uses to authenticate and download messages.

Offering SSL encryption to IMAP and POP users on the email server is a simple matter.

First, create an SSL certificate. This can be done in two ways: by applying to a Certificate Authority (CA) for an SSL certificate or by creating a self-signed certificate.

To create a self-signed SSL certificate for IMAP or POP, change to the /etc/pki/dovecot/ directory, edit the certificate parameters in the /etc/pki/dovecot/dovecot-openssl.cnf configuration file as you prefer, and type the following commands, as root:

Once finished, make sure you have the following configurations in your /etc/dovecot/conf.d/10-ssl.conf file:

Issue the following command to restart the dovecot daemon:

Alternatively, the stunnel command can be used as an encryption wrapper around the standard, non-secure connections to IMAP or POP services.

The stunnel utility uses external OpenSSL libraries included with Fedora to provide strong cryptography and to protect the network connections. It is recommended to apply to a CA to obtain an SSL certificate, but it is also possible to create a self-signed certificate.

To create a self-signed SSL certificate, change to the /etc/pki/tls/certs/ directory, and type the following command:

Answer all of the questions to complete the process.

Once the certificate is generated, create an stunnel configuration file, for example /etc/stunnel/mail.conf, with the following content:

Once you start stunnel with the created configuration file using the stunnel /etc/stunnel/mail.conf command, it will be possible to use an IMAP or a POP email client and connect to the email server using SSL encryption.

For more information on stunnel, see the stunnel(8) man page or the documents in the /usr/share/doc/stunnel/ directory.