As emocionantes aventuras de um sysadmin linux na procura pelo uptime perfeito!

Como funciona a parada da Gestão da Porta 25

Posted: maio 22nd, 2009 | Author: coredump | Filed under: Linux e Open Source, segurança | Tags: , ,

Baseado nesse post do br-linux e nas dúvidas do povo no twitter, resolvi escrever um post rápido sobre o como funciona. Pode ser que tenha algo faltando ou errado, se tiver avisem nos comentários.

É assim:

Imagine que você tem um email email@longe.cu que fica longe.

Atualmente sua máquina conecta na porta 25 do servidor smtp.longe.cu para enviar email para qualquer lugar. Para isso ele deve pedir uma senha para permitir que você consiga enviar email e fazer relay.

Com a gerência da porta 25, vc não conseguiria fazer isso mais, a porta seria bloqueada. Teria algumas opções:

  • Passar a usar SMTP com TLS/SSL que usa a porta 900 e algo.
  • Usar um MSA (Mail Submission Agent) do seu provedor de conexão.

Esse MSA basicamente é um servidor que aceita conexões na porta 487, num formato igual ao SMTP mas com alguns relaxamentos de cabeçalho. Esse servidor tem de estar configurado para fazer relay para qualquer lugar do planeta, desde que a conexão venha da rede que ele serve, independente do FROM do email.
Então o seu cliente de correio envia a sua mensagem como você mesmo (email@longe.cu) para o MSA que daí envia ele pra o TO dele.

FROM: email@longe.cu
TO: bleh@gmail.com; bleh@uol.com.br; bleh@longe.cu

O que o MSA faz é enviar via SMTP (e aí entra o MTA) para os MXs responsáveis pelos dominios gmail, uol e longe.cu

Então sua mensagem continua saindo com seu email, da mesma forma de antes, só não vai ser do SMTP do domínio do email, mas isso não faz muita diferença.

Algumas vantagens/desvantagens que eu vejo:

  • Os provedores de conexão tem mais controle sobre o que sai na sua rede de SMTP. Evita que faixas inteiras sejam banidas por causa de 1 spammer enviando emails diretamente lá de dentro;
  • Até onde eu vi isso quebra SPF;
  • Provedores de conexão poderiam bloquear envio de certos tipos de mensagem e etc.

intel

Compartilhe:
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Slashdot
  • StumbleUpon
  • Technorati
  • TwitThis
  • Identi.ca
  • Twitter

Posts relacionados:

  1. Python: Chega de enviar email sem acento! Então, quem já escreveu um script Bash ou mesmo PHP...
  2. Rascunho do artigo sobre SPAM Ai no menu a direita ja tem o link para...
  3. Módulo Security manda ver no meu artigo :) A pedido do Luis, da Módulo, dei permissão para publicarem...
  4. Guia da Desobediência Virtual O GDV é um projeto simples, consistindo em gerar e...
  5. Usando o Tor e Foxy Proxy para acessar o YouTube E então. Pela segunda vez tenho a impressão de que...

2 Comments »

2 Comments on “Como funciona a parada da Gestão da Porta 25”

  1. 1 Daniel Sobral said at 16:32 on maio 22nd, 2009:

    Pois é. O problema disso é o seguinte:

    Opção 1: outra porta. Quando a porta 25 não for mais útil aos spammers, eles usarão outras portas populares. No fim das contas, acaba não adiantando nada.

    Opção 2: quebra a única solução de longo prazo contra spam: Sender ID. Isso porque SOMENTE o servires cadastrados de um domínio podem enviar e-mails por aquele domínio, no Sender ID. Se o MSA de sua operadora enviar o e-mail, ele (o e-mail) não terá o domínio autenticado.

    A única solução para spam é autenticar o cliente no envio ao MTA, e autenticar o domínio do remetente entre MTAs. Ir para uma solução que vai afetar o curto prazo e atrapalhar o longo prazo é uma péssima idéia.

  2. 2 Yves Junqueira said at 22:17 on maio 22nd, 2009:

    Não concordo.

    Essa gerência da porta 25 assume um monte de coisas errada:

    1) Assume que os clientes vão usar o relay do provedor apenas para mandar mensagens “do bem”. Errado, vão usar pra mandar SPAM também. Spammers-de-quintal vão configurar isso manualmente, e botnets/vírus vão dar seu jeito de encontrar esses relay hosts e usá-los também.
    2) Assume que esses os provedores sabem cuidar dos seus servidores e configurá-los corretamente. Muito falso. Vão fazer merda, vão deixar spammer usar o servidor, não vão configurar o PTR DNS do IP, não vão fazer quase nada certo. O servidor vai virar um relay de spam, assim todos os filtros vão marcar as mensagens inocentes como spam também.

    Um amigo caiu numa dessas RBLs malditas porque adicionaram toda uma sub-rede /20 da Embratel, e ele deu azar de ficar na lista negra, porque a Embratel foi/era/é(?) negligente ao lidar com spam vindo de outros clientes.

    Provedores têm todas as ferramentas para combatar SPAM, mas eles são pão duros. Nem mesmo pagam gente capacitada para lidar com denúncias e evitar abusos por parte dos clientes (em outras palavras, tão se lixando para as reclamações que mandam para abuse@provedora-do-caraleo.cu).

    As provedoras brasileiras conseguem ser piores do que a média quanto à lidar com abuso de clientes spammers, e pelo jeito essa história de bloquear porta 25 é pura preguiça – que não funciona de qualquer jeito.


Leave a Reply