[MASOCH-L] Nova meta do SPFBL

Thu Feb 11 17:53:17 BRST 2016

Oi Rejaine,

Me passe todos os casos para eu analisar aqui.

Eu criei um algoritmo para minerar IPs dinâmicos e acredito que ele seja
responsável por incluir na lista blocos que não são dinâmicos de fato.

Eu já desliguei o algoritmo alguns dias atrás mas não consegui revisar tudo
que ele fez.

Leandro

Em 11 de fevereiro de 2016 17:29, Rejaine Monteiro <rejaine at bhz.jamef.com.br
> escreveu:

>
> Olá Leandro,
>
> Estou usando a SPFBL ha algum tempo e esta funcionando bem...
> Mas de um tempo cá, mais especificamente nas últimas duas semanas, tem
> aparecido alguns falsos positivos.
> Eu criei um dns local  para fazer o "bypass" da consulta RBL para esses
> casos,  portanto estou contornando os casos que encontro dessa forma. Só
> achei estranho que entre ontem e hoje apareceram três ou quatro casos, por
> exemplo, e já estou usando desde novembro e raramente estavam reclamando.
>
> On 10-02-2016 15:00, Leandro wrote:
>
>> A deterioração já funciona bem. Estamos bloqueando mais de 95% do SPAM com
>> quase zero de falso positivo. O SPFBL consegue determinar bem o verdadeiro
>> responsável pelo envio do SPAM.
>>
>> Estou trabalhando na nova página de política de listagem. Mesmo que os
>> códigos não foram definidos ainda, coloquei no ar um exemplo. Como meu
>> inglês está enferrujado, vejam se fica claro ao remetente que ele deve
>> cessar o envio nestes situações para melhorar a reputação dele:
>>
>> http://spfbl.net/policy2.html
>>
>> Leandro
>> Em 10/02/2016 13:35, "Leonardo Amaral - Listas" <
>> listas at leonardoamaral.com.br> escreveu:
>>
>> Acredito que quanto mais próximo do standard, melhor, se atendem os
>>> códigos e se é suficiente a descrição do sinal para satisfazer os
>>> scores da API.
>>>
>>> Sobre a questão da deterioração, eu precisaria pensar um pouco mais,
>>> acredito que possa ter saída mesmo para quem não filtra e faz relay.
>>>
>>> Em 10 de fevereiro de 2016 11:49, Leandro Carlos Rodrigues
>>> <leandro at allchemistry.com.br> escreveu:
>>>
>>>> Leonardo. Eu dei uma olhada nesta RFC 3463 e vi que este código 5.7.1 já
>>>>
>>> foi
>>>
>>>> definido para esta finalidade:
>>>>
>>>>     https://tools.ietf.org/html/rfc3463
>>>>
>>>> Neste caso eu estava pensando em usar o mesmo código, pois não
>>>> precisaria
>>>> mudar a RFC.
>>>>
>>>> Para dar um pontapé inicial, criei esta listinha de códigos SMTP para
>>>>
>>> cada
>>>
>>>> reposta negativa do SPFBL:
>>>>
>>>>     451 4.7.1 GREYLIST
>>>>     451 4.7.2 LISTED
>>>>     554 5.7.1 FAIL
>>>>     554 5.7.1 NXDOMAIN
>>>>     554 5.7.1 INVALID
>>>>     554 5.7.1 BLOCKED
>>>>
>>>> Se o sistema que responde por 554 5.7.1 não seja o SPFBL, mesmo assim a
>>>> regra de parar de enviar e-mail para aquele destinatário continua
>>>>
>>> valendo.
>>>
>>>> Neste caso aproveitar este mesmo código não prejudica os demais
>>>> sistemas.
>>>> Aliás pode até ajudar estes outros sistemas se o SPFBL conseguir fazer
>>>> os
>>>> enviadores diminuírem o volume de SPAM para esta códigos.
>>>>
>>>> Se a gente adotar este código 554 5.7.1 mesmo, terei que deixar bem
>>>>
>>> claro na
>>>
>>>> página de política do SPFBL que a persistência na tentativa de envio
>>>> para
>>>> estes casos acarreta em deterioração da reputação na rede P2P do SPFBL.
>>>>
>>>> O que vocês acham?
>>>>
>>>> Leandro Carlos Rodrigues
>>>> TI All Chemistry do Brasil
>>>> (11) 3014-7100
>>>>
>>>>
>>>> Em 10/02/2016 08:51, Leonardo Amaral - Listas escreveu:
>>>>
>>>>> Bom dia!
>>>>>
>>>>> Inicialmente, parabéns pela solução criada! Eu sou a favor de expandir
>>>>> os códigos SMTP para uso de combate a SPAM e também sou favorável de
>>>>> mandar uma RFC (Que instituição tupiniquim poderia endorsar a causa?)
>>>>> para homologar esses códigos.
>>>>>
>>>>> Sobre o comentário da versão para Windows, eu não uso o sistema pois
>>>>> (felizmente) não administro mais servidores de email, mas eu imagino
>>>>> que não deva ser complicado usar cygwin + um .bat que chame o spfbl
>>>>> usando o bash.exe (Ou alguma solução mais elegante, como portar
>>>>> nativamente a cli e disponibilizar API para as chamadas internas, um
>>>>> RPC ou coisa equivalente).
>>>>>
>>>>> Att,
>>>>>
>>>>> Em 6 de fevereiro de 2016 14:13, Leandro <leandro at spfbl.net> escreveu:
>>>>>
>>>>>> Gostaria de agradecer a todos que colaboraram com este nosso projeto
>>>>>> SPFBL.
>>>>>> Para quem ainda não conhece o projeto, segue o link do Github:
>>>>>>
>>>>>> https://github.com/leonamp/SPFBL
>>>>>>
>>>>>> No inicio, nossa meta foi identificar e rejeitar pelo menos 90% do
>>>>>>
>>>>> volume
>>>
>>>> total de SPAM. Hoje conseguimos atingir esta meta com mais de 95% de
>>>>>> identificações e bloqueios do volume total de SPAM.
>>>>>>
>>>>>> Agora queremos estipular uma nova meta.
>>>>>>
>>>>>> Existe um problema grande hoje, falando do escopo Brasil, onde cerca
>>>>>> de
>>>>>> 60%
>>>>>> do volume de mensagens enviadas são consideradas SPAM, segundo estudo
>>>>>>
>>>>> que
>>>
>>>> fizemos no nosso próprio sistema incluindo 15 provedores como
>>>>>>
>>>>> amostragem.
>>>
>>>> Isso significa que um provedor deve alocar mais da metade de seus
>>>>>> recursos
>>>>>> computacionais para recepcionar e processar mensagens indesejadas.
>>>>>>
>>>>>> Se esta proporção fosse menor, daria para o provedor alocar menos
>>>>>> recursos
>>>>>> computacionais, reduzindo custos, ou aumentar a quantidade de clientes
>>>>>> sem
>>>>>> fazer novos investimentos. Acredito que uma redução drástica do volume
>>>>>>
>>>>> de
>>>
>>>> SPAM poderia até estimular redução de preços aos consumidores finais.
>>>>>>
>>>>>> Hoje o feedback de abusos aos enviadores de e-mail é feito através de
>>>>>> empresas especializadas, como Spamcop ou Spamhaus, que são
>>>>>> responsáveis
>>>>>> por
>>>>>> processar denuncias e colocar as fontes de SPAM em listas negras
>>>>>> centralizadas. Para que o modelo de negócio deles seja viável, estas
>>>>>> empresas cobram a remoção dos IPs de suas listas, sob certas condições
>>>>>>
>>>>> de
>>>
>>>> cada uma.
>>>>>>
>>>>>> A minha proposta é romper completamente com este paradigma de
>>>>>> centralização
>>>>>> de processamento de denuncias. Invés disso, seria interessante
>>>>>>
>>>>> determinar
>>>
>>>> códigos SMTP de rejeição específicos para dizer ao MTA da origem que
>>>>>> aquele
>>>>>> remetente especifico que está enviando foi considerado como SPAM pelo
>>>>>> destinatário e por isso o MTA de origem deve parar de enviar mensagens
>>>>>> daquele destinatário para o remetente em questão. Tudo isso usando o
>>>>>> sistema descentralizado do SPFBL.
>>>>>>
>>>>>> Com posse desta informação, é possível por exemplo que administradores
>>>>>>
>>>>> de
>>>
>>>> MTA de envio monitorarem os e-mails enviados por terceiros através de
>>>>>>
>>>>> seu
>>>
>>>> MTA e possam punir aqueles que estão abusando de seu MTA. Isso
>>>>>> facilitaria
>>>>>> muito o processo de punição pois não haveria necessidade de empresas
>>>>>> de
>>>>>> lista negra informem a eles estes abusos para que eles tomem
>>>>>>
>>>>> providências
>>>
>>>> pois a informação já está lá no código de retorno do SMTP.
>>>>>>
>>>>>> Se a ideia der certo, espero que vários desenvolvedores comecem a
>>>>>> desenvolver ferramentas que monitorem e bloqueiem envio de e-mail pelo
>>>>>> MTA
>>>>>> se este receber tais códigos SMTP de rejeição do destino. Com isso
>>>>>>
>>>>> viria
>>>
>>>> a
>>>>>> redução do volume de SPAM que sinalizei antes como meta.
>>>>>>
>>>>>> Como inicio, coloquemos uma meta modesta de baixar o volume de SPAM de
>>>>>> 60%
>>>>>> do total para 10% do total e vemos o até aonde conseguimos chegar. Se
>>>>>> conseguirmos reduzir para este patamar de 10%, a alocação de recursos
>>>>>> computacionais para recepcionar e-mails indesejados seria
>>>>>> satisfatória,
>>>>>> do
>>>>>> meu ponto de vista.
>>>>>>
>>>>>> A partir daqui, gostaria que se iniciasse uma discussão sobre o padrão
>>>>>>
>>>>> de
>>>
>>>> códigos SMTP de rejeição para estas finalidades dentro do SPFBL. O
>>>>>> critério
>>>>>> seria usar códigos SMTP 5.x.x ainda não usados ou que já estejam sendo
>>>>>> usados para finalidades semelhantes. Este aqui seria um exemplo de
>>>>>>
>>>>> código
>>>
>>>> usado pela Symantec:
>>>>>>
>>>>>> https://support.symantec.com/en_US/article.TECH169847.html
>>>>>>
>>>>>> Notem ai que o cenário 2 diz que o remetente foi bloqueado pelo
>>>>>> destinatário. De forma análoga, se o SPFBL retornar um código SMTP
>>>>>> semelhante, seria equivalente a dizer:
>>>>>>
>>>>>> 554 5.x.x O remetente desta mensagem foi bloqueado pelo destinatário e
>>>>>> por
>>>>>> isso cada tentativa de envio deste remetente para este destinatário
>>>>>> acarretará em pontuação negativa dele na tabela de reputação da rede
>>>>>> SPFBL,
>>>>>> como é o caso desta tentativa atual.
>>>>>>
>>>>>> Se o padrão pegar, então teremos o maior mecanismo de obtenção de
>>>>>> informações de abusos do Brasil usando apenas o SMTP como veículo e
>>>>>> talvez
>>>>>> atingirmos nossa meta.
>>>>>>
>>>>>> Mandem seus comentários e críticas. Vamos definir este padrão e
>>>>>>
>>>>> perseguir
>>>
>>>> a
>>>>>> nova meta.
>>>>>>
>>>>>> Abraços,
>>>>>> Leandro
>>>>>> SPFBL.net
>>>>>> __
>>>>>> masoch-l list
>>>>>> https://eng.registro.br/mailman/listinfo/masoch-l
>>>>>>
>>>>> __
>>>>> masoch-l list
>>>>> https://eng.registro.br/mailman/listinfo/masoch-l
>>>>>
>>>>>
>>>>> -----
>>>>> Nenhum vírus encontrado nessa mensagem.
>>>>> Verificado por AVG - www.avgbrasil.com.br
>>>>> Versão: 2016.0.7303 / Banco de dados de vírus: 4522/11594 - Data de
>>>>> Lançamento: 02/09/16
>>>>>
>>>>
>>>> __
>>>> masoch-l list
>>>> https://eng.registro.br/mailman/listinfo/masoch-l
>>>>
>>> __
>>> masoch-l list
>>> https://eng.registro.br/mailman/listinfo/masoch-l
>>>
>>> __
>> masoch-l list
>> https://eng.registro.br/mailman/listinfo/masoch-l
>>
>
> --
> Rejaine da Silveira Monteiro
> Suporte-TI
> Tel: (31) 2102-8854
> rejaine at bhz.jamef.com.br
> www.jamef.com.br
>
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
>