Resumo

  • RSET tornou a mensagem incompleta descartável dentro de uma sessão SMTP mais longa: apaga remetente, destinatários e dados da transação, mas não encerra a conexão.
  • O 250 OK confirma o reset, não uma entrega. Ele não desfaz uma mensagem já concluída nem elimina TLS, autenticação ou toda a memória operacional da sessão.

Um destinatário aceito que já não deveria receber

O cliente envia MAIL FROM e dois comandos RCPT TO. O servidor aceita o primeiro endereço e recusa o segundo. A aplicação, porém, exige entrega conjunta: ou os dois entram no envelope, ou a mensagem não segue.

A recusa posterior não cancela a aceitação anterior. O servidor ainda guarda o caminho de retorno e um destino válido. Se o cliente enviar DATA, continuará uma transação que já abandonou. Se iniciar outro MAIL, encontrará o envelope anterior aberto. Encerrar TCP limparia o estado, mas trataria uma mudança local de intenção como falha de transporte e desperdiçaria uma sessão saudável.

RSET diz algo mais preciso: descarte esta transação. Quando o servidor responde positivamente, as duas pontas passam a compartilhar a prova de que o próximo envelope não herdará o anterior.

A limpeza já estava no SMTP original

RFC 821 definiu o reset em 1982. O servidor deveria descartar remetente, destinatários e dados armazenados, limpar buffers e tabelas de estado e devolver uma resposta de sucesso. O mesmo documento estabeleceu que uma sessão podia conter zero ou mais transações de correio.

Uma regra dependia da outra. Reutilizar a conexão para várias mensagens só era seguro se uma delas pudesse morrer sem contaminar a seguinte. Reconectar a cada erro eliminaria o benefício da sessão; manter o envelope quebrado eliminaria o isolamento.

RFC 821 também orientava as partes a não fechar o canal apenas porque um comando anterior recebeu erro. Se a conexão caísse antes da hora, a transação pendente seria cancelada, mas as já concluídas permaneceriam concluídas. Canal, tentativa atual e resultado passado eram estados separados.

O reset precisa ser reconhecido pelo outro lado

Apagar a fila local não revela o que existe no servidor. Um destinatário aceito pode continuar em memória. A reutilização só se torna segura depois que a resposta do par confirma a transição.

RFC 5321 exige 250 OK para RSET sem argumentos e permite o comando a qualquer momento. Sem transação aberta, ele funciona quase como um no-op. Com uma transação, remove remetente, destinatários e dados. O servidor não pode fechar a conexão por causa dele; QUIT é o comando que encerra o canal.

O objeto do 250 precisa ser preservado. Após RSET, o código aprova a limpeza, não a mensagem anterior. Também não promete destruição física de logs ou trilhas de abuso. A garantia é protocolar: o estado visível daquele envelope não participa da próxima transação.

A sessão lembra mais do que o envelope

“Limpar tabelas de estado” não significa apagar toda a sessão. A conexão TCP continua. A saudação não recomeça. As extensões aprendidas por EHLO não precisam ser redescobertas por causa de uma mensagem abortada. TLS permanece ativo e uma identidade autenticada não volta a ser anônima. O que deve sumir são endereços e conteúdo próprios da transação.

Um novo EHLO aceito também limpa a transação aberta como se houvesse um RSET, segundo RFC 5321. Mas ele executa trabalho adicional de saudação e capacidades; por isso o reset simples costuma ser mais eficiente. A equivalência se limita ao efeito sobre o envelope atual.

STARTTLS marca uma fronteira maior. RFC 3207 manda cliente e servidor descartar o conhecimento obtido antes do handshake e recomenda um novo EHLO. O contexto de segurança mudou, então a sessão reconstrói suas capacidades. Abandonar apenas uma mensagem não exige esse alcance.

O presente pode ser abortado; o passado, não

A transação começa com MAIL, inclui um ou mais RCPT e termina com a transferência do conteúdo. RSET age enquanto essa unidade ainda está aberta. Depois da aceitação final dos dados, há uma transação concluída. Um reset posterior prepara a próxima, mas não retira a responsabilidade já assumida.

Uma sessão persistente não é uma única transação de banco de dados abrangendo todas as mensagens. Cada mensagem concluída conserva seu próprio resultado. A continuidade da conexão não cria uma capacidade de rollback histórico.

Isso também explica por que contar códigos 250 sem o comando correspondente produz métricas falsas. O sucesso de um destinatário, do conteúdo e do reset são afirmações distintas.

PIPELINING aproximou eventos distintos

RFC 2920 permitiu agrupar comandos sem esperar cada resposta. RSET, comandos de remetente e RCPT TO podem aparecer no grupo; o fim do conteúdo de uma mensagem pode até compartilhar uma transmissão TCP com o reset e o novo remetente da próxima.

A proximidade não funde os resultados. O cliente deve correlacionar todas as respostas em ordem. A resposta do conteúdo anterior, a confirmação do reset e a aceitação do novo remetente pertencem a estados diferentes.

Quanto maior a otimização, mais importante fica o livro-caixa. Esvaziar o buffer local não comprova que o servidor atravessou a fronteira; só a resposta correta comprova.

Quando o conteúdo em blocos fica indeterminado

RFC 3030 permite transportar o corpo em blocos BDAT. Um bloco depois de BDAT LAST, a mistura de DATA e BDAT ou uma falha que deixe a transação indeterminada exigem RSET antes de continuar.

O reset descarta os segmentos ligados à tentativa. Ele não nega a existência da conexão, de TLS ou de registros operacionais; impede que octetos parciais formem a mensagem seguinte.

RFC 4954 protege outra camada ao proibir AUTH durante uma transação aberta e exigir 503. A identidade da sessão não pode ser trocada entre remetente, destinatários e conteúdo. Primeiro o envelope precisa terminar ou ser abandonado.

Recuperação com alcance definido

Depois de uma falha, ignorar o estado é perigoso e destruir a conexão inteira pode ser desnecessário. RSET ocupa o meio útil: nomeia a unidade descartada, mantém o canal e pede confirmação.

O aprendizado histórico não foi tornar SMTP sem estado. Foi dividir o estado. Uma mensagem incompleta pode desaparecer sem apagar a conversa; uma conversa pode continuar sem alterar o resultado das mensagens concluídas.

Fontes