02 - Entre Servidores

A Transferência entre Servidores, tecnicamente conhecida como Relay SMTP, é o estágio de "backbone" onde o e-mail viaja pela Internet pública do servidor de origem (MTA emissor) para o servidor de destino (MTA receptor). Este processo é a essência da comunicação inter-organizacional e exige uma coordenação precisa entre serviços de diretório (DNS) e protocolos de transporte (SMTP na Porta 25). Diferente da submissão do usuário, o relay opera sob um modelo de confiança verificada por reputação e políticas criptográficas.

1. A Inteligência de Localização: DNS MX e Priorização

O servidor de origem não conhece antecipadamente o endereço IP do servidor de destino. O fluxo de transferência entre servidores depende totalmente da resolução de nomes.

Resolução de Registros MX (Mail Exchanger)

1. Busca por Domínio: O MTA emissor extrai o domínio do destinatário (ex: @google.com) e solicita ao servidor DNS os registros MX.
2. Lista de Prioridade: O DNS retorna uma lista de hosts com valores de preferência numérica (ex: 10 aspmx.l.google.com, 20 alt1.aspmx...).
3. Algoritmo de Seleção: O MTA tenta o servidor de menor valor de prioridade primeiro. Se este falhar ou estiver ocupado (Timeout), o MTA automaticamente desvia o fluxo para o próximo da lista. Isso garante a alta disponibilidade do sistema de correio.

O Mecanismo de Fallback (Registro A)

Caso o domínio de destino não possua registros MX configurados (um erro comum em novas startups), muitos MTAs modernos tentam um "fallback" para o registro A ou AAAA (IP) do próprio domínio, como última tentativa de entrega direta.

Exemplo de Resposta MX

$ dig MX gmail.com +short
10 aspmx.l.google.com.
20 alt1.aspmx.l.google.com.
30 alt2.aspmx.l.google.com.
40 alt3.aspmx.l.google.com.
50 alt4.aspmx.l.google.com.

O menor número (10) é o preferido. Google utiliza 5 níveis de MX para garantir entrega mesmo durante quedas massivas.

2. A Conexão Síncrona na Porta 25 (RFC 5321)

A transferência entre servidores é o único cenário onde o uso da Porta 25 de saída continua sendo o padrão industrial inquestionável.

• Identificação com EHLO: O servidor emissor se apresenta (ex: EHLO mail.emissor.com). Servidores receptores modernos comparam este anúncio com o Reverse DNS (PTR) do IP de origem para validar a legitimidade da infraestrutura.
• Negociação de STARTTLS: Embora a conexão comece em texto plano, 95% do tráfego de e-mail global hoje utiliza STARTTLS para criptografar o trajeto entre os servidores.
• Tamanho Máximo: A RFC 5321 recomenda suporte a mensagens de no mínimo 64 KB, mas servidores modernos aceitam de 10 MB a 50 MB.

Diálogo SMTP Típico Entre Servidores

C: EHLO mail.emissor.com
S: 250-mail.google.com at your service
S: 250-SIZE 35882577
S: 250-STARTTLS
S: 250 8BITMIME
C: STARTTLS
S: 220 Ready to start TLS
[handshake TLS]
C: MAIL FROM:<remetente@emissor.com>
S: 250 OK
C: RCPT TO:<destinatario@gmail.com>
S: 250 OK
C: DATA
S: 354 Start mail input
C: Subject: Teste\n\nCorpo do email\n.
S: 250 OK queued as xyz123
C: QUIT
S: 221 Bye

3. Segurança no Trânsito: DANE e TLS Forçado

Para um analista de Cyber Security, a fase "Entre Servidores" é o ponto onde ataques de interceptação (Man-in-the-Middle) podem ocorrer se a criptografia for oportunística.

DANE (DNS-based Authentication of Named Entities)

O DANE utiliza a segurança do DNSSEC para publicar no DNS o hash do certificado digital legítimo do servidor de e-mail.
- Efeito: Impede que um atacante use um certificado falsificado durante a transferência SMTP. Se o hash do certificado apresentado não bater com o hash no DNS (garantido por DNSSEC), o servidor emissor interrompe a transferência imediatamente.

Políticas de TLS Forçado (MTA-STS)

O MTA-STS (SMTP Strict Transport Security) permite que um domínio declare via DNS e HTTPS que o seu servidor de e-mail obriga o uso de TLS com certificados válidos. Isso desencoraja ataques de "Downgrade" onde um adversário intercepta a conexão e remove o sinal de EHLO STARTTLS para ler as mensagens em texto plano.

Comparativo das Defesas

4. Auditoria de Saltos: A Cadeia de Cabeçalhos Received

Cada servidor intermediário (MTA) que a mensagem atravessa tem a obrigação técnica de carimbar o topo da mensagem com um cabeçalho Received. Para investigações de Cyber Security, esta é a ferramenta de rastreamento mais poderosa.

Anatomia de um Salto Received:

• from: Identifica o IP e o domínio que entregaram a mensagem.
• by: Identifica a identidade do servidor que recebeu.
• with: O protocolo e o tipo de criptografia (ex: ESMTPS para SMTP Seguro).
• id / for: O Queue ID interno e o destinatário pretendido para aquele salto.

Analisando a sequência destes cabeçalhos de baixo (mais antigo) para cima (mais recente), é possível identificar exatamente em qual ponto da Internet um e-mail foi gerado ou alterado maliciosamente.

Exemplo de Cabeçalho Received Forense

Received: from mail.atacante.ru (unknown [185.220.101.1])
    by mx.gmail.com with ESMTP id abc123
    for <vitima@gmail.com>;
    Mon, 15 Jan 2024 10:30:45 -0800 (PST)

Esta linha sozinha já permite identificar:
- IP de origem (185.220.101.1) em rede TOR.
- Domínio HELO declarado (mail.atacante.ru) que não bate com o IP real.
- Servidor receptor (mx.gmail.com).
- Hora precisa (com offset).
- Queue ID interno para correlação com logs.

5. Gestão de Latência e Filas de Relay

O fluxo entre servidores não é apenas binário (sucesso ou erro). Se o servidor receptor estiver ocupado, o emissor o coloca novamente na Deferred Queue.

• Retry Schedules: MTAs como Postfix utilizam algoritmos de "recuo exponencial" para não inundar o servidor de destino com tentativas inúteis a cada segundo.
• Concurrency Management: Para evitar listas negras, MTAs grandes limitam quantas conexões simultâneas podem abrir para um mesmo destino (por exemplo, no máximo 5 conexões simultâneas para o Gmail).
• Tempo de Vida: Após 5 dias (configurável), mensagens não entregues geram um DSN (Delivery Status Notification) de falha permanente.

Tabela de Comportamento Padrão do Postfix

6. Perspectiva Cyber: Reputação e Greylisting em Trânsito

A fase entre servidores é protegida por filtros de reputação globais.

• IP Reputation Check: Durante o relay, o receptor analisa se o IP do emissor não é de uma rede residencial ou se não está bloqueado em listas mundiais (Spamhaus, Barracuda, SORBS).
• Greylisting: O receptor dá um erro temporário deliberado (4xx) para novos remetentes. Robôs de spam simples (spambots) geralmente não tentam reenviar, enquanto MTAs legítimos o fazem de forma automática, permitindo filtrar e-mails maliciosos sem olhar o conteúdo.
• SPF/DKIM/DMARC: Validam que o remetente do envelope está autorizado pelo domínio declarado, prevenindo spoofing.

7. Conclusão da Transferência

A transferência entre servidores termina com o sucesso do comando DATA e o recebimento de um código final de aceitação. A partir deste ponto, o servidor receptor assume a responsabilidade pela entrega final da mensagem para a caixa de correio do usuário, encerrando o ciclo de trânsito global do protocolo SMTP.

Para engenheiros de e-mail, dominar este estágio significa conhecer profundamente o interplay entre DNS (MX), TLS (STARTTLS/DANE/MTA-STS), reputação de IP e cabeçalhos Received. Cada e-mail bem entregue é o resultado de dezenas de validações técnicas transparentes ao usuário — e cada uma delas é um ponto de falha potencial quando mal configurada.