Summary

  • La RFC 1845 propuso en 1995 la extensión experimental CHECKPOINT: TRANSID distinguía una operación de envío y el servidor guardaba su estado en almacenamiento no volátil.
  • En el ejemplo, 355 6135 indicaba 6.135 octetos de datos del mensaje almacenados. El cómputo excluía las órdenes de sobre y los octetos añadidos por SMTP para proteger líneas que empiezan por un punto.

Un mensaje largo enviado por una conexión poco fiable podía convertirse en una factura repetida. SMTP original no ofrecía al cliente un sitio donde retomar una operación de envío después de que se rompiera TCP. La propuesta experimental de D. Crocker, N. Freed y A. Cargille, fechada en septiembre de 1995, repartió el trabajo: el servidor conservaría lo recibido; el cliente volvería con la identidad de la misma operación y preguntaría cuánto faltaba. La cifra 6.135 pertenece al ejemplo escrito en la RFC, no a una avería documentada.

El primer paso era negociar la capacidad. El cliente enviaba EHLO y solo podía usar el mecanismo si la respuesta del servidor incluía CHECKPOINT. En MAIL FROM añadía un TRANSID sensible a mayúsculas y minúsculas. Esta marca correspondía a una copia concreta del mensaje que se movía por un enlace SMTP. El Message-ID de la cabecera podía acompañar a varias copias que siguieran rutas diferentes; no servía para recuperar sin ambigüedad una transferencia. El servidor debía tratar TRANSID como una cadena opaca, aunque su sintaxis incluyera una parte parecida a un dominio.

Guardar un identificador en la memoria volátil habría sido una broma cara. RFC 1845 pedía al receptor conservar también el estado más reciente de la operación en almacenamiento no volátil. Recomendaba mantener los datos interrumpidos al menos 48 horas, sin imponer un plazo fijo. Tras la caída, el cliente esperaba a que se liberaran las conexiones anteriores y consultaba DNS. Probaba primero la dirección original si seguía siendo aceptable; después, otras direcciones válidas. Si en otro servidor no existía el estado, enviaba la operación entera de nuevo. La entrega no quedaba parada a la espera del regreso del primer equipo.

La respuesta 355 tenía una definición que cerraba muchas trampas. El desplazamiento era la posición, desde cero, del siguiente octeto de datos del mensaje que el receptor esperaba. Equivalía a contar los octetos ya almacenados con éxito. MAIL FROM y RCPT TO no entraban en la suma. Tampoco los octetos insertados por el mecanismo de dot-stuffing. Al reanudar mediante DATA, el punto tenía que caer al comienzo de una línea. Por eso «saltar 6.135 bytes» no podía significar buscar una posición cualquiera en el archivo local; había que reproducir el formato canónico que SMTP contaba.

El diálogo termina sin fanfarria: el cliente repite el mismo MAIL FROM y TRANSID, recibe 355 6135, manda DATA desde el resto y obtiene 250 OK. La RFC incluso describe una implementación que reconstruye todo el flujo en el cliente y suprime la salida hasta alcanzar el desplazamiento. El ahorro se produce en la red, donde importaba para el enlace que se había roto.

El recibo tenía límites útiles. Confirmaba un prefijo almacenado bajo una identidad de transferencia concreta. Ni identificaba todas las copias del correo ni decía que alguien hubiera abierto el mensaje. Justamente por eso servía para una decisión operativa precisa: cuánto podía dejar de retransmitirse sin inventar progreso.