> 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
