O que é MTA-STS?
O MTA-STS (Mail Transfer Agent Strict Transport Security) é o padrão que permite a um domínio declarar publicamente que só aceita receber e-mail por canal criptografado e validado, e que quem não conseguir cumprir isso não deve entregar. Ele corrige o ponto cego do STARTTLS, cuja proteção é opcional e pode ser derrubada em silêncio: a exigência passa a estar publicada de antemão, e não é mais decidida no calor da entrega. A política fica num arquivo servido por HTTPS, anunciado por um registro _mta-sts no DNS.
Como o MTA-STS funciona
O truque do MTA-STS é publicar a exigência em dois lugares que um atacante de rede não consegue adulterar ao mesmo tempo, e fazer o remetente guardar essa exigência antes de precisar dela.
O domínio anuncia que tem política
Um registro de texto em _mta-sts.seudominio.com, com o conteúdo v=STSv1 e um id de versão, diz que existe política. Quando esse identificador muda, os remetentes sabem que precisam buscar a política de novo.
A política é servida por HTTPS
O conteúdo real fica em https://mta-sts.seudominio.com/.well-known/mta-sts.txt e lista o modo, os servidores de entrada válidos e o max_age, que é por quanto tempo o remetente deve guardar aquilo.
O remetente busca e guarda
Na primeira entrega, o servidor que envia lê a política e a mantém em cache pelo prazo do max_age. É isso que reduz o poder do atacante: na hora do ataque, a exigência já está na mão do remetente. A janela que sobra é o primeiro contato, antes de existir cópia guardada, e é por isso que a norma recomenda prazos de cache tão longos quanto for prático.
A exigência é aplicada na entrega
Se o modo for enforce e o canal não puder ser protegido e validado, o remetente recusa a entrega em vez de cair para texto aberto. Nos outros modos, ele entrega assim mesmo.
Fonte: RFC 8461, a especificação oficial do MTA-STS publicada pelo IETF, que define a publicação em duas partes (o registro _mta-sts e o arquivo mta-sts.txt servido por HTTPS), os três modos de política e o campo max_age.
Onde o MTA-STS para
- Ele depende de quem envia. A política é uma exigência declarada, e quem a cumpre é o servidor do remetente. Provedor que não implementa o padrão simplesmente não a enxerga, e entrega como sempre entregou.
- A política que você publica protege a entrada, não a saída. Ela diz como o mundo deve falar com o seu domínio. Proteger o que você envia é o outro lado do padrão: depende de os seus servidores lerem as políticas dos destinos e de esses destinos publicarem alguma.
- Ele vive de infraestrutura própria. Exige um nome mta-sts publicado, um site HTTPS com certificado válido servindo o arquivo e o registro no DNS coerente com ele. Se o certificado desse site vence, a política some para quem ainda não a tinha guardado.
- Ele não faz nada em modo de teste. É o degrau onde a maioria para, e vale dizer com todas as letras: em testing a política existe, aparece em qualquer verificação e não impede uma única entrega insegura.
Os três modos da política
- none Declara que o domínio não mantém mais política ativa. Serve para sair do padrão de forma limpa, avisando os remetentes que guardaram a política anterior, em vez de simplesmente apagar tudo e quebrar entregas.
- testing A política existe e não exige nada. Quem implementa o relatório de TLS informa as falhas que teria encontrado, mas entrega a mensagem de qualquer jeito, qualquer que seja o resultado da validação. É a fase de medição, e é onde quase metade dos domínios que publicam ficam parados.
- enforce O único modo que protege. O remetente é obrigado a recusar a entrega para um servidor que falhe na validação ou que não suporte a troca para canal criptografado. É aqui que o ataque de supressão do anúncio deixa de funcionar: apagar a linha 250 STARTTLS da conversa não faz mais o remetente cair para texto aberto, faz a entrega ser recusada.
- O campo max_age Não é um modo, é o que dá força aos três: define por quanto tempo o remetente guarda a política. Prazo curto demais reabre a janela de ataque a cada expiração; a norma permite até 31.557.600 segundos, cerca de um ano.
Publicado não é o mesmo que em vigor
Os números deste padrão contam uma história aritmética. De cada mil domínios do topo da internet, sete publicam a política. Desses sete, quatro pararam no modo de teste. E de cada cinco implantações publicadas, uma sequer passa na validação. Multiplicando os três recortes, o total de domínios que de fato recusam uma entrega insegura é uma fração pequena de um número que já era pequeno. E não é uma fila andando: a proporção entre os modos praticamente não se mexeu em três anos de levantamento, o que sugere que o modo de teste deixou de ser etapa e virou destino. Para quem contrata, e para quem responde pelo próprio ambiente, a consequência prática é a mesma: saber que um domínio tem MTA-STS não autoriza nenhuma conclusão sobre a proteção dele, e a única pergunta que devolve informação é em que modo a política está.
Como chegar ao modo obrigatório sem perder e-mail
A sequência existe porque errar aqui não enche a caixa de spam, faz mensagem legítima deixar de ser entregue. Cinco passos, nesta ordem:
- Arrume o certificado dos seus servidores de entrada antesA validação que o remetente vai fazer é contra o nome do seu servidor de e-mail. Certificado vencido ou com nome que não bate reprova, e em enforce reprovar significa mensagem recusada.
- Publique o relatório de TLS primeiroÉ o instrumento. Sem ele, você entra em modo obrigatório sem enxergar quem estava falhando, e descobre a lista de afetados pelo pior caminho possível, um a um, à medida que eles reclamam.
- Comece em modo de teste e leia o que chegaDeixe o testing fazer o trabalho dele, que é medir, por algumas semanas. O que aparece ali é a lista do que precisa ser corrigido antes de exigir.
- Suba para enforce com prazo de cache curto no inícioUm max_age menor no começo permite recuar rápido se algo escapar. Depois de estável, aumente o prazo, porque prazo longo é o que protege de verdade.
- Trate o site da política como serviço de produçãoSe o certificado do mta-sts.seudominio.com vencer, a política some para quem ainda não a guardou. É um item de monitoramento, não um arquivo estático que se publica e esquece.
Na prática
É a diferença entre pedir sala fechada no meio da conversa e ter combinado, antes de qualquer conversa existir, que sem sala fechada não há reunião. O pedido feito na hora pode ser desconvidado na hora, e é exatamente isso que o ataque de supressão faz. A condição combinada de antemão já está guardada com o outro lado quando o momento chega, e então não há o que negociar: ou a sala está fechada, ou não há entrega.
Como a Zamak trata o MTA-STS
A Zamak Technologies conduz o MTA-STS como um caminho medido até o modo obrigatório: certificado de entrada correto, relatório de TLS ligado antes, medição em modo de teste e promoção só com evidência de que nada legítimo é recusado, ao lado da equipe que já administra o ambiente. O STARTTLS explica o buraco que esse padrão fecha, e o TLS-RPT é o instrumento que torna a promoção segura. A verificação de falsificação de e-mail mostra o retrato inicial do seu domínio. Esse acompanhamento faz parte da Segurança de E-mail Gerenciada e da Cibersegurança gerenciada do Método Zamak.