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

[Marcelo Coelho]

>      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.

>    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.

>   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.

>    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".

>    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.
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 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.

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"...

>    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.

>    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?

>   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 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.

> - 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.
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?

> - Autenticação individual do remetente por web (TMDA, por exemplo)

Você diz, como o anti-spam do UOL?

>    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.

--
Marcelo Coelho
marcelo at tpn.com.br