Zimbra Problemas de entrega LMTP (connection refused port 7025)

 Clusterweb, ClusterWeb, Linux, Profissional de TI, Proxy, Redes, Segurança, Zimbra  Comentários desativados em Zimbra Problemas de entrega LMTP (connection refused port 7025)
fev 012019
 

Olá ! Recentemente efetuei uma migração de um Zimbra Network para Cloud e no ambiente não seria configurado um DNS local, utilizando somente o DNS de cache implementado pela própria solução.

Neste cenário, o servidor possui um endereço IP interno configurado, portanto, é utilizado NAT para que o mesmo seja acessado através da Internet. Para exemplificar, vamos assumir as seguintes informações:

Domínio: zimbra.local

IP interno: 192.168.1.1

IP válido: 1.1.1.1

Hostname (interno e externo): mail.zimbra.local

O que precisamos corrigir neste cenário?

O Zimbra efetua as entregas das mensagens locais via LTMP, e como pode ser observado através do parâmetro zimbraMailTransport, é utilizado o nome do servidor. Por padrão, o LMTP irá efetuar resoluções DNS para a entrega das mensagens, portanto, o hostname mail.zimbra.local irá resolver para o IP válido, e pode ocorrer que o ambiente não permita esse acesso.

Como devemos corrigir a entrega LMTP para utilizar o endereço IP interno?

Para que ao entregar as mensagens locais, é preciso informar ao Zimbra que o protocolo LMTP não deve utilizar DNS, e sim resolução interna.

Para isso, além de definir corretamente a entrada no /etc/hosts, precisamaos definir o parâmetro zimbraMtaLmtpHostLookup conforme abaixo:

zmprov ms `zmhostname` zimbraMtaLmtpHostLookup native

zmprov mcf zimbraMtaLmtpHostLookup native

Após as alterações serem efetuadas, NÃO é necessário reiniciar nenhum serviço.

Zimbra Letsencrypt SSL

 Apache2, CentOS 7 / RHEL 7, Clusterweb, ClusterWeb, Linux, Profissional de TI, Redes, Segurança, Zimbra  Comentários desativados em Zimbra Letsencrypt SSL
ago 022018
 

Olá ! Nesse artigo eu gostaria de compartilhar com vocês as orientações para implementar um certificado válido e gratuito da Let’s Encrypt no Zimbra.

(Essa implementação é idêntica para a versões Open Source, Suite Plus e Network)

Tenho observado que mesmo com a divulgação dos certificados gratuitos da Let’s Encrypt e a diminuição do custo de certificados assinados no Brasil em geral, muitos administradores Zimbra ainda não implementaram um certificado válido no seu ambiente.

Vamos ao que interessa ! 

A emissão de certificados pela Let’s Encrypt é bem simples: Você instala o pacote, solicita o certificado com o nome principal e nomes alternativos (opcional) que deseja e a validação é efetuada através de consultas DNS: Se a sua solicitação estiver partindo do endereço IP para qual o(s) endereço(s) resolve(m), o certificado será emitido.

(Também é possível efetuar a validação com uma URL específica, espero abordar isso em um próximo artigo)

A solicitação pode ser executada no próprio servidor Zimbra (se a requisição na Let’s Encrypt chegar com o endereço IP do endereço requisitado), para isso, é necessário parar o serviço de Proxy OU Mailbox (aquele que estiver respondendo pelas requisições dos clientes nas portas 80 e 443):

zmproxyctl stop
zmmailboxdctl stop

Continue reading »

jul 122018
 

O interface de administração do Zimbra é muito boa entretanto ela não permite a criação e edição de listra negra e branca de e-mails ou domínios de e-mail, mas podemos fazer a lista de forma muito simples pelo terminal.

Para executar os comandos abaixo você deve está conectado no servidor com o usuários zimbra:

# su zimbra

Edite o arquivo de configuração salocal.cf.in que fica em /opt/zimbra/conf

$ vim /opt/zimbra/conf/salocal.cf.in

No final no arquivo iremos criar a blacklist e whitelist, vamos até o final e editamos da seguinte forma.

#Lista Negra(Bloqueia por dominio ou e-mail)

blacklist_from usuario@clusterweb.com.br

blacklist_from *@clusterweb.com.br

#Lista Branca(Libera por domínio ou e-mail)

whitelist_from usuario@clusterweb.com.br

whitelist_from *@clusterweb.com.br

Quando colocamos a conta de e-mail exemplo usuario@clusterweb.com.br nós bloqueamos ou liberamos especificamente os e-mails vindos dessa conta, se colocarmos o * antes do @ significa que todas as mensagens estão bloqueadas ou liberadas daquele determinado domínio exemplo *@clusterweb.com.br

Terminada a edição da lista precisamos salvar e sair do arquivo, devido a permissão desse arquivo talvez seja necessário sair com um :wq! Para salvar sem problemas.

Precisamos agora reiniciar os serviços zmmtactl e zmamavisdctl para as listas entrarem em funcionamento.

$ zmmtactl restart

$ zmamavisdctl restart

Com essa criação de lista negra e branca os e-mail não ficarão nem parados na caixa de spam, eles serão bloqueados automaticamente no caso da blacklist e direcionados para a caixa de entrada no caso da whitelist.

Zimbra: Instalando un Certificado gratuito SSL Let’s Encrypt

 Apache2, Clusterweb, ClusterWeb, Linux, Profissional de TI, Segurança, Zimbra  Comentários desativados em Zimbra: Instalando un Certificado gratuito SSL Let’s Encrypt
mar 242018
 

letsencrypt-esSaludos, Let’s Encrypt ha lanzado su Beta hace unos días, llevaba siguiendo el proyecto desde hace unos meses, y parece que por fín está casi listo.

¿Qué es Let’s Encrypt?

Let’s Encrypt es una nueva Entidad Certificadora, es gratis, automatizada y además abierta. Es una buena opción para proteger entornos Zimbra con un Certificado SSL profesional, a coste cero. Hay que tener en cuenta que por ahora se encuentra en estado Beta, y pueden surgir problemas, o incidencias, usarlo siempre bajo vuestra responsabilidad.

Para seguir el proyecto de cerca por favor ir a la web Oficial del Proyecto – https://letsencrypt.org. Además, siempre es bueno leer las preguntas y respuestas frecuentes

Continue reading »

abr 272015
 

Below are the guidelines to manage the distribution list through CLI.

Create domain

   $ zmprov cd domain.com zimbraAuthMech zimbra

Create the delegated admin

   $ zmprov ca  delegatedadmin@example.com <passwd>  zimbraIsDelegatedAdminAccount TRUE

Continue reading »

Instalando e utilizando o Zimbra

 Apache2, Leitura Recomendada, Linux, Profissional de TI, Redes, Segurança, Servidor de E-mail  Comentários desativados em Instalando e utilizando o Zimbra
ago 172014
 

O Zimbra, é uma suite colaborativa de e-mail muito poderosa, cujo foco é ser uma alternativa livre ao Microsoft Exchange. Com suas duas versões disponíveis, a versão Network Edition (NE) e a Open Source, ele consegue, no mínimo equiparar-se a solução oferecida pela Microsoft, tendo a sua versão NE voltada a empresas que precisam de suporte e ferramentas de backup mais avançadas.

Neste artigo, iremos abordar a versão Open Source, a qual não possui o suporte da equipe de desenvolvimento, bem como algumas outras limitações. Limitações estas que não devem impedir o seu funcionamento e aplicação em pequenas e médias empresas.

Caso você prefira, pode efetuar o download da versão Trial do Zimbra Network Edition, para efetuar testes. Continue reading »

abr 232014
 
Instalação e Configuração

Introdução

Como o objetivo é só a instalação do Zimbra, não fiz a instalação do CentOS por entender que já tenham uma Lab com um máquina instalada.

A instalação foi feita do zero, usando a instalação minimal do CentOS, só com o pacotes básicos, pois o Zimbra já inclui todos os pacotes necessários para o seu funcionamento.

Softwares necessários

Para iniciar o processo de configuração, primeiramente precisamos baixar/instalar alguns pacotes. São eles:

  • bind;
  • nc;
  • sysstat;
  • perl;
  • weget;
  • vim;
  • zimbra.

Ao instalar o CentOS, é instalado por default um servidor de e-mail para envio de mensagens locais, o Postfix. Precisamos, assim, parar e remover o Postfix da inicialização, pois o Zimbra já possui o Postfix e, se deixarmos ele rodando, o Zimbra não vai subir.

Sendo assim, vamos parar e tirar o serviço do boot:

# service postfix stop
# chkconfig –del postfix

Agora, vamos instalar os pacotes para podermos iniciar a instalação:

# yum install bind bind-utils nc sysstat perl wget vim

Pronto, agora estamos com o todos o requisitos necessários para a configuração do DNS e a instalação do Zimbra em si. Continue reading »

Migrando Servidores Zimbra

 Clusterweb, Leitura Recomendada, Linux, Servidor de E-mail  Comentários desativados em Migrando Servidores Zimbra
maio 082013
 

O Zimbra é um servidor de colaboração completo, o “lindo” nome é porque ele foi criado pela empresa Zimbra e depois comprado pelo Yahoo e finalmente pela VMware mas como o nome já estava consolidado ficou :-P . Ele é um concorrente direto do Exchange da Microsoft e como ele tem: Email, agenda colaborativa, interface de administração completa, Porta Arquivos e gerenciamento de recursos, possui cliente integrado de Email (Exchange tem o Outlook ele tem o Zimbra Desktop), etc…

Pode ser comprado com Licença de suporte e uso, pode também ser utilizado em sua versão Open Source que conta com todas as funcionalidades principais. Possui muita documentação (wiki.zimbra.com) e integra com LDAP, Active Directory, etc.

Mas eu vou falar hoje sobre migração entre servidores Zimbra, já trabalho com ele há alguns anos e em alguns clientes chegou a hora de atualizar a versão. É uma tarefa simples, dá um pouco de trabalho mas é simples, basta ter um servidor novo instalado e funcionando(basta seguir alguns dos muitos tutoriais que existem por aí para isso :-) ) e fazer a migração.

Já migrei de Zimbra 5.0.9 para 7, de 6 para 8 e de 7 para 8. Esse procedimento funcionou em todas as migrações que fiz para a versão 8 do Zimbra, que é a mais nova e muito mais rápida. Portanto faça em uma ambiente de teste, confira se há igualdade nas contas dos servidores e depois pode fazer a migração. Lembre-se que não é atualizar o software, é migrar para outro servidor com versão mais nova do software.

Esse procedimento não altera nada no servidor de produção, ou seja, pode fazer que continua tudo funcionando.

 

Vamos à migração.

Com os dois servidores na mesma rede, vamos de 192.168.1.250 produção e 192.168.1.251 migração, vamos começar o processo.

Primeiro sincronizamos as contas, podem ser todas ou apenas algumas, no caso faremos com todas. No servidor de migração faremos o serviços através de linha de comando, mas não se preocupe farei um pequeno tutorial sobra a função na interface de administração posteriormente :-) .

Se você tem 10 ou 20 usuários crie de novo e deixe de preguiça :-P , mas se tem 200, 400, 1500, 2500… Faça com scripts que é muito melhor :-)

Primeiro vamos obter uma lista das contas e dados básicos dos usuários com o seguinte procedimento:

Logue no servidor de produção como root e mude para usuário zimbra:
# su – zimbra

Entre no diretório /tmp e crie um diretório contas:
$ cd /tmp
$ mkdir contas

Crie o seguinte script no /tmp que irá obter os dados(nome completo(displayName, primeiro nome(givenName), sobrenome(sn),senha(userPassword) dos usuários e gravá-los nos diretório contas:

vi obtem-contas-zimbra.sh
#!/bin/bash
# Obtemos uma lista de todas as contas do servidor
ZMPROV="/opt/zimbra/bin/zmprov"
for MAIL in $($ZMPROV -l gaa | sort); 	do
		DNOME=$($ZMPROV -l ga $MAIL displayName | grep displayName | awk -F " " '{print $2" "$3" "$4" "$5}')
		PNOME=$($ZMPROV -l ga $MAIL givenName | grep givenName | awk -F " " '{print $2}')
		SNOME=$($ZMPROV -l ga $MAIL sn | grep sn | awk -F " " '{print $2}')
		SENHA=$($ZMPROV -l ga $MAIL userPassword | grep userPassword | awk -F " " '{print $2}')

   		echo "Conta: $MAIL" > contas/dados-$MAIL
   		echo "Display: $DNOME" >> contas/dados-$MAIL
		echo "Nome: $PNOME" >> contas/dados-$MAIL
		echo "Sobrenome: $SNOME" >> contas/dados-$MAIL
		echo "Senha: $SENHA" >> contas/dados-$MAIL
done

Esse script irá criar um arquivo no diretório contas com o nome dados-EMAIL_DA_PESSOA com os dados necessários.

Execute o script da seguinte forma:

$ chmod 755 obtem-contas-zimbra.sh
$ ./obtem-contas-zimbra.sh

Agora basta copiar esse diretório para o servidor de migração(ftp, ssh, rsync, pendrive, cd-rom … use seu recurso preferido).

No servidor de migração logue como root, mude para o usuário zimbra e copie o diretório contas para o /tmp :

# su – zimbra
$ cd /tmp

Agora crie o seguinte script para criar os usuários:

vi cria-contas.sh

#!/bin/bash
# Cria as contas no Zimbra
ZMPROV="/opt/zimbra/bin/zmprov"
for DADOS in $(ls contas); do

	EMAIL=$(grep Conta contas/$DADOS | awk -F " " '{print $2}')
	DNAME=$(grep Display contas/$DADOS | awk -F " " '{print $2" "$3" "$4" "$5}')
	PNAME=$(grep Nome contas/$DADOS | awk -F " " '{print $2}')
	SNAME=$(grep Sobrenome contas/$DADOS | awk -F " " '{print $2}')
	SENHA=$(grep Senha contas/$DADOS | awk -F " " '{print $2}')

	$ZMPROV ca "$EMAIL" "$SENHA" displayName "$DNAME" givenName "$PNAME" sn "$SNAME"
	done

Esse script lê todos os arquivos do diretório contas, transforma os dados que obtivemos no servidor de produção e cria as contas, caso algum dados não exista(displayName, givenName, sn) ele cria com valor padrão do nome da conta. Não podem estar vazios EMAIL e SENHA.

Execute o script da seguinte forma:

$ chmod 755 cria-contas.sh
$ ./cria-contas.sh

Pronto, com os usuários criados vamos aos emails, se pudermos parar o servidor de produção podemos criar exportar as mensagens conta a conta e depois importar no servidor de migração, mas se não pudermos temos um script de sincronia chamado imapsync, que pode nos ajudar.

Vou colocar aqui os dois métodos utilizados para que vocês possam escolher.

O primeiro método iremos parar o recebimento de email, pode ser desligando o acesso externo, pode ser bloqueando as portas de leitura/recebimento, bem você é quem sabe. Vamos ao procedimento:

No servidor de produção, faça o seguinte:

# su – zimbra
$ cd /tmp
$ mkdir mensagens

Agora vamos usar o seguinte script para importar as caixas:

vi obtem-mensagens.sh
#!/bin/bash
# Obtemos uma lista de todas as contas do servidor
ZMPROV="/opt/zimbra/bin/zmprov"
ZMMAILBOX="/opt/zimbra/bin/zmmailbox"
for MAIL in $($ZMPROV -l gaa | sort); 	do
		$ZMMAILBOX -z -m $MAIL getRestURL "//?fmt=tgz" > mensagens/$MAIL.tgz
done

Execute o script da seguinte forma:

$ chmod 755 obtem-mensagens.sh
$ ./obtem-mensagens.sh

Com esse script criamos um arquivos chamado, emaildousuario@dominio.com.br.tgz dentro do diretório mensagens, agora basta compartilhar esse diretório(copiar pode ser inviável se for muito grande, eu lidei com diretórios com mais de 200GB e sei disso :-) ), pode compartilhar via NFS, SMB, CIFS, GlusterFS, o que você desejar, desde que compartilhe com o servidor de migração.

No servidor de migração entre no diretório onde as mensagens foram compartilhadas e faça o seguinte como usuário zimbra(ele tem que ter direito de leitura/escrita no diretório para criar o script e para ler os arquivos. Ex: /mnt/mensagens

# su – zimbra
$ cd /mnt/

Crie o seguinte script:

vi importa-mensagens.sh

#!/bin/bash
# Obtemos uma lista de todas as contas do servidor
ZMPROV="/opt/zimbra/bin/zmprov"
ZMMAILBOX="/opt/zimbra/bin/zmmailbox"
for MAIL in $($ZMPROV -l gaa | sort); 	do
                $ZMMAILBOX -z -m $MAIL postRestURL "//?fmt=tgz&resolve=reset" mensagens/$MAIL.tgz 
done

Execute o script da seguinte forma:

$ chmod 755 importa-mensagens.sh
$ ./importa-mensagens.sh

Pronto, todas as mensagens estão importadas, agora basta conferir e habilitar o servidor novo para receber e enviar as mensagens.

Mas se você não pode parar o servidor para exportar/importar as mensagens pode usar o script imasync para fazer a sincronia com os servidores online.

Utilizei a versão 1.3.15, as anteriores deram erro.

Já estando com as contas criadas lembre de liberar o login em texto plano (para a migração apenas), crie no servidor de migração o seguinte script:

vi migra-mensagens.sh
#!/bin/bash
ZMPROV="/opt/zimbra/bin/zmprov"
for USER in $($ZMPROV -l gaa); do

imapsync --nosyncacls --host1 192.168.1.250 --host2 192.168.1.251 --authmech1 PLAIN --authmech2 PLAIN --ssl1 --user1 $USER --authuser1 admin@dominio.com.br --password1 'senha_do_admin_zimbra_producao' --ssl2 --user2 $USER --authuser2 admin@dominio.com.br --password2 'senha_do_admin_zimbra_migracao'

done

Agora execute:

$ chmod 755 migra-mensagens.sh
$ ./migra-mensagens.sh

Pronto, contas e mensagens criadas. Se o servidor não for entrar em produção no dia, basta repetir o script que ele atualiza as mensagens que ainda não estão no servidor de migração.

Zimbra 8.0 no CentOS 6.3

 Linux, Servidor de E-mail  Comentários desativados em Zimbra 8.0 no CentOS 6.3
out 252012
 
Instalação e Configuração

Introdução

Como o objetivo é só a instalação do Zimbra, não fiz a instalação do CentOS por entender que já tenham uma Lab com um máquina instalada.

A instalação foi feita do zero, usando a instalação minimal do CentOS, só com o pacotes básicos, pois o Zimbra já inclui todos os pacotes necessários para o seu funcionamento.

Softwares necessários

Para iniciar o processo de configuração, primeiramente precisamos baixar/instalar alguns pacotes. São eles:

  • bind;
  • nc;
  • sysstat;
  • perl;
  • weget;
  • vim;
  • zimbra.

Ao instalar o CentOS, é instalado por default um servidor de e-mail para envio de mensagens locais, o Postfix. Precisamos, assim, parar e remover o Postfix da inicialização, pois o Zimbra já possui o Postfix e, se deixarmos ele rodando, o Zimbra não vai subir.

Sendo assim, vamos parar e tirar o serviço do boot:

# service postfix stop
# chkconfig –del postfix

Agora, vamos instalar os pacotes para podermos iniciar a instalação:

# yum install bind bind-utils nc sysstat perl wget vim

Pronto, agora estamos com o todos o requisitos necessários para a configuração do DNS e a instalação do Zimbra em si.

Configurando

Bom, agora com o pacotes instalados em seu sistema, vamos para à parte de configuração do named. Execute os comandos:

# cd /etc/
# cp -p named.conf named.conf-original
# > named.conf
# vim named.conf

Adicionaremos o seguinte conteúdo ao arquivo “named.conf”:

options {
        directory "/var/named";
        dump-file "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        allow-query { 127.0.0.1; 192.168.0.0/24; };
        allow-recursion { 127.0.0.1; 192.168.0.0/24; };
        forwarders { 8.8.8.8; 8.8.4.4; };
        forward first;
        notify no;
};
controls {
        inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
};
zone "." IN {
        type hint;
        file "named.ca";
};
zone "zmexemplo.com.br" IN {
        type master;
        file "db.zmexemplo.com.br";
};
include "/etc/rndc.key";

Agora, criaremos o arquivo “db.zmexemplo.com.br”, este arquivo deve estar em /var/named/:

# cd /var/named/

# vim db.zmexemplo.com.br
$TTL    86400
@       IN      SOA     zmail.zmexemplo.com.br. root.zmail.zmexemplo.com.br. (
                                10118      ; Serial
                                43200      ; Refresh
                                3600       ; Retry
                                3600000    ; Expire
                                2592000 )  ; Minimum
          IN          NS         zmail.zmexemplo.com.br.
          MX         10          zmail.zmexemplo.com.br.
zmail            IN          A          192.168.0.252

Feito isso, agora iremos gerar a chave:

# rndc-confgen -a -c /etc/rndc.key

Obs.: Deve demorar uns minutinhos.

Configurando o /etc/resolv.conf:

# vim /etc/resolv.conf

Edite:

search zmexemplo.com.br
nameserver 192.168.0.252

Testando o serviço DNS

Testando a configuração do named:

# service named configtest

No retorno deste comando, deve vir algo assim:

zone zmexemplo.com.br/IN: loaded serial 10118

Se estiver tudo ok, execute:

# service named restart

Caso dê algum erro, verifique no /var/log/messenges. Se tiver algum erro de permissão, verificar a permissão com:

# ls -l /etc/rndc.key

Ou, faça da seguinte maneira:

# chown root:named /etc/rndc.key
# service named restart [ok] está tudo certo

Se não deu erro, podemos continuar. Agora vamos editar o /etc/hosts:

# vim /etc/hosts

Edite:

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
192.168.0.252 zmail.zmexemplo.com.br zmail
::1       localhost localhost.localdomain localhost6 localhost6.localdomain6

Feito assim, salve a configuração a partiremos para testar o serviço DNS:

# dig +short zmail.zmexemplo.com.br

No retorno do comando dig, deverá vir o IP do servidor. No meu caso:

192.168.0.252
# dig -x 192.168.0.252 # Numero do servidor

Assim, terminamos essa parte. Agora vamos iniciar a instalação do Zimbra.

Baixando e instalando o Zimbra 8

Agora, vamos baixar e instalar o Zimbra Open Source Edition 8 x64, para RHEL. Como estamos utilizando CentOS, vamos baixar este arquivo:

# wget http://files2.zimbra.com/downloads/8.0.0_GA/zcs- 8.0.0_GA_5434.RHEL6_64.20120907144639.tgz

Extraindo o arquivo com o tar:

# tar -xvf zcs-8.0.0_GA_5434.RHEL6_64.20120907144639
# cd zcs-8.0.0_GA_5434.RHEL6_64.20120907144639

Iniciando a instalação:

# ./install.sh –platform-override

O comando –platform-override, é mais ou menos isso: “Subscreva e ignore a plataforma”.

Como baixamos para RHEL e nosso servidor é CentOS, o Zimbra chia, é para isso que serve o comando.

Quanto aparecer esta pergunta:

Do you agree with the terms of the software license agreement? [N] y

Colocamos y e apertamos ENTER.

Abaixo, deixamos tudo como default do Zimbra, só acrescentamos “Y” onde está “Y”, e “N” onde está “N”:

Select the packages to install:

Install zimbra-ldap [Y] y

Install zimbra-logger [Y] y

Install zimbra-mta [Y] y

Install zimbra-snmp [Y] y

Install zimbra-store [Y] y

Install zimbra-apache [Y] y

Install zimbra-spell [Y] y

Install zimbra-memcached [N] n

Install zimbra-proxy [N] n
Install anyway? [N] y [e dê um ENTER]
The system will be modified. Continue? [N] y [e dê um ENTER]

Agora, é só aguardar a instalação dos serviços do Zimbra.

Ao terminar, ocorrerá esse erro: ele fala que não conseguiu resolver o mx do domínio zmail.zmexemplo.com.br, pois zmail não é mx e o mx é zmexemplo.com.br, então colocamos Yes [dê ENTER].

DNS ERROR resolving MX for zmail.zmexemplo.com.br
It is suggested that the domain name have an MX record configured in DNS
Change domain name? [Yes]Yes

E ficará da seguinte forma:

Create domain: [zmail.zmexemplo.com.br] zmexemplo.com.br [de ENTER]

A próxima etapa é configurar a senha do admin. Irá surgir as opções:

Main menu
   1) Common Configuration:
   2) zimbra-ldap:                  Enabled
   3) zimbra-store:                 Enabled
        +Create Admin User:             yes
        +Admin user to create:          admin@zmexemplo.com.br
******* +Admin Password             UNSET
        +Anti-virus quarantine user:        virus-quarantine.hnh04bvgxu@zmexemplo.com.br
        +Enable automated spam training:    yes
        +Spam training user:                spam.0wby7p2sr@zmexemplo.com.br
        +Non-spam(Ham) training user:       ham.i7csumon8@zmexemplo.com.br
        +SMTP host:                 zmail.zmexemplo.com.br
        +Web server HTTP port:          80
        +Web server HTTPS port:         443
        +Web server mode:               https
        +IMAP server port:              143
        +IMAP server SSL port:          993
        +POP server port:               110
        +POP server SSL port:           995
        +Use spell check server:            yes
        +Spell server URL:              http://zmail.zmexemplo.com.br:7780/aspell.php
        +Configure for use with mail proxy: FALSE
        +Configure for use with web proxy:  FALSE
        +Enable version update checks:      TRUE
        +Enable version update notifications:   TRUE
        +Version update notification email: admin@zmexemplo.com.br
        +Version update source email:       admin@zmexemplo.com.br
   4) zimbra-mta:                   Enabled
   5) zimbra-snmp:                  Enabled
   6) zimbra-logger:                    Enabled
   7) zimbra-spell:                 Enabled
   8) Default Class of Service Configuration:
   r) Start servers after configuration     yes
   s) Save config to file
   x) Expand menu
   q) Quit

Escolheremos acima, as opções 3 e 4. Os resultados dessas opções, você confere abaixo:

Password for admin@zmexemplo.com.br (min 6 characters): [1AIAXRBsJ] SENHADOADMIN

Usado para criar as futuras contas de e-mail. A opção ‘r’ retorna, ‘a’ para salvar, ou Yes para salvar a configuração no arquivo.

Ele pedirá para notificar a VMware Zimbra do tanto de instalação que tem, no meu caso, eu coloquei “No”, pois como é uma instalação de teste não irá ser publicada e não há necessidade.

Quanto aparecer:

Configuration complete – press return to exit

Pronto, a instalação está feita.

Depois execute:

# su – zimbra

$ Zmcontrol status    # Verifica os serviços que estão rodando
$ Zmcontrol stop    # Para os serviços do Zimbra
$ Zmcontrol start    # Inicia os serviços do Zimbra

Firewall – Chat – Screenshots

Para quem usa um firewall, como via de regra, é fazer a liberação das portas no firewall para que o Zimbra funcione (envie e receba dados). Como no meu caso foi só para teste, eu desabilitei o firewall.

Um dos inúmeros recursos interessantes do Zimbra é o Zimlets, que tem a função, entre outras, que você pode ir adicionando, do chat. Este é um recurso que pode ser liberado de dentro do e-mail para os contatos do próprio domínio.

Então mãos à obra, vamos carpi. (hehehe)

Vamos logar com o usuário Zimbra:

# su – zimbra

Depois, basta executar:

$ zmprov -l -v mcf zimbraXMPPEnabled TRUE
$ zmprov -v mc default zimbraFeatureIMEnabled TRUE
$ zmprov -v mc default zimbraFeatureInstantNotify TRUE
$ zmcontrol stop
$ zmcontrol start

Screenshots

Uns screenshots das telas do Zimbra:

Linux: Zimbra 8.0 no 
CentOS 6.3   Linux: 
Zimbra 8.0 no CentOS 6.3   Linux: Zimbra 
8.0 no CentOS 6.3

Conclusão

Esta instalação foi feita em um ambiente de teste com Zimbra 8, para um ambiente de testes para estudos e conhecimento da nova versão da ferramenta.

Já para ambiente de produção, seria aconselhável o Zimbra 7.2.

Para visualizar o Zimbra no navegador, acesse:

– Esse é o console do Admin:

  • https://IP_DO_SERVIDOR:7071

– Interface do Webmail:

  • https://IP_DO_SERVIDOR

Dkim-filter.conf

 Linux, Proxy, Servidor de E-mail  Comentários desativados em Dkim-filter.conf
ago 232012
 

NAME

       dkim-filter.conf - Configuration file for dkim-filter

LOCATION

       /etc/mail/dkim-filter.conf

DESCRIPTION

       dkim-filter(8)  implements  the  DKIM  specification  for  signing  and
       verifying e-mail messages on a per-domain  basis.   This  file  is  its
       configuration file, read on startup only.

       Blank  lines  are ignored.  Lines containing a hash ("#") character are
       truncated at the hash character to allow for comments in the file.

       Other content should be the name of  a  parameter,  followed  by  white
       space,  followed  by  the  value  of that parameter, each on a separate
       line.

       For parameters which are Boolean in nature, only the first byte of  the
       value  is  processed.  For positive values, the following are accepted:
       "T", "t", "Y", "y",  "1".   For  negative  values,  the  following  are
       accepted: "F", "f", "N", "n", "0".

       Many,  but  not  all, of these parameters are also available as command
       line options to dkim-filter(8).  However, new parameters are  generally
       not  added  as  command  line options so the complete set of options is
       available here, and thus use of the configuration file  is  encouraged.
       In  some  future  release, the set of available command line options is
       likely to get trimmed.

       See the dkim-filter(8) man page for details  about  how  and  when  the
       configuration file contents are reloaded.

PARAMETERS

       AllowSHA1Only (Boolean)
              Permit verify mode when only SHA1 support is available.  RFC4871
              requires that verifiers implement both SHA1 and SHA256  support.
              Setting  this feature changes the absence of SHA256 support from
              an error to a warning.

       AlwaysAddARHeader (Boolean)
              Add  an  "Authentication-Results:"  header  even   to   unsigned
              messages  from domains with no "signs all" policy.  The reported
              DKIM result will be "none" in  such  cases.   Normally  unsigned
              mail  from  non-strict domains does not cause the results header
              to be added.

       AlwaysSignHeaders (string)
              Specifies a list of headers which  should  be  included  in  all
              signature  header  lists  (the  "h="  tag) even if they were not
              present at the time the signature  was  generated.   The  string
              should  be  a comma-separated list of header names.  The list is
              empty by default.  The purpose of listing an absent header is to
              prevent  its addition between the signer and the verifier, since
              the verifier would include that header if  it  were  added  when
              performing verification, which would mean the signed message and
              the verified message were different and the  verification  would
              fail.

       AutoRestart (Boolean)
              Automatically  re-start  on  failures.  Use with caution; if the
              filter fails instantly after it starts, this can cause  a  tight
              fork(2) loop.

       AutoRestartCount (integer)
              Sets  the maximum automatic restart count.  After this number of
              automatic restarts, the filter will give up  and  terminate.   A
              value of 0 implies no limit; this is the default.

       AutoRestartRate (string)
              Sets  the  maximum automatic restart rate.  If the filter begins
              restarting faster than the rate defined here, it  will  give  up
              and  terminate.   This is a string of the form n/t[u] where n is
              an integer limiting the count of restarts in the given  interval
              and  t[u]  defines  the  time interval through which the rate is
              calculated; t is  an  integer  and  u  defines  the  units  thus
              represented ("s" or "S" for seconds, the default; "m" or "M" for
              minutes; "h" or "H" for  hours;  "d"  or  "D"  for  days).   For
              example,  a  value  of  "10/1h" limits the restarts to 10 in one
              hour.  There is no default, meaning restart rate is not limited.

       Background (Boolean)
              Normally  dkim-filter  forks  and exits immediately, leaving the
              service running in the background.  This  flag  suppresses  that
              behaviour so that it runs in the foreground.

       BodyLengths (Boolean)
              Requests  that dkim-filter include the "l=" body length tag when
              generating signatures.  This indicates to the verifier that only
              a  certain  amount  of the original message was signed, allowing
              tolerance of things like  mailing  list  managers  which  append
              list-specific   text  to  the  end  of  mailings  it  processes.
              However, this also  enables  an  abuse  attack.   See  the  DKIM
              specification for more information.

       Canonicalization (string)
              Selects  the  canonicalization method(s) to be used when signing
              messages.  When verifying, the message’s DKIM-Signature:  header
              specifies  the  canonicalization  method.  The recognized values
              are relaxed and simple as defined  by  the  DKIM  specification.
              The  default  is  simple.   The  value may include two different
              canonicalizations separated by a slash ("/") character, in which
              case  the first will be applied to the headers and the second to
              the body.

       ClockDrift (integer)
              Sets the tolerance in seconds to  be  applied  when  determining
              whether  a  signature  was  either  expired  or generated in the
              future.  The default is 300.

       Diagnostics (Boolean)
              Requests the inclusion of "z=" tags in signatures, which  encode
              the  original  header  set  for use by verifiers when diagnosing
              verification failures.  Not recommended for normal operation.

       DNSTimeout (integer)
              Sets the DNS timeout  in  seconds.   A  value  of  0  causes  an
              infinite  wait.   The  default  is  5.  Ignored if not using the
              asynchronous resolver  package.   See  also  the  NOTES  section
              below.

       Domain (string)
              A comma-separated list of domains whose mail should be signed by
              this filter.  Mail from other domains will  be  verified  rather
              than being signed.

              The  value  of  this parameter may also be a filename from which
              domain names will be read.  The "#" character in such a file  is
              assumed  to  indicate  a comment.  An absolute path must be used
              (i.e. the first character must be a "/").

              In either case, the  domain  name(s)  may  contain  the  special
              character  "*" which is treated as a wildcard character matching
              zero or more characters in a domain name.

       ExternalIgnoreList (string)
              Identifies a file  of  "external"  hosts  which  may  send  mail
              through  the  server  as  one  of  the  signing  domains without
              credentials as such.  Basically suppresses  the  "external  host
              (hostname)  tried  to  send  mail  as  (domain)"  log  messages.
              Entries in the file should be of the same form as those  of  the
              PeerList option below.  The list is empty by default.

       FixCRLF (Boolean)
              Requests that the DKIM library convert bare CRs and LFs to CRLFs
              during body canonicalization, anticipating that an MTA somewhere
              before  delivery will do that conversion anyway.  The default is
              to leave them as-is.

       Include (string)
              Names  a  file  to  be  opened  and  read   as   an   additional
              configuration  file.   Nesting  is  allowed to a maximum of five
              levels.

       InternalHosts (string)
              Identifies a file of internal hosts whose mail should be  signed
              rather than verified.  Entries in this file follow the same form
              as those of the PeerList option below.  If  not  specified,  the
              default of "127.0.0.1" is applied.  Naturally, providing a value
              here overrides the default, so if mail from 127.0.0.1 should  be
              signed,  the  list  provided  here  should  include that address
              explicitly.

       KeyFile (string)
              Gives the location of a PEM-formatted private key to be used for
              signing all messages.  Ignored if KeyList is defined.

       KeyList (string)
              Gives  the  location  of  a  file listing rules for signing with
              multiple keys.  If present, overrides any KeyFile setting in the
              conifguration file.  The file named here should contain a set of
              lines of the  form  sender-pattern:signing-domain:keypath  where
              sender-pattern  is  a  pattern  to match against message senders
              (with the special character "*" interpreted  as  "zero  or  more
              characters"),  signing-domain  is  the domain to announce as the
              signing domain when generating signatures, and  keypath  is  the
              path  to  the  PEM-formatted  private key to be used for signing
              messages which match the sender-pattern.  The selector  used  in
              the  signature  will be the filename portion of keypath.  If the
              file referenced by keypath cannot be opened, the filter will try
              again  by appending ".pem" and then ".private" before giving up.

       LogWhy (boolean)
              If logging is enabled (see Syslog below), issues  very  detailed
              logging  about  the logic behind the filter’s decision to either
              sign a message or verify it.  The logic behind the  decision  is
              non-trivial  and can be confusing to administrators not familiar
              with its operation.  A description of how the decision  is  made
              can be found in the OPERATIONS section of the dkim-filter(8) man
              page.  This causes a large increase in the amount  of  log  data
              generated for each message, so it should be limited to debugging
              use and not enabled for general operation.

       MacroList (string)
              Defines a set of MTA-provided macros which should be checked  to
              see  if  the  sender  has been determined to be a local user and
              therefore whether or not the message should  be  signed.   If  a
              value  is  specified,  the value of the macro must match a value
              specified (matching is case-sensitive), otherwise the macro must
              be  defined  but  may  contain  any  value.  The set is empty by
              default.    The   general    format    of    the    string    is
              test1[,test2[,...]]    where   a   "test"   is   of   the   form
              macro[=value1[|value2[|...]]]; if one or more value  is  defined
              then  the  macro  must  be  set  to  one  of  the listed values,
              otherwise the macro must be set but can contain any value.

       MaximumHeaders (integer)
              Defines the maximum number  of  bytes  the  header  block  of  a
              message  may  consume before the filter will reject the message.
              This mitigates a denial-of-service  attack  in  which  a  client
              connects  to  the  MTA and begins feeding an unbounded number of
              header fields of arbitrary size; since the filter keeps a  cache
              of  these,  the  attacker  could cause the filter to allocate an
              unspecified amount of memory.  The default is 65536; a value  of
              0 removes the limit.

       MaximumSignedBytes (integer)
              Specifies  the  maximum  number  of  bytes of message body to be
              signed.  Messages shorter than this  limit  will  be  signed  in
              their  entirety.   Setting  this  value forces BodyLengths to be
              "True".

       MilterDebug (integer)
              Sets the debug level to be requested from  the  milter  library.
              The default is 0.

       Minimum (string)
              Instructs  the  verification  code  to fail messages for which a
              partial  signature  was  received.   There  are  three  possible
              formats:  min  indicating at least min bytes of the message must
              be signed (or if the message is smaller than min then all of  it
              must be signed); min% requiring that at least min percent of the
              received message must be signed; and min+ meaning there  may  be
              no  more than min bytes of unsigned data appended to the message
              for it to be considered valid.

       Mode (string)
              Selects operating modes.   The  string  is  a  concatenation  of
              characters   which  indicate  which  mode(s)  of  operation  are
              desired.  Valid modes are s  (signer)  and  v  (verifier).   The
              default  is  sv  except in test mode (see the dkim-filter(8) man
              page) in which case the default is v.

       MTA (string)
              A comma-separated list  of  MTA  names  (a  la  the  sendmail(8)
              DaemonPortOptions Name parameter) whose mail should be signed by
              this filter.  There is no default.

       OmitHeaders (string)
              Specifies a  list  of  headers  which  should  be  omitted  when
              generating  signatures.   The string should be a comma-separated
              list of header names.  If an entry in the list names any  header
              which  is  mandated  by  the  DKIM  specification,  the entry is
              ignored.  A set of headers is listed in the  DKIM  specification
              as  "SHOULD  NOT" be signed; the default list for this parameter
              contains  those  headers   (Return-Path,   Received,   Comments,
              Keywords,  Bcc,  Resent-Bcc  and  DKIM-Signature).   To  omit no
              headers, simply use the string "-" (or  any  string  which  will
              match  no  headers).   Note  that  specifying  a  list with this
              parameter replaces the default entirely.

       On-BadSignature (string)
              Selects the action  to  be  taken  when  a  signature  fails  to
              validate.    Possible   values   (with   abbreviated   forms  in
              parentheses): accept (a) accept the message; discard (d) discard
              the  message;  tempfail  (t)  temp-fail  the message; reject (r)
              reject the message.  The default is accept.

       On-Default (string)
              Selects the action to be taken when any verification or internal
              error  of any kind is encountered.  This is processed before the
              other "On-" values so it  can  be  used  as  a  blanket  setting
              followed by specific overrides.

       On-DNSError (string)
              Selects  the  action  to  be taken when a transient DNS error is
              encountered.  Possible values are the  same  as  those  for  On-
              BadSignature.  The default is tempfail.

       On-InternalError (string)
              Selects  the  action  to be taken when an internal error of some
              kind is encountered.  Possible values are the same as those  for
              On-BadSignature.  The default is tempfail.

       On-NoSignature (string)
              Selects  the action to be taken when a message arrives unsigned.
              Possible values are the same as those for On-BadSignature.   The
              default is accept.

       On-Security (string)
              Selects the action to be taken when a message arrives containing
              properties that may be a security concern.  Possible values  are
              the same as those for On-BadSignature.  The default is tempfail.

       On-SignatureMissing (string)
              Selects the action to be taken when a message  arrives  unsigned
              from  a  domain  which advertises a "we sign everything" policy.
              Possible values are the same as those for On-BadSignature.   The
              default is accept.

       PeerList (string)
              Identifies  a  file  of  "peers"  which identifies clients whose
              connections  should  be  accepted  without  processing  by  this
              filter.  The file should contain on each line a hostname, domain
              name  (e.g.  ".example.com"),  IP  address,  an   IPv6   address
              (including   an   IPv4  mapped  address),  or  a  CIDR-style  IP
              specification (e.g. "192.168.1.0/24").  An entry beginning  with
              a  bang  ("!")  character  means  "not",  allowing exclusions of
              specific hosts that are otherwise members of larger  sets.   The
              order of entries in this file is therefore significant.

       PidFile (string)
              Specifies  the path to a file which should be created at process
              start containing the process ID.

       POPDBFile (string)
              Requests that the filter consult a POP  authentication  database
              named  in the string for IP addresses that should be allowed for
              signing.  The filter must be compiled with the POPAUTH  flag  to
              enable this feature, since it adds a library dependency.

       Quarantine (Boolean)
              Requests that messages which fail verification be quarantined by
              the MTA.  (Requires a sufficiently recent version of the  milter
              library.)

       QueryCache (Boolean)
              Instructs  the  DKIM  library to maintain its own local cache of
              keys and policies retrieved from DNS, rather than relying on the
              nameserver  for caching service.  Useful if the nameserver being
              used by the filter is not local.  The filter  must  be  compiled
              with  the QUERY_CACHE flag to enable this feature, since it adds
              a library dependency.

       RemoveARAll (Boolean)
              Removes all Authentication-Results:  header  fields  which  also
              satisfy  the  requirements  of  RemoveARFrom below.  By default,
              only those containing a DKIM result are removed.

       RemoveARFrom (string)
              Lists patterns of hostnames whose Authentication-Results: header
              fields  should  be  removed  before  the  message  is passed for
              delivery.  By default only  those  headers  matching  the  local
              host’s canonical name will be removed.  If more than one pattern
              is desired, the list should  be  comma-separated.   Matching  is
              only  done  on  full  hostnames  (e.g. "host.example.com") or on
              domain names (e.g. ".example.com").

       RemoveOldSignatures (Boolean)
              Removes all existing signatures when operating in signing  mode.

       SignHeaders (string)
              Specifies  the  list  of  headers  which should be included when
              generating signatures.  The string should be  a  comma-separated
              list  of  header  names.   If the list omits any header which is
              mandated by the DKIM specification, those headers are implicitly
              added.    By   default,   those   headers  listed  in  the  DKIM
              specification as "SHOULD"  be  signed  will  be  signed  by  the
              filter.   Specifying  a  list  here replaces that list entirely.
              See the OmitHeaders configuration option for more information.

       Selector (string)
              Defines the name  of  the  selector  to  be  used  when  signing
              messages.   See  the  DKIM specification for details.  Used only
              when signing with a single key; see the KeyList parameter  above
              for more information.

       SendReports (Boolean)
              If  true,  when  a  signature verification fails and the signing
              site advertises a reporting address (i.e.   r=user@host  in  its
              policy record), the filter will send a structured report to that
              address containing details needed to reproduce the problem.

       SignatureAlgorithm (string)
              Selects the signing algorithm to use when generating signatures.
              If  the  filter  was  compiled against version 0.9.8 or later of
              OpenSSL then both rsa-sha1 and rsa-sha256 are available and  the
              latter  is the default.  Otherwise, only the former is available
              and it is (obviously) the default.

       SignatureTTL (integer)
              Sets the time-to-live, in seconds, of  signatures  generated  by
              the  filter.   If  not  set,  no  expiration  time  is  added to
              signatures.

       Socket (string)
              Specifies the socket that should be established by the filter to
              receive   connections  from  sendmail(8)  in  order  to  provide
              service.  socketspec is in one of two  forms:  local:path  which
              creates   a  UNIX  domain  socket  at  the  specified  path,  or
              inet:port[@host] which creates a TCP  socket  on  the  specified
              port.   If  the  host is not given as either a hostname or an IP
              address, the socket will be listening on all  interfaces.   This
              option  is  mandatory either in the configuration file or on the
              command line.

       StrictTestMode (Boolean)
              Selects strict CRLF mode during testing (see the -t command line
              flag  in  the  dkim-filter(8)  man page); messages for which all
              header  fields  and  body  lines  are  not  CRLF-terminated  are
              considered malformed and will produce an error.

       SubDomains (Boolean)
              Sign  subdomains of those listed by the Domain parameter as well
              as the actual domains.

       Syslog (Boolean)
              Log via calls to syslog(3) any interesting activity.

       SyslogFacility (string)
              Log via calls  to  syslog(3)  using  the  named  facility.   The
              facility   names   are   the   same   as  the  ones  allowed  in
              syslog.conf(5). The default is mail .

       SyslogSuccess (Boolean)
              Log  via  calls  to  syslog(3)  additional  entries   indicating
              successful signing or verification of messages.

       TestPublicKeys (string)
              Names  a  file  from which public keys should be read.  Intended
              for use only during automated testing.

       UMask (integer)
              Requests a  specific  permissions  mask  to  be  used  for  file
              creation.   This  only  really applies to creation of the socket
              when Socket specifies a UNIX domain socket, and to  the  PidFile
              (if any); temporary files are created by the mkstemp(3) function
              which enforces a specific file mode on  creation  regardless  of
              the process umask.  See umask(2) for more information.

       UserID (string)
              Attempts   to   become  the  specified  userid  before  starting
              operations.  The value  is  of  the  form  userid[:group].   The
              process  will be assigned all of the groups and primary group ID
              of the named userid unless an alternate group is specified.

       UseASPDiscard (Boolean)
              If "true", requests discard of messages which are determined  to
              be suspicious according to the author domain’s published signing
              procedure (ASP) record if that record also recommends discard of
              such messages.

       X-Header (Boolean)
              Causes  dkim-filter  to  add a header indicating the presence of
              this filter in  the  path  of  the  message  from  injection  to
              delivery.   The  product’s  name,  version,  and  the job ID are
              included in the header’s contents.

NOTES

       When using DNS timeouts (see the DNSTimeout option above), be sure  not
       to  use  a  timeout  that  is  larger  than  the timeout being used for
       interaction between sendmail and the filter.  Otherwise, the MTA  could
       abort  a  message  while  waiting for a reply from the filter, which in
       turn is still waiting for a DNS reply.

VERSION

       This man page covers version 2.5.4 of dkim-filter.

COPYRIGHT

       Copyright (c) 2007, 2008, Sendmail, Inc. and its suppliers.  All rights
       reserved.

SEE ALSO

       dkim-filter(8), sendmail(8)

       RFC4871 - DomainKeys Identified Mail

       Authentication-Results Internet Draft

Configuring Zimbra As A Secondary / Backup MX Server

 Clusterweb, Servidor de E-mail  Comentários desativados em Configuring Zimbra As A Secondary / Backup MX Server
maio 162012
 

Lets assume that we have two mail servers

primary.mailserver.com
secondary.mailserver.com

What we ultimately want is secondary.mailserver.com to accept, store ( and forward ) mail for primary.mailserver.com when it goes down.

 

On secondary.mailserver.com from within the administration console add the domain in question you are configuring. From console on secondary.mailserver.com run the following commands as user zimbra

 

zmprov md domain.com zimbraMailCatchAllAddress @domain.com
zmprov md domain.com zimbraMailCatchAllForwardingAddress @domain.com
zmprov md domain.com zimbraMailTransport smtp:primary.mailserver.com

 

In DNS your primary mail server should have a lower weighting ( 1 in this example ) then your secondary (10) and should look something like this.

 

[root@mailhost ~]# dig mx mailserver.com

; <<>> DiG 9.7.3-P3-RedHat-9.7.3-8.P3.el6_2.1 <<>> mx mailserver.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43716
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mailserver.com.            IN    MX

;; ANSWER SECTION:

mailserver.com.        3600    IN    MX    10 secondary.mailserver.com.
mailserver.com.        3600    IN    MX    1 primary.mailserver.com.

;; Query time: 104 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Jan  6 15:02:06 2012
;; MSG SIZE  rcvd: 72

Configuring Zimbra As A Secondary / Backup MX Server

 Clusterweb, Linux, Servidor de E-mail  Comentários desativados em Configuring Zimbra As A Secondary / Backup MX Server
maio 032012
 

Lets assume that we have two mail servers

primary.mailserver.com
secondary.mailserver.com

What we ultimately want is secondary.mailserver.com to accept, store ( and forward ) mail for primary.mailserver.com when it goes down.

 

On secondary.mailserver.com from within the administration console add the domain in question you are configuring. From console on secondary.mailserver.com run the following commands as user zimbra

 

zmprov md domain.com zimbraMailCatchAllAddress @domain.com
zmprov md domain.com zimbraMailCatchAllForwardingAddress @domain.com
zmprov md domain.com zimbraMailTransport smtp:primary.mailserver.com

 

In DNS your primary mail server should have a lower weighting ( 1 in this example ) then your secondary (10) and should look something like this.

 

[root@mailhost ~]# dig mx mailserver.com

; <<>> DiG 9.7.3-P3-RedHat-9.7.3-8.P3.el6_2.1 <<>> mx mailserver.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43716
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mailserver.com.            IN    MX

;; ANSWER SECTION:

mailserver.com.        3600    IN    MX    10 secondary.mailserver.com.
mailserver.com.        3600    IN    MX    1 primary.mailserver.com.

;; Query time: 104 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Jan  6 15:02:06 2012
;; MSG SIZE  rcvd: 72

Howto set up a backup MX for Zimbra in Ubuntu/Debian

 Clusterweb, Linux, Servidor de E-mail  Comentários desativados em Howto set up a backup MX for Zimbra in Ubuntu/Debian
maio 032012
 

Have you ever wanted to set up a backup mail exchanger (MX) for your main Zimbra installation? Recently, I had this need for two of my Zimbra installations. Of course, if you run the enterprise version of Zimbra where they offer you the tools to do this without too much work out of the box. But if you just don’t have the resources to put up another full scale Zimbra server, you can achieve much of the same with much less. Of course, it won’t offer you all the bells and whistles that a full Zimbra installation will, but it does the trick if your needs are sparse.

You can run this backup MX of a low price VPS or similar services. And in this day and age, you have a huge selection of such providers that won’t set you back in terms of money. You have great providers such as Linode that offers this at an affordable price, that give you a virtual server where you have complete root access to your virtual server. Which is just what we need to achieve our task of setting up a backup MX. If this is something you want and need, please continue to read this article.What I’ve done, is make two BASH scripts to make the task of setting up a backup MX a breeze as well as making the process automated once set up. I assume in this howto that you already have a fully working installation of Zimbra in production. I also assume that you have NTP (Network Time Protocol) set up and working on both hosts. We first start the work on our main host, the existing Zimbra server. We require root privileges to run the script, so let’s sudo into the root account.

youruser@main:~: sudo su -
root@main:~#: wget "http://redmine.tolecnal.net/projects/zimbrabackupmx/repository/revisions/master/raw/gen-users.sh"
root@main:~#: vim gen-users.sh

What the script ‘gen-users.sh’ does, is to query the Zimbra LDAP server for a list of active user accounts on all of your domains. This list is formatted in such a way that the backup host can easily parse it, and generate the necessary configuration files for postfix, which is used as the MTA on the backup host. You need to change a few things in the script before we proceed, namely the variables ‘REMOTEUSER’, ‘REMOTEHOST’ and ‘REMOTEPATH’. Since the scripts on both ends needs to be run as root, all that’s left to configure is really ‘REMOTEHOST’. Set this to the hostname of your backup MX host.

Since the list of users that are needed by the backup host needs to be copied over, I’ve chosen to do this using scp. Seeing as we want this process automated, we need to create a SSH key without a password using ssh-keygen.

root@main:~#: ssh-keygen -t rsa
root@main:~#: ssh root@remotehost mkdir -p .ssh
password:
root@main:~#: cat .ssh/id_rsa.pub | ssh root@remotehost 'cat &gt;&gt; .ssh/authorized_keys'
password:

To confirm that we’ve successfully enabled to authorized key on the remote host, we issue the following command (you should not need to enter a password).

root@main:~#: ssh root@remotehost hostname

At this point, the configuration files created by ‘gen-users.sh’ should be copied over to the remote host without being asked for a password. To automate the task, we also need to set up a crontab entry for the script. I prefer to run the script at 30 minute intervals, and I choose it to run at every whole hour and thirty minutes past the hour.

root@main:~#: crontab -e

Just add this to your crontab.

0/30 * * * * /root/gen-users.sh

Save the file, and cron should state that the crontab has been installed. To verify this, you can monitor your syslog and look out for the following:

Feb 12 11:30:02 mainhost BackupMX: SUCCESS: created the list of users
Feb 12 11:30:05 mainhost BackupMX: SUCCESS: sent user list to seattle.thebios.com

We now have to move over to our secondary box. I already assume that you have postfix installed and working for local mail delivery, and if you haven’t done so, do so now before proceeding. I won’t cover this process here, so if you’re in doubt on this one, please consult one of the many howto’s out there on how to get a basic postfix installation running. Just as on the main Zimbra host, we need to sudo into our root account and download the script.

youruser@backup:~: sudo su -
root@backup:~#: wget "http://redmine.tolecnal.net/projects/zimbrabackupmx/repository/revisions/master/raw/gen-postfix-config.sh"
root@backup:~#: vim gen-postfix-config.sh

You really shouldn’t need to change much here to get things working, maybe apart from the paths to postconf, postmap and postfix itself (if you’re not running Debian or Ubuntu). I would highly recommend that you keep ‘DEBUG’ enabled, even in production as it logs useful information to syslog. If you’ve successfully set up the main host, and verified that you indeed have the file ‘zimbra_recipients.list’ in your /root folder that was copied over with scp, we are good to go. All we need to do now is to set up a crontab entry for the job. I prefer to run this task at every five minutes past the hour and every 35 minutes past the hour. This is five minutes after the user/domain list was created on the main host, and should have made it over to the backup host (you did remember to set up NTP right?). So let’s set up the crontab.

root@backup:~#: crontab -e

Add this to your crontab

5/35 * * * * /root/gen-postfix-config.sh

Cron should now state that your crontab was successfully installed. At this point, you should be able to monitor your syslog to see that the script generates the needed configuration files for postfix. These files/configuration directives include:

  • The relay domains map (which domains postfix on our backup host should relay mails for if our main host is down)
  • The relay map (which user accounts under our domain(s) we allow incoming mail from)

If all has gone well, you should be able to see something similar to this in your syslog.

Feb 20 12:02:24 backuphost BackupMX: MD5 has changed - need to notify postfix of changes
Feb 20 12:02:24 backuphost BackupMX: Domains to relay for: $mydestination yourdomain1.com yourdomain2.org yourdomain3.net ... [etc]
Feb 20 12:02:24 backuphost BackupMX: SUCCESS: postconf updated with relay domains
Feb 20 12:02:24 backuphost BackupMX: SUCCESS: created the relay_recipient_maps file
Feb 20 12:02:24 backuphost BackupMX: SUCCESS: copied the relay map to /etc/postfix/backup-mx-relays
Feb 20 12:02:26 backuphost BackupMX: SUCCESS: postconf notified about the new relay map
Feb 20 12:02:26 backuphost postfix/postfix-script[18348]: refreshing the Postfix mail system
Feb 20 12:02:26 backuphost postfix/master[32541]: reload -- version 2.7.1, configuration /etc/postfix
Feb 20 12:02:26 backuphost BackupMX: SUCCESS: postfix configuration reloaded

This sums up this howto. I wish you all the best with setting this up, and I hope you found this useful. Comments are more than welcome, and if you find any bugs, please report them over at my