[MASOCH-L] Nova meta do SPFBL

[Leandro]

Pessoal,

Estamos colocando em produção, para alguns provedores apenas, o seguinte
código de rejeição SPFBL:

554 5.7.1 SPFBL <message>

Vocês conseguem ver se, ao enviar e-mail, seu servidor recebeu alguma
mensagem com este padrão nos últimos dias?

Leandro
SPFBL.net

Em 6 de fevereiro de 2016 14:11, Leandro Carlos Rodrigues <
leandro.carlos.rodrigues at gmail.com> escreveu:

> Pessoal,
>
> 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
>
>