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, tabié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:

Message header analysis allows you to reject mail based on header contents. SMTP servers store information about an email’s journey in the message header. As the message travels from one MTA to another, each puts in a Received header above all the other Received headers. It is important to note that this information may be altered by spammers.

The above examples only represent a small part of what Sendmail can do in terms of allowing or blocking access. See the /usr/share/sendmail-cf/README file for more information and examples.

Since Sendmail calls the Procmail MDA when delivering mail, it is also possible to use a spam filtering program, such as SpamAssassin, to identify and file spam for users. See Spam Filters for more information about using SpamAssassin.

Using LDAP is a very quick and powerful way to find specific information about a particular user from a much larger group. For example, an LDAP server can be used to look up a particular email address from a common corporate directory by the user’s last name. In this kind of implementation, LDAP is largely separate from Sendmail, with LDAP storing the hierarchical user information and Sendmail only being given the result of LDAP queries in pre-addressed email messages.

However, Sendmail supports a much greater integration with LDAP, where it uses LDAP to replace separately maintained files, such as /etc/aliases and /etc/mail/virtusertables, on different mail servers that work together to support a medium- to enterprise-level organization. In short, LDAP abstracts the mail routing level from Sendmail and its separate configuration files to a powerful LDAP cluster that can be leveraged by many different applications.

The current version of Sendmail contains support for LDAP. To extend the Sendmail server using LDAP, first get an LDAP server, such as OpenLDAP, running and properly configured. Then edit the /etc/mail/sendmail.mc to include the following:

Next, recreate the /etc/mail/sendmail.cf file by running the m4 macro processor and again restarting Sendmail. See Common Sendmail Configuration Changes for instructions.

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

Although it is possible to pass all necessary options on the command line to check for email on a remote server when executing Fetchmail, using a .fetchmailrc file is much easier. Place any desired configuration options in the .fetchmailrc file for those options to be used each time the fetchmail command is issued. It is possible to override these at the time Fetchmail is run by specifying that option on the command line.

A user’s .fetchmailrc file contains three classes of configuration options:

Global options appear at the top of the .fetchmailrc file, followed by one or more server options, each of which designate a different email server that Fetchmail should check. User options follow server options for each user account checking that email server. Like server options, multiple user options may be specified for use with a particular server as well as to check multiple email accounts on the same server.

Server options are called into service in the .fetchmailrc file by the use of a special option verb, poll or skip, that precedes any of the server information. The poll action tells Fetchmail to use this server option when it is run, which checks for email using the specified user options. Any server options after a skip action, however, are not checked unless this server’s host name is specified when Fetchmail is invoked. The skip option is useful when testing configurations in the .fetchmailrc file because it only checks skipped servers when specifically invoked, and does not affect any currently working configurations.

The following is an example of a .fetchmailrc file:

In this example, the global options specify that the user is sent email as a last resort (postmaster option) and all email errors are sent to the postmaster instead of the sender (bouncemail option). The set action tells Fetchmail that this line contains a global option. Then, two email servers are specified, one set to check using POP3, the other for trying various protocols to find one that works. Two users are checked using the second server option, but all email found for any user is sent to user1's mail spool. This allows multiple mailboxes to be checked on multiple servers, while appearing in a single MUA inbox. Each user’s specific information begins with the user action.

Fetchmail has numerous global, server, and local options. Many of these options are rarely used or only apply to very specific situations. The fetchmail man page explains each option in detail, but the most common ones are listed in the following three sections.

Each global option should be placed on a single line after a set action.

Server options must be placed on their own line in .fetchmailrc after a poll or skip action.

User options may be placed on their own lines beneath a server option or on the same line as the server option. In either case, the defined options must follow the user option (defined below).

Most Fetchmail options used on the command line when executing the fetchmail command mirror the .fetchmailrc configuration options. In this way, Fetchmail may be used with or without a configuration file. These options are not used on the command line by most users because it is easier to leave them in the .fetchmailrc file.

There may be times when it is desirable to run the fetchmail command with other options for a particular purpose. It is possible to issue command options to temporarily override a .fetchmailrc setting that is causing an error, as any options specified at the command line override configuration file options.

Certain options used after the fetchmail command can supply important information.

These options are occasionally useful for overriding defaults often found in the .fetchmailrc file.

More commands and .fetchmailrc options can be found in the fetchmail man page.

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:

See Services and Daemons for more information on how to configure services in 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.