Diagnosticar el «no envío» de mails en Debian

Los hacks de hacks4geeks son minitutoriales rápidos pensados para geeks con conocimiento informático avanzado. Si no entiendes o no consigues ejecutar un hack de esta web considera suscribirte a Premium para solicitar asistencia sobre el mismo.

Diagnosticar el «no envío» de mails en Debian

Puede ocurrir que un servidor Debian deje de enviar correos de un día para otro y no tengamos claro dónde está el problema. En estos casos conviene diagnosticar el fallo con orden, porque el problema puede estar en Postfix, en la cola de correo, en DNS, en la resolución del destinatario, en el relay SMTP, en el firewall o incluso en bloqueos del proveedor.

Vamos a revisar los puntos básicos para diagnosticar por qué Debian no está enviando mails correctamente.

Lo primero que debemos comprobar es si Postfix está instalado y funcionando. Para ver el estado del servicio podemos ejecutar:
```
service postfix status
```
También podemos usar systemctl:
```
systemctl status postfix
```
Si Postfix está parado, intentamos arrancarlo:
```
systemctl start postfix
```
Y si queremos que arranque automáticamente con el sistema:
```
systemctl enable postfix
```
Si el servicio no arranca, debemos revisar directamente el error que devuelve systemd:
```
journalctl -u postfix --no-pager -n 100
```
El siguiente paso es comprobar si hay correos atascados en la cola. Para eso usamos:
```
mailq
```
También podemos usar:
```
postqueue -p
```
Si la cola está vacía, Postfix no tiene correos pendientes de enviar. En ese caso el problema puede estar antes de Postfix, por ejemplo en la aplicación que debería generar el correo.

Si vemos correos en la cola, debemos leer el motivo por el que no se han entregado. Normalmente Postfix muestra un mensaje de error junto a cada correo en cola. Ahí podemos encontrar pistas como problemas de DNS, conexión rechazada, autenticación fallida, dominio inexistente o bloqueo del servidor remoto.

Para forzar el intento de envío de los correos pendientes podemos ejecutar:
```
postqueue -f
```
También podemos usar:
```
sendmail -q
```
Después de forzar la cola, debemos volver a mirar los logs para ver qué ha pasado realmente.

En Debian, los logs de correo suelen estar en:
```
/var/log/mail.log
```
Podemos revisarlos en tiempo real mientras forzamos el envío:
```
tail -f /var/log/mail.log
```
En otra terminal podemos lanzar:
```
postqueue -f
```
De esta forma veremos inmediatamente si Postfix intenta entregar los mensajes, si el servidor remoto rechaza la conexión o si hay algún error de configuración.

Si queremos buscar errores concretos en el log, podemos usar:
```
grep -i "error" /var/log/mail.log
grep -i "warning" /var/log/mail.log
grep -i "deferred" /var/log/mail.log
grep -i "reject" /var/log/mail.log
grep -i "authentication failed" /var/log/mail.log
```
Si no tenemos herramientas básicas para enviar correos de prueba desde consola, instalamos mailutils:
```
apt-get update
apt-get -y install mailutils
```
Después podemos enviar un correo de prueba:
```
echo "Prueba de envio desde Debian" | mail -s "Prueba Postfix" usuario@dominio.com
```
Mientras enviamos la prueba, revisamos el log:
```
tail -f /var/log/mail.log
```
Si el correo aparece en la cola pero no sale, el problema está en la entrega. Si ni siquiera aparece en el log, el problema probablemente está en la herramienta, aplicación o script que intenta enviar el correo.

También conviene comprobar la configuración principal de Postfix:
```
postconf -n
```
Este comando muestra la configuración activa de Postfix, omitiendo los valores por defecto. Nos interesa revisar especialmente parámetros como:
```
myhostname
mydestination
relayhost
inet_interfaces
inet_protocols
smtp_sasl_auth_enable
smtp_sasl_password_maps
smtp_tls_security_level
```
Si usamos un servidor SMTP externo como relay, debemos revisar el parámetro relayhost:
```
postconf relayhost
```
Si el relay requiere autenticación, debemos comprobar que Postfix tenga configuradas las credenciales SMTP. Normalmente estarán en un archivo como:
```
/etc/postfix/sasl_passwd
```
Después de modificar ese archivo, debemos regenerar el mapa correspondiente:
```
postmap /etc/postfix/sasl_passwd
systemctl reload postfix
```
Un fallo muy habitual es que el archivo de credenciales exista, pero no se haya ejecutado postmap después de modificarlo. En ese caso Postfix seguirá usando la versión anterior del mapa.

También debemos comprobar los permisos de los archivos de credenciales, porque no deberían ser legibles por cualquier usuario del sistema:
```
chown root:root /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db
chmod 600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db
```
Si el error apunta a DNS, debemos comprobar que el servidor pueda resolver dominios externos:
```
getent hosts gmail.com
getent hosts debian.org
```
También podemos comprobar los registros MX del dominio destinatario instalando dnsutils:
```
apt-get -y install dnsutils
dig MX dominio.com
```
Si no hay resolución DNS, Postfix no podrá saber a qué servidor debe entregar el correo.

Otro punto importante es comprobar si el servidor puede abrir conexiones salientes al puerto SMTP correspondiente. Para entrega directa se usa normalmente el puerto 25. Para relay autenticado se usan normalmente los puertos 587 o 465.
```
apt-get -y install netcat-openbsd
nc -vz servidor.smtp.com 587
nc -vz servidor.smtp.com 465
nc -vz gmail-smtp-in.l.google.com 25
```
Si la conexión al puerto 25 falla, puede que el proveedor del servidor esté bloqueando el tráfico SMTP saliente. Esto es habitual en VPS, servidores cloud y conexiones residenciales. En ese caso, lo normal es usar un relay SMTP autenticado por el puerto 587.

Si Postfix intenta enviar por IPv6 y la conectividad IPv6 del servidor no funciona bien, podemos encontrarnos con entregas fallidas o retardos. Para probarlo, podemos revisar el valor de inet_protocols:
```
postconf inet_protocols
```
Si necesitamos forzar IPv4, podemos configurar:
```
postconf -e "inet_protocols = ipv4"
systemctl restart postfix
```
También debemos comprobar si los correos están siendo generados localmente pero acabando en buzones locales del sistema. Para eso podemos revisar:
```
ls -lah /var/mail
ls -lah /var/spool/mail
```
La existencia o no de usuarios en estos directorios no determina si Debian puede enviar correo al exterior. Estos directorios se usan para almacenar correo local de usuarios del sistema. Pueden ser útiles para diagnosticar entregas locales, pero no son una condición necesaria para enviar mails externos.

Si queremos ver qué correos locales ha recibido root, podemos usar:
```
mail
```
O revisar directamente el buzón:
```
less /var/mail/root
```
Si una aplicación intenta enviar correo pero no llega nada a Postfix, debemos comprobar qué comando utiliza. Muchas aplicaciones llaman a sendmail directamente. En Debian, Postfix proporciona una interfaz compatible con sendmail, así que podemos comprobar si existe:
```
which sendmail
ls -l /usr/sbin/sendmail
```
Si no existe, probablemente Postfix no está instalado correctamente o no hay ningún MTA instalado en el sistema.

Para revisar la cola con más detalle, podemos ver un mensaje concreto usando su ID de cola. Primero listamos la cola:
```
mailq
```
Después inspeccionamos un mensaje concreto:
```
postcat -q ID_DEL_MENSAJE
```
Esto nos permite ver cabeceras, destinatario, remitente y parte del contenido del mensaje en cola.

Si queremos eliminar un mensaje concreto de la cola:
```
postsuper -d ID_DEL_MENSAJE
```
Si queremos borrar todos los mensajes diferidos, debemos tener cuidado, pero podemos hacerlo con:
```
postsuper -d ALL deferred
```
Antes de borrar una cola completa conviene revisar el motivo real del atasco. Si borramos sin mirar, perdemos información útil para diagnosticar el problema.

Una secuencia práctica para diagnosticar el fallo sería esta:
```
systemctl status postfix
mailq
tail -f /var/log/mail.log
postqueue -f
```
Y para enviar una prueba desde consola:
```
echo "Prueba de envio desde Debian" | mail -s "Prueba Postfix" usuario@dominio.com
```
Si el correo no sale, el log normalmente nos dirá dónde está el problema: servicio parado, autenticación fallida, DNS roto, relay inaccesible, puerto bloqueado, certificado TLS problemático, destinatario rechazado o servidor remoto denegando la entrega.

Lo importante es no diagnosticar a ciegas. Primero comprobamos Postfix, después la cola, después los logs, después la conectividad y finalmente la configuración del relay o de la entrega directa.

Ver como PDF

Los comentarios están cerrados.