El paper de aquella charla se puede encontrar en:

http://www.ukuug.org/events/eurobsdcon2009/papers/BSDCON09-SMTP-DDoS-Final.pdf

Como el propio título hace suponer, se trata de un módulo (llamado accf_smtp para el kernel de FreeBSD capaz de gestionar las conexiones SMTP entrantes al servidor y prevenir cierto tipo de ataques (comunes entre las botnes). Con dichas conexiones, puede realizar diversas funciones como hacer una pausa antes de entregar el banner del servicio SMTP, rechazar conexiones que no envíen primeramente el comando HELO/EHLO, establecer número máximo de caracteres en parámetros de comandos…etc.

Soy de la opinión de Wietse Venema que comentaba que esas funciones no son para hacerlas en el kernel sino en userland, como ya hacen numerosos servidores de correo electrónico, por lo que en realidad no supone nada nuevo.

Esta idea está basada en el ya existente accf_http, que gestiona las conexiones HTTP entrantes.

Habrá que esperar a ver qué opinan los que puedan probarlo en sus FreeBSDs.

Como se puede ver en su web, se trata de un nuevo demonio que actuará delante del proceso smtpd actual para escuchar las peticiones SMTP externas. Dicho demonio gestionará las conexiones para intentar evitar los ya famosos zombies, consultar RBLs…etc.

En unas transparencias se habla un poco más del tema y de su arquitectura. Por ahora, el demonio se basa en la consulta de una lista blanca de 24 horas de duración en la que se listan las IPs que no están en RBLs y que pasan los tests de pausa después del “saludo” inicial que devuelve el servidor (aquí es donde la mayoría de zombies caerán). Las IPs que estén listadas en alguna lista negra o no pasen dichos tests, se rechazarán. Dicho saludo se trata de una respuesta multilínea, en este formato:

220 servidor.dns-servicios.com ESMTP
[espera de unos segundos]
220 servidor.dns-servicios.com ESMTP

donde el primer saludo lo lanza Postscreen y el segundo el proceso SMTPD real. Como decía, muchos zombies pondrán el comando HELO/EHLO antes de esa segunda línea y caerán en “la trampa”.

Veremos cómo evoluciona el proyecto, pero a primeras, parece interesante :)

¿Para qué reinventar la rueda? “Simplemente” por cuestiones de licencia; parece que en OpenBSD no les gusta excesivamente la licencia pública de IBM que tiene Postfix, por ello han decidido desarrollar otro servidor SMTP.

Wietse Venema, el creador de Postfix, ya decía que no le apetecía mucho andar con jaleos de licencias con los abogados de IBM, y el bueno de él comenta:

Apart from that, if they come up with a decent MTA then I welcome
some competition. More motivation for me to look into postfix-lite.

Por lo que parece, Wietse tiene prevista hacer una limpieza de código importante, sobre todo evitando código de compatibilidad con versiones antiguas y demás:

Fully-featured as far as RFCs are concerned, but not necessarily
drop-in compatible with earlier Postfix configurations or file
formats.

Ideally this means eliminating thousands of lines of non-obvious
code, either by removing the feature or workaround altogether, or
by replacing it with code that is easier to maintain but not 100%
compatible. This will be a slow process.

Veremos cómo avanza OpenSMTPD, pero realmente lo tienen bastante difícil para desbancar no solo a Postfix, sino a otros proyectos ya muy maduros como Exim, Qmail, Sendmail…etc.
Tienen MUCHO trabajo por delante…suerte!

$ dig mx microsoft.com +short
 10 mail.global.frontbridge.com.

$ telnet mail.global.frontbridge.com 25
Trying 65.55.88.22...
Connected to mail.global.frontbridge.com.
Escape character is '^]'.
220 mail156-tx2.bigfish.com ESMTP Postfix EGGS and Butter

Y así lo confirmaba el propio Victor Duchovni, que se podría decir que es la mano derecha de Wietse Venema, diciendo que Microsoft compró Frontbridge hace tiempo y que éstos usaban por aquél entonces Postfix en su versión 1.1. Parece entonces que lo siguen usando y seguramente, Microsoft tendrá una primera frontera de servidores con Postfix para hacer frente a todo el tráfico entrante, dada la excelente capacidad de este MTA de gestionar grandes cantidades de conexiones concurrentes como las que puede recibir Microsoft en sus MX.

Como fijarse en el banner es algo banal, haciendo alguna prueba con comandos no existentes y demás, sí parece tener las respuestas de Postfix. Pasando smtpscan obtenemos:

$ /usr/local/bin/smtpscan  mail.global.frontbridge.com
smtpscan version 0.5

  15 tests available
  3184 fingerprints in the database

Scanning mail.global.frontbridge.com (216.32.180.22) port 25
 15/15

Result --
503:501:501:250:501:250:450:502:502:502:502:502:502:250:250

Banner :
220 mail153-va3.bigfish.com ESMTP Postfix EGGS and Butter

No exact match. Nearest matches :
  - Postfix 1.1.11 (1)
  - Postfix (1)

Que es justamente lo que decía Viktor, un Postfix v1.1 modificado.

Parece que esto coincide además con el reciente lanzamiento de Hosted Exchange, algo que no ha sentado muy bien entre sus clientes ya que hacen clara competencia a sus partners.

El proceso consiste en guardar en una tabla en MySQL las direcciones que qmail va “viendo”. Existe otra tabla en la que se guarda el valor por defecto que se le quiere dar al límite (por ejemplo, 100 mensajes) y si se llega a dicho límite en un rango de tiempo (por defecto, en 1 hora) el mensaje es rechazado a nivel de SMTP temporalmente.

Existe también la posibilidad de poner límites diferentes para determinadas direcciones; por ejemplo, alguna persona que por X razón legítima necesite enviar más correos.

Además, existe una lista blanca para IPs a las cuáles no aplicar dichos límites. Por ejemplo, si tenemos unos relays de entrada.

Qmail debe estar parcheado con SPP para poder usar este plugin. Por ejemplo, el qmail de Plesk viene de serie ya parcheado, por lo que no hay más que copiarlo en /var/qmail/plugins/ y añadirlo en el archivo /var/qmail/control/smtpplugins.

En la siguiente URL puede ser descargado:

http://postmaster.hostalia.com/rate_from

Leyendo el blog de MailChannels, que compara dichos RFCs, se aprecian los siguientes cambios:

• RFC 5322 (Internet Message Format)

- Especificación de qué puede contener una cabecera de un mensaje SMTP y qué no.

- Se recomienda que la parte de dominio de una dirección de email, sea un dominio legítimo en el ámbito o contexto en el que ese mensaje se esté tratando.

- No es posible el uso de texto entrecomillado en la cabecera Message-ID.

- La definición de la cabecera Received pasa a estar en el RFC 5321.

• RFC 5321 (SMTP)

- Actualizaciones y aclaraciones sobre textos ya existentes en el RFC 2821, dejando partes de él obsoletas.

- Recomendación del uso del puerto 587 (Submission – RFC 4409) en algunas configuraciones en vez de el uso del de SMTP para el envío de correo.

- Los comandos “MAIL FROM” y “RCPT TO” ya no pueden contener detrás un espacio.

- Mención de la existencia de SPF y DKIM para la comprobación del remitente.

- Posibilidad de desconectar a un cliente SMTP tras un timeout.

- Códigos 100 de respuesta eliminados del estándar por su falta de uso.

- Posibilidad de responder con un código 550 después del comando DATA (para filtros antispam “inline”, por ejemplo).

- Mención a la existencia de IPv6 pero sin ser un requerimiento.

- Los bounces ante abusos, ataques…etc solamente deberán ser enviados si se tiene constancia de que van a ser últiles en el origen (por ejemplo, no tiene sentido enviar bounces al origen ante detecciones de virus o spam en mensajes, ya que suelen ser falsificados en su totalidad).

- Posibilidad de rechazar con mensajes 550 (por ejemplo) a emisores que cometan abusos (muchos RCPTs inválidos, por ejemplo).

No hay grandes cambios ni medidas drásticas pero parece que los RFCs se adaptan a las necesidades que van surgiendo por el aumento del spam.

Remote host said: 550 5.7.1 Sender ID (PRA) Not Permitted

Sender ID está claro lo que es, por eso, tras comprobar el registro SPF de los dominios emisores (por eso de “Not Permitted”), parecía todo correcto; dominios de clientes que usan los servidores de correo legítimos que les ofrecemos para hacer los envíos. Nada raro.

Nada raro hasta que buscando y rebuscando se llega a esta URL:

The “Sender ID Filtering” feature does not work correctly in an Exchange Server 2003 SP2 server

http://support.microsoft.com/?scid=kb%3Ben-us%3B910272&x=13&y=17

Vamos, que si tienes en el dominio un registro SPF de este estilo:

v=spf1 ip4:10.0.63.0/18 -all

un Exchange 2003 SP2 te lo va a echar para atrás con el error arriba indicado.

Este bug parece ser de Octubre de 2007, lo que muestra la existencia de servidores sin actualizaciones de por lo menos hace un año (nada que nadie no sepa, por otra parte). Aunque cierto es que lo siguiente:

A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing this specific problem. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.

No es que de mucha confianza…

- TLS (SSL) support was streamlined further, and provides a new
security level based on certificate fingerprints instead of CA
signatures. See TLS_README for details.

- Milter support was updated from the Sendmail 8.13 feature set and
now includes most of the features that were introduced with
Sendmail 8.14. See MILTER_README for details.

- Stress-adaptive configuration was introduced. This allows the
Postfix SMTP server to temporarily adjust its rules under conditions
of overload, such as a malware attack or backscatter flood. See
STRESS_README for details.

- The queue manager scheduler was refined. It now provides per-transport
scheduling controls and allows for adjustment of the sensitivity
to mail delivery (non-)errors. See SCHEDULER_README.

- Security was improved by introducing a Postfix-owned data_directory
for storage of randomness, caches and other non-queue data. This
change avoids future security loopholes due to untrusted data
sitting in root-owned files or in root-owned directories. Writes
to legacy files in root-owned directories are automatically
redirected to files in the new data_directory.

Interesante sobre todo el tema de “stress” :-)
Para una descripción más detallada de los cambios: RELEASE_NOTES.