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

[Aristeu Gil Alves Jr]

Em 30/04/07, Luiz Otavio Souza<luiz em visualconnect.com.br> escreveu:
>
>
> 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.

Oi, apenas para complementar, um detalhe que passei um trabalho por
aqui. Para manutenir a tabela spamd-white ele também verifica logs de
pass na porta 25 no pflog0. Logo, é importante logar as conexões ao
servidor smtp depois que passaram pelo greylist.

Abs
-- 
Aristeu Gil Alves Jr