[MASOCH-L] Nova meta do SPFBL

Wed Feb 10 15:00:07 BRST 2016

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
>