Por que um cliente SMTP envia um comando RSET (Reset)?

Question

Estou tentando entender exatamente como um e-mail é processado pelo Postfix - e alguns dos detalhes mais sutis das transações de e-mail SMTP. Meu objetivo de curto prazo é depurar um cliente SMTP proprietário (binário de código fechado), mas primeiro pensei em examinar o que acontece em uma transação SMTP bem-sucedida.

Eu planejo bloquear o SMTP de saída (porta 25) no firewall da LAN, então configurei o Postfix como um servidor de email interno para aceitar emails de software cliente local (primitivo) que só pode enviar email via SMTP não autenticado (pela porta 25). ).

Ativei a depuração do processo smtpd do Postfix, anexando o sinalizador -v verbose em master.cf , conforme descrito em Solução de problemas com os logs do Postfix . Em seguida, enviei um e-mail da minha própria estação de trabalho usando o Cygwin Mutt com sSMTP (uma implementação mínima de sendmail ).

Os logs do Postfix mostram que depois que a linha RCPT TO: foi processada com sucesso e o endereço do destinatário foi aceitável, smtpd do Postfix atribuiu à transação uma ID da fila e respondeu ao cliente SMTP (sSMTP) com 250 OK . / p>

No entanto, em vez de emitir um comando DATA , o cliente SMTP emitiu um RSET para redefinir / anular a transação de e-mail atual e o Postfix respondeu com um 250 OK .

Eu fiz algumas pesquisas sobre o que este comando faz e, sem surpresa, o Simple Mail Transfer Protocol, RFC 2821 forneceu a informação mais abrangente:

This command specifies that the current mail transaction will be aborted. Any stored sender, recipients, and mail data MUST be discarded, and all buffers and state tables cleared. The receiver MUST send a "250 OK" reply to a RSET command with no arguments. A reset command may be issued by the client at any time. It is effectively equivalent to a NOOP (i.e., if has no effect) if issued immediately after EHLO, before EHLO is issued in the session, after an end-of-data indicator has been sent and acknowledged, or immediately before a QUIT. An SMTP server MUST NOT close the connection as the result of receiving a RSET; that action is reserved for QUIT (see section 4.1.1.10).

Since EHLO implies some additional processing and response by the server, RSET will normally be more efficient than reissuing that command, even though the formal semantics are the same.

There are circumstances, contrary to the intent of this specification, in which an SMTP server may receive an indication that the underlying TCP connection has been closed or reset. To preserve the robustness of the mail system, SMTP servers SHOULD be prepared for this condition and SHOULD treat it as if a QUIT had been received before the connection disappeared.

Todos os itens acima ocorreram no espaço de um segundo, então não deve haver problemas com o tempo limite.

No próximo segundo, o cliente enviou outro RSET , mas o cliente esperou 10s inteiros antes de reiniciar com MAIL FROM: , RCPT TO: , mas desta vez segue e emite o comando DATA e a transação é concluída (todos dentro do mesmo segundo de acordo com os logs).

Essencialmente, estou me perguntando por que um cliente SMTP interromperia sua própria transação emitindo comandos RSET em vez de um comando DATA .

Notas:

1. Eu posso editar a pergunta para incluir a extração do arquivo de registro de e-mail, mas com a depuração -v , eles são muito detalhados e Eu não quero sobrecarregar as pessoas com uma mangueira de dados irrelevantes.

2. Pesquisei o código-fonte do sSMTP, mas não encontrei menção a RSET .

Answer 1

TLDR

Eu estava me perguntando por que um cliente SMTP interromperia sua própria transação emitindo comandos RSET em vez do comando DATA. A resposta curta é que não seria; isso é um sintoma de conexões SMTP sendo interceptadas pelo software antivírus.

Registro do cliente

Eu habilitei a opção Debug na configuração do sSMTP, mas levei algum tempo para descobrir como instalar e configurar o syslog no Cygwin para que as mensagens dos processos do Cygwin sejam registradas em /var/log/messages em vez do visualizador de eventos do Windows.

No entanto, ele registrou apenas os primeiros comandos MAIL FROM: e RCPT TO: ; não houve indicação de que esses comandos foram enviados mais de uma vez - ou que sSMTP nunca enviou um comando RSET .

Como mencionado em minha pergunta, verifiquei o código-fonte sSMTP, mas não há código para enviar um comando RSET .

Symantec Interception of SMTP traffic

O usuário masegaloeh sugeriu que o software antivírus pode estar modificando os pacotes SMTP - e ele estava certo: temporariamente desativou o Symantec Endpoint Protection no meu computador e as transações SMTP prosseguiram normalmente.

Depois de reativar o Symantec Endpoint Protection, eu monitorei as conexões TCP usando o utilitário TCPView em Windows Sysinternals e pude ver que o processo ccSvcHst.exe da Symantec estava fazendo proxy de todo o tráfego TCP cuja porta de destino é 25.

Fiz telnet para a porta 25 no servidor de e-mail (o netcat não funcionava corretamente, possivelmente devido à interceptação da Symantec) para enviar um e-mail de teste usando a inserção manual de comandos SMTP. Ao mesmo tempo, eu tinha outra janela de terminal aberta com uma conexão SSH para o host de correio enquanto estava executando sudo tail -F /var/log/maillog para monitorar simultaneamente o que o servidor SMTP estava vendo.

A interceptação realizada pelo proxy da Symantec é sutil. Do ponto de vista do cliente de e-mail, há muito pouca indicação de que ele não está falando diretamente com o servidor SMTP. A maioria dos comandos é passada para o servidor de e-mail conforme eles foram enviados e as respostas são o que você espera. Não foi até que eu digitei o comando DATA , que o proxy da Symantec começou a mudar as coisas: ele respondeu com:

354 Please start mail input.

Isso parece normal, mas, na realidade, a resposta do meu servidor Postfix deveria ter sido

354 End data with <CR><LF>.<CR><LF>

Além disso, ele não passou o comando DATA para o Postfix depois que eu terminei o corpo da mensagem e o segui com QUIT .

Nota: enquanto eu digitava o conteúdo da mensagem de teste, o proxy da Symantec manteve sua conexão com o servidor Postfix ativa, emitindo comandos NOOP .

Lidando com clientes SMTP com bugs

Mencionei na minha pergunta que meu objetivo final era solucionar um cliente de email proprietário (binário, de código fechado) usado por minha organização. Descobri que esse cliente é realmente problemático: ele envia um comando HELO inválido (sem qualquer nome de host) e simplesmente desiste e QUITs após ser educadamente informado pelo servidor SMTP que sua sintaxe está errada - mesmo que eu tenha configurado o Postfix como não requer um HELO (válido ou não).

Eu resolvi esse problema instalando um novo servidor com o CentOS 7, que vem com uma versão Postfix recente o suficiente para que eu possa desativar O postfix HELO verifica completamente (similar a como o MS Exchange simplesmente ignora comandos HELO inválidos).

Uso geral do RSET

Eu também estava me perguntando sobre o uso geral de RSET em transações SMTP e encontrei o seguinte no RFC 821 para SMTP:

This command specifies that the current mail transaction is to be aborted. Any stored sender, recipients, and mail data must be discarded, and all buffers and state tables cleared. The receiver must send an OK reply.

RSET seria usado se o endereço de e-mail do destinatário fosse de um usuário inexistente. A seguinte transação SMTP é um exemplo de um Cenário de Transação SMTP Abortado .

R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready
S: HELO ISI-VAXA.ARPA
R: 250 MIT-Multics.ARPA

S: MAIL FROM:<[email protected]>
R: 250 OK

S: RCPT TO:<[email protected]>
R: 250 OK

S: RCPT TO:<[email protected]>
R: 550 No such user here

S: RSET
R: 250 OK

S: QUIT
R: 221 MIT-Multics.ARPA Service closing transmission channel

Reutilização de conexões SMTP

Os clientes SMTP podem usar a mesma conexão SMTP para enviar várias mensagens para o mesmo destino. Esse recurso é denominado cache de conexão SMTP pelo Postfix. Ao usar esse recurso de desempenho, o Postfix envia um comando RSET antes de cada MAIL FROM para verificar se a conexão SMTP ainda pode ser usada (consulte Postfix Cache de Conexão ).