[GTER] Data para Bloqueio da porta 25

[Julio Arruda]

Sem contar que spammer vai para o 'low hanging fruit'....

Se com isto, ele nao conseguir usar bots no provedor X, ele vai estar usando de outros, ate o proximo passo da corrida armamentista :-)

Existe um custo, para os provedores, para os clientes e etc, mas para alguem de fora como eu, parece que compensa..
Kudos para quem esta seguindo as orientacoes primeiro.
E entendimento com quem tem mais trabalho/custo, se demoram um pouco mais...no fim da historia, tem que pagar as contas no final do mes :-)..

On Jan 7, 2010, at 12:12 PM, Rafael Henrique Faria wrote:

> Então Fabio, aí que entra o lado positivo da porta 587, como
> obrigatoriamente tem que ter autenticação, o malware teria que se
> autenticar para fazer o envio das mensagens... e com isso seria mais
> fácil bloquear o usuário.
> 
> Enquanto que o malware enviando diretamente para o servidor destino
> pela porta 25, dificilmente você conseguiria bloquear a origem, com um
> malware enviando através de um login capturado, você bloqueia o login,
> o cara vai entrar em contato, e vai receber a noticia que a conta dele
> estava sendo usada para enviar spam.
> 
> IMHO, vai ficar bem mais facil para bloquear a origem dos spams.
> 
> 
> 2010/1/7 Fabio Catunda <fcatunda at lightcomm.com.br>:
>> Eu venho acompanhando esse tópico do início, mas vou ser honesto, ainda não
>> entendi em que o bloqueio vai ajudar.
>> 
>> A grande vantagem que vi até o momento é que os provedores poderiam bloquear
>> a porta 25/tcp, maravilha. Mas vocês não acham que os malwarez da vida vão
>> se adaptar muito mais rápido do que os provedores de Internet?
>> 
>> Att,
>> 
>> Catunda!
>> 
>> Danton Nunes wrote:
>>> 
>>> On Thu, 7 Jan 2010, Rafael Henrique Faria wrote:
>>> 
>>>> Acho que assim, para o lado do servidor, os benefícios não serão
>>>> tantos, acredito que apenas 1:
>>>> 
>>>> Por exemplo, se eu conectar direto no seu servidor a partir de
>>>> qualquer máquina, eu consigo mandar uma mensagem para alguém do seu
>>>> domínio através desta conexão, sem autenticar, pois o seu MTA irá
>>>> apenas receber a mensagem como se eu fosse um MTA também.
>>> 
>>> sim, é assim mesmo.
>>> 
>>>> Mas claro, é possível contornar este procedimento verificando se o IP
>>>> de origem da conexão é o MX do domínio em questão, e outras
>>>> verificações do tipo.
>>> 
>>> existe um jeito mais sofisticado de fazer isso que é o protocolo SPF, em
>>> que o dono do domínio do remetente define uma lista de controle de acesso de
>>> quem pode mandar email em nome do domínio.
>>> 
>>>> Mas não permitindo que usuários comuns enviem mensagem pela porta 25,
>>>> você pode fechar mais ainda o MTA, criando regras para certificar que
>>>> a conexão de origem é um MTA válido. Mas nada que não possa ser
>>>> realizado hoje.
>>> 
>>> e como você distingue um MTA válido de um telnet na porta 25 do meu
>>> notebook? as coisas não são tão pão-pão queijo-queijo assim.
>>> 
>>>> Por exemplo, podemos ter um 200.x.x.0/24, com todas as portas TCP 25
>>>> DEST bloqueadas. Então dá para garantir que nenhuma máquina desta
>>>> faixa conseguirá se passar por um MTA e enviar mensagens.
>>> 
>>> sim, porque MTAs conversam com outros MTAs justamente pela porta que está
>>> bloqueada.
>>> 
>>>> Agora se alguém de dentro desta rede, tentar enviar um e-mail através
>>>> do seu servidor que ainda utilizará a porta 25, essa pessoa não
>>>> conseguirá, mesmo que seja um e-mail valido.
>>> 
>>> exatamente. mas como o servidor que ele usa é decente e segue as boas
>>> regras do jogo, terá a porta 587 aberta para receber a submissão de
>>> mensagens. então, tudo o que o usuário válido tem a fazer é configurar seu
>>> cliente, trocar 25 por 587 e tacar lá suas credenciais. se o servidor for
>>> indecente e não aceitar conexão pela 587 ainda resta a possibilidade de usar
>>> um webmail, ou melhor ainda, trocar de provedor de serviço de correio para
>>> um decente.
>>> 
>>> usando a metáfora meio porca do correio comum, a 587 corresponde ao ato de
>>> depositar o envelope na caixa do correio. a 25 é usada entre os vários
>>> postos da empresa de correio. Assim como você não coloca sua carta
>>> diretamente nas máquinas de classificação, também não deve enviar email para
>>> servidores de transporte.
>>> --
>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>> 
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>> 
> 
> 
> 
> -- 
> Rafael Henrique da Silva Faria
> Grupo de Sistemas e Redes
> 
> Serviço Técnico de Informática
> Faculdade de Ciências e Letras do Campus de Araraquara - UNESP
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter