Artigos

Nada na sua instalação do Matomo conhece uma palavra-passe de caixa de correio

O Matomo envia correio. Relatórios PDF agendados às segundas-feiras de manhã, alertas quando o tráfego cai a pique, a redefinição de palavra-passe de que um colega precisa num momento inoportuno. Tudo isto sai por SMTP, configurado em Definições Gerais, com um nome de servidor, um nome de utilizador e uma palavra-passe guardados no ficheiro de configuração.

No Microsoft 365, esse arranjo está a chegar ao fim. A autenticação básica para o envio de correio via SMTP — nome de utilizador e palavra-passe transmitidos em cada ligação — está a ser retirada do Exchange Online por fases: a Microsoft já a desativa por predefinição nos inquilinos que não a utilizam, e prevê desligá-la por predefinição em todos os inquilinos até ao final de 2026. Quando isso acontecer no seu inquilino, o Matomo deixa de enviar, e a primeira coisa que nota é um relatório que nunca chegou.

A solução a que a maioria dos plugins recorre é pior do que parece

A resposta habitual é o OAuth delegado: ligar o plugin a uma conta Microsoft, avançar por um ecrã de consentimento, e o plugin fica com um token de atualização que lhe permite enviar em nome dessa pessoa.

Funciona. Mas também arrasta uma pessoa para dentro da sua infraestrutura. Essa conta precisa de uma licença. Precisa de uma palavra-passe e de MFA. Se a pessoa sair, se a palavra-passe for alterada, ou se o token de atualização expirar — e os tokens de atualização expiram —, os seus relatórios de análise param silenciosamente e ninguém dá por isso até alguém perguntar por que os números desapareceram. Substituiu uma palavra-passe guardada por um token guardado, pertencente a um colaborador, o que é um problema diferente, não um problema resolvido.

As permissões de aplicação eliminam por completo o fator humano

O Missivus segue o outro caminho que a Microsoft disponibiliza. Em vez de agir em nome de uma pessoa, autentica-se como uma aplicação.

Um registo de aplicação no Entra ID guarda um segredo de cliente ou um certificado. É-lhe concedida a permissão de aplicação Mail.Send — não a delegada — com consentimento de administrador. Envia para uma caixa de correio partilhada, o que no Microsoft 365 não exige nenhuma licença. Não há utilizador, não há início de sessão, não há pedido de MFA, não há token de atualização, e não há nenhuma palavra-passe de caixa de correio em lado nenhum da sua instalação do Matomo ou da sua base de dados. A credencial é um segredo de aplicação que roda no seu próprio calendário, e rodá-lo é colar um novo valor num único campo.

A parte que quase todos fazem mal

Aqui está o pormenor que importa, e a razão pela qual este plugin existe em vez de um excerto de configuração.

Conceder Mail.Send como permissão de aplicação dá a essa aplicação a capacidade de enviar em nome de todas as caixas de correio do seu inquilino. Por predefinição. Isto não é um pormenor menor — é uma capacidade de enviar em nome de qualquer pessoa, à escala de todo o inquilino, entregue a um service principal, e muitos guias práticos param exatamente aí e dão o assunto por encerrado.

A restrição é um passo à parte, num local diferente, numa ferramenta de administração diferente: uma política de acesso de aplicação no Exchange Online — a nova RBAC for Applications da Microsoft cumpre a mesma função e é a direção para a qual a Microsoft está a orientar os administradores —, aplicada via PowerShell, limitando essa aplicação a um único grupo de segurança com correio ativado, contendo apenas a caixa de correio que ela pode tocar. Até a executar, o âmbito é tudo. Depois de a executar, verifica com Test-ApplicationAccessPolicy e confirma que o acesso é negado a uma caixa de correio que deveria estar fora de alcance — porque uma restrição que não testou é uma restrição que está apenas a presumir.

O Missivus disponibiliza o PowerShell para este passo como parte da configuração, em vez de o deixar como exercício para o administrador, e o plugin não considera uma configuração completa sem ele.

O que isto não faz

É exclusivo do Microsoft 365. Se utiliza o Google Workspace ou o seu próprio servidor de correio, isto não é para si e o SMTP está bem como está.

Envia correio de saída e nada mais. A permissão de aplicação é Mail.Send — a aplicação não consegue ler nenhuma caixa de correio, nem deveria conseguir.

E faz passar o correio do seu Matomo pela infraestrutura da Microsoft, uma empresa norte-americana a operar sob alojamento na UE. Se essa for a resposta errada para os seus dados, é a resposta errada também aqui, e preferimos dizê-lo do que deixá-lo por mencionar.

Onde o obter

O Missivus for Matomo está disponível no Matomo Marketplace, GPLv3, gratuito. O guia de configuração — registo da aplicação, concessão da permissão, política de acesso, verificação — está em missivus.com/setup.

Se preferir não mexer no Entra ID nem no PowerShell do Exchange, nós tratamos da instalação e entregamos-lhe uma configuração a funcionar. Essa é a parte paga; o plugin nunca é.

Perguntas frequentes

Isto funciona fora do Microsoft 365?
Não. É exclusivo do Microsoft 365; no Google Workspace ou num servidor de correio auto-alojado, o SMTP continua a ser a resposta certa.
A aplicação consegue ler o nosso correio?
Não. A permissão concedida é apenas `Mail.Send`. A aplicação pode enviar correio de saída e não consegue ler nenhuma caixa de correio.
O que acontece quando o segredo do cliente expira?
O envio pára até o segredo ser substituído. Rodá-lo é colar um novo valor num único campo, e a data de expiração é definida por si no momento em que o segredo é criado.
← Todos os artigos

Conte-nos sobre o seu projeto.

Algumas linhas sobre a empresa e o desafio bastam para começar. Lemos cada mensagem e respondemos pessoalmente — em 24 horas.

Iniciar um projeto