Resumo

  • A resposta positiva ao terminador final de DATA faz o receptor SMTP aceitar a mensagem e assumir a responsabilidade de entregá-la ou retransmiti-la. É um comprovante de custódia, não de destino.
  • O código precisa permanecer ligado ao comando. 250 depois de EHLO, MAIL, RCPT, RSET ou NOOP encerra atos diferentes e não significa que o corpo completo foi aceito.
  • Uma cadeia confiável preserva envelope, respostas por destinatário, fim de DATA, fila durável, cada salto e o resultado local. Caixa postal, quarentena e leitura exigem provas próprias.

O painel encerrou a história cedo demais

O registro diz que a sessão terminou com sucesso. O sistema de origem recebeu a resposta final e apagou a cópia. Ao mesmo tempo, o destinatário procura a mensagem sem encontrá-la. O protocolo pode ter funcionado corretamente até o ponto observado.

O problema é a legenda escolhida para a observação. 250 não é uma palavra única dentro de SMTP. Após EHLO, ele conclui a apresentação e pode trazer extensões. Após MAIL FROM, aceita o caminho de retorno. Cada RCPT TO pode ser aceito separadamente. RSET recebe confirmação ao limpar a transação; NOOP recebe confirmação sem produzir trabalho.

O corpo inteiro só entra no compromisso depois de DATA. O servidor primeiro envia 354, autorizando a transmissão. O cliente manda o conteúdo e o marcador final. Só então o receptor processa reverse-path, destinatários aceitos e dados armazenados. Se aceitar a transação para entrega, responde positivamente; se não aceitar, devolve falha.

Segundo a RFC 5321, a resposta positiva nesse limite transfere responsabilidade total. O remetente não viu a caixa postal. Ele viu outro sistema prometer que entregará, retransmitirá ou tratará uma falha descoberta depois.

Guardar apenas os dígitos remove a pergunta respondida. O recibo precisa incluir conexão, transação, comando, MAIL FROM, RCPTs aceitos e recusados, final de DATA, horário, identidade observada do servidor e eventual identificador de fila.

John Klensin ocupa um lugar documental, não operacional. O perfil oficial da IETF identifica o Dr. John C. Klensin e listava 60 RFCs no momento da pesquisa. A RFC 5321 o apresenta como autor. Isso prova participação na elaboração de um padrão coletivo, não comando sobre um serviço de e-mail nem conformidade de uma implementação.

A fila deve existir antes da promessa

O sentido da resposta obriga uma ordem segura. O receptor precisa atingir a durabilidade que oferece antes de enviar o aceite. Se responder e só depois tentar persistir, abre um intervalo no qual a origem já pode ter descartado sua única cópia e o destino ainda não tem uma cópia recuperável.

A RFC 5321 diz que uma mensagem aceita não pode ser perdida por motivos frívolos, como uma falha posterior ou uma escassez previsível. Ela não escolhe um banco de dados ou mecanismo de replicação. Operadores podem usar journal, storage transacional, réplica ou outra técnica. O texto distribui obrigação; o código em execução produz a evidência.

Por isso, citar a RFC não demonstra que um fsync ocorreu. Um produto que promete resposta somente após replicação deve preservar o handle da fila, a etapa de persistência, a versão de configuração e a hora do reply. Esse comprovante pode evitar o conteúdo da mensagem e ainda provar a sequência.

O princípio de running-code primacy de Heng Lu impede que a reputação do padrão seja usada como recibo de uma máquina. Autor, implementador e operador têm autoridades distintas. Klensin não assina o estado de uma fila apenas porque escreveu a gramática que ela deveria cumprir.

Custódia pode seguir por relay

O receptor assume responsabilidade por entregar ou retransmitir. A segunda opção é decisiva. Um relay pode estar longe da caixa final. Depois de aceitar, ele se torna cliente em outra sessão SMTP e solicita um novo aceite ao próximo hop. Cada transação abre um novo relógio e um novo dono.

Linhas Received ajudam a reconstruir esses saltos. Elas registram identidades declaradas e horários. Não são certificados fim a fim: não provam que a fila seguinte foi persistida, que um alias foi expandido sem perda, que um gateway preservou o destinatário ou que o provedor exibiu a mensagem.

Até “entrega final” tem escopo técnico. Para a RFC 5321, é a saída do ambiente SMTP. Normalmente a mensagem alcança o usuário ou um mail drop associado, mas outro sistema de correio ainda pode processá-la e transmiti-la. A última operação SMTP não é a última decisão humana.

Um modelo público pode separar: aceito neste hop, persistido localmente, aceito no hop seguinte, passado ao agente local, gravado na caixa, retido em quarentena, descartado por política e visibilidade ao usuário desconhecida. Quando uma plataforma não expõe um estágio, deve-se registrar “desconhecido”, não copiar o sucesso anterior.

Sem bounce não significa entregue

Quando a falha surge depois do aceite, o servidor responsável normalmente cria uma notificação para o reverse-path do envelope. A própria notificação usa caminho reverso nulo, evitando que uma notificação impossível gere outra.

Há situações sem retorno. Se o reverse-path original é nulo, não se envia uma falha SMTP para ele. Um relay, lista ou alias pode impedir validação durante a transação. Uma falha temporária de nomes posterga o resultado. E o ambiente moderno de abuso admite políticas que descartam mensagens indesejadas sem produzir backscatter para um remetente possivelmente forjado.

Logo, ausência de bounce pode significar entrega, aviso ainda em fila, retorno inexistente, gateway opaco, descarte silencioso ou falta de observação.

As RFCs 3461, 3463 e 3464 criam outro tipo de recibo: pedido de DSN, status ampliado e relatório por destinatário. As ações failed, delayed, delivered, relayed e expanded não são equivalentes. Solicitar um DSN não garante recebê-lo. relayed não afirma caixa final; delivered não prova leitura. O próprio relatório precisa ser transportado.

O 250 final identifica quem assumiu a obrigação. Um DSN posterior descreve o que outro estágio declarou. A junção entre os dois preserva a cronologia; um único selo “entregue” apaga ambos.

O aceite que o cliente não viu

Um receptor persiste a mensagem e envia 250, mas a conexão cai antes de o cliente observar o reply. O receptor mantém uma cópia legítima. A origem não pode provar o aceite, conserva sua cópia e tenta novamente. Pode haver duplicação.

A RFC concede tempo longo à terminação de DATA porque há processamento, mas também pede resposta rápida para diminuir essa ambiguidade. Nenhum timeout garante que ambas as partes observem o mesmo último evento.

“Resposta final não observada” não é “rejeição remota”. É uma condição ambígua com risco de cópia dupla. A fila deve ligar handle original, desconexão, retry e identificadores posteriores. Métricas de 250 contam handoffs reconhecidos; sem separar retries e duplicatas, não contam experiências de destinatários.

O formato por destinatário muda no LMTP

SMTP responde a cada RCPT antes do corpo, mas o resultado final de DATA cobre a transação aceita como conjunto. Ele não entrega uma conclusão pós-DATA distinta para cada endereço.

LMTP, usado em transferências locais, retorna depois do ponto final uma resposta para cada RCPT previamente aceito, na mesma ordem. Uma resposta positiva transfere responsabilidade pelo destinatário correspondente.

O parser precisa guardar protocolo, ordem e cardinalidade. Transformar um único 250 SMTP em vários sucessos finais inventa detalhe. Colapsar respostas LMTP em um estado único pode atribuir falha ao endereço errado.

Um ledger mínimo de responsabilidade

O primeiro bloco identifica conexão e transação; separa contexto TLS de aceite de conteúdo; registra MAIL FROM, todos os RCPTs, 354, conclusão de DATA, horário e queue ID. O segundo bloco pertence ao novo responsável: durabilidade, tentativas, próximo hop, resposta e desconexões ambíguas.

A entrega local soma o resultado do agente ou LMTP. Um DSN soma Action e Status por destinatário e prova de que o relatório saiu da própria fila. Spam, gateways fechados e leitura permanecem desconhecidos sem fonte independente.

É uma especificação inicial mínima, não um software comum. Cada operador escolhe engine de fila, retry, privacidade e retenção. O contrato compartilhado é não separar reply do comando, não renomear custódia como entrega e não emprestar ao próximo hop a certeza do anterior.

A conclusão segura diz: este servidor aceitou este envelope e corpo no encerramento de DATA; a responsabilidade mudou; estes estados posteriores são observados; estes resultados de destinatário e usuário continuam sem prova.

Fontes