Resumen

  • La RFC 1846 de septiembre de 1995 describió equipos especializados que jamás recibían correo. Sin un servidor SMTP que respondiera, los emisores podían tratar el fallo como temporal, conservar el mensaje equivocado y reintentarlo durante días. El código experimental 521 permitía a un repetidor MX o a un servidor mínimo dar una respuesta definitiva.
  • Los autores encontraron una trampa: algunos clientes reintentaban si el servidor enviaba 521 y cerraba inmediatamente, pero devolvían el mensaje si esperaba a que enviaran QUIT. La RFC 7504 de 2015 normalizó el 521 para un equipo que nunca recibe correo y creó el 556 para un intermediario que sabe de antemano que un dominio no lo acepta.

El buzón que nadie había instalado

El correo electrónico tiene una virtud cara: no abandona enseguida. Si el servidor de destino se cae, el remitente puede conservar el mensaje y volver más tarde. Esa virtud se convierte en una rutina inútil cuando el destino es una máquina que jamás ofreció correo. En la RFC experimental publicada en 1995, Alain Durand y Francis Dupont observaron que Internet incorporaba equipos cada vez más especializados, por ejemplo para DNS y NTP. Una persona aún podía escribir una dirección de correo que señalara a uno de ellos.

Al no encontrar un servicio SMTP, el programa emisor debía tratar el intento como un problema provisional. Quizá un administrador encendería un servidor de correo al día siguiente. Mientras tanto, el mensaje permanecía en cola, se intentaba otra vez y acababa regresando días después con un error que la RFC calificaba de confuso. No había un buzón lleno al otro lado; el trabajo y la demora estaban en los sistemas que seguían llamando a una puerta sin timbre.

La diferencia entre silencio y rechazo es el centro de esta historia. El SMTP de 1982 organizaba una conversación entre un emisor y un receptor: órdenes y respuestas numéricas permitían decidir el siguiente paso. Durand y Dupont querían que el dueño de la máquina, o un repetidor autorizado a hablar por ella, pudiera decir algo que el fallo de conexión no decía: aquí nunca se recibirá correo. Le dieron el número 521. El mensaje no creaba un buzón; evitaba que otros siguieran buscándolo.

La propuesta ofrecía dos sitios desde los que hablar. Un repetidor MX podía responder 521 al ver el destinatario durante la conversación. O la propia máquina sin correo podía ejecutar un servidor SMTP diminuto cuya única función fuera rechazarlo todo. El primero aprovechaba la infraestructura de correo de un tercero operativo; el segundo colocaba la negativa en el destino. Ambas soluciones requerían que alguien respondiera por una regla permanente, en vez de dejar que los remitentes adivinaran si la ausencia del servicio era temporal.

La ruta del MX necesitaba disciplina. La RFC 1846 recomendaba que, si un repetidor rechazaba el correo de un equipo sin buzón, los repetidores menos preferidos hicieran lo mismo. De nada servía que una ventanilla dijera «no» si otra, anunciada para el mismo destino, dejaba al emisor esperando o intentando una entrega imposible. Publicar una política en una sola entrada no controla las demás.

Un «no» demasiado breve sonaba a avería

El pequeño servidor podía enviar 521 nada más abrir la conexión, seguido del nombre oficial del equipo o su dirección IP. Después tenía dos opciones: cerrar o seguir leyendo órdenes, contestar 521 a todas salvo QUIT y terminar cuando el cliente se despidiera. La RFC prohibía anunciar como MX a una máquina que enviaba ese saludo de rechazo. No tenía sentido ofrecerla como receptor de correo mientras declaraba que jamás aceptaría uno.

La forma de terminar la conversación resultó decisiva. Durand y Dupont señalaron que algunos clientes SMTP trataban el cierre inmediato después del 521 como un fallo transitorio y devolvían el mensaje a la cola. Si el servidor permanecía abierto, esos clientes enviaban QUIT y devolvían el correo a su autor. La misma negativa, en un intercambio ligeramente distinto, producía el comportamiento contrario. El código podía ser impecable sobre el papel; el software ya instalado decidía si la cola se detenía.

Así, un equipo dedicado al DNS o a la hora podía necesitar un programa de correo que no recibiera ni un solo correo. Debía ser accesible, identificarse, pronunciar una frase fija y aguardar el cierre correcto cuando hiciera falta. Esa pieza mínima ahorraba muchos intentos ajenos. No era una concesión a quien escribía a la dirección equivocada, sino una forma de no trasladar indefinidamente el coste del silencio.

La RFC de 1995 era experimental. Sus autores pidieron noticias a quienes implementaran el código. La mención a «algunos» clientes que reintentaban tras el cierre rápido describe una incompatibilidad observada, sin cuantificar qué porcentaje de programas o mensajes sufría el problema. Para saberlo harían falta registros de las colas o un censo de implementaciones de aquella época. El mecanismo, en cambio, queda documentado en el intercambio que la RFC compara.

En 2015, dos lugares distintos para decir «no»

La RFC 7504 incorporó 521 a SMTP veinte años después. El documento de 2015 afirmaba que el código se usaba ampliamente, aunque todavía no formaba parte formal del protocolo. Reservó el 521 para el inicio de una conexión con un equipo que no acepta correo bajo ninguna circunstancia. No es la negativa amplia que puede dar un servidor con 554 ante una fuente, dirección o situación concreta. Es una declaración sobre el propio servicio del equipo. La nueva norma cerró el experimento que Durand y Dupont habían abierto.

Para entonces, el rechazo podía producirse incluso antes de contactar con el equipo. La RFC 7505 definió el registro DNS «null MX»: un dominio anuncia que no recibe correo. Si no hay MX, un cliente puede recurrir a la dirección A o AAAA y probar suerte con un equipo que sí sirve páginas u otra cosa, pero no buzones. El registro de ausencia de servicio evita esa visita. Habla del dominio desde el DNS, no de la respuesta de un servidor en una conexión SMTP.

La misma RFC 7504 creó el 556 para un sistema intermedio que sabe, por una señal como null MX, que el dominio de una dirección de reenvío no recibe correo. Puede responder al sistema que le entregó el mensaje sin abrir una conexión con el destino. Un host comunica 521 en la apertura. Un intermediario comunica 556 gracias a una regla que ya conoce sobre el dominio. La decisión de no insistir llega antes o después según dónde esté la información.

En 1995, el remedio podía consistir en encender un servidor que solo sabía negarse. En 2015, el DNS ofrecía otra manera de declarar la ausencia de buzón sin encenderlo. El ahorro no nació de hacer más rápida la cola, sino de darle un final cierto. El silencio de la máquina equivocada hacía trabajar a todos; una negativa creíble les permitía dejar de llamar.