Summary

  • A RFC 1845 propôs em 1995 uma extensão Experimental: CHECKPOINT anunciava suporte, TRANSID distinguia uma cópia em trânsito e o servidor guardava seu estado em armazenamento não volátil.
  • No exemplo, 355 6135 registra 6.135 octetos dos dados da mensagem armazenados; comandos de envelope e bytes extras do dot-stuffing não entram na conta.

Uma mensagem grande em uma conexão instável cobra pedágio repetido. O SMTP original conseguia tentar de novo, mas não voltar ao meio de uma transação interrompida depois da queda do TCP. Em setembro de 1995, D. Crocker, N. Freed e A. Cargille escreveram uma proposta Experimental para que o servidor contasse o que reteve e o cliente mandasse o restante. O número 6.135 pertence à conversa ilustrativa da RFC, não a um registro de falha em produção.

O envio precisava primeiro ganhar uma identidade que coubesse à operação. O cliente perguntava por EHLO; se a resposta trazia CHECKPOINT, podia acrescentar TRANSID a MAIL FROM. O valor diferenciava maiúsculas e minúsculas e identificava aquela transação de SMTP. O conhecido Message-ID do cabeçalho não resolvia o trabalho: uma mensagem podia gerar cópias enviadas por caminhos diferentes, cada uma com seu próprio progresso. O servidor tratava TRANSID como uma sequência opaca. O que importava era reconhecer a mesma tentativa depois da desconexão.

Reconhecer a tentativa sem guardar seus dados seria um truque de palco. O servidor devia reter o ID e o estado mais recente em armazenamento não volátil. A RFC recomendava preservar uma transação interrompida por pelo menos 48 horas, deixando a política de prazo com o administrador. O cliente aguardava a liberação da conexão antiga e verificava novamente o DNS. Tentava primeiro o endereço original se ainda fosse elegível; depois podia buscar os demais endereços aceitáveis. Se outro servidor não tivesse o ponto de retomada, o cliente retransmitia tudo. O retorno do servidor antigo não podia virar condição para entregar a mensagem.

Ao reconectar, o cliente repetia exatamente o MAIL FROM e o TRANSID. O servidor respondia com 355 e o deslocamento do próximo octeto esperado. No exemplo, os 6.135 octetos são dados da mensagem já armazenados. MAIL FROM e RCPT TO ficam fora da conta. Os bytes que o protocolo acrescenta para proteger linhas iniciadas por ponto também ficam de fora. Se o envio usa DATA, a posição deve cair no começo de uma linha. Abrir um arquivo local no byte 6.135 não basta: a referência é o fluxo canônico de dados SMTP.

A sequência final cabe em poucas linhas: DATA, resto dos dados, 250 OK. A RFC admite até que o cliente gere novamente o fluxo inteiro e simplesmente deixe de emitir a parte anterior ao deslocamento. É um jeito de gastar processamento local para poupar a conexão que vinha falhando.

O recibo do servidor prova apenas a parte preservada daquela transação. Não informa leitura por uma pessoa nem identifica todas as cópias do mesmo e-mail. Essa limitação é sua qualidade. Um número pequeno, definido com rigor, permitia decidir o próximo byte sem fingir que a entrega inteira já estava resolvida.