Rspamd em vez do SpamAssassin: uma comparação útil entre filtros de spam modernos

Objetivos dos filtros de spam e erros inevitáveis

Um filtro de spam de e-mail avalia as mensagens no fluxo de e-mails com base em características técnicas e de conteúdo. Dependendo do produto, estas incluem, por exemplo, dados do remetente e de autenticação, cabeçalhos, URLs, texto da mensagem, estrutura HTML, classificações estatísticas e consultas externas. O objetivo não é determinar a veracidade de um e-mail, mas sim classificar o risco de entrega de forma compreensível. Rspamd Para tal, reúne também vários módulos de verificação e consegue compilar os resultados num documento de apoio à tomada de decisões.

Várias etapas devem ser mantidas separadas: o MTA aceita inicialmente uma mensagem SMTP ou rejeita-a durante a transmissão. O filtro determina, em seguida ou durante a integração, uma pontuação. Uma marcação complementa, por exemplo, o cabeçalho ou desloca a mensagem para uma pasta de lixo eletrónico através de regras posteriores. Por outro lado, uma rejeição encerra o processo de aceitação; por isso, é a medida com maiores consequências e não apenas uma marcação mais forte.

A Falso positivo ocorre quando uma mensagem legítima é erroneamente classificada como spam. Isto pode acontecer, por exemplo, com uma fatura autêntica de um fornecedor, cujo anexo em PDF, pedido de pagamento ou domínio de envio invulgar desencadeie várias verificações. Se for apenas marcada, o destinatário ainda a pode encontrar; se for rejeitada, nem sequer chega à caixa de correio. Para a comunicação empresarial, esta diferença é decisiva.

Por outro lado, um Falso negativo uma mensagem de spam que consegue passar pelo filtro. Um exemplo típico seria uma campanha com textos ligeiramente alterados, links variáveis e cabeçalhos que parecem tecnicamente corretos. Estas mensagens aumentam o risco de phishing, software malicioso ou publicidade indesejada, mas não significam automaticamente que qualquer rejeição rigorosa se justifique. Um filtro de spam de e-mail procura sempre o equilíbrio entre estes dois tipos de erros, e não uma taxa de precisão de 100%.

Os valores-limite são, por isso, uma decisão operacional em matéria de risco. Um valor baixo para rejeições pode reduzir o spam que passa, mas aumenta o risco de perda de correio legítimo. Um valor mais elevado transfere mais responsabilidade para a marcação, a quarentena e a verificação pelo utilizador. É aconselhável adotar uma estratégia gradual: primeiro, a marcação e a observação; depois, a lista cinzenta ou medidas mais rigorosas, apenas nos casos em que os registos, os comentários e o próprio tráfego de e-mail justifiquem essa decisão.

SpamAssassin: Regras, pontuações e modelo de funcionamento

SpamAssassin é um filtro expansível, baseado em regras e pontos. Analisa, entre outros, cabeçalhos, corpo do texto, HTML e URLs; além disso, estão disponíveis métodos estatísticos, consultas de rede e plug-ins para funções como Bayes, SPF, DKIM ou DMARC. Cada correspondência contribui com pontos para o resultado. A soma desses pontos resulta numa pontuação, que pode ser comparada com um valor-limite configurado.

As personalizações próprias são normalmente efetuadas em .cf-ficheiros. Isto permite, por exemplo, definir regras para cabeçalhos, corpo e URI com pontuações próprias. Este modelo é particularmente transparente quando uma equipa precisa de compreender por que razão uma determinada regra foi acionada. Ao mesmo tempo, com tantas exceções, conjuntos de regras locais e avaliações diferentes, o esforço de manutenção aumenta: cada regra requer uma justificação técnica, um impacto documentado e um controlo regular.

No funcionamento contínuo do servidor, o serviço normalmente spamd Recebe ordens de auditoria, enquanto o cliente leve spamc Envia-lhe mensagens. Esta separação evita o esforço de iniciar o programa na íntegra para cada mensagem e destina-se a verificações recorrentes. O serviço pode ainda incluir configurações SQL ou LDAP, bem como definições específicas do utilizador.

Isto é relevante para ambientes de alojamento: um domínio pode necessitar de listas brancas diferentes, enquanto as caixas de correio individuais têm as suas próprias preferências ou níveis de aprendizagem. Estas estruturas que foram evoluindo ao longo do tempo não constituem uma falha técnica, mas dificultam a migração. Por isso, antes de uma mudança, deve ficar claro quais as regras que são efetivamente críticas para o negócio, quais foram apenas herdadas historicamente e quais as tarefas que já são desempenhadas pelo MTA ou por outro serviço.

Uma instalação bem mantida do SpamAssassin não tem de ser substituída apenas devido à sua antiguidade. Se as regras forem compreensíveis, a integração funcionar de forma estável e o esforço administrativo for adequado ao volume de e-mails, uma manutenção específica pode fazer mais sentido do que uma migração. Por outro lado, uma elevada percentagem de regras especiais difíceis de manter não constitui um argumento para uma cópia cega: é um motivo para que o Existência normalizada ajustar de forma crítica, independentemente do filtro que venha a ser escolhido posteriormente.

Rspamd: Trabalhadores, ícones e ações

O Rspamd funciona com um modelo mestre-trabalhador. O mestre gere os processos e a configuração, enquanto os trabalhadores normais verificam as mensagens. Um «proxy-worker» pode, entre outras coisas, receber pedidos do Milter e distribuí-los pelos «scanners». O «controller» disponibiliza funções de gestão e uma interface web, mas não deve ser exposto sem proteção à rede pública. Estas funções separam mais claramente o tráfego de e-mail, o processamento e a administração.

Um aspeto importante para a arquitetura é a entrada e saída não bloqueantes. As consultas DNS, Redis ou HTTP podem ser realizadas de forma assíncrona. Se uma verificação estiver à espera de uma resposta externa, isso não tem necessariamente de interromper outras verificações do mesmo worker. Daí não decorre qualquer garantia geral de desempenho: os resultados reais continuam a depender do conjunto de regras, do hardware, das latências do DNS, do Redis, da ligação ao MTA e da composição real das mensagens.

Criação de testes no Rspamd Símbolos com avaliações e informações adicionais. O filtro agrupa-as numa pontuação global e pode sugerir uma ação, como, por exemplo, add header, greylist ou reject. Esta ação não constitui uma decisão de entrega obrigatória: só a configuração e a integração concreta no Postfix, no Exim ou no Sendmail determinam se e como o MTA a aplica.

É precisamente por isso que os limites existentes do SpamAssassin não devem ser adotados como valores numéricos. Cada pontuação reflete a interação entre as regras ativadas, a sua ponderação e as fontes de dados disponíveis. Mesmo as verificações com o mesmo nome podem ser ponderadas de forma diferente, agregadas de forma diferente ou executadas em momentos diferentes nos dois sistemas. Uma comparação direta de required_score Utilizar um limiar Rspamd seria tecnicamente enganador.

Para a empresa, a separação entre avaliação e aplicação é uma vantagem: podes, numa primeira fase, observar as publicações de símbolos e as ações sugeridas sem as rejeitar imediatamente. Só com base nas tuas próprias mensagens legítimas, nas campanhas identificadas e nos comentários é que se pode determinar quais Limiares de ação são aceitáveis. Assim, uma predefinição técnica transforma-se numa diretriz de entrega verificável, em vez de um limite de spam supostamente objetivo.

Comparação para a gestão diária do correio eletrónico

As diferenças entre o SpamAssassin e o Rspamd residem menos numa regra de deteção específica e mais no modelo de funcionamento. Ambos avaliam os e-mails com base em vários sinais, mas as formas de configuração, integração e funcionamento distribuído diferem. A comparação que se segue organiza estes pontos como base de planeamento; não substitui uma análise do próprio tráfego de e-mail.

Para um pequeno servidor individual, uma instalação bem mantida do SpamAssassin não constitui, portanto, uma emergência técnica. Se as regras próprias forem compreensíveis, o serviço funcionar de forma estável e as classificações erradas forem corrigidas, mantê-la pode significar um menor esforço de alteração. No entanto, uma reinstalação com o Rspamd continua a ser uma opção plausível, caso a sua integração com o Milter e os módulos agrupados centralmente se adaptem melhor ao ambiente planeado.

Em ambientes de alojamento com vários scanners, a Escalonamento mais importante do que o mero número de regras instaladas. O Proxy-Worker do Rspamd pode reencaminhar pedidos Milter para outros workers; as consultas externas assíncronas não devem, assim, bloquear todo o worker. No entanto, isto não implica uma garantia geral de desempenho: as latências do DNS, as regras, o hardware e a composição das mensagens determinam a taxa de transferência real.

Ligação MTA, Redis e módulos baseados no estado

A integração técnica determina em que ponto um filtro de spam de e-mail envia a sua avaliação de volta ao Mail Transfer Agent. O Rspamd pode ser ligado ao Postfix e ao Sendmail através do Milter. O Exim utiliza, para o efeito, a sua integração através de spamd_address. O filtro fornece um resultado, mas o MTA e a configuração selecionada continuam a determinar se uma mensagem é marcada, atrasada ou rejeitada.

Nem todas as verificações requerem um estado comum. O SPF, o DKIM e o DMARC analisam informações de autenticação; as listas baseadas em DNS e as expressões regulares verificam outras características de uma mensagem individual. Embora essas verificações possam necessitar de respostas DNS externas, não mantêm automaticamente um histórico de aprendizagem. A sua validade depende, entre outros fatores, do funcionamento correto do DNS e de uma ponderação adequada no conjunto de regras.

Trabalhar de forma diferente módulos baseados no estado. A classificação bayesiana armazena características aprendidas, a lista cinzenta tem de reconhecer tentativas de entrega anteriores e os limites de taxa requerem contadores que abranjam várias ligações. O Rspamd prevê a utilização do Redis na arquitetura documentada para a classificação bayesiana, a classificação neural, a lista cinzenta e outros estados. Desta forma, várias instâncias podem aceder a informações partilhadas.

O Redis não é, portanto, nem um detalhe dispensável nem um pré-requisito para cada verificação individual do Rspamd. Sem memória disponível, os módulos estáticos podem continuar a ser utilizados, enquanto as funções de aprendizagem e de reputação ficam limitadas ou deixam de funcionar. Por isso, os operadores devem definir a disponibilidade, a ligação à rede, a proteção de acesso, a segurança e o comportamento em caso de falha do Redis antes da entrada em produção.

Na prática, faz sentido separar as responsabilidades: o MTA aceita ligações SMTP e aplica a decisão de filtragem, o Rspamd avalia as mensagens e o Redis mantém os estados necessários. Esta divisão facilita a deteção de erros, mas aumenta o número de serviços a monitorizar. Uma dependência lenta ou inacessível não deve ser compensada por rejeições precipitadas.

Transferir regras e dados de aprendizagem de forma controlada

Uma migração começa com um levantamento da situação atual, e não com a cópia de todos os ficheiros. As regras próprias, em particular, merecem ser analisadas: podem refletir requisitos empresariais, mas também conter exceções desatualizadas. O Rspamd disponibiliza um módulo do SpamAssassin que processa apenas uma parte das regras. A semelhança técnica de uma regra não garante, portanto, que esta tenha o mesmo efeito.

O módulo permite, entre outras coisas, determinar certos body-, rawbody-, header-, meta- e uri-Processar regras. Por outro lado, os plug-ins específicos de rede e HTML não estão totalmente abrangidos. Carregar conjuntos de regras externos extensos sem os verificar pode complicar a configuração e sobrecarregar o processamento. É preferível adotar apenas regras próprias cuja necessidade seja comprovada e dar preferência aos módulos nativos.

Isto exige um cuidado especial Treino de Bayes. De acordo com a documentação do Rspamd, não é possível importar bases de dados Bayes do SpamAssassin. Por isso, o Rspamd necessita de novos corpora verificados, compostos por mensagens desejadas e spam. Faturas, newsletters ou campanhas classificadas incorretamente desviam a classificação na direção errada e podem agravar decisões erradas posteriores.

O AWL também não deve ser tratado como uma transferência de ficheiros. Embora o histórico anterior do remetente e a avaliação atual da reputação tenham objetivos semelhantes, podem utilizar fontes de dados e ponderações diferentes. Por isso, documente primeiro qual o efeito pretendido de uma exceção ou regra de confiança existente. Só depois é que se pode decidir se é mais adequado utilizar uma função nativa do Rspamd ou uma regra própria específica.

Implementar o Rspamd em segurança em ambiente paralelo

Uma transição produtiva não começa com a substituição do filtro atual, mas sim com um levantamento da situação. Documenta a ligação MTA, as regras do SpamAssassin, as exceções específicas de cada utilizador, as dependências de DNS, os remetentes aceites e o tratamento atual das mensagens suspeitas. Defina também quais os indicadores que serão importantes mais tarde: por exemplo, e-mails comerciais marcados erroneamente, campanhas que passaram pelo filtro e o esforço de processamento manual.

Comece por instalar o Rspamd separadamente do caminho de e-mail principal e configure-o de forma a que a sua avaliação seja registada, mas sem alterar a entrega. O «Shadow Mode» documentado permite exatamente essa observação: o Rspamd verifica as mensagens sem aplicar as ações que propõe. Assim, o SpamAssassin continua a ser o único decisor ativo durante a fase de comparação.

Não avalie apenas a pontuação total, mas sobretudo os resultados obtidos Símbolos e a ação daí decorrente. Um valor elevado pode resultar de erros de autenticação, características da URL, dados de reputação ou regras locais; estas causas exigem correções diferentes. Por isso, para cada mensagem suspeita, verifica o cabeçalho, o grupo de destinatários e a ação sugerida pelo filtro antes de alterares pontuações ou módulos.

Uma comparação pertinente inclui casos-limite específicos, tanto desejados como indesejados. Uma fatura legítima de um fornecedor conhecido pode, por exemplo, conter um ficheiro PDF e um link de rastreio externo. Por outro lado, uma campanha de spam com grande variedade altera constantemente o assunto, os blocos de texto e o remetente, mas mantém URLs típicas ou características estruturais. Ambos os tipos de mensagens revelam se determinados símbolos contribuem de forma compreensível ou se uma regra é demasiado abrangente.

Jugo Valores de limiar só quando existirem exemplos verificáveis suficientes. A escala de pontuação do Rspamd não é equiparável a um valor anterior do SpamAssassin; por isso, uma adoção direta pode desencadear ações inadequadas. Decida separadamente em que momento se devem apenas completar os cabeçalhos, quando se deve colocar temporariamente na lista cinzenta e em que condições se deve rejeitar. A integração com o MTA determina, neste contexto, se e como uma ação é efetivamente aplicada.

Após uma fase de observação planeada, a transição é efetuada de forma controlada: o Rspamd passa a ser o filtro ativo, enquanto o SpamAssassin permanece instalado e configurável, mas deixa de intervir no fluxo de e-mails. Este período de transição deve incluir definições de responsabilidades, um método documentado para reverter a configuração e critérios para a interrupção do processo. Além disso, uma configuração de firewall bem delimitada é útil; o artigo explica os princípios básicos para migrações graduais de regras. Netfilter vs. nftables.

Operação, registo e deteção sistemática de erros

No caso de uma rejeição inesperada, o diagnóstico começa com a mensagem específica e a sua cadeia de processamento, e não com um abrandamento generalizado do limite do filtro. Verifique o registo do MTA, o resultado do Rspamd, os símbolos acionados, a pontuação e a ação sugerida. Só esta análise permite determinar se a rejeição foi causada, por exemplo, por uma regra local, uma verificação baseada em DNS ou pela aplicação do MTA.

O spam que passou pelo filtro requer uma análise inversa. Verifica se a mensagem chegou ao Rspamd, quais os símbolos que faltam e se uma ação configurada não foi executada devido à pontuação. Se faltarem resultados de DNS esperados, analisa os resolvers, a acessibilidade e os tempos de resposta antes de criares novas regras de conteúdo. Nem todas as campanhas podem ser avaliadas de forma adequada através de um único valor-limite.

Uma falha do Redis deve ser tratada separadamente, uma vez que pode afetar funções baseadas no estado. Verifique a ligação do filtro à memória, os registos do serviço Redis e, em seguida, quais os módulos que dependem desse estado. As verificações estáticas podem continuar a fornecer resultados, mas o treino bayesiano, a lista cinzenta ou outras avaliações dependentes do estado requerem um sistema de armazenamento de dados em funcionamento.

Se uma regra esperada não for acionada, verifique primeiro o local onde foi efetivamente carregada, a sintaxe e o formato da mensagem em relação ao qual deve funcionar. As verificações de cabeçalho, texto bruto, HTML e URL analisam dados diferentes. No SpamAssassin, os ficheiros de regras podem ser verificados com uma verificação de sintaxe antes de serem aplicados; o comando seguinte verifica a configuração e não altera o envio de e-mails em produção.

spamassassin --lint

Para falhas recorrentes, mantenha os carimbos de data/hora, o comportamento da fila, os pedidos de DNS e os erros de resposta numa vista comum. Desta forma, é possível distinguir se um atraso na entrega tem origem no MTA, numa consulta externa ou no processo de filtragem. Para telemetria Linux mais aprofundada e monitorização de sistemas em execução, o artigo complementar oferece bpftool para a análise moderna do kernel princípios técnicos.

Não altere de forma impulsiva nem as pontuações globais nem conjuntos de regras abrangentes na sequência de um único incidente. Em vez disso, guarde a mensagem em questão de acordo com as normas de proteção de dados, compare-a com casos semelhantes e documente a causa, juntamente com a alteração. Isto Análise de erros permite efetuar correções compreensíveis e reduz o risco de que uma regra de exceção venha a tratar indevidamente grandes quantidades de e-mails legítimos ou indesejados.

Tomar uma decisão com base no perfil do servidor

Continuar a utilizar o SpamAssassin de forma seletiva é plausível se o servidor de e-mail existente for gerido de forma fiável, com as suas próprias regras, definições por utilizador e procedimentos operacionais. O sistema é expansível com base em regras e pontos e suporta plug-ins, bem como várias opções de configuração e armazenamento. Uma mudança apenas devido à antiguidade de uma instalação não traz qualquer benefício técnico, caso não exista um problema operacional concreto.

O Rspamd é a escolha óbvia para uma reconstrução, caso a integração com o Milter, as verificações de autenticação modernas, o controlo centralizado e os módulos baseados no estado sejam planeados em conjunto desde o início. A sua arquitetura inclui funções de «worker» para o processamento, ligações proxy e gestão; ao mesmo tempo, o DNS e, se for o caso, o Redis têm de ser operados de forma fiável como dependências operacionais. Trata-se de uma decisão de arquitetura, não de uma garantia geral de desempenho.

Para ambientes de alojamento já consolidados, com muitos casos específicos, o Funcionamento em paralelo geralmente a opção mais fiável. Permite identificar quais as regras do SpamAssassin que continuam a ser necessárias, se os símbolos do Rspamd refletem as causas esperadas e quais os grupos de destinatários que reagem de forma particularmente sensível a erros de classificação. Só com base nisso é que se pode decidir entre uma transição completa ou a manutenção deliberada do sistema atual.

A escolha depende, portanto, menos do número de caixas de correio em si do que da capacidade de manutenção e das dependências. Quem puder assumir a responsabilidade permanente pelo Redis, pelo resolvedor de DNS, pela análise de protocolos e pelas atualizações poderá operar o Rspamd de forma consistente, incluindo as funções de aprendizagem e baseadas no estado. Na ausência destes recursos, um conjunto simplificado e bem documentado, com regras claras, pode representar o menor risco operacional.

Independentemente do produto, aplica-se o seguinte: não disponibilize o controlador Rspamd na rede sem proteção. A documentação recomenda uma ligação local ou proteção por firewall; no caso de acesso remoto, são necessárias medidas de proteção de acesso e um hash de palavra-passe. Além disso, não adote regras de terceiros nem pontuações históricas sem as verificar. Medições isoladas ou campanhas que chamem a atenção não constituem uma base para uma política de filtragem global.

A decisão certa é, portanto, uma Avaliação de riscos: A proteção contra mensagens indesejadas contrapõe-se às consequências da perda de e-mails legítimos. Defina, para cada ação, quem é o responsável, como é verificada e como se pode reverter para o estado anterior. Desta forma, o filtro de spam de e-mail continua a ser uma parte controlável do funcionamento do serviço de e-mail, em vez de uma instância automática difícil de compreender.