Resumo

  • No SMTP, a resposta positiva após os dados aceita a transação inteira e transfere ao servidor a responsabilidade por entregar ou tratar falhas posteriores.
  • O RFC 2033 fez o LMTP responder, na ordem, a cada RCPT bem-sucedido; a fila pode manter só os destinatários não resolvidos, embora uma confirmação perdida ainda permita duplicação.

Uma transação escondia resultados incompatíveis

Um gerenciador de fila entrega a mesma mensagem a dois destinatários locais. Os dois comandos RCPT são aceitos. Depois do corpo completo, a primeira caixa recebe a mensagem e a segunda retorna uma condição temporária de quota.

O SMTP comum não encerra DATA com dois veredictos. Segundo o RFC 5321, não existe falha parcial no ponto final dos dados: o servidor aceita a mensagem para entrega ou não aceita. Ao devolver 250, assume responsabilidade integral. Se um destinatário falhar depois, cabe ao receptor reter trabalho ou emitir uma notificação posterior.

Esse desenho é coerente no armazenamento e encaminhamento entre hosts, porque o servidor receptor já opera uma fila persistente. Na passagem de um gerenciador de fila existente para um agente local, porém, obrigar o agente a criar outra fila apenas para representar diferenças entre caixas duplica custódia e recuperação.

O LMTP foi definido para essa passagem estreita, não para substituir o SMTP da Internet.

A quantidade de respostas mudou a custódia

O RFC 2033, publicado como Informational em 1996, determina uma resposta final para cada comando RCPT previamente bem-sucedido, na ordem em que foi enviado.

O 250 final de A permite retirar A do conjunto de retentativa. Um 452 para B mantém B na fila. O agente local informa o fato mais próximo da caixa postal, sem herdar uma segunda máquina de espera.

A correspondência é posicional. Um RCPT rejeitado antes de DATA não aparece na série final. Duas aceitações do mesmo forward-path ainda ocupam duas posições. Uma resposta multilinha conta como uma. Portanto, reagrupar por texto do endereço não preserva o contrato.

A aceitação inicial de destinatário também não é promessa de entrega. A transferência decisiva ocorre somente quando o resultado final correspondente é positivo.

LHLO tornou o contrato detectável

A semelhança com ESMTP criava risco. Um cliente SMTP poderia tratar a primeira resposta LMTP como fim da transação e deslocar as seguintes; um cliente LMTP poderia esperar uma série que um servidor SMTP nunca enviaria.

Por isso, LHLO substituiu HELO e EHLO. Um servidor LMTP não deve aceitar positivamente as saudações SMTP, e o protocolo não deve usar a porta de serviço SMTP 25. A distinção expõe uma configuração incompatível antes do envio do conteúdo.

O RFC também exige PIPELINING e códigos de status aprimorados. O RFC 2920 mantém a ordem de respostas quando comandos são antecipados; o RFC 2034 e o RFC 3463 refinam o significado do resultado. Esses códigos não substituem a lista ordenada que identifica o destinatário.

Com CHUNKING, BDAT LAST recebe a mesma série individual. Blocos BDAT sem LAST continuam tendo uma resposta. A pluralidade pertence à conclusão da mensagem.

O intervalo de duplicação continuou existindo

O RFC 1047 descreveu o intervalo entre a aceitação no receptor e a chegada da confirmação ao emissor. Se a conexão cai, um lado pode ter concluído a entrega enquanto o outro precisa repetir. Surge uma cópia adicional.

No LMTP, esse intervalo é separado por destinatário. Se a confirmação de A foi recebida e tornada durável, A está encerrado. Se B foi gravado, mas sua resposta se perdeu, o cliente não dispõe da prova necessária. O RFC 2033 manda processar o prefixo recebido e tratar as posições restantes como falhas temporárias.

O servidor deve enviar e descarregar cada resposta prontamente; o cliente deve consumi-la sem esperar o lote inteiro. Isso reduz o sufixo ambíguo, mas não transforma uma gravação local e um ACK de rede em uma transação atômica.

A recomendação de não usar LMTP em redes de longa distância decorre daí. O caminho previsto é curto e local. Quanto mais instável a ligação, maior a chance de o ato se separar da evidência.

Resposta LMTP e DSN não eram a mesma coisa

Uma DSN relata posteriormente um evento sob responsabilidade já aceita. A resposta LMTP decide a própria transferência: temporária significa que a fila atual continua devendo; positiva significa que o agente local assumiu aquela posição.

Ela não prova leitura humana, exibição em uma interface ou identidade do destinatário. O protocolo organiza obrigação de transporte, não atenção.

Fontes e limites

O conjunto fechado é RFC 1047, RFC 2033, RFC 2034, RFC 2920, RFC 3463 e RFC 5321. Eles demonstram gramática e responsabilidade, não adoção atual, padrões de fornecedores ou um socket universal. O RFC 2033 é Informational e não impõe LMTP a todos os sistemas.