É, mas isso era quando se amarrava cachorro com lingüiça e se podia confiar nos remetentes :)
Nota: Alguns fatos podem não estar 100% certos. Eu conheço o protocolo SMTP como usuário, como programador (se bem que SMTP não requer "programação") e como administrador de site, mas nunca tive o ponto de vista do provedor de e-mail.
O esquema atual, onde você envia a mensagem para o seu servidor, que depois envia para o servidor do destinatário, é tão generalizado que você pode imaginar que não existe (ou existiu) outra maneira, mas existe sim. A porta só está fechada por causa dos spammers.
O protocolo SMTP permite que você deposite o e-mail diretamente no servidor do destinatário, dispensando a necessidade de outro servidor ou até de senha (mas nenhum programa popular de e-mail jamais explorou isso, que eu saiba). Assim se você quisesse enviar e-mails para:
fulano@bol.com.br
beltrano@bol.com.br
cicrano@hotmail.com
Você poderia se conectar a bol.com.br e entregar os e-mails de fulano e beltrano. Depois se conectar a hotmail.com e entregar o e-mail de cicrano. A vantagem disso é que uma vez recebido o OK final do servidor de destino, você tem certeza de que o e-mail foi entregue. E corretamente. Só faltando o destinatário ir lá pegar.
Eu mesmo escrevi um programa simples de e-mail há uns oito anos que funcionava dessa forma, mas hoje ele não funciona mais :(
Em caso de erro você também saberia imediatamente. Hoje quando um e-mail "se perde" fica difícil saber se a culpa é da "infraestrutura" do destinatário ou da sua.
Antigamente nem era preciso de senha para enviar e-mail. Só para receber a autenticação do usuário sempre foi necessária. Os primeiros spammers exploraram isso para fazer com que um servidor qualquer mandasse SPAM por eles. Alguns provedores de acesso então criaram um bloqueio para que você só pudesse enviar e-mail se estivesse conectado à internet por eles (mais ou menos como só poder enviar e-mail pelo Hotmail se o Hotmail fosse seu provedor de acesso). Como isso obviamente não é uma boa solução os servidores foram gradativamente adotando uma extensão do protocolo SMTP que exige senha para o envio.
Mas há um detalhe: a mesma conexão/protocolo que você, usuário, usa (ou usaria) para enviar e-mail diretamente também é usada pelos servidores para trocar e-mails entre si. E obviamente a coisa ficaria complicada se o Hotmail precisasse ter a senha do servidor da Americanas se um usuário do Hotmail precisassse mandar e-mail *@americanas.com.br. Para evitar isso, a regra é que quando você se conecta a um servidor de e-mail para deixar mensagens para usuários desse mesmo servidor, não é necessário senha.
Assim como nenhum servidor de e-mail do planeta precisa de autenticação para enviar e-mail para meu servidor em ryan.com.br. Eles só não podem deixar e-mail no meu servidor que é destinado para pessoas fora dele. Isso só quem pode fazer são meus usuários.
Mas aí os spammers começaram a explorar isso também.
É claro que dá mais trabalho. No modelo antigo bastava depositar uma mensagem com 100 pessoas (até mais) em qualquer ordem no campo CC (Com Cópia) para que o servidor de e-mail dos outros se encarregasse do trabalho sujo. Com a conexão direta o spammer precisava então ordenar suas mensagens por servidor de destino, conectar-se a cada um deles e deixar as mensagens correspondentes (talvez uma só, com CC para todos). Pior que isso: o spammer se conectava e começava a "chutar" nomes de usuário. Os que não davam erro ele sabia que existiam e mesmo que fosse desconectado/bloqueado poderia voltar outra vez com uma lista "certa". Muitos provedores de hospedagem (o meu, inclusive) precisaram proibir o uso do recurso de "catch-all" por causa disso, pois todo e-mail que o spammer chutava dava válido. Eu cheguei a receber uns 1500 spams por dia, quando eu tinha um catch-all e um spammer se "pendurava" no meu domínio. Eu não me incomodava porque era tudo redirecionado para minha conta no Gmail que filtrava quase tudo com perfeição, mas o que eu não sabia é que a carga era significativa para o meu provedor.
Para evitar que isso aconteça, os servidores de e-mail legítimos agora checam o IP de quem se conecta contra uma "blacklist" para saber se pode ser de um conhecido spammer ou de um servidor de e-mail público que anda agindo irresponsavelmente (como quando o IG inteiro entrou na blacklist em 2000). Na verdade o esquema de blacklist já existia, mas acabou por englobar (não sei se "por default" ou "naturalmente") toda a faixa de endereçamentos atribuída a usuários ADSL ou discados. Ou seja: toda a faixa "não fixa".
(des)Graças a isso, eu estava tentando ressuscitar umas rotinas de meu antigo programa de envio de e-mail para usar em outro programa que estou criando mas desisti. Como tanto eu como os possíveis usuários de meu programa iriam usá-lo de uma conexão com IP variável, é quase certo tentar a conexão e receber uma resposta do destino dizendo que você está numa RBL (ou resposta nenhuma).
Bateu saudade daquele tempo, 10 anos atrás... :)
Eu acho que uma das soluções "fáceis" para resolver o problema de SPAM é limitar o nº de envio de emails por usuário por hora. Algo assim.
ResponderExcluirE verificar quais os servidores infrigem as "regras", colocando eles em Blacklist.
Acho que mais de 90% de usuários de email não precisam enviar mais de 500/1000 emails hora.
O que limitaria muito spammers.
Eu entendo menos de SMTP, mas pela sua descrição fiquei com a impressão de eu posso sim enviar um e-mail direto ao servidor SMTP do destinatário. O que eu não posso é pedir para um servidor SMTP onde não tenho senha enviar e-mails para outros servidores SMTP.
ResponderExcluirDaniel,
ResponderExcluirSó se seu IP não estiver em uma RBL. Aí você pode deixar e-mails direto na conta do destinatário mesmo sem qualquer senha.
Enviar para outros (relay) você só pode se for usuário e se autenticar.
Pois é... eu tinha servidor smtp próprio na minha maquina justamente pra isso, garantir a entrega direto na boca da caixa postal do destinatário. Funcionava muito bem, até que os malditos spammers acabaram com tudo. Hoje eu mantenho o servidor aqui ainda, mas o deixei muito a contra-gosto como smtp-relay, ou seja ele recebe todas as minhas mensagens enviadas, e faz relay para o meu provedor de acesso no seu smpt.
ResponderExcluirVantagem disso? Uma só... não ficar olhando com uma besta para aquela tela de envio do cliente de email, aguardado ele fazer o upload da mensagem.
Dessa forma clicou em enviar em menos de 2 segundos a mensagem inteira vai embora pro meu smtp server local, que se encarrega de fazer o serviço sujo de colocar isso no smtp do meu provedor.
Nisso eu ainda tenho a vantagem de poder configurar a quota que ele vai abocanhar nos meus mirrados 300Kbps de upload.
Olá,
ResponderExcluirBem, quando precisei enviar uma boa quantidade de emails para divulgar um site meu, fiz alguns testes com os servidores, o gmail só deixa enviar 50 e depois bloqueia, o yahoo vai por aí. Então... na epóca (2007), eu assinava um pequeno provedor e resolvi fazer um teste. Consegui enviar 10.000 por meio deste provedor. Pensei: "Oh! esse provedor está com relay livre!". Depois de um tempo, fui tentar novamente e vi que alteraram: depois da 2.000ª mensagem, dava erro. Foi aí que arrumei um programa que conseguia dividir a lista de emails para cada conta, então mandava 2000 por cada 1 das 5 contas de email que tinha desse provedor, aí dava para mandar 10000 por dia, se quisesse. Mas isso já faz uns dois anos.
Ah, não sou spammer, foi só uma saída que achei para um obstáculo na época.
Abraços,
André
Luciano,
ResponderExcluirIsso é interessante. Eu já havia pensado em instalar um proxy para e-mail (que é outro tipo de animal) em um cliente só pela necessidade de bloquear a internet de um usuário mantendo o e-mail. Mas nessa vantagem do servidor próprio de e-mail honestamente eu não havia pensado.
Que programa você está usando?