[MASOCH-L] Nova meta do SPFBL

Thu Feb 11 17:29:09 -03 2016

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