[MASOCH-L] Nova meta do SPFBL

Leandro leandro at spfbl.net
Sat Feb 6 14:13:19 BRST 2016


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


More information about the masoch-l mailing list