7.3.3.2. Aceptación de mensajes

7.3.3.2.1. Políticas de aceptación

Ver también

Para completar la información bajo este epígrafe pueden consultarse los enlaces:

7.3.3.2.1.1. Control de accesos

postfix tiene la habilidad de aceptar o rechazar mensajes dependiendo de múltiples criterios. Cuando recibe un mensaje a través de una comunicación SMTP, esta pasa por fases (véase la descripción de cómo se lleva a cabo esta comunicación) y en cada una de ellas pueden operar estas restricciones de acceso:

Momento

Directiva

Conexión

smtpd_client_restrictions

EHLO

smtpd_helo_restrictions

MAIL FROM

smtpd_sender_restrictions

RCPT TO
smtpd_recipient_restrictions
smtpd_relay_restrictions

Nota

Ante un comando RCPT_TO se consultan smtpd_recipient_restrictions o smtpd_relay_restrictions dependiendo de cuál sea la dirección del destinatario. Si el destinatario es una cuenta del propio servidor se aplican las primeras; y, si no, las segundas. Además, si smtpd_relay_restrictions está vacía, se usa smtpd_recipient_restrictions para cualquier destinatario.

Nota

Existen más restricciones, que se relacionan en la documentación de postfix

Las restricciones de cada fase (clases de restricciones en la terminología de postfix) las define el administrador entre todas las que ofrece postfix y están constituidas por un conjunto de pruebas cada una de las cuales, esencialmente, puede devolver tres respuestas:

  • Una respuesta de aceptación, que supone que se abandonen las pruebas faltantes y se considere que el mensaje ha superado las restricciones de esa fase.

  • Una respuesta de rechazo, que supone que se abandonen las pruebas faltantes, se considere que el mensaje no ha superado las restricciones de la fase y, en consecuencia, el mensaje sea definitivamente rechazado.

  • Ninguna respuesta concluyente, que supone que se pase a la siguiente prueba. En caso de que la prueba fuese la última de la fase, se considera que el mensaje ha superado las restricciones de esa fase.

Para ilustrarlo, supongamos esta directiva:

smtpd_client_restrictions = reject_unknown_client_hostname
                            check_client_access hash:/etc/postfix/tb/client_access

La directiva implica que, tras la conexión del cliente, el servidor hará la prueba reject_unknown_client_hostname, que responderá rechazo si la IP del cliente no tiene nombre asignado[1], y nada concluyente en caso contrario. En el primer caso, las restricciones de esta fase acabarán con un resultado de rechazo y no habrá nada más que hacer ni será necesario comprobar las restricciones de fases ulteriores. En el segundo caso, aún hay otra prueba que hacer: check_client_access. Esta segunda comprobación hace uso de una tabla access que en este caso determina a partir de la IP o el nombre del cliente qué acción se toma. Imaginemos que su contenido es el siguiente:

# Cliente         # Acción
192.168.255.4     REJECT Banned client
192.168.2         REJECT 192.168.2.0/24 banned network
spammer.dhns.org  REJECT Banned client
spammers.org      REJECT Banned domain

En ese caso, se comprueba por orden la tabla y si el cliente es 192.168.255.4, pertenece a la red 192.168.2.0/24, es spammer.dhns.org o su nombre pertenece al dominio spammers.org, se rechazará la conexión. En cualquier otro caso, la prueba no devuelve una respuesta concluyente y al no haber más pruebas en esta fase se pasará a comprobar las restricciones de la siguiente fase (smtpd_helo_restrictions).

Aunque lo lógico es que las restricciones de cada fase se aplicaran nada más completarse esta (p.e. las que nos han servido para ilustrar deben efectuarse nada más completarse la conexión y antes de que el cliente pueda saludar con EHLO), postfix deja que el cliente complete todas las fases hasta el comando DATA y, entonces es cuando aplica las restricciones de todas las fases secuencialmente. Este comportamiento puede alterarse usando la directiva:

smtpd_delay_reject = no

Aunque cada prueba de las que provee postfix es propia de una fase de la comunicación SMTP (p.e. la ilustrada check_client_access de la fase de conexión), se permiten usar cualquiera de ellas en las restricciones de cualquier fase. Por esa razón, al presentar la configuración básica incluimos una prueba propia de la conexión como reject_rbl_client en smtpd_recipient_restrictions. Ahora bien, es obvio que si, incorporando la directiva anterior, hacemos que las restricciones se apliquen en su momento respectivo y no al final, sólo podrán aplicarse las pruebas correspondientes a la propia fase o a fases previas. En concreto, para smtpd_helo_restrictions sólo podremos aplicar pruebas propias de la fase de conexión o de la fase de saludo, ya que aún se desconocen el emisor y los destinatarios.

Advertencia

Es importante tener presente que, si se usan restricciones de fases anteriores a la de recepción (RCTP TO), normalmente sólo tiene sentido utilizar pruebas para el rechazo y no para la aceptación, ya que la aceptación de la fase, no implica que se acepte el correo, sino que se pase a la fase siguiente. Para entenderlo observemos que;

smtpd_client_restrictions = permit_sasl_authenticated
smtpd_recipient_restrictions = reject_unauth_destination

no es equivalente a:

smtpd_recipient_restrictions = permit_sasl_authenticated
                               reject_unauth_destination

con la segunda configuración cualquier cliente autenticado podrá usar el servidor de relay (enviar correos a cuentas que no son de nuestro propio servidor), mientras que en el primer caso, no.

Restricciones de usuario

Además de las clases de restricciones predefinidas (smtpd_client_restrictions, etc.), el administrador puede definir las suyas propias que pueden usarse como alias para definir grupos de pruebas en las clases predefinidas o como valor en la segunda columna de una tabla access[2].

Por ejemplo, si quisiéramos que los clientes de nuestra red sólo envíen mensajes con cuentas de nuestra red, podríamos hacer lo siguiente:

smtpd_restriction_classes = emisor_propio_restriction
emisor_propio_restriction = check_sender_access hash:/etc/postfix/tb/cue_propias, reject
smtpd_sender_restrictions = check_client_access hash:/etc/postfix/tb/cli_propios

donde /etc/postfix/tb/cli_propios es:

mail1.org         emisor_propio_restriction

y /etc/postfix/tb/cue_propias:

mail1.org         OK

Nota

Si el primero de los ficheros lo hubieras definido así:

mail1.org         check_sender_access hash:/etc/postfix/tb/cue_propias, reject

nos habíamos ahorrado definir la clase propia.

7.3.3.2.1.2. Control de destinatario

Por defecto, el valor de smtpd_reject_unlisted_recipient:

# postconf -d smtpd_reject_unlisted_recipient
smtpd_reject_unlisted_recipient = yes

provoca que postfix compruebe durante la comunicación SMTP cuál será el receptor del mensaje y lo rechace en los siguientes casos:

postfix obra así, porque esto evita que, ante un envío indiscriminado hacia nuestro servidor de cuentas generadas aleatoriamente, se llene nuestra cola de salida con mensajes de que la cuenta no existe.

Nota

Existe una politica de aceptación llamada reject_unlisted_recipient que sirve exactamente para lo mismo, pero sólo tiene sentido usarla si se modifica el valor de smtpd_reject_unlisted_recipient.

Ver también

Para más información, consulte el artículo oficial sobre la verificación del destino

7.3.3.2.1.3. Control del contenido del mensaje

Las restricciones al acceso anteriores no se aplican al contenido del mensaje, sea la cabecera o el cuerpo. Si nuestra intención es rechazar mensajes según el contenido podemos recurrir a header_checks y body_checks.

Advertencia

Estos mecanismos de filtro no deberían sustituir a software específico de filtrado (p.e. software antispam), porque su rendimiento es pobre y sólo deben usarse para resolver casos muy concretos.

Un ejemplo de uso puede ser este:

header_checks = regexp:/etc/postfix/tb/reject_rules

y dentro de tal fichero:

/^Subject: .*VIAGRA.*$/    REJECT Los clientes de este servidor no tienen problemas de erección

Para probar si el filtro funciona, puede usarse la siguiente orden:

$ postmap -q 'Subject: Vendo VIAGRA barata' regexp:/etc/postfix/tb/reject_rules
REJECT Los clientes de este servidor no tienen problemas de erección

7.3.3.2.1.4. Campo From:

Ver también

Conviene que eche un vistazo a la introducción del epígrafe dedicado a la acreditación del remitente para que tenga claros los conceptos de remitente del sobre y dirección del mensaje, que se usarán aquí.

El propósito de este epígrafe es estudiar cómo evitar que nuestros usuarios usen direcciones arbitrarias como direccion del mensaje, bien rechazando aquel mensaje en que no coincide ésta con el remitente del sobre, bien sustituyendo la dirección del mensaje por la del remitente del sobre antes de remitirlo a su destinatario.

Nota

La tarea inversa de descubrir falsificaciones en el remitente o de facilitarla sobre nuestros mensajes a servidores ajenos se desarrolla en la acreditación del remitente.

postfix no tiene ningún mecanismo para llvar a cabo este propósito pero existe un software de terceros con paquete en debian, vrfydmn, que funciona como milter:

# apt install vfrydmn

La mayor dificultad de uso es que el paquete no parece estar perfectamente integrado en la distribución, y es necesario modificar su arranque para que nos funcione con postfix.

Lo primero es cambiar el fichero /etc/default/vrfydmn para que quede con este contenido:

DAEMON_OPTS=""
SOCKET=local:/var/spool/postfix/var/run/vrfydmn.sock
USER=vrfydmn
GROUP=vrfydmn
PIDFILE=/var/run/vrfydmn/vrfydmn.pid
FILE=/etc/postfix/tb/vrfydmn

y crear el fichero /etc/systemd/system/vrfydmn.service.d/10_override.conf que sobreescriba la configuración para systemd, a fin de que se use el fichero anterior:

[Service]
EnvironmentFile=/etc/default/vrfydmn
ExecStart=
ExecStart=/usr/sbin/vrfydmn -s $SOCKET -u $USER -g $GROUP -p $PIDFILE --file $FILE $DAEMON_OPTS

Para que se pueda crear el socket dentro de la jaula de postfix, crearemos un directorio var/run/ en el que puedan escribir todos los usuarios, pero con bit pegajoso:

# mkdir -m1777 /var/spool/postfix/var/run

Por último es necesario crear el fichero /etc/postfix/tb/vrfydmn que debe ser una tabla semejante a relay_domains o virtual_mailbox_domains en la que la primera columna contiene los dominios para los que vrfydmn no realizará comprobaciones, y la segunda es indiferente[3]:

mail1.org            importa_poco_que_se_ponga_aqui
# Resto de dominios que gestionemos

Con estos cambios, ya podemos recargar la configuración de systemd y reiniciar el servicio:

# systemctl daemon-reload
# invoke-rc.d vrfydmn restart

Además, debemos indicarle a postfix que use el milter:

smtpd_milters = unix:var/run/vrfydmn.sock

Nota

Es conveniente que aplique el milter en los puertos dedicados a la escucha de clientes (465 y 587), así que la línea anterior debería aplicarla sólo al servicio smtpd que escuche en esos puertos. Así pues, no incluya la línea en /etc/postfix/main.cf, sino de forma adecuada en /etc/postfix/master.cf:

urd       inet  n       -       y       -       -       smtpd
   -o smtpd_tls_wrappermode=yes
   -o smtpd_milters=unix:aux/vrfydmn
submission inet n       -       y       -       -       smtpd
   -o smtpd_milters=unix:aux/vrfydmn

Además, el usuario postfix debería pertenecer al grupo vrfydmn.

Tal como se ha configurado vrfydmn, éste se comporta de modo que permite cualquier dirección del mensaje siempre que sea de un dominio incluido en el fichero. Si no es así, el mensaje se rechaza.

Una alternativa a lo anterior, es indicarle a vrfydmn que en vez de rechazar el correo, lo acepte, pero modificando el campo From: para que lo haga coincidir con la dirección indicada en MAIL FROM. Para ello, habría que modificar /etc/default/vrfydmn para dejar esta línea:

DAEMON_OPTS="-F"

7.3.3.2.2. Spam

El correo indeseado o spam puede afectar a nuestro servidor de correo de dos maneras:

  • Como emisor del spam, porque el servidor se use para enviar ingentemente correo a otras cuentas.

  • Comp receptor del spam por algunas de nuestras cuentas lo reciban de otros servidores.

7.3.3.2.2.1. Control del flujo

Por lo general, los spammers se dedican a enviar miles y decenas de miles de mensajes, por lo que una manera de controlar el spam es el limitar la recepción o emisión de mensajes.

Emisor

El servidor de correo puede convertirse en un emisor de spam si alguna de sus cuentas se usa para tal fin. Puede deberse tanto a la existencia de un usuario malintencionado o como al robo de alguna contraseña.

Para el primer caso (o bien cuando el segundo ya se ha consumado) es útil limitar la capacidad de nuestros usuarios para enviar correos[4]:

# Mensajes simultáneos que se pueden enviar a un mismo dominio.
smtp_destination_concurrency_limit = 2
# Lapso entre dos envíos a un mismo dominio.
smtp_destination_rate_delay = 1s
# Número máximo de destinatarios por mensaje.
smtp_extra_recipient_limit = 10

Para el segundo, es necesario habilitar algun mecanismo que obstaculice los robos de contraseña. Algunas veces estos robos se deben a ataques de fuerza bruta efectuados contra el servidor. Para evitarlos es conveniente disponer algún mecanismo contra ellos.

Receptor

Para limitar los efectos del spam entrante, podemos limitar la recepción de mensajes, si es que nuestras cuentas están recibiendo masivamente spam de alguna fuente[5]:

# Número de conexiones entrantes por cliente.
smtpd_client_connection_count_limit = 5
# Número de conexiones que un cliente puede hacer en un intervalo (fijado por anvil_rate_time_unit)
smtpd_client_connection_rate_limit = 10
# Número de mensajes entregados por cliente en un intervalo (anvil_rate_time_unit)
smtpd_client_message_rate_limit = 2
# Número de destinatarios a los que un cliente puede enviar mensajes en un intervalo (anvil_rate_time_unit)
smtpd_client_recipient_rate_limit = 15

7.3.3.2.2.2. Filtro antispam

Los filtros antispam analizan los mensajes recibidos con la intención de detectar los que son spam y desecharlos o, al menos, marcarlos como indeseados.

Ver también

Otras técnicas para detectar spam están relacionadas con los mecanismos que acreditan al remitente del mensaje, que se explican en su epígrafe correspondiente.

7.3.3.2.2.2.1. Spamassassin

El software más extendido encargado de esta tarea es spamassassin (página oficial), que tiene fácil instalación en debian:

# apt-get install spamassassin spamc

Puede, además tocarse la configuración de /etc/default/spamassassin para alterar la prioridad del proceso:

NICE="--nicelevel 15"

Por último, es necesario habilitar el servicio ya que viene deshabilitado por defecto[6]:

# systemctl enable spamassassin
# systemctl start spamassassin

El siguiente paso es hacer que postfix haga pasar los correos por spamassassin para que este los analice, lo cual requiere editar el fichero /etc/postfix/master.cf y dejar la primera línea que empieza por smtp así:

smtp      inet  n       -       -       -       -       smtpd -o content_filter=spamfilter

además de añadir al final del fichero en qué consiste este filtro:

spamfilter unix  -       n       n       -       -       pipe
   flags=Rq user=debian-spamd argv=/usr/local/bin/spamfilter.sh -oi -f ${sender} ${recipient}

El usuario debian-spamd lo crea la propia instalación de spamassassin y el script mencionado lo debemos crear nosotros en la ruta señalada con este contenido:

#!/bin/sh
#
# Vease: http://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix
#

# Los correos >10MB no se procesan como spam.
MAX_MESSAGE_SIZE=10485760

SENDMAIL=/usr/sbin/sendmail
SPAMASSASSIN=/usr/bin/spamc

logger "Spam filter piping to SpamAssassin, then to: $SENDMAIL $*"
${SPAMASSASSIN} -x -E -s $MAX_MESSAGE_SIZE | ${SENDMAIL} "$@"

exit $?

Advertencia

Recuérdese que habrá que dar permisos de ejecución al script:

# chmod 755 /usr/local/bin/spamfilter.sh

A partir de ahora, todo tráfico que sea considerado spam por spamassassin contendrá una cabecera[7][8]:

X-Spam-Flag: YES

Para tratar la cabecera podemos seguir dos estrategias.

  • Utilizar header_checks para desecharlo, según lo expuesto anteriormente. En este caso, el filtro podría ser:

    /^X-Spam-Flag:\s+YES$/    DISCARD  Mensaje de spam

    Nota

    Lo prudente ante el spam es descartar el mensaje silenciosamente, no rechazarlo.

  • Postergar y delegar la decisión en un MDA externo, que podrá desecharlo o mandarlo al buzón de spam.

7.3.3.2.2.2.2. rspamd

Notas al pie