[MASOCH-L] SPF LOCAWEB

[Leandro Carlos Rodrigues]

Danton, a idéia seria mais impedir abusos por exploração das brechas, 
que ao meu ver é caso de bloqueio imediato e inegociável.
No caso de spam conceitual, deixemos isso para sistemas de inteligência 
artificial tentar minimizar, pois qualquer um terá alguma probabilidade 
de errar e isso são outros quinhentos.
Mas nos casos das fraudes que estamos discutindo recentemente é 
altamente possível eliminar por completo na recepção, inclusive não 
deixando passar mensagens para serem analisadas pelo sistema que irá 
julgar se a mensagem é spam conceitual, fazendo com que estes sistemas 
julgadores possam ser alterados para serem especializados e não tomem 
tanto tempo de processamento da maquina.
Para isso basta criar um protocolo que quem usa deve obrigatoriamente 
utilizar tecnologias de identificação que já existem e práticas de 
configuração como por exemplo reverso, etc, que não existe uma regra 
fixa e somos obrigados a aceitar alguma mensagem mesmo que o servidor de 
origem não as usem.
Hoje se você decide por conta própria bloquear por algum critério seu, 
sempre vai ter um caso que é legítimo e isso pode fazer com que você 
sofra reclamações de seus clientes porque ele não está recebendo alguma 
mensagem de alguém importante porque o provedor dele não obedece o seu 
critério.
Se criasse algo novo, na qual esses critérios fossem obrigatórios, 
poderiamos bloquear sem medo, pois a origem não está seguindo as regras 
acordadas.

Atenciosamente,

*Leandro Carlos Rodrigues
TI - All Chemistry do Brasil Ltda.
(11) 3014-7100
***
Em 26/07/2012 10:02, Danton Nunes escreveu:
> On Thu, 26 Jul 2012, Leandro Carlos Rodrigues wrote:
>
>> Pessoal,
>>
>> Será que já não é hora de discutirem um substituto ao protocolo STMP 
>> que seja projetado para não ter tantas brechas como o STMP?
>
> invente um e submeta ao IETF como RFC. todo mundo pode fazer isso.
>
> o problema do spam no email é conceitual, a gente sempre tem que ter a 
> possibilidade de receber mensagem de um completo desconhecido, logo 
> qualquer sistema de mensagens que tenha essa propriedade altamente 
> desejada também será vulnerável ao spam e um que não a tenha será inútil.
>
>> Se analisarem bem, verão que todos esses problemas que enfrentamos é 
>> por conta da flexibilidade dele. Se criarem um substituto na qual 
>> quem adere seja obrigado a seguir todas as regras de segurança e 
>> identificação poderia ser substituido gradualmente em alguns anos. 
>> Seria algo equivalente ao que estão fazendo com a porta 25 para 
>> usuarios comuns.
>
> protocolo nenhum previne fraudes e tecnologia não resolve problemas de 
> natureza humana, política, comercial, criminal, etc.
>
> por que a locaweb é o ninho de spammers que é? simples, para reduzir 
> custos a gente pode contratar os serviços deles preenchendo um mero 
> formulário na Web cuja autenticidade ninguém vai conferir porque isso 
> custa dinheiro, pagar e sair usando, até que seja denunciado. aí a 
> conta é bloqueada e o ciclo simplesmente recomeça.
>
> os eventos de spam envolvendo a locaweb recentemente trazidos à lista 
> envolvem falsificação do endereço do remetente no envelope das 
> mensagens não solicitadas, na esperança de quem um email de "mim" para 
> "mim mesmo" passe batido pelas patrulhas anti-spam que colocamos. aí 
> entra em cena o SPF, pois esse artifício falha em domínios que o tem 
> registrado com um -all como regra geral. a mensagem de erro (bounce) 
> resultante é encaminhada para o remetente declarado no envelope (é só 
> para isso que ele serve!) ou seja, para a própria vítima do spam.
>
> eu entendo que esse tipo de falsificação do endereço de remetente de 
> uma mensagem constitui crime de falsidade ideológica, art. 299 do 
> código penal, entendo-se que o email é um documento.
>
> a locaweb tem um contato para reclamações desses abusos, mas nunca 
> recebi qualquer feed-back deles. além disso o endereço do contato para 
> abusos não segue a RFC-2142, o que mostra o quanto eles são 
> respeitadores de normas e boas práticas da Internet (a propósito o 
> endereço é regcom at hospedagemdesites.ws, que eu desconfio seja um alias 
> de /dev/null)
>
> -- Danton.
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l