| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Numa altura em que grande parte do spam começa a ser enviado por sistemas infectados com trojans/backdoors, será que bloquear e-mails cujo domínio do endereço não corresponde ao servidor pelo qual foram enviados vai ajudar muito? Penso que não, que na verdade só vai complicar a vida a quem é obrigado a usar o servidor smtp do seu ISP para enviar e-mail com o endereço de uma conta de um outro fornecedor, mas a ver vamos...
Mindstorm |
| | | | | | Falando especificamente do meu caso.
Uso e-mails em 4 domínios. Dois meus, e dois de ISPs: a Oninet e a Netcabo. Obviamente quanto aos meus servidores não tenho problemas, mas para a grande maioria dos e-mails que envio uso o endereço da oninet. Mas quando estou em casa ligo-me pela netcabo, e como tal não consigo acesso ao servidor da oninet. Para contornar o problema recebo todo o meu e-mail (por forwarding) na minha conta da netcabo, e para enviar uso o endereço da oninet mas o smtp da netcabo.
Agora vejamos se o SPF for implementado:
- qualquer e-mail com um enderço da oninet enviado pelo servidor da netcabo será rejeitado como falso, o que me impedirá de enviar e-mail desta forma
- qualquer email recebido na oninet e forwarded para a netcabo será rejeitado pela netcabo, porque o endereço do destinatário não é da oninet
Ou seja, vou deixar de poder usar o e-mail desta forma.
Se acho que vale a pena para evitar o spam? Claro!
O problema é que um spammer que utilize computadores infectados para enviar e-mails os poderá simplesmente enviar com o endereço e smtp configurados no pc.
O spam vai continuar a existir e duvido que o seu volume diminua consideravelmente. Por outro lado, muitos utilizadores legítimos serão afectados por este sistema
Mindstorm |
| | | | Ok, voces teem razao, mas esquecem-se de dois pormenores:
-o SPF nao obriga, mas recomenda que se active a autenticacao SMTP (com ou sem TLS/SSL, apesar de com ser mais aconselhavel), pelo que alguem num ISP poderia enviar emails de outro ISP usando o proprio servidor SMTP desse ISP...
neste caso da netcabo ligavas-te ao smtp da oninet, autenticavas-te e enviavas o email... se a porta 25 estivesse bloqueada, usavas a porta 587, o sbmission, basicamete um smtp em que apenas entregas emails (relay)
a autenticacao existe precisamente para os utilizadores moveis e podendo hoje em dia tambem ser usada como forma de bloquear spam e virus (precisavam de autenticar, possivel, mas vai complicar as coisas), alem de identificar exactamente o culpado pelo spam (o dono do PC com virus, com openproxy/openrelay, etc)
tirando o facto de servidores e clientes mais antigos poderem nao suportar a autenticacao, nao vejo desvantagem em SMTP+AUTH
nos casos dos clientes e servidores mais antigos, tal como todos teriam de implementar o SPF, estes teriam de actualizar o software sob a pena de terem os dominios abusados ou os emails bloqueados (com o tempo, quem nao suportasse o SPF, poderia ver os seus dominios rejeitados) ou nao poderem enviar os emails do exterior da sua rede
-os emails enviados por sistemas vulneraveis apenas seria diferente do spammer enviar ele proprio se usassem o dominio e o servidor SMTP do ISP ou de outra conta que o infectado podesse ter...
ora isto implica que 1º o spam comeca a ser muito associado aos ISPs, que para evitar a ma' publicidade poderiam comecar a proteger mais os clientes (ou o contrario, desliga-los imediatamente ate' corregirem o problema)
2º, o ISP provavelmente tem limites de quantos emails o to: pode levar, e ate' pode configurar que apenas pode enviar X emails por dia... ora isto torna a entrega do spam muito lenta e da' tempo de identificar o problema e resolve-lo
o spam continua a existir, mas em vez dos milhoes de emails que cada spammer envia hoje em dia, poderia enviar apenas alguns milhares e assim reduzir drasticamente o numero de spam a circular
isto nao soluciona tudo, existem sempre problemas, mas pode levantar barreiras o forte suficiente para limitar o spam e torna-lo inutil para alguns spammers
ao nao poderem falsificar o from: tornam mais simples a filtragem OU se o falsificam associam os ISP e entidades vulneraveis ao spam, aumentando a pressao a estes para filtrar o spam agir contra os spammers ou donos dos computadores vulneraveis
Higuita |
| | | | Tens razao, a autenticação existe, resta saber se vai ser implementada. Já poderia ter sido há muito tempo, mas por alguma razão a maioria dos ISPs continuam a preferir o método "se está com outro acesso, use webmail". Mas pode ser que alguem leia as especificaçoes da proposta com atenção e active a autenticação, espero que sim; nesse caso também não vejo grande inconveniente, embora duvide que isso vá acontecer.
Quanto aos ISPs a desligar os clientes infectados, a Comcast por exemplo já o começou a fazer esta semana, e suponho que outros também já o façam.
E sim muitos ISPs tem limites de mails enviados, mas se a quantidade de clientes infectados se manter como até agora, são mais do que os suficientes para enviar os ditos milhões de emails. Mas acredito que a implementação do SPF, juntamente com a adopção de novas políticas de segurança por parte dos ISPs e a utilização de antivirus (que também já poderia ter sido implementada há muito tempo, mas grande parte dos ISPs ainda não o fazem) o número de infecções diminua drasticamente, levando a uma redução gradual do spam em circulação.
Visto por esta perspectiva "idealista" o SPF seria quase um milagre para o sistema de email, mas infelizmente duvido que a sua adopção vá ser tão "correcta" como nós esperamos.
Pena é não acabar com as correntes "se não mandar isto a 55 pessoas os seus dentes da frente ficarão do tamanho de touros murcielago", mas isso era pedir demais ;)
Mindstorm
Mindstorm |
| | | | os ISPs dizem para usar o webmail, pois assim podem mostrar publicidade e ir ganhando uns trocos... isto e nao so', eles tambem nao querem mexer em servidores em producao, activar a autenticacao implica re-configurar o servidor smtp e isso da' trabalho e tem sempre riscos... downtime e' sempre clientes a queixar-se (nao e' que a telepac/sapo/netcabo se importem muito com as queixas...)
eu nao tenho duvidas que o SPF vai arrancar lentamete, mas a' medida que mais gente o for usando, maiores vao ser os efeitos e vai-se chegar a uma massa critica que quase todos vao querer implementar...
as distros e os programas SMTP ao trazerem incluido suporte para SPF, vao ser a maior alavanca para ser mais implementadp
depois ficaram durante ANOS centenas de dominios que ninguem gere sem o SPF e ira haver a altura em que se vai de ter de escolher, ou se recebe spam ou se impede a recepcao dos dominios sem SPF definido... mas isso cada um (ISPs, empresas, etc) vai ter que decidir
o facto dos grandes dominios e emails gratis usarem esta solucao (ou compactivel) so' por eles vao fazer que exista uma grande quebra no spam
pelo site, quando a AOL testou o SPF, verificou-se uma quebra no spam recebido nos servidores que usavam SPF.
os spammers terao entao de usar outros dominios menos conhecidos, pelo menos ate' implementarem o SPF ou toda a gente bloquear nos filtros esse dominio (uma vez que sao menos conhecidos, a probabilidade de um falso positivo e' baixa, logo pouco risco)
Higuita |
| | | | qualquer email recebido na oninet e forwarded para a netcabo será rejeitado pela netcabo, porque o endereço do destinatário não é da oninet Estas a confundir o envelope com o endereco nos headers. Ao forward um email da oninet para a netcabo, o envelope-sender e' o da oninet. Ou seja, a netcabo ve um utilizador da oninet a reenviar um email para a netcabo que recebeu de EXAMPLE.COM
--
Luís Bruno |
| | | | Quoting SMTP+SPF: FAQ But that breaks forwarding!
Yes, it does. You'll have to switch from forwarding, where the envelope sender is preserved, to remailing, where the envelope sender is changed. But don't worry, we're working on providing SRS patches for the four major opensource MTAs, so that when you upgrade to an SPF-aware version, this problem will be solved also.
If your forwarding runs through a commercial service like pobox.com, you shouldn't have to do anything. They have to change with the times, and perform the above rewriting automatically for you. SRS is a structured standard that helps them adapt.
Mindstorm |
| | | | A Yahoo, por exemplo, já mete mail com um endereço FROM que não corresponda ao SMTP usado na folder 'bulk mail' (i.e. classifica-o como SPAM) Já o faz há muito tempo. De certeza que ainda não usa SPF.
|
| | | | eu tenho no meu postfix 2 configuracoes que lista os grandes dominios de email gratis (hotmail, yahoo, netscape, aol) e o outro os restantes emails gratis que eu tenho conhecimento e que consegui arranjar
sempre que recebo um email de cada uma destas listas, o postfix vai verificar se os emails veem de uma lista de servidores correspondentes aos grupos acima referidos (*.hotmail.com, *.yahoo.com, *.netscape.com, *.aol.com para o 1º grupo, centenas de outros para o 2º caso)
sim, enviar um email @hotmail.com dos servidores da yahoo.com da' a volta ao filtro, mas que eu visse, isto nunca aconteceu
o que isto faz emula um pouco o SPF, embora muito menos fiavel, ja' que sou eu quem decido que servidores podem entregar os varios dominios e nao o donos do dominio (que sao quem realmente sabe quem pode enviar)
na 1º lista, os servidores smtp teem todos rDNS e nao permitem enviar emails dos seus SMTPs com o from de outro dominio (logo funciona bem)
no 2º caso, sao emails menos conhecidos e logo menos riscos de perder algo valido
sempre que isso acontece, acabo por descobrir mais um servidor que pode enviar emails desdes dominios e adiciono-o a lista
devido a este e outros filtros eu tenho um script que todos os dias avisa os varios utilizadores quais os emails rejeitados (from:, IP/nome de origem da ligacao, razao para a filtragem, numero de tentativas), que permite detectar os filtros errados e assim os corrigir
se na 1º semana havia varios problemas de filtragem, hoje em dia so' recebo comentarios a perguntar sobre emails com virus que falsificaram o from: para um email conhecido
isto para dizer que e' possivel fazer isto sem implementar o SPF, mas sempre de forma muito menos fiavel
no meu caso, com buracos, mas implementar uma regra para cada dominio da' demasiado trabalho, as 2 regras funcionam muito bem e filtra-se 80% dos spams (os que usam emails gratis para o spam, mas que usam openrelays/openproxies para distribuir o spam)
Higuita |
| | | | Mas hoje, um cliente meu, com dominio alojado no estrangeiro, e que fazia relay de SMTP pelo servidor fornecido pelo seu próprio ISP, deixou de conseguir fazê-lo, e foi-lhes comunicado (ao ligar para lá) que tinham começado a bloquear esse tipo de funcionalidade...
|
| | | | | | O SPF tem de ser activado no servidor que recebe o email e não no que o envia, por isso penso que não esteja relacionado...
Mindstorm |
| | | | Explica lá isso que eu não percebi. Fazia relay de fora para fora do ISP, usando o SMTP deste? Esse ISP por acaso não será a Telepac? É que a Telepac funcionava como open-relay limitado (só fazia relay até um número limite de destinatários/emails) o que lhes custava serem apanhados pelas listas de open-relays regularmente. Agora como passaram a usar SMTP autenticado (alguém viu a luz lá na Telepac) penso que isto deve ter sido eliminado.
-- Carlos Rodrigues
|
| | | | E ainda bem k usam SMTP com autenticação agora.
Antes não conseguia mandar mails pra minha avó na polónia.
O servidor do lado de lá barrava os mails.
Só mesmo através da netcabo.
Vejo que agora já mudou ;)
"Everyone has the right to be stupid. Some just abuse the privilege" |
| |
|
