Home Comunidade Eventos YouTube Networks Desafios // produtos Academy News CTI | CVE Contato

01 - Do Remetente ao Servidor

video explicativo
Video explicativoEspaco reservado para o video desta anotação — adicione video: https://youtu.be/... no frontmatter da nota.

O primeiro salto na jornada de um e-mail é a Submissão, o processo técnico onde o MUA (Mail User Agent) transfere a mensagem para o seu servidor de correio de saída de confiança. Ao contrário da comunicação entre servidores (Relay), a submissão é um processo restrito e altamente autenticado, projetado para garantir que apenas usuários autorizados utilizem a infraestrutura de envio da organização, prevenindo o uso do servidor como uma plataforma de SPAM.


1. O Protocolo de Submissão (RFC 4409)

Enquanto a transferência entre servidores ocorre na porta 25, a submissão de mensagens do usuário final foi separada tecnicamente pela RFC 4409, que define o papel do MSA (Mail Submission Agent). Essa separação foi fundamental para permitir que provedores residenciais bloqueassem a porta 25 de saída sem interromper o envio legítimo de e-mails por seus clientes.

A Escolha da Porta: 587 vs 25 vs 465

Porta Função Autenticação Criptografia Padrão
25 Relay MTA-MTA (entre servidores) Opcional STARTTLS oportunístico
587 Submissão de usuário (Submission) Obrigatória STARTTLS
465 Submissão com TLS Implícito Obrigatória TLS direto
  • Porta 587 (Submission): É o padrão ouro moderno. Ela é especificamente destinada a conexões de usuários finais. Força o uso de autenticação e permite negociar criptografia via STARTTLS.
  • Porta 25 (Legado/MTA): Frequentemente bloqueada por provedores residenciais (ISPs) para evitar que dispositivos domésticos infectados enviem SPAM diretamente.
  • Porta 465 (Implicit TLS): Embora tenha sido depreciada, ainda é amplamente usada em dispositivos que exigem que o túnel TLS seja estabelecido antes de qualquer comando SMTP ser enviado. A RFC 8314 (2018) reintroduziu formalmente seu uso como padrão moderno de submissão segura.

2. Autenticação e Autorização (SMTP-AUTH - RFC 4954)

A submissão exige que o emissor prove sua identidade. Sem isso, o servidor de correio recusaria o envio (erro 550 Relaying Denied).

Mecanismos de Autenticação Comuns

  1. AUTH PLAIN / LOGIN: O MUA envia o nome do usuário e a senha codificados em Base64. Como o Base64 não é criptografia, estas comunicações exigem obrigatoriamente um túnel TLS prévio.
  2. CRAM-MD5 / DIGEST-MD5: Métodos mais antigos de desafio e resposta que tentavam proteger a senha, mas que hoje são evitados em favor do TLS.
  3. OAuth2: O novo padrão para serviços de nuvem (Gmail, Microsoft 365), onde o MUA utiliza um Token de Acesso em vez da senha real do usuário, aumentando drasticamente a segurança.

Fluxo de SMTP-AUTH PLAIN

C: EHLO cliente.dominio.com
S: 250-AUTH PLAIN LOGIN
C: AUTH PLAIN AGpvaG5AZXhhbXBsby5jb20Ac2VuaGExMjM=
S: 235 2.7.0 Authentication successful

A string Base64 contém: \0john@example.com\0senha123. O caractere nulo (\0) separa o authorization identity da authentication identity — um mecanismo legado do SASL.


3. Segurança e Criptografia em Trânsito (TLS)

O primeiro salto é o momento em que a mensagem do usuário (que pode conter dados sensíveis) atravessa a Internet pública para chegar ao servidor da empresa.

  • STARTTLS: O MUA estabelece uma conexão de texto plano e envia o comando STARTTLS. Se o servidor aceitar, ocorre o handshake TLS e toda a transação SMTP subsequente (incluindo as credenciais de login) torna-se cifrada.
  • Validação de Certificado: MUAs modernos devem validar o certificado digital do MSA contra autoridades certificadoras (CAs) confiáveis para evitar ataques de interceptação (Man-in-the-Middle).

Cenário de Ataque MitM sem TLS

Atacante intercepta:
  AUTH PLAIN <base64>
  MAIL FROM: ceo@empresa.com
  RCPT TO: atacante@exfil.com
  DATA
  ...transferência bancária urgente...

Sem TLS, o atacante captura credenciais e conteúdos. Com STARTTLS obrigatório e verificação de certificado, o ataque é neutralizado.


4. O Papel do Servidor na "Limpeza" (Normalization)

O MSA não apenas recebe a mensagem; ele atua como um editor técnico para garantir que o e-mail esteja em conformidade total com as RFCs antes de ser lançado na rede global.

  • Injeção de Cabeçalhos Faltantes: Se o MUA não incluiu um campo Date: ou um Message-ID:, o MSA deve gerá-los e injetá-los.
  • Fixing Return-Path: O servidor garante que o remetente do envelope (MAIL FROM) corresponda à identidade autenticada do usuário, impedindo spoofing interno.
  • Filtragem de Saída (Outbound Scanning): O servidor processa a mensagem em busca de malwares ou padrões de vazamento de dados confidenciais (DLP) antes de aceitar o envio.
  • Validação de Tamanho e Codificação: Limita o tamanho máximo da mensagem e valida a codificação MIME para evitar rejeição por servidores downstream.

5. Limitação de Taxa e Detecção de Abuso (Cyber Perspective)

Para um profissional de Cyber Security, monitorar o estágio de submissão é a forma mais eficaz de detectar um "Compromisso de Conta" (Account Takeover).

Rate Limiting por Usuário

Se um usuário legítimo costuma enviar 20 e-mails por dia e, de repente, tenta enviar 2.000 mensagens em 10 minutos, o MSA deve disparar um bloqueio automático.
- Proteção de Reputação: Este limite impede que um atacante que roubou uma senha consiga manchar a reputação do IP do servidor da empresa em listas negras (RBLs) mundiais.

Identificação de Origem no Primeiro Salto

O MSA registra nos cabeçalhos da mensagem (Received headers) o IP de origem do usuário final. Em investigações forenses, este carimbo é a prova definitiva de onde partiu o envio original, permitindo identificar se a submissão ocorreu de um IP conhecido do funcionário ou de uma rede russa/chinesa suspeita.

Indicadores de Account Takeover (ATO)

Indicador Ação Recomendada
Pico de envio repentino Bloquear conta + alertar SOC
Login de IP geograficamente impossível Forçar reautenticação com MFA
Conteúdo com anexos suspeitos Quarantine + scan avançado de malware
Muitas mensagens para domínios novos Marcar como spam e notificar o usuário

6. Diagnóstico e Teste do Primeiro Salto

Para auditar se um servidor está configurado corretamente para submissão:

# Teste com Swaks (focado em submissão na porta 587)
swaks --to destinatario@externo.com --from usuario@sua-empresa.com \
      --server smtp.sua-empresa.com:587 --auth PLAIN \
      --auth-user usuario@sua-empresa.com --tls

# Teste de handshake TLS completo com OpenSSL
openssl s_client -starttls smtp -connect smtp.empresa.com:587 -crlf

# Verificando mecanismos AUTH anunciados
echo -e "EHLO test\nQUIT" | nc -w5 smtp.empresa.com 587

# Capturando a negociacao TLS para analise de cipher suites
sudo tcpdump -i eth0 -w submissao.pcap port 587

Se o comando Swaks falhar com erros de TLS ou autenticação, significa que a infraestrutura de submissão da empresa está em risco ou mal configurada para clientes modernos.


7. Conclusão da Submissão

A submissão termina quando o MUA envia o comando QUIT e o MSA confirma que a mensagem foi enfileirada (250 2.0.0 Ok: queued as [QID]). Neste ponto, o usuário pode fechar o seu cliente de e-mail, e a responsabilidade da mensagem passa a ser inteiramente do lado do servidor (MTA).

Compreender o ciclo de submissão — desde a porta 587 obrigatoriamente autenticada até a normalização de cabeçalhos pelo MSA — é o que separa uma infraestrutura de e-mail profissional de um servidor "aberto" que vira ferramenta de spammers em questão de horas. Para administradores modernos, a regra operacional é simples: sem TLS, sem AUTH, sem limite de taxa — não há submissão.