Sendmail e IPv6. Hacer que sendmail escuche en IPv6

Problema:
Tengo un servidor de correo en Linux Debian con Sendmail, en IPv4 todo funciona bien pero no escucha conexiones en IPv6

Escenario:
Servidor Debian con Sendmail 8.14.3 e IPv6 configurado

Procedimiento:
Primero verificar que efectivamente Sendmail no escucha en IPv6. Por ejemplo:

#netstat -pan | grep sendmail

tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 2596/sendmail: MTA:
unix 2 [ ACC ] STREAM LISTENING 4198 1025/mysqld / var/run/mysqld/mysqld.sock
unix 2 [ ACC ] STREAM LISTENING 13539 2596/sendmail: MTA: / var/run/sendmail/mta/smcontrol
unix 2 [ ] DGRAM 13535 2596/sendmail: MTA:

En la salida anterior notamos que sendmail se encuentra escuchando solo sobre la red IPv4.

Solucion:
La solucion es indicarle al Sendmail que también levante sobre la familia Inet6. Para ello es necesario modificar el sendmail.mc para reconstruir el sendmail.cf y luego reiniciar el sendmail. Los pasos son los siguientes:

1) Editar el sendmail.mc y agregar las siguientes lineas:
DAEMON_OPTIONS(`Family=inet6, Name=MTA-v6, Port=smtp, Addr=DIRIPV6')dnl
DAEMON_OPTIONS(`Family=inet6, Name=MSP-v6, Port=submission, M=Ea, Addr=::1')dnl

OJO: Sustituir DIRIPV6 por tu dirección IPv6


2) Ejecutar sendmailconfig (para procedar el sendmail.mc con m4 y generar el .cf)

3) Luego de ejecutar el comando anterior lo siguiente es siempre indicarle que Y en las siguientes preguntas:

Configure sendmail with the existing /etc/mail/sendmail.conf? [Y] y
Configure sendmail with the existing /etc/mail/sendmail.mc? [Y] y
Reload the running sendmail now with the new configuration? [Y] y

Verificar:
Para verificar ejecuta el comando:
#netstat -pan | grep sendmail

Realiza un telnet de la siguiente manera:

#telnet ::1 25

debes recibir respuesta similar a:

Trying ::1...
Connected to ::1.
Escape character is '^]'.
220 ipv6.para.com ESMTP Sendmail 8.14.3/8.14.3/Debian-9.1ubuntu1; Fri, 1 Oct 20 10 11:52:48 -0430; (No UCE/UBE) logging access from: localhost(OK)-localhost [IPv6:::1]

Suerte, espero haya sido util.

Problemas con Postfix dsn= 4.4.2

En el dia de ayer, una empresa a la que a veces le presto servicios me llamo porque estaban teniendo fallas con su servicio de correo.

El primer paso que hice, fue revisar los logs, y al hacerlo me encontre con estos errores que ocurrian con varios Dominios:

dsn=4.4.2, status=deferred (lost connection with alt1.gmail-smtp-in.l.google.com[209.85.222.27] while sending message body)

dsn=4.4.2, status=deferred (lost connection with f.mx.mail.yahoo.com[98.137.54.237] while sending end of data -- message may be sent more than once)

Estos errores tienden a ser por problemas de latencia, que la transmision del correo se cierra debido al delay que se presenta, pero para mi sorpresa, el enlace estaba bien, no habia latencia en la red de la empresa.

Intente disminuir el MTU de la interfaz eth0:

debian:/home/xxxx# ifconfig eth0 mtu 1000
debian:/home/xxxx# ifconfig
eth0 Link encap:Ethernet HWaddr 00:1a:4b:5e:10:c8
inet addr:10.10.10.10 Bcast:192.168.127.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1000 Metric:1

Pense que esto iba a solucionarlo, pero no fue asi, despues de correr "mailq -q" para forzar la salida de los correos en cola, los mismos se mantenian en las mismas condiciones.

Capaz era problema se relacionaba con el MTU discovery

"debian:/home/xxxx#echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc"

Luego de volver a correr "mailq -q", seguia dando el mismo error.


Por lo que procedi a instalar tcpdump "debian:/home/xxxx# aptitude install tcpdump" y sniffear el trafico del puerto 25.

"debian:/home/xxxx# tcpdump -i eth0 port 25"

Y lo deje corriendo un rato, mientras enviaba correos a la empresa y de la empresa enviaba correos a otros dominios. Luego de obtener bastante informacion procedi a analizarla con Wireshark (esta herramienta es lo mejor creado por el ser Humano, junto con nmap :P).

Comparte con ustedes lo que vi en Wireshark


Al ver el error que estaba teniendo en cuanto al "TCP checksum offload", procedi a deshabilitarlo en la interfaz eth0.

Esto se puede hacer con una herramienta que se llama ethtool, que te permite manipular las propiedades de la interfaz.


debian:/home/xxxx# ethtool --show-offload eth0
Offload parameters for eth0:
Cannot get device rx csum settings: Operation not supported
Cannot get device flags: Operation not supported
rx-checksumming: off
tx-checksumming: on <============
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
large receive offload: off

debian:/home/xxxx# ethtool --offload eth0 tx off

y luego

debian:/home/xxxx# ethtool --show-offload eth0
Offload parameters for eth0:
Cannot get device rx csum settings: Operation not supported
Cannot get device flags: Operation not supported
rx-checksumming: off
tx-checksumming: off <============ :)
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
large receive offload: off


Al hacer esto, los correos empezaron a salir :)....

Para quienes no tengan muy claro que es esto, les dejo una pequenha nota;

"If you are experiencing network problems and while trying to figure
it out with Wireshark you found these checksum errors, you may have a
network card with TCP checksum offload enabled and for some reason the
packet is not being fixed by the adapter (NAT, bridge or route
redirection is sending the packet to another interface). In this case,
you may want to check and disable checksum offload for the adapter, if
possible."

Mas detallado:

"tcp checksum offloading will not offer you very much performance wise
since it is so cheap to calculate it with the CPU. tcp checksum
offloading is dangerous for data however since it means that you will
send your packets across the least reliable component of your computer
(the pci bus) and without tcp checksum calculated by the stack you
will not detect bits being flipped/corrupted by the pci bus and thus
data might be corrupted. tcp checksum offloading is not as good as it
initially might be thought."