Z2Z: Zimbra to Zimbra Migration Tool

422789_3f8a1934797d4200a0dd9fb2c6b61a34-mv2

Olá ! É com muito prazer que anuncio a ferramenta Z2Z (Zimbra to Zimbra Migration Tool) !

Essa ferramenta foi criada visando facilitar o processo de migração entre ambientes Zimbra, independentemente de qual versão ou edição esteja sendo utilizada. Motivada pelos desafios encontrados em migrações efetuadas pela BKTECH (parceiro oficial Zimbra para negócios e treinamentos), além da participação em comunidades do Zimbra, a ferramenta visa, no decorrer de sua evolução, atender os mais diversos cenários, contemplando também a migração de outras plataformas, livres e proprietárias.

Z2Z – Link para download: https://github.com/BktechBrazil/Z2Z

Embora o Zimbra seja uma ferramenta bastante avançada na questão de utilitários de migração, a ferramenta agiliza e simplifica o processo, exportando as classes de serviço, contas, nomes alternativos e listas de distribuição. Nesta primeira versão (0.9), Z2Z facilita o processo de exportação das entradas citadas, além de criar o lote de contas que devem ser exportadas, utilizando o comando nativo – zmmailbox.

Interface Inicial da ferramenta Z2Z:

prtscr-capture

Anúncios

Dovecot: Adicionando mais informações na entrega da mensagem

Olá ! Esta dica é para quem utiliza o Dovecot e deseja aumentar a rastreabilidade das mensagens entregues. Por padrão, ao entregar a mensagem na caixa postal do usuário o Dovecot registra somente com as informações como no exemplo abaixo:

lda(joao@laboratorio.com.br): Info: msgid=<d3eeda6273fd6200692be138668e43fd@laboratorio.com.br>: saved mail to INBOX

Muitas vezes o ID da mensagem (msgid) não é suficiente para rastrear a mensagem e certamente ter informações como o remetente e o assunto ajuda muito.

Para incluir estas informações na entrega, configure o parâmetro deliver_log_format conforme abaixo:

deliver_log_format = from:%f msgid:%m subject:%s action:%$ 

Desta forma, para todas as entregas o Dovecot irá registrar, nesta ordem: Remetente, ID da Mensagem, Assunto e ação aplicada.

Exemplo:

lda(joao@laboratorio.com.br): Info: from:joao@dextermatriz.com.br msgid:<1817fc98bb0f6b64372aea33184718fa@laboratorio.com.brr> subject:Novo teste action:saved mail to INBOX

Postfix: Efetuando relay em hosts que exigem autenticação E nas portas SUBMISSION ou SMTPS

Olá ! Em um post anterior eu tratei as configurações necessárias para configurar o Postfix para efetuar relay em um servidor que exige autenticação: https://respirandolinux.wordpress.com/2014/10/25/postfix-efetuando-relay-em-hosts-que-exigem-autenticacao/

Ocorre que muitas vezes é necessário efetuar o relay no servidor utilizando as portas SUBMISSION (587) ou SMTPS (465). Para que seja possível efetuar essa entrega, as configurações abaixo podem ser utilizadas (exemplo com destino utilizando submission):

O parâmetro que define o host para onde será encaminhada a mensagem é o relayhost:

Exemplo:

relayhost = servidor-externo.laboratorio.com.br

Agora para fazer com que o Postfix autentique ao efetuar o relay e inicie a encriptação exigida pelo serviço SUBMISSION, insira as configurações conforme abaixo:

relayhost = servidor-externo.laboratorio.com.br:587
smtp_sasl_password_maps= hash:/etc/postfix/sasl_passwd
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous, noplaintext
smtp_sasl_tls_security_options = noanonymous

O grande detalhe aqui está no parâmetro smtp_sasl_password_maps, onde iremos inserir no arquivo criado o usuário e senha para autenticação no host definido em relayhost.

O arquivo deve ser criado no seguinte formato:

hostname-do-relayhost.fqdn:porta                     usuario:senha

Nosso exemplo:

servidor-externo.laboratorio.com.br:587              usuario:senha

Efetuadas as configurações, rode o postmap no arquivo /etc/postfix/sasl_passwd e efetue um reload no serviço do Postfix.

Postfix: Efetuando relay em hosts que exigem autenticação

Olá ! É muito comum para administradores de correio eletrônico precisar configurar o servidor para efetuar relay em outro host. Porém geralmente essa prática é feita tendo o IP do servidor liberado no servidor de relay. Neste post irei tratar a configuração que pode ser feita no Postfix caso o host exija autenticação.

O parametro que define o host para onde será encaminhada a mensagem é o relayhost:

Exemplo:

relayhost = servidor-externo.laboratorio.com.br

Agora para fazer com que o Postfix autentique ao efetuar o relay insira as configurações conforme abaixo:

smtp_sasl_auth_enable= yes
smtp_sasl_password_maps= hash:/etc/postfix/sasl-passwd
smtp_sasl_security_options= noanonymous

O grande detalhe aqui está no parametro smtp_sasl_password_maps, onde iremos inserir no arquivo criado o usuário e senha para autenticação no host definido em relayhost.

O arquivo deve ser criado no seguinte formato:

hostname-do-relayhost.fqdn                     usuario:senha

Nosso exemplo:

servidor-externo.laboratorio.com.br               usuario:senha

Efetuadas as configurações, rode o postmap no arquivo /etc/postfix/sasl-passwd e efetue um reload no serviço do Postfix.

Postfix: Contornando comandos incorretos de conexões SMTP

Olá !

Anteriormente, eu publiquei um artigo (https://respirandolinux.wordpress.com/2013/09/20/postfix-contornando-501-syntax-helo-hostname/) sobre como contornar o erro de sintaxe quando clientes remotos enviam o comando HELO/EHLO de forma incorreta, principalmente sem inserir o hostname após o comando. Utilizando o procedimento do meu artigo anterior, não será mais possível aplicar restrições na etapa HELO/EHLO, uma vez que independentemente da entrada, o resultado sempre será “OK”.

É muito comum quando temos um servidor SMTP que será utilizado por aplicações, muitos comandos serem enviados com a sintaxe incorreta ou até mesmo estas aplicações enviarem comandos inválidos. Para contornar este problema, podemos utilizar o parâmetro “smtpd_command_filter” no Postfix.

A diretiva “smtpd_command_filter” (disponível a partir da versão 2.7) é descrita na documentação do Postfix como um último recurso para contornar clientes que enviam comandos incorretos ou inválidos de fato. Apesar das modificações que serão aplicadas, é possível aplicar restrições HELO após utilizar esse parâmetro.

Vejamos um exemplo que pode ser utilizado para contornar clientes que enviam o HELO/EHLO sem estar seguido do FQDN:

smtpd_command_filter = pcre:/etc/postfic/command_filters

Conteúdo do arquivo:

/^HELO\s*$/ HELO nome.desejado
/^EHLO\s*$/ EHLO nome.desejado

Desta forma, quando um cliente remoto enviar o HELO/EHLO sem estar seguindo do hostname, este comando será substituído por “HELO/EHLO nome.desejado”.

No log será exibida uma entrada conforme abaixo sempre que um comando por modificado pelo Postfix.:

replacing client command “HELO” with “HELO domain.invalid”