Um problema de segurança descoberto por um administrador de servidores alemão revelou que o Microsoft Outlook, mesmo com a opção “Usar SSL/TLS” ativada nas configurações de conta POP3, pode estar enviando e recebendo emails sem qualquer criptografia. A falha ocorre porque o programa não valida a coerência entre a configuração de criptografia e o número da porta definida para o servidor de entrada. Se a porta for 110, a comunicação segue em texto puro, independentemente da opção de segurança estar marcada. O comportamento foi confirmado em versões do Outlook que vão de 2007 a 2016, e pode ter passado despercebido por quase duas décadas.
A descoberta: uma atualização de servidor expôs a falha
O administrador Marius, que mantém um servidor de email na Alemanha, estava atualizando o sistema operacional de Fedora 42 para Fedora 43 em maio de 2026. A atualização incluiu o software de servidor Dovecot, que saltou da versão 2.3 para a 2.4.3. Com a nova versão, o arquivo de configuração foi completamente reescrito, e uma mudança específica no nome da diretiva de segurança — de auth_allow_cleartextcodecodecodecode para um equivalente moderno — fez com que a antiga permissão para autenticação em texto puro, que era comum em ambientes de hospedagem para garantir compatibilidade com clientes variados, simplesmente não fosse transferida. Imediatamente após a migração, vários clientes que usavam Outlook começaram a relatar que não conseguiam receber emails. A mensagem de erro era sempre a mesma: “-ERR [AUTH] Cleartext authentication disallowed on non-secure (SSL/TLS) connections.” O servidor estava rejeitando conexões que tentavam autenticar sem criptografia.
Por que o Outlook ignorou a própria configuração de segurança
Marius investigou e descobriu que todos os clientes afetados usavam Outlook e, nas configurações de conta, a caixa “Usar SSL/TLS” estava marcada. No entanto, a comunicação real não era criptografada. O motivo: a porta configurada para o servidor POP3 era a 110, que é a porta padrão para conexões não criptografadas (ou que usam STARTTLS após o handshake inicial). A porta correta para SSL/TLS dedicado em POP3 é a 995. O Outlook, mesmo com a opção de criptografia ativada, não altera automaticamente a porta nem emite qualquer aviso ao usuário. Ele simplesmente ignora a configuração de segurança e tenta a conexão em texto puro pela porta 110. O usuário acredita estar protegido, mas sua senha e o conteúdo dos emails trafegam sem qualquer proteção na rede.
O correto, do ponto de vista de usabilidade e segurança, seria que o Outlook alertasse sobre a inconsistência entre porta e configuração, ou que ajustasse automaticamente a porta para 995. Mas isso não acontece. O programa segue em silêncio, transmitindo dados sensíveis de forma vulnerável.
Impacto: por que o problema ficou escondido por tanto tempo
Para que a falha se manifestasse, duas condições precisavam ser atendidas: o servidor de email precisava aceitar autenticação em texto puro na porta 110, e o cliente Outlook precisava estar configurado com a porta 110 mas com a opção SSL/TLS ativada. Durante anos, a maioria dos servidores de hospedagem mantinha a permissão para texto puro ativa, justamente para garantir que clientes antigos ou mal configurados continuassem funcionando. O Dovecot 2.3, por exemplo, já trazia a rejeição de texto puro como padrão, mas muitos administradores desabilitavam essa proteção por questões de compatibilidade. Com a atualização para o Dovecot 2.4, a configuração de permissão foi perdida, e o servidor passou a aplicar a regra de segurança padrão, bloqueando as conexões do Outlook. Foi aí que o problema veio à tona.
Marius coletou evidências de Outlook 2007, 2010, 2013 e 2016, todas apresentando o mesmo comportamento. Ainda não está claro se versões mais recentes, como Outlook 2019 e Microsoft 365, também são afetadas, mas as configurações padrão atuais do Outlook já usam a porta 995 para POP3, o que reduz o risco para novas contas. O perigo real está em contas configuradas manualmente ou migradas de instalações antigas, onde a porta 110 permaneceu inalterada.
Como verificar e corrigir a configuração no Outlook
Se você usa POP3 para receber emails no Outlook, a verificação é simples. Acesse o menu Arquivo, depois Informações, Configurações de Conta, selecione a conta POP3 e clique em Alterar. Na janela que abrir, clique em Mais Configurações e vá para a guia Avançado. Verifique o campo “Porta do servidor de entrada”. Se o número for 110, você está vulnerável. Altere para 995 e mantenha a opção “Esta servidor requer uma conexão criptografada (SSL/TLS)” marcada. Pronto: a partir desse momento, toda a comunicação será criptografada. Se possível, considere migrar para IMAP (porta 993), que oferece sincronização entre dispositivos e também permite criptografia adequada.
Vale lembrar que a responsabilidade pela falha recai sobre o Outlook, que não valida a consistência entre porta e configuração de segurança. O servidor, ao aceitar conexões na porta 110 sem criptografia, estava agindo conforme o protocolo POP3 padrão — quem deve exigir a criptografia é o cliente. O Outlook, que deveria ser o guardião da segurança do usuário, falhou nesse papel.
Implicações legais e de privacidade
Para empresas e organizações na União Europeia, a situação pode configurar violação ao Regulamento Geral de Proteção de Dados (GDPR). O regulamento exige medidas técnicas adequadas para proteger dados pessoais. Se uma empresa configurou o Outlook com SSL/TLS ativado, acreditando estar em conformidade, mas na prática os emails trafegavam sem criptografia, ela pode ter exposto dados de clientes e colaboradores indevidamente. A responsabilidade, no entanto, é difusa: o servidor seguiu o protocolo, o administrador seguiu as práticas comuns da indústria, e o cliente Outlook falhou em aplicar a segurança que o usuário solicitou. A Microsoft ainda não se pronunciou oficialmente sobre o caso.
O episódio serve como um alerta sobre a confiança cega em configurações de software. Uma opção marcada em uma interface não garante que a funcionalidade correspondente esteja realmente ativa. A descoberta só foi possível porque um administrador, ao atualizar o servidor para padrões de segurança mais rigorosos, esbarrou em um comportamento inesperado do cliente de email mais usado do mundo. Quantas outras falhas semelhantes podem estar dormindo em softwares amplamente adotados, esperando uma mudança de configuração para serem reveladas?
