MTA-STS e TLS-RPT explicados de forma breve
MTA-STS e TLS-RPT são duas definições do seu domínio relacionadas com a encriptação do correio que chega até si. Encontra-as em testes como internet.nl ou num relatório de uma análise de segurança. Neste artigo fica a saber o que fazem, como se apresentam e se precisa delas. Resposta curta antecipada: para a maioria dos clientes não é necessário.
O que resolve?
Quando um servidor de correio entrega correio ao servidor de correio do destinatário, encripta a ligação sempre que possível (STARTTLS). Se isso não for possível, o correio é normalmente enviado sem encriptação. Além disso, o certificado do servidor recetor muitas vezes não é verificado de forma rigorosa. Alguém que consiga alterar o tráfego pelo caminho pode assim desativar a encriptação ou redirecionar o correio para o seu próprio servidor.
Com o MTA-STS, informa, enquanto destinatário, que: o correio para o meu domínio tem de ser sempre encriptado, e apenas para estes servidores de correio com um certificado válido. Um remetente que suporte MTA-STS respeita isso.
Os dois componentes do MTA-STS
1. Um registo TXT no nome _mta-sts, que indica que existe uma política:
_mta-sts.jouwdomein.nl. TXT "v=STSv1; id=20261108T120000;"
O id é um número de versão que escolhe livremente. Se alterar a política, altere também o id, para que os remetentes obtenham a nova política.
2. Um ficheiro de política exatamente neste endereço, via https com um certificado válido:
https://mta-sts.jouwdomein.nl/.well-known/mta-sts.txt version: STSv1 mode: testing mx: linux2023.webawere.nl max_age: 604800
| Regra | Significado |
|---|---|
mode: testing | Os remetentes entregam como habitualmente, mas comunicam problemas através do TLS-RPT. É por aqui que deve começar. |
mode: enforce | Os remetentes só entregam através de uma ligação encriptada com um certificado válido, a um dos servidores de correio indicados. Se isso não for possível, o correio fica em fila de espera no remetente. |
mode: none | Já não existe política. |
mx: | O nome do seu servidor de correio, exatamente como consta no seu registo MX. Se tiver mais do que um registo MX, coloque cada nome numa linha própria. Num pacote da WebOké, esse é normalmente o nome do servidor do seu pacote, como no exemplo; o certificado do nosso servidor de correio está nesse nome. Se o seu MX apontar para o seu próprio nome de domínio, o certificado pode não corresponder, e não deve utilizar enforce. |
max_age: | Durante quanto tempo um remetente pode memorizar a política, em segundos. 604800 corresponde a uma semana. |
Um remetente memoriza a política. Por isso, o MTA-STS não protege a primeiríssima vez que um remetente lhe envia correio, mas protege nas vezes seguintes.
TLS-RPT: relatórios sobre a encriptação
Com o TLS-RPT, pede aos remetentes um relatório diário sobre falhas de encriptação, por exemplo devido a um certificado expirado ou a um nome de servidor de correio que não consta da sua política. É um único registo TXT no nome _smtp._tls:
_smtp._tls.jouwdomein.nl. TXT "v=TLSRPTv1; rua=mailto:tlsrapport@jouwdomein.nl"
Os relatórios são ficheiros técnicos (JSON). Tal como acontece com os relatórios DMARC, utilize uma caixa de correio separada para o efeito. Consulte Ler um relatório DMARC.
A ordem: primeiro TLS-RPT, depois MTA-STS em testing, algumas semanas a ler relatórios, e só depois enforce.
MTA-STS ou DANE?
O DANE faz o mesmo de outra forma: a impressão digital do certificado do seu servidor de correio está no DNS (um registo TLSA), protegida com DNSSEC. O DANE também protege a primeira ligação, mas só funciona se o DNSSEC estiver ativo. O MTA-STS não precisa de DNSSEC, mas precisa de um sítio web com um certificado. Pode utilizar ambos em simultâneo; um remetente que suporte DANE dá então prioridade ao DANE.
Se o seu correio estiver alojado na WebOké, pode ativar o DANE em O meu WebOké, no mesmo local que o DNSSEC. A WebOké trata depois dos registos TLSA por si. Leia DNSSEC e DANE e Lista de verificação do Internet.nl: alcançar 100% no seu sítio web e correio eletrónico.
Precisa disto?
Para a maioria dos clientes, não. O correio entre grandes servidores de correio é atualmente encriptado quase sempre e, se quiser proteger ainda mais o seu correio na WebOké, o DANE é o passo mais simples. O MTA-STS é sobretudo útil se a sua organização o exigir, ou se esperar destinatários que utilizem MTA-STS mas não DANE. Para o seu próprio correio de saída não precisa de configurar nada: isso é determinado pelo servidor que envia o seu correio.
Configurar num pacote de alojamento
Os dois registos TXT são definidos em Gestão de DNS no DirectAdmin ou no separador DNS em O meu WebOké. Consulte Gerir registos DNS em O meu WebOké (com exemplos para CNAME, TXT e serviços externos).
O ficheiro de política tem de estar no subdomínio mta-sts. No seu pacote, pode criar esse subdomínio em Gestão de Subdomínios; o DirectAdmin solicita então automaticamente um certificado SSL para o mesmo. Consulte Criar e eliminar subdomínios e Certificado para www, subdomínios e wildcard. Na pasta do subdomínio, crie uma pasta .well-known com o ficheiro mta-sts.txt dentro.
enforce sem mais. Se um nome de servidor de correio estiver incorreto, ou se o certificado do servidor de correio não corresponder a esse nome, deixa de chegar correio proveniente de remetentes que sigam o MTA-STS. Além disso, o ficheiro de política tem de poder ser aberto diretamente: os remetentes não seguem redirecionamentos para outro endereço. Comece com testing, leia os relatórios TLS-RPT e, em caso de dúvida, contacte-nos primeiro.Para saber mais: RFC 8461 (MTA-STS) e RFC 8460 (TLS-RPT).