Re: [FUG-BR] Bloquear Freebsd
Rafael Busetti escreveu: > Estive aqui pensando na lógica e me deparei com um problema, se eu der > um halt no sistema, ele irá prepara-lo para um reboot, porém preciso > de um tempo de espera para ele nao fazer a ação, poderia usar um Sleep > para dar uma pausa, porém é facilmente contornável usando um Ctrl + C > ... > > Talvez um bloqueio de teclado temporario ajude ? Alguem tem alguma sujestão? > > Obrigado! > Rafa > Nao se você colocar seu código depois da linha 46 do /etc/rc (trap ...) O trap ignora o ctrl + c (SIGINT) no /etc/rc, evitando que o processo de startup do SO possa ser cancelado. Exitem outras maneiras de fazer isso, mas ai já complica um pouco... Com C você faz um init(8) falso e tem o controle total do boot do seu sistema. luiz > Em 28/04/07, Rafael Busetti<[EMAIL PROTECTED]> escreveu: > >> Muito obrigado Luiz, >> >>Sim sem problemas, aheuiahe irei cuidar com isso, estou >> desenvolvendo meio que um "serial number" no sistema, só para não >> permitir a troca de hardware da máquina sem meu aval. >> >> >> Em 28/04/07, Luiz Otavio Souza<[EMAIL PROTECTED]> escreveu: >> >>> Rafael Busetti escreveu: >>> Na rede era só dar um deny all, tenho ipfw rodando, o tipo de bloqueio que eu quiz dizer é logo na inicialização do sistema, é bloquear o BSD mesmo, a máquina servidor que tem tudo configurado. Ele faz um teste e bloqueia a própria maquina. >>> Poe no /etc/rc: >>> >>> if [ -f /etc/maquina_travada ]; then >>> halt >>> fi >>> >>> Cria o arquivo /etc/maquina_travada e a maquina vai executar um halt >>> logo que ela começar a carregar. >>> >>> Espero que você tenha como apagar esse aquivo depois.. hehehe >>> >>> 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] [1/2 off] Qmail + dspam
Renato Frederick escreveu: > Tive o mesmo problema. > > Com menos de 500usuarios, uns 30dominios > a base do SQL passava de 3GB, um boot forçado no servidor era > motivo para um repair table/myisamchk :( > > estou usando > spamd+clamav+RBL+greylist+spamcontrol, prá dar uma segurada nos > spam. > > inte > Se a tabela chegar aos 4GB (limite máximo de um arquivo no ufs) ai você vai ver a dor de cabeça.. heheheh Eu nunca gostei do spamassassim por ser feito em perl (overhead) e ter um grande número de dependencias, mas com o spamc/spamd estou conseguindo utilizar o SA sem muitos problemas (embora ainda não goste muito do sistema de classificação dele...) O spamc deve ser executado atraves do qmail-queue e não nos .qmail da vida (cada mensagem que passa no qmail-queue pode se tornar várias mensagens já que ela será copiada para cada e-mail local que recebe a mensagem). Isso também ajuda a reduzir o overhead no servidor. Acredito que existam muitos programas que façam isso, mas se você tiver qualquer dificuldade tenho isso pronto aqui. Tenho o pf+spamd (greylist) no front de batalha e SA no qmail com smtp-auth, solução toska e razoavelmente eficaz. Acho que o spamcontrol oferece os melhores recursos na prevenção dos spams, mas infelizmente não é compatível a instalação atual do qmail que venho utilizando. Se eu conseguir reunir a massa critica necessária por aqui, a idéia é gerar substitutos para o qmail-smtpd e o qmail-queue, integrando todas as funcionalidades originais com as tecnicas corretas para se combater os spams (smtp-auth, verificação de dns/reverso, spf, domainkeys, greylist, tarpit, etc..) A idéia é ter alguma coisa compativel com o spamcontrol (recursos anti-spam e logs melhorados), mas sem patchs no qmail ! As vantagens são obvias, principalmente no greylist aonde não será necessário utilizar a porta 587 para envio de e-mails. O único problema até agora é fazer com que o sistema seja compativel com qualquer instalação do qmail (original, vpopmail, ldap), a única alteração no entanto é na autenticação e verificação de usuários (no big deal). Se isso vier a se concretizar, provavelmente não poderei mais dizer que uso o patch-qmail ;) luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: [1/2 off] Qmail + dspam
> > Se a tabela chegar aos 4GB (limite máximo de um arquivo no ufs) ai você > vai ver a dor de cabeça.. heheheh Pois > > Eu nunca gostei do spamassassim por ser feito em perl (overhead) e ter > um grande número de dependencias, mas com o spamc/spamd estou > conseguindo utilizar o SA sem muitos problemas (embora ainda não goste > muito do sistema de classificação dele...) > > O spamc deve ser executado atraves do qmail-queue e não nos .qmail da > vida (cada mensagem que passa no qmail-queue pode se tornar várias > mensagens já que ela será copiada para cada e-mail local que recebe a > mensagem). Isso também ajuda a reduzir o overhead no servidor. > > Acredito que existam muitos programas que façam isso, mas se você tiver > qualquer dificuldade tenho isso pronto aqui. > > Tenho o pf+spamd (greylist) no front de batalha e SA no qmail com > smtp-auth, solução toska e razoavelmente eficaz. > > Acho que o spamcontrol oferece os melhores recursos na prevenção dos > spams, mas infelizmente não é compatível a instalação atual do qmail > que > venho utilizando. > > Se eu conseguir reunir a massa critica necessária por aqui, a idéia é > gerar substitutos para o qmail-smtpd e o qmail-queue, integrando todas > as funcionalidades originais com as tecnicas corretas para se combater > os spams (smtp-auth, verificação de dns/reverso, spf, domainkeys, > greylist, tarpit, etc..) > > A idéia é ter alguma coisa compativel com o spamcontrol (recursos > anti-spam e logs melhorados), mas sem patchs no qmail ! > > As vantagens são obvias, principalmente no greylist aonde não será > necessário utilizar a porta 587 para envio de e-mails. > > O único problema até agora é fazer com que o sistema seja compativel > com > qualquer instalação do qmail (original, vpopmail, ldap), a única > alteração no entanto é na autenticação e verificação de usuários (no > big > deal). > > Se isso vier a se concretizar, provavelmente não poderei mais dizer que > uso o patch-qmail ;) > > luiz > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: [1/2 off] Qmail + dspam
Ops, o outro email foi errado, desculpem!!! > Se a tabela chegar aos 4GB (limite máximo de um arquivo no ufs) ai você > vai ver a dor de cabeça.. heheheh Pois é, por isto que já tirei o dito cujo da jogada, inclusive pro cliente poder acessar via WEB tinha que ativar uma opção no apache de autenticar via pop3, etc etc.. muito remendo... ou então eu que não soube como fazer. > > Eu nunca gostei do spamassassim por ser feito em perl (overhead) e ter > um grande número de dependencias, mas com o spamc/spamd estou > conseguindo utilizar o SA sem muitos problemas (embora ainda não goste > muito do sistema de classificação dele...) O perl é meio pesado mesmo, mas se você tiver muito tráfego, pode fazer um front-end ou então mandar o spamc perguntar a um spamd remoto, que fica só por conta. A classificação é meio enjoada, mas com as regras brasileiras e usando imap e mandando os usuários ajudarem você a classificar spam/ham dá bons resultados. > > O spamc deve ser executado atraves do qmail-queue e não nos .qmail da > vida (cada mensagem que passa no qmail-queue pode se tornar várias > mensagens já que ela será copiada para cada e-mail local que recebe a > mensagem). Isso também ajuda a reduzir o overhead no servidor. Eu costumo usar no .qmail do usuario, pelo qmailadmin na opção "filtro de spam". Assim, o usuario terá o email encaminhado para uma pasta "SPAM", e só cairá no spamc mensagens efetivamente validas, após terem sido passadas pelo antivírus, pelo spamcontrol, pelas rbl e etc etc. Alem disso dou o controle do próprio usuário ativar ou não seu spam. > > Acredito que existam muitos programas que façam isso, mas se você tiver > qualquer dificuldade tenho isso pronto aqui. Quais programas? Perdi o "fio da meada" > > Tenho o pf+spamd (greylist) no front de batalha e SA no qmail com > smtp-auth, solução toska e razoavelmente eficaz. Bacana, aqui com muito tráfego divido os servidores, um para webmail, um para qmail, um para spamd e por ai vai. > > Acho que o spamcontrol oferece os melhores recursos na prevenção dos > spams, mas infelizmente não é compatível a instalação atual do qmail > que > venho utilizando. O port do garga atualmente "quebrou um galho" já deixando o qmail pronto para ser usado, mas alguns casos ainda não dá mesmo :( > > Se eu conseguir reunir a massa critica necessária por aqui, a idéia é > gerar substitutos para o qmail-smtpd e o qmail-queue, integrando todas > as funcionalidades originais com as tecnicas corretas para se combater > os spams (smtp-auth, verificação de dns/reverso, spf, domainkeys, > greylist, tarpit, etc..) O Patrick se não me engano, estava querendo fazer um módulo pro qmail que chamaria qualquer programa externo sem patch. O exemplo atual disto é o softfail, não sei se isto poderia lhe ajudar já/. > > A idéia é ter alguma coisa compativel com o spamcontrol (recursos > anti-spam e logs melhorados), mas sem patchs no qmail ! > > As vantagens são obvias, principalmente no greylist aonde não será > necessário utilizar a porta 587 para envio de e-mails. > > O único problema até agora é fazer com que o sistema seja compativel > com > qualquer instalação do qmail (original, vpopmail, ldap), a única > alteração no entanto é na autenticação e verificação de usuários (no > big > deal). > Verifica se o que o Patrick fez pode lhe atender ou você basear no sistema dele. > Se isso vier a se concretizar, provavelmente não poderei mais dizer que > uso o patch-qmail ;) > A vantage do qmaileh esta modularidade, tão criticada por outros NE hehee > luiz > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [1/2 off] Qmail + dspam
Renato Frederick escreveu: > Tive o mesmo problema. > > Com menos de 500usuarios, uns 30dominios > a base do SQL passava de 3GB, um boot forçado no servidor era > motivo para um repair table/myisamchk :( > Atualmente chamo tanto o SA quando o clamav via simscan. Fiquei feliz quando saiu a versão 3.1.3 que tem o dspam integrado. Pelo visto, não vai me ajudar muito :( > estou usando > spamd+clamav+RBL+greylist+spamcontrol, prá dar uma segurada nos > spam. > O que você esta usando para greylist? Como integrou com o qmail? No caso da base greylist, você teve algum problema de tamanho também? Eu uso atualmente o qmail-ldap e não encontro uma solução de greylist que seja integrada com ele. Um das coisas que fica ruim usando o SA é que, ao enviar um e-mail autenticado, ele demora bem mais para enviar do que quando libero um determinado IP fixo. []s, 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] [1/2 off] Qmail + dspam
Luiz Otavio Souza escreveu: > Renato Frederick escreveu: > >> Tive o mesmo problema. >> >> Com menos de 500usuarios, uns 30dominios >> a base do SQL passava de 3GB, um boot forçado no servidor era >> motivo para um repair table/myisamchk :( >> >> estou usando >> spamd+clamav+RBL+greylist+spamcontrol, prá dar uma segurada nos >> spam. >> >> inte >> >> > > Se a tabela chegar aos 4GB (limite máximo de um arquivo no ufs) ai você > vai ver a dor de cabeça.. heheheh > > Eu nunca gostei do spamassassim por ser feito em perl (overhead) e ter > um grande número de dependencias, mas com o spamc/spamd estou > conseguindo utilizar o SA sem muitos problemas (embora ainda não goste > muito do sistema de classificação dele...) > > O spamc deve ser executado atraves do qmail-queue e não nos .qmail da > vida (cada mensagem que passa no qmail-queue pode se tornar várias > mensagens já que ela será copiada para cada e-mail local que recebe a > mensagem). Isso também ajuda a reduzir o overhead no servidor. > > Acredito que existam muitos programas que façam isso, mas se você tiver > qualquer dificuldade tenho isso pronto aqui. > Eu agradeço se você passar como usa. Atualmente chamo o SA via simscan. > Tenho o pf+spamd (greylist) no front de batalha e SA no qmail com > smtp-auth, solução toska e razoavelmente eficaz. > Do que estou entendo são dois servidores, correto? Esse front é openbsd? > Acho que o spamcontrol oferece os melhores recursos na prevenção dos > spams, mas infelizmente não é compatível a instalação atual do qmail que > venho utilizando. > Vc esta usando o qmail em que base para autenticar? Estou usando o qmail-ldap, mas algumas vezes, tenho encontro dificuldades em integrar com alguns softwares de spam, por exemplo. > Se eu conseguir reunir a massa critica necessária por aqui, a idéia é > gerar substitutos para o qmail-smtpd e o qmail-queue, integrando todas > as funcionalidades originais com as tecnicas corretas para se combater > os spams (smtp-auth, verificação de dns/reverso, spf, domainkeys, > greylist, tarpit, etc..) > > A idéia é ter alguma coisa compativel com o spamcontrol (recursos > anti-spam e logs melhorados), mas sem patchs no qmail ! > Interessante. Eu ainda estou procurando uma solução ideal. []s, 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: [1/2 off] Qmail + dspam
Renato Frederick escreveu: > Ops, o outro email foi errado, desculpem!!! > > >> Se a tabela chegar aos 4GB (limite máximo de um arquivo no ufs) ai você >> vai ver a dor de cabeça.. heheheh >> > > Pois é, por isto que já tirei o dito cujo da jogada, inclusive pro cliente > poder acessar via WEB tinha que ativar uma opção no apache de autenticar via > pop3, etc etc.. muito remendo... ou então eu que não soube como fazer. > 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 nunca gostei do spamassassim por ser feito em perl (overhead) e ter >> um grande número de dependencias, mas com o spamc/spamd estou >> conseguindo utilizar o SA sem muitos problemas (embora ainda não goste >> muito do sistema de classificação dele...) >> > > O perl é meio pesado mesmo, mas se você tiver muito tráfego, pode fazer um > front-end ou então mandar o spamc perguntar a um spamd remoto, que fica só > por conta. > mas aqui, se estamos falando de dois servidores, acredito que usando um front end com pf+spamd fica mais robusto. ou não? > A classificação é meio enjoada, mas com as regras brasileiras e usando imap > e mandando os usuários ajudarem você a classificar spam/ham dá bons > resultados. > 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. > >> O spamc deve ser executado atraves do qmail-queue e não nos .qmail da >> vida (cada mensagem que passa no qmail-queue pode se tornar várias >> mensagens já que ela será copiada para cada e-mail local que recebe a >> mensagem). Isso também ajuda a reduzir o overhead no servidor. >> > > Eu costumo usar no .qmail do usuario, pelo qmailadmin na opção "filtro de > spam". Assim, o usuario terá o email encaminhado para uma pasta "SPAM", e só > cairá no spamc mensagens efetivamente validas, após terem sido passadas pelo > antivírus, pelo spamcontrol, pelas rbl e etc etc. > Alem disso dou o controle do próprio usuário ativar ou não seu spam. > > >> Acredito que existam muitos programas que façam isso, mas se você tiver >> qualquer dificuldade tenho isso pronto aqui. >> > > Quais programas? Perdi o "fio da meada" > > >> Tenho o pf+spamd (greylist) no front de batalha e SA no qmail com >> smtp-auth, solução toska e razoavelmente eficaz. >> > > Bacana, aqui com muito tráfego divido os servidores, um para webmail, um > para qmail, um para spamd e por ai vai. > Hum. Estou precisando fazer isso por aqui. >> Acho que o spamcontrol oferece os melhores recursos na prevenção dos >> spams, mas infelizmente não é compatível a instalação atual do qmail >> que >> venho utilizando. >> > > O port do garga atualmente "quebrou um galho" já deixando o qmail pronto > para ser usado, mas alguns casos ainda não dá mesmo :( > > > >> Se eu conseguir reunir a massa critica necessária por aqui, a idéia é >> gerar substitutos para o qmail-smtpd e o qmail-queue, integrando todas >> as funcionalidades originais com as tecnicas corretas para se combater >> os spams (smtp-auth, verificação de dns/reverso, spf, domainkeys, >> greylist, tarpit, etc..) >> > > O Patrick se não me engano, estava querendo fazer um módulo pro qmail que > chamaria qualquer programa externo sem patch. O exemplo atual disto é o > softfail, não sei se isto poderia lhe ajudar já/. > Isso me parece interessante. Hoje não consigo adicionar alguns softwares de greylist que encontrei. []s, Luiz Morte. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Raid5 Fase 2
rapazeada consegui montar o raid5 com o gvinum seguindo umas dicas de um forum, porem somente funciona com 3 discos, eu possuo 6 discos se eu acrecento mais do que 3 esta dando erro. procedimento faco isso para cada disoc. dd if=/dev/zero of=/dev/ad10 bs=1k count=20 fdisk -I /dev/ad10 if=/dev/zero of=/dev/ad10s1 bs=32k count=16 bsdlabel -w ad10s1 auto No arquivio de configuracao raid5.conf drive disk_ad1 device /dev/ad6s1a drive disk_ad2 device /dev/ad7s1a drive disk_ad3 device /dev/ad10s1a volume raid5 plex org raid5 256k sd length 102M drive disk_ad1 sd length 102M drive disk_ad2 sd length 102M drive disk_ad3 Aqui seu adiciono mais um disco da erro na hora de criar. gvinum create /etc/raid5.conf Alguem pode me ajudar, nas controladoras de hadware para raid, tambem so suporta 4 discos eu precisso que funcione em 6, nao acho material disso. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Bloquear Freebsd
Em 28/04/07, Rafael Busetti<[EMAIL PROTECTED]> escreveu: > cada computador com seu > determinado hardware tem um Serial Number, se for adicionado algum > hardware novo ao computador, este serial será diferente Essa parte você já conseguiu fazer? Se sim me diga como. -- Uma informação por dia, leva ao sábio sabedoria. There will be a day machines will reign, and only the ones able to understand them will survive. Freebsd Br-User Registered #371 Hugo Pessoa/NgD Vulto. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Bloquear Freebsd
vou ver as sujestões do pessoal aqui e depois posto com qual tive sucesso ... amigo sobre o serial de uma olhada no dmidecode =) Um abraço! Em 29/04/07, NgD Vulto<[EMAIL PROTECTED]> escreveu: > Em 28/04/07, Rafael Busetti<[EMAIL PROTECTED]> escreveu: > > cada computador com seu > > determinado hardware tem um Serial Number, se for adicionado algum > > hardware novo ao computador, este serial será diferente > > Essa parte você já conseguiu fazer? Se sim me diga como. > > -- > Uma informação por dia, leva ao sábio sabedoria. > > There will be a day machines will reign, and only the ones able to > understand them will survive. > > Freebsd Br-User Registered #371 > > Hugo Pessoa/NgD Vulto. > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: RES: [1/2 off] Qmail + dspam
Olá Luiz! > > > 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. Talvez, como eu falei, eu fiz algo errado, mas não sei, fiz tudo que o Google mandou hehehee. > > > 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. > 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. > > > 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
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
[FUG-BR] RES: RES: RES: [1/2 off] Qmail + dspam
> 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? Sim, ele é um servidor qmail como se fosse "smarthost". Só que se ele ficasse sem nenhum filtro spamcontrol, ele iria processar muito email inválido. Este é o maior problema com as soluções até pagas que existem no mercado. O gateway da Norton é assim por exemplo, para manter compatibilidade desde um Exchange até um Novell, aceita tudo e depois repassa pro qmail ou seja lá o que você usa. Imagina o tanto de email facilmente descartado com simples verificações na sessão smtp que você processa(que vem de endereços sem dns reverso, que vem de IP adsl) A solução que encontrei foi instalar um qmail/spamcontrol e deixar neste só o spamassassin, mas checando usuários válidos, compartilhando a base mysql(em um servidor dedicado). Daí entrega pra outro servidor, que só faz o pop/imap. O webmail em outro Etc etc O tanto de servidor que precisa depende da carga do usuário. Talvez pode-se usar o mysql no mesmo servidor que o pop, mas se o pessoal usar muito webmail(provedor de internet por exemplo), o apache teria que ficar em outra máquina, etc etc Usar só um qmail+spamc e um smtproutes jogando pro servidor qmail valido iria deixar o frontend sobrecarregado rapidamente! > 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. Sim, no spamcontrol também. O ideal é enviar pro clamav/spam o mínimo de email, tentar barrar antes do "data" o Maximo de email considerado inválido. Creio que o caminho de deixar o servidor mais leve é este. > O que eu procuro é um software tipo simscan que chame um greylist. > Ainda > não encontrei. O extodo faz isto, na variável do smtp/run você chama um programa de terceiro, mas não tive tempo de ler como funciona esta implementação nem o patch greylist. > 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 :) Sim, ele baseia a ideia no seguinte, se o spammer usa um programa pra conectar a milhares de servidores, quanto menos tempo ele esperar a resposta de cada um melhor, afinal ele que é quantidade. Então parte da premissa que o bot que o spammer usa não vai esperar, vamos supor, 40segundos pra começar a digitar o "mail to" depois do "helo" fake. Eu uso mas somente dos servidors de entrada. Muita gente usa o mesmo smtp para acesso de clientes e recebimento externo. Isso com smtp de cliente é terrível, o Outlook fica falando que a sessão foi desconectada, que houve um erro.. imagina o desespero :) Normalmente rodo na porta 587 o smtp dos clientes, com menos verificações(mas smtp autenticado) e esta e outras diversas flags do spamcontrol habilitadas! - 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: RES: [1/2 off] Qmail + dspam
Opa Renato, Renato Frederick escreveu: > > Sim, ele é um servidor qmail como se fosse "smarthost". Só que se ele > ficasse sem nenhum filtro spamcontrol, ele iria processar muito email > inválido. Este é o maior problema com as soluções até pagas que existem no > mercado. > > O gateway da Norton é assim por exemplo, para manter compatibilidade desde > um Exchange até um Novell, aceita tudo e depois repassa pro qmail ou seja lá > o que você usa. Imagina o tanto de email facilmente descartado com simples > verificações na sessão smtp que você processa(que vem de endereços sem dns > reverso, que vem de IP adsl) > Como você filtra, por exemplo os IP de adsl? Na versão nova do simscan, eles estão incluindo o p0f. Muito legal para filtrar emails que vem, por exemplo, de máquinas windows. Logicamente temos o problema de windows legítimo enviando mensagens, mas estava sendo tratado isso. Bem interessante se pensar que muitas máquinas invadidas são windows comuns. [...] >> 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 :) >> > > Sim, ele baseia a ideia no seguinte, se o spammer usa um programa pra > conectar a milhares de servidores, quanto menos tempo ele esperar a resposta > de cada um melhor, afinal ele que é quantidade. > Então parte da premissa que o bot que o spammer usa não vai esperar, vamos > supor, 40segundos pra começar a digitar o "mail to" depois do "helo" fake. > > > Eu uso mas somente dos servidors de entrada. Muita gente usa o mesmo smtp > para acesso de clientes e recebimento externo. > Interessante saber. Vou testar isso também :) []s, Luiz Morte. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
