[MASOCH-L] Nova meta do SPFBL

[Leonardo Amaral - Listas]

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