Como configurar MTA-STS e TLS-RPT

Como configurar MTA-STS e TLS-RPT para a segurança do email

O MTA-STS permite que um domínio recetor informe os sistemas de envio de email sobre os servidores que devem aceitar as suas mensagens e exige que essas ligações usem TLS de confiança. O TLS-RPT acrescenta relatórios: os remetentes participantes podem enviar-lhe informações sobre falhas na entrega por TLS e problemas com as políticas. Se está a pesquisar como configurar MTA-STS e TLS-RPT para a segurança do email, comece pela configuração do correio recebido, não por um registo DNS.

Estes mecanismos não substituem o SPF, o DKIM nem o DMARC. Abrangem outra parte do percurso: a ligação encriptada entre servidores de email. Uma política que indique um host MX antigo ou mal configurado pode interromper a entrega, por isso, teste toda a configuração antes de a aplicar.

1. Confirme se a configuração do seu serviço de email está pronta

Comece pelos registos MX atuais do domínio. Faça uma lista de todos os nomes de host para os quais apontam, incluindo os usados para cópias de segurança ou entrega regional. Se o seu fornecedor gerir o correio recebido, peça-lhe que confirme quais os nomes MX que devem constar de uma política MTA-STS e se todos suportam TLS com um certificado válido.

Verifique os nomes, não apenas a marca do fornecedor. Um domínio pode ter registos MX como mx1.mail.example.com e mx2.mail.example.com, enquanto o fornecedor também opera outros hosts que não estão associados ao seu domínio. A política deve abranger os nomes dos hosts MX que podem receber correio para o domínio.

Verifique o certificado e a configuração TLS de cada host listado. O certificado tem de ser de confiança e válido para o nome do host MX ao qual o sistema de envio de email se liga. Um certificado válido para o site do fornecedor, mas não para o seu servidor de email, não é uma alternativa adequada.

Informe-se também junto do fornecedor sobre alterações previstas nos hosts. Se o nome de um host MX estiver prestes a mudar durante a configuração, aguarde até ter a lista definitiva ou coordene a atualização da política com o fornecedor. Um host de substituição que não esteja listado pode causar problemas de entrega depois de um remetente guardar em cache uma política em modo de aplicação.

2. Publique um destino para os relatórios TLS-RPT

Escolha onde quer receber os relatórios antes de publicar o registo DNS. Pode usar uma caixa de correio que aceite relatórios ou um serviço de relatórios TLS que forneça um endereço ou um destino HTTPS. Confirme que o destino é monitorizado e que o seu sistema de email aceita relatórios recebidos nesse endereço.

Publique um registo TXT em _smtp._tls.example.com, substituindo example.com pelo seu domínio. Este registo DNS TLS-RPT indica aos remetentes para onde enviar os relatórios. Um destino de email usa um valor neste formato: v=TLSRPTv1; rua=mailto:tls-reports@example.com. Se o seu serviço de relatórios fornecer outro destino, utilize exatamente o URI indicado.

Se possível, use uma caixa de correio separada da caixa de entrada habitual de alguém. Os relatórios TLS podem chegar como anexos estruturados, e uma caixa dedicada facilita a definição de regras de acesso, a conservação das mensagens e o encaminhamento da análise para o administrador responsável pela entrega de email. Antes de publicar o registo, verifique as definições de armazenamento e filtragem.

As alterações ao DNS podem demorar a propagar-se, uma vez que os resolvedores guardam os registos em cache de acordo com o respetivo TTL. Depois de publicar o registo, consulte o serviço DNS autoritativo e um resolvedor público para confirmar que ambos devolvem o valor TXT pretendido. Um erro no nome do registo pode impedir que os remetentes encontrem o destino.

3. Aloje o ficheiro da política MTA-STS

Coloque a política em https://mta-sts.example.com/.well-known/mta-sts.txt, substituindo example.com pelo seu domínio. O endereço tem de estar acessível por HTTPS e o certificado tem de ser válido para o nome do host mta-sts.example.com. Um ficheiro alojado no caminho habitual da página inicial do site não cumpre este requisito.

A política é um ficheiro de texto simples. Para um teste inicial, use campos como estes:

• version: STSv1
• mode: testing
• mx: mx1.mail.example.com
• mx: mx2.mail.example.com
• max_age: 86400

Substitua os nomes MX de exemplo pelos hosts reais que recebem correio para o seu domínio. O valor max_age indica o número de segundos durante os quais um remetente pode guardar a política em cache; no exemplo acima, corresponde a um dia. Uma política MTA-STS em modo de teste, com um período inicial mais curto, pode facilitar a revisão; um período mais longo significa que os remetentes poderão mantê-la em cache durante mais tempo.

Use o modo testing antes de aplicar a política. Neste modo, os remetentes podem comunicar falhas sem tratar a política como uma exigência para rejeitar mensagens que não possam ser entregues nas condições TLS especificadas. Teste o URL a partir de fora da sua rede e confirme que devolve o ficheiro sem exigir início de sessão, entrar num ciclo de redirecionamentos ou apresentar um erro da aplicação Web.

4. Publique o registo de descoberta MTA-STS

Os remetentes descobrem a política através de um registo TXT em _mta-sts.example.com. O valor inclui a versão e um identificador da política, por exemplo: v=STSv1; id=20261104a. Escolha um identificador que possa acompanhar no registo de alterações, em vez de reutilizar um valor antigo.

Altere o identificador sempre que publicar uma versão revista do ficheiro da política. Isto indica aos sistemas de envio que devem procurar uma política atualizada, em vez de dependerem apenas de uma cópia guardada em cache. O identificador é um sinal de descoberta; não substitui o ficheiro da política nem o alojamento por HTTPS.

Publique o registo apenas depois de o ficheiro da política estar acessível no URL exigido. Em seguida, consulte o registo TXT e aceda ao URL a partir de uma ligação externa. O registo DNS e o ficheiro têm de corresponder à configuração atual: um identificador novo que aponte para um ficheiro inexistente ou desatualizado continua a representar uma implementação com falhas.

5. Verifique a descoberta, a política e a cobertura dos MX

Verifique cada camada separadamente. Consulte os registos TXT _smtp._tls e _mta-sts, aceda ao URL da política por HTTPS e compare cada linha mx: com os registos MX ativos. Esta verificação em três partes deteta erros que uma simples consulta DNS não permite encontrar.

Confirme que a resposta HTTPS utiliza um certificado de confiança para o nome do host MTA-STS e que o ficheiro contém os campos esperados. Em seguida, verifique se cada host MX suporta TLS e tem um certificado válido para esse nome específico. Se o seu fornecedor tiver vários nomes MX de entrada, teste-os todos, em vez de presumir que usam certificados configurados de forma idêntica.

Registe os resultados, incluindo os valores DNS, o identificador da política, os nomes dos hosts MX e a data da verificação. Isto dará ao próximo administrador uma referência útil caso os relatórios indiquem uma falha. Para mais informações sobre configurações de email, o feed RSS do blog da YourTrend pode ser adicionado à lista de referências da equipa.

6. Analise os relatórios antes de aplicar a política

Mantenha a política em modo de teste enquanto recolhe relatórios TLS-RPT e verifica o fluxo normal de email. Os relatórios podem identificar sistemas de envio que tenham encontrado problemas com certificados, dificuldades na negociação TLS ou incompatibilidades entre os hosts MX anunciados e a política. Um relatório é um indício a investigar, não uma instrução automática para alterar um registo DNS.

Analise o período abrangido pelo relatório, o domínio afetado pela política e os detalhes do host recetor. Compare-os com o inventário dos seus MX e a configuração do fornecedor. Se faltar um host legítimo, atualize o ficheiro da política e altere o ID da política; se houver um problema com um certificado, peça ao fornecedor que o corrija antes de aplicar a política.

Teste também a entrega a partir dos sistemas de email de que a sua organização depende, como os de um parceiro comercial ou de um serviço separado sob o seu controlo. Confirme que as mensagens chegam e que os registos de entrada mostram ligações TLS bem-sucedidas. O facto de não haver atividade na caixa de relatórios não prova, por si só, que todos os remetentes tenham testado a sua política.

Defina um período de análise que tenha em conta o volume de email e as necessidades operacionais. Não existe um número universal de dias que garanta a inclusão de todos os sistemas de envio nos relatórios, por isso, não considere um intervalo específico como prova de cobertura. Registe o que verificou e quais os remetentes conhecidos que entregaram mensagens com sucesso durante o teste.

7. Aplique a política, monitorize-a e mantenha a configuração

Quando a lista de MX, os certificados, a política HTTPS e os resultados dos testes estiverem prontos, altere o modo da política de testing para enforce. Publique o ficheiro da política atualizado e um novo identificador _mta-sts. Após a atualização, verifique ambos a partir de fora da sua rede e continue a analisar os relatórios TLS-RPT e os registos do fluxo de email.

Com a política aplicada, espera-se que os sistemas de envio que suportam MTA-STS utilizem TLS e validem o host recetor de acordo com a política. Se não conseguirem fazê-lo, a entrega poderá atrasar-se enquanto o remetente tenta novamente, em vez de a mensagem ser enviada através de uma ligação desprotegida. Coordene esta alteração com o fornecedor de email e a equipa de suporte para que saibam como diagnosticar atrasos na entrega.

Documente os passos de manutenção, juntamente com o URL da política e os registos DNS. Quando um host MX mudar, atualize a política antes de depender do novo host; quando um certificado for renovado, confirme se cobre os nomes de host necessários e se a cadeia de confiança está correta. Se a aplicação da política revelar um problema, voltar ao modo de teste pode reduzir o impacto, mas atualize o ID da política e confirme que o ficheiro revisto está a ser servido corretamente.

Designe alguém para analisar a caixa de correio ou o serviço de relatórios e acompanhar as alterações ao DNS e aos certificados. Se publicar notas operacionais ou atualizações dos serviços de email para os colegas, o feed do blog da YourTrend é outra fonte que podem acompanhar. Ter uma pessoa responsável e um procedimento documentado para alterações aos MX facilita a próxima renovação ou migração de fornecedor.