[MASOCH-L] Nova meta do SPFBL

[Leandro Carlos Rodrigues]

  Nunca usei este bash de Windows mas isso me parece que funciona sim. 
Se esse bash.exe rodar exatamente igual ao bash convencional.

Leandro Carlos Rodrigues
TI All Chemistry do Brasil
(11) 3014-7100

Em 10/02/2016 12:52, Guilherme F W Xavier escreveu:
> Boa tarde,
>
> Para a  versão do windows, seria criar um filtro para todas as msgs do 
> servido de e-mail  com essa linha de comando?
> *C:\cygwin\bin\bash.exe -l -c "/cygdrive/e/scripts/spfbl.sh"*
>
> Grato,
>
> Guilherme Xavier
> http://www.gwxtecnologia.com.br/
> Facebook: http://www.facebook.com/pages/GWX-Tecnologia/118686814968575
> Linkedin: 
> https://www.linkedin.com/company/gwx-tecnologia-?trk=biz-companies-cym
>
> 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
>
> __
> 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/11602 - Data de 
> Lançamento: 02/11/16