+ Responder ao Tópico



  1. #1

    Exclamation Redirecionamento de um dominio para um outro servidor de e-mail

    Tenho dois servidores de e-mail, um com diversos dominios e outro para um dominio exclusivo.
    Um servidor tem um IP válido em uma classe e o outro servidor IP válido totalmente diferente do outro.

    Nesse servidor com diversos dominios, contem um software proprietario de anti-spam.
    Queria fazer com que os e-mail enviados para esse dominio que tem servidor exclusivo fosse primeiro para o servidor no qual tem a ferramente de anti-spam e depois só assim entrege no outro servidor. Que passasse no filtro primeiro no outro servidor e depois fosse para o servidor do dominio correspondente. Tem como?

    Sei la se é assim.. uam ideia que eu tenho é de apontar o DNS desse dominio para esse servidor onde tem o filtro e no transport desse servidor colocaria o IP do servidor onde tem que ser entregue. Isso funciona? Tenho que mexer algo no meu firewall iptables? Alguma liberação de acesso desse IP?

    Estou pesquisando antes de fazer, pois o servidor esta rodando e se der algum problema os clientes ficarão sem e-mail e isso dara uma dor de cabeça imensaaa.

    Se alguem tiver alguma ideia da uma ajuda!

    Ah, utilizo o Debian e o Postfix.

    Valeuuuuuuuu!!
    Última edição por MrJoe; 16-06-2009 às 11:14.

  2. #2

    Padrão

    Seguinte,

    Altera o MX do seu domínio para cair no Servidor Anti-Spam e coloca o transport dele como "smtp:[host/ip]" onde [host/ip] seria o hostname ou ip do seu servidor de destino final.

    Assim tudo que for enviado para o seu dominio vai cair no servidor Anti-Spam e vai encaminhar para o seu servidor de destino final depois de passar pelos content-filters de acordo com a configuração, porem e bom liberar no seu servidor apenas o servidor Anti-Spam para não acontecer de alguem tentar enviar direto pelo seu servidor final, ignorando o MX, você pode usar um "check_client_access" no "smtpd_recipient_restrictions" liberando o [host/ip] do servidor Anti-Spam e colocando um reject no final, lembrando que o "check_client_access" deve ficar abaixo do "reject_unauth_destination", assim você não permite relay do seu anti-spam para a rede, a maioria do pessoal quando vai fazer algo assim coloca o endereço em "mynetworks" abrindo o relay para este host que pode acabar enviando spam (na maioria das vezes através de injeção de código em paginas dinâmicas).

    EX:

    /etc/postfix/main.cf
    --------------------------------------------------------------------------
    smtpd_recipient_restrictions =
    permit_mynetworks,
    reject_unauth_destination,
    check_client_access hash:$config_directory/authorized,
    reject
    --------------------------------------------------------------------------

    /etc/postfix/authorized
    --------------------------------------------------------------------------
    200.200.200.200 OK
    --------------------------------------------------------------------------

    Onde 200.200.200.200 deve ser o IP ou Host do seu Anti-Spam, depois basta um "# postmap /etc/postfix/authorized" para gerar o .db e recarregar o serviço.

    Esta forma de estrutura é mais conhecida como MX Gateway ou Satélite.

    A[]'s



  3. #3

    Padrão

    Sensacional!!!!

    Muito obrigado!

    Topico fechado!!

    Como fecha o topico?

  4. #4

    Padrão

    Bom, feito isso, os e-mails estão passando pelo filtro de spam primeiro e depois entregando no servidor novo. Mas após essa alteração no MX, alguns lugares não estão resolvendo nome do SMTP e do POP tendo que colocar o IP direto nas configurações de e-mail.

    Alguém tem alguma ideia?



  5. #5

    Padrão

    Os registros de DNS estão apontando para os servidores corretos? Foi alterado o servidor de DNS recentemente? Se sim então demora até 48h até que todos os servidores de dns da rede reconheçam estas alterações, se você tiver acesso aos servidores de DNS utilizados por estas pessoas basta reiniciar o serviço ou limpar o cache.

    Neste meio tempo, uma alternativa melhor do que colocar direto o ip, e fornecer um endereço de DNS público que você tenha controle para seus clientes utilizarem, assim as alterações que fizer valerão instantâneamente evitando qualquer problema.

    A[]'s

  6. #6

    Padrão

    Fiz isso em dois dominios, segue abaixo a configuração do DNS desses dominios:

    Dominio aaaaaa.com.br
    ______________________
    $TTL 3h
    @ IN SOA zzz.zzzzzz.com.br. hostmaster.zzzzzz.com.br. (
    2009061901 ; Serial
    28800 ; Atualizacao
    14400 ; Tentativas
    3600000 ; expiracao
    86400) ; TTL minimo
    IN NS zzz.zzzzzz.com.br.
    IN NS xx.xxxxx.com.br.
    IN MX 10 999.99.999.9 (IP DO SERVIDOR FILTRO DE SPAM)
    localhost IN A 127.0.0.1
    web1 IN A 777.77.777.7 (IP DO SERVIDOR DE E-MAIL)
    mail IN CNAME web1
    pop IN CNAME web1
    smtp IN CNAME web1
    www IN CNAME web1
    wwws IN CNAME web1
    webmail IN CNAME web1


    Dominio bbbbbb.com.br
    ______________________
    $TTL 3h
    @ IN SOA zzz.zzzzzz.com.br. hostmaster.zzzzzz.com.br. (
    2009061803 ; Serial
    28800 ; Atualizacao
    14400 ; Tentativas
    3600000 ; expiracao
    86400) ; TTL minimo
    IN NS zzz.zzzzzz.com.br.
    IN NS xx.xxxxx.com.br.
    IN MX 10 999.99.999.9 (IP DO SERVIDOR FILTRO DE SPAM)
    localhost IN A 127.0.0.1
    mail IN A 777.77.777.7 (IP DO SERVIDOR DE E-MAIL)
    pop IN A 777.77.777.7
    smtp IN A 777.77.777.7
    webmail IN A 777.77.777.7
    www IN A 777.77.777.7

    Tem algo errado?

    Pois como disse, a parte de mensagem de e-mail está funcionando passando pelo servidor1 primeiro e repassando para o servidor2.
    Mas quem não utiliza o nosso DNS, não consegue resolver nome do SMTP e POP, e outra, não conseguem abrir o site. Pois o dominio também tem www.



  7. #7

    Padrão

    Como eu disse na mensagem anterior demora um tempo para que suas alterações de DNS se propaguem pela rede, mas uma coisa que você DEVE certificar-se é de que o Domain Master e todos os Slaves estejam com as configurações corretas, você pode simplesmente acertar as configurações no Master e apagar o arquivo das zonas correspondentes nos Slaves e reiniciar o serviço, assim ele vai puxar as configurações do Master.

    Se você não sabe qual servidor está como dono do domínio use o whois pela linha de comando ou pelo registro.br

    Se tudo estiver correto então todos os seus servidores devem pingar os endereços corretamente, e após expirar o cache toda a rede vai ter acesso normalmente, que leva até 48horas (normalmente demora bem menos que isso).

    A[]'s