[FUG-BR] RES: [1/2 off] Qmail + dspam

Luiz Morte morte em chsti.com
Domingo Abril 29 13:45:52 BRT 2007


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.


Mais detalhes sobre a lista de discussão freebsd