Resumen

  • La respuesta positiva al terminador final de DATA hace que el receptor SMTP acepte el mensaje y la responsabilidad de entregarlo o retransmitirlo. Certifica un relevo de custodia, no el resultado final.
  • 250 solo adquiere significado probatorio junto a la orden que responde. EHLO, MAIL, RCPT, RSET, NOOP y el cierre de DATA pueden acabar con los mismos dígitos y afirmar cosas distintas.
  • La cadena auditable conserva sobre, respuestas por destinatario, aceptación final, cola duradera, cada nuevo relevo y el resultado local. Bandeja, cuarentena y lectura no se heredan de un salto anterior.

La firma pertenece al relevo

En la consola aparece una línea verde: el servidor remoto respondió 250 OK. La cola de salida elimina el mensaje y el indicador de envío sube. Ese comportamiento puede ser exactamente el correcto. El error comienza cuando el panel cambia la etiqueta a «entregado al destinatario».

SMTP no asigna un único significado a 250. Tras EHLO, la respuesta cierra el saludo y puede enumerar extensiones. Tras MAIL FROM, admite la ruta de retorno. Tras cada RCPT TO, conserva un destinatario para la transacción. RSET obtiene una conclusión positiva después de borrar el estado; NOOP puede recibirla sin alterar nada.

El mensaje completo solo cambia de dueño después de otra frontera. El cliente recibe 354, envía el contenido y marca su final. El servidor procesa entonces el sobre y los datos almacenados. Si acepta el mensaje para entrega, emite una conclusión positiva; si no, devuelve un fallo. RFC 5321 no permite expresar una aceptación parcial de la transacción en ese punto.

Con el 250 final, el receptor toma plena responsabilidad. La palabra clave no es «llegada», sino «responsabilidad». El receptor debe entregar o retransmitir, y debe encargarse de un fallo que descubra más tarde. El emisor puede borrar su copia porque la obligación ha pasado a otro operador.

Un registro que guarda únicamente tres dígitos pierde el hecho más importante: a qué acción contestaron. Para reconstruir el relevo hacen falta la sesión, la orden, MAIL FROM, los RCPT admitidos, el final de DATA, la hora y la identidad observada del servidor.

John Klensin aparece aquí con una función limitada. El perfil oficial de IETF identifica al Dr. John C. Klensin y mostraba 60 RFC en la fecha de consulta. RFC 5321 lo nombra como autor. Esa atribución documenta trabajo en un estándar colectivo; no demuestra que opere una cola actual ni que certifique un producto.

Aceptar obliga a conservar

La secuencia impone una consecuencia práctica. El servidor debería alcanzar la durabilidad que promete antes de enviar la respuesta positiva. Si primero dice sí y después intenta escribir, crea un intervalo peligroso: el emisor ya puede haber eliminado la única copia mientras el receptor todavía no la ha asegurado.

RFC 5321 ordena que un servidor no pierda un mensaje aceptado por causas frívolas, como una caída posterior o una falta de recursos previsible. No fija un motor de colas universal. Un sistema puede usar journal, base transaccional, réplica o almacenamiento local. La obligación es común; su ejecución pertenece al código real.

Por eso una auditoría no debe presentar el texto de la RFC como prueba de que hubo persistencia. El comprobante operativo es un identificador de cola unido al instante de aceptación, la clase de almacenamiento lograda y la configuración aplicable. Si el servicio promete replicación antes de responder, debe poder demostrar ese paso sin exponer el contenido del correo.

La idea de primacía del código en funcionamiento de Heng Lu ayuda a distribuir autoridad. El estándar define cuándo cambia la responsabilidad. El implementador construye la secuencia. El operador configura durabilidad y reintentos. El nombre del autor no sustituye ninguno de esos actos.

Entregar o retransmitir son dos caminos

La fórmula de RFC 5321 ofrece dos destinos legítimos para la responsabilidad: entregar o retransmitir. Un relay puede estar a muchos sistemas del buzón. Tras aceptar, se convierte en cliente de una nueva transacción y busca su propio 250 final. Cada aceptación abre un relevo diferente.

Las líneas Received permiten seguir declaraciones de paso: qué host dice haber enviado, cuál dice haber recibido y a qué hora. Son útiles para investigar rutas y bucles. No certifican la cola siguiente, la expansión de un alias, el comportamiento de un gateway ni la visibilidad para el usuario.

Incluso «entrega final» es un término de alcance protocolario. Para SMTP significa que el mensaje abandona el entorno SMTP. Normalmente llega al usuario o a un depósito asociado, pero otro sistema de correo todavía puede procesarlo y transmitirlo. La última orden SMTP no es necesariamente el último control sobre el mensaje.

Conviene modelar estados separados: aceptado por este salto, persistido, aceptado por el siguiente, transferido al agente local, colocado en buzón, retenido en cuarentena, descartado por política y lectura desconocida. Si un proveedor no expone una fase, el dato es desconocido; no debe heredarse del último 250 visible.

Un silencio tiene demasiadas causas

Si el receptor descubre después que no puede entregar, normalmente debe crear una notificación y dirigirla a la ruta de retorno del sobre. La propia notificación usa un reverse-path nulo para que su fallo no cree otra notificación infinita.

Pero el canal negativo no siempre existe. Un mensaje cuyo retorno ya es nulo no recibe un aviso SMTP. Un relay puede desconocer al destinatario final. Listas, alias y fallos temporales de nombres retrasan la decisión. El estándar también reconoce que, en el entorno de abuso actual, puede permitirse eliminar ciertos mensajes no deseados sin avisar a un supuesto remitente posiblemente falsificado.

La ausencia de bounce no acredita entrega. Puede corresponder a un éxito, a un aviso aún en cola, a un retorno imposible, a una pasarela que no transmite estados, a una política silenciosa o a un hueco de observación.

Los DSN de RFC 3461, RFC 3463 y RFC 3464 forman otra clase de comprobante. Un informe puede declarar por destinatario failed, delayed, delivered, relayed o expanded. Pedirlo no garantiza recibirlo. relayed no promete buzón; delivered describe una acción del sistema de correo y no una lectura humana. Además, el DSN debe recorrer su propia ruta.

El artículo histórico de BTW sobre DSN estudia esa gramática. El límite de este perfil está antes: el 250 final identifica al nuevo responsable, y solo una prueba posterior describe qué hizo con la obligación.

Cuando se pierde el sí

Supongamos que el receptor almacena el mensaje, envía 250 y la conexión cae antes de que el emisor reciba la respuesta. El receptor conserva una copia válida. El emisor no puede demostrar la aceptación, mantiene la suya y vuelve a intentar. El resultado puede ser una entrega duplicada.

Por eso RFC 5321 concede tiempo suficiente al cierre de DATA y, al mismo tiempo, pide minimizar la demora. El diseño reduce los fallos ambiguos, pero no puede asegurar que ambas partes observen el mismo último evento.

«No observé la respuesta final» no equivale a «el servidor rechazó». Es una incertidumbre con riesgo de duplicado. El sistema debería conservar el identificador original, la caída, la política de retry y cualquier clave posterior útil para reconciliar copias. Una estadística de sesiones positivas tampoco mide buzones: cuenta relevos reconocidos y puede ocultar reintentos.

LMTP cambia la cardinalidad

Durante SMTP, cada RCPT obtiene su respuesta antes del contenido. El 250 final de DATA cubre luego la transacción aceptada en conjunto. No entrega un resultado post-DATA individual por cada dirección.

LMTP, pensado para la transferencia local, sí devuelve después del punto final una respuesta por cada RCPT previamente aceptado, en el mismo orden. Una respuesta positiva hace que el servidor asuma responsabilidad por ese destinatario concreto.

La diferencia debe aparecer en los datos. Expandir un 250 SMTP a varios éxitos finales inventa precisión. Reducir una secuencia LMTP a un único estado puede asignar un fallo a la dirección equivocada. El registro debe declarar protocolo, orden de RCPT y número de respuestas.

El registro mínimo de custodia

El primer bloque une conexión y transacción, identidad observada de los extremos, contexto TLS separado, MAIL FROM, cada RCPT con respuesta, 354, final de DATA, resultado, hora e identificador de cola. El segundo bloque pertenece al receptor: persistencia, reintentos, siguiente hop, respuesta y desconexiones ambiguas.

La entrega local añade el resultado del agente o de LMTP. Un DSN aporta Action y Status por destinatario y necesita a su vez una prueba de salida. La ubicación en spam, la decisión de una pasarela propietaria y la lectura siguen sin afirmarse hasta que una fuente competente las observe.

Es una especificación inicial mínima, no una imposición sobre todas las arquitecturas. Cada operador decide motor de cola, privacidad, plazos y política. La coordinación consiste en conservar la orden que da sentido a la respuesta, no llamar entrega a la custodia y no regalar al siguiente salto una certeza que todavía no produjo.

La frase de cierre correcta es precisa: este servidor aceptó este sobre y este cuerpo al finalizar DATA; desde entonces asumió la obligación; estos relevos o resultados locales están demostrados; estas consecuencias para cada destinatario y usuario siguen abiertas.

Fuentes