Resumen

  • El SMTP de 1982 permitía que un servidor aceptara correo para retransmitirlo y se convirtiera en emisor del siguiente tramo.
  • El RFC 2505 de 1999 exigió poder rechazar ese trabajo cuando nadie lo había autorizado: HELO y MAIL FROM eran declaraciones del visitante, no credenciales.

Al taxista del correo le bastaba con oír «vengo de parte del jefe» para llevar un cargamento al otro extremo de la red. La carrera la pagaba el dueño del servidor. La idea original de retransmitir mensajes era útil; la versión que prestaba el vehículo a cualquier desconocido terminó siendo un excelente negocio para quien enviaba correo no solicitado.

El RFC 821 de agosto de 1982 describía el relevo como una tarea posible del servidor SMTP receptor. Podía aceptar o rechazar un mensaje dirigido a otro servidor. Si lo aceptaba, pasaba a ser el emisor en la etapa siguiente. La dirección final del buzón y la ruta entre máquinas eran cosas diferentes. Aquel mecanismo permitía que un mensaje cruzara sistemas distintos sin exigir un camino directo de extremo a extremo.

Para 1999, la pregunta difícil ya no era cómo mover la carta. Era quién podía encargársela a una máquina ajena. El RFC 2505 de febrero de 1999, Best Current Practice 30, describió el relevo sin autorización como consumo indebido de recursos y daño a la reputación del operador. Exigió que el programa de transporte de correo pudiera controlar y negar ese servicio. El taxi podía seguir circulando; el desconocido ya no recibía las llaves por pedirlas con educación.

La especificación ordenó las señales de una conversación SMTP según la confianza que merecían. HELO anuncia un nombre de máquina que el interlocutor puede inventar. MAIL FROM declara un remitente igualmente falsificable. RCPT TO identifica el destino pretendido, y el servidor conoce la dirección de red del equipo que se conecta. Autorizar el transporte a partir del saludo o del supuesto remitente equivalía a aceptar un carné escrito por su portador cinco segundos antes.

El criterio recomendado se apoyó en responsabilidades verificables por el propio operador. El servidor podía admitir mensajes para los dominios que atendía o reenviaba por acuerdo. También podía prestar el relevo a un equipo autorizado por su dirección de origen o, cuando la política confiaba en DNS, por su nombre. El resto debía recibir un rechazo. Esta regla no decidía si el contenido era agradable; decidía quién podía gastar capacidad y reputación de ese servidor en otro tramo de entrega.

Los caminos antiguos complicaban el control. El RFC 2505 señaló las rutas @a,@b:, los trucos con % y los recorridos UUCP marcados con !. Una comprobación superficial del destinatario podía confundir una parada intermedia con el destino final. También existían pasarelas legítimas que usaban direcciones poco corrientes. Por eso el documento pedía inventariar los algoritmos de encaminamiento antes de cerrar el relevo. Un portero que ignora cómo se escribe la dirección real deja entrar al tramposo y expulsa al vecino.

En junio de 1999, el RFC 2635, DON'T SPEW, llevó la cuestión a la mesa del proveedor de acceso. Aconsejó mantener los servidores cerrados al relevo de extraños, publicar una política de uso, comprobar las acusaciones antes de suspender cuentas y atender direcciones como abuse y postmaster. La regla de software cerraba una puerta. La organización tenía que abrir otra para escuchar los informes de abuso y corregir los errores.

El RFC 5321 de octubre de 2008 conservó la tensión que esa puerta no resolvía por sí sola. El correo arrastraba una expectativa de entregar el mensaje o devolver un aviso de fallo. El volumen de mensajes no deseados hacía necesarios ciertos rechazos y descartes, mientras que la desaparición silenciosa debilitaba la confianza en la entrega. Elegir quién puede usar un relevo y explicar qué ocurrió con un mensaje son decisiones distintas.

La red siguió necesitando mensajeros entre sistemas. Lo que cambió fue la forma de contratarlos. El servidor no tenía que creer el nombre que el cliente gritaba al llegar; tenía que mirar si esa ruta y ese interlocutor estaban dentro del servicio que su operador había aceptado prestar. El taxi del correo no dejó de trabajar. Dejó de repartir vales gratuitos a quien sabía pronunciar HELO.