LeandroCarlosRodrigues

Boa noite pessoal. Estou trabalhando em um novo utilitário, semelhante ao spfquery, que é capaz de fazer outras verificações simultaneamente: https://github.com/leonamp/SPFBL/blob/master/client/spfbl.pl A ideia é integrar nossas listas públicas e também melhorar a resposta convencional do spfquery. Quem já estiver usando o spfquery, é bem fácil trocar porque o funcionamento de ambos é muito parecido. Esse utilitário resolve dois problemas ao mesmo tempo, que é a validação do SPF e consulta RBL. Estou testando ele em nossos servidores Exim e parece funcionar muito bem. Quem puder testar, me dê um feedback para eu poder fazer as correções necessárias e poder também melhorar as respostas deste utilitário, a fim dele atingir um alto grau de precisão e ajudar assim a comunidade a combater spam da melhor forma possível. Fico à disposição. Leandro SPFBL.net

Bom dia senhores. Algum de vocês tem experiência em desenvolvimento de plugin para WHM ou conhecem quem tenha?

Excelente. Faça um experimento com essa configuração aqui, pois ela mescla nossas listas publicas de uma forma mais inteligente e gera menos falsos positivos do que as consultas convencionais das listas separadas: https://spfbl.net/rspamd

Sensacional. Tamo junto!

Isso mesmo. Porém, para o evento na qual me refiro, ainda que você mande bloquear, o Gmail é incapaz de executar, porque o tal grupo hacker consegue forjar dados de identificação da mensagem, a fim de confundir o filtro do Gmail. E são muito eficazes nessa tarefa. Leia a matéria que você irá entender melhor o problema.

Esse problema ocorre apenas para alguns usuários do Gmail. Quando se inicia, então o usuário passa a receber uma avalanche de lixo tóxico, mesmo que peça para o Gmail bloquear. Suponho que o endereço do usuário tenha que ser descoberto, pelo grupo hacker que aplica o ataque, para que só então o tal evento se deflagre. Então minha solução não se aplica a seu caso.

Bom dia pessoal, Devido à enorme incompetência do Gmail nos últimos meses, em conseguir filtrar spam de uma forma satisfatória, eu decidi iniciar a pesquisa de desenvolvimento de um nova solução. Segue uma matéria que fala sobre o problema: https://www.businessinsider.com/gmail-spam-filter-problem-issue-2019-6 Estive testando essa solução por vários meses, que aparentemente vem surtindo efeito. O fluxo de spam em minha conta do Gmail vem caindo drasticamente, inclusive aqueles encaminhados para a pasta Junk. Porém, para eu ter certeza que a solução funciona, eu preciso de uma amostragem maior de usuários do Gmail. Para aqueles que forem usuários do Gmail, e quiserem obter mais informações sobre essa solução, me contate no privado por gentileza. Abraços, Leandro SPFBL.net

Disponha sempre que precisar!

Infelizmente, a solução não depende de uma medida do seu lado. Ela depende exclusivamente de uma medida do lado do cliente, mais especificamente na máquina dele. Você deve instruí-lo a instalar um antivirus bom ou então mandar formatar a máquina. Esses antivirus gratuitos podem não conseguir resolver pois o malware é polimórfico, onde ele se auto encripta e usa chaves de encriptação diferente a cada salto. Se ele não fosse polimórfico, daria para pegar pelo padrão de código fonte no script VB dentro do documento Word. Os antivirus bons conseguem visualizar o comportamento do script, rodando ele em uma sandbox e vendo se ele tenta executar o tal código malicioso. Pessoal. Nada disso vai resolver o problema pois, uma vez que o hacker tem acesso à máquina do usuário, os emails serão enviados com a autenticação e senha usada pelo próprio usuário naquele momento. Significa que seu servidor de email não é capaz de diferenciar os envios do usuário humano e os envios do bot, assinando assim o DKIM para ambos os casos. Quem recebe essas mensagens, também não é capaz de diferencia-los pelo DKIM nem pelo SPF.

Recomendo que você mande o cliente investigar sobre o ataque hacker, realizado por documentos de Word infectados, pois esse ataque permite a abertura de um backdoor, onde o hacker tem acesso ao sistema e todos os privilégios do usuário, inclusive credencial de SMTP dele. Significa que não resolve alterar a senha pois, uma vez que o hacker tem acesso à conta de SMTP do usuário, o malware dele irá usar a mesma autenticação de usuário para envio destes spams no seu servidor SMTP. Esse ataque já vem ocorrendo desde o ano passado e sua infecção se dá pelo envio de um documento Word, anexado em um email aparentemente inofensivo, aonde a abertura deste anexo faz o script rodar na máquina do destinatário e então o hacker ganha acesso a essa nova máquina, repetindo o processo pelo crescimento exponencial. Estamos presenciando grandes ondas desse ataque nessas ultimas semanas, de diversas contas de usuários e de diversos provedores. Não é um problema fácil de resolver e depende de instalação de bons antivírus nas máquinas dos usuários. Mais detalhes sobre essa vulnerabilidade: https://www.symantec.com/security_response/attacksignatures/detail.jsp?asid=28087

Excelente. Se você tivesse pegado o código fonte da mensagem na caixa postal do Google e o código fonte da mesma mensagem na caixa postal de outro serviço qualquer, veria que não eram idênticas. Por algum motivo desconhecido, sua configuração fez com que ficassem idênticas em ambos destinos.

Pode ser que minha explicação não ficou clara, então vou tentar simplificar. Uma vez que sua aplicação DKIM assina a mensagem original, ela vai gerar um hash desta mensagem para só então realizar a assinatura sobre este hash. Para que o sistema do destinatário consiga validar a sua assinatura DKIM, o hash da mensagem recebida tem que ser exatamente igual ao hash gerado pela aplicação que assinou a mesma. Se ambos os hashs não baterem, significa que a mensagem sofreu alguma alteração no trajeto entre o servidor de origem e o destino final. Resumindo. Lá no Google, o hash da mensagem recebida não bate com o hash da mensagem original, porque sofreu alteração no trajeto, enquanto que o hash dos demais destinos bate com o hash da mensagem original, porque sofreu nenhuma alteração no trajeto. Me perdoe se eu não consegui ser claro.

Para fazer validações paralelas, você deve coletar o código fonte da mensagem diretamente da interface do Google e então usar este mesmo código fonte na ferramenta de validação. Se você simplesmente testar a validação por envio direto, isso não implica que a mensagem recebida pelo Google não é válida porque o roteamento da mensagem pode ser diferente e essa diferença de rota é o que está causando a modificação desta. A chave para você resolver o problema é descobrindo porque a mensagem é modificada, quando enviada para o Google, mas não é modificada quando enviada para os demais. Essa modificação da mensagem é o único fato que conhecemos, pois o DKIM só funciona desta forma, com a mensagem original e sem modificações. Se resultar em FAIL, significa necessariamente que não se trata da mensagem original, exatamente com os mesmos bytes.

Disponha!

Perfeito. Tenta me mente que a mensagem foi alterada, necessariamente. Não tenho como te dizer o que está sendo alterado pois isso depende de investigação na sua infra. Eu só consigo te garantir que a mensagem está sendo alterada, mesmo que seja um único byte. Sacou?

Exatamente. O fato é que a mensagem não é alterada para estes casos, apenas para o Google. Por isso que suspeito de algum tipo de processo de forward. Tenha em mente que a mensagem não fica intacta somente para este ultimo caso, seja lá qual for a causa.

A validação do DKIM depende da mensagem ser mantida inalterada por todo processo de roteamento de mesma, byte por byte. No caso de algum nó modificar a mensagem, seja o corpo ou seja algum cabeçalho descrito no algoritmo, então a validação irá falhar no nó final. No seu caso, você diz que o Google dá como FAIL a validação do DKIM. Como eu tenho certeza que a validação de DKIM realizada pelo Google é perfeita, isso implica que algum nó alterou a mensagem no meio do caminho de roteamento da mensagem. Verifique se você está utilizando algum forward para seus destinatários e, no caso de existir tal nó de forward, investigue quais modificações esse nó faz na mensagem.

Bom dia. A mudança de HDD para SSD não explica o problema, então pode descartar essa hipótese. Recomendo você olhar se houve de fato alguma alteração de configuração do MTA durante o processo em questão, como alguma atualização do software por exemplo.

Bom dia pessoal, Estou passando aqui para avisá-los que os usuários do serviço DNSBL já podem reportar abusos como se fossem usuários da própria rede SPFBL. Nós preparamos o sistema para recepcionar e processar automaticamente esses relatórios de abuso, para que possamos intermediar o caso junto do administrador do sistema de envio, que receberá uma cópia do relatório de abuso e assim ele poder tomar as providências necessárias do lado dele. A ideia é incentivar o sistema de envio a parar os abusos também para os usuários da DNSBL. Nosso serviço foi preparado para processar mensagens anexadas com "Content-Type: message/rfc822", semelhante ao método usado pelo Spamcop, e assim facilitar a implementação do lado de vocês. Porém, esse serviço será restrito apenas para usuários cadastrados. Quem tiver interesse de usá-lo, me contacte em privado para receber os detalhes deste novo programa de abuse report. Um grande abraço, Leandro SPFBL.net

Isso mesmo. É necessário você me passar os ranges de IPv4 e IPv6 que seus MTAs utilizarão para se conectar em nosso serviço para que eu os cadastre aqui e assim o firewall abra o acesso para eles.

Se você tiver familiaridade com o Rspamd, tem uma configuração muito boa que um colega meu fez: https://spfbl.net/rspamd Isso não é a mesma coisa que você configurar o serviço SPFBL, que é bem mais preciso, mas pelo menos a vantagem é que você dependeria de mais ninguém. No caso de não ser familiarizado com o Rspamd, tem essas documentações para cada MTA que já conseguiram implementar para consultar o serviço SPFBL: https://github.com/leonamp/SPFBL/wiki/Integração-com-Postfix---SPFBL https://github.com/leonamp/SPFBL/wiki/Integração-com-Zimbra---SPFBL https://github.com/leonamp/SPFBL/wiki/Integração-com-Exim-SPFBL https://github.com/leonamp/SPFBL/wiki/Integração-com-Exim-do-cPanel---SPFBL https://github.com/leonamp/SPFBL/wiki/Integração-com-Dovecot---SPFBL

Pois eh. A gente acolhe todo mundo aqui, inclusive aqueles que não podem ajudar diretamente com as despesas. ?

O Jefferson utiliza o serviço SPFBL público não pago. Nesse caso, não damos acesso ao painel pois o painel consome muito recurso computacional então é impossível manter ele sem alguma receita correspondente. Ainda sim, mesmo sendo de acesso público, dá para manipular todas as listas de cliente pela linha de comando. Temos mais de 30 provedores usando o nosso serviço publico, e todos eles manipulam suas próprias listas sem problema algum.

Correção: o SPFBL permite que o cliente gerencie a sua própria whitelist.

Depois de uma longa pesquisa, descobri que é tecnicamente possível, mas não existe uma documentação apropriada para explicar isso. Teria que ler toda documentação de integração técnica do Rspamd e fazer as configurações cPanel na unha. Até queria mostrar aqui minha indignação, ao mantenedor do cPanel, pois tiverem coragem de implementar a porcaria do SpamAssassin ativo por default no cPanel, mas não fizeram o mesmo pelo Rspamd, que é muito melhor, ainda que fosse apenas um plugin para ser manualmente ativado. Se eu estiver errado, e os mantenedores implementarem o Rspamd como plugin do cPanel, então peço perdão antecipado por essa crítica incisiva aqui.