[MASOCH-L] Ataque mailserver (???)

[Leandro]

Muito interessante sua pergunta André.

O que a gente faz para resolver esse problema é tomar o sinal 5.1.1 do seu
host e alimentar a base de dados do SPFBL.

Quando seu host informa que tal destinatário é inexistente, nosso MX
adiciona ele na lista de inexistentes, que irá virar spamtrap
automaticamente no futuro.

Ocorre que esses MTAs que fazem verificação do sinal 5.1.1 são obrigados a
enviarem antes para uma conta gerada aleatoriamente antes, para ter certeza
que não retornar o sinal 5.1.1 é porque o MTA não manda o sinal e não
porque a conta exista.

Para evitar de inserirmos todos os endereços que retornam sinal 5.1.1,
pegamos os endereços que teve pelo menos 7 vezes um sinal desse, para ter
certeza absoluta que se trata de conta que foi desativada e não de conta
aleatória, ou também aqueles casos que o destinatário come uma letra e tal.

Dito isso, respondendo sua pergunta, pelo que sei sobre o call back é que
ele segue o padrão de descoberta do MX pelo DNS. Então neste caso, o call
back seria feito no nosso MX e não no seu.

Como o SPFBL trata os casos de inexistência, vai retornar o sinal 5.1.1,
como seu fosse seu host fazendo isso. Seria como se a gente tivesse sua
tabela de contas, mas do modo invertido com lista de inexistência invés de
lista da existência. Do ponto de vista do MTA de origem, seria equivalente
as duas formas.

Leandro
SPFBL.net

Em 26 de janeiro de 2017 10:11, Andre Almeida <andre at bnet.com.br> escreveu:

> Leandro, agora me surgiu uma questão aqui, vou compartilhar na lista porque
> pode ajudar mais alguem.
>
> Se utilizamos seus MX do SPFBL para a filtragem de conteúdo, subentende-se
> que os emails com destino ao nosso domínio vão sempre passar primeiro por
> seus MXs para depois serem encaminhadas as mensagens legítimas pra nosso
> MTA.
>
> Nesse caso, no nosso server, eu fiz liberação da porta 25 exclusivamente
> para seu MX, pois vi como desnecessária a liberação global.
> Uma vez que mensagens legítimas não tentariam entregar diretamente porque
> os MX do domínio apontam para vocês e não pra nós.
> O fato de você encaminhar para nosso MTA é irrelevante ao remetente.
>
> Mas nesse caso, analisando o tópico, pode ocorrer de no envio de uma
> mensagem, o destinatário de um email que saia do nosso MTA testar um
> Callback no servidor de origem, e logo, utilizaria a porta 25 para tal que
> cairia no nosso MTA; como a porta 25 estaria aberta somente para os MX do
> SPFBL, o callback irá falhar. Isso poderia causar algum transtorno para
> nós?
> Seria interessante mesmo com o cenário de encaminhamento e filtragem,
> termos a porta 25 habilitada globalmente?
>
>
> Att,
>
> Andre H. de Almeida
>
>
> Em 26 de janeiro de 2017 10:00, Leandro <leandro at spfbl.net> escreveu:
>
> > Anderson,
> >
> > Passamos por isso o tempo todo aqui.
> >
> > A gente usa essas contas inativas para gerar spamtrap. Isso ajuda um
> pouco
> > a mitigar SPAM para outras contas ativas.
> >
> > Mas quando a conta é inexistente e gerada aleatoriamente, possivelmente
> são
> > MTAs externos descobrindo se o seu MTA manda sinal 5.1.1 quando a conta
> não
> > existe. Isso é uma técnica chamada call back:
> >
> > https://en.wikipedia.org/wiki/Callback_verification
> >
> > Se o MTA de destino não manda sinal 5.1.1 na camada SMTP, então o call
> back
> > é inútil e deve ser desconsiderado.
> >
> > Leandro
> > SPFBL.net
> >
> > Em 26 de janeiro de 2017 09:04, Anderson Oliveira <
> > anderson.oliveira54 at gmail.com> escreveu:
> >
> > > Pessoal, bom dia.
> > >
> > > Estou passando por uma situação e gostaria de compartilhar com todos.
> > >
> > > Meu servidor de e-mail ontem a noite passou a receber milhares de
> e-mails
> > > para destinatários que não existem:
> > >
> > > 2017-01-25 21:17:32 1cWWog-0000cO-67 => :blackhole: <
> > pevon at dominio.com.br>
> > > R=virtual_aliases
> > > 2017-01-25 21:17:33 1cWWoj-0000cg-5X => :blackhole: <
> > > instresearch at dominio.com.br> R=virtual_aliases
> > > 2017-01-25 21:17:34 1cWWoj-0000ci-Ex => :blackhole: <
> > > comune.almese.to at dominio.com.br> R=virtual_aliases
> > > 2017-01-25 21:17:34 1cWWoi-0000cT-PO => :blackhole: <
> > > rebecca.dalton at dominio.com.br> R=virtual_aliases
> > > 2017-01-25 21:17:34 1cWWoj-0000ce-JO => :blackhole: <
> > budver at dominio.com.br
> > > >
> > > R=virtual_aliases
> > > 2017-01-25 21:17:35 1cWWoa-0000c2-Bd => :blackhole: <
> > > lualarruda at dominio.com.br> R=virtual_aliases
> > > 2017-01-25 21:17:35 1cWWok-0008MH-Ig => :blackhole: <
> > > stop4698 at dominio.com.br>
> > > R=virtual_aliases
> > >
> > > Estes e-mails são enviados mais pelos mais variados hosts, com isso não
> > > consigo nem realizar o um bloqueio pelo IP do sender.
> > >
> > > Algum de vocês já passou por alguma situação parecida?
> > >
> > >
> > >
> > > *Att.*
> > >
> > > *Anderson Henrique de Oliveira*
> > > __
> > > masoch-l list
> > > https://eng.registro.br/mailman/listinfo/masoch-l
> > >
> > __
> > masoch-l list
> > https://eng.registro.br/mailman/listinfo/masoch-l
> >
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
>