[GTER] Bloquear SPAM - uma tarefa impossível?

[João Carlos Mendes Luís]

Marcelo Coelho wrote:
>>     Mas voce vai descobrir que vários servidores estão com esse problema.
>>Eu mesmo perdi algumas informações bancárias por que o servidor de email
>>do meu banco estava com essa configuração.
>>
>>    É um falso positivo sim, mesmo causado pela falha de outras pessoas.
> 
> Realmente é complicado. Já pensei em combinar este tipo de bloqueio com uma
> faixa de IPs, por exemplo a dos ADSLs, mas isso não resolverá o problema.
> Muito pelo contrário, a maioria dos servidores de e-mail configurados em
> ADSL é que estão com o HELO incorreto.
> Fico torcendo para um ou dois provedores grandes se juntarem e passarem a
> bloquear estes hosts mal configurados.

     Ai é que está, os grandes não vão fazer isso justamente por causa dos 
falsos positivos.

>>   Só funciona por que voce usa duas máquinas diferentes para email
> 
> entrando e
> 
>>saindo, mas acho que foi uma boa idéia.
>>
>>    Verifique ainda que tem spammer usando endereços IP no HELO.  Em
> 
> geral,
> 
>>127.0.0.1 ou o seu próprio IP.
> 
> 
> Sim, eu tenho um arquivo com uma lista de helo's que óbviamente são fake,
> entre eles, meu próprio IP, 127.0.0.1, o famoso TmpStr, entre outros.

     No HELO tem que ser dado um nome, não um número.  Eu bloqueio TODOS!


#  Tinha gente usando endereço local na etapa de HELO. Isso deve filtrar esses
#  caras.  Essa string acha endereços IP.
#
/^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$/      450 Keep trying

     Note o erro temporário.  É só para ser chato mesmo!!!

>>  Tem como fazer melhor aqui.  Se o MAIL FROM for local, exija
> 
> autenticação,
> 
>>ou simplesmente rejeite, mesmo que a conta exista.  Junto com o SPF isso
> 
> pode
> 
>>ser uma solução bastante prática.
> 
> 
> Não posso. Posso ter um cliente, com servidor de e-mail em sua própria
> infra-estrutura, mandando mensagem com o MAIL FROM local, para RCPT TO
> local, sem autenticação.

     Se estiver na sua lista de redes locais, coloca na white list.  Se estiver 
fora, só com autenticação!

>>   Esquece o trabalho do DNS.  Tudo vale na guerra contra SPAM.
> 
> 
> Ok, se tudo vale, vale tudo ;-)
> 
> 
>>   Uma RBL que seria muito boa é a rfc-ignorant, mas infelizmente ela dá
>>MUITOs falsos positivos.  Ou segundo a sua definição, detecta muito
> 
> servidor mal
> 
>>configurado.  Incluindo ai hotmail, yahoo, terra, etc.
> 
> 
> Tenho aproveitado que alguns provedores estão declarando o SPF, e colocando
> estes IPs em listas privilegiadas.
> Se não vou bloquear UOL, nem AOL, nem Terra, por exemplo, não vou ficar
> perdendo tempo checando RBL, nem checando MAIL FROM.
> É claro que não vou abrir relay para eles, mas pelo menos economizo
> processamento "desnecessário".

     No postfix voce define a ordem em que as regras vão ser tratadas.  Por 
exemplo, se a conexão vem de um relay que eu acho confiável, nem passa pelas 
outras regras.

>>   Acredito que as reclamações sejam de empresas com DSL, na maior parte.
>>Culpa das carriers DSL que não separam empresas de usuários.  Minha
> 
> sugestão
> 
>>nesse caso: bloqueia e usa lista branca para quem for necessário.
> 
> 
> Haja lista branca. Bloquear os dial-ups até que vai, mas os ADSLs, é ter uma
> reclamação atrás da outra.

     Mas é justamente dos ADSLs que vem a maior parte dos Spams nacionais.  É 
uma questão de pesar qual é mais importante para voce.  Não gerencio nenhum 
provedor grande no momento, por isso achei que fechar os DSLs foi lucro.  Se 
fosse um provedor grande, talvez eu pensasse de outra forma.

> Queria entender como o UOL e AOL fazem com estes casos. Ou melhor, queria
> entender porque estes administradores dos servidores que estão ADSL não se
> tocam de que estão fazendo besteira, que não conseguem conversar com UOL,
> AOL, e não passam a "forwardar" tudo para o SMTP do provedor.

     A UOL é simples: tem o anti-spam deles, baseado em white-list por web.

> (A resposta: acho que é porque muitos enviam SPAM mesmo).
> 
> 
>>   O SPF pode ser a sua solução, mas é preciso informar isso aos usuários.
>>O interessante do SPF é que ele é uma decisão que parte do dono do domínio
>>origina.  Voce só bloqueia se o dono do domínio pediu para bloquear.  Se
> 
> voce
> 
>>colocar SPF no seu dominio, vai evitar que usem o seu dominio como fonte
> 
> de
> 
>>spam.  Procure no google por joejobbing, e entre em panico.  Já aconteceu
>>comigo, não é legal.
> 
> 
> Como solução para evitar que usem o domínio como fonte de SPAM, concordo,
> porém, posso publicar meu SPF sem necessariamente requerer SPF, posso também
> publicar meu SPF com ?all, e caso alguém faça um SPAM em meu nome, tenho,
> pelo menos, como argumentar que não faço isso.

Se voce não forcou o SPF, não ajuda nada.  Foi apenas uma dica, não uma "ordem".

> 
> Daí a pergunta: e se o SPAMMER passar a fazer o mesmo? Ele no próprio
> domínio cria um SPF, com ?all, mas manda e-mail para o mundo, e alega que
> "ele não enviou SPAM"...

     Pelo menos já sabemos quais IPs e remetentes filtrar.  O que ele não vai 
poder fazer é falsificar um rementente da AOL ou o Yahoo.

>>   Nesse caso, voce diz para ele reclamar com o provedor dele, que foi
> 
> quem
> 
>>colocou o SPF a disposição.  É simples.
> 
> 
> Concordo. Pena que a ignorância do usuário pode ser um problema, nem todos
> entenderão que foi o UOL quem pediu.
> A argumentação: ele consegue mandar e-mail para outros lugares normalmente.

     A lei brasileira não considera ignorancia desculpa para inocencia.  Já 
temos o precedente.   ;-)

> 
> 
>>   Está certissimo.  E o legal do SPF é que ele está sendo adotado pelos
>>grandes provedores.  Principalmente por que ele resolve o problema deles:
> 
> A
> 
>>maioria dos spams são falsificados usando um email de um grande provedor.
> 
> 
> Acho que os grandes provedores estão adotando o SPF (publicando os registros
> TXT) muito mais para "tirar o deles da reta" do que para solucionar o
> problema de SPAM no mundo. O UOL publicou o SPF? Ótimo! E ele, está
> validando SPF?

     A função deles é publicar o SPF.  Quem vai validar é quem decide se quer 
receber email ou nao.  Seria muito pior se voce quisesse usar o SPF ou qualquer 
outro mecanismo, mas ninguem registrasse ele.  Isso nao lembra o DNS reverso, 
rfc-ignorant, etc?

> 
> 
>>  E o que leva voce a acreditar que iriam segui-la?  Não seguem as RFCs...
> 
> 
> Pelo menos teríamo um órgão responsável recomendando tais ações. Justificar
> o usuário leigo com uma RFC não o faz compreender.

     Se o IETF não é um orgao responsável, então não sei mais o que é...

> Se o Registro.br tivesse um link em seu site, talvez, digo TALVEZ, alguns
> usuários passassem a compreender.
> 
> 
>>   Os efeitos colaterais existem, e cada um tem que decidir quais aceita
> 
> ou não.
> 
>>    Voce poderia ter listado outras forma de bloqueio, todas com efeitos
>>colaterais e falsos positivos:
> 
> 
>>- Bloquear conexoes vindas de IPs sem DNS reverso.
> 
> 
> Uma vez que quase todos os ADSL tem reverso, não creio que bloquearei muito
> SPAM, pelo contrário, irei bloquear e-mails legítimos, de servidores mal
> configurados.

    Esses eu bloqueio pelo próprio DNS:

roma::root postfix [605] grep adsl dialup | wc
       33      33     554
roma::root postfix [606] grep dsl dialup | wc
       78      78    1479
roma::root postfix [607] grep telesp dialup
customer.telesp.net.br
dial-up.telesp.net.br
dsl.telesp.net.br
roma::root postfix [608]

> 
> 
>>- Bloquear remetentes com MAIL FROM listados em rhsbl como o rfc-ignorant
> 
> 
> Ótima idéia. Mas será que hotmail.com, terra.com.br, uol.com.br estão na
> lista? Se tiverem, seria uma roubada.

     Estão, esse é o problema.  E é verdade, eles merecem estar na lista, pois 
ignoram o abuse at .

> Qual seria o critério para constar na RHSBL? Enviar um SPAM com determinado
> MAIL FROM ou depende do site que estã sendo divulgado no CORPO da mensagem?

     No caso do rfc-ignorant, não precisa nem mandar spam.  Basta que seu abuse@ 
ou postmaster@ não aceitem email ou não sejam lidos por ninguém.  Ou ainda, seus 
dados de WHOIS estejam inválidos.  Tem outras listas no rfc-ignorant, mas essas 
são as principais.  O que se percebe é que o mundo é uma ignorancia generalizada.

> 
> 
>>- Autenticação individual do remetente por web (TMDA, por exemplo)
> 
> 
> Você diz, como o anti-spam do UOL?

Isso

> 
> 
>>   E finalmente, uma que eu gosto muito, que não tem falsos positivos mas
> 
> que
> 
>>pode causar um pouco de transtorno e atrasos na entrega:
>>
>>- Greylisting
> 
> 
> Pelo que estou lendo a respeito do greylisting, acho uma boa.
> Talvez eu possa determinar que hosts "suspeitos" devam passar pelo
> greylisting, com base no reverso das redes que são spam-friend.
> Uma alternativa, seria limitar o número de conexões simultâneas destas
> redes, em, digamos, 1 ou 2 conexões simultâneas.
> Isso evitaria, pelo menos, o ataque do tipo dicionario, com threads.

     Isso não seria greylisting.

     Se o host não é "suspeito", já passou por alguma forma de white-list.  O 
greylist significa que todo mundo que não está numa white-list, será bloqueado 
sem dó nem piedade na primeira tentativa.  Mas se ele fizer um retry depois de 
algum tempo, vai conseguir enviar a mensagem e ainda vai entrar na lista branca.


                                         Jonny

-- 
João Carlos Mendes Luís - Networking Engineer - jonny at jonny.eng.br