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

[Luiz Otavio Souza]

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=spamd&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=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
>
>
>