Zimbra 8.6: Entregando os SPAMs independentemente da pontuação

zimbra-no-lettermark - Copy

Olá ! Nesse artigo irei falar sobre o ajuste da ação a ser aplicada no Anti Spam do Zimbra para que a mensagem seja entregue independentemente da sua pontuação (spam score). Nesta nova versão do Zimbra o suporte à ações para mensagens com pontuação de SPAM alta foi aprimorado, permitindo que o administrador defina qual ação seja aplicada.

Essa configuração é armazenada no parâmetro zimbraAmavisFinalSpamDestiny e aceita os seguintes valores:

  • D_DISCARD: Descarta silenciosamente a mensagem (valor padrão)

  • D_PASS: Entrega a mensagem independentemente do Score.

  • D_BOUNCE: Gera um Bounce para a mensagem

  • D_REJECT: Rejeita a mensagem.

Desta forma, desejamos ajustar o parâmetro para o valor D_PASS:

zmprov mcf zimbraAmavisFinalSpamDestiny D_PASS

Spamassassin: Portas para o mecanismo Razor

zimbra-no-lettermark - Copy download (2)

Olá ! Na última turma que ministrei do curso EAD de Zimbra nos deparamos com um problema ao habilitar o mecanismo Razor através de um Firewall, o mesmo não consegui se conectar no pool de servidores deste mecanismo.

Após pesquisas (gostaria de agradecer ao aluno Rickifer pelo empenho na pesquisa) foi constatado que as seguintes portas (Output) devem ser liberadas para o funcionamento deste mecanismo:

2703/tcp e 7/tcp

O mecanismo não necessita de nenhuma porta para conectar no seu servidor.

Referências:

http://wiki.apache.org/spamassassin/NetTestFirewallIssues

Configurando o Amavis em um servidor dedicado

Olá ! Neste artigo apresento as configurações para separar o Amavis em um servidor dedicado. Em alguns ambientes isso pode ser necessário devido ao trafego de mensagens, onde o MTA (neste exemplo o Postfix)e Amavis precisam ser separados em servidores dedicados.

Neste exemplo o servidor Postfix é o host mail.matriz.com.br (192.168.200.116) e o servidor dedicado para o Amavis é o host amavis.matriz.com.br (192.168.200.115)

Primeiramente, no servidor Postfix edite o main.cf adicionando a seguinte linha:

content_filter = smtp-amavis:amavis.matriz.com.br:10024

Ainda no servidor Postfix, edite o arquivo master.cf adicionando o seguinte serviço:

0.0.0.0:10025 inet n – y – – smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o mynetworks=127.0.0.0/8,192.168.200.115/32
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
-o recipient_bcc_maps=
-o sender_bcc_maps=

Deve-se prestar atenção no parâmetro mynetworks do serviço, onde deve ser incluído o IP do servidor do Amavis para entrega das mensagens. Feito isso, após reiniciar o serviço, o Postfix já irá entregar as mensagens com as configurações feitas.

No servidor Amavis, precisamos colocar o serviço para escutar na porta 10024 e aceitar conexões do nosso MTA. No Debian e derivados o arquivo 20-debian_defaults pode ser editado para incluir as configurações ou o 50-user, que vem limpo justamente para as configurações adicionais. Para distribuições baseadas em Red Hat, o Amavis utiliza um único arquivo de configuração.

@inet_acl = qw(127.0.0.1 192.168.200.115 192.168.200.116 [::1]); # Controle acesso – Informar os IPs dos MTAs e do servidor amavis
$inet_socket_bind = ‘0.0.0.0’; # Onde escutar – Colocar as interfaces onde o Amavis deve aceitar conexões
$inet_socket_port = 10024; # Porta
### Encaminhando para o Postfix ###
$notify_method = ‘smtp:[mail.matriz.com.br]:10025’;
$forward_method = ‘smtp:[mail.matriz.com.br]:10025’;
###

Efetuada as configurações, reinicie o serviço do Amavis e tente enviar uma mensagem, nos logs do Amavis deve aparecer a conexão do MTA:

Feb  4 13:30:27 amavis amavis[3052]: (03052-01) Passed CLEAN {RelayedInternal}, MYNETS LOCAL [192.168.200.116]:51347 [192.168.200.116] <joao@matriz.com.br> -> <joao@matriz.com.br>, Message-ID: <67917efa9170c57c59fd791eb0e83c47@matriz.com.br>, mail_id: zQYc-U7HehsQ, Hits: -1.326, size: 596, queued_as: 46FAC5A6DC, dkim_new=default:matriz.com.br, 2981 ms

Utilizando o amavis para inserir Disclaimer

Olá ! Nos artigos anteriores eu expliquei sobre a inserção de Disclaimer utilizando um filtro externo escrito somente para essa funcionalidade:

https://respirandolinux.wordpress.com/2013/01/10/postfix-adicionando-disclaimer-excecoes-de-remetentes-e-arquivos-diferentes-por-dominio/

https://respirandolinux.wordpress.com/2013/01/05/postfix-adicionando-disclaimer-excecoes-de-remetentes/

https://respirandolinux.wordpress.com/2012/12/18/postfix-adicionando-disclaimer-todas-as-mensagens-enviadas/

Porém, se o Amavis já estiver implementado é possível utilizar o mesmo para inserir as mensagens automáticas, portanto veremos essa implementação neste artigo.

Primeiramente, é necessário instalar o altermime, que continua sendo o programa utilizado para modificar a mensagem,

Após instalar o altermime, vamos iniciar a configuração do Disclaimer, podendo ser feita no arquivo 50-user.conf do Amavis:

### HABILITA INSERÇÃO DISCLAIMER
$defang_maps_by_ccat{+CC_CATCHALL} = [ ‘disclaimer’ ];

# Programa utilizado para modificar a mensagem
$altermime = ‘/usr/bin/altermime’;

$policy_bank{‘MYNETS’} = { # Modificar somente as mensagens geradas internamente
originating => 1,
allow_disclaimers => 1,
};

# Arquivo com o Disclaimer
@altermime_args_disclaimer = qw(–disclaimer=/etc/postfix/disclaimer/_OPTION_.txt);

@disclaimer_options_bysender_maps = ({
#Permite incluir disclaimer baseado no dominio ou usuário

#Os domínios matriz e filial terão disclaimers diferentes
‘matriz.com.br’ => ‘matriz.com.br’,
‘filial.com.br’ => ‘filial.com.br’,

#O usuario fabio terá um disclaimer pessoal
fabio@matriz.com.br’ => ‘fabio.matriz.com.br’,

#O usuario fulano não terá um disclaimer

fulano@matriz.com.br’ => ‘empty’,

# Disclaimer para ser inserido caso não se encaixe nos critérios acima
‘.’ => ‘default’,
},);

Feito isso, basta reiniciar o serviço do Amavis que as mensagens automáticas já serão inseridas, sendo preciso criar os arquivos no diretório apontado em altermime_args_disclaimer.

Spamassassin e PostgreSQL: sintaxe de entrada é inválida para tipo bytea

Continuando com a série de artigos sobre Amavis e Spamassassin, segue uma dica para quem está integrando o Spamassassin ao PostgreSQL. Após efetuar as configurações observei que não estava sendo possível gravas as mensagens como Spam ou Ham na tabela bayes do Spamassassin, no PostgreSQL era apresentado o seguinte erro:

sintaxe de entrada é inválida para tipo bytea

Isso se devia por estar utilizando a função genérica SQL para o plugin BayesStore:

Mail::SpamAssassin::BayesStore::SQL

Para corrigir, basta alterar a função para a própria do Postgres:

Mail::SpamAssassin::BayesStore::PgSQL 

Spamassassin: Melhorando a eficácia do seu anti-spam

Iniciando a série de artigos sobre o Spamassassin e Amavis, vamos aumentar a eficácia da detecção de Spams atualizando as regras do Spamassassin.

No Debian por padrão a atualização diária das regras do Spamassassin vem desativada, para ativar basta editar o arquivo /etc/default/spamassassin e mudar a varável CRON para 1:

# Cronjob
# Set to anything but 0 to enable the cron job to automatically update
# spamassassin’s rules on a nightly basis
CRON=1

Isso fará com que o script spamassassin, que está no diretório /etc/cron.daily seja executado diariamente.

Porém, há o canal SOUGHT RULES, que é atualizado 4 vezes ao dia pelo desenvolvedor do Spamassassin, e é altamente recomendável utiliza-lo, e pesquisando na internet, inclusive na própria página do projeto são apresentados as melhorias nos resultados após utilização deste canal.

Para utilizar este canal, primeiramente é necessário efetuar o Download e importar a chave do mesmo:

wget http://yerp.org/rules/GPG.KEY

sa-update –import GPG.KEY

Agora, vamos alterar o script do Spamassassin para efetuar utilizar o canal SOUGHT RULES em sua atualização diária, para isso, altere o arquivo /etc/crond.daily/spamassasin, modificando a linha 64 da seguinte forma:

sa-update -v –channel sought.rules.yerp.org –channel updates.spamassassin.org –gpgkey 6C6191E3

Feito isso, basta aguardar a próxima atualização para que as regras do canal SOUGHT sejam instalados, caso queira aplicar imediatamente basta executar o comando conforme inserido no script.


	

Amavis / Spamassassin: Série de artigos

Nas próximas semanas, irei manter uma série de artigos relacionados ao Amavis e Spamassasin, através da experiência com as últimas turmas dos treinamentos que ministro, procurarei compartilhar algumas experiências para aumentar a eficiência destes softwares, principalmente na detecção de Spams.

Um novo artigo sobre este tema será publicado a cada semana, e o primeiro será publicado amanhã (07/08).