Resumen

  • En SMTP, la respuesta positiva posterior a DATA acepta el mensaje como una unidad y transfiere al servidor toda la responsabilidad de entregar o informar fallos posteriores.
  • LMTP añadió una respuesta final por cada RCPT aceptado, correlacionada por orden, para que el gestor de cola reintentara solo los destinatarios pendientes; perder una respuesta todavía podía producir duplicados.

Un solo punto cerraba demasiadas obligaciones

Dos destinatarios han superado la fase RCPT. Tras recibir el cuerpo, el agente local deposita el mensaje en el primer buzón, pero el segundo está temporalmente sin cuota. El estado real ya es plural. La gramática final de SMTP no lo es.

RFC 5321 no admite éxito parcial en ese momento. Después del indicador de fin de datos, el servidor devuelve un resultado para la transacción. Si responde 250, asume plenamente el mensaje. Si más tarde un destinatario falla, el receptor debe reintentar o producir una notificación; no puede hacer que el único 250 sea simultáneamente éxito y error.

Ese reparto resulta útil entre servidores de correo que practican almacenamiento y reenvío. El receptor tiene una cola. Puede aceptar de forma duradera y trabajar después. Pero en el tramo entre un gestor de cola y un agente de entrega local, exigir otra cola completa solo para representar diferencias entre buzones duplica estado y recuperación.

LMTP nació para esa frontera limitada.

La cardinalidad de la respuesta trasladó la custodia

Publicado como RFC Informativo en 1996, RFC 2033 establece que, tras el punto final de DATA, el servidor LMTP emite una respuesta por cada comando RCPT que antes obtuvo éxito. Las respuestas conservan el orden de esos comandos.

Así, el primer 250 final cierra la deuda del gestor de cola con el primer destinatario. Un 452 para el segundo mantiene solo esa posición en espera. La cola original conserva el reintento; el agente local aporta el resultado de buzón sin adquirir un sistema paralelo de almacenamiento diferido.

El detalle «cada RCPT exitoso» evita varios errores. Una dirección rechazada antes de DATA no espera otro resultado. Si la misma ruta se aceptó dos veces, hay dos posiciones y dos respuestas. Una respuesta multilínea sigue siendo un único resultado. El cliente debe guardar el orden exacto, no reconstruirlo después agrupando textos de direcciones.

La primera aceptación de RCPT tampoco equivale a entrega. Permite incluir ese destinatario en la operación. Solo el resultado positivo posterior al cuerpo transfiere la responsabilidad final correspondiente.

LHLO declaró qué diálogo estaba activo

LMTP y ESMTP se parecen, pero discrepan justo en el punto donde una lectura equivocada corrompería el estado. Un cliente SMTP podría consumir el primer resultado LMTP como cierre total y atribuir los siguientes a otros comandos. Un cliente LMTP podría esperar una serie tras el único resultado de SMTP.

Por eso RFC 2033 sustituye HELO y EHLO por LHLO. Un servidor LMTP no debe aceptar positivamente los saludos SMTP y LMTP no debe operar en el puerto de servicio SMTP 25. La separación hace detectable una configuración en la que las dos partes creen usar contratos distintos.

La especificación exige además PIPELINING y códigos de estado mejorados. RFC 2920 preserva la correlación por orden cuando el cliente adelanta comandos. RFC 2034 y RFC 3463 refinan la causa del resultado. Sin la lista ordenada de destinatarios aceptados, un código más expresivo seguiría sin tener dueño.

Con CHUNKING, BDAT LAST también genera la serie por destinatario; un BDAT no final continúa recibiendo una sola respuesta. El cambio se vincula a la conclusión del mensaje, no a cada bloque de bytes.

La conexión podía romperse entre el hecho y su prueba

RFC 1047 explicó años antes el intervalo de sincronización de SMTP. El receptor puede haber decidido aceptar o incluso haber entregado, mientras el emisor todavía no ha recibido la confirmación. Si el enlace cae, ambos conservan razones para actuar: uno considera cumplida la entrega; el otro debe reintentar. El resultado puede ser una copia adicional.

LMTP reduce la unidad de ambigüedad al destinatario, pero no crea una transacción atómica con el buzón. Si el cliente registra el 250 de A, A sale de la cola. Si el agente deposita B y la conexión se corta antes de que su respuesta llegue, B continúa sin prueba para el cliente. RFC 2033 ordena procesar el prefijo de respuestas recibido y tratar el resto como fallo temporal.

El servidor debe enviar cada resultado pronto y vaciar el búfer antes de invertir tiempo considerable en la siguiente entrega. El cliente debe consumirlos a medida que llegan. Estas reglas acortan el sufijo incierto. No recuperan un acuse perdido ni deshacen un depósito.

La misma razón explica la recomendación de no usar LMTP en redes de área extensa. Su sitio natural es un trayecto corto hacia un agente local, con la cola duradera a un lado. Cuanto más largo y frágil sea el camino, más probable es separar la entrega de la constancia que permite cerrar el reintento.

Un resultado LMTP no era una DSN

Una DSN informa después sobre un mensaje cuya responsabilidad ya cambió de manos. El resultado final LMTP decide ese cambio en el momento de la entrega local. Un temporal conserva la posición en la cola actual; un positivo la entrega al agente.

Nada de ello prueba lectura humana, identidad del usuario o aparición en una interfaz. La evidencia pertenece a la custodia del transporte. La innovación fue impedir que un fallo local obligara a mantener una segunda cola para todos, no crear una certificación de atención.

Fuentes y límites

Las fuentes cerradas son RFC 1047, RFC 2033, RFC 2034, RFC 2920, RFC 3463 y RFC 5321. Definen semántica y límites, no despliegue actual, valores predeterminados ni una conexión universal. RFC 2033 es Informativo y no impone LMTP a todo sistema de correo.