O que é TLS-RPT (relatório de TLS)?
O TLS-RPT é o registro que pede aos provedores do mundo inteiro que enviem, todo dia, um relatório do que deu certo e do que falhou ao entregar e-mail de forma criptografada no seu domínio. Ele não protege nada sozinho: é o instrumento de medição da camada de transporte, e é o que torna seguro exigir criptografia obrigatória, porque mostra quem estava falhando antes que a exigência passe a recusar mensagens. Definido na RFC 8460 sob o nome SMTP TLS Reporting, publicado num registro _smtp._tls.
Como o TLS-RPT funciona
Quem tenta entregar e-mail no seu domínio é quem enxerga se a criptografia funcionou. O TLS-RPT é o pedido formal para que esses provedores do outro lado contem o que viram.
Você publica o endereço de destino
Um registro de texto em _smtp._tls.seudominio.com, com o conteúdo v=TLSRPTv1 e um rua=mailto: seguido do endereço que vai receber os relatórios, diz ao mundo para onde mandá-los. O destino também pode ser um endereço web.
Cada provedor remetente mede as entregas
Ao entregar para você, o servidor do remetente registra se conseguiu estabelecer o canal criptografado, se o certificado validou e se a sua política foi encontrada e aplicada.
O relatório chega uma vez por dia
Os provedores agrupam o resultado do dia inteiro e enviam um arquivo com as contagens de sucesso e de falha, o tipo de cada falha e os endereços envolvidos.
Você lê e corrige antes de exigir
É esse conteúdo que diz se dá para subir a política para o modo obrigatório sem recusar remetente legítimo, e é ele que denuncia certificado prestes a virar problema.
Fonte: RFC 8460, a especificação oficial do relatório de TLS do SMTP publicada pelo IETF, que define o registro _smtp._tls, o formato do relatório e os tipos de falha que ele nomeia, reunidos ali em dois blocos: falha na negociação do canal e falha de política.
Por que tanta gente publica e nunca lê
- O relatório é feito para máquina, não para pessoa. O arquivo é dado estruturado, normalmente compactado, e chega numa caixa de e-mail. Sem uma ferramenta que traduza aquilo em texto legível, ele se acumula sem nunca ser lido.
- A leitura do relatório de TLS costuma ficar atrás de uma camada paga. O relatório de autenticação, do DMARC, tem serviço gratuito de sobra que devolve um resumo legível; nas mesmas plataformas, a leitura do relatório de TLS aparece com frequência só nos planos pagos. Existe alternativa gratuita e existe ferramenta aberta, mas é preciso ir atrás, e isso empurra o assunto para o fim da fila.
- Ele só enxerga quem implementa. Um provedor que não adotou o padrão não manda relatório, então o silêncio de uma origem não prova que ela esteja entregando bem: prova apenas que ela não reporta.
- Ele olha para trás, não para agora. O relatório fecha um dia inteiro em horário UTC e ainda sai com algumas horas de atraso proposital, para não sobrecarregar quem recebe. Serve para diagnóstico e tendência, e não como alarme em tempo real de uma entrega que acabou de falhar.
As três famílias de falha que o relatório permite distinguir
- Falha de negociação O caso mais direto: o servidor do outro lado não ofereceu a troca para canal criptografado. No relatório aparece com o nome starttls-not-supported, e é o sinal de que a entrega seguiu, ou teria seguido, em texto aberto.
- Falha de certificado O canal até pôde ser criptografado, mas a identidade não fechou: o relatório separa cada caso pelo nome, certificate-expired para o vencido, certificate-host-mismatch para o emitido com outro nome e certificate-not-trusted para o de emissor não confiável. É a família que mais gera susto na véspera de exigir, e a mais fácil de corrigir com antecedência.
- Falha de política O remetente não conseguiu buscar a sua política de canal obrigatório, ou a encontrou inválida: são os nomes sts-policy-fetch-error e sts-policy-invalid. O relatório distingue aqui os dois caminhos de exigência que o padrão prevê: o que publica a política num site, onde a causa costuma ser o certificado ou a disponibilidade desse site, e o que a publica no próprio DNS assinado (DANE), onde a causa está no registro. Em nenhum dos dois casos o problema está no servidor de e-mail.
- E o outro lado da moeda Não é uma quarta família, é o contraponto das três: o relatório também conta os sucessos. É essa contagem, e não a ausência de reclamação, que autoriza subir a exigência: você passa a saber quantas entregas por dia já estão acontecendo do jeito certo.
Exigir sem medir é apostar
A ordem em que essas três peças entram é o que separa um endurecimento tranquilo de um incidente autoinfligido. Exigir canal criptografado sem relatório é decidir no escuro: você não sabe quais parceiros, clientes ou sistemas ainda entregam de um jeito que a exigência vai recusar, e a primeira notícia do problema chega pelo telefone, com alguém dizendo que o e-mail voltou. Com o relatório ligado antes, a mesma decisão vira contabilidade: você vê durante semanas quem falha, por qual motivo e em que volume, corrige o que é seu, avisa quem precisa ser avisado, e só então aperta. E o prejuízo dessa versão não é técnico: é o pedido que não chegou ao cliente, a fatura que ninguém recebeu e o parceiro que concluiu que a sua empresa deixou de responder. É o mesmo princípio da autenticação de remetente, onde a política de observação existe para medir antes de bloquear. O instrumento não protege, mas é ele que permite proteger sem quebrar nada.
Como tirar valor do relatório de TLS
Publicar o registro é a parte fácil e é onde a maioria para. O valor está nos quatro passos seguintes:
- Aponte o relatório para um destino que alguém acompanhaUma caixa que ninguém abre transforma a etapa de medição em espera. Vale uma caixa monitorada ou um serviço que receba e processe, nunca o e-mail pessoal de quem configurou.
- Garanta que alguém consegue ler o que chegaO arquivo é dado estruturado e compactado. Antes de publicar, decida como ele vai ser transformado em algo legível, seja por uma ferramenta, seja por um processo interno. Sem isso, o registro é decorativo.
- Olhe primeiro a família de certificadoÉ a que mais aparece e a que mais barra entrega quando a exigência entra em vigor. Certificado vencendo ou com nome que não bate é problema conhecido com data marcada.
- Use a contagem de sucessos para decidir a hora de exigirA pergunta não é se apareceu falha, é se as falhas que restam são de origens que você reconhece e aceita perder. Quando não houver mais surpresa, o modo obrigatório deixa de ser risco.
- Mantenha o relatório ligado depois de exigirEle deixa de ser preparação e vira monitoramento: certificado vence, servidor muda, parceiro reconfigura. É o relatório que avisa antes do cliente.
Na prática
O relatório de TLS é o instrumento de voo da entrega de e-mail: ele não faz o avião voar, mas voar sem ele no escuro é o que derruba. Publicar a exigência de canal criptografado antes de ter o relatório funcionando é exatamente esse voo às cegas, e o custo aparece na forma mais cara possível, que é a mensagem legítima que deixa de chegar sem ninguém saber por quê.
Como a Zamak trata o relatório de TLS
A Zamak Technologies liga o relatório antes de qualquer exigência, aponta o destino para onde ele é de fato lido e usa a contagem de sucessos e falhas para decidir quando o modo obrigatório deixa de ser risco, ao lado da equipe que já administra o ambiente. O STARTTLS explica por que a medição é necessária e o MTA-STS é a exigência que ela torna segura. A verificação de falsificação de e-mail dá o retrato inicial do que o seu domínio publica hoje. Esse acompanhamento faz parte da Segurança de E-mail Gerenciada e da Cibersegurança gerenciada do Método Zamak.