Spam: CGI.br determina bloqueio da porta 25 (smtp) a partir de janeiro
| Tweet |
|
Segundo a cobertura no UOL Notícias, o Comitê Gestor da Internet no Brasil está divulgando que espera reduzir o tráfego de spam em até 90%. Para isso, empresas como Telefônica, Oi e Net vão atender à determinação de bloquear os dados transmitidos pela porta 25.
Enviado por Alexandro Silva (alexoslabsΘgmail·com):
Se você usa programas de gerenciamento de e-mails —como o Outlook, Thunderbird ou Mail— para não ficar impedido de mandar mensagens, a porta de envio deve ser trocada de 25 para 587. Usuários apenas de webmail não serão impactados.
“Com a implementação das recomendações, será mais difícil para que computadores zumbis sejam utilizados para o envio de spam, pois além de necessitar de um usuário e senha para utilizar o serviço de e-mail, ele ainda deverá burlar os possíveis controles antispam existentes no serviço mencionado”, diz Nelson Novaes, gerente de segurança do UOL.
A medida não é nova, órgãos internacionais aconselham o bloqueio da porta 25 desde 1998, mas apenas em 2005, provedores e operadoras de todo o mundo começaram a adotá-la em massa. O UOL oferece o acesso pela porta 587 desde 2004. Leia mais em UOL-Noticias” [referência: blog.alexos.com.br]
| Tweet |
|
• Link direto para este post: http://br-l.org/!17021
• Siga no Twitter: @brlinuxblog e @augustocc
• Mais posts do mesmo tema: Administração, Aplicações
Demorou pra o órgão gestor tomar essa decisão, mas não sei se vai adiantar muita coisa. Possivelmente o tráfego de spam disseminados a partir de computadores zumbi localizados no Brasil irá diminuir num primeiro momento, mas logo os spammers passarão a utilizar a porta 587.
Os provedores menores vem fazendo isso a mais de 10 anos. AGORA é que o comitê acordou pra mandioquinha? Comitê Gestor desse jeito era melhor nem ter.
@ Frank
Para isso eles precisarão também saber a senha para autenticação no servidor SMTP. Não impossibilita, mas complica um pouco a vida destes ratos cibernéticos. Antigamente alguns provedores de e-mail já usavam o popb4smtp (pop before smtp, cuja transmissão de e-mail só é possível após proceder com o login e verificar a conta no pop3).
Um outro problema é a capacidade de alguns spambots de lidarem com CAPTCHA e/ou JavaScript (em webmail). Neste caso, é interessante usar um “honeypot”, com um campo que um usuário normal não conseguiria preencher por não ser possível vê-lo (escondido pela CSS da página) mas o bot ao preenchê-lo não consegue validar sua tentativa de acesso, pois o backend exige aquele campo em branco por padrão.
http://damienkatz.net/2007/01/negative_captch.html
Com este artifício aliado ao JavaScript, não é necessário o CAPTCHA, eliminando mais de 90% dos spambots e preservando a paciência dos usuários. O CAPTCHA só é interessante para prevenir ataques de quebra de senha por dicionário, depois de “n” tentativas de login sem sucesso.