C: Q01 LOGOUT
    Connection closed.

5. Instalación y configuración de Postfix.

Es muy posible que tengamos ya instalado el paquete postfix, pues el paquete cyrus21-common depende de él o de mail-transport-agent. En cualquier caso, ejecutaremos el siguiente comando como root:

    apt-get install postfix postfix-tls postfix-doc postfix-pcre mime-codecs

Esto nos dejará instalados en el sistema todo lo necesario para la configuración posterior de Postfix. En el caso de que no tuviésemos el paquete postfix anteriormente, el script de postinstalación de este paquete nos mostrará unas pantallas que permiten configurar de un modo básico el servidor. Si ya estaba instalado el paquete, entonces deberemos llamar a ese asistente de modo manual mediante el comando:

    dpkg-reconfigure postfix

No es imprescindible usarlo, pues en el artículo se incluyen los ficheros completos de configuración, pero es un buen punto de partida. Estas son las respuestas usadas para el servidor de este artículo:

1. General type of configuration? Internet Site
2. Where should mail for root go? jsabater
3. Mail name? linuxsilo.net
4. Append .domain to simple addresses? No
5. Other destinations to accept mail for? linuxsilo.net, genma.linuxsilo.net, localhost.linuxsilo.net, localhost
6. Force synchronous updates on mail queue? No
7. Local networks? 127.0.0.0/8
8. Use procmail for local delivery? No
9. Mailbox size limit? 0
10. Local address extension character? +

5.1. El fichero /etc/postfix/master.cf

Usaremos el protocolo LMTP para la comunicación entre el MTA Postfix y Cyrus, pues es condición sinequa non para aprovechar las ventajas de Sieve. No es posible usar el transporte cyrus ni tampoco procmail y Sieve a la vez y, además, LMTP ofrece un rendimiento muy superior al uso directo de cyrdeliver para entregar el correo. Usaremos el socket /var/run/cyrus/socket/lmtp, por lo que debemos asegurarnos de que el servicio lmtpunix está habilitado en el fichero /etc/cyrus.conf y que Postfix tiene acceso a ese fichero (un socket, a efectos de permisos, funciona igual que un fichero). Asimismo, Cyrus requiere que las entregas por LMTP estén autenticadas, y asume que las que se hagan a través del socket Unix son de confianza y las preautentica como si vinieran del usuario postman (ficticio).

Por lo tanto, nos aseguraremos de que el fichero /etc/postfix/master.cf contenga esta línea:

    # service type  private unpriv  chroot  wakeup  maxproc command + args
    #               (yes)   (yes)   (yes)   (never) (100)
    # ==========================================================================
    lmtp      unix  -       -       n       -       -       lmtp
		

Nótese que el programa no se ejecuta en un chroot. En el caso de querer ejecutarlo en una jaula, el socket /var/run/cyrus/socket/lmtp debería ser accesible desde dentro de la jaula, bien creando un enlace duro (hard link), bien modificando la ruta en el fichero de configuración /etc/cyrus.conf.

5.2. El fichero /etc/postfix/main.cf

Para conseguir que Postfix entregue los correos a Cyrus a través de LMTP deberemos configurar un transporte en el primero. No es aconsejable usar cyrdeliver. La configuración del transporte en Postfix puede hacerse de diversas maneras (default_transport, transport_maps o mailbox_transport). En este artículo se usará mailbox_transport. Debido a que Postfix 2.x no pasa a minúsculas los destinatarios en las entregas por LMTP, es aconsejable usar la opción lmtp_downcase_rcpt: yes en el fichero /etc/imapd.conf. Para el uso de sockets Unix, el transporte de Postfix se especifica como lmtp:unix:/var/run/cyrus/socket/lmtp (en este ejemplo se usa la localización por defecto del socket de Cyrus en Debian, que se define en /etc/cyrus.conf).

Se necesita también un servicio lmtpd de Cyrus escuchando en ese socket, luego es conveniente asegurarse de que exista una línea como esta:

    lmtpunix    cmd="lmtpd" listen="/var/run/cyrus/socket/lmtp" prefork=0 maxchild=20

en la sección SERVICES del fichero /etc/cyrus.conf. Asimismo, es imprescindible asegurarse de que tanto Cyrus como Postfix pueden hablarse a través de ese socket. Los sockets Unix funcionan igual que los ficheros, por lo que esto se traduce en que tanto el usuario cyrus como el usuario postfix pueden leer y escribir en ese fichero. Aviso: debido a que Cyrus preautentica cualquier cosa que proceda del socket Unix, cualquiera que pueda escribir en él será capaz de inyectar correo directamente en Cyrus.

Úsese dpkg-statoverride para asegurarse que la configuración de los permisos del socket no es sobreescrita por los paquetes de Cyrus. Recuerde que Postfix ejecuta el transporte LMTP con el usuario definido en /etc/postfix/master.cf, por defecto postfix) y que si se quiere ejecutar dicho transporte en una jaula, el socket deberá encontrarse dentro de esa jaula. Para ello:

1. Cree un grupo llamado lmtp:
   $ addgroup lmtp
2. Agregue el usuario postfix a ese grupo:
   $ adduser postfix lmtp
3. Corrija los permisos del directorio del socket:
   $ dpkg-statoverride --force --update --add cyrus lmtp 750 /var/run/cyrus/socket
4. Reinicie Postfix y Cyrus:
   $ /etc/init.d/postfix restart
$ /etc/init.d/cyrus21 restart

Las modificaciones mínimas necesarias en Postfix nos dejan un /etc/postfix/main.cf como éste:

    setgid_group = postdrop
    smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
    biff = no
    append_dot_mydomain = no
    delay_warning_time = 4h
    command_directory = /usr/sbin
    daemon_directory = /usr/lib/postfix
    program_directory = /usr/lib/postfix
    myhostname = webmail.linuxsilo.net
    alias_maps = hash:/etc/aliases
    alias_database = hash:/etc/aliases
    mydestination = $myhostname, $mydomain, localhost.$mydomain, localhost
    myorigin = $mydomain
    mynetworks = 127.0.0.0/8
    mailbox_size_limit = 0
    recipient_delimiter = +
    local_recipient_maps =

    mailbox_transport = lmtp:unix:/var/run/cyrus/socket/lmtp

Donde /etc/mailname es:

    linuxsilo.net

Donde /etc/hostname es:

    genma

Donde /etc/hosts contiene:

    127.0.0.1       localhost       localhost.localdomain
    66.79.182.201  genma           genma.linuxsilo.net         webmail.linuxsilo.net

Y donde /etc/resolv.conf contiene:

    search linuxsilo.net
    nameserver 66.79.182.201

Nótese que la directiva local_recipient_maps = evita que Postfix busque el nombre de usuario y su contraseña en los usuarios de sistema, pues su valor por defecto es proxy:unix:passwd.byname $alias_maps.

Para comprobar el correcto funcionamiento de lo que tenemos hecho hasta el momento, primero nos aseguramos de que los servicios estén escuchando en los puertos correspondientes:

    $ netstat -an|grep LISTEN
    tcp        0      0 0.0.0.0:143             0.0.0.0:*               LISTEN     
    tcp        0      0 127.0.0.1:2000          0.0.0.0:*               LISTEN     
    tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN
		

El puerto 25 es de smtp, el 143 es de imap y el 2000 de sieve. Las correspondencias entre servicios y puertos pueden consultarse en el fichero /etc/services. Acto seguido podemos mandar un correo electrónico a un buzón local desde de la propia máquina local o desde una exterior (en negrita los comandos que tecleamos nosotros, genma es el hostname):

    $ telnet localhost 25
    Trying 127.0.0.1...
    Connected to localhost.
    Escape character is '^]'.
    220 webmail.linuxsilo.net ESMTP Postfix (Debian/GNU)
    HELO localhost
    250 webmail.linuxsilo.net
    MAIL FROM: <jsabater@genma>
    250 Ok
    RCPT TO: <jsabater@genma>
    250 Ok
    DATA
    354 End data with <CR><LF>.<CR><LF>
    Este es un mensaje de pruebas enviado a traves de telnet.
    .
    250 Ok: queued as 5F496BEE9
    QUIT
    221 Bye
    Connection closed by foreign host.


En estos momentos podemos ver que el correo ha sido enviado al buzón jsabater@genma ejecutando el comando:

    $ ls /var/spool/cyrus/mail/j/user/jsabater/
    1.  cyrus.cache  cyrus.header  cyrus.index

O, por supuesto, conectándonos mediante un cliente de correo que soporte IMAP y visualizando el correo. Nótese que si modificamos el fichero /etc/postfix/master.cf y en la línea donde se establece el smtp:

    smtp      inet  n       -       -       -       -       smtpd

añadimos el parámetro -v podremos ver un log del servidor de correo mucho más detallado (particularmente, recomiendo tail -f /var/log/mail.log | colorize, previa instalación del paquete colorize). La línea quedaría tal que:

    smtp      inet  n       -       -       -       -       smtpd -v

A continuación vamos a activar el uso de SASL en Postfix. El objetivo es autenticar los clientes smtp para que puedan hacer relay a través del servidor de correo. Para ello se modifica la opción smtpd_recipient_restrictions del fichero /etc/postfix/main.cf:

    smtp_sasl_auth_enable = no
    smtpd_sasl_auth_enable = yes
    smtpd_sasl_local_domain = genma
    smtpd_recipient_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_unauth_destination
    smtpd_sasl_security_options = noanonymous

De este modo, se permite hacer relay a los clientes sin autenticar que pertenezcan a las redes indicadas en mynetworks (habitualmente la red local) y a los clientes autenticados mediante el método SASL. Se rechazarán los que están sin autenticar. Además, podríamos requerir que fuese necesario utilizar TLS para autenticarse (smtpd_tls_auth_only = yes), pero eso lo haremos más adelante. Opcionalmente, mediante la opción smtpd_sasl_local_domain=genma se indica que compruebe el usuario entrando en /etc/sasldb2 con usuario@genma.

Para que Postfix sepa qué mecanismo usar a través de SASL hay que crear el fichero /etc/postfix/sasl/smtpd.conf con las siguientes líneas:

    pwcheck_method: saslauthd
    mech_list: plain login

Debido a que Postfix se ejecuta por defecto en una jaula (chrooted), localizada en /var/spool/postfix, no puede acceder al socket y demás ficheros del demonio de autenticación SASL, que se encuentran en /var/run/saslauthd. Por lo tanto, Postfix va a tratar de encontrarlos en /var/spool/postfix/var/run/saslauthd/. Entonces, tenemos dos opciones:

1. No ejecutar Postfix en un entorno chroot. Para ello, editamos el fichero /etc/postfix/master.cf y dejamos la línea del smpt tal y como esta:

    # ==========================================================================
    # service type  private unpriv  chroot  wakeup  maxproc command + args
    #               (yes)   (yes)   (yes)   (never) (100)
    # ==========================================================================
    smtp      inet  n       -       n       -       -       smtpd

Ejecutar Postfix, o cualquier otro servicio, enjaulado es un medida añadida de seguridad, pero la programación orientada a la seguridad de Postfix lo hacen ya de por sí un servidor muy seguro. Por otra parte, esta opción simplifica el mantenimiento, y eso siempre es bueno. Por lo tanto, no es una opción descartable en absoluto.

2. Usar enlaces duros. Siempre que el fichero original y el enlazado estén en la misma partición, podemos crear un hard link entre /var/run/saslauthd y /var/spool/postfix/var/run/saslauthd. Pero, debido a que estos ficheros son sobreescritos cada vez que se inicia el demonio saslauthd, debemos asegurarnos de que se vuelven a enlazar. Para ello, modificaremos el script de arranque en /etc/init.d/saslauthd y lo dejaremos como el que sigue (en negrita los cambios realizados):

    #!/bin/sh -e

    NAME=saslauthd
    DAEMON="/usr/sbin/${NAME}"
    DESC="SASL Authentication Daemon"
    DEFAULTS=/etc/default/saslauthd
    PWDIR=/var/run/saslauthd
    PIDFILE="/var/run/${NAME}/saslauthd.pid"

    mklinks() {
        sleep 1
        cd /var/spool/postfix/var/run/saslauthd/
        ln /var/run/saslauthd/* .
        echo "Links inside the Postfix jail have been created."
    }

    rmlinks() {
        rm -f /var/spool/postfix/var/run/saslauthd/*
        echo "Links inside the Postfix jail have been removed."
    }

    createdir() {
        # $1 = user
        # $2 = group
        # $3 = permissions (octal)
        # $4 = path to directory
        [ -d "$4" ] || mkdir -p "$4"
        chown -c -h "$1:$2" "$4"
        chmod -c "$3" "$4"
    }

    test -f "${DAEMON}" || exit 0

    # Source defaults file; edit that file to configure this script.
    if [ -e "${DEFAULTS}" ]; then
        . "${DEFAULTS}"
    fi

    # If we're not to start the daemon, simply exit
    if [ "${START}" != "yes" ]; then
        exit 0
    fi

    # If we have no mechanisms defined
    if [ "x${MECHANISMS}" = "x" ]; then
        echo "You need to configure ${DEFAULTS} with mechanisms to be used"
        exit 0
    fi

    # Add our mechanimsms with the necessary flag
    PARAMS="${PARAMS} -a ${MECHANISMS}"

    START="--start --quiet --pidfile ${PIDFILE} --startas ${DAEMON} --name ${NAME} -- ${PARAMS}"

    # Consider our options
    case "${1}" in
        start)
            echo -n "Starting ${DESC}: "
            dir=`dpkg-statoverride --list $PWDIR`
            test -z "$dir" || createdir $dir
            if start-stop-daemon ${START} >/dev/null 2>&1 ; then
                echo "${NAME}."
            else
                if start-stop-daemon --test ${START} >/dev/null 2>&1; then
                    echo "(failed)."
                    exit 1
                else
                    echo "${DAEMON} already running."
                    exit 0
                fi
            fi
            mklinks
            ;;
        stop)
            echo -n "Stopping ${DESC}: "
            if start-stop-daemon --stop --quiet --pidfile "${PIDFILE}" \
            --startas ${DAEMON} --retry 10 --name ${NAME} \
            >/dev/null 2>&1 ; then
                echo "${NAME}."
            else
                if start-stop-daemon --test ${START} >/dev/null 2>&1; then
                    echo "(not running)."
                    exit 0
                else
                    echo "(failed)."
                    exit 1
                fi
            fi
            rmlinks
            ;;
        restart|force-reload)
            $0 stop
            exec $0 start
            ;;
        *)
            echo "Usage: /etc/init.d/${NAME} {start|stop|restart|force-reload}" >&2
            exit 1
            ;;
    esac

    exit 0

De este modo los enlaces se alterarán adecuadamente cada vez que se pare, inicie o reinicie el demonio. Aunque antes es preciso crear el directorio donde se harán los enlaces en el interior de la jaula de Postfix:

    mkdir -p /var/spool/postfix/var/run/saslauthd
    chown root.sasl /var/spool/postfix/var/run/saslauthd

Tras reiniciar el servidor de autenticación (/etc/init.d/saslauthd restart) y el de correo (/etc/init.d/postfix restart) ya podemos comprobar el buen funcionamiento de la autenticación SASL. Primero tendremos que generar la cadena alfanumérica que nos autenticará durante el proceso de comunicación. Para ello necesitaremos soporte para Perl y nuestro nombre de usuario y contraseña definidos en la base de datos /etc/sasldb2. Ejecutamos entonces:

    perl -MMIME::Base64 -e 'print encode_base64("username\0username\0password");'

sustituyendo username por nuestro identificador de usuario en las dos ocasiones y password por nuestra contraseña. En la línea siguiente aparecerá una cadena alfanumérica que usaremos en seguida. Por ejemplo, para la combinación jsabater/jsabater sería anNhYmF0ZXIAanNhYmF0ZXIAanNhYmF0ZXI=. A continuación se muestra la comprobación del buen funcionamiento usando autenticación PLAIN y la cadena obtenida como ejemplo (en negrita lo que nosotros tecleamos):

    $ telnet localhost 25
    Trying 127.0.0.1...
    Connected to localhost.
    Escape character is '^]'.
    220 webmail.linuxsilo.net ESMTP Postfix (Debian/GNU)
    EHLO localhost
    250-webmail.linuxsilo.net
    250-PIPELINING
    250-SIZE 10240000
    250-VRFY
    250-ETRN
    250-AUTH PLAIN
    250 8BITMIME
    AUTH PLAIN anNhYmF0ZXIAanNhYmF0ZXIAanNhYmF0ZXI=
    235 Authentication successful
    QUIT
    221 Bye
    Connection closed by foreign host.

5.3. Autenticación y autorización.

La autenticación es el mecanismo por el cual los sistemas pueden identificar con seguridad a los usuarios. Los sistemas de autenticación proporcionan respuestas a las siguientes preguntas:

• ¿Quién es el usuario?
• ¿Es el usuario quien realmente pretende ser?

Un método de autenticación puede ser tan sencillo (e inseguro) como una contraseña en texto plano (servidores de FTP antiguos) o tan complicados como el sistema Kerberos. En cualquier caso, sin embargo, los sistemas de autenticación dependen de alguna pequeña porción de información conocida (o disponible) sólo por el individuo que está autenticándose y el sistema de autenticación (un secreto compartido). Esa información puede ser la clásica contraseña, algún tipo de propiedad física del individuo (huellas dactilares, patrón de retina, etc), o algunos datos derivados (como es el caso de los llamados sistemas de tarjeta inteligente - smartcard). De modo que pueda verificarse la identidad de un usuario, el sistema de autenticación típicamente solicita al usuario que proporcione esa información única (su contraseña, sus huellas, etc.) y, si el sistema de autenticación puede verificar que ese secreto compartido se ha presentado correctamente, entonces el usuario se considera autenticado.

La autorización, en contraste, es el mecanismo por el cual un sistema determina qué nivel de acceso un usuario particular que ya se ha autenticado debería tener sobre los recursos controlados por el sistema. Por ejemplo, un sistema de gestión de bases de datos puede estar diseñado para proporcionar a ciertos individuos la capacidad de recuperar información de la base de datos pero no la capacidad de cambiar los datos almacenados, mientras que podría dar a otros individuos esa capacidad. Los sistemas de autorización responden a las siguientes preguntas:

• ¿Está autorizado el usuario X a acceder al recurso R?
• ¿Está autorizado el usuario X a realizar la operación P?
• ¿Está autorizado el usuario X a realizar la operación P sobre el recurso R?

5.4. Alias virtuales.

La mayoría de los servidores de correo son el destino final de unos pocos dominios. Estos incluyen los hostnames y las [direcciones IP] de la máquina en la que se ejecuta Postfix, y en ocasiones también el dominio padre del hostname. En adelante se considerarán dominios canónicos estos dominios. En este artículo, el servidor tiene como dominios canónicos localhost, localhost.linuxsilo.net, genma.linuxsilo.net y linuxsilo.net, aunque realmente sólo vayan a usarse el primero y el último (los dos de en medio son equivalentes al primero).

Además de los dominios canónicos, Postfix puede configurarse para ser el destino final de otros dominios adicionales. A estos dominios se les llama hospedados, pues no tienen relación directa con el nombre de la máquina. Los dominios hospedados se implementan habitualmente con la directiva virtual_alias_domain o con la directiva virtual_mailbox_domain. Asimismo, Postfix puede configurarse como servidor secundario o de seguridad en un registro MX de DNS. En este caso, Postfix no es el destino final de estos dominios, sino que tan sólo guarda temporalmente el correo del servidor principal cuando éste está caído, y se lo reenvía cuando vuelve a estar disponible. Esta función se implementa con la directiva relay_domain.

Siguiendo la línea del artículo, interesa configurar el servidor para que acepte correo de direcciones de dominios que no son el principal y lo redirija a cuentas locales. Por ejemplo, dado otro dominio de nuestra propiedad, bsdsilo.net, tenemos una dirección de contacto para ese dominio que es info@bsdsilo.net y queremos que el correo se reciba en jsabater@linuxsilo.net. Esto se consigue usando la directiva virtual_alias_maps. Entonces, en el fichero /etc/postfix/main.cf añadiríamos las líneas:

    virtual_alias_maps = hash:/etc/postfix/virtual
    virtual_alias_domains = /etc/postfix/vdomains

Y crearíamos el fichero /etc/postfix/virtual tal que:

    info@bsdsilo.net    jsabater

Y el fichero /etc/postfix/vdomains tal que:

    bsdsilo.net

De esta manera, el correo recibido para el alias virtual info@bsdsilo.net sería reenviado al buzón local jsabater, que equivale a jsabater@linuxsilo.net. Si dejamos la configuración tal que así, cualquier correo que vaya para una dirección diferente a info@bsdsilo.net será rechazado con el clásico mensaje de error 550-Mailbox unknown. Si deseamos recoger todo el correo "perdido", podemos establecer una sentencia que en inglés se conoce como catch-all, tal que:

    @bsdsilo.net    jsabater

5.5. Dominios virtuales.

Una opción muy común en la configuración de servidores de correo electrónico es hospedar las cuentas de correo de varios dominios. Estos dominios son, efectivamente, tratados como dominios virtuales pero, a diferencia de los alias virtuales, es preciso disponer de un buzón de correo para las cuentas de cada dominio. El uso de dominios virtuales y alias virtuales es complementario, no exclusivo. Siguiendo las pautas establecidas anteriormente en este artículo, un ejemplo de configuración del fichero main.cf sería el siguiente:

    virtual_transport = lmtp:unix:/var/run/cyrus/socket/lmtp
    virtual_mailbox_domains = bsdsilo.net
    virtual_mailbox_maps = hash:/etc/postfix/vmailbox
    virtual_alias_maps = hash:/etc/postfix/virtual

Donde /etc/postfix/vmailbox sería:

    info@bsdsilo.net    jsabater
    sales@bsdsilo.net   rgalli
    support@bsdsilo.net asimon
    # Descoméntese la siguiente línea para obtener un efecto "catch-all"
    # @bsdsilo.net      asimon

Y donde /etc/postfix/virtual sería:

    postmaster@bsdsilo.net    postmaster

La directiva virtual_mailbox_domains le dice a Postfix que bsdsilo.net debe procesarse a través del transporte especificado en el valor de virtual_transport, en este caso el socket UNIX de Cyrus. Si se omite la configuración de virtual_mailbox_domains tanto puede ocurrir que Postfix rechace el correo (relay access denied) como que no sea capaz de enviarlo (mail for bsdsilo.net loops back to myself).

Nunca debe listarse un dominio virtual de virtual_mailbox_domain en mydestination. Y nunca debe listarse un dominio virtual de virtual_mailbox_domain como alias de dominio virtual en virtual_alias_maps.

El parámetro virtual_mailbox_maps especifica una tabla de búsqueda con todos los destinatarios válidos. En el ejemplo de más arriba, info@bsdsilo.net, sales@bsdsilo.net y support@bsdsilo.net se listan como direcciones válidas, mientras que el correo dirigido a cualquier otro destinatario será rechazado con el mensaje de error User unknown. Por supuesto, tal y como puede apreciarse por el comentario en el ejemplo, puede crearse una redirección para todo el correo que no tenga como destinatario alguno de los buzones especificados anteriormente para ese dominio.

Tal y como se explica en el punto 4 de este artículo, deberá crearse una cuenta en la base de datos de usuarios para estos buzones, tal que:

    $ saslpasswd2 -c jsabater -u bsdsilo.net
    $ saslpasswd2 -c rgalli -u bsdsilo.net
    $ saslpasswd2 -c asimon -u bsdsilo.net

Además, deberán crearse también los buzones:

    $ cyradm --user cyrus localhost
    localhost> cm user.jsabater@bsdsilo.net
    localhost> cm user.rgalli@bsdsilo.net
    localhost> cm user.asimon@bsdsilo.net
    localhost> quit

Por último, tal y como puede apreciarse en el ejemplo, es posible mezclar alias virtuales y buzones virtuales. En este caso se está usando la directiva virtual_alias_maps para redirigir la cuenta del postmaster del dominio bsdsilo.net al postmaster local. Puede usarse el mismo mecanismo para redirigir cualquier dirección a un buzón local o a una dirección remota.

Nota: este ejemplo asume que, en el main.cf, $myorigin aparece listado en los valores de mydestination. Si no es así, debe especificarse un valor de dominio explícito en la parte derecha de las entradas de la tabla de alias virtuales o el correo será enviado al dominio incorrecto.

Cada vez que se modifiquen los ficheros /etc/postfix/vmailbox o /etc/postfix/virtual debe ejecutarse el comando postmap /etc/postfix/vmailbox o postmap /etc/postfix/virtual, respectivamente. Si se cambia el /etc/postfix/main.cf debe ejecutarse /etc/init.d/postfix reload.

6. Cifrado del canal de comunicación usando TLS.

Cuando se está estableciendo una conexión TLS, la máquina que establece la conexión tiene que validarse a sí mismo. Esto es debido a que alguien podría interceptar la comunicación y establecer una conexión cifrada. La máquina remota posiblemente no se daría cuenta y pasaría la información con normalidad. Por ello, los certificados se usan para proporcionar información única que prueba que la máquina que está cifrando la comunicación es realmente aquella con la cuál nuestra máquina quiere hablar.

Sería correcto pensar que cualquier servidor malicioso podría emitir un certificado si no fuera por el pequeño detalle que falta mencionar: cada certificado que es emitido proporciona información sobre una autoridad que dará validez el certificado enviado al establecer una conexión TLS.

Añadir cifrado al canal de transmisión es muy sencillo una vez tenemos tanto Postfix como Cyrus configurados adecuadamente, según se ha descrito en los puntos anteriores. El primer paso será instalar el paquete openssl:

    apt-get install openssl

6.1. La generación de los certificados.

Si se pretende ofrecer servicios de correo electrónico a terceros, es más que recomendable usar un certificado que esté firmado por una autoridad certificadora (CA, del inglés Certificate Authority) reconocida, como Verisign o Thawte. Pero si sólo se va a usar en la red local de una empresa pequeña o mediana, o simplemente se quiere disfrutar de las comunicaciones cifradas a título personal, posiblemente sea suficiente crear una autoridad certificadora nosotros mismos y firmar con ella el certificado. En cualquier caso, ambas soluciones son igual de seguras; es una cuestión de formalidad ante el cliente o usuario. El proceso básico a seguir se resume en los siguientes puntos:

1. Crear el certificado.
2. Una autoridad certificadora debe firmar el certificado.
3. Instalar el certificado.

Para crear los certificados pueden seguirse los pasos descritos en el Lutz's very short course on being your own CA o en el Postfix SMTP AUTH (and TLS) HOWTO. En estos tutoriales se explica, además, como actuar como autoridad certificadora y poder firmar así los certificados. Básicamente, los pasos a seguir son tres:

1. Crear una nueva autoridad certificadora: /usr/lib/ssl/misc/CA.pl -newca
2. Realizar la petición de un certificado: /usr/lib/ssl/misc/CA.pl -newreq-nodes
3. Firmar el certificado: /usr/lib/ssl/misc/CA.pl -sign

Con la salvedad de que no debemos añadir una palabra de paso al certificado para que el servidor no se quede bloqueado esperándola al iniciarse. Luego deberemos copiar tres de los ficheros resultantes del proceso al subdirectorio /etc/postfix/ssl/:

• cacert.pem: el certificado de la autoridad certificadora, al cual se remitirá al cliente cuando quiera comprobar la autenticidad del certificado que le ha enviado nuestro servidor Postfix.
• newcert.pem: el certificado público que enviaremos al cliente para establecer la comunicación segura.
• newreq.pem: el certificado privado que almacenaremos en el servidor y del cual la parte realmente importante es la clave, que debe permanecer secreta.

Ejecutaremos entonces los siguientes comandos:

    mkdir /etc/postfix/ssl
    cp demoCA/cacert.pem /etc/postfix/ssl/
    cp newcert.pem /etc/postfix/ssl/
    cp newreq.pem /etc/postfix/ssl/
    chown root /etc/postfix/ssl/newreq.pem
    chmod 400 /etc/postfix/ssl/newreq.pem

Una solución intermedia entre crear nuestra propia autoridad certificadora y el pago de una ingente cantidad de dinero a una reconocida comercialmente, es el uso de una llevada por la comunidad que emita certificados al público de manera gratuita, por ejemplo CAcert.org. Si solicitamos el alta en su página web, añadimos nuestro dominio y solicitamos que nos firme el CSR (Certificate Signing Request), tan sólo deberemos entonces instalar su certificado raíz en cada máquina para evitar los mensajes de aviso de los clientes de correo. Más información en la documentación de CAcert.org.

6.2. Modificaciones en Postfix.

Tan sólo es necesario editar el fichero /etc/postfix/main.cf y agregar las siguientes líneas:

    smtpd_use_tls = yes
    # smtpd_tls_auth_only = yes
    smtpd_tls_key_file = /etc/postfix/ssl/newreq.pem
    smtpd_tls_cert_file = /etc/postfix/ssl/newcert.pem
    smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem

    smtpd_tls_loglevel = 3
    smtpd_tls_received_header = yes
    smtpd_tls_session_cache_timeout = 3600s
    tls_random_source = dev:/dev/urandom

De este modo restringimos que las autenticaciones al envío se puedan hacer únicamente usando TLS (esta línea aparece comentada de momento). Además, obligamos a que todas las comunicaciones con el demonio smtpd se hagan a través de TLS. Tras reiniciar el servidor Postfix, ya podemos comprobar el correcto funcionamiento del mismo:

    $ telnet localhost 25
    Trying 127.0.0.1...
    Connected to localhost.
    Escape character is '^]'.
    220 webmail.linuxsilo.net ESMTP Postfix (Debian/GNU)
    EHLO localhost
    250-webmail.linuxsilo.net
    250-PIPELINING
    250-SIZE 10240000
    250-VRFY
    250-ETRN
    250-STARTTLS
    250-AUTH LOGIN PLAIN
    250-AUTH=LOGIN PLAIN
    250 8BITMIME
    STARTTLS
    220 Ready to start TLS
    QUIT
    QUIT
    Connection closed by foreign host.

Entonces, si queremos asegurarnos de que las autenticaciones se realicen únicamente sobre un canal cifrado mediante el protocolo TLS, debemos descomentar la línea que reza smtpd_tls_auth_only = yes. Tras reiniciar el servidor, podemos observar las diferencias:

    $ telnet localhost 25
    Trying 127.0.0.1...
    Connected to localhost.
    Escape character is '^]'.
    220 webmail.linuxsilo.net ESMTP Postfix (Debian/GNU)
    EHLO localhost
    250-webmail.linuxsilo.net
    250-PIPELINING
    250-SIZE 10240000
    250-VRFY
    250-ETRN
    250-STARTTLS
    250 8BITMIME
    STARTTLS
    220 Ready to start TLS
    QUIT
    QUIT
    Connection closed by foreign host.

Nótese que el servidor no ofrece los métodos de autenticación antes de que se haya establecido el canal seguro. Asimismo, una vez que nos hemos cerciorado de que todo funciona adecuadamente, podemos reducir el nivel de logging cambiando el valor 3 por 1 en la opción smtpd_tls_loglevel.

6.3. Modificaciones en Cyrus IMAP.

Para activar el cifrado del canal de comunicaciones en Cyrus IMAP deberemos modificar dos ficheros, /etc/cyrus.conf y /etc/imapd.conf. En el primero añadiremos el servicio imaps a la lista de los que deben iniciarse con el sistema Cyrus, mientras que en el segundo configuraremos varios parámetros relacionados con TLS y la localización de los certificados en el disco duro. Entonces, en la sección SERVICES del fichero /etc/cyrus.conf tan sólo debemos descomentar una línea, de modo que quede como la que sigue:

    imaps           cmd="imapd -s -U 30" listen="imaps" prefork=0 maxchild=100

Y cambiar la que antes teníamos activa para soportar IMAP sin SSL solo a través de la interfaz localhost (necesario para usar cyradm), de modo que forcemos al usuario a usar un canal cifrado:

    imap           cmd="imapd -U 30" listen="localhost:imap" prefork=0 maxchild=100

Las líneas a descomentar o modificar del fichero /etc/imapd.conf son las siguientes:

    tls_cert_file: /etc/ssl/certs/cyrus-global.pem
    tls_key_file: /var/imap/cyrus-global.key
    tls_ca_file: /etc/ssl/certs/cyrus-imapd-ca.pem
    tls_ca_path: /etc/ssl/certs
    tls_session_timeout: 1440
    tls_cipher_list: TLSv1:SSLv3:SSLv2:!NULL:!EXPORT:!DES:!LOW:@STRENGTH

Puede apreciarse que la parte privada del certificado se encuentra en un directorio específicamente creado para tal propósito, /var/imap. Esto es debido a que el usuario cyrus debe tener permisos de lectura sobre él, mientras que su ubicación estándar, que sería /etc/ssl/private no nos permite esa posibilidad. En este artículo se ha usado el mismo certificado para Postfix que para Cyrus, siendo necesario ejecutar los siguientes comandos:

    mkdir /var/imap
    chown cyrus:mail /var/imap
    chmod 750 /var/imap
    cp /etc/postfix/ssl/newcert.pem /etc/ssl/certs/cyrus-global.pem
    cp /etc/postfix/ssl/cacert.pem /etc/ssl/certs/cyrus-imapd-ca.pem
    cp /etc/postfix/ssl/newreq.pem /var/imap/cyrus-global.key
    chown cyrus:mail /var/imap/cyrus-global.key
    chmod 600 /var/imap/cyrus-global.key

Téngase en cuenta que, tal y como hemos configurado el servidor Postfix (smtpd), si al enviar un correo lo hacemos a un servidor que soporta (ofrece) TLS sobre el protocolo smtp, nuestro servidor tratará de usar cifrado sobre el canal. Por lo tanto, es muy conveniente, por no decir imprescindible, tener un certificado firmado por una autoridad certificadora reconocida. Tras reiniciar el servidor Cyrus (/etc/init.d/cyrus21 restart) podemos comprobar que los cambios han surgido efecto:

    $ imtest -a jsabater -w <contraseña> -m login -s localhost
    verify error:num=20:unable to get local issuer certificate
    verify error:num=21:unable to verify the first certificate
    TLS connection established: TLSv1 with cipher AES256-SHA (256/256 bits)
    S: * OK genma Cyrus IMAP4 v2.1.16-IPv6-Debian-2.1.16-6 server ready
    C: C01 CAPABILITY
    S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES IDLE AUTH=LOGIN AUTH=PLAIN LISTEXT LIST-SUBSCRIBED ANNOTATEMORE
    S: C01 OK Completed
    C: L01 LOGIN jsabater {8}
    S: + go ahead
    C: <omitted>
    S: L01 OK User logged in
    Authenticated.
    Security strength factor: 256

Pulsando Ctrl+C abandonaremos el programa de pruebas:

    C: Q01 LOGOUT
    Connection closed.

CAcert es una organización certificadora sin ánimo de lucro que pretende promocionar el conocimiento y la educación en la seguridad informática a través del uso de cifrado, especialmente la familia X.509 de estándares. Esta organización puede firmar nuestro certificado digital, pero aún no es una autoridad certificadora reconocida, por lo cual será siempre necesario instalar su certificado raíz en la aplicación cliente. En cualquier caso, en la actualidad no hay diferencia entre usar un certificado firmado por esta asociación o por una autoridad certificadora creada por nosotros mismos, pero quizás en el futuro esto cambie.

7. El uso de Sieve.

Para poder sacar partido al uso de scripts en el lado del servidor es preciso utilizar LMTP. Para activar un script de Sieve en el servidor es preciso ejecutar un comando en el mismo servidor, a menos que se use algún tipo de interfaz gráfica que agilice la tarea. Cada usuario puede subir y activar los scripts generados por el mismo (siempre y cuando tenga acceso con una cuenta en el servidor). Por ejemplo, dado el script jsabater.sieve, ejecutaríamos los siguientes comandos desde el directorio donde se encuentre el script:

    $ sieveshell -u jsabater localhost
    connecting to localhost
    Please enter your password:
    > put jsabater.sieve
    > activate jsabater.sieve
    > ls
    jsabater.sieve <- active script
    > quit

Acto seguido se muestra un script de ejemplo que clasifica el correo entrante en varias subcarpetas, usando las cabeceras propias de algunas listas de correo, el remitente del mensaje o el asunto del mismo.

    require "fileinto";
    if header :contains "List-Id" "bulmailing.bulma.net" {
        fileinto "Inbox.Bulmailing";
    }
    elsif header :contains "List-Post" "postfix-users@postfix.org" {
        fileinto "Inbox.Postfix";
    }
    elsif header :contains "From" "sylvie@linuxsilo.net" {
        fileinto "Inbox.Sylvie";
    }
    elsif address :contains :all ["From"] "newsletter@linuxsilo.net" {
        fileinto "Inbox.Newsletters";
    }
    elsif header :contains "Subject" "firebird-support" {
        fileinto "Inbox.Firebird";
    }
    elsif header :contains "X-Mailing-List" "debian-powerpc@lists.debian.org" {
        fileinto "Inbox.Debianppc"
    }
    elsif header :is "X-Spam-Flag" "YES" {
        fileinto "Inbox.Junk";
    }
    else {
        fileinto "Inbox";
    }

8. Filtros de contenidos.

SpamAssassin y ClamAV son dos filtros de contenidos que serán utilizados desde Postfix a través de Amavisd-new. Se instalarán y configurarán primero estos filtros y después el interfaz Amavisd-new entre ellos y el servidor.

8.1. SpamAssassin.

Ejecutaremos el siguiente comando como root:

    apt-get install spamassassin spamc

Debido a que la configuración con la cual se ejecuta SpamAssassin al ser llamado desde Amavisd-new es la que se establece en el fichero de configuración de este último, no tendremos que tocar nada. En el fichero /etc/default/spamassassin podemos observar que el demonio de SpamAssassin no se ejecuta por defecto, que es el comportamiento que nos conviene:

    ENABLED=0
    OPTIONS="-c -m 10 -a -H"

La ventaja principal de ejecutarlo como demonio sería su eficiencia, pues las comunicaciones se establecerían a través del puerto 783 en lugar de tener que arrancar un ejecutable cada vez que se tuviera que analizar un correo. En cambio, se correrían ciertos riesgos de seguridad, pues el paquete Debian nos deja una configuración por defecto que hace que se ejecute como root (en la documentación se explica como cambiarlo para que se ejecute como un usuario no privilegiado). Entonces, una posible vulnerabilidad a causa de un error en el código podría darnos permisos de root.

En cambio, debido a que se usará SpamAssassin a través de Amavisd-new, éste será llamado a través del módulo de Perl Mail::SpamAssassin, manteniendo Perl el motor de reglas siempre cargado en memoria y consiguiendo la misma eficiencia que con el demonio. De hecho, este es el comportamiento por defecto de los paquetes Debian de estos dos softwares.

Si se desean utilizar los filtros bayesianos del SpamAssassin, y es muy recomendable hacerlo si se quiere tener un alto porcentaje de acierto, será preciso entrenarlo. Según el manual, varios miles de mensajes deben ser proporcionados a SpamAssassin, tanto de spam como de ham (correo no-spam). Para ello se usa la herramienta sa-learn (man sa-learn para su documentación). Con sa-learn --spam <directorio> lo instruimos para que recoja información de correos que sabemos con certeza que son spam, y con sa-learn --ham <directorio> lo instruimos para que recoja información de correos que sabemos con certeza que no son spam. Asimismo, sa-learn tiene una opción que permite pasarle un fichero que contenga una lista de directorios, uno en cada línea, en los cuales buscará el tipo de correo que le especifiquemos.

Este parámetro, --folders=file, es muy útil si queremos recoger una lista de buzones de usuarios que sabemos con seguridad que sólo guardan spam o ham y utilizarlos para continuamente mejorar nuestros filtros desde un job del cron, pues esta herramienta mantiene una lista de los correos que ya ha analizado y se los salta cada vez, haciendo este proceso bastante eficiente. Es importante tener en cuenta que la base de datos bayesiana se encuentra en /var/lib/amavis/.spamassassin, pues SpamAssassin es llamado a través de Amavisd-new (módulo Mail::SpamAssassin de Perl). Por lo tanto, cuando queramos usar la herramienta sa-learn deberemos hacerlo siempre con el usuario amavis. De hecho, éste es el motivo por el cuál se estableció la máscara de los ficheros y subdirectorios de Cyrus a 027, de modo que, si añadimos el usuario amavis al grupo mail -adduser amavis mail-, se podrán leer esos mails considerados ham o spam. Asimismo, es posible que los directorios y ficheros que se crearon por los scripts de instalación antes de realizar el cambio en /etc/imapd.conf deban ver sus permisos modificados. El comando find nos será de gran utilidad para este propósito, por ejemplo:

    cd /var/spool/cyrus/mail
    find -type f -exec chmod g+rw '{}' ';'
    find -type d -exec chmod g+rwx '{}' ';'

Nos actualizará los permisos de forma adecuada en una instalación exacta a la que se ha realizado en el artículo.

En cualquier caso, como administrador y por propia experiencia, no recomiendo dejar en manos de los usuarios la distinción de lo que es spam y lo que es ham.

8.2. Clam Antivirus.

Ejecutaremos los siguientes comandos como root (teniendo el repositorio non-free en nuestro /etc/apt/sources.list):

    apt-get install unrar lha arj unzoo zip unzip bzip2 gzip cpio file lzop
    apt-get install clamav clamav-base clamav-daemon clamav-freshclam libclamav1

Como método de actualización de la lista y los patrones de los virus del clamav-freshclam recomiendo seleccionar daemon y como mirror para la descarga el más cercano a la localización geográfica de nuestro servidor. En la pregunta Number of freshclam updates per day, con 12 tenemos actualizada cada dos horas nuestra lista de virus. Y contestamos que sí a al pregunta de Should clamd be notified after updates?. No es preciso modificar ningún fichero de configuración, pues la instalación ya nos deja todo lo que necesitamos funcionando adecuadamente, pero si observamos el siguiente error en el /var/log/mail.log:

    genma amavis[13147]: (13147-01) Clam Antivirus-clamd FAILED - unknown status: /var/lib/amavis/amavis-20040818T163812-13147/parts: Access denied. ERROR\n
    genma amavis[13147]: (13147-01) WARN: all primary virus scanners failed, considering backups

Entonces deberemos añadir el usuario clamav al grupo amavis, tal que:

    adduser clamav amavis

Y la directiva AllowSupplementaryGroups al fichero /etc/clamav/clamav.conf.

8.3. Amavisd-new.

Tan sólo es necesario instalar un paquete, como root:

    apt-get install amavisd-new

El fichero de configuración de Amavisd-new es bastante largo, pero tan sólo es necesario realizar unos pocos cambios a la configuración que viene por defecto. En este artículo se propone una configuración que marca los correos que son identificados como spam, pero los deja llegar a su destinatario. Entonces, mediante Sieve, es muy fácil añadir una línea que mueve directamente los correos con cierta cabecera específica a una carpeta genérica de spam. Así, el usuario tan sólo tiene que revisar periódicamente los correos que hay en esa carpeta y, viendo que no hay ningún falso positivo, borrarlos. En caso de haber falsos positivos, es preciso instruir a SpamAssassin para que olvide (opción forget de sa-learn) ese correo como spam.

SpamAssassin realimenta automáticamente sus filtros bayesianos con los correos que son identificados como spam y que superan un cierto umbral. Pero es conveniente seguir entrenándolo con aquellos correos que son spam y que se le han pasado por alto, los llamados falsos negativos. Este proceso es necesario pero delicado, pues una mala instrucción puede deshacernos casi irremediablemente el trabajo hecho hasta la fecha en nuestra base de datos bayesiana.

A continuación se presentan las líneas del fichero /etc/amavis/amavisd.conf que necesitan ser modificadas, en el formato definitivo (es decir, con las modificaciones ya realizadas):

    $mydomain = 'linuxsilo.net';
    $myhostname = 'webmail.linuxsilo.net';
    # @bypass_spam_checks_acl = qw( . );
    $final_spam_destiny = D_PASS;
    $warnbannedsender = 1;
    $warnbadhsender = 1;
    # $virus_quarantine_to = 'virus-quarantine';
    $virus_quarantine_to = "virus-quarantine\@$mydomain";
    # $sa_spam_subject_tag = '***SPAM*** '; #
    $banned_filename_re = new_RE(
    # qr'^UNDECIPHERABLE$',
      qr'\.[^.]*\.(exe|vbs|pif|scr|bat|cmd|com|dll)$'i,
      qr'[{}]',
    # qr'.\.(exe|vbs|pif|scr|bat|cmd|com)$'i,
      qr'.\.(ade|adp|bas|bat|chm|cmd|com|cpl|crt|exe|hlp|hta|inf|ins|isp|js|
             jse|lnk|mdb|mde|msc|msi|msp|mst|pcd|pif|reg|scr|sct|shs|shb|vb|
             vbe|vbs|wsc|wsf|wsh)$'ix,
      qr'.\.(mim|b64|bhx|hqx|xxe|uu|uue)$'i,
    # qr'^\.(zip|lha|tnef|cab)$'i,
      qr'^\.exe$'i,
      qr'^application/x-msdownload$'i,
      qr'^application/x-msdos-program$'i,
      qr'^message/partial$'i, qr'^message/external-body$'i,
    );

Estas modificaciones realizadas al fichero dejan una configuración específica para que amavisd-new se comporte de la manera que el autor de este artículo requiere, pero lo más habitual es que deba personalizarse para cada caso. Acto seguido se resumen los porqués de los cambios realizados:

• bypass_spam_checks_acl: comentamos esta línea para que Amavisd-new use SpamAssassin (por defecto viene deshabilitado su uso).
• final_spam_destiny: dejamos pasar los correos identificados como spam, aunque siguen siendo marcados como tales mediante cabeceras en el correo. De este modo, los destinatarios seguirán recibiendo toda su correspondencia pero podrán filtrarla fácilmente usando Sieve y las cabeceras que Amavisd-new habrá añadido al mensaje.
• warnbannedsender: activamos el envío de un mensaje de aviso al remitente de un mensaje que contuviera algún fichero adjunto con una de las extensiones prohibidas que más abajo se detallan.
• warnbadhsender: igual que el anterior para ficheros con cabeceras malformadas.
• virus_quarantine_to: activamos la cuarentena de los correos con virus. De este modo, cualqueir correo que contenga un virus detectado será redirigido a la cuenta especificada. Así, podremos revisarlos y decidir qué hacer con ellos.
• sa_spam_subject_tag: al comentar esta sentencia se desactiva la modificación del asunto del mensaje, pues con las cabeceras que se han añadido es suficiente para que Sieve (o nuestro cliente de correo) filtre adecuadamente.
• banned_filename_re: rechazamos correos que contengan ficheros adjuntos con alguna de las extensiones mencionadas en esta variable (únicamente se permiten ficheros comprimidos), principalmente ejecutables y scripts.

Tras esto ya podemos reiniciar el servicio mediante el comando /etc/init.d/amavis restart y observar su carga en el log /var/log/mail.log, donde se informa de todos los módulos cargados al iniciar.

8.4. Modificaciones en Postfix.

Las modificaciones a realizar en Postfix son muy sencillas. En primera instancia, editamos el fichero /etc/postfix/master.cf y le añadimos estas líneas:

    127.0.0.1:10025 inet    n       -       n       -       -       smtpd
        -o content_filter=
        -o local_recipient_maps=
        -o relay_recipient_maps=
        -o smtpd_restriction_classes=
        -o smtpd_client_restrictions=
        -o smtpd_helo_restrictions=
        -o smtpd_sender_restrictions=
        -o smtpd_recipient_restrictions=permit_mynetworks,reject
        -o mynetworks=127.0.0.0/8
        -o strict_rfc821_envelopes=yes
        -o smtpd_error_sleep_time=0
        -o smtpd_soft_error_limit=1001
        -o smtpd_hard_error_limit=1000

    smtp-amavis unix - - n - 2 lmtp
        -o lmtp_data_done_timeout=1200
        -o lmtp_send_xforward_command=yes

Y en el fichero /etc/postfix/main.cf tan sólo debemos añadir esta línea:

    content_filter = smtp-amavis:[127.0.0.1]:10024

De este modo añadimos un filtro de contenido a Postfix, el cual redirigirá el tráfico al puerto 10024 de la interfaz loopback. Una vez Amavisd-new haya finalizado su trabajo, devolverá el mensaje a Postfix a través del puerto 10025, donde hemos habilitado un smtpd. Ahora tan sólo queda reiniciar el servidor Postfix mediante el comando /etc/init.d/postfix restart.

8.5. Medidas anti-UCE.

Las medidas anti-UCE (del inglés, Unsolicited Commercial Email) son una serie de mecanismos que se habilitarán en Postfix para filtrar el uso abusivo de nuestro servidor y tratar de denegar la entrada de una buena parte del correo no solicitado en él. En primer lugar, añadimos las siguientes líneas al fichero /etc/postfix/main.cf:

    smtpd_helo_required = yes
    disable_vrfy_command = yes

    smtpd_recipient_restrictions =
        reject_invalid_hostname,
        reject_non_fqdn_hostname,
&