Resumen

  • DELIVERBY añadió a MAIL FROM un saldo de segundos y dos modos: R detenía los intentos y devolvía fallo al vencer; N avisaba del retraso pero mantenía la entrega bajo la política local.
  • Cada servidor compatible recalculaba el tiempo restante antes del siguiente salto. La capacidad no compraba prioridad, no ampliaba la retención normal y no garantizaba que el mensaje o la DSN llegaran dentro del plazo.

La aritmética del ejemplo de RFC 2852 cuenta una historia de autoridad. El primer cliente pide entrega en 120 segundos. El relé emplea 22 antes de abrir la siguiente sesión. Al emitir el nuevo MAIL FROM, no puede volver a escribir 120. Tiene que escribir 98.

Si pudiera restaurar el número original, cada frontera administrativa borraría el coste temporal de la anterior. El mensaje conservaría para siempre un plazo que nunca se acercaría a cero. El protocolo parecería compatible en cada enlace y fracasaría como obligación de extremo a extremo.

El Deliver By SMTP Service Extension, publicado en junio de 2000, evitó esa ficción. Permitió que el significado temporal del remitente viajara por un sistema de almacenamiento y reenvío, pero exigió que cada operador aceptara la condición por separado y que el saldo disminuyera.

La urgencia no entró en la cola como privilegio

El caso inicial era cotidiano: un correo podía activar un buscapersonas antes de las 17:00 y ser inoportuno después. La cola ordinaria solo sabía que un fallo temporal merecía otro intento. No sabía que el contenido perdía valor fuera del horario.

Un servidor muestra DELIVERBY en EHLO y puede anunciar el mínimo que acepta para Return. El cliente añade BY a MAIL FROM; no aparece ningún verbo nuevo. Tampoco aparece una orden de prioridad.

El receptor puede no acelerar nada. Conserva su planificación, sus recursos y sus reglas de equidad. El remitente decide qué consecuencia desea cuando el tiempo termina, no qué mensaje salta por delante de otro. El operador puede rechazar un intervalo incompatible con su capacidad antes de asumirlo.

Esta separación distribuye mejor el riesgo. Quien conoce el valor externo declara el plazo. Quien paga la cola declara el mínimo y decide la admisión. Aceptar crea un deber concreto; negarse evita una promesa vacía.

El saldo evitaba depender de relojes idénticos

BY contiene segundos decimales con signo, un modo R o N, y opcionalmente T para traza. El valor absoluto máximo es de novecientos noventa y nueve millones novecientos noventa y nueve mil novecientos noventa y nueve segundos, tanto en negativo como en positivo.

Es un delta, no una fecha absoluta. El MTA receptor suma el valor a su reloj y obtiene un deliver-by-time local. Antes de retransmitir calcula el saldo cercano al instante del siguiente MAIL FROM.

Dos organizaciones no necesitan acordar una hora mundial exacta para preservar el mismo presupuesto. Sin embargo, la red tarda. RFC 2852 reconoce que la transmisión del comando alarga ligeramente el plazo efectivo y que el error se acumula en varios saltos. La resta es coherente; la sincronía perfecta no existe.

El valor tampoco significa “entregar después”. No programa una liberación futura, sino un límite superior. Ni extiende la retención habitual: si la política local abandona antes un mensaje imposible, puede devolverlo antes del deliver-by-time.

Al llegar a cero, el verbo operativo dependía del modo

En R, Return, cero y los negativos son inválidos. Si el mensaje no fue entregado o retransmitido cuando vence, no puede haber más intentos. El MTA genera para los destinatarios aplicables una DSN failed con 5.4.7, delivery time expired.

En N, Notify, el cruce no cancela la custodia. La cola continúa según su política y genera una DSN delayed con 4.4.7 para los destinatarios que admiten aviso. Cero y los negativos conservan información: muestran que el plazo ya quedó atrás aunque la entrega siga siendo legítima.

La diferencia impide confundir “tarde” con una única decisión. Una instrucción puede ser dañina después de su momento y exigir devolución. Un documento puede seguir siendo útil, aunque el remitente necesite conocer la demora. Return cambia lo que la cola puede hacer; Notify cambia lo que debe evidenciar.

Los fallos permanentes siguen cerrando antes. Los temporales siguen justificando reintentos. Una política de retención más breve sigue vigente. DELIVERBY añade un corte semántico, no sustituye toda la vida de la cola.

El siguiente salto tenía que poder heredar

Si el servidor posterior anuncia DELIVERBY, el relé mantiene el modo y transmite el nuevo saldo. Para R, la cadena debe ser completa: no puede pasar a un servidor sin la extensión ni a uno cuyo mínimo declarado sea mayor que el tiempo restante.

El relé puede evaluar otra ruta válida. Si ninguna acepta la obligación, debe tratar el mensaje como no entregable. Entregarlo sin el plazo no sería una degradación inocente; cambiaría la decisión que el remitente eligió para el vencimiento.

N permite cruzar un salto incapaz porque la entrega puede continuar después de la fecha. Pero la pérdida no queda oculta. El relé genera una DSN relayed para los destinatarios aplicables y, si el siguiente entorno entiende DSN, preserva la petición de retraso donde corresponda.

Así, el protocolo no unifica las colas. Define el pequeño estado común que debe sobrevivir: saldo, modo y evidencia de la frontera donde la semántica deja de pasar. Es coordinación mínima con decisión local.

Una respuesta temprana no conocía todavía a todos los destinatarios

El servidor puede aceptar MAIL FROM y rechazar más tarde en RCPT TO, DATA o fin de datos. La petición llega antes que toda la información necesaria para juzgarla. El primer 250 no certifica entrega puntual; solo confirma aceptación en esa etapa.

El mínimo anunciado hace visible otro límite. Si el saldo cae por debajo de la capacidad declarada del siguiente sistema, no hay interpretación creativa que cierre la brecha. La ruta no puede asumir Return en esos términos.

La DSN describía el resultado, pero viajaba por su cuenta

DELIVERBY usa DSN para expresar failed, delayed y relayed, y añade Deliver-By-Date al informe. T puede pedir notificaciones de relevo no terminales aunque no se haya solicitado éxito.

DSN estructura la acción observada. DELIVERBY determina la acción exigida al vencer. Esa diferencia mantiene esta historia separada de la del recibo: aquí el objeto central no es qué prueba un informe, sino quién puede conservar un mensaje después de que el tiempo se agota.

La DSN de retorno no comparte necesariamente la prioridad ni el reloj del mensaje original. Un BY=60;R puede producir fallo a los sesenta segundos y aun así informar al remitente más tarde. La obligación hacia delante es acotada; el conocimiento del remitente no queda mágicamente sincronizado.

El saldo también podía convertirse en sonda

La traza revela relevos. Una secuencia de mensajes con plazos breves y crecientes puede comparar resultados y sugerir umbrales o latencias. RFC 2852 reconoce esa capacidad de sondeo en sus consideraciones de seguridad.

La inferencia tiene límites. Un número negativo en Notify no identifica al causante. 5.4.7 no demuestra negligencia. relayed demuestra transferencia, no entrega final. El tiempo da evidencia operacional, no un veredicto automático.

El registro SMTP de IANA sigue incluyendo DELIVERBY, con referencia a RFC 2852 y nivel MAY. Es un dato de registro, no un censo de proveedores.

La innovación fue hacer heredable una obligación sin centralizar el sistema que la cumplía. El remitente podía definir cuándo seguir era incorrecto. Cada operador podía rechazar. El relé que aceptaba solo podía entregar el saldo real. Allí donde la semántica terminaba, el límite debía aparecer como fallo o evidencia.

La cuenta regresiva no gobernó la cola. Impidió que la cola fingiera que el tiempo gastado nunca había existido.

Fuentes