01 - Do Remetente ao Servidor
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
- 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.
- 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.
- 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 umMessage-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.