[MASOCH-L] fornecedores de ferramentas e serviços antispam

[Leandro Carlos Rodrigues]

Em 16/09/2015 11:21, Otavio Augusto escreveu:
> Leandro,
> Estou com 4 servidores (geograficamente separados com dominios
> diferentes ) para colocar com o SPFBL.
> Vi na documentação e acompanhado esta lista entendi o funciobnamento.
> Mas ai vai uma coisa que eu gostaria e inclusive me ofereço para
> ajudar a desenvolver e testar.

Maravilha Otavio. Precisamos mesmo de ajuda. Uma divisão das tarefas 
seria o ideal.

Você consegue montar um servidor SPFBL em qualquer um destes locais e 
direcionar as consultas dos 4 MX para ele.

Eu posso te passar todas as informações necessárias para fazer isso 
acontecer.

Nossa VM de 1CPU e 1GB de memória é capaz de dar conta de 1 milhão de 
consultas por dia então hardware não será problema para você.

> O sistema trabalhar com vizinho de de consultas semelhante ao recurso
> de parent proxy do squid cache :  Cada servidor conhecera seu parente
> através de configuração manual ou com a distribuição de um catalogo de
> parentes conhecidos , opção para autenticação, eles comunicarão entre
> si através de uma porta específica.

Olha só. O SPFBL já faz isso, porem sem autenticação. Achei que uma 
autenticação faria o processo todo ficar mais complexo e com alta latência.

A ideia é que cada servidor SPFBL "troque figurinhas" como os demais 
através de pacotes UDP. Cada pacote UDP carrega "uma figurinha". É mais 
fácil desta forma pois não precisa de confirmação de recebimento do 
pacote e a eventual perda do pacote gera nenhum prejuízo.

> Consultas, quando um cliente ( servidor de email: Postfix, Exim,
> Qmail, Sendmail, etc.) fizer uma consulta ao servidor conhecido o
> servidor irá verificar se há algo no seu cache internet de acordo com
> a especificação que ja existe ) se não ele irá consultar seus parentes
> conhecidos que irão retornar uma reposta baseada no seu cache
> internet, exceto withlist, caso contrario ira retorna uma resposta
> nula,

Na verdade não precisaria desta consulta em cascata pois para pool manda 
cada "figurinha" nova para todos seus peers assim que a mesma é 
conhecida. Sendo assim cada um destes pools que receberão nova 
"figurinha" já tem conhecimento desta e já podem rejeitar novas 
mensagens a partir daquele momento sem recorrer a novas consultas.

A gente já tem dois pools funcionando. Estou recebendo no meu pool todas 
as "figurinhas" do outro pool. Veja alguns exemplos:

    ubuntu at ip-172-31-28-232:~$ egrep " gian at live.com: " log.049.txt
    2015-09-15T09:48:29-0300 0002 PEERB gian at live.com:
    018.780.360/0001-19 => ADDED
    2015-09-15T09:48:29-0300 0164 PEERB gian at live.com: 291.564.028-99 =>
    ALREADY EXISTS
    2015-09-16T00:01:08-0300 0003 PEERB gian at live.com: .56srvqrma.com.br
    => ADDED
    2015-09-16T00:01:08-0300 0284 PEERB gian at live.com:
    @dicaboapravoce.com.br => ADDED
    2015-09-16T00:01:08-0300 0247 PEERB gian at live.com:
    @feriasmes12.com.br => ADDED
    2015-09-16T00:01:08-0300 0567 PEERB gian at live.com:
    @d-view.visitesaopaulo.com => ADDED
    2015-09-16T00:01:08-0300 0567 PEERB gian at live.com:
    .d-view.visitesaopaulo.com => ADDED
    2015-09-16T00:01:08-0300 0567 PEERB gian at live.com:
    .dicaboapravoce.com.br => ADDED
    2015-09-16T00:01:08-0300 0567 PEERB gian at live.com:
    .feriasmes12.com.br => ADDED
    2015-09-16T00:01:08-0300 0567 PEERB gian at live.com:
    018.852.993/0001-95 => ALREADY EXISTS
    2015-09-16T00:01:08-0300 0568 PEERB gian at live.com: @56srvqrma.com.br
    => ADDED
    ubuntu at ip-172-31-28-232:~$

Só para ficar claro, nosso pool solicita nada a este outro. Este outro 
simplesmente manda para nós tudo que ele identifica como "spam de 
consenso" dele. A única coisa que meu pool tem que fazer é adicionar 
estas "figurinhas" na lista de bloqueio dele. A partir daí, todos os 
clientes MX que consultam no meu pool já terão as mensagens destes caras 
bloqueadas.

> Caso receba uma resposta não nula o servidor ira armazenar a mesma no
> seu cache, pelo tempo máximo válido da resposta ja excluindo o tempo
> qua a mesma ja existia no servidor original. E retornará para o
> cliente.
> Caso receba uma resposta nula ele ira continuar o processo normal de
> consulta que já existe implementado.
> Acredito que desta forma as resposta serão mais rápidas na maior parte
> dos casos e nenhum servidor ficara sobre carregado.
>
> O que você acha.

Acho que você deveria vir trabalhar com a gente pois tem bastante ideia 
e ter ideias é o que faz o mundo ir para frente. :-)

>
> Em 16 de setembro de 2015 09:10, Leandro Carlos Rodrigues
> <leandro at allchemistry.com.br> escreveu:
>> Em 15/09/2015 15:14, GoldMail escreveu:
>>> Claudio,
>>>
>>> estamos usando o SPFBL já ha quase 1 mês.
>>>
>>> apesar da
>>> ferramenta ainda estar em desenvolvimento, esta se apresenta bastante
>>> estável;
>>>
>>> efetuamos a instalação "stand alone" em nossa própria
>>> estrutura, onde compartilhamos apenas as informações de bloqueio com o
>>> "pool central"
>>
>> Ai Gian. Temos um novo membro no MatrixDefense e as consultas saltaram para
>> 260mil por dia com latência média abaixo de 200ms. O projeto está crescendo
>> rápido!
>>
>>> quando implantando o serviço localmente, o seu
>>> funcionamento ja inicia o armazenamento do comportamento do seu fluxo de
>>> entrada e em cerca de 1 semana provavelmente inicie os bloqueios
>>> automáticos - tambem podem ser inseridos de forma manual bloqueios e
>>> white lists
>>
>> __
>> masoch-l list
>> https://eng.registro.br/mailman/listinfo/masoch-l
>
>