Re: [FUG-BR] RES: RES: [1/2 off] Qmail + dspam
Renato Frederick escreveu: (...) mas aqui, se estamos falando de dois servidores, acredito que usando um front end com pf+spamd fica mais robusto. ou não? Nunca testei esta solução, não tenho cenário para testá-la. Separando o spamd/spamc e os serviços imap/pop e afins deu certo para mim, mas pode ser uma boa o PF+spamd sim! A vantagem no meu caso é que, usando um frontend qmail em cada serviço, todas as verificações do spamcontrol são feitas. Eu poderia fazer um frontend do dspam, mas eu iria processar muito lixo, afinal ele não verifica NADA que o spamcontrol/rbl/greylist faz. Ele é um Proxy smtp, vamos dizer assim.. Não sei se o PF/spamd diminuiria o lixo recebido, se poderia usá-lo para conversar com o qmail. O ideal é que o sofware antispam entrasse no meio da conversação smtp, depois que o cliente desse o comando DATA [email] [CR,.CR] Aí ele deixou o qmail fazer todas as verificações smtp e só escaneou o conteudo do [email]. O software que eu conheço que se integra razoavelmente bem assim é o trend(pago). Daí não precisamos fazer muita peripécia prá funcionar, pois ele só entra em ação depois que o cliente começa a dar os comandos do email. Uso o pf e o spamd (http://www.openbsd.org/cgi-bin/man.cgi?query=spamdapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=html) que esta no ports (/usr/ports/mail/spamd) no front-end para fazer o greylist. Todos os spams com remetentes e/ou destinatários aleatórios param nele (no firewall... no pf) e não consomem qualquer recurso do servidor de e-mail propriamente dito. No meu caso o número de spams bloqueados no greylist do spamd é significativo e mantém a baixa carga no servidor de e-mail. O problema é que como o spamd é um sistema autonomo é não sabe quem são meus clientes (ele não suporta auth). Para resolver isso tenho outro qmail-auth na porta 587 e quando há ip disponivel utilizo um ip para o mx (servidor-servidor) que roda o greylist e outro para o envio de mensagens via smtp (cliente-servidor). Fácil configuração e zero manutenção, sem regras, sem treinamento... Esse é um dos problemas que tenho com o SA. Os usuários usam apenas pop3. Para ensinar novos spam, so pedindo para salvar a mensagem (pelo menos não conheço outra forma). Aqui o dspam com a história de assinaturas, ajuda bastante. Com certeza, usuário tem que ajudar hehehe. Você pode criar caixas spam/nospam e pedir pra eles encaminharem a mensagem. O problema é que muitos Outlook Express que existem por aí apagam o cabeçalho, alteram, etc etc, assim a classificação não fica perfeita. A assinatura dele resolve isto, mas tem um problema. Por exemplo, se você envia uma mensagem criptografada ou assinada digitalmente, ele vai anexá-la ao corpo do email atual, afinal ele não pode abrir a mensagem assinada :) Alguns usuários ficam doidos com isto. Colocar a assinatura no header remete ao mesmo problema, alguns clients e de email comem o cabeçalho. Sim... Voce pode configurar o courier-imap (/usr/local/etc/courier-imap/imapd) para enviar os e-mails assim que você os copia para uma caixa imap específica (Outbox na configuração padrão). Certa vez para resolver esse problema, modifiquei o courier-imap para reconhecer duas novas caixas imap (spam e nospam) e quando alguma mensagem era copiada para la eu utilizava esse recurso para treinar o filtro. Durante a copia não havia esse problema da alteração dos cabeçalhos e o treinamento passou a ser bem mais efetivo. luiz Isso me parece interessante. Hoje não consigo adicionar alguns softwares de greylist que encontrei. O patch exttodo pode resolver(no port do qmail/spamcontrol do garga). Atualmente ele é usado, no tutorial da FUG, para chamar o greylist da freebsdbrasil. Você poderia chamar qualquer programa com ele, teoricamente. Talvez este seja o caminho prá modularizar o qmail hehehe - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: RES: [1/2 off] Qmail + dspam
Uso o pf e o spamd (http://www.openbsd.org/cgi-bin/man.cgi?query=spamdapropos=0sektion=0manpat h=OpenBSD+Currentarch=i386format=html) que esta no ports (/usr/ports/mail/spamd) no front-end para fazer o greylist. Todos os spams com remetentes e/ou destinatários aleatórios param nele (no firewall... no pf) e não consomem qualquer recurso do servidor de e-mail propriamente dito. No meu caso o número de spams bloqueados no greylist do spamd é significativo e mantém a baixa carga no servidor de e-mail. O problema é que como o spamd é um sistema autonomo é não sabe quem são meus clientes (ele não suporta auth). Para resolver isso tenho outro qmail-auth na porta 587 e quando há ip disponivel utilizo um ip para o mx (servidor-servidor) que roda o greylist e outro para o envio de mensagens via smtp (cliente-servidor). Fácil configuração e zero manutenção, sem regras, sem treinamento... Mas o spamd vai se comunicar com o qmail backend? Por exemplo, os recursos que eu tenho no qmail backend ele vai respeitar? Ou ele vai ser um burro de carga aceitando qualquer coisa? Porque este é o maior problema com soluções de gateway que existem(até pagas), conforme falei. Não sei como ele funciona, mas seria bom que ele interagisse com o smtp que eu especifico, só entrando em ação depois que o cliente começou a jogar o email. Daí todos os patches que a gente tem, como spamcontrol, greyulist, etc etc ficariam ativos. Porque é muito chato usar uma solução que é passiva, recebe tudo da net e fica jogando pro qmail mensagem anonima. Sim... Voce pode configurar o courier-imap (/usr/local/etc/courier-imap/imapd) para enviar os e-mails assim que você os copia para uma caixa imap específica (Outbox na configuração padrão). Certa vez para resolver esse problema, modifiquei o courier-imap para reconhecer duas novas caixas imap (spam e nospam) e quando alguma mensagem era copiada para la eu utilizava esse recurso para treinar o filtro. Durante a copia não havia esse problema da alteração dos cabeçalhos e o treinamento passou a ser bem mais efetivo. Com certeza, resolve todos os problemas, fiz uma shell que varre o spam e nospam e joga pro spamassassin, mas a questão é quando o cliente ainda usa só pop3 !!! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: RES: [1/2 off] Qmail + dspam
Renato Frederick escreveu: Uso o pf e o spamd (http://www.openbsd.org/cgi-bin/man.cgi?query=spamdapropos=0sektion=0manpat h=OpenBSD+Currentarch=i386format=html) que esta no ports (/usr/ports/mail/spamd) no front-end para fazer o greylist. Todos os spams com remetentes e/ou destinatários aleatórios param nele (no firewall... no pf) e não consomem qualquer recurso do servidor de e-mail propriamente dito. No meu caso o número de spams bloqueados no greylist do spamd é significativo e mantém a baixa carga no servidor de e-mail. O problema é que como o spamd é um sistema autonomo é não sabe quem são meus clientes (ele não suporta auth). Para resolver isso tenho outro qmail-auth na porta 587 e quando há ip disponivel utilizo um ip para o mx (servidor-servidor) que roda o greylist e outro para o envio de mensagens via smtp (cliente-servidor). Fácil configuração e zero manutenção, sem regras, sem treinamento... Mas o spamd vai se comunicar com o qmail backend? Por exemplo, os recursos que eu tenho no qmail backend ele vai respeitar? Ou ele vai ser um burro de carga aceitando qualquer coisa? Porque este é o maior problema com soluções de gateway que existem(até pagas), conforme falei. Não sei como ele funciona, mas seria bom que ele interagisse com o smtp que eu especifico, só entrando em ação depois que o cliente começou a jogar o email. Daí todos os patches que a gente tem, como spamcontrol, greyulist, etc etc ficariam ativos. Porque é muito chato usar uma solução que é passiva, recebe tudo da net e fica jogando pro qmail mensagem anonima. Ele trabalha baseado nas seguintes regras do pf: table spamd-white persist no rdr inet proto tcp from spamd-white to any port smtp rdr pass inet proto tcp from any to any port smtp - 127.0.0.1 port spamd Ou seja quem o spamd ainda não identificou (ip do servidor) vai ser redirecionado para o greylist do spamd. Quem já foi identificado simplesmente ignora o rdr. O spamd não é um proxy, as conexões direcionadas para ele sempre falham temporariamente (451). Depois de duas conexões no spamd do mesmo remente, destinatário e ip o spamd cria uma entrada na tabela spamd-white. A solução é transparente, utiliza recursos mínimos e funciona muito bem com o pf. luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: RES: [1/2 off] Qmail + dspam
Em 30/04/07, Luiz Otavio Souza[EMAIL PROTECTED] escreveu: Renato Frederick escreveu: Uso o pf e o spamd (http://www.openbsd.org/cgi-bin/man.cgi?query=spamdapropos=0sektion=0manpat h=OpenBSD+Currentarch=i386format=html) que esta no ports (/usr/ports/mail/spamd) no front-end para fazer o greylist. Todos os spams com remetentes e/ou destinatários aleatórios param nele (no firewall... no pf) e não consomem qualquer recurso do servidor de e-mail propriamente dito. No meu caso o número de spams bloqueados no greylist do spamd é significativo e mantém a baixa carga no servidor de e-mail. O problema é que como o spamd é um sistema autonomo é não sabe quem são meus clientes (ele não suporta auth). Para resolver isso tenho outro qmail-auth na porta 587 e quando há ip disponivel utilizo um ip para o mx (servidor-servidor) que roda o greylist e outro para o envio de mensagens via smtp (cliente-servidor). Fácil configuração e zero manutenção, sem regras, sem treinamento... Mas o spamd vai se comunicar com o qmail backend? Por exemplo, os recursos que eu tenho no qmail backend ele vai respeitar? Ou ele vai ser um burro de carga aceitando qualquer coisa? Porque este é o maior problema com soluções de gateway que existem(até pagas), conforme falei. Não sei como ele funciona, mas seria bom que ele interagisse com o smtp que eu especifico, só entrando em ação depois que o cliente começou a jogar o email. Daí todos os patches que a gente tem, como spamcontrol, greyulist, etc etc ficariam ativos. Porque é muito chato usar uma solução que é passiva, recebe tudo da net e fica jogando pro qmail mensagem anonima. Ele trabalha baseado nas seguintes regras do pf: table spamd-white persist no rdr inet proto tcp from spamd-white to any port smtp rdr pass inet proto tcp from any to any port smtp - 127.0.0.1 port spamd Ou seja quem o spamd ainda não identificou (ip do servidor) vai ser redirecionado para o greylist do spamd. Quem já foi identificado simplesmente ignora o rdr. O spamd não é um proxy, as conexões direcionadas para ele sempre falham temporariamente (451). Depois de duas conexões no spamd do mesmo remente, destinatário e ip o spamd cria uma entrada na tabela spamd-white. A solução é transparente, utiliza recursos mínimos e funciona muito bem com o pf. Oi, apenas para complementar, um detalhe que passei um trabalho por aqui. Para manutenir a tabela spamd-white ele também verifica logs de pass na porta 25 no pflog0. Logo, é importante logar as conexões ao servidor smtp depois que passaram pelo greylist. Abs -- Aristeu Gil Alves Jr - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: RES: [1/2 off] Qmail + dspam
Renato Frederick escreveu: Olá Luiz! Opa Renato, La se vai minha idéia de colocar em produção o dspam. O engraçado é que na documentação dele, existe uma solução com 300k caixas postais (se não me engano). Fico imaginando então a estrutura para isso tudo. Eu também fiquei muito impressionado com o site deles, mas não entendi qual a implementação que usaram. Sei que no .qmail de cada usuário, a base crescia muito. Mas a classificação era aceitável, mas, no meu caso, nada tão melhor que o spamd. Quando vc fala spamd, esta se referendo ao daemon do SA, correto? Talvez, como eu falei, eu fiz algo errado, mas não sei, fiz tudo que o Google mandou hehehee. Fui por ai também, mas tentei ensinar ele de acordo com que o SA sabe. So que nem deu tempo de colocar em produção. Tive problemas com acesso ao mysql, pois tinha muitos processos para entrega de mensagens, mesmo com o número de mensagens chegando baixo. mas aqui, se estamos falando de dois servidores, acredito que usando um front end com pf+spamd fica mais robusto. ou não? Nunca testei esta solução, não tenho cenário para testá-la. Separando o spamd/spamc e os serviços imap/pop e afins deu certo para mim, mas pode ser uma boa o PF+spamd sim! A vantagem no meu caso é que, usando um frontend qmail em cada serviço, todas as verificações do spamcontrol são feitas. Quando você fala frontend qmail, você esta dizendo que tem um servidor antes apenas para filtro e este envia internamente para o teu servidor principal. É isso? Eu poderia fazer um frontend do dspam, mas eu iria processar muito lixo, afinal ele não verifica NADA que o spamcontrol/rbl/greylist faz. Ele é um Proxy smtp, vamos dizer assim.. Não sei se o PF/spamd diminuiria o lixo recebido, se poderia usá-lo para conversar com o qmail. O ideal é que o sofware antispam entrasse no meio da conversação smtp, depois que o cliente desse o comando DATA [email] [CR,.CR] Aí ele deixou o qmail fazer todas as verificações smtp e só escaneou o conteudo do [email]. Acredito que a idéia do qmail-ldap é mais ou menos assim (me corrijam se estiver errado). Existem várias checagem antes de entregar a mensagem para, no meu caso, o simscan. Este faz a verificação no SA e no clamav, retornando a mensagem ao qmail. O que eu procuro é um software tipo simscan que chame um greylist. Ainda não encontrei. O software que eu conheço que se integra razoavelmente bem assim é o trend(pago). Daí não precisamos fazer muita peripécia prá funcionar, pois ele só entra em ação depois que o cliente começa a dar os comandos do email. Esse é um dos problemas que tenho com o SA. Os usuários usam apenas pop3. Para ensinar novos spam, so pedindo para salvar a mensagem (pelo menos não conheço outra forma). Aqui o dspam com a história de assinaturas, ajuda bastante. Com certeza, usuário tem que ajudar hehehe. Você pode criar caixas spam/nospam e pedir pra eles encaminharem a mensagem. O problema é que muitos Outlook Express que existem por aí apagam o cabeçalho, alteram, etc etc, assim a classificação não fica perfeita. A assinatura dele resolve isto, mas tem um problema. Por exemplo, se você envia uma mensagem criptografada ou assinada digitalmente, ele vai anexá-la ao corpo do email atual, afinal ele não pode abrir a mensagem assinada :) Alguns usuários ficam doidos com isto. Colocar a assinatura no header remete ao mesmo problema, alguns clients e de email comem o cabeçalho. hum. Ai não da para confiar muito. Bem colocado. Isso me parece interessante. Hoje não consigo adicionar alguns softwares de greylist que encontrei. O patch exttodo pode resolver(no port do qmail/spamcontrol do garga). Atualmente ele é usado, no tutorial da FUG, para chamar o greylist da freebsdbrasil. Você poderia chamar qualquer programa com ele, teoricamente. Talvez este seja o caminho prá modularizar o qmail hehehe Vou dar uma olhada. Se alguém tiver mais detalhes aqui e puder explicar melhor, agradeço :) Aproveitando a mensagem, vc já usou o SMTP HELO/EHLO Greeting delay? Fiz algumas buscar e vi isso em http://www.fehcom.de/qmail/qmail.html A idéia parece muito legal, mas não sei como fica na prática. Também agradeço se alguém da lista comentar a respeito :) []s, Luiz Morte. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
