Comando DATA (Conteúdo da Mensagem)

O comando DATA é o ponto de virada técnica em uma transação SMTP. Diferente dos comandos anteriores (EHLO, MAIL, RCPT), que são atômicos e curtos, o comando DATA sinaliza ao servidor que o cliente está pronto para iniciar a transferência em massa do conteúdo real do e-mail. Este estágio é onde ocorrem os maiores desafios de integridade de dados e onde as defesas de filtragem de conteúdo (Anti-Spam e Anti-Malware) realizam o seu processamento intensivo.

1. A Transição de Estado e o Código 354 (RFC 5321)

Quando o cliente envia DATA, o servidor SMTP entra no modo de recepção de fluxo.

• Resposta Intermediária: O servidor deve responder com o código 354 Start mail input; end with <CRLF>.<CRLF>.
• Lógica Técnica: A partir deste código, o servidor deixa de interpretar cada linha como um comando individual e passa a ler tudo como um "blob" de dados bruto até encontrar a sequência de término.
• Pré-condição: O comando DATA só pode ser enviado após MAIL FROM e pelo menos um RCPT TO aceitos.

Sequência de Estados do Servidor

[ESTABLISHED]
    ↓
[EHLO recebido]  → negociou extensões
    ↓
[MAIL FROM aceito]  → iniciou transação
    ↓
[RCPT TO aceito]    → definido destinatário
    ↓
[DATA recebido]     → servidor responde 354
    ↓
[Modo de leitura de dados]
    ↓
[CRLF.CRLF recebido] → servidor processa mensagem
    ↓
[250 OK]            → mensagem aceita, fila atribuída

2. O Mecanismo de Término e o "Dot-Stuffing"

Como o SMTP sinaliza o fim de um e-mail através de um ponto final sozinho em uma linha (\r\n.\r\n), surge o desafio técnico da transparência: E se o corpo real do e-mail contiver uma linha com apenas um ponto?

Transparência do Protocolo (RFC 5321, Capítulo 4.5.2)

Para evitar que uma mensagem seja cortada prematuramente, o cliente aplica o "Dot-Stuffing":

1. No Cliente: Antes de enviar cada linha, o cliente verifica se o primeiro caractere é um ponto. Se for, ele insere um segundo ponto (ex: .Texto vira ..Texto).
2. No Servidor: Ao receber uma linha que começa com um ponto, o servidor verifica o próximo caractere. Se for outro ponto, ele o remove, restaurando a mensagem original. Se for apenas um ponto seguido de um fim de linha, o servidor sabe que a mensagem terminou.

Exemplo Prático

Conteúdo original do e-mail:

Linha 1
.Linha que comeca com ponto
Última linha

O que trafega na rede (após dot-stuffing):

Linha 1
..Linha que comeca com ponto
Última linha
.

O servidor receptor remove o ponto extra, restaurando o conteúdo original.

3. Anatomia da Carga Útil (Headers vs Body)

Dentro do fluxo de dados do comando DATA, a mensagem é dividida em dois blocos técnicos principais, separados obrigatoriamente por uma linha em branco (CRLF CRLF).

Bloco de Cabeçalhos (RFC 5322)

Contém metadados como Subject, From, To, Date, MIME-Version. Estes campos são processados pelo MUA do destinatário para exibição.

Date: Sun, 06 Apr 2026 12:00:00 -0300
From: Remetente <rem@emissor.com>
To: Destinatario <dest@receptor.com>
Subject: Teste de Email
Message-ID: <abc123@emissor.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Bloco do Corpo (Body)

Contém o texto da mensagem e os blocos MIME codificados em Base64 ou Quoted-Printable.

Olá, este é o corpo do e-mail.

Em anexo segue o documento solicitado.

[base64 do arquivo anexo]

4. Estrutura MIME para Multipart e Anexos

Quando o e-mail contém anexos ou múltiplas representações (HTML + texto), o corpo usa o padrão MIME (RFC 2045-2049), com boundary que separa as partes:

Content-Type: multipart/mixed; boundary="frontier"

--frontier
Content-Type: text/plain; charset=utf-8

Olá! Veja o anexo.

--frontier
Content-Type: application/pdf; name="doc.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="doc.pdf"

JVBERi0xLjQKJeLjz9MKMSAwIG9iaiA8PC9UeXBlL0NhdGFsb2cvUGFn
... [mais bytes Base64] ...
==

--frontier--

5. Perspectiva de Cyber Security: Ataques no Estágio DATA

Para um profissional de Cyber Security, o comando DATA é o campo de batalha mais complexo, pois os dados aqui não são estruturados como os comandos.

SMTP Smuggling (Contrabando de SMTP)

Esta vulnerabilidade moderna explora a forma como diferentes MTAs interpretam o fim da mensagem.

• O Ataque: Um atacante usa sequências não padronizadas (ex: <LF>.<LF> em vez de <CRLF>.<CRLF>). Se um gateway de segurança achar que a mensagem continua, mas o servidor de destino achar que ela terminou, o atacante pode "contrabandear" uma segunda mensagem falsa que não passará pelos filtros do gateway.
• CVE-2023-51764: Vulnerabilidade real descoberta em dezembro de 2023 afetando Postfix, Sendmail e outros.
• Mitigação: Forçar interpretação estrita RFC 5321 do CRLF.CRLF em todos os MTAs intermediários.

Header Injection (Injeção de Cabeçalhos)

Ocorre quando o cliente insere deliberadamente sequências de fim de linha e novos cabeçalhos no corpo da mensagem. Isso pode enganar o servidor receptor, fazendo-o acreditar que campos como o Reply-To: ou Bcc: foram gerados pelo sistema legítimo, facilitando ataques de Spear Phishing.

Exemplo de injeção em formulário web vulnerável:

From: user@exemplo.com\r\nBcc: atacante@evil.com\r\n

Data Loss Prevention (DLP) no Voo

MTAs modernos realizam o "Deep Content Inspection" durante o recebimento do DATA. O servidor lê o fluxo de bytes, reconstrói anexos em tempo real e os submete a scanners de DLP e antivírus. Se algo proibido for detectado, o servidor pode abortar a conexão imediatamente e retornar um erro 554 Message Rejected.

6. Códigos de Erro e Timeouts Técnicos

O comando DATA possui tempos de espera (timeouts) muito longos definidos nas RFCs para suportar conexões lentas:

Códigos de Erro Comuns no DATA

7. Laboratório Prático: Auditoria de Término de Dados

# Teste de transao DATA com dot-stuffing
telnet mx.alvo.com 25
HELO emissor.com
MAIL FROM:<remetente@emissor.com>
RCPT TO:<destino@alvo.com>
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Teste de Dot-Stuffing
Esta e uma linha de teste.
.. (Linha com dois pontos para testar o stuffing)
.
# Resposta 250 OK indica sucesso

O tshark (Wireshark em linha de comando) permite ver o fluxo real de bytes e confirmar se a aplicação cliente está fazendo o stuffing corretamente: sudo tshark -i eth0 -Y "smtp" -T fields -e ip.src -e ip.dst -e smtp.req.command -e smtp.data.fragment.

8. PIPELINING e DATA

A extensão PIPELINING (RFC 2920) permite ao cliente enviar MAIL FROM, RCPT TO e DATA em sequência sem esperar respostas individuais. Após o DATA, o cliente deve esperar o 354 antes de iniciar o envio do corpo. Otimiza latência mas mantém a sincronia do protocolo.

9. Conclusão da Transferência de Conteúdo

O sucesso do comando DATA é o momento em que o servidor recupera o controle da sessão SMTP. Ao responder 250 OK, o servidor declara que a mensagem está agora em posse firme da sua infraestrutura e que os dados foram recebidos de forma íntegra. Este é o estágio de maior consumo de recursos de rede em um servidor de e-mail e sua correta implementação é o pilar da confiabilidade do sistema de correio global.