Resumen

  • RFC4865 permite que un cliente encargue al servidor de envío conservar un mensaje hasta un momento futuro. Prohíbe liberarlo antes, pero no garantiza que salga exactamente entonces ni que llegue a esa hora.
  • Al combinar esa espera con DELIVERBY, el cliente debe situar la entrega límite después de la liberación. El servidor compatible debe rechazar el conflicto que la norma describe; un calendario válido no elimina los riesgos del reloj, el almacenamiento o el trayecto posterior.

La tentación de arreglar automáticamente una solicitud mal planteada es comprensible. Un servicio que devuelve un error parece menos amable que otro que consigue completar la operación. Pero esa amabilidad puede esconder una elección: para mostrar éxito, el sistema ha decidido qué parte de la petición del cliente dejará de cumplir.

El envío programado ofrece un ejemplo nítido. Imaginemos, sin atribuirlo a ningún incidente real, un correo presentado por la mañana con estas condiciones: no podrá salir hasta mediodía y no se harán intentos de entrega después de las once. La incompatibilidad no se debe a una cola lenta. Incluso un servidor vacío y una conexión instantánea dejarían intacta la contradicción.

RFC4865, publicada en mayo de2007, define Future Message Release como una extensión del servicio de envío inicial por SMTP. Su utilidad es trasladar al servidor la espera que, de otro modo, tendría que organizar el terminal. Un cliente sin almacenamiento local adecuado o que no permanecerá conectado puede entregar anticipadamente el contenido para que otro lo conserve.

Ese desplazamiento tiene un precio operativo. El servidor recibe datos que todavía no debe poner en circulación, ocupa recursos presentes para una obligación futura y necesita una base temporal. El remitente obtiene comodidad, no autoridad sobre todos los servidores que después transportarán el mensaje.

Rechazar antes de tener que elegir por otro

El conflicto aparece cuando se añade DELIVERBY. Esta extensión, descrita en RFC2852, permite expresar un plazo de entrega y el tratamiento deseado cuando no se logra entregar a tiempo. No es una orden de salida diferida ni una exigencia de procesamiento prioritario.

RFC4865 dedica su apartado5.2 a la combinación. Para el cliente, la regla exige que el plazo de entrega quede estrictamente después del momento de liberación, tanto si este se expresa directamente como si se calcula a partir de una duración. No basta con que ambas cifras estén en el futuro: deben dejar un intervalo compatible.

La obligación del servidor está redactada con un matiz distinto. Si admite ambas extensiones y determina que la liberación es posterior al límite de entrega, debe rechazar MAIL. La especificación recomienda responder501 y utilizar el estado mejorado5.5.4.

Conviene no borrar la diferencia entre las dos formulaciones. El cliente necesita un plazo estrictamente posterior. La condición explícita de rechazo del servidor se refiere a una liberación posterior al plazo. No debe reescribirse como una comparación de mayor o igual. Tampoco esa redacción más estrecha autoriza al cliente a pedir dos instantes iguales: seguiría incumpliendo su propio requisito.

La igualdad merece, por tanto, un caso de prueba separado si importa al servicio. Hay que comprobar la obligación del cliente y observar qué hace el servidor utilizado, sin convertir una lectura cómoda del texto en una garantía de interoperabilidad. Este artículo no ha ejecutado esa prueba.

En la contradicción evidente, la negativa evita que una decisión empresarial se esconda dentro de una corrección técnica. El remitente puede preferir que no se divulgue nada antes de una hora, o que una notificación no llegue cuando ya ha perdido utilidad. El servidor no sabe cuál de las dos preferencias puede sacrificar. Puede devolver la solicitud para corregirla; no debería inventar una jerarquía entre ellas para mejorar su tasa de aceptación.

La hora programada marca un permiso, no un resultado

El servidor anuncia FUTURERELEASE en EHLO junto con dos máximos: un intervalo de espera y una fecha-hora futura. El cliente comprueba esa capacidad y añade exactamente un parámetro de espera a MAIL. HOLDFOR expresa una duración; HOLDUNTIL, una fecha-hora. Cada uno tiene que respetar su máximo correspondiente.

La ausencia de ese parámetro no implica un periodo de retención predeterminado. Tampoco anunciar la extensión significa que cualquier mensaje quedará programado. La solicitud concreta sigue siendo la unidad sobre la que se adquiere la obligación.

Las dos formas existen para clientes con capacidades temporales diferentes. Algunos pueden manejar una hora local sin disponer de información fiable sobre la zona horaria; otros no tienen un reloj suficientemente preciso. El documento acepta las ventajas prácticas de admitir ambas representaciones. Pero el reloj no deja de ser un componente del servicio.

Una vez aceptado el mensaje con la petición de liberación futura, el servidor no debe liberarlo antes de que transcurra el intervalo o llegue el instante solicitado. Esto establece un mínimo, no un compromiso de ejecución exacta en ese momento. Cuando se levanta la prohibición de salida todavía quedan la planificación de la cola, el intento real y el transporte.

Por eso la expresión «programado para las doce» puede resultar demasiado amplia. Puede describir una instrucción almacenada, una elegibilidad que ya ha llegado o una salida efectivamente observada. Son hechos distintos. Ninguno prueba por sí solo que el buzón final haya recibido el contenido o que una persona lo haya leído.

Tampoco HOLDFOR constituye un refugio universal frente a los problemas de hora. RFC4865 advierte expresamente de que un reloj inexacto o cambiante en el servidor puede provocar liberación prematura o tardía con ambos mecanismos. La representación relativa resuelve ciertas dificultades del cliente; no certifica el comportamiento temporal del servidor.

Hay dos maneras de alcanzar el plazo

DELIVERBY distingue Return y Notify. Si en modo Return el mensaje no ha sido entregado o retransmitido antes del límite, no pueden continuar los intentos de entrega. Debe generarse la notificación de fallo correspondiente para los destinatarios cuyas condiciones de notificación la requieren.

En modo Notify, alcanzar el plazo no obliga a detener el trabajo. Deberían continuar los intentos según la política del sitio, junto con la notificación de demora prevista para los destinatarios pertinentes. El mismo reloj puede, pues, marcar dos decisiones operativas diferentes.

Un campo de estado que solo diga «vencido» elimina información necesaria para actuar. Si el sistema abandona todo lo vencido, puede interrumpir solicitudes Notify que debían continuar. Si reintenta todo por principio, puede incumplir una condición Return. La recuperación no consiste en elegir siempre el comportamiento que produce más entregas.

La siguiente etapa también limita lo que puede prometerse. Return no puede retransmitirse a un servidor que no admita DELIVERBY ni a uno cuyo intervalo mínimo fijo supere el tiempo restante. Notify sí puede pasar por una etapa no compatible, con las consecuencias de notificación que fija RFC2852. El compromiso depende de la capacidad que se conserva en el recorrido.

El plazo tampoco prolonga la retención ordinaria de mensajes que no se pueden entregar, y no otorga prioridad por sí mismo. El servicio conserva sus límites de tratamiento. Una ventana temporal coherente no representa una reserva del ancho de banda, del procesador o de los recursos del destinatario.

Además, el conocimiento del resultado puede llegar tarde. RFC2852 aclara que las notificaciones de estado no tienen por qué recibir trato acelerado. Detener los intentos a tiempo no garantiza que el remitente reciba inmediatamente el aviso de que se han detenido. El silencio después del plazo no debe convertirse en una afirmación de entrega.

El remitente autorizado también consume la cola

La espera centralizada crea un inventario. No basta con contar los mensajes que están circulando: hay que guardar otros que no pueden circular todavía. Una autorización válida identifica a quien solicita ese almacenamiento, pero no hace ilimitado el presupuesto.

RFC4865 recomienda un cupo por usuario para los mensajes de liberación futura. Si el servidor aplica ese cupo y detecta que el nuevo mensaje lo superará, debe rechazar MAIL. Se trata de una obligación condicionada a la existencia y detección del exceso, no de una afirmación de que todas las implementaciones reservan espacio del mismo modo.

El documento diferencia también dos estados de insuficiencia: X.7.16 para el cupo del usuario y X.7.17 para el cupo del sistema. En el primero puede ser necesario que se vacíe trabajo de ese usuario; en el segundo, recuperar margen compartido. No son diagnósticos intercambiables y no justifican un tiempo universal de reintento.

La distribución futura de la carga importa. Un conjunto de solicitudes individualmente admisibles puede concentrar muchas liberaciones en el mismo instante. Esto es una posibilidad operativa derivada del mecanismo, no un incidente medido aquí. El límite puede trasladarse de los bytes almacenados a la capacidad de procesar y transportar la oleada.

Así se entiende mejor el máximo futuro anunciado: expresa hasta dónde admite esperar el servicio, no qué capacidad estará libre entonces. Confundirlo con una reserva crea una promesa comercial que el estado del sistema no demuestra.

Lu Heng plantea en su Nota32 el problema de separar el poder de decisión de sus consecuencias económicas. Aplicado al correo programado, ese enfoque pregunta quién amplía el horizonte ofrecido, quién financia el inventario pendiente y quién responde por las salidas. No permite deducir mala fe de una empresa ni de sus técnicos. Su Nota36 sobre BTW.Media exige precisamente describir estructuras sin sustituir la evidencia por una campaña.

La documentación del encargo debe sobrevivir al reloj

Cuando el servidor genera una DSN sobre un mensaje con una solicitud de liberación futura, RFC4865 exige Arrival-Date y Future-Release-Request en la parte legible por máquina. El segundo campo conserva el valor de espera solicitado en la forma prevista por el protocolo.

Esto ayuda a distinguir una demora intencionada de una demora del transporte. Pero conserva una petición, no todas las observaciones de ejecución. Saber qué se pidió no demuestra cuándo se intentó liberar el mensaje, si aceptó la siguiente etapa o si terminó entregándose.

El cliente tampoco puede pedir Future Message Release al enviar una DSN o una notificación de disposición MDN al servidor de envío. El informe del tratamiento no debe convertirse, mediante esta extensión, en otra notificación deliberadamente programada. La prohibición no significa que la red sea incapaz de retrasar esos informes.

Date, en la cabecera, no sustituye al registro de la cola. RFC4865 explica que permanece sin cambiar después de la presentación; el cliente puede elegir una fecha futura y el transporte no debe entender que tiene que modificar las trazas para ocultar la espera. Otra cosa es la corrección limitada, durante la presentación, de una Date ausente o con sintaxis inválida que permite RFC6409.

RFC6409 reemplaza RFC4409 y separa envío inicial y retransmisión. El primero utiliza normalmente el puerto587. Su posibilidad general de designar ciertos servicios en25 para envío inicial no elimina el ámbito propio de FUTURERELEASE: no convierte un servicio de retransmisión ordinaria en uno al que corresponda anunciar esta capacidad.

Lo que aún hay que observar

La errata editorial2040 de RFC4865, verificada en2010, corrige una producción de fecha-hora sin definición para remitir a date-time de RFC3339. La mención del informante a su propio servidor funcionando es testimonio histórico atribuido, no una medición de adopción actual.

La errata editorial2300 de RFC2852 está retenida para una futura actualización del documento y se refiere a espacios en la gramática. No cambia las consecuencias del vencimiento. Es importante conservar tanto el contenido como el estado de estas correcciones.

No se ha enviado correo de prueba, alterado relojes ni intervenido en colas de producción para este análisis. La evidencia establece obligaciones y límites; el comportamiento real de un proveedor exige observación propia. Esto incluye la igualdad de tiempos, la exactitud de liberación y la gestión de la carga concentrada.

Un servicio fiable no debería medir su éxito únicamente por cuántas solicitudes acepta. También debe poder explicar qué promesas se negó a hacer, qué obligaciones aceptó realmente y quién conserva la evidencia de su ejecución. Antes de pedir a un correo que llegue a tiempo, hay que dejarle una oportunidad coherente de salir.

Fuentes