[MASOCH-L] Nova meta do SPFBL

Thu Feb 11 17:57:49 -03 2016

te mandei os ips em pvt.

On 11-02-2016 17:53, Leandro wrote:
> 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
>>
> __
> 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