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

[Luiz Otavio Souza]

Renato Frederick escreveu:
>> Uso o pf e o spamd
>> (http://www.openbsd.org/cgi-bin/man.cgi?query=spamd&apropos=0&sektion=0&manpat
>> h=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...
>>     
>
> Mas o spamd vai se comunicar com o qmail backend?
>
> Por exemplo, os recursos que eu tenho no qmail backend ele vai respeitar? Ou
> ele vai ser um "burro de carga" aceitando qualquer coisa?
>
> Porque este é o maior problema com soluções de gateway que existem(até
> pagas), conforme falei.
>
> Não sei como ele funciona, mas seria bom que ele interagisse com o smtp que
> eu especifico, só entrando em ação depois que o cliente começou a jogar o
> email.
>
> Daí todos os patches que a gente tem, como spamcontrol, greyulist, etc etc
> ficariam ativos.
>
> Porque é muito chato usar uma solução que é passiva, recebe tudo da net e
> fica jogando pro qmail mensagem anonima.
>
>   
Ele trabalha baseado nas seguintes regras do pf:

table <spamd-white> persist
no rdr inet proto tcp from <spamd-white> to any port smtp
rdr pass inet proto tcp from any to any port smtp -> 127.0.0.1 port spamd


Ou seja quem o spamd ainda não identificou (ip do servidor) vai ser redirecionado para o greylist do spamd.

Quem já foi identificado simplesmente ignora o rdr. O spamd não é um proxy, as conexões direcionadas para ele sempre falham  temporariamente (451).

Depois de duas conexões no spamd do mesmo remente, destinatário e ip o spamd cria uma entrada na tabela spamd-white.

A solução é transparente, utiliza recursos mínimos e funciona muito bem com o pf.

luiz