Resumen

  • El SMTP inicial incorporó VRFY y EXPN como ventanas de diagnóstico: una respuesta positiva podía revelar un buzón o enumerar uno por uno los miembros de una lista.
  • El código 252 introdujo un tercer estado veraz: el servidor no verifica al usuario, pero puede aceptar el mensaje e intentar entregarlo. La revelación del directorio, la aceptación de transporte y el resultado final quedan separados.

Cuando el servidor de correo hacía de directorio

RFC 821 mostraba una conversación casi doméstica. El cliente preguntaba VRFY Smith; el servidor podía responder 250 con el nombre completo de Fred Smith y su buzón. Si conocía un reenvío, ofrecía la dirección nueva. Si no encontraba coincidencias, lo decía. Si había más de un Smith, debía responder 553 User ambiguous.

EXPN convertía esa consulta en una lista. Ante el nombre de una lista de correo, una respuesta positiva de varias líneas podía entregar sus buzones, uno por línea. La especificación no trataba esos datos como pistas imprecisas: un éxito de VRFY tenía que incluir el buzón y un éxito de EXPN tenía que dar los buzones de la lista. El conocimiento local se convertía en evidencia utilizable por un interlocutor remoto.

La utilidad era concreta. Se podía detectar un nombre mal escrito antes de enviar, localizar un reenvío y seguir expansiones anidadas hasta encontrar un bucle. Como el directorio y el reparto dependían del mismo conocimiento, ubicar el diagnóstico dentro de SMTP parecía una economía sensata.

El problema era que la ventana de diagnóstico se abría en el mismo servicio que escuchaba a Internet.

La respuesta útil encontró otro usuario

RFC 1123 reforzó la función en 1989: obligó al receptor SMTP a implementar VRFY, recomendó EXPN y permitió que una instalación desactivara ambos o cerrara listas concretas. El texto conserva la tensión histórica. Los administradores los usaban para investigar entregas y bucles de listas multinivel; la expansión también podía suponer una exposición seria de privacidad y seguridad.

Con el correo masivo no solicitado, la misma interfaz adquirió una finalidad distinta. VRFY permitía probar nombres; EXPN, obtener muchas direcciones a partir de un identificador. RFC 2505 recomendó controlar quién podía ejecutar los comandos mediante conmutadores o listas de acceso. Propuso 252 como respuesta predeterminada al VRFY desactivado o bloqueado y recomendó mantener EXPN apagado por defecto.

No se trataba de que el diagnóstico hubiese dejado de ser legítimo. Un administrador que audita reenvíos internos y un recolector anónimo pueden enviar exactamente los mismos caracteres. La autorización procede de la identidad y del ámbito administrativo, no del nombre del comando.

La tercera respuesta honesta

Un protocolo binario habría obligado al servidor a fingir conocimiento. Responder 250 tras comprobar únicamente la sintaxis fabrica una verificación que no ocurrió. Responder siempre 550 fabrica una inexistencia. RFC 5321 considera que ambos comportamientos incumplen la norma.

252 rompe la falsa disyuntiva: “No se puede verificar al usuario, pero se aceptará el mensaje y se intentará la entrega”. No prueba que exista el buzón. No garantiza que un futuro RCPT TO sea aceptado bajo cualquier condición. Tampoco certifica que el mensaje alcance a una persona. Solo declara que el servidor no puede o no quiere emitir la afirmación de directorio solicitada, mientras deja abierta la vía ordinaria de entrega.

Un servidor MX puede saber que atiende un dominio y que una cadena tiene forma válida, pero no disponer en tiempo real de la base final de destinatarios. 252 conserva esa incertidumbre, en vez de convertir una apariencia razonable en un sí o un no falsos.

La política de seguridad usa la misma semántica. RFC 5321 exige que un sitio que cierre estos comandos por seguridad devuelva 252, no un código confundible con una verificación positiva o negativa. Negarse a revelar no demuestra que el usuario no exista.

Verificación, aceptación y entrega no son el mismo registro

Los sistemas de correo suelen comprimir estados adyacentes. Una sintaxis válida pasa a ser una “dirección verificada”. Un 250 en un salto se etiqueta como “entregado”. Una consulta bloqueada se registra como “buzón inválido”. En cada paso, una observación parcial recibe más autoridad de la que merece.

Hay que conservar, al menos, tres hechos. La verificación de directorio confirma que el servidor estableció realmente una dirección o expansión. La aceptación transaccional indica que un servidor asumió responsabilidad en un punto preciso. La entrega final depende de rutas posteriores, colas, reenvíos y procesamiento del destinatario. 252 se sitúa deliberadamente antes de esos desenlaces.

Por ello, una herramienta de supervisión no debe traducirlo ni a una marca verde de verificación ni a una invalidez definitiva. El estado correcto es incertidumbre explícita con una ruta de transporte posible. La transacción posterior podrá aportar evidencia; la consulta no puede anticiparla.

Cerrar una ventana no elimina todas las señales

Desactivar VRFY no borra toda evidencia sobre destinatarios. RFC 5321 señala que algunas implementaciones revelan información equivalente en las respuestas a RCPT. Otras posponen la comprobación hasta después de DATA, de modo que RCPT apenas informa. La seguridad marginal depende de toda la cadena de aceptación.

No basta, por tanto, con celebrar que un verbo devuelve 252. La medida reduce la consulta más barata y directa, pero las diferencias de código, tiempo de respuesta, dominios comodín, rebotes o informes posteriores pueden seguir dando pistas. Es necesario medir la superficie compuesta.

Tampoco sirve el argumento inverso: que existan otros métodos de recolección no justifica ofrecer EXPN al público. Retirar la vía más autoritativa cambia el coste y la confianza del atacante. La seguridad suele gobernar el precio y la calidad de la evidencia, no prometer secreto perfecto.

El diagnóstico sobrevivió dentro de un límite

RFC 5321 mantiene una función para ambos comandos. Usuarios autenticados y administradores del mismo dominio pueden auditar rutas, descubrir el reenvío automático de correo sensible o examinar listas. Un sitio puede reservarlos a solicitantes autenticados. Sobrevive la capacidad; desaparece el supuesto derecho del desconocido.

El registro SMTP actual de IANA conserva otra frontera. La implementación de VRFY sigue siendo obligatoria en servidores, aunque anunciarlo en EHLO es optativo. Tanto VRFY como EXPN figuran como MUST NOT en Message Submission. La autenticación necesaria para enviar el propio correo no concede automáticamente acceso al directorio del receptor.

SMTP no aprendió a evitar la pregunta mediante una mentira o un silencio absoluto. Aprendió a contestar con precisión una pregunta más pequeña. El servidor podía rehusar certificar a una persona, conservar la posibilidad de transportar un mensaje y reservar el diagnóstico rico para una relación justificada. En un protocolo hecho de respuestas, 252 limitó aquello que una respuesta podía afirmar que sabía.

Fuentes