wwt3_encryption para TYPO3

Por que a ofuscação de email continua sendo obrigatória em qualquer site público

Todo site corporativo, toda página universitária e toda presença de órgão público publica endereços de email: contatos no impressum legal, pessoas de contato em equipes, contatos de imprensa em newsrooms, departamento jurídico em avisos de privacidade. Sem proteção, bots harvesters coletam esses endereços em poucos dias após a publicação e os vendem a remetentes de spam. O wwt3_encryption é uma extensão TYPO3 clássica para esse problema e ofusca endereços de email no servidor, de modo que bots fazendo parse de HTML só vêem código inútil, enquanto usuários reais podem clicar no endereço correto. A extensão se destina a operadores que, por razões legais, precisam exibir dados de contato de forma proeminente, mas não estão dispostos a aceitar a enxurrada de spam resultante.

Cenários típicos de uso

Um escritório de advocacia brasileiro com 60 sócios e associados publica todos os perfis dos advogados, inclusive endereços de email diretos, porque o Código de Ética da OAB exige uma forma de contato acessível. Sem ofuscação, todos os 60 endereços recebem em semanas emails de phishing, publicidade e, em parte, ataques direcionados. O wwt3_encryption renderiza os endereços de forma que o código-fonte não contém string @ legível, enquanto o navegador exibe o endereço mailto correto ao usuário.

Um segundo cenário é uma universidade, como USP ou UNICAMP, que mantém páginas de departamentos com contatos de cátedras. Cada cátedra tem uma página com telefone e email, editada via TYPO3 pela equipe editorial. Os redatores inserem os endereços como texto normal em elementos RichText ou campos de contato, sem se preocupar com ofuscação. O wwt3_encryption entra automaticamente no processo de renderização e protege todos os links mailto sem esforço editorial adicional.

O terceiro caso são órgãos públicos brasileiros com impressum, formulários de contato e listas de departamentos. Aqui a exigência costuma ser ainda mais rígida, porque há uma exigência de acessibilidade: o endereço protegido precisa ser lido corretamente por leitores de tela, e um clique precisa abrir o cliente de email, exatamente como em um endereço não ofuscado. Uma combinação de decodificação JavaScript e atributos href semanticamente limpos é o único caminho para cumprir os dois requisitos.

Arquitetura técnica: content post-processing no rendering do TYPO3

O wwt3_encryption se liga ao processo de renderização do TYPO3, tipicamente via hook de Content Post-Processor ou uma Userfunc TypoScript. Depois que o page renderer monta o HTML de saída, a extensão percorre o markup finalizado, encontra todos os links mailto e todos os endereços de email simples em texto corrido via regex e os substitui por variantes ofuscadas. A ofuscação pode ser feita por vários métodos: codificação ROT13 do alvo do link com decodificação JavaScript, codificação Base64, fragmentação caractere a caractere com pseudoelementos CSS ou uma combinação.

A vantagem da variante post-processing é que ela funciona sem alterações em elementos de conteúdo ou templates. Redatores continuam trabalhando com links mailto normais no RichText, e a extensão assume a proteção automaticamente. A configuração é feita via constantes TypoScript, que permitem escolher entre os vários métodos de ofuscação e definir exceções para determinadas páginas ou seções de conteúdo.

Problemas frequentes e soluções

O primeiro problema é acessibilidade. Soluções puramente JavaScript falham em usuários com JavaScript desativado, e alguns leitores de tela têm problemas com fragmentação baseada em CSS. Uma abordagem pragmática combina uma ofuscação no cliente facilmente quebrável com um aria-label semântico adicional no link, de forma que leitores de tela leiam o endereço corretamente enquanto harvesters falham na diferença sintática. Segurança absoluta não é alcançável com endereços publicamente acessíveis, mas mesmo barreiras moderadas reduzem mensuravelmente a carga de spam.

O segundo problema são camadas de cache. Se a ofuscação post-processing roda antes do page cache, o cache entrega os dados ofuscados e tudo funciona. Se, pelo contrário, ela roda depois do cache, toda página cacheada é reprocessada em cada requisição, o que afeta perceptivelmente a performance. A ordem correta na rendering chain do TypoScript é crítica e deve ser verificada a cada mudança maior no comportamento de caching.

O terceiro tema envolve conteúdos dinâmicos. Endereços de email recarregados via AJAX ou vindos de APIs externas não passam pelo renderer do TYPO3 e, portanto, não passam pelo wwt3_encryption. Esses pontos precisam ser protegidos separadamente, seja fazendo a API entregar variantes ofuscadas, seja por um JavaScript cliente que pós-processa o conteúdo recarregado.

Migração e compatibilidade de versões

O wwt3_encryption tem, como muitas extensões TYPO3 mais antigas, um histórico de versões inconsistente: para v9 e v10 houve releases mantidos, para v11 e v12 existem forks comunitários com atividade variada. Quem migra para TYPO3 v13 deve, antes do upgrade, verificar se o próprio fork ainda funciona ou se uma mudança para um método alternativo de ofuscação é necessária.

O core TYPO3 traz um sistema simples de ofuscação de email, ativado via config.spamProtectEmailAddresses no TypoScript, que aplica ROT13 no kernel do renderer. Para setups simples, essa variante do core basta e torna uma extensão própria desnecessária. Quem precisa de ofuscação mais forte ou flexível, por exemplo com vários métodos em paralelo ou exceções por elemento de conteúdo, recorre a uma extensão como wwt3_encryption. A Gosign avalia caso a caso se a função do core basta ou se uma extensão dedicada faz sentido, e apoia, se necessário, a reconstrução em uma implementação post-processing enxuta própria, adaptada ao projeto em questão.

A eficácia de qualquer ofuscação de email diminui com o tempo, porque as técnicas dos harvesters evoluem. ROT13 hoje é considerado quase ineficaz contra bots especializados, enquanto fragmentação caractere a caractere com CSS ou truques Unicode ainda levantam barreiras moderadas. A defesa realmente sólida é, portanto, uma combinação: ofuscação no HTML output, complementada por um bom filtro de spam no lado do destinatário e, idealmente, uma opção de contato via formulário em vez de um endereço publicado diretamente. Quem precisa cumprir exigências legais não escapará da publicação, mas deve oferecer o formulário de contato como via primária e mostrar o endereço apenas secundariamente.

Para operadores de TYPO3 v13, recomenda-se adicionalmente verificar a pipeline de renderização de conteúdo regularmente contra breaking changes no core. Alguns pontos de hook disponíveis em versões anteriores para post-processing foram deprecated na v13 ou substituídos por eventos PSR-14. Extensões que ainda dependem dos hooks antigos rodam tecnicamente após o upgrade, mas não processam mais conteúdo. Uma verificação curta dos logs após um upgrade revela essas falhas silenciosas cedo e evita que, por semanas, endereços não ofuscados sejam entregues sem que ninguém perceba.