[MASOCH-L] Nova meta do SPFBL

Wed Feb 10 11:49:44 -03 2016

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