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

[Renato Frederick]

> 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!